Tom,
The uniqueness aspect of the registry is fine, as is the 'null suffix'
part. I'm more concerned with the confusing way in which the various
documents interact in this respect and the fact that two different
'types' of values will be registered (advisedly) from now on.
I don't believe there will be any confusion since the purpose of the registry
is to ensure the uniqueness of the prefixes and identifiers used by the RDAP
extensions and the purpose of the referenced specification is to define their
usage. The set of suffixes are defined in the specification, which can include
a null suffix or a list of non-null suffixes. The proposal defined in the
mailing list message
(https://mailarchive.ietf.org/arch/msg/regext/GUNzKuVIFx7FHu3DuhS0Nn_zppk/) and
implemented in draft-ietf-regext-rdap-redacted-05 " fully follows the existing
RFC language, does not invalidate any existing registrations, supports the
registration of a versioned extension identifier, and the registration of
unique extension prefix identifiers for URI path segments, JSON response
members, and “objectClassName” member values.".
I do believe clarity is needed in the RFCs, since we're now seeing a variety of
RDAP extensions getting created.
Thanks,
--
JG
James Gould
Fellow Engineer
jgo...@verisign.com
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 5/17/22, 7:12 PM, "Tom Harrison" <t...@apnic.net> wrote:
Hi James,
On Tue, May 17, 2022 at 04:59:35PM +0000, Gould, James wrote:
> On 5/17/22, 8:56 AM, "Tom Harrison" <t...@apnic.net> wrote:
>> I think this approach could work in principle, but I don't think it's
>> in accordance with the current text:
>>
>> - RFC 7480 has "[t]he extension identifier is used as a prefix in
>> JSON names and as a prefix of path segments in RDAP URLs", but
>> under this new approach, that would no longer be the case for
>> values registered as RDAP conformance values (because they would
>> not be used as prefixes).
>
> A registered value is a prefix but with a null suffix. The only
> formal definition of the name in RFC 7480 is the ABNF name = ALPHA
> *( ALPHA / DIGIT / "_" ), which does not require the use of the
> underbar.
I'm not concerned (here) with the absence of a suffix or an underbar,
but with the RDAP conformance values, which are now used purely as
RDAP conformance values. -06 of the redacted draft has:
Extension identifier: redacted_level_0_3
Registry operator: Any
Published specification: This document.
Contact: IESG <i...@ietf.org>
Intended usage: This extension identifier is used for an
"rdapConformance" value when returning the "redacted" member in
the JSON response.
But "redacted_level_0_3" is not "used as a prefix in JSON names [or]
as a prefix of path segments in RDAP URLs", so its registration is not
in accordance with RFC 7480. (It's true that there are other cases
where the extension identifier is not used as a prefix in this way,
but in those cases the extension doesn't define any new fields/paths
anyway, whereas that's not the case here.)
>> - RFC 9082 has:
>>
>> 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 the new extension approach described above would permit a
>> different model to be used for fields in responses (null suffix),
>> which is unintuitive/inconsistent. (At least, it would be
>> surprising if this extra text in 9082 were intended to lead to a
>> different outcome for path segments when compared with the text in
>> 9083 about fields in responses.)
>> - More generally, having a single registry for both RDAP conformance
>> values and field/path prefixes seems like it could be confusing for
>> users, especially in the absence of clarifying text. (It's true
>> that there's a mix at the moment, but that appears to be an
>> oversight, rather than something done intentionally or something
>> that should be preserved in the future. There are also no existing
>> instances of an RDAP conformance value and a path prefix being
>> registered for a single extension.)
>
> This language from RFC 9082 is not normative and provides an example
> of defining a custom "entity" path segment, which would conflict
> with the existing "entity" path segment without the use of the
> prefix.
This is a good point, I don't have any concerns about this part
anymore.
> The registration of the prefix will ensure uniqueness of
> the use of the prefix across the extensions, where adding a non-null
> suffix can be used if and when there is a conflict.
>
>> I think this topic is sufficiently unclear that a new clarifying
>> document should be written (and preferably finalised) before any
>> document progresses that is not in accordance with a 'strict' reading
>> of the current text. (Such a reading (IMHO) has the RDAP conformance
>> value as the extension identifier in the IANA registry, with that
>> identifier used as-is as a prefix for new path segments and fields
>> defined by the extension.) That new document could e.g. set out the
>> approach you have described above, though possibly with a separate
>> registry for path segment and field prefixes to avoid any potential
>> confusion in that respect, and it could also amend relevant entries in
>> the existing registry so that they become valid.
>
> I agree, it looks like there is the need for a clarifying document
> to address this. There will be no conflict with other entries in
> the registry, since a unique versioned identifier is registered for
> the RDAP conformance, and a unique prefix is registered for use by
> the path segments and the fields. Use of a null suffix doesn't
> impact the uniqueness of the registration of the prefixes. The
> registrations include a reference to the specification that fully
> defines the use of the registered value. The registry addresses the
> uniqueness of the identifiers and prefixes, and the specification
> addresses the usage of the registered identifiers and prefixes with
> the inclusion of the set of suffix values.
The uniqueness aspect of the registry is fine, as is the 'null suffix'
part. I'm more concerned with the confusing way in which the various
documents interact in this respect and the fact that two different
'types' of values will be registered (advisedly) from now on.
-Tom
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
