From: Mario Loffredo <[email protected]> Sent: Thursday, September 17, 2026 3:24 PM To: Scott Hollenbeck <[email protected]>; 'Pawel Kowalik' <[email protected]>; [email protected] Subject: Re: [regext] Re: I-D Action: draft-ietf-regext-rdap-jscontact-26.txt
Il 17/09/2026 18:12, Scott Hollenbeck ha scritto: From: Mario Loffredo <mailto:[email protected]> <[email protected]> Sent: Thursday, September 17, 2026 11:48 AM To: Scott Hollenbeck <mailto:[email protected]> <[email protected]>; 'Mario Loffredo' <mailto:[email protected]> <[email protected]>; 'Pawel Kowalik' <mailto:[email protected]> <[email protected]>; [email protected] <mailto:[email protected]> Subject: Re: [regext] Re: I-D Action: draft-ietf-regext-rdap-jscontact-26.txt Il 17/09/2026 16:31, Scott Hollenbeck ha scritto: From: Mario Loffredo <mailto:[email protected]> <[email protected]> Sent: Thursday, September 17, 2026 9:38 AM To: Scott Hollenbeck <mailto:[email protected]> <[email protected]>; 'Pawel Kowalik' <mailto:[email protected]> <[email protected]>; 'Mario Loffredo' <mailto:[email protected]> <[email protected]>; [email protected] <mailto:[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: 1. objectClassName -- the string "entity" 2. handle -- a string representing a registry-unique identifier of the entity 3. 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. [SAH] I have to disagree with that, Mario. You’re writing a draft that’s known to conflict with other operational extensions. It’s up to you to describe how to mitigate the conflicts. Once this draft becomes an RFC it’ll be up to designers of new profiles and new extensions to accommodate it. Scott Scott, I may agree with the general principle that this document should describe how it interacts with existing specifications and known deployed extensions. However, I don't believe that the ICANN gTLD RDAP Response Profile creates a conflict with this draft. I'm not aware of any other extension that conflicts with this one either. RFC 9083 does not require every entity object to include a vcardArray member. Section 5.1 states that an entity object "can contain" a vcardArray, while Section 2.1 allows servers to omit optional registration-data members according to server policy. As you pointed out, the only member that RFC 9083 expressly requires in every RDAP response object is objectClassName, as specified in Section 4.9. The ICANN RDAP Response Profile explicitly anticipates alternative contact representations. Section 1.6.1 requires a server to use jCard only "absent an indication from the RDAP client preferring an alternative format". Section 1.6.2 permits the use of alternative formats approved as Proposed Standards. Section 1.6.3 then provides the applicable rule when a client requests such a format: the server MUST represent the contact information using (1) jCard, (2) the requested alternative format, or (3) both. Consequently, the Profile clearly allows a server to return only the requested alternative representation. When JSContact is requested, returning jscontact_card without vcardArray is one of the alternatives already allowed by Section 1.6.3. The other requirements in the Profile identify contact data that must be returned in particular contexts; they do not establish a general requirement that every entity object always include vcardArray (see Sections 2.4.1, 2.4.5, 2.7.4, 2.7.6 and 3.1). When JSContact is requested, the draft maps those required data elements to their JSContact counterparts. Therefore, the Profile’s substantive data requirements can still be satisfied without providing the same contact information a second time via vcardArray. The prohibition against returning both jscontact_card and vcardArray in the same entity does narrow the three choices offered by Section 1.6.3 of the Profile. For a JSContact request, the server uses the second choice (i.e, the requested alternative format) rather than the third one (i.e. both formats). It doesn't eliminate a Profile requirement. This restriction also applies only after the client has explicitly requested JSContact through one of the mechanisms defined by this draft. A client that doesn't request JSContact continues to receive the default jCard representation. Therefore, existing clients and deployments are not required to replace jCard merely because this document is published. If there is a known operational extension that normatively requires vcardArray, or that addresses values within vcardArray using representation-specific paths, I agree that this document should identify that extension and define whether it is incompatible with JSContact or provide an equivalent JSContact mapping. However, that is a specific extension-interaction issue. It does not establish a general need to return both contact representations. [SAH] Correct, but given the current draft text that disallows returning both representations there’s a conflict with the third option (both) described in Section 1.6.3 of the profile. Scott
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
