[regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-09.txt

[Pawel Kowalik]

Hi Jasdip,

On 12.12.25 21:28, Jasdip Singh wrote:

Hi Pawel,

From: Pawel Kowalik <kowalik=40denic...@dmarc.ietf.org>
Date: Friday, December 12, 2025 at 3:59 AM
To: Andy Newton <a...@hxr.us>, regext@ietf.org <regext@ietf.org>
Subject: [regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-09.txt

On 11.12.25 22:02, Andy Newton wrote:

    Just to be clear, are you suggesting evolving an extension without
    an evolution signal should be allowed? In other words, not MUST
    NOT and not NOT RECOMMENDED?

Yes, not MUST NOT and not NOT RECOMMENDED.

But RECOMMEND using versioning extension and MUST assure clients do not break, whatever it means if not yet enough specified in STD 95. [JS] To your "assure clients do not break, whatever it means” point, would it help to clarify that in the draft?

[PK] definitely. I am in doubt if we come up with an exhaustive list, but giving some guidance and examples would be of a value

 From a client’s perspective, changes injected into an existing extension (without a successor extension) could fall into: Breaking: new object class, referral with different semantics from another extension, altered JSON member value syntax, new required JSON member, new required query parameter

[PK] "new object class" - only if returned on an already existing path, otherwise it's not breaking

"referral with different semantics from another extension" - this I don't understand. What is "another extension"? Do you mean new semantics of an already defined referral? I believe otherwise the clients shall not break by a presence of any referral link, which they don't understand. "new required JSON member - this is typically valid for requests but not for responses, as "required" actually applies to the server not to the client. I would rather use "new JSON member which is critical to the client to properly understand the response".

Non-breaking: new JSON member, new query path, new query parameter, new HTTP header

[PK] + New referral type

Kind Regards,
Pawel

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org