I agree with Scott, that replacing the response of an existing object class of RFC 9083 would require updating or replacing RFC 9083. The "/entity/XXXX query" is defined as using jCard to represent the contact information. How about if the jscontact extension created a new object class that is an alternative to the entity object class in RFC 9083, such as "/jscontact_entity/XXXX query" returning jscontact in place of jCard to represent the contact information with the "objectClassName" of "jscontact_entity"? I don't believe that RFC 9083 requires the use of the "entities" member to return the related entities in other object classes. Could the "jscontact_entities" member be used as an alternative? Server implementation compliant with RFC 9083 would need to continue to support entity queries using jCard in the response and could optionally support jscontact entity queries and inclusion of jscontact entities (e.g., "jscontact_entities") as members of related objects, such as the domain object in RFC 9083.
-- JG James Gould Fellow Engineer [email protected] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 9/17/26, 8:12 AM, "Scott Hollenbeck" <[email protected] <mailto:[email protected]>> wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > -----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] <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. Scott _______________________________________________ regext mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
