[urn] Feedback on draft-ietf-urnbis-rfc2141bis-urn-16

[Julian Reschke <[e-mail]>]

Hi there,

below some notes on draft-ietf-urnbis-rfc2141bis-urn-16 (I didn't read 
all of the spec once I realized that it's the other spec that concerns 
me more :-)

(again, sorry for the format)

Best regards, Julian

-- snip --


    The basic syntax for a URN is defined using the Augmented Backus-Naur
    Form (ABNF) as specified in [RFC5234].  Rules not defined here
    (specifically: alphanum, fragment, and pchar) are defined as part of
    the URI syntax [RFC3986] and used here to point out the syntactic
    relationship with the terms used there.  The definitions of some of
    the terms used below are not complete; additional restrictions are
    imposed sections of the document that are specific to those terms.

Maybe "imposed in the sections"?

       rq-components =  ( "?="  q-component
                           [ "?+" r-component ] ) /
                        ( "?+" r-component
                           [ "?="  q-component ] )
       q-component   = pchar *( pchar / "/" / "?" )
       r-component   = pchar *( pchar / "/" / "?" )
       f-component   = fragment

These come as a surprise to anybody not already familiar to what led to 
the spec.

Either introduce them later, or insert some prose explaining where they 
come from.

Also, it would be good if there was a discussion about compatibility 
with existing use of queries, as these essentially reserve certain 
variants of queries for generic use.


    The NSS specified in this document allows characters not permitted by
    earlier specifications (see Appendix B.  In particular, the "/"
    character, which is now allowed, effectively makes it possible to
    encapsulate hierarchical identifiers from other naming systems.  For

s/(see Appendix B/(see Appendix B)/

    For the sake of consistency with RFC 3986, neither the general syntax
    nor the semantics of q-components are defined by, or dependent on,
    the namespace of the URN.  In parallel with RFC 3896, specifics of
    syntax and semantics, e.g., which keywords or terms are meaningful,
    of course may depend on a particular namespace or even a particular
    resource.

I agree that this is the right thing to do, but I'm not sure what this 
has to do with 3986.  3986 allows a scheme to mandate a specific syntax, no?

       urn:example:foo-bar-baz-qux?+CCResolve: cc=uk

Whitespace? Huh?

    For the sake of consistency with RFC 3986, neither the general syntax
    nor the semantics of f-components are defined by, or dependent on,
    the namespace of the URN.  In parallel with RFC 3896, specifics of
    syntax and semantics, e.g., which keywords or terms are meaningful,
    of course may depend on a particular namespace or even a particular
    resource.

s/3896/3986/

    Section 5.2 of [RFC3986] describes an algorithm for converting a URI
    reference that might be relative to a given base URI into "parsed
    components" of the target of that reference, which can then be
    recomposed per RFC 3986 Section 5.3 into a target URI.  This

s/RFC3986//

    algorithm cannot be applied directly to URNs because their syntax

Well, it can be applied (and will be by software developed according to 
RFC 3986). It's just that the result won't be helpful.

    does not support the necessary path components.  Whenever a URN
    resolves to a URL which may be used to access the resource, there is
    a more specific interpretation of q-component and f-component: the
    q-component is copied verbatim to the query portion of the URL (if
    that URL scheme supports query), and the f-component is copied
    verbatim to the fragment portion of the URL.  Even though the notion
    of a URN as a "persistent", "permanent" identifier does not reconcile
    easily with relative referencing, resources named with URNs may
    contain relative references that do not apply to the URN itself.

I find this very problematic. The URN spec of course can specify a 
URN-specific algorithm for resolution against a base URI. What it can't 
do easily is override what RFC 3986 without clearly saying so (updates: 
3986) and getting consensus for that.

Maybe it would make sense to step back and to consider what software is 
supposed to implement this algorithm. Browsers? If so, what are the 
plans of this WG to actually get them to do this?

I'm sure there are other use cases that are specific to URNs; do those 
really require overriding RFC 3986, or could they be addressed differently?