Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

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

Scott,

My feedback is embedded below.

-- 
 
JG



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

On 7/18/22, 1:49 PM, "Hollenbeck, Scott" <shollenbeck=[e-mail]> wrote:



    > -----Original Message-----
    > From: Gould, James <jgould=[e-mail]>
    > Sent: Monday, July 18, 2022 1:06 PM
    > To: Hollenbeck, Scott <[e-mail]>; [e-mail];
    > [e-mail]
    > Cc: [e-mail]
    > Subject: [EXTERNAL] Re: RE: RE: Re: [regext] OK, What Next? (was RDAP
    > Extensions Approach Analysis v2)
    >
    > Caution: This email originated from outside the organization. Do not click 
    > links
    > or open attachments unless you recognize the sender and know the content
    > is safe.
    >
    > Scott,
    >
    > >    You can't give drafts, and the content they contain, implementation
    > status
    > >    that they don't have. I get the value of implementation experience, but
    > that
    > >    doesn't mean that we can add something to IETF processes that doesn't
    > exist.

    > I'm not stating that a draft has the implementation status, but by 
    > supporting
    > pointed versioning and minimal client / server impact to draft updates, it 
    > will
    > encourage implementations and contribute to the implementation status
    > section.  We found the pointed versioning to be very useful with the EPP
    > extensions, which should be reused for RDAP extensions.

    [SAH] You're putting content into a document that has no formal status with 
    the expectation that implementations will do something with version 
    information that changes over time. It might be useful, but you really 
    shouldn't be doing it.

JG - Do you mean the IANA registrations that are used for the elements of the extension, including the RDAP conformance?  We’ve done this for the EPP extensions (e.g., pointed versioned namespace URIs) for many years and it is needed for those that choose to implement to a draft version.  Encouraging support for implementing a draft is important to contribute to the Implementation Status section of the draft; otherwise, the draft is purely theoretical.  Versioning can change and the signaling of it is material.  The RDAP conformance values in RDAP should have had explicit support for versioning.  The "rdap_level_0" implied versioning, but there is no mention of versioning in the RFCs.  If versioning is included, the RDAP conformance is the natural place for it.  

    > > [SAH] As I mentioned in my response to Mario, part of the answer may
    > > lie in the server NOT removing support for older versions of an
    > > extension if it wishes to provide backward compatibility.
    >
    > Eventually the support for the old version can and will go away on the 
    > server-
    > side, where embedding the version into all the extension elements can
    > create interoperability issues without the prior knowledge of the server.
    > There is no version negotiation in RDAP, so once the old version support is
    > removed, a client implementation can be broken.  Using just the RDAP
    > conformance for hinting / signaling the support of the versioned
    > extension(s), can be adjusted by the server with little to no impact to the
    > clients.

    [SAH] "There is no version negotiation in RDAP"? It's not done the same way 
    it's done in EPP, but it certainly is possible. Look at Section 3.1.6 of RFC 
    9082:

    "The help path segment can be used to request helpful information (command 
    syntax, terms of service, privacy policy, rate-limiting policy, supported 
    authentication methods, supported extensions, technical support contact, etc.) 
    from an RDAP server."

    A client can submit a "help" query to an RDAP server to request information 
    before doing anything else. If the server publishes information describing 
    supported extensions, versions of supported extensions, etc., the client can 
    then choose which features it wishes to use based on the information received 
    in the "help" response, which contains an rdapConformance data structure along 
    with everything else the server returns. The server will know which versions 
    of extensions are being requested by the client based on the prefix the client 
    prepends to the extension elements sent in subsequent requests.

JG - The help does not support client version signaling and the help response doesn't use any formal information for client software discovery.  If the intent of the "help" query was to provide for formal client software discovery, it would require much more formality.  The "help" query could help the developer develop the extension in the client software, but not by software discovery.  Some extensions don't include path segment or query parameter extensions, such as the redacted extension (draft-ietf-regext-rdap-redacted), so there is no method of client extension version signaling.  If RDAP does need to provide client version signaling, then there would be the need for a new extension for that purpose.  

JG - I'm going to go back to Approach B, where there is a unique common prefix registered ("e.g., "foo") used by all extension elements and the extension's RDAP conformance values ("foo_level_0" or even pointed versions "foo_level_0_1").  You get the extension signaling and content consistency and the versioning is isolated to the RDAP conformance.  What is the issue with this approach?      

    Scott