Hi Mario,
On Tue, Apr 26, 2022 at 08:17:18AM +0200, Mario Loffredo wrote:
> Il 25/04/2022 00:55, Tom Harrison ha scritto:
>> The structure looks fine to me, but assuming that the
>> "reverse_search_properties" field name is prefixed with
>> "reverse_search" because of the "reverse_search_0" rdapConformance
>> value, then either the field name should be
>> "reverse_search_0_properties", or the rdapConformance value should
>> become "reverse_search", so that the field is prefixed with the entire
>> rdapConformance value.
>>
>> (Semi-related: on looking at the relevant rdapConformance content in,
>> 7480 has (section 8.1):
>>
>> The extension identifier is used as a prefix in JSON names and as
>> a prefix of path segments in RDAP URLs.
>
> [ML] According to the response extension example in RFC9083 (see
> "lunarNIC"), the prefix does not include the version info (in that case
> "_level_0").
>
> Therefore, it seems better to call the metadata field
> "reverse_search_properties".
>
> The same rule has been followed for the "redcated" extension.
I'm not sure this is the right way to go. The current set of
registered extensions can be grouped together like so:
- 1.
- rdapConformance is an exact match for the extension identifier
- 1.1
- New fields are prefixed with the extension identifier
- New paths are prefixed with the extension identifier
- arin_originas0
- 1.2
- New fields are prefixed with the extension identifier
- No new paths are defined
- cidr0
- paging
- sorting
- subsetting
- 1.3
- rdapConformance is an exact match for the extension identifier
- No new fields are defined
- No new paths are defined
- icann_rdap_response_profile_0
- icann_rdap_technical_implementation_guide_0
- nro_rdap_profile_0
- nro_rdap_profile_asn_flat_0
- nro_rdap_profile_asn_hierarchical_0
- rdap_objectTag
- redirect_with_content
- 2.
- rdapConformance is prefixed with the extension identifier
- 2.1
- New fields are prefixed with the extension identifier
- New paths are prefixed with the extension identifier
- fred
- 2.2
- New fields are prefixed with the extension identifier
- No new paths are defined
- artRecord
- platformNS
- regType
The extensions in category 2 are not registered correctly, inasmuch as
the rdapConformance value used for the extension must be an exact
match for the extension identifier in the registry, as opposed to
being prefixed with the extension identifier (see e.g.
https://www.rfc-editor.org/errata/eid6310). If the rdapConformance
value in each of those cases were updated to be the extension
identifier, then each extension in category 2 would fall into the
corresponding subcategory in category 1, and the rules followed by
every extension would then be:
- rdapConformance is an exact match for the extension identifier
- New fields (if present) are prefixed with the extension identifier
- New paths (if present) are prefixed with the extension identifier
which aligns (IMHO) with the previously-quoted text from RFC 7480, as
well as the following:
6. Extensibility
For extensibility purposes, this document defines an IANA
registry for prefixes used in JSON [RFC7159] data serialization
and URI path segments (see Section 8).
as well as guaranteeing that different extensions occupy different
namespaces, which has other positive effects (e.g. a client seeing an
unknown rdapConformance value could extract all fields/paths prefixed
with that rdapConformance value from the response, for further review
by a user).
It's true that the above reading does not accommodate the use of
lunarNIC in RFC 9083, where the rdapConformance value includes
_level_0 but the fields are prefixed with lunarNIC only. However, an
alternative set of rules which covered the use of lunarNIC in that
document would be:
- rdapConformance is an exact match for the extension identifier
- New fields are prefixed with an arbitrary string, defined in the
extension
- New paths are prefixed with an arbitrary string, defined in the
extension
which is considerably less useful for clients. Since the lunarNIC
case seems like the exception rather than the rule, I think it makes
sense to use the former reading, at least for extensions that are yet
to be finalised. (Assuming the lunarNIC text is incorrect, possibly
it can be addressed by an erratum, and even if the category 2
extensions can't be changed now, at least the set of extensions in
that category doesn't have to expand.)
-Tom
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
