Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments

["Gould, James" <[e-mail]>]

Approach A – “tight coupling” and Approach B “lack of tight coupling “ treats the RDAP Conformance value not as hint to the specifications used in the construction of the response, as defined in section 4.1 of RFC 9083, but instead as defining the prefix value of the extension elements (URI path segments, JSON response members, and objectClassName values).  My read of the RDAP Conformance is that version is material and there doesn’t need to be any direct link between the literal values in the RDAP Conformance with the prefixes used for the extension elements.  If the versioning of the RDAP Conformance needed to cascade down to the extension elements, why didn’t the base RDAP RFCs cascade the version “rdap_level_0” down to all the base RFC elements?  What would happen if a new version of RDAP was created, with the RDAP Conformance value of “rdap_level_1”, should all of the RFC elements embed the version “_1” version as well, as in “domain_1”, “domains_1”?  I believe the answer is “no”.  The example provided for the fictional registry of the Moon is “lunarNIC_level_0” and not simply the prefix “lunarNIC”.  We already have examples of pure RDAP Conformance literals that don’t relate to extension element prefixes with the RDAP profile identifiers, which certainly have value to the client.



My recommendation is to separate the RDAP Conformance values from the registration of the prefixes used for the extension elements, which can be registered separately for uniqueness.  We get full version signaling in the RDAP Conformance member and we get full support for a mix of extension elements that are registered for uniqueness.  I don’t see a compliance issue with the language in the RDAP RFCs with Approach C taken in draft-ietf-regext-rdap-redacted and I don’t see any technical issues that will impact the client by having a versioned RDAP Conformance registration (“redacted_level_0_3” with a future value of “redacted_level_1”) and a registration of the “redacted” member that is used in the JSON response.  Does anyone see any explicit compliance issues or technical issues with this?



Thanks,

--

JG

[cid:image001.png@01D86F8C.7BC9B1B0]

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: Mario Loffredo <[e-mail]>
Date: Tuesday, May 24, 2022 at 7:02 AM
To: James Gould <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "Hollenbeck, Scott" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments


Hi,

please find my thoughts below.
Il 23/05/2022 21:26, Gould, James ha scritto:

Tom,



In reviewing the thread below, I'll summarize my thoughts below that goes along with my response with Approach C to Jasdip:



1.       It looks like there is consensus that the existing language in the RDAP RFCs is unclear and there is a mix of cases that exist in the RDAP Extension Registry.  Creating something like the Guidelines for Extending the Extensible Provisioning Protocol (EPP), in RFC 3735, is needed for RDAP.

[ML] Absolutely. Have always supported that. Such guidelines should be written as soon as we reach a consensus on a first draft proposal since this discussion is blocking the progress of the WG documents about RDAP extensions.



2.       It looks like there is consensus that the RDAP Extension Registry ensures uniqueness of the identifiers and prefixes used by the extensions for the rdapConformance, URI path segments, and JSON response members.  I believe the values of the “objectClassName” needs to be included as well to support the definition of new RDAP objects.
[ML] Agreed. I'm a bit doubtful about including query parameters as proposed by Jasdip since it would break RFC8977 and RFC8982. This is another reason why I don't support Approach A.


3.

4.       It doesn’t look like there was an explicit attempt to define a namespace feature in RDAP, like what exists with XML namespace URIs and XML namespace prefixes.  The only version signaling is handled by the rdapConformance member of the JSON response.  Based on the practice that we followed with EPP extensions, we’ve been using pointed version numbers (“0.1”, “0.2”, “0.N”) for the namespace URIs up until the draft passed WGLC, resulting in bumping the version to “1.0”.  Supporting pointed version numbers has proven to be useful during the development of the EPP extensions, but since the ABNF in RFC 7480 doesn’t support the use of a ‘.’, the ‘_’ needs to be used instead for pointed version numbers.

[ML] IMO, ABNF in RFC7480 defines how extension identifiers rather than rdapConformance values should be written. Anyway, if we agree on Approach B or C, there is no need to drop pointed version numbers since the rdapConformance values would be decoupled from the prefix values. The only update needed (that wouldn't break the current RDAP responses and related documents) would be the removal of "_0" suffix from the registered extension identifiers related to RDAP profiles. On the other hand, versions could be clearly identified and extracted from rdapConformance values.

I recognize that the Approach C as is would accomplish backward compatibility but would maintain the current mix of cases in in the RDAP Extension Registry.

By the way, "cidr0" and "arin_originas0" would always appear a bit misleading unless Approach A was adopted.

I'm more in favor of strictly defining the rules for this stuff once and forever and correcting whereas it is necessary rather than opting for a solution that saves the past but gives way to ambiguities.



5.       For draft-ietf-regext-rdap-redacted, I view the registration of the extension identifier “redacted_level_0_3” (target of “redacted_level_1” after WGLC) that is returned in RDAP Conformance as meeting the signaling needs.  The registration of the prefix “redacted” ensures uniqueness of the member included in the JSON response.  This could be addressed with the single RDAP Extension Registry registration of “redacted”, where the specification formally defines the full version included in the rdapConformance member, but I feel inclusion of the separate full identifier registration as being more explicit for signaling.  What happens when there is version 2 of the redacted extension, should the RDAP Extension Registry only reference the latest specification for the “redacted” prefix used in the “rdapConformance”, or would it be better to include two versioned identifiers (“redacted_level_1” and “redacted_level_2”) that link to the associated specification in the RDAP Extension Registry?  I believe having both versions in the RDAP Extension Registry provides benefit to the client.  I recommend updating the registered prefixes for the extension with the latest specification.

[ML] In principle I don't like the idea that we should register an extension identifier for any version. We can use response links to provide the user with documentation related to each version. However, excluding Approach B, I prefer to support Approach C rather than Approach A.

That said, my response to James's last question is that it would be better to include both the version identifiers, at least for a period,  even when the new version  doesn't introduce any breaking change compared to the old one.

This would signal the client about any version transition especially when it involves the deprecation of a feature (e.g. a response field or a path). In such a case, the old and the new should temporarily coexist.



Best,

Mario

6.



Thanks,



--



JG







James Gould

Fellow Engineer

[e-mail]<mailto:[e-mail]> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]><mailto:applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com <http://verisigninc.com/><http://secure-web.cisco.com/1wRpZPJG3nhKGmiESd17M7CG7SNXSDxGws-Razme9DZn5hXjKsEX-oCSk4GrjQRKcPMZii_U7_hHVe-Xg020daTUK5ETVzjRwI0zECzWMKlGyn1uJwbenKTyWZ83IodY6LikHiaxO49IenNRyVqL8cmJ-o3HYVtFUWCTqMqTqk3VTEfKuOBl8YgeyW-TMdbbxNEewBA_5pNFmNfFxquFDi3kqnzTxBoAN71x1vsccaNe2dQNQE0zHksio7MexrMC_/http%3A%2F%2Fverisigninc.com%2F>



On 5/19/22, 8:44 PM, "Tom Harrison" <[e-mail]><mailto:[e-mail]> wrote:



    Hi James,



    On Thu, May 19, 2022 at 06:36:59PM +0000, Gould, James wrote:

    > On 5/19/22, 2:35 AM, "Tom Harrison" <[e-mail]><mailto:[e-mail]> wrote:

    >> On Wed, May 18, 2022 at 11:59:05AM +0000, Gould, James wrote:

    >>> On Wed, May 18, 2022 at 09:12:16AM +1000, Tom Harrison wrote:

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

    >>

    >> Having reviewed the relevant text again, I think I know what

    >> happened here (which is relevant to what to do next).  RFC 7480

    >> has:

    >>

    >>   For extensibility purposes, this document defines an IANA

    >>   registry for prefixes used in JSON [RFC7159] data serialization

    >>   and URI path segments (see Section 8).

    >

    > What's interesting is the first normative sentence of the next

    > paragraph states "Prefixes and identifiers SHOULD only consist

    > of...", where an identifier is not formally defined but there is

    > clearly inclusion of both a prefix and an identifier.



    But this doesn't of itself mean that the value of the 'prefix' is

    distinct from that of the 'identifier'.  If the original intent were

    that both prefixes and identifiers be registered, then one or more of

    artRecord, fred, platformNS and regType might have been registered in

    that way, but they weren't.  Whereas all current extensions can be

    characterised as 'prefix' registrations, with some using the prefix

    value as-is as the conformance value, and some adding version

    information to that prefix for the purposes of the conformance value.



    > We have a mix of prefixes and identifiers that exist in the RDAP

    > Extension Registry (e.g., icann_rdap_response_profile_0 as an

    > identifier, rdap_objectTag as a prefix for an identifier in the

    > rdapConformance, paging that is used as a prefix and as an

    > identifier in the rdapConformance).



    I can see the distinction you are drawing here, but I think a better

    way of framing it is simply that some extensions define additional

    fields/paths, and in all of those cases those fields/paths are

    prefixed with the extension identifier.  Or in other words, the fact

    that there are extensions where the prefix is the same as the value

    used in rdapConformance does not of itself mean the registry is (or

    was intended as) a dual prefix/identifier registry.



    > It's unclear whether the registrations are intended to define a

    > namespace or the values that are needed for uniqueness in the URI

    > path segments and JSON response members.



    Putting aside the change in 9083 in how the conformance value was

    treated, it seems to me that there is plenty of text indicating that

    namespacing was intended.  Apart from all the mentions of 'prefixes',

    and the way in which 'lunarNIC' is used in the documents, there is the

    following from section 2.1 of 9083 that I don't think has been

    mentioned before:



        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.



    > I believe attempting to model a namespace in the RDAP Extension

    > Registry for use across all elements defined in the extension is

    > unneeded for REST, but that we only need to ensure that there is

    > uniqueness across the extensions.  There is nothing that restricts

    > an extension for registering more than one entry in the RDAP

    > Extension Registry to ensure uniqueness.  I believe a versioned

    > identifier for an extension has value for client signaling in the

    > rdapConformance and to decouple the potential set of unique prefixes

    > used for the URI path segments and JSON response members defined by

    > the extension.



    The existing model per my reading (again, putting aside the change in

    9083) supports this for the most part, though.  For a document like

    redacted:



     - there would be a single entry in the IANA registry with the

       extension identifier 'redacted';

     - versioned identifiers could be used as rdapConformance values, so

       long as they were prefixed with 'redacted' (the associated

       specification document link could be updated as new versions were

       released); and

     - 'redacted' would be used as a prefix throughout the responses

       making use of those conformance values.



    (Given the text from section 2.1 of 9083 above, I don't think it's

    open to use 'redacted' with a 'null suffix', though: I hadn't noticed

    that text before responding to your earlier mail on this point,

    sorry.)



    As far as registering multiple prefixes in the same document goes, I

    don't see any problem with that, so long as the response includes

    conformance values that either match or are prefixed with each of the

    relevant extension identifiers (prefixes).



    >> Later in that document:

    >>

    >>   The purpose of this registry is to ensure uniqueness of extension

    >>   identifiers.  The extension identifier is used as a prefix in

    >>   JSON names and as a prefix of path segments in RDAP URLs.

    >

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



    > Clients will not auto discover the prefixes to based on the value in

    > the rdapConformance to match up the accepted set of path segments

    > and the set of response members included in the response.  If that

    > was the intent, there would be a much more formal definition

    > requirement in the protocol to support auto-discovery.



    RFC 7483 was pretty clear about this:



        When custom JSON values are inserted into responses, conformance

        to those custom specifications MUST use a string prefixed with the

        appropriate identifier from the IANA RDAP Extensions registry

        specified in [RFC7480]



    It's not like it's a complicated operation on the client side: the

    client just has to find the extension identifier that is a prefix of

    the conformance value.



    >> Followed by an example registration:

    >>

    >>   Extension identifier: lunarNic Registry operator: The Registry of

    >>   the Moon, LLC Published specification:

    >>   http://www.example/moon_apis/rdap Person & email address to

    >>   contact for further information: Professor Bernardo de la Paz

    >>   <[e-mail]><mailto:[e-mail]> Intended usage: COMMON

    >>

    >> lunarNic is not otherwise mentioned in RFC 7480.  But RFC 7483 (not

    >> 9083) has:

    >>

    >>   When custom JSON values are inserted into responses, conformance

    >>   to those custom specifications MUST use a string prefixed with

    >>   the appropriate identifier from the IANA RDAP Extensions registry

    >>   specified in [RFC7480].

    >>

    >> with an example conformance value of "lunarNic_level_0".  It then

    >> goes on to give example lunarNic fields like

    >> "lunarNic_beforeOneSmallStep".  For a user looking at this prior to

    >> the publication of RFC 9083, it looks like:

    >>

    >>   - the prefix is what is registered as the extension identifier; -

    >>   if a conformance value begins with the prefix, then the response

    >>   is in accordance with the corresponding extension; - such a

    >>   response may contain new fields that begin with the prefix; and -

    >>   the relevant server may support additional paths that begin with

    >>   the prefix, per the extension documentation.

    >

    > What you're defining is equivalent to a namespace, which sounds

    > reasonable but doesn't provide value to clients.  Does it really

    > matter to a client that an extension has an extension identifier of

    > "foo" that chooses to define the URI path segment "foo_bar" in the

    > specification and a set of response members of the form

    > "foo_member_1", "foo_member_2", and "foo_member_N" in the

    > specification?  I see it being more valuable to have a versioned

    > identifier for the extension, such as "foo_level_0" or "foo_level_1"

    > for use in the rdapConformance, along with a set of unique URI path

    > segments and response member prefixes in the registry (e.g., "bar",

    > "member").



    I can see the argument for changing how extensions work in RDAP.  My

   concern here is simply that I don't think the current text supports

    this approach.  Having a document progress that is not in accordance

    with the current text, and establishes (at a minimum) a novel approach

    to the use of the registry, seems like something that will further

    confuse potential clients of the system.  Additionally, the approach

    I've proposed requires very little change to the redacted document (or

    to any other pending extension document), and submitting an erratum

    shouldn't take much time either.



    >> If the change in 9083 is considered to be a mistake, and registering

    >> prefixes is considered acceptable, then possibly the simplest option

    >> is to:

    >>

    >>   - submit an erratum against 9083;

    >>   - continue registering extensions, but register only the prefixes;

    >>     and

    >>   - write a document clarifying all of this, as well as noting

    >>     conventions around versioning and so on, to avoid some of the

    >>     problems Patrick raised around namespacing and similar.

    >>

    >> This has some added benefits:

    >>

    >>   - only one registry is needed; and

    >>   - the entries in the existing registry are all fine and do not need

    >>     to be changed (so long as conformance values are permitted to be

    >>     exact matches for extension identifiers, which doesn't seem to be

    >>     problematic).

   >>

    >> It does mean that a given extension is restricted to a single

    >> field/path prefix, but I'm not sure that that's a serious problem, or

    >> at least I don't think there are any documents pending that are using

    >> multiple prefixes.

    >

    > The proposal that I'm making doesn't require touching any of the

    > existing registry entries, which has a mix of identifiers and

    > prefixes.  There is no restriction for a given extension to have a

    > single field/path prefix.



    On this point, I think you are right that a document can define

    multiple field/path prefixes, so long as it includes multiple

    conformance values that map to those prefixes and registers both

    prefixes in the registry.



    -Tom





_______________________________________________

regext mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1J4tK1w6Ho1iyYkKbCr-r2vJ4CFzo0PC0aFtwGwQBkIYunKAXPGpr6yT6pR2SCOpc6TpfSmlNPKoSHSJCer6ToHhDVS1PYqF3N5W5Jr_URlsOFjU6fgVL3YU817bECz2sU1wCPJFWOqg5ayTWe__AWgyK6qypZEpPFFUWV1C0L9maB2HgsHEkcgkvJm6Ocx2T_1GyqQuN6HlBbLW20pm7Ide0S6gTN1UDcQJ0ugzibJ8aB68xi8edTK9ZFbLR5jiM/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>

--

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<http://secure-web.cisco.com/1mrcmAm1tnmS1LGNnNS5meGxCBeJ-n1c3Y6Ny27UFQ4UBClH0Zj44mmdcCxXRAF4qOqH6EVrCHXxRBfiE2oyAIuhe0hCeL4Uko8F1z4OGzAfSn6nCuyfsxM5ZAlihRK_PRGIBqNCv753SgNjDNIiUZbP4mECaTlSGwkuIUXswFi99IRmrn0-IMZbD9eU-76CU3MQjZH4Ieh1nnIp02ETBN2PJvdihBajsSKU-HclRnnNSEH501uUpvyziDkAU8rLE/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>