Hi Pawel,
please find my comments embedded below prefixed with [ML]
Il 16/09/2026 17:14, Pawel Kowalik ha scritto:
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.
[ML] Basically, supporting JSContact format is an extension. Therefore,
a server MAY return the jscontact_card, i.e. supporting the JSContact
format is not required.
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.
[ML] Your interpretation is correct. The JSContat format is returned
only upon request. If a client requests this extension, this means that
it's capable of handling the jscontact_card member; therefore, returning
the vcardArray member as well is superfluous, and its absence in the
response doesn't break the client.
The other scenario where the server returns the JSContact extension
regardless of whether it is requested is when the server transition
from jCard to JSContact is completed, implying that all involved clients
have finished the transition on their end. However, it can happen that a
server continues to support both formats for a long time.
New jCard-based clients intending to interact with a server returning
exclusively the JSContact format are informed, via the "noJcard"
rdapConformance tag in the help response, that the server will not
return the vcardArray member.
Best,
Mario
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.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]
_______________________________________________
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]
