[regext] Fwd: RDAP JSContact feedback

[Mario Loffredo <[e-mail]>]

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 <[e-mail]>
A: 	Jasdip Singh <[e-mail]>



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