James, Comments in-line...
On Mon, Jun 27, 2022 at 12:36 PM Gould, James <[email protected]> wrote: > > > The question is how we handle versioning, which is an aspect not covered in > the existing RFCs. The only version reference is in the RDAP Conformance > definition in section 4.1 of RFC 9083 with "rdap_level_0" and > "lunarNIC_level_0". If the use of "lunarNIC_level_0" was a mistake, then > versioning is completely absent for extensions. In my opinion, this is not accurate. The identifier is the version. If I understand your position correctly, you believe that the identifier should contain a separate, embedded, syntactically-parsable version identifier. And that is not an unreasonable position. However, what are the benefits of having it? And what are the complications of having it? If this sub-identifer were also an opaque identifier, then I don't see much benefit. If it were to have semantics, then what are those semantics? > > Approach A is a showstopper to me since it cascades versioning to all > elements with no perceived value and with the cost of interoperability issues > when the version number does change. What do you mean by "all elements" here? Can you provide an example? -andy _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
