On Fri, May 20, 2022 at 01:01:37PM +0000, Scott Hollenbeck wrote:
>> -----Original Message-----
>> From: Tom Harrison <[email protected]>
>> Sent: Thursday, May 19, 2022 8:44 PM
>> To: Gould, James <[email protected]>
>> Cc: Hollenbeck, Scott <[email protected]>; [email protected]
>> 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.
-Tom
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
