> -----Original Message----- > From: Tom Harrison <t...@apnic.net> > Sent: Thursday, May 19, 2022 8:44 PM > To: Gould, James <jgo...@verisign.com> > Cc: Hollenbeck, Scott <shollenb...@verisign.com>; regext@ietf.org > Subject: [EXTERNAL] Re: Re: Re: Re: [regext] Extension Prefixes, JSON > Values, and URI Path Segments
[SAH] snip > > Agreed, the uniqueness is the key requirement for the extension > > registrations. Here is a mix of the term identifier and prefix, which > > needs clarification. Earlier in RFC 7480 it refers to "Prefixes and > > identifiers", as opposed to simply one form. I see the need for both > > an identifier for signaling in the rdapConformance, which includes > > versioning, along with prefixes that are used path segments and > > response members. Is should be up to the specification to define the > > set of suffixes (null and non- null) that are used. > > Per earlier comments, I think the existing model (putting aside the change > in > 9083) supports this, save that null suffixes wouldn't be permitted. [SAH] Where exactly is this concept of "suffixes" coming from? Section 6 of RFC 7490 describes the prefix that can be registered with IANA. The production makes no mention of a suffix, and neither does the text. Section 8.1 of 7480 (the IANA Considerations section) references Section 6: "The production rule for these identifiers is specified in Section 6". Again, no mention of a suffix. Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
