Re: [regext] RDAP JSContact feedback

[Mario Loffredo <[e-mail]>]

Hi Jasdip,

thanks a lot for your careful review.

Please find my comments inline.

Il 07/11/2021 21:58, Jasdip Singh ha scritto:
>
> Hello Mario, Gavin,
>
> Please find below the initial shepherd feedback for the latest 03 
> <https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-jscontact-03> 
> draft.
>
> Thanks,
>
> Jasdip
>
> ---
>
>      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?

> *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.

> “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.

> “"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.
>
> “"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.
>
> “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.

> *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.

> “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.

> *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"
>
> “"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>
>
> “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 :-(

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.

> *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?

> “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?
>
> *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.


Best,

Mario

> 1.
>
>
> _______________________________________________
> regext mailing list
> [e-mail]
> 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: [phone]
Web: http://www.iit.cnr.it/mario.loffredo