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 <mailto:[email protected]> <[email protected]> Sent: Thursday, September 17, 2026 3:06 AM To: Mario Loffredo <mailto:[email protected]> <[email protected]>; Pawel Kowalik <mailto:[email protected]> <[email protected]>; [email protected] <mailto:[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
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
