Subject: [urn] suggested text changes for -12 on p-components, f- and q-components in URN resolution, and relative references

From: Keith Moore <[email-masked]>
Date: Thu, 23 Apr 2015 02:02:54 -0400

Here are my suggestions for changes to draft-ietf-urnbis-rfc2141bis-11 
based on last Friday's conference call.

I will try to also suggest text for r-components in a separate message, 
hopefully sometime tomorrow.  If I don't get it out by tomorrow it will 
be early next week.

I. p-components

If we have consensus that (a) relative references in resources named by 
URNs are always evaluated with respect to a base URI that is not a URN, 
and (b) there's no special need for URNs to be able to contain "paths", 
then we have several choices:

(a) Disallow p-components in the 2141bis grammar, OR
(b) Allow p-components in the 2141bis grammar, but reserve them for 
future use.   basically this means that parsers would recognize 
p-components, and p-components would be transmitted to resolution 
services, but namespaces shouldn't assign names containing p-components 
until a standards-track document explains how to do so, OR
(c) Permit "/" in NSS arbitrarily without giving any special 
significance to them.

Any of these seem workable but I lean toward either (a) or (c) - maybe a 
bit more toward (c) because I suspect there are namespaces that assign 
names containing "/" which could more easily be URN namespaces if "/" 
did not need to be %-encoded.

(I don't think that (c) breaks RFC 3986 compatibility because that 
"path" component of a URN (according to the 3986 grammar) never begins 
with "/" because a namespace never begins with a "/".   The 
namespace:NSS portion of a URN always matches "path-rootless", and 
"path-rootless" can containing an arbitrary number of "/"s in a row 
because "segment" is defined to be zero or more "pchar"s.   See RFC 3986 
mostly section 3.3)

Since there are three choices, I'm supplying three sets of changes, 
color-coded to hopefully minimize confusion as one scrolls back and 
forth through the message.   Pick only one :)   Note that in all cases 
the new text is shorter than the old; I take that as a favorable sign.

Option (a): Disallow p-components in the 2141bis grammar

Section 3

OLD:

       namestring    = assigned-name
                       [ q-component ]
                       [ f-component ]
       assigned-name = "urn" ":" NID ":" NSS [ p-component ]
       NID           = (alphanum) 0*30(ldh) (alphanum)
       ldh           = alphanum / "-"
       NSS           = 1*(pchar)
       p-component   = "/" path-absolute
       q-component   = "?" query
       f-component   = "#" fragment

    Note that "/" can be used without percent-encoding inside
    p-components and that "?" can be used without percent-encoding inside
    q-components and f-components.

NEW:

       namestring    = assigned-name
                       [ q-component ]
                       [ f-component ]
       assigned-name = "urn" ":" NID ":" NSS
       NID           = (alphanum) 0*30(ldh) (alphanum)
       ldh           = alphanum / "-"
       NSS           = 1*(pchar)
       q-component   = "?" query
       f-component   = "#" fragment

    Note that "?" can be used without percent-encoding inside
    q-components and f-components.

Section 3.3

OLD

3.3.  p-component, q-component, and f-component

    The p-component, q-component, and f-component are optional components
    that follow the assigned-name.  In terms of URI syntax these
    components are essentially equivalent to the URI "path-absolute",
    "query", and "fragment" constructions, respectively. However, the
    URN p-component, q-component, and f-component need not be
    semantically equivalent to the URI path component, query component,
    and fragment component; therefore they are called by different names
    in this specification.

    Unless specifically defined for a particular namespace after
    publication of this document, use of these components is disallowed,
    thereby maintaining strict backward compatibility with namespaces
    defined in accordance with [RFC2141] and registered in accordance
    with [RFC3406].

    This specification does not define the semantics of the p-component,
    q-component, and f-component for URNs in general. Instead,
    additional specifications might establish these matters for URN-
    related services (such as URN resolution) or for individual URN
    namespaces (e.g., to handle extended information about the resource
    identified by a URN).  For example, it is possible that the
    q-component might be used in requests to URN resolution services, or
    that the f-component might be used to distinguish the integral parts
    of resources named by URNs in particular namespaces (say, the
    chapters of a book).  However, defining such usage is the
    responsibility of specifications for URN resolution services,
    namespace registration requests and specifications for individual
    namespaces, and other appropriate documentation (such as policy
    documents governing the management of a given URN namespace).

    As general guidance that might not apply to all cases, it would be
    inappropriate for namespaces that do not intend to support resolution
    services to allow q-components.  Namespaces that deal with digital
    manifestations might be able to support f-components. At the time of
    writing, no general guidance can be provided for use of p-components.

NEW

3.3.  q-component and f-component

    The q-component and f-component are optional componentsthat follow
    the assigned-name.  In terms of URI syntax thesecomponents are
    essentially equivalent to the URI"query", and "fragment"
    constructions, respectively.  However, thesemantics of the URN
    q-component and f-component are subtly different than the semantics
    of the generic URI equivalents, therefore they are called by
    different namesin this specification.

    Note: URN syntax provides no equivalent to the "path" component of
    a generic URI.

    See section [TBD.A] for a description on how the URN q-component
    and f-component affect resolution of a URN, and section [TBD.B] for
    how relative references are evaluated with respect to a URN.

Section 3.3.1 (delete)

Section 4.1

OLD:

    If a p-component is included in a URN, it MUST be identical
    (including case sensitivity) in the strings being compared.

NEW: (delete this paragraph)

Section 4.2

(delete examples using "/" in NSS, whether or not percent-encoded)

Section 7.3.2

OLD:

    3.  If p-components, q-components, and/or f-components are allowed
        for the namespace, a discussion of how they are used.

NEW: (delete this paragraph. use or handling of f-components and 
q-components should not be namespace-specific)

Option (b):  Allow p-components in the 2141bis grammar, but reserve them 
for future use.

OLD:

3.3.  p-component, q-component, and f-component

    The p-component, q-component, and f-component are optional components
    that follow the assigned-name.  In terms of URI syntax these
    components are essentially equivalent to the URI "path-absolute",
    "query", and "fragment" constructions, respectively. However, the
    URN p-component, q-component, and f-component need not be
    semantically equivalent to the URI path component, query component,
    and fragment component; therefore they are called by different names
    in this specification.

    Unless specifically defined for a particular namespace after
    publication of this document, use of these components is disallowed,
    thereby maintaining strict backward compatibility with namespaces
    defined in accordance with [RFC2141] and registered in accordance
    with [RFC3406].

    This specification does not define the semantics of the p-component,
    q-component, and f-component for URNs in general. Instead,
    additional specifications might establish these matters for URN-
    related services (such as URN resolution) or for individual URN
    namespaces (e.g., to handle extended information about the resource
    identified by a URN).  For example, it is possible that the
    q-component might be used in requests to URN resolution services, or
    that the f-component might be used to distinguish the integral parts
    of resources named by URNs in particular namespaces (say, the
    chapters of a book).  However, defining such usage is the
    responsibility of specifications for URN resolution services,
    namespace registration requests and specifications for individual
    namespaces, and other appropriate documentation (such as policy
    documents governing the management of a given URN namespace).

    As general guidance that might not apply to all cases, it would be
    inappropriate for namespaces that do not intend to support resolution
    services to allow q-components.  Namespaces that deal with digital
    manifestations might be able to support f-components. At the time of
    writing, no general guidance can be provided for use of p-components.

NEW:

3.3.  p-component, q-component, and f-component

    The p-component, q-component, and f-component are optional components
    that follow the assigned-name.  In terms of URI syntax these
    components are essentially equivalent to the URI "path-absolute",
    "query", and "fragment" constructions, respectively. However, the
    URN p-component, q-component, and f-component are not
    semantically equivalent to the URI path component, query component,
    and fragment component; therefore they are called by different names
    in this specification.

See section [TBD.A] for a description on how the URN q-component
    and f-component affect resolution of a URN, and section [TBD.B] for
    how relative references are evaluated with respect to a URN.

    p-components are reserved for future use.  Implementations which
    recognize URNs MUST parse URNs according to the grammar described in
    this document, and MUST include the entire assigned portion of a URN
    (including any p-component) to a resolution service. However,
    namespaces MUST NOT assign URNs containing p-components. This
    restriction on use of p-components may be relaxed in a later 
specification.

section 3.3.1:

OLD

3.3.1.  p-component

    The only formal restriction placed upon a p-component by this
    specification is that the syntax SHALL adhere to the "path-absolute"
    rule from [RFC3986].  The specification for a particular namespace or
    URN-related service MAY define further syntax restrictions within the
    p-component.  (For example, a namespace specification might define a
    character such as "~" or "@" as a delimiter inside p-components
    assigned within that namespace.)  Note that characters outside the
    ASCII range [RFC20] MUST be percent-encoded using the method defined
    in Section 2.1 of the generic URI specification [RFC3986].

    Consider the hypothetical example of a hierarchical naming system in
    which the identifiers take the form of a series of numbers separated
    by the "/" character, such as "1/406/47452/2".  If the naming
    authority for such identifiers were to use URNs, it would be natural
    to place the existing identifiers in the p-component, resulting in
    URNs such as "urn:example/1/406/47452/2" (using the "example" URN
    namespace [RFC6963] instead of a registered NID).

    As described under Section 4, the p-component SHALL be taken into
    account when determining URN equivalence.

NEW

[[Note:  Maybe I misunderstand, but I think the -11 text is incorrect in 
syntax even if we don't change the semantics of p-components at all.   
As I read 3986, the URI "path" corresponds to the URN namespace:NSS, so 
the "path" never begins with "/" and can never correspond to 
"path-absolute".   (Yes, we can reuse that production from the 3986 
grammar if we want to do so, but I see no reason to do so.)   And the 
example given in the next paragraph is also incorrect, because there 
would need to be a ":" after the namespace "example".]]

3.3.1.  p-component

    p-component is reserved for future use.  Namespaces MUST NOT assign
    URNs with p-components.  A future specification may permit
    p-components while possibly imposing other constraints on their use.

    However, software that recognizes URNs MUST parse URNs (including
    p-components) according to the grammar in this document, and MUST
    present the entire "assigned-name" portion of a URN to a resolution
    service when resolving the URN.

    As described under Section 4, the p-component SHALL be taken into
    account when determining URN equivalence.

Section 7.3.2:

OLD

    3.  If p-components, q-components, and/or f-components are allowed
        for the namespace, a discussion of how they are used.

NEW:  (delete this.  use or interpretation of f- and q-components should 
not be namespace-specific)

Option (c): Permit "/" in NSS arbitrarily without giving any special 
significance to them.

Section 3:

OLD

       namestring    = assigned-name
                       [ q-component ]
                       [ f-component ]
       assigned-name = "urn" ":" NID ":" NSS [ p-component ]
       NID           = (alphanum) 0*30(ldh) (alphanum)
       ldh           = alphanum / "-"
       NSS           = 1*(pchar)
       p-component   = "/" path-absolute
       q-component   = "?" query
       f-component   = "#" fragment

    Note that "/" can be used without percent-encoding inside
    p-components and that "?" can be used without percent-encoding inside
    q-components and f-components.

NEW

       namestring    = assigned-name
                       [ q-component ]
                       [ f-component ]
       assigned-name = "urn" ":" NID ":" NSS
       NID           = (alphanum) 0*30(ldh) (alphanum)
       ldh           = alphanum / "-"
       NSS           = 1*(pchar / "/")
       q-component   = "?" query
       f-component   = "#" fragment

    Note that "?" can be used without percent-encoding inside
    q-components and f-components.

Section 3.3

OLD

3.3.  p-component, q-component, and f-component

    The p-component, q-component, and f-component are optional components
    that follow the assigned-name.  In terms of URI syntax these
    components are essentially equivalent to the URI "path-absolute",
    "query", and "fragment" constructions, respectively. However, the
    URN p-component, q-component, and f-component need not be
    semantically equivalent to the URI path component, query component,
    and fragment component; therefore they are called by different names
    in this specification.

    Unless specifically defined for a particular namespace after
    publication of this document, use of these components is disallowed,
    thereby maintaining strict backward compatibility with namespaces
    defined in accordance with [RFC2141] and registered in accordance
    with [RFC3406].

    This specification does not define the semantics of the p-component,
    q-component, and f-component for URNs in general. Instead,
    additional specifications might establish these matters for URN-
    related services (such as URN resolution) or for individual URN
    namespaces (e.g., to handle extended information about the resource
    identified by a URN).  For example, it is possible that the
    q-component might be used in requests to URN resolution services, or
    that the f-component might be used to distinguish the integral parts
    of resources named by URNs in particular namespaces (say, the
    chapters of a book).  However, defining such usage is the
    responsibility of specifications for URN resolution services,
    namespace registration requests and specifications for individual
    namespaces, and other appropriate documentation (such as policy
    documents governing the management of a given URN namespace).

    As general guidance that might not apply to all cases, it would be
    inappropriate for namespaces that do not intend to support resolution
    services to allow q-components.  Namespaces that deal with digital
    manifestations might be able to support f-components. At the time of
    writing, no general guidance can be provided for use of p-components.

NEW

3.3.  q-component and f-component

    The q-component and f-component are optional components
    that follow the assigned-name.  In terms of URI syntax these
    components are essentially equivalent to the URI
    "query", and "fragment" constructions, respectively. However, the
    URN  q-component, and f-component are not quite
    semantically equivalent to the URI query component
    and fragment component; therefore they are called by different names
    in this specification.

See section [TBD.A] for a description on how the URN q-component
    and f-component affect resolution of a URN, and section [TBD.B] for
    how relative references are evaluated with respect to a URN.

Section 3.3.1 (delete this section)

Section 4.1

OLD

    If a p-component is included in a URN, it MUST be identical
    (including case sensitivity) in the strings being compared.

NEW (delete this paragraph)

Section 4.2

(delete examples containing p-components and text referring to p-components)

Section 7.3.2

OLD

    3.  If p-components, q-components, and/or f-components are allowed
        for the namespace, a discussion of how they are used.

NEW (delete this item; f- and q-components should not be namespace-specific)

II. URN resolution

Notes:

1. My first cut at this said that a client MUST NOT include a 
q-component or f-component in a URN sent in a request to a resolution 
service.  Then I realized that a resolution service might in some 
circumstances provide access to resource content (say by caching it), or 
act as a proxy to a resource, in which circumstances interpreting the 
q-component might be appropriate.   So now the client MUST NOT include 
q-component or f-component unless it's requesting that the resolution 
service provide access to the resource itself, and the resolution 
service is supposed to ignore the q-component except when it needs to 
send it as a query to the resource, and to ignore the f-component.   But 
this bothers me somewhat, and I'd like for the rules to be simpler while 
still maintaining a layer separation between the resolution service and 
the resources which it names.   The simplest solution is probably to say 
that resolution services never provide access to resource content, only 
to locations and metadata.  However, it's long been expected that 
resolution services could provide access to resource content.

2. Lars Svensson pointed out to me in private mail that a resolution 
service could potentially return a URL with query and/or fragment, so 
this text takes a position on how to interpret such a URL when the 
original URN also had an q-component and/or f-component.   I thought it 
made more sense to ignore those components from the original URN in that 
case.   There are other positions that could be taken, e.g. that 
resolution services should not be permitted to return URLs with queries 
and/or fragments, but I actually think it can be reasonable for them to 
do so.

(new section.  note: text in brackets/italics about r-components should 
only be included if r-component proposal is adopted)

TBD.A. Use of f- and q-components in URN resolution

Since a URN, by design, does not contain either explicitly or implicitly 
the name or address of a network service which can be used to access the 
resource named by the URN, an application wishing to access that 
resource must somehow discover one or more "resolution services" which 
can, given the URN, either provide the resource content directly, or 
provide information to the application to enable it to access the resource.

Though f- and q-components may appear in a URN, they are not assigned or 
managed by the URN namespace, but instead evaluated in the context of 
the named resource.   Specifically, an f-component of a URN refers to a 
"fragment" of the resource named by the URN, and a q-component of a URN 
is used to specify a "query" to be evaluated by the resource named by 
the URN.   This convention ensures consistent use of these components 
across all URN namespaces, and preserves the ability to reference 
"fragments" of resources named by URNs that have fragments, and to 
specify "queries" with resources named by URNs that support queries.   
In order to preserve this ability, f-components and q-components MUST 
NOT be transmitted to a URN resolution service except when that service 
is being requested to provide direct access (or access via proxy) to the 
resource itself.   For all other requests, the client MUST transmit only 
the "assigned-part" of a URN /[ along with any r-component//, if 
specified ]/ to the URN resolution service.

A resolution service processing a request for a URN MUST ignore any 
f-component or q-component of that URN unless the request is to provide 
direct access (or access via proxy) to the named resource.   If the 
request is to provide access to the named resource (as opposed to, say, 
resource locations or resource metadata), the resolution service MUST 
ignore the f-component of the URN and SHOULD (if possible) process the 
q-component as if it were a query transmitted to the resource, returning 
the resource's response to that query.  If the resolution service cannot 
provide the requested access to the resource, but instead returns 
resource locations, the f-component and q-component of the request URN 
MUST be ignored in determining these locations, and MUST NOT be included 
as fragment and query (respectively) in the returned locations.

These rules are intended to impose a layer separation between the URN 
resolution service and the content, and to discourage the URN resolution 
service from returning different results depending on the presence of f- 
and/or q-components in the request.

If the resource named by a URN that contains an f- and/or q-component is 
accessed via an intermediate URI (other than a URN) obtained from a 
resolution service, and that intermediate URI contains neither a 
fragment nor a query, the q-component (if present) is appended to the 
intermediate URI as a query, and the f-component (if present) is 
appended to the intermediate URI as a fragment (in that order).  The 
resulting URI is then processed according to RFC 3986.

Example: If the URN urn:example:foo?bar#zot appears in a link, the 
client application might transmit the assigned-part of that URN 
(urn:example:foo) to a resolution service with a request for resource 
locations.   The resolution service might then return the intermediate 
URI http://example.com/whatnot/xyzzy as one of those locations.   The 
client would then append ?bar#zot to that intermediate URI producing 
http://example.com/whatnot/xyzzy?bar#zot .   This URI would then be 
processed per normal RFC 3986 rules.

A resolution service MAY return an intermediate URI which contains a 
fragment and/or a query.   If the intermediate URI contains a fragment 
or a query, any f- or q-component from the URN is ignored.   (This 
situation is basically no different than anyone composing a URI from a 
base URI plus a fragment and/or query without being aware of what 
fragments and/or queries are valid in the context of the named 
resource.   Any user or document author may combine URIs with arbitrary 
queries and/or fragments, but that doesn't mean that the results will do 
what the user or author intended.)

Example: If the URN urn:example:foo?bar#zot appeared in a link, a 
resolution service might be requested to return locations of the URN 
urn:example:foo .  If such a service returned an intermediate URI 
http://example.com/whatnot/xyzzy?abcde , neither the q-component ?bar 
nor the f-component #zot would be appended to the intermediate URI 
before processing it.

If the content of a resource named by a URN containing an f-component is 
obtained directly from a resolution service, the f-component SHOULD be 
treated as a "fragment" and evaluated with respect to that content, just 
as if the content had been obtained from any other service.

III. Relative References

(new section)

TBD.B. URNs and Relative References

RFC 3986 section 5.2 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. If this algorithm 
were applied directly to URNs, it would pragmatically have the effect of 
imposing additional constraints on the naming of URNs containing 
p-components, in order that relative references contained in the 
resources named by those URNs would not break.  Alternatively, resources 
named with URNs could be forbidden to contain relative references.   
Neither of those alternatives seems attractive.   In addition, if the 
same resources are accessible by both URN and URL, it is desirable to 
permit relative references to work correctly in either case.

Therefore a relative reference SHOULD NOT be evaluated with respect to a 
URN.   Instead, a relative reference SHOULD be evaluated with respect to 
either

(a) a BASE URI (other than a URN) declared by the resource itself, OR
(b) a BASE URI (other than a URN) obtained through the URN resolution 
process, OR
(c) the URL of the resource as obtained through the URN resolution process

(Case (b) 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.

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

---

From: "Leslie Daigle (ThinkingCat)" <[email-masked]>
Date: Thu, 23 Apr 2015 11:21:36 -0400

Hi,

Tackling one issue at a time :^)  -- I went back and re-read RFC3986 per 
your point about "path-rootless", and came to the same conclusion.   I'm 
not a (URI-)parser, though, so I wouldn't object to hearing confirmation 
from someone who does deal in non-URN URI parsing for a living...

Given that, I'd favour "c" as well -- allow "/" with no special 
significance imbued.

Leslie.

On 4/23/15 2:02 AM, Keith Moore wrote:
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn
>

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
[email-masked]
-------------------------------------------------------------------

---

From: "Hakala, Juha E" <[email-masked]>
Date: Fri, 24 Apr 2015 05:49:23 +0000

Hello, 

> -----Original Message-----
> From: urn [mailto:[email-masked]] On Behalf Of Leslie Daigle
> (ThinkingCat)
> Sent: 23. huhtikuuta 2015 18:22
> To: Keith Moore; [email-masked]
> Subject: [urn] "/" Re: suggested text changes for -12 on p-components, f-
> and q-components in URN resolution, and relative references
> 
> Hi,
> 
> not a (URI-)parser, though, so I wouldn't object to hearing confirmation from
> someone who does deal in non-URN URI parsing for a living...
> 
> Given that, I'd favour "c" as well -- allow "/" with no special significance
> imbued.

"C" is my favourite option as well. Colleagues who are responsible of the national library's URN services informed me that "/" has been used often in (other organization's) internal identifiers which they wish to use as URN:NBNs. So avoiding the "/" is not an option. However, if "/" has been used in an identifier, it does not have any special (RFC 3986-based) significance.   

Percent encoding the character in NSS would bring no added value to the URN:NBN resolution.    

Juha 
> > I will try to also suggest text for r-components in a separate
> > message, hopefully sometime tomorrow.  If I don't get it out by
> > tomorrow it will be early next week.
> >
> >
> > I. p-components
> >
> > If we have consensus that (a) relative references in resources named
> > by URNs are always evaluated with respect to a base URI that is not a
> > URN, and (b) there's no special need for URNs to be able to contain
> > "paths", then we have several choices:
> >
> > services, but namespaces shouldn't assign names containing
> > p-components until a standards-track document explains how to do so,
> > OR
> > Any of these seem workable but I lean toward either (a) or (c) - maybe
> > a bit more toward (c) because I suspect there are namespaces that
> > assign names containing "/" which could more easily be URN namespaces if
> "/"
> > Option (b):  Allow p-components in the 2141bis grammar, but reserve
> > them for future use.
> >
> > OLD:
> >
> > [[Note:  Maybe I misunderstand, but I think the -11 text is incorrect
> > in syntax even if we don't change the semantics of p-components at all.
> > As I read 3986, the URI "path" corresponds to the URN namespace:NSS,
> > so the "path" never begins with "/" and can never correspond to
> > NEW:  (delete this.  use or interpretation of f- and q-components
> > should not be namespace-specific)
> >
> >
> > circumstances provide access to resource content (say by caching it),
> > or act as a proxy to a resource, in which circumstances interpreting the
> > this bothers me somewhat, and I'd like for the rules to be simpler
> > while still maintaining a layer separation between the resolution service
> and
> > that resolution services never provide access to resource content,
> > only to locations and metadata.  However, it's long been expected that
> > resolution services should not be permitted to return URLs with
> > queries and/or fragments, but I actually think it can be reasonable
> > for them to do so.
> >
> >
> > (new section.  note: text in brackets/italics about r-components
> > should only be included if r-component proposal is adopted)
> >
> > Since a URN, by design, does not contain either explicitly or
> > implicitly the name or address of a network service which can be used
> > to access the resource named by the URN, an application wishing to
> > access that resource must somehow discover one or more "resolution
> > services" which can, given the URN, either provide the resource
> > content directly, or provide information to the application to enable it to
> access the resource.
> >
> > Though f- and q-components may appear in a URN, they are not assigned
> > or managed by the URN namespace, but instead evaluated in the context
> of
> > "fragment" of the resource named by the URN, and a q-component of a
> > URN is used to specify a "query" to be evaluated by the resource named by
> > NOT be transmitted to a URN resolution service except when that
> > service is being requested to provide direct access (or access via proxy) to
> the
> > request is to provide access to the named resource (as opposed to,
> > say, resource locations or resource metadata), the resolution service
> > MUST ignore the f-component of the URN and SHOULD (if possible)
> > process the q-component as if it were a query transmitted to the
> > resource, returning the resource's response to that query.  If the
> > resolution service cannot provide the requested access to the
> > resource, but instead returns resource locations, the f-component and
> > q-component of the request URN MUST be ignored in determining these
> > locations, and MUST NOT be included as fragment and query (respectively)
> in the returned locations.
> >
> > resolution service and the content, and to discourage the URN
> > resolution service from returning different results depending on the
> > presence of f- and/or q-components in the request.
> >
> > If the resource named by a URN that contains an f- and/or q-component
> > is accessed via an intermediate URI (other than a URN) obtained from a
> > queries and/or fragments, but that doesn't mean that the results will
> > do what the user or author intended.)
> >
> > If the content of a resource named by a URN containing an f-component
> > is obtained directly from a resolution service, the f-component SHOULD
> > be treated as a "fragment" and evaluated with respect to that content,
> > just as if the content had been obtained from any other service.
> >
> > III. Relative References
> >
> > (new section)
> >
> > recomposed per RFC 3986 section 5.3 into a target URI. If this
> > algorithm were applied directly to URNs, it would pragmatically have
> > the effect of imposing additional constraints on the naming of URNs
> > containing p-components, in order that relative references contained
> > in the resources named by those URNs would not break.  Alternatively,
> > resources named with URNs could be forbidden to contain relative
> references.
> > (Case (b) 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.
> >

---

From: "Svensson, Lars" <[email-masked]>
Date: Fri, 24 Apr 2015 10:04:50 +0000

All,

> "C" is my favourite option as well. Colleagues who are responsible of the
> national library's URN services informed me that "/" has been used often in
> (other organization's) internal identifiers which they wish to use as URN:NBNs.
> So avoiding the "/" is not an option. However, if "/" has been used in an
> identifier, it does not have any special (RFC 3986-based) significance.
> 

+1

I shall get back with comments on resolution and relative references.

Best,

Lars

---

From: "Leslie Daigle (ThinkingCat)" <[email-masked]>
Date: Fri, 24 Apr 2015 12:58:17 -0400

I think the proposed section on Relative References works (modulo
removal of discussion of p-components, if that's how the consensus rolls).

Proposed approach:

KEITH:
> references.   Neither of those alternatives seems attractive.

ALTERNATIVELY:
RFC 3986 section 5.2 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.  The notion of a "persistent",
"permanent" identifier (URN) does not reconcile easily with relative
referencing.  However, resources named with URNs may contain relative
references that do not apply to the URN itself.

Leslie.

On 4/23/15 2:02 AM, Keith Moore wrote:
> Here are my suggestions for changes to
> draft-ietf-urnbis-rfc2141bis-11 based on last Friday's conference
> call.
>
>  by URNs are always evaluated with respect to a base URI that is not
> a URN, and (b) there's no special need for URNs to be able to contain
> (a) Disallow p-components in the 2141bis grammar, OR (b) Allow
> p-components in the 2141bis grammar, but reserve them for future use.
> basically this means that parsers would recognize p-components, and
> p-components would be transmitted to resolution services, but
> namespaces shouldn't assign names containing p-components until a
> standards-track document explains how to do so, OR (c) Permit "/" in
>  NSS arbitrarily without giving any special significance to them.
>
> Any of these seem workable but I lean toward either (a) or (c) -
> maybe a bit more toward (c) because I suspect there are namespaces
> that assign names containing "/" which could more easily be URN
> namespaces if "/" did not need to be %-encoded.
>
> "path" component of a URN (according to the 3986 grammar) never
> begins with "/" because a namespace never begins with a "/".   The
> because "segment" is defined to be zero or more "pchar"s.   See RFC
> 3986 mostly section 3.3)
>
> forth through the message.   Pick only one :)   Note that in all
> cases the new text is shorter than the old; I take that as a
> favorable sign.
>
> namestring    = assigned-name [ q-component ] [ f-component ]
> assigned-name = "urn" ":" NID ":" NSS [ p-component ] NID =
> (alphanum) 0*30(ldh) (alphanum) ldh           = alphanum / "-" NSS =
> 1*(pchar) p-component   = "/" path-absolute q-component   = "?" query
> p-components and that "?" can be used without percent-encoding
> inside q-components and f-components.
>
> NEW:
>
> namestring    = assigned-name [ q-component ] [ f-component ]
> assigned-name = "urn" ":" NID ":" NSS NID           = (alphanum)
> 0*30(ldh) (alphanum) ldh           = alphanum / "-" NSS           =
> 1*(pchar) q-component   = "?" query f-component   = "#" fragment
>
> The p-component, q-component, and f-component are optional
> components that follow the assigned-name.  In terms of URI syntax
> these components are essentially equivalent to the URI
> "path-absolute", "query", and "fragment" constructions, respectively.
> However, the URN p-component, q-component, and f-component need not
> be semantically equivalent to the URI path component, query
> component, and fragment component; therefore they are called by
> different names in this specification.
>
> q-component, and f-component for URNs in general. Instead, additional
> specifications might establish these matters for URN- related
> services (such as URN resolution) or for individual URN namespaces
> (e.g., to handle extended information about the resource identified
> by a URN).  For example, it is possible that the q-component might be
> used in requests to URN resolution services, or that the f-component
> might be used to distinguish the integral parts of resources named by
> URNs in particular namespaces (say, the chapters of a book). However,
> defining such usage is the responsibility of specifications for URN
> resolution services, namespace registration requests and
> specifications for individual namespaces, and other appropriate
> documentation (such as policy documents governing the management of a
> given URN namespace).
>
> inappropriate for namespaces that do not intend to support
> resolution services to allow q-components.  Namespaces that deal with
> digital manifestations might be able to support f-components. At the
> time of writing, no general guidance can be provided for use of
> p-components.
>
> NEW
>
> Note: URN syntax provides no equivalent to the "path" component of a
>  generic URI.
>
> See section [TBD.A] for a description on how the URN q-component and
>  f-component affect resolution of a URN, and section [TBD.B] for how
>  relative references are evaluated with respect to a URN.
>
>
> Section 3.3.1 (delete)
>
> Section 4.1
>
> OLD:
>
> The p-component, q-component, and f-component are optional
> components that follow the assigned-name.  In terms of URI syntax
> these components are essentially equivalent to the URI
> "path-absolute", "query", and "fragment" constructions, respectively.
> However, the URN p-component, q-component, and f-component need not
> be semantically equivalent to the URI path component, query
> component, and fragment component; therefore they are called by
> different names in this specification.
>
> q-component, and f-component for URNs in general. Instead, additional
> specifications might establish these matters for URN- related
> services (such as URN resolution) or for individual URN namespaces
> (e.g., to handle extended information about the resource identified
> by a URN).  For example, it is possible that the q-component might be
> used in requests to URN resolution services, or that the f-component
> might be used to distinguish the integral parts of resources named by
> URNs in particular namespaces (say, the chapters of a book). However,
> defining such usage is the responsibility of specifications for URN
> resolution services, namespace registration requests and
> specifications for individual namespaces, and other appropriate
> documentation (such as policy documents governing the management of a
> given URN namespace).
>
> inappropriate for namespaces that do not intend to support
> resolution services to allow q-components.  Namespaces that deal with
> digital manifestations might be able to support f-components. At the
> time of writing, no general guidance can be provided for use of
> p-components.
>
> NEW:
>
> The p-component, q-component, and f-component are optional
> components that follow the assigned-name.  In terms of URI syntax
> these components are essentially equivalent to the URI
> "path-absolute", "query", and "fragment" constructions, respectively.
> However, the URN p-component, q-component, and f-component are not
> See section [TBD.A] for a description on how the URN q-component and
>  f-component affect resolution of a URN, and section [TBD.B] for how
>  relative references are evaluated with respect to a URN.
>
> in syntax even if we don't change the semantics of p-components at
> all. As I read 3986, the URI "path" corresponds to the URN
> namespace:NSS, so the "path" never begins with "/" and can never
> correspond to "path-absolute".   (Yes, we can reuse that production
> from the 3986 grammar if we want to do so, but I see no reason to do
> so.)   And the example given in the next paragraph is also incorrect,
> because there would need to be a ":" after the namespace
> "example".]]
>
> 3.3.1.  p-component
>
> namestring    = assigned-name [ q-component ] [ f-component ]
> assigned-name = "urn" ":" NID ":" NSS [ p-component ] NID =
> (alphanum) 0*30(ldh) (alphanum) ldh           = alphanum / "-" NSS =
> 1*(pchar) p-component   = "/" path-absolute q-component   = "?" query
> p-components and that "?" can be used without percent-encoding
> inside q-components and f-components.
>
> NEW
>
> namestring    = assigned-name [ q-component ] [ f-component ]
> assigned-name = "urn" ":" NID ":" NSS NID           = (alphanum)
> 0*30(ldh) (alphanum) ldh           = alphanum / "-" NSS           =
> 1*(pchar / "/") q-component   = "?" query f-component   = "#"
> fragment
>
> The p-component, q-component, and f-component are optional
> components that follow the assigned-name.  In terms of URI syntax
> these components are essentially equivalent to the URI
> "path-absolute", "query", and "fragment" constructions, respectively.
> However, the URN p-component, q-component, and f-component need not
> be semantically equivalent to the URI path component, query
> component, and fragment component; therefore they are called by
> different names in this specification.
>
> q-component, and f-component for URNs in general. Instead, additional
> specifications might establish these matters for URN- related
> services (such as URN resolution) or for individual URN namespaces
> (e.g., to handle extended information about the resource identified
> by a URN).  For example, it is possible that the q-component might be
> used in requests to URN resolution services, or that the f-component
> might be used to distinguish the integral parts of resources named by
> URNs in particular namespaces (say, the chapters of a book). However,
> defining such usage is the responsibility of specifications for URN
> resolution services, namespace registration requests and
> specifications for individual namespaces, and other appropriate
> documentation (such as policy documents governing the management of a
> given URN namespace).
>
> inappropriate for namespaces that do not intend to support
> resolution services to allow q-components.  Namespaces that deal with
> digital manifestations might be able to support f-components. At the
> time of writing, no general guidance can be provided for use of
> p-components.
>
> NEW
>
> The q-component and f-component are optional components that follow
> the assigned-name.  In terms of URI syntax these components are
> essentially equivalent to the URI "query", and "fragment"
> constructions, respectively. However, the URN  q-component, and
> f-component are not quite semantically equivalent to the URI query
> component and fragment component; therefore they are called by
> different names in this specification.
>
> See section [TBD.A] for a description on how the URN q-component and
>  f-component affect resolution of a URN, and section [TBD.B] for how
>  relative references are evaluated with respect to a URN.
>
> or act as a proxy to a resource, in which circumstances interpreting
> the q-component might be appropriate.   So now the client MUST NOT
> include q-component or f-component unless it's requesting that the
> resolution service provide access to the resource itself, and the
> resolution service is supposed to ignore the q-component except when
> it needs to send it as a query to the resource, and to ignore the
> f-component.   But this bothers me somewhat, and I'd like for the
> rules to be simpler while still maintaining a layer separation
> between the resolution service and the resources which it names. The
> simplest solution is probably to say that resolution services never
> provide access to resource content, only to locations and metadata.
> However, it's long been expected that resolution services could
> provide access to resource content.
>
>  service could potentially return a URL with query and/or fragment,
> so this text takes a position on how to interpret such a URL when the
>  original URN also had an q-component and/or f-component.   I thought
>  it made more sense to ignore those components from the original URN
>  in that case.   There are other positions that could be taken, e.g.
>  that resolution services should not be permitted to return URLs with
> content directly, or provide information to the application to enable
> it to access the resource.
>
> of the named resource.   Specifically, an f-component of a URN refers
> to a "fragment" of the resource named by the URN, and a q-component
> of a URN is used to specify a "query" to be evaluated by the resource
> named by the URN.   This convention ensures consistent use of these
> components across all URN namespaces, and preserves the ability to
> reference "fragments" of resources named by URNs that have fragments,
> and to specify "queries" with resources named by URNs that support
> queries. In order to preserve this ability, f-components and
> q-components MUST NOT be transmitted to a URN resolution service
> except when that service is being requested to provide direct access
>  (or access via proxy) to the resource itself.   For all other
> requests, the client MUST transmit only the "assigned-part" of a URN
>  /[ along with any r-component//, if specified ]/ to the URN
> resolution service.
>
> f-component or q-component of that URN unless the request is to
> provide direct access (or access via proxy) to the named resource.
> If the request is to provide access to the named resource (as opposed
>  to, say, resource locations or resource metadata), the resolution
> service MUST ignore the f-component of the URN and SHOULD (if
> possible) process the q-component as if it were a query transmitted
> to the resource, returning the resource's response to that query. If
> the resolution service cannot provide the requested access to the
> locations, and MUST NOT be included as fragment and query
> (respectively) in the returned locations.
>
> is accessed via an intermediate URI (other than a URN) obtained from
> a resolution service, and that intermediate URI contains neither a
> locations.   The resolution service might then return the
> intermediate URI http://example.com/whatnot/xyzzy as one of those
> locations.   The client would then append ?bar#zot to that
> intermediate URI producing http://example.com/whatnot/xyzzy?bar#zot .
> This URI would then be processed per normal RFC 3986 rules.
>
>  fragment and/or a query.   If the intermediate URI contains a
> fragment or a query, any f- or q-component from the URN is ignored.
> (This situation is basically no different than anyone composing a URI
> from a base URI plus a fragment and/or query without being aware of
> what fragments and/or queries are valid in the context of the named
> resource.   Any user or document author may combine URIs with
> arbitrary queries and/or fragments, but that doesn't mean that the
> results will do what the user or author intended.)
>
> is obtained directly from a resolution service, the f-component
> SHOULD be treated as a "fragment" and evaluated with respect to that
> content, just as if the content had been obtained from any other
> service.
>
> III. Relative References
>
> (new section)
>
> references. Neither of those alternatives seems attractive.   In
> addition, if the same resources are accessible by both URN and URL,
> it is desirable to permit relative references to work correctly in
> either case.
>
> Therefore a relative reference SHOULD NOT be evaluated with respect
> to a URN.   Instead, a relative reference SHOULD be evaluated with
> respect to either
>
> (a) a BASE URI (other than a URN) declared by the resource itself,
> OR (b) a BASE URI (other than a URN) obtained through the URN
> resolution process, OR (c) the URL of the resource as obtained
> through the URN resolution process
>
> Resolution services SHOULD ensure that a BASE URI is supplied any
> time they provide resource content directly to a client.
>
>
>
>
>
>
> _______________________________________________ urn mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/urn
>

--

---

From: "Leslie Daigle (ThinkingCat)" <[email-masked]>
Date: Tue, 28 Apr 2015 10:59:16 -0400

I've been chewing on the proposed f-component and q-component text.  I 
think we need to be clear(er) about the overall concept:  how do 
fragments and queries fit with instance-independent naming of resources? 
   I think it was, indeed, progress to focus on their use as applied to 
resolution to content (via URN or URL), but I don't think the concept of 
composing parts is quite captured in the proposed text.  It reads as a 
bunch of complex rules, from which people might (or might not) derive a 
shared concept.

Example:  If I have a URN for a particular article, that could resolve 
to a URL or a URL for a book with a fragment ID for the article's 
position within the book.   Suppose the f-component on the URN is for a 
particular section of the article.  By the rules outlined below, that 
resolves correctly IFF the resolution process goes for content or gets a 
URL that is undecorated by fragments.

Leslie.

--

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Apr 2015 01:41:33 -0400

On 04/28/2015 10:59 AM, Leslie Daigle (ThinkingCat) wrote:
> fragments and queries fit with instance-independent naming of 
> resources?   I think it was, indeed, progress to focus on their use as 
> applied to resolution to content (via URN or URL), but I don't think 
> the concept of composing parts is quite captured in the proposed 
> text.  It reads as a bunch of complex rules, from which people might 
> (or might not) derive a shared concept.

I agree that the text I proposed could use some more work.

> position within the book. 

I assume you meant "...that could resolve to a URL /for just that 
article/ or a URL for a book with a fragment ID for the article's 
position within the book"?

> Suppose the f-component on the URN is for a particular section of the 
> article.  By the rules outlined below, that resolves correctly IFF the 
> resolution process goes for content or gets a URL that is undecorated 
> by fragments.

Basically I don't think anything useful is likely to happen if both the 
URN has an f-component, and the URN resolves to a URL that has a 
fragment ID.   Nor do I see a sensible way to try to combine the 
f-component from the URN and the fragment ID from the URL.  I think 
that's a case that's very similar to adding a fragment ID to a URL that 
names a resource that doesn't have that fragment.   (In general, just 
because someone adds a fragment to a URI doesn't mean it's going to make 
any sense in relation to that resource's content.)   But it made more 
sense to me to have the behavior in that case be defined rather than 
undefined, and it made more sense to me to give priority to the fragment 
ID obtained during resolution than anything else I could think of.

(One idea I briefly considered and then soundly rejected was to pass the 
f-component to the URN resolution service and let the resolution service 
determine the mapping to URL, which might then contain a query and/or 
fragment.   Basically I think it's a very Bad Idea to have to depend on 
resolution services knowing the internal structure of resources in order 
to use those resources or references to those resources.   Resources 
should be able to be self-contained and usable, independent of URNs and 
URN resolution services; and the URN resolution service shouldn't be 
able to affect interpretation of references internal to a resource.)

Keith

p.s. Note also that there exist fragment definitions for some kinds of 
content that don't require the content to be "decorated" by fragments.   
e.g. the clipping rectangle for an image (with dimensions in pixels).  I 
don't know how widely implemented these kinds of fragments are, but 
apparently there are definitions for several such kinds of fragments.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 29 Apr 2015 19:25:26 -0600

>> Percent encoding the character in NSS would bring no added value to the

In general I think this is fine, and I agree with Keith that it's a good 
sign if we've been able to significantly simplify the text. As far as I 
can see, Keith's proposed text removes the term "p-component" entirely; 
again this is fine, but now that the NSS itself is allowed to contain 
what we've been calling a p-component, I think we should include some 
text explicitly noting this change from RFC 2141 and providing some 
guidance to those who define URN namespaces.

Here is proposed text:

    This document modifies the syntax of the NSS by allowing the "/"
    character.  The primary intent is that the assigned name can
    encapsulate existing identifiers that contain the "/" character.  In
    URNs, the "/" character does not have any special significance (in
    particular, inclusion of the "/" character in the NSS does not imply
    that the URN is "hierarchical", even though the encapsulated
    identifier might be).

    For instance, consider the hypothetical example of a hierarchical
    naming system in which the identifiers take the form of a series of
    numbers separated by the "/" character, such as "1/406/47452/2".  If
    the naming authority for such identifiers were to use URNs, it would
    be natural to place the existing identifiers in the NSS, resulting
    in URNs such as "urn:example/1/406/47452/2" (using the "example" URN
    namespace [RFC6963]).

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 29 Apr 2015 19:29:29 -0600

> references that do not apply to the URN itself.

Leslie's text looks reasonable to me. However, I suppose one could 
quibble that allowing "/" in the NSS effectively mean that URNs can 
indeed "support the necessary path components" - which is why I think 
it's important to include some text describing the role of "/" in the 
NSS (see the other message I just sent).

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Apr 2015 00:50:45 -0400

On 04/29/2015 09:25 PM, Peter Saint-Andre - &yet wrote:
>>>> significance
> In general I think this is fine, and I agree with Keith that it's a 
> good sign if we've been able to significantly simplify the text. As 
> far as I can see, Keith's proposed text removes the term "p-component" 
> entirely; again this is fine, but now that the NSS itself is allowed 
> to contain what we've been calling a p-component, I think we should 
> include some text explicitly noting this change from RFC 2141 and 
> providing some guidance to those who define URN namespaces.
>
> Here is proposed text:
>

This is fine with me except that the example URN would still need a ":" 
after the namespace identifier,
e.g. urn:example:1/406/47452/2

Another thing that might be worth saying in the text is that the 
extension of 2141 syntax to permit "/" in NSS doesn't change the NSS 
syntax associated with any existing namespace.   However if an existing 
namespace wants to start assigning URNs with "/"s in them, it can update 
its registration to make it clear that they are permitted.

(one possible wrinkle:  if any existing namespace has "native" names 
that include "/" but those currently require percent-encoding, those 
namespace should still require percent-encoding for "/"s.   If "/"s in 
those namespaces appear without percent-encoding the comparison for 
equivalence will break.)

Keith