Sorry, I reply to Jasdip instead of relplying to all.
-------- Messaggio Inoltrato --------
Oggetto: Re: [regext] RDAP JSContact feedback
Data: Tue, 9 Nov 2021 13:43:38 +0100
Mittente: Mario Loffredo <mario.loffr...@iit.cnr.it>
A: Jasdip Singh <jasd...@arin.net>
Hi Jasdip,
please find my replies below.
Il 09/11/2021 01:23, Jasdip Singh ha scritto:
Hello Mario,
Please find my comments below.
Thanks,
Jasdip
*From: *Mario Loffredo <mario.loffr...@iit.cnr.it>
*Date: *Monday, November 8, 2021 at 1:09 PM
*To: *Jasdip Singh <jasd...@arin.net>, "regext@ietf.org" <regext@ietf.org>
*Subject: *Re: [regext] RDAP JSContact feedback
1.*Rationale*
“provides a simpler and more efficient representation for contact
information”
Is it possible someone could question the “efficient” part, given
the RDAP response with JSContact would likely be bigger in size
than that with jCard? E.g. the sample jscard member in Fig 1 is
2724 characters whereas the equivalent vcardArray member in Fig 17
in RFC 9083 is 1842 chars, per this word-count tool
<https://wordcounter.net/character-count>. May help to elaborate
what we mean here with efficiency.
[ML] The reasons why the authors considers JSContact more efficient
than jCard are presented in Section 2 (please see after "JSCard
differs from jCard in that it:"). Searching for the meaning of
"efficient" on the web, I find "performing or functioning in the best
possible manner with the least waste of time and effort" so I might
change the sentence as in the following:
" more efficient representation for contact information with regard to
time and effort saved in processing it."
Would it sound better to you?
[JS] Yes.
[ML] Good.
*3. Using JSCard objects in RDAP Responses*
“The JSCard "uid" property SHOULD contain the same value as the
RDAP "handle" property.”
Curious why it is not a MUST?
[ML] Well, RDAP "handle" is registry-unique while JSContact "uid" is
an identifier deigned to be unique across different systems.
That being said, my opinion is: if the contact is used only as part of
an RDAP response, the two properties will much likely coincide. On the
contrary, if the contact is used by the registry also outside the RDAP
ecosystem, they will potentially differ.
Honestly don't know how much the second scenario is realistic but
SHOULD leaves the door open to possible evolutions.
[JS] Ok.
[ML] Good.
“To aid interoperability, RDAP providers are RECOMMENDED to use as
map keys the following string values and labels defined in [RFC5733]”
Should we elaborate upon the consequences if this recommendation
is not followed? Should this be a MUST?
[ML] This is merely a basic set of map keys related to registry's
mostly used information items and recalls the basic field sets
described in RFC8982.
In that circumstance, the WG decided that, being part of the
operational aspects, the field set names should be dependent on the
RDAP profiles.
Should the WG agree on the provided keys, I would have no problem to
change it into MUST.
[JS] Agreed. Good to ask.
[ML] Good.
“"org" in the "organizations" map for either the only or the
internationalized organization;”
Should we clarify further here? Are we trying to say: use it only
when there is a single org, whether internationalized or not?
[ML] Use it when there is a single org. If both internationalized and
localized forms exist, use it for the internationalized form and put
the localized one in the "localizations" property.
[JS] Like how you elaborated it. Perhaps we can include it for clarity.
[ML] Good.
“"addr" in the "addresses" map for either the only or the
internationalized postal address ;”
If we do end up clarifying for org, similar clarification would be
needed here.
Nit: extra space before the semi-colon.
[ML] See my previous comment. I'll correct the typo.
“"email" in the "emails" map for the email address;”
Should we address the EAI (email address internationalization)
scenario here, similar to org and addr i18n?
[ML] Absolutely. I missed that.
“If present, the localized versions of name, organization and
postal address MUST be inserted into the "localizations" map.”
For clarity, would it help to include an example for the localized
versions?
[ML] Agreed.
[JS] Great!
[ML] Good.
“Implementers MAY use different mapping schemes to define keys for
additional entries of the aforementioned maps or others.”
Should we elaborate this further with an example? Do we need to
discuss client implications for this MAY?
[ML] As I wrote above, the provided map keys are related to the
contact properties described in RFC5733 so they are assumed to be the
most commonly used by registries.
However, with reference to the Figure 15 of RFC9083, other contact
information, such as vCard "key" and "url", could be included in other
JSContact maps, i.e. the "online" map.
Obviously, I can add an example matching this case in the document but
I can't find a reasonable mapping scheme other than using a trivial
sequential number (e.g. url-1, url-2, etc.) that seems very trivial
to me.
[JS] Agreed; an example looks like an overkill. Perhaps, for guidance,
we could add some verbiage around “using a trivial sequential number
(e.g. url-1, url-2, etc.)“.
[ML] OK.
*4. Transition Considerations*
*4.2.1.6. Goals*
Should we move this sub-section up to the top, so as to upfront
give the reader a sense of the “requirements” for the transition
design?
[ML] I intended that the WG decided to change the draft title to
clearly state that the draft's primary goal is to define an RDAP
extension.
The jCard replacement is a secondary goal subordinated to other
conditions becoming true; for example, the number of implementations,
the explicit requirement in a RDAP profile to deprecate jCard.
If I understood correctly, this concept must be better clarified in
the document.
[JS] Oh, my point was just to have Goals as the first sub-section
within the Transition Considerations section. :)
[ML] OK. Sorry for the misunderstanding.
“the response would always be compliant to [RFC9083];”
What does this mean when 9083 does not know about JSCard?
[ML] The response would always be compliant for two reasons:
- being the "jscard" property a response extension, its presence would
be signaled by the "jscard" conformance tag;
- being "vcardArray" property optional in a response, its absence
would be allowed.
[JS] Well explained! Wonder if it would be good to add these
clarifying points, to help make it less implicit?
[ML] No problem from my side. I'll change the document to incorporate it.
*4.2.1.2. Stage 2: jCard sunset*
“include a description reporting the jCard sunset end time”
Should we clarify that the notice’s description string would
contain both the time and date, as we do when defining eventDate
in RFC 9083
<https://datatracker.ietf.org/doc/html/rfc9083#section-4.5>?
[ML] I'll correct the sentence in "include a description reporting the
jCard sunset end date and time"
[JS] Ok.
[ML] Good.
“"rel": "deprecation"”
In various examples (Figures 2, 3, 4, and 5), we use this
“deprecation” rel type. Do we need to register it with the IANA
Link Relations registry
<https://www.iana.org/assignments/link-relations/link-relations.xhtml>?
[ML] This is already addressed by
https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-deprecation-header-02#section-7.2
<https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-deprecation-header-02#section-7.2>
[JS] Oh, I missed that. No, we are good here. :)
[ML] :-)
“plus the parameter "jscard" set to a true value”
Should we make it consistent with “1/true/yes” from section
4.2.1.3. Stage 3: jCard deprecation?
[ML] Absolutely.
*6. IANA Considerations*
“Extension identifier: jscard”
Should we version this extension as say, jscard_0, in case we need
to evolve it in the future? That said, we have not always
versioned extensions in the IANA RDAP Extensions
<https://www.iana.org/assignments/rdap-extensions/rdap-extensions.xhtml>
registry.
[ML] Honestly the method we should follow to assign conformance tags
appears still obscure to me :-(
[JS] You are not alone. :)
Maybe, in this case, having to refer to a spec outside RDAP that could
be changed through time, I agree that it could be more appropriate to
add a version number.
[JS] Ok.
[ML] Good.
*7. Security Considerations*
“The only mandatory property, namely "uid", is usually an opaque
string.”
Do we need to clarify further here, given “uid” would be a
non-opaque handle in jscard?
[ML] Sorry but I didn't catch this. Did you mean that "uid" in jscard
could disclose some sensitive contact information?
[JS] That’s an interesting question. In contrast with a UUID for a
“uid”, a handle might disclose. But, I was simply reacting to the
“usually an opaque string” phrase given we have a SHOULD for “uid”
being a handle. Meaning, in our case, it would more likely be a handle
(less opaque) than a UUID (more opaque).
[ML] UUID is not the only value accepetd for "uid" in JSContact (see
https://datatracker.ietf.org/doc/html/draft-ietf-jmap-jscontact-08#section-2.1.2
<https://datatracker.ietf.org/doc/html/draft-ietf-jmap-jscontact-08#section-2.1.2>),
both URI and free-form text are accepted.
Maybe opaque is not the right term. I'll rearrange the sentence to mean
that the only required property in JSContact is not a sensitive
information as it happens with fn for jCard.
“redacted properties can be merely excluded without using
placeholder values”
Now that we have the RDAP redaction draft
<https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/>,
should we elaborate further vis-à-vis the Removal and/or Empty
Value redaction methods?
[ML] Can you clarify this point?
[JS] I was thinking it could guide better here by saying that use the
Removal method, with a reference to the RDAP redaction draft
<https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/>
included. IIUC, JSContact seems to obviate the Empty Value method,
unlike for redacting “” or null values in jCard.
[ML] Ah, understood.
*General comments:*
1. Does the portion of the spec for jCard to JSContact transition
signaling add significant implementation overhead for RDAP
servers and clients? Could an out-of-band (OOB) method have
been employed? (There is a similar transition effort happening
in the RPKI space, in moving from rsync to RRDP
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-prefer-rrdp-01>,
but that seems more OOB.) Just wanted to ask in the spirit of
“what not to do.” :)
[ML] Obviously, we can figure out the best way for RDAP providers to
inform the clients about the transition steps. Personally, I'm in
favor of REST services providing self-descriptive responses and this
is the spirit of
https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-deprecation-header-02
<https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-deprecation-header-02>
but I'm open to any shared proposal.
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
