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 ?
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.
Section 7 looks really good!
[ML] Thanks.
Best,
Mario
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]> 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]
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
