Subject: [urn] text on URN relative resolution in Section 4.3

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 4 Sep 2016 15:44:00 -0600

During the interim meeting on 2016-06-29 (around the 25 minute mark of 
the recording), Julian raised a concern that the URNbis specification 
says that relative resolution is done by first resolving the URN and 
only then doing the relative resolution if possible. A discussion of 
around 15 minutes in length ensued. Specifically, Henry raised a concern 
about the text that was added between versions 11 and 12:

https://tools.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-12.txt

That text currently reads as follows:

###

4.3.  URNs and Relative References

    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
    algorithm cannot be applied directly to URNs because their syntax
    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.

    Given the foregoing, a relative reference SHOULD NOT be evaluated
    directly with respect to a URN.  Instead, a relative reference SHOULD
    be evaluated indirectly with respect to one of the following:

    1.  a base URI (other than a URN) declared by the resource itself; or

    2.  a base URI (other than a URN) obtained through the URN resolution
        process; or

    3.  the URL of the resource as obtained through the URN resolution
        process

    (Case 2 permits the resolution process to explicitly supply a base
    URI if the resource content is supplied directly by the resolution
    service rather than via an intermediate "location" URI.)

    If no such base URI exists, use of a relative reference with respect
    to a URN is an error.  Client behavior in this case is undefined.

    Resolution services SHOULD ensure that a base URI is supplied any
    time they provide resource content directly to a client.

###

John said that he thought he saw a way to fix it, but I'm not sure what 
that was, so I'll leave that aspect of the text fixes for -18 to him.

Peter