On Mon, May 23, 2022 at 12:33:23PM +0000, Scott Hollenbeck wrote: >> -----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. > > I agree, but I don't think any of that has anything to do with a > "suffix".
My understanding of the term 'suffix' here (as first used by James in https://mailarchive.ietf.org/arch/msg/regext/LgFFahqbRfT-9Lwj_IzJUmLw02E/, I think) is that it refers to the text that comes after the prefix. Using the cidr0 extension as an example, 'cidr0' is the prefix (and the extension identifier), and the new field name 'cidr0_cidrs' comprises a prefix ('cidr0') and a suffix ('_cidrs'). > 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? Yes, I think the current text is such that new fields and structures (at least) should be prefixed with the registered extension identifier, and should all have a form similar to that used for the cidr0 extension ({prefix}_{meaningful name}), such that a field would not be permitted to have the prefix alone as its name. -Tom _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
