Hi Pawel, On Tue, Oct 21, 2025 at 09:57:01AM +0200, Pawel Kowalik wrote: > In fact I am not proposing anything, just trying to comprehend what > is now in the draft, namely what backward compatibility mentioned in > 5.3.1 means to identifiers that an extension ought to register. > > As versioning draft is an extension, not an update to the protocol, > the mechanisms have to work also without this extension. > > So far the approach of versioning an extension is to have new opaque > identifier which by RDAP current specification MUST appear in > the rdapConformance array. > > This is how foov1 and foov2 will get registered in IANA and > populated to rdapConformance. > > Then I was wondering how would it work for back compatibility. > > Approach 1: foov1 and foov2 add JSON names using only their > prefixes. They obviously never collide, data is just duplicated, but > is it back compatible? foov1-aware client won't be able to read > foov2-only output. So this is not back compatible. Of course one can > keep foov1 in the response, but then the whole back compatibility > topic is moot. foov2 would be just an unrelated extension. 5.3.1 and > 5.3.2 would be in fact the same in this case.
The text in the document could be clearer, but the idea is that foov2 is backwards-compatible in the sense that the data or functionality supported by foov1 is still valid. Whereas in 5.3.2, foov2 renders foov1 invalid in some way. For a somewhat contrived example, the NRO RDAP profile currently mandates trailing periods in domain names. If v2 of that profile instead mandated that trailing periods be omitted, then it wouldn't be backwards-compatible with v1. > Approach 2: foov1 and foov2 have a common prefix that remains stable > over the versions. It can be foo, bar or foov1. This would be back > compatible if foov2 response in this common prefix can be read by > foov1-only aware client. If this ought to be a valid and allowed > approach, than few other questions are to clarify: > - if foov1 can register a self-colliding prefix foo? > - if foov2 can populate JSON names registered by a different (but > related) extension foov1? I don't think this pattern is permissible with the current specifications, because an identifier is associated with at most one extension, and it's not open to an extension to use identifiers from other extensions for its own fields/paths. > I slowly tend to think that the real problem is the dual use of RDAP > Extensions IANA registry. From one side it needs to keep full > extension identifiers (to identify specifications) as they appear in > the rdapConformance array. On the other side it registers namespace > prefixes, which inherently collide with the extension identifiers. I think the way the registry works is fine, in that extension identifiers are 1:1 with namespace prefixes. Per James's comment, if there is a need for extension versioning in the way you have set out above, then draft-ietf-regext-rdap-versioning should be used. -Tom _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
