Re: [regext] RDAP JSContact feedback

[Jasdip Singh <[e-mail]>]

Hello Mario,

Please find my comments below.

Thanks,
Jasdip

From: Mario Loffredo <[e-mail]>
Date: Monday, November 8, 2021 at 1:09 PM
To: Jasdip Singh <[e-mail]>, "[e-mail]" <[e-mail]>
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.

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.

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

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

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


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

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

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

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.

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


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

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

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



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