On Thu, May 19, 2022 at 8:44 PM Tom Harrison <t...@apnic.net> wrote: > > RFC 7483 was pretty clear about this: > > When custom JSON values are inserted into responses, conformance > to those custom specifications MUST use a string prefixed with the > appropriate identifier from the IANA RDAP Extensions registry > specified in [RFC7480] > > It's not like it's a complicated operation on the client side: the > client just has to find the extension identifier that is a prefix of > the conformance value.
I believe the intent was for an opaque identifier. If the identifier were to have versioning semantics, that would have been specified. So should the prefix and the conformance value match? Yes. Did we make that clear in the spec? Obviously not. > > >> Followed by an example registration: > >> > >> Extension identifier: lunarNic Registry operator: The Registry of > >> the Moon, LLC Published specification: > >> http://www.example/moon_apis/rdap Person & email address to > >> contact for further information: Professor Bernardo de la Paz > >> <berny@moon.example> Intended usage: COMMON > >> > >> lunarNic is not otherwise mentioned in RFC 7480. But RFC 7483 (not > >> 9083) has: > >> > >> When custom JSON values are inserted into responses, conformance > >> to those custom specifications MUST use a string prefixed with > >> the appropriate identifier from the IANA RDAP Extensions registry > >> specified in [RFC7480]. > >> > >> with an example conformance value of "lunarNic_level_0". It then > >> goes on to give example lunarNic fields like > >> "lunarNic_beforeOneSmallStep". For a user looking at this prior to > >> the publication of RFC 9083, it looks like: > >> > >> - the prefix is what is registered as the extension identifier; - > >> if a conformance value begins with the prefix, then the response > >> is in accordance with the corresponding extension; - such a > >> response may contain new fields that begin with the prefix; and - > >> the relevant server may support additional paths that begin with > >> the prefix, per the extension documentation. Thinking about this, I distinctly remember Alissa Cooper telling me this lunarNIC example was cute and all but to ditch it and make things clearer. I guess that didn't happen. -andy _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext