Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-reverse-search

[Mario Loffredo <[e-mail]>]

Hi Tom,

I really appreciated your effort in grouping the rdapConformance tags 
defined so far because I have always thought that there should be a 
document addressing the relationship between the rdapConformance tags  
and the proposed extensions.

Therefore, I encourage you to submit such document to the WG and I'll 
support its adoption.

My opinion is that the part of the rdapConformance tag about the version 
number (e.g. _0 or _level_0) should be left out from the possible rule 
tying the tag and the related extension for the following reasons:

1) A version number can be (normally is) a sequence of numbers separated 
by dots.  The rdap-redacted document presents a similar case (i.e. 
"redacted_0.1").

But a label including dots used as either the prefix or the exact match 
of an RDAP response extension couldn't be deserialized 
straightforwardly. Nothing particularly difficult to work around by 
using annotations or custom deserialization but why should we introduce 
such a complication?

2) Supposing that a subsequent version might change the structure of an 
existing response extension (maybe by adding some members), the backward 
compatibility should be guaranteed as much as possible.

It seems to me that including the version number as part of the name of 
a JSON field could cause breaking changes in the response structure.

3) Any subsequent version of an extension to requests and responses 
would cause both path segments and response fields to be renamed each 
time even if the update involved only one of them.


My conclusion is that, at least as regards response extensions, your 
rule could be arranged as in the following:


/- An rdapConformance tag contains the extension identifier and, 
optionally, the version number separated by "_" or "_level_" //
/

/- New fields (if present) must be prefixed with the extension identifier/


Finally, I'm very doubtful if it's worth having a similar rule about new 
paths but, at the same time, very curious to know others' opinions on 
this topic.

If there was consensus on applying your rule, the rdap-reverse-search 
document should be slightly changed, instead the rdap-openid document 
should be updated much more.


Best,

Mario


Il 28/04/2022 02:45, Tom Harrison ha scritto:
> 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

-- 
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: [phone]
Web:http://www.iit.cnr.it/mario.loffredo