https://github.com/anewton1998/draft-regext-rdap-extensions/issues/54
>> Section 2.5, paragraph 0
>> 2.5. Identifier Omission
> What is a practical difference between this case and a registered bare
> identifier in 4.5?
[JS] Did you mean 2.4.5? Perhaps the section title can be better.
[TH] I think his concern here is that they appear to be overlapping, and that's
likely due to the second paragraph of 2.5 talking about the use of the
identifier as a prefix. Suggested updated 2.5:
Though all RDAP extensions are to be registered in the IANA RDAP
Extensions Registry, there is an implicit two-class system of
extensions that comes from the ownership of the RDAP
specifications by the IETF: extensions created by the IETF and
extensions not created by the IETF.
In the perspective of how extension identifiers are used as
namespace separators, extensions created by the IETF are not
required to use the extension identifier in requests and
responses, as the IETF can coordinate its own activities to avoid
name collisions. In practice, most extensions owned by the IETF
do use extension identifiers in their requests and responses,
either as a prefix or as a bare identifier.
RDAP extensions not defined by the IETF MUST use the extension
identifier as a prefix or as a bare identifier, in accordance with
this document, [RFC7480], [RFC9082], and [RFC9083]. RDAP
extensions defined by the IETF SHOULD use the extension identifier
as a prefix or as a bare extension identifier (see Section 2.4.5).
IETF-defined RDAP extensions that do not follow this guidance MUST
describe why it is not being followed.
>> Section 2.5, paragraph 1
>> [RFC9082], and [RFC9083]. RDAP extensions defined by the IETF SHOULD use
>> the extension identifier as a prefix or as a bare extension identifier (see
>> Section 2.4.5). IETF-defined RDAP extensions that do not follow this
>> guidance MUST describe why it is not being followed.
> I'm confused. The text in the beginning suggests it causes no harm if there
> is no prefix. Here it recommends to use the prefix adding a hurdle if someone
> would like to do it.
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
