> -----Original Message----- > From: Tom Harrison <t...@apnic.net> > Sent: Sunday, May 22, 2022 12:19 AM > To: Hollenbeck, Scott <shollenb...@verisign.com> > Cc: Gould, James <jgo...@verisign.com>; regext@ietf.org > Subject: [EXTERNAL] Re: Re: Re: Re: [regext] Extension Prefixes, JSON > Values, and URI Path Segments > > Caution: This email originated from outside the organization. Do not click > links > or open attachments unless you recognize the sender and know the content > is safe. > > On Fri, May 20, 2022 at 01:01:37PM +0000, Scott Hollenbeck wrote: > >> -----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. > > For new fields, see section 2.1 of RFC 9083: > > Servers that insert such unspecified members into JSON responses > SHOULD have member names prefixed with a short identifier followed > by an underscore followed by a meaningful name. > > with later text in the section describing how to include custom lunarNIC > fields > in responses. > > For new path segments, see section 5 of RFC 9082: > > Custom path segments can be created by prefixing the segment with a > unique identifier followed by an underscore character (0x5F). For > example, a custom entity path segment could be created by prefixing > "entity" with "custom_", producing "custom_entity". > > But per the earlier comment from James, this text does not use normative > language, and the use of 'custom_entity' supports the argument that the > example is specifically about the case where the new name conflicts with an > existing name. So path segments without suffixes appear to be acceptable.
[SAH] I agree, but I don't think any of that has anything to do with a "suffix". The text describes a "meaningful name" and path segments. So, the names of any new data structures, path segments, etc. should be prefixed with the registered identifier - right? Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
