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 >> 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.
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org