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