I am generally supportive of this work and have implemented JSContact in both client and server form. However, there are a number of problems with this version:
1. As Scott has pointed out, the MUST/MUST NOT of Section 3.1.1 p2&3 are problematic. A server's policy is a server's policy, and no client signaling changes that. Client signaling just informs the server of client capabilities. If a server wants to have both jCard and JSContact at the same time to maximize interoperability, the server operator should be able to do so. 2. Section 4 is overly broad. It should only suggest a transition strategy where client signaling informs the server. Furthermore, the "alternate" link will never be used, and I think most server operators would prefer to return both jCard and JSContact instead of the extra query. And practically speaking, this creates rate limiting implications for the clients and servers. 3. As Jasdip has mentioned, there is a tension between versions_list and exts_list, and the draft assumes the client knows which one to use for every particular server. I am not sure how that works. 4. This draft has normative references two other drafts in this working group upon which there is plenty of disagreement (one of those drafts has changed drastically three separate times). Sending this through now risks having it sit in the RFC queue only to be pulled back to the working group should one of the normative references impact this one (again, one of those drafts has changed drastically three separate times). -andy, no hats On 9/15/26 2:08 PM, 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.txt > > > > Dear 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] > <mailto:[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] <mailto:[email protected]> > > *Rispondi-a: * > > > > [email protected] <mailto:[email protected]> > > *A: * > > > > [email protected] <mailto:[email protected]> > > *CC: * > > > > [email protected] <mailto:[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/ > <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 > <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 > <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] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > > _______________________________________________ > regext mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[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 to [email protected]
