Hi Mario, I was also confused with the logic of current 3.1.1.
I believe it should be saying, that in implementing this extension jscontact_card is MUST (not MAY) at the places where vcardArray appears today, and it is MAY for vcardArray accounting for transition period.
And I copy what Scott tells - MUST NOT of the two representations is very misleading and not even an intention. As implementer I would interpret that the two would never appear in one object and maybe even reject the payload if they did -which is not the intention.
Kind Regards, Pawel On 15.09.26 20:08, Scott Hollenbeck wrote:
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.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.Section 7 looks really good! Scott *From:*Antoin Verschuren <[email protected]> *Sent:* Monday, September 14, 2026 10:23 AM *To:* [email protected]*Subject:* [regext] Re: I-D Action: draft-ietf-regext-rdap-jscontact-26.txtDear WG,We would like to move this document to WGLC, but we haven’t seen any comments on the last (version 26) document.The document does have 21changes though, some of them substantial.We want to avoid discussing any changes in WGLC, so could we please have some review before we issue the WGLC?If you reviewed any changes in version 26 and you agree, please send a message to the list too.Regards, Your co-chairs Jim, Jorge and Antoin Op 27 aug 2026, om 09:12 heeft Mario Loffredo <[email protected]> het volgende geschreven: Hi, the authors believe that this document is ready for the WGLC. Best, Mario -------- Messaggio Inoltrato -------- *Oggetto: * [regext] I-D Action: draft-ietf-regext-rdap-jscontact-26.txt *Data: * Thu, 27 Aug 2026 00:09:40 -0700 *Mittente: * [email protected] *Rispondi-a: * [email protected] *A: * [email protected] *CC: * [email protected] Internet-Draft draft-ietf-regext-rdap-jscontact-26.txt is now available. It is a work item of the Registration Protocols Extensions (REGEXT) WG of the IETF. Title: Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses Authors: Mario Loffredo Gavin Brown Name: draft-ietf-regext-rdap-jscontact-26.txt Pages: 39 Dates: 2026-08-27 Abstract: This document describes an RDAP extension which represents entity contact information in JSON responses using JSContact. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-jscontact-26 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-jscontact-26 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ regext mailing list [email protected] To unsubscribe send an email [email protected]
OpenPGP_0x46946DDF180B154D.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
