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

[Tom Harrison <[e-mail]>]

Hi Mario,

On Thu, Apr 28, 2022 at 10:56:35AM +0200, Mario Loffredo wrote:
> 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:

I'm not sure this point is open.  To clarify, there is the following
in RFC 9082 (section 4.1):

    When custom JSON values are inserted into responses, conformance
    to those custom specifications MUST be indicated by including a
    unique string literal value registered in the IANA RDAP Extensions
    registry specified in [RFC7480].  For example, if the fictional
    Registry of the Moon wants to signify that their JSON responses
    are conformant with their registered extensions, the string used
    might be "lunarNIC_level_0".

plus Scott's input on this topic when this last came up
(https://mailarchive.ietf.org/arch/msg/regext/kWZ9ix80uaUAHqXjJsf_L2IN-Ys/):

    I'm also going to change the text in 4.1 a bit to be clear that
    these string literals are the values that should be registered
    with IANA and returned in RDAP responses. There won't be any
    confusing mention of prefixes.

plus an earlier mail from Scott on this topic
(https://mailarchive.ietf.org/arch/msg/regext/gX7r-RXx5Zy-IUlNjPPu4EPPWzo/):

    Patrick, my expectation is that the value registered with IANA is
    the exact value that should appear in an rdapConformance section.
    The purpose of these values is to clearly identify an associated
    specification, so one should be able to extract an identifier from
    an RDAP response, look it up in the IANA registry, find an exact
    match, and unambiguously identify the associated specification.
    We clearly need to clean up this part of 7483 if/when we do
    7483bis.

in addition to the RFC 8521 erratum reference from my previous mail.
I think the only open point here is about the requirements (if any)
with respect to the naming of new fields/paths in an extension.  See
inline for some comments on your other points, though.

> 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").

The redacted document is the only one that I know of that includes
dots in the rdapConformance value.

> 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.

If extra members need to be added, that could be done by way of an
additional extension on top of the previous extension.  Clients who
understand only the first extension would simply ignore the additional
fields.

> 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.

Similarly to the previous point, additional fields can be added by way
of a new extension.  All other changes are likely to affect the
semantics of the existing extension in such a way that using new
field/path names is probably sensible, plus the server can support
both version 1 and version 2 alongside each other in that case if need
be.

-Tom