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.”
:)
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
