inline... On Fri, Jan 3, 2025 at 4:46 PM Jasdip Singh <jasd...@arin.net> wrote: > > https://github.com/anewton1998/draft-regext-rdap-extensions/issues/44 > > > > >> Section 5, paragraph 9 > > >> Client authors should be aware that responses that make use of these > >> extensions may require special handling on the part of the client. Also, > >> while these extensions will be retained in the registry, future extensions > >> that are similarly non-compliant will not be registered. > > > > > How about registering missing identifiers fred_version_0, > > artRecord_level_0, platformNS_level_0 and regType_level_0? It could be done > > with this draft as IANA action. The registry seems to be fully additive, so > > no risk of this getting out of sync. > > > > [JS] That’s an interesting point but shouldn’t the original registrants of > these extensions take care of it? This draft is simply highlighting this > status quo. > > > > > Or can RFC mandate IANA to take this action with the original requesters > > off band? > > > > [JS] Not sure but we could discuss this further. > > > > [TH] I don't think we should do this. Registering the additional values > doesn't help to improve conformance with the existing RFCs, since the > identifiers still aren't used as prefixes in members etc., and it would > require additional documentation as to its exceptional nature
Agree with Tom. This is not a good idea. > > > > >> To avoid any confusion with the operation of the existing entries, an > >> extension registration that attempts to use one of the RDAP conformance > >> values given in this section as an extension identifier (and so as an RDAP > >> conformance value also) will be rejected. > > > > > This one looks like not normative, for sure not for IANA. This exclusion > > list should be then included in the IANA considerations which in fact would > > have the same effect as registering these names as mentioned above. I think putting these in the IANA considerations section is a good idea, but I disagree that it is the same as registering them as a registration must point to a stable reference of the extension. -andy _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org