[regext] Re: draft-ietf-regext-rdap-x-media-type and draft-ietf-regext-rdap-versioning Compatibility Topic 1: Query Identifiers

[Pawel Kowalik <[e-mail]>]

Hi Mario,

Picking some of your examples with my comment:

   "risk_ext": {
     "score": {
       "value": 0.72,
       "scale": "0-1"
     },
     "level": "medium"
   }

PK> This one, as being breaking within realm of risk_ext extension shall 
require risk_ext to change to new extension identifier (e.g. risk_ext2). 
This is what 5.4.1 of draft-ietf-regext-rdap-extensions tells.

Keeping risk_ext shall be only allowed if risk_ext implements own 
signalling of version changes which would make the change non-breaking 
in this context. draft-ietf-regext-rdap-versioning is describing such 
solution.
This is a possibility, however I don't think we should encourage such 
solutions or assume them default, which would in end effect make 
implementation more complex (e.g. simple curl | jq script won't work 
anymore).

"risk_ext": {
   "score": 72,
   "level": "medium",
   "normalizedScore": {
     "value": 0.72,
     "scale": "0-1"
   }
}

PK> this is a non-breaking change which shall be allowed to keep 
extension identifier unchanged. This is where 5.4.2. applies.

"risk_ext": {
   "score": 72,
   "level": "medium"
},
"risk_ext2": {
   "score": {
   "value": 0.72,
   "scale": "0-1"
   },
   "level": "medium"
}

PK> and this is a possible migration model if new extension identifier 
is introduced. As per 5.4.3.

Kind Regards,
Pawel

On 18.06.26 10:33, Mario Loffredo wrote:
> Hi Andy,
>
> sorry for the late reply.
>
> Please find my comments embedded below prefixed with [ML2].
>
> Il 10/06/2026 18:34, Andy Newton ha scritto:
>> Hi Mario,
>>
>> On 6/10/26 10:14 AM, Mario Loffredo wrote:
>>>> No clients do this today. But this confirms my earlier assertion 
>>>> that what is being attempted with the versioning draft is not 
>>>> backwards compatible with everything deployed today.
>>> [ML] I'm sorry, but I don't understand why you think the versioning 
>>> extension is backwards-incompatible.
>> Likewise, I don't understand why you and James are not comprehending 
>> the points that I and others have made in this thread. But 
>> miscommunication happens with complex topics. That is why I asked 
>> that the version draft include some query/response examples of how a 
>> client is suppose to handle backwards incompatibility.... both for a 
>> client that supports this versioning extension and one that does not. 
>> James seems more interested in discussing the conceptual definition 
>> of a breaking change, but since you are also one of the authors would 
>> it be possible for you to provide those examples to help clarify this 
>> discussion?
>
> [ML2] I think we can agree that a breaking change is challenging 
> whatever will be the versioning scheme, opaque, point or other.
>
> So every change should be made additive whenever possible.
>
> Hope to make myself clear with an example.
>
> Assume to have an extension called risk_ext like:
>
>   "risk_ext": {
>     "score": 72,
>     "level": "medium"
>   }
>
> risk_ext.score is an integer from 0 to 100.
>
> Not let's suppose to turn risk_ext.score into an object. This is 
> intentionally incompatible with the original version.
>
> A first point versioning approach to risk_ext v2 implmenetation 
> assuming that a non-versioning client parses the response extension 
> defensively could be:
>
>   "risk_ext": {
>     "score": {
>       "value": 0.72,
>       "scale": "0-1"
>     },
>     "level": "medium"
>
>   }
>
> but the cleanest non-breaking point versioning approach  would be 
> mostly a server-side compatibility policy like:
>
> "risk_ext": {
>   "score": 72,
>   "level": "medium",
>   "normalizedScore": {
>     "value": 0.72,
>     "scale": "0-1"
>   }
> }
>
> This would work regardless of whether clients supported the versioning 
> extension and seeems to me to be perfectly equivalent to opaque 
> versioning approaches such as:
>
> "risk_ext": {
>   "score": 72,
>   "level": "medium"
> },
> "risk_ext2": {
>   "score": {
>   "value": 0.72,
>   "scale": "0-1"
>   },
>   "level": "medium"
> }
>
> or
>
> "risk_ext_score": 72,
> "risk_ext_level": "medium",
> "risk_ext2_score": {
>   "value": 0.72,
>   "scale": "0-1"
> },
> "risk_ext2_level": "medium",
>
> On the other hand, point versioning would work much better than opaque 
> versioning in handling non-breaking changes (no data duplication, no 
> transition to manage) which are supposed to be the most frequent.
>
>
>>
>>>>> If a server implements the versioning specification, a client can 
>>>>> not only check which extensions, but also which versions of those 
>>>>> extensions are implemented by the server.
>>>> And what will the client do with that information? I have asked 
>>>> this question multiple times and have yet to get an answer.
>>> [ML] Clients may notice that a backwards-compatible change has 
>>> occurred, as explained in Section 5.4.5 of the rdap-extensions draft.
>>>
>>> They can also clearly determine the relationship between two 
>>> versions of an extension that differ by a backwards-incompatible 
>>> change, as explained in Section 5.4.
>> Nothing in Section 5.4.x says a client dynamically changes behavior 
>> upon receiving versioning information. When you say "They can also 
>> clearly determine the relationship between two versions of an 
>> extension", then what? What is client software suppose to do with 
>> that information?
>
> [ML2] The versioning_help member provides the full list of supported 
> extensions and their available versions, enabling self-configuring.
>
> The versioning_data member tells the client exactly which version of 
> each extension was used to produce the response, enabling conditional 
> parsing and fallback handling.
>
> During transitions between extension versions, clients can operate 
> with multiple versions in parallel, automatically detect when a server 
> has completed its migration, and plan their own upgrades without 
> service interruption.
>
>
> Hope I answered your questions.
>
>
> Best,
>
> Mario
>
>
>>
>> -andy
>>
>> _______________________________________________
>> regext mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>