Il 17/09/2026 16:31, Scott Hollenbeck ha scritto:
*From:*Mario Loffredo <[email protected]>
*Sent:* Thursday, September 17, 2026 9:38 AM
*To:* Scott Hollenbeck <[email protected]>; 'Pawel
Kowalik' <[email protected]>; 'Mario Loffredo'
<[email protected]>; [email protected]
*Subject:* [regext] Re: I-D Action:
draft-ietf-regext-rdap-jscontact-26.txt
Hi Scott,
please find my comment below.
Il 17/09/2026 14:09, Scott Hollenbeck ha scritto:
-----Original Message-----
From: Pawel Kowalik<[email protected]>
<mailto:[email protected]>
Sent: Thursday, September 17, 2026 3:06 AM
To: Mario Loffredo<[email protected]>
<mailto:[email protected]>; Pawel
Kowalik<[email protected]>
<mailto:[email protected]>;[email protected]
Subject: [regext] Re: I-D Action:
draft-ietf-regext-rdap-jscontact-26.txt
Hi Mario,
On 16.09.26 18:03, Mario Loffredo wrote:
[SAH] [snip]
PK> "JSContat format is returned only upon request" - is it a reasonable
assumption? RDAP is build around "ignore unknown properties" therefore
it shall remain an option for the server to add the extension data even
if not requested, even if it is in the transition - which I would assume
would be the typical approach to double the content if there is no
signal in place.
[SAH] After thinking about this some more, I have a more fundamental issue with the draft that Pawel
touches on above. We have to remember that jCard and "rdap_level_0" as defined in RFC 9083 are
tightly coupled. A server can't signal support for "rdap_level_0" without supporting jCard. That's
immutable without updating or replacing 9083. I prefer an option where a server that supports JSContact
signals support for the "jscontact" extension in the usual way and returns both representations. As
Pawel describes above, the extension data can be included even if not explicitly requested because we're
assured that clients will ignore things that they don't understand. Clients that want the JSContact
representation will receive it, and clients that don't want it can ignore it.
Deprecation of jCard use in RDAP, or changing what "rdap_level_0" means,
requires either update or replacement of 9083. We can't get around that.
[ML] Section 5.1 of RFC9083 states the following:
The entity object class *can contain *the following members:
* objectClassName -- the string "entity"
* handle -- a string representing a registry-unique identifier of
the entity
* vcardArray -- a jCard with the entity's contact information
....
My interpretation is that an RDAP response including an entity object
remains compliant with "rdap_level_0" even when the vcardArray member
is missing.
The text defines which members are allowed in an entity object, not
which ones are mandatory.
The other normative language mentioning jCard refers to the case where
contact information is included and provided via jCard.
The handle property may also be missing.
In fact, RFC9537 includes an example in which the handle property -
despite belonging to a domain object - is redacted by the removal method.
There is nothing in the definition of handle and vcardArray that makes
handle optional and vcardArray mandatory.
Maybe I'm wrong but could you please indicate where it is clearly
stated that an entity object MUST include the vcardArray member?
*/[SAH] That’s a good point. It isn’t clearly stated. The current “can
contain” text could be interpreted to mean that *all* of the members
of an entity object are OPTIONAL. Section 4.9 clarifies that the
"objectClassName" member is REQUIRED (5.1 should really note the
requirement, too. That may merit an errata report.), but there’s not a
similar requirement for a vcardArray or any other member. I can’t
remember why we chose to use “can contain”, except that it supports
the development of operational profiles (such as ICANN’s gTLD response
profile) to provide greater specificity. Ugh./*
*//*
*/ICANN’s gTLD response profile requires a vcardArray in some cases.
That’s a potential conflict. It may be worth noting somewhere that
jCard omission could cause a conflict with any extensions or profiles
that require inclusion of a vcardArray./*
*//*
*/Scott/*
I believe this is a matter to be addressed within the scope of specific
RDAP profiles. Similarly, the specification regarding JSContact profiles
allows profile designers to define additional constraints beyond those
in RFC 9553.
Best,
Mario
--
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]
