Re: [urn] [art] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice

[[e-mail] (Dale R. Worley)]

I am surprised to read a document that is marked "best current practice"
but filled with MUST and MUST NOT specifications.  I expect "best
current practice" to be advisory.  However, perhaps I am not
understanding the IETF use of BCP.  But this document does claim the
right to override any existing RFC, which seems to be excessive unless
the document receives very wide vetting and approval:

   There may be existing IETF specifications that already deviate from
   the guidance in this document.  In these cases, it is up to the
   relevant communities (i.e., those of the URI scheme as well as that
   which produced the specification in question) to determine an
   appropriate outcome; e.g., updating the scheme definition, or
   changing the specification.

As a nit, there is a reference to "BCP115":

   [BCP115]   Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
              Registration Procedures for New URI Schemes", BCP 115,
              RFC 4395, February 2006,
              <https://tools.ietf.org/html/bcp115>.

but my copy of bcp-index.txt says:

0115 [BCP number 115 is retired. It was mistakenly assigned to RFC
     4395. RFC 4395 is BCP 35.]

And I think the name/locator distinction is easy to overemphasize.  It
is often useful, but instead of trying to hammer all applications into a
single theoretical structure separating "names" and "locators", it's
less error-prone and more useful to examine each instance of the
distinction individually in the context within which it will operate, at
which point all sorts of knotty theoretical problems have obvious
solutions.

Getting down to the substance of this document, it seems to largely be
about how ownership of subsets of the universe of URIs is delegated.  We
intend the delegation to look something like:

    URIs->              (owned by the IETF)
        schema->        (owned by the IETF)
            namespace->       (e.g. owned by the URN experts)
                authority->   (owned by the domain registrant)
                    path prefixes->    (owned by the operator of the host)
                        resources      (owned by the application instance)

The problem arises when a single instance of an "application" demands a
particular structure for the URI subset delegated to it, but we expect
the instance's owner to be unwilling/unable to delegate a subset with
that structure, e.g., because the subset demands a particular path
prefix or a particular form of authority, or uses query parts in
specific ways that might not be supported by the instance owner's
preferred deployment method.

So it might be useful to express these rules more explicitly in terms of
delegeated URI subsets, and to say what sort of URI subsets an
application instance can reasonably demand to be delegated to it and
which it cannot.

Dale