From: Mario Loffredo <[email protected]> Sent: Wednesday, September 16, 2026 8:35 AM To: Scott Hollenbeck <[email protected]>; 'Antoin Verschuren' <[email protected]>; [email protected] Cc: Robert Stepanek <[email protected]> Subject: [regext] Re: I-D Action: draft-ietf-regext-rdap-jscontact-26.txt
Hi Scott, thanka a lot for your feedback. Please find my comments embedded below prefixed with [ML] Il 15/09/2026 20:08, Scott Hollenbeck ha scritto: Thanks for the reminder, Antoin. I found a few things that I’d like to discuss: Section 3.1.1: “An entity object MUST NOT contain both the "jscontact_card" and "vcardArray" members.” Why is this? It feels like more of a policy restriction (that has no place in a protocol specification) than a technical restriction, and if having both makes life easier for clients why not allow both formats as long as they include the same information? Part of what concerns me here is that the draft has a stated assumption of the JSContact representation of contact information deprecating the jCard representation of contact information. If you’re an operator that has already implemented and deployed jCard, there may be little motivation for replacing your working code just because an RFC is published that describes a new format. [ML] The intention is not to require an operator that currently provides jCard to replace it merely because this specification is published. Implementing the JSContact extension is optional, and an operator that does not choose to transition can continue to return jCard. The transition procedure applies only when an operator elects to introduce JSContact. The prohibition against including both members is an interoperability constraint rather than a claim that maintaining both representations is technically impossible. When a client explicitly requests JSContact using either of the negotiation mechanisms defined in Section 3.2, there is no reason to return jCard as well. The client has indicated its preferred representation, and returning both would only duplicate the same contact information. Legacy clients remain supported during Stage 2 because a client that does not request JSContact continues to receive jCard. The requirement therefore ensures that each response contains only the selected contact representation; it does not require an operator to implement JSContact or to discontinue an existing jCard implementation. Returning both representations could also create ambiguity if their contents differ. A server can complete the transition from jCard to JSContact only when all clients have completed it on their end. However, I agree that this rationale may appear not to be sufficiently explicit in Section 3.1.1 and propose adding explanatory text there. I will also clarify that publication of this specification does not require an existing RDAP operator to implement JSContact or to discontinue jCard. I would add the following text after the second paragraph of Section 3.1.1: This restriction does not require an RDAP server to implement JSContact or to discontinue support for jCard. A server that does not implement this extension can continue to represent contact information exclusively using "vcardArray". A server that supports both representations selects the representation returned in a particular response as described in Sections 3.2 and 4.2. I would also add the following text at the beginning of Section 4.2 The transition procedure defined in this section applies when an RDAP operator elects to replace jCard with JSContact. This specification does not require an operator to initiate that transition or to discontinue an existing jCard implementation. Do the proposed texts work for you ? [SAH] Not really. I explained why in another message sent a moment ago. Section 3.1.9: Can internationalized email addresses be used? JSContact doesn’t support them. It references RFC 5322 for email address syntax, not the later 6530/6531 specifications. Text needs to be added to make it clear one way or another. [ML] Thank you very much for pointing this out. We will publish a new document updating RFC 9553; we will include the replacement of the normative reference to RFC 5322 with RFC 6531, along with other changes. [SAH] That’ll do it! Scott
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
