From: Mario Loffredo <[email protected]> Sent: Monday, October 5, 2026 12:41 PM To: [email protected] Subject: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-jscontact-27.txt
Hi, I have just submitted version -27. This revision incorporates the latest review comments and updates the document to RFC 10050. The authors wish to draw particular attention to the following considerations supporting the requirement that an RDAP entity object must not include both vcardArray and jscontact_card: - The two members are alternative representations of the same contact information. jscontact_card is intended to provide the same information as vcardArray; it is not an additional, independent set of contact data. - Returning both representations would duplicate information and unnecessarily increase response size and processing costs, especially for responses containing multiple entities. - Two representations in the same response could become inconsistent. Although jCard and JSContact convey substantially the same information, differences could arise through implementation errors or updates applied to only one representation. Clients would then have no rule for deciding which value to use. - Returning exactly one representation is consistent with the principles of content negotiation through the RDAP media-type parameters in the Accept header. - Backward compatibility does not require both members in one response. vcardArray is optional under RFC 9083, while jscontact_card is an RDAP response extension whose presence is explicitly requested by clients and signaled by the "jscontact" conformance identifier. The response therefore remains compliant with RFC 9083 when only jscontact_card is provided. Furthermore, the response remains compatible with existing RDAP profiles and with their potential evolution towards the deprecation of jCard. That said, the authors believe that the draft is now ready for WGLC. [SAH] Section 3.1.12 refers to “internationalized and localized versions of organization, postal address, and email”. Section 3.1.13 refers to “localized versions of name, organization, postal address and email”. There is, however, no normative reference to internationalized email addresses in RFC 9553, so it’s unclear how the “MUST be (included in|added to) the "localizations" map” requirement can be met. Section 3.2 would fit better if it appeared before Section 3.1.1. That would make it clearer that the contact representation returned by the server depends on an explicit client request. It would also help explain why the draft is still disallowing return of both "jscontact_card" and "vcardArray" members in the same RDAP response. Scott
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
