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