Subject: [regext] RDAP JSContact feedback

From: Jasdip Singh <[email-masked]>
Date: Sun, 7 Nov 2021 20:58:37 +0000

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

---

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

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?

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

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

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

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

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

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

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?

“the response would always be compliant to [RFC9083];”

What does this mean when 9083 does not know about JSCard?

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

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

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

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.

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?

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

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.” :)

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 8 Nov 2021 19:08:13 +0100

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*
>
> 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*
>
[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]”
>
[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.

> 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.
> Nit: extra space before the semi-colon.
[ML] See my previous comment. I'll correct the typo.
> 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.”
>
[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.

> 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*
>
> 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>
> Stage 3: jCard deprecation?
[ML] Absolutely.
> *6.  IANA Considerations*
> 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*
>
[ML] Sorry but I didn't catch this. Did you mean that "uid" in jscard 
could disclose some sensitive contact information?

> 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
> [email-masked]
> 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

---

From: Jasdip Singh <[email-masked]>
Date: Tue, 9 Nov 2021 00:23:01 +0000

Hello Mario,

Please find my comments below.

Thanks,
Jasdip

From: Mario Loffredo <[email-masked]>
Date: Monday, November 8, 2021 at 1:09 PM
To: Jasdip Singh <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [regext] RDAP JSContact feedback

1.      Rationale

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

[JS] Yes.

[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] 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.

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.

[JS] Great!

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

4.2.1.6.  Goals

[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. :)

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

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.

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

[JS] Oh, I missed that. No, we are good here. :)

6.  IANA Considerations

[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] 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).

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

General comments:

[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 but I'm open to any shared proposal.