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

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

Tom,

Referencing the 'strict' model would indicate that the RFC language is clear, and we've gone through the language in the RFCs in detail in prior messages on the mailing list.  There is no language in the RFCs that would make approach A, B, or C non-compliant.  There is a mix of language in the RFCs that reference prefixes and identifiers and there is a mix of existing registrations in the RDAP Extension Registry.  Compliance is not driven by looking for patterns in past registrations but based on the language in the RFCs.  There is simply no clear language in the RFCs that addresses the recommended or required design for the prefix/suffix/version of RDAP elements (e.g., RDAP conformance, path elements, and response members) other than the ABNF in RFC 7480 (ALPHA *( ALPHA / DIGIT / "_" )), the naming of response members in RFC 9803 adhering to format defined in RFC 7480 (e.g., "lunicNIC" prefix with "lunarNIC_beforeOneSmallStep" response member), and the RDAP Conformance in RFC 7480 that is used as an identifier for the specification.  There is no linkage between the RDAP Conformance registration and the prefixes used for the path segments or response members in the RFCs to make "Approach A - tight coupling" the only compliant approach with the label of the 'strict' model.  It is best that we consider all the approaches presented along with any new approaches that are proposed on equal footing.  

Thank you for including the reference to the Patrick Mevzek's message from 2 1/2 years ago.  He summarized many of the issues that we're struggling with now.  In particular, what is the desired design for the RDAP extension prefix/suffix/version?  There is no clear definition of the prefix, the suffix, or how to handle versioning in the RFCs, which results in inconsistency and interoperability issues.  This issue became obvious with draft-ietf-regext-rdap-redacted, since the editors took an EPP extension best practice by incorporating the use of a pointed version number with draft updates to clearly signal clients the version supported by the server.  We started with Approach B and transitioned to Approach C.  

My recommendation is that we focus on the requirements for the prefixes / identifiers, suffixes, and versions.  We have a set of approaches that have been proposed, which is useful but may be getting ahead of defining what we're attempting to solve.  


-- 
 
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 5/31/22, 7:13 PM, "Tom Harrison" <[e-mail]> wrote:

    Hi James,

    On Tue, May 31, 2022 at 07:49:18PM +0000, Gould, James wrote:
    > I'm not exactly sure where the term 'strict' model is coming from,
    > which I assume is associated with Approach A "Tight Coupling".

    That's right.  See my earlier mail at
    https://secure-web.cisco.com/101f106DGqS2KuNui7F_Dicqj4REduCEHOjh2hctMk5VrWkB-QMZFYAPNzKdhGkxCQ7C2Rb7mvM4_R87kTaNHUZ7CAruEumv6cs_qo5Zy_MZuBVkOxs7OQb3mP8SvyVZS2jVlc5zm3hz4hy1vJEsCA04CGeBlkxSokCleMBU5FD8rVStEeic5c2ttn2N0VbyKONV2fAjd9CmqrdlO3jF1NImE4D94YeXaZh1DH4iIjUHd0YhhOiMKfO0nu2YQRLlf/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fregext%2F6Xg0ViGGlV19Ka-JGhEdFSFjsKM%2F%3A

        I think this topic is sufficiently unclear that a new clarifying
        document should be written (and preferably finalised) before any
        document progresses that is not in accordance with a 'strict'
        reading of the current text.  (Such a reading (IMHO) has the RDAP
        conformance value as the extension identifier in the IANA
        registry, with that identifier used as-is as a prefix for new path
        segments and fields defined by the extension.)

    > I believe the RFCs are sufficiently unclear to support all three
    > approaches discussed thus far (A, B, and C).

    While I think the RFCs are unclear, I don't think approach B or C is
    supported by the current text or practice.  As best I can tell, both
    of those approaches require the documents to be read as though the
    registry is for both prefixes and extension identifiers, as discrete
    things, even though:

     - in the seven years since these documents were finalised, no
       extension has been registered on that basis;
     - 7480 has "[t]he extension identifier is used as a prefix in JSON
       names and as a prefix of path segments in RDAP URLs"; and
     - when an extension that used a prefix as its identifier in the
       registry ('fred') was flagged on the list, the idea of prefix
       registration was disavowed
       (https://secure-web.cisco.com/1PlGqHFoVPEO6iTiAX_BLPsy_nZd6zc6fAOI3VenfHUJ9wUk2bcfGiZ-dEr3lmEVVLpPi0ixPyEk1PFdbxveI9cKZA1CyQlxnk1s_R9iHalhPzbJ1kZwkMhibv_Ijtw7jTtIR0GVCghbRWoSNUKm6Zj9zSe7v4vsxl65TL12W-yeRBzSz-Fn7WFh24yrSY4GJ03OLk4qWfvkG4GVZdneVhrPeEa6-K47EG-rbVy1dQqFVVYfcludFk7Y6MNGk62i3/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fregext%2FgX7r-RXx5Zy-IUlNjPPu4EPPWzo%2F),
       and 7483 was updated (by way of 9083) to give effect to that
       intent.

    An additional consideration is that the registered extensions that
    don't fall into the same category as 'fred' (i.e. the 'category 1'
    extensions from
    https://secure-web.cisco.com/1LptGQToj4xEIH5aIcMPUBceXlRi4edPfwx8WqG2s3MEi9XgkNvurvXi2jrQt_6OAWB85cyKI8xd0lvRSA_6C4oxhyCsbfoQRtH_ktScpAxO64j57pLZZnv7sGx5xEoH29tjX5dmDhNyKJLLnUBki-e6z160mvD02VmoA65vW04sfKdhC3LaCh6z-J86bHMfXQYwmrK-yrEJR6nySi_7mx5xQiNHbpZgz4vRYRsLIB64C3EoIjuHFWJMkhbpSqIjR/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fregext%2FhDGnDuzPFXcO8zXTUKW-8IjIS6w%2F)
    all follow approach A.

    -Tom