Subject: [urn] suggested text for r-components

From: Keith Moore <[email-masked]>
Date: Fri, 24 Apr 2015 00:53:21 -0400

Okay, here's a first stab at text for r-components.   This isn't 
complete; in particular the IANA section needs more prose.

I am also sensitive to the concern Leslie expressed - i.e. that if I 
don't happen to finish writing it down, someone will come along and 
interpret it completely differently than was intended. (Or perhaps more 
likely, if I am unable to specify this succinctly and yet with 
sufficient clarity and detail.)   This is currently missing both some 
clarity and some detail, but it will be sometime next week before I can 
look at it again.

---

The basic idea is that an r-component consists of a request followed by 
one or more constraints.   The request is something like U2R (access an 
instance of the named resource), U2L (request locations of the named 
resource), or U2C (request metadata about the named resource).  (I'm not 
particularly fond of those names, and would be happy with other names, 
but there is some history behind these names.)

In each case, evaluating the request should produce a set of results.   
In the U2R case that set would be a set of resource instances (even 
though only one of them could be ultimately used).   In the U2L case it 
would be a set of resource locations.  In the U2C case it would be a set 
of resource descriptions. (The result set for any of these requests can, 
of course, be the null set.)

In any of these cases the items in the set may vary along certain 
dimensions.  For instance, a resource may exist in multiple revisions.  
It may have versions in multiple languages.  It may be available in 
different media types, e.g. HTML and PDF.  In the U2C case there may be 
MARC records, Dublin Core metadata sets, etc.   The constraints exist to 
narrow the result set.  Examples of constraints might be things like 
"order by revision-date descending" or "limit to a maximum of 10 
results" or "include only resource instances with content-types in [ 
application/pdf, text/html ]" or "include only resource descriptions in 
the set [ dublin-core ]" or "revision dates between 2001-1-1 and 
2002-12-31".

Constraints can be forwarded to URN resolution services to let the 
filtering be done by the service; additional filtering may be done by 
the client.  If a client or a resolution service doesn't know how to 
implement a constraint, that constraint may be ignored.  (even though 
this may produce a result set that contains members that don't satisfy 
all of the constraints.)

Both the set of requests and the set of results are extensible via an 
IANA registry for each.   I would like to define the initial requests as 
U2R, U2L, and U2C (perhaps by other names).   My current thinking is to 
not define any constraints in this document, and leave constraint 
definitions for other documents.   I expect that there will be a need 
for both additional requests and a wide variety of constraints, though I 
hope we can identify a minimal core set for each that clients and 
resolution services can reasonably implement.

--

One thing I realized is that r-components probably should not be 
evaluated entirely by the resolution service, because the client 
application may have a role in satisfying the request.   For instance 
the request (U2R) may be to access the actual resource named by the URN, 
but the resolution service might not provide such access.  So in that 
event the client needs to request locations from the resolution service, 
pick one, and access the resource via that location.

Another thing I realized is that resolution services will naturally 
differ in which requests and constraints that they support, and it's 
necessary for client software to be able to combine results from 
different services in spite of this.   So whatever constraints are 
implemented by a resolution service are essentially optimizations to 
reduce server load and network traffic.   So my original thinking about 
r-components was that they're parameters to be transmitted to resolution 
services, now I think that they're more like search constraints 
implemented on clients.

--

Anyway, here's a start at some text.

These changes are relative to draft-ietf-urnbis-rfc2141bis-urn-11, not 
to any other set of proposed changes.

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

NEW:

       namestring = assigned-name
                       [ r-component ]
                       [ 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
       r-component   = "??" request *(";" constraint)
       request       = 1*(unreserved)
       constraint    = name 0*1("=" value)
       name          = alpha *(alphanum / ".") alphanum
       value         = *( unreserved / pct-encoded
                        / "!" / "$" / "&" / "'" / "(" / ")"
                        / "*" / "+" / "," / "=" / ":" / "@"
                        / "/" )

(somewhere later in section 3)

This grammar is syntax-compatible with the URI grammar in RFC 3986; 
however, it parses the
URN differently than the RFC 3986 grammar.   An RFC 3986 parser will 
parse the combination
of any "r-component" and/or "q-component" as a single "query".

New section TBD.C:

TBD.C.  r-component

    In contrast to f-component (which specifies a fragment of the named 
resource), and
    q-component (which specifies a query to be sent to the named 
resource), the optional
    r-component specifies a default "use" of the URN.  Broadly speaking, 
"use"s that have
    been identified as desirable fall into one of three categories: 
requests to access
    the resource, requests to obtain one or more locations of the 
resource, and requests
    for information about the resource ("metadata").  The request may be 
followed by
    zero or more parameters which are interpreted as modifiers to the 
request.   For
    instance, the parameters might specify: revision or range of 
revisions, language
    or set of languages, acceptable media types, or a preference to have 
the results
    reported according to a particular schema and/or representation.   
These parameters
    generally have the effect of narrowing the set of responses or 
potential responses
    to a request.

    More than one parameter with the same name MAY appear in an 
r-component.

    Implementation of requests and interpretation of parameters is the 
job of URN-aware
    client applications.  However, it is anticipated that URN resolution 
services will
    provide support for frequently used requests that appear in 
r-components, and may
    also interpret some of the parameters associated with r-components.

    A URN-aware client application MAY ignore r-component requests 
and/or parameters
    when they specify a behavior that is not appropriate for the context 
in which the
    URN appears.  A client application MAY also permit a URN which 
contains an
    r-component to be used for a different purpose than that specified 
in the r-component.
    For example, if a URN appears in a "link" in a document, and the 
request in the URN's
    r-component specifies that the resource should be accessed directly, 
clicking on the
    link might cause the URN's target content to be displayed. However, 
the client
    application might also allow the user to request other behaviors 
(say, via a
    pull-down menu) such as to display the available locations and/or 
metadata associated
    with the URN.

    If a URN does not include an r-component, the default use of the URN 
is determined
    by the client application and possibly by the context in which the 
URN appears.

    A client application MAY interpret an r-component's request and 
attempt to implement
    the specified default use independent of any resolution service.   
For example,
    if the request in a r-component specifies that the resource should 
be accessed,
    a client application MAY obtain a location of that resource from a 
resolution
    service and then arrange access to the resource via that location.

    The set of requests is defined by an IANA registry. The set of 
parameter names is
    defined by a separate IANA registry. Parameter names beginning with a
    IANA-registered URN namespace ID followed by "." are reserved for 
definition by
    that namespace.  This permits each namespace to define additional 
parameters
    which may be specific to its namespace or to the kinds of resources 
to which
    it assigns URNs.

    r-components are not considered significant for the purpose of 
comparing URNs
    for equivalence.

New section 8.3:

8.3.   Registration of URN r-component request names

        r-component requests are intended for broad categories of 
requests for
        URN processing that could reasonably be fulfilled by resolution 
services,
        and/or by clients capable of processing URNs.

        The set of request names that are prefixed by a registered URN 
namespace
        followed by "." is reserved for definition by that namespace.   
A namespace
        MAY register such names with IANA but is not required to do so.  
Registration
        of additional request names not prefixed by a registered URN 
namespace
        requires IETF consensus.

        IANA is hereby requested to register the following URN 
r-component request
        names:

        Request-name: "U2R"
        Purpose:  This is used to request access to the named resource.

        Request-name: "U2L"
        Purpose:  This is used to request zero or more locations of the 
named resource.

        Request-name: "U2C"
        Purpose:  This is used to request information about the named 
resource (metadata).

8.4.   Registration of URN r-component parameter names

        *** to be written ***

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Apr 2015 10:37:09 -0400

The "suggested text for r-components" message I sent earlier was 
somewhat hurried and incomplete because I am leaving town for a few days 
and wanted to get something out the door before leaving.   But I woke up 
this morning and realized two things:

1. I had started out saying that r-components are needed to communicate 
parameters to resolution services and ended up saying they're for 
interpretation by clients.   I think these are both true, but I don't 
think I've adequately captured the relationship between the client's 
role and the resolution service's role.

2. I had started out saying that "constraints" are name = value pairs.   
At the last minute before sending the message I changed the grammar to 
make the "= value" part optional.   Because I think that there's likely 
to be a lot of potential variation in the kinds of constraints that 
resolution services implement, I think the name should actually specify 
the type of constraint (something akin to the computer language in which 
the constraint is being expressed) rather than, say, the name of the 
attribute that's being constrained.

Note:  I imagine that people will want to express constraints in a 
language that reflects the characters available in a URI according to 
RFC 3986.   So for instance while we might like to be able to express 
relational constraints, we don't have "<" and ">" available.   So we 
might end up using something like FORTRAN's notation - .lt. for less 
than, .gt. for greater than, and so on.

On 04/24/2015 12:53 AM, Keith Moore wrote:
> interpret it completely differently than was intended. (Or perhaps 
> more likely, if I am unable to specify this succinctly and yet with 
> clarity and some detail, but it will be sometime next week before I 
> can look at it again.
>
> ---
>
> The basic idea is that an r-component consists of a request followed 
> by one or more constraints.   The request is something like U2R 
> (access an instance of the named resource), U2L (request locations of 
> the named resource), or U2C (request metadata about the named 
> resource).  (I'm not particularly fond of those names, and would be 
> happy with other names, but there is some history behind these names.)
>
> In each case, evaluating the request should produce a set of 
> results.   In the U2R case that set would be a set of resource 
> instances (even though only one of them could be ultimately used).   
> In the U2L case it would be a set of resource locations.  In the U2C 
> case it would be a set of resource descriptions. (The result set for 
> any of these requests can, of course, be the null set.)
>
> different media types, e.g. HTML and PDF.  In the U2C case there may 
> be MARC records, Dublin Core metadata sets, etc.   The constraints 
> exist to narrow the result set.  Examples of constraints might be 
> things like "order by revision-date descending" or "limit to a maximum 
> of 10 results" or "include only resource instances with content-types 
> in [ application/pdf, text/html ]" or "include only resource 
> descriptions in the set [ dublin-core ]" or "revision dates between 
> 2001-1-1 and 2002-12-31".
>
> IANA registry for each.   I would like to define the initial requests 
> as U2R, U2L, and U2C (perhaps by other names).   My current thinking 
> is to not define any constraints in this document, and leave 
> constraint definitions for other documents.   I expect that there will 
> be a need for both additional requests and a wide variety of 
> constraints, though I hope we can identify a minimal core set for each 
> that clients and resolution services can reasonably implement.
>
> --
>
> the request (U2R) may be to access the actual resource named by the 
> URN, but the resolution service might not provide such access.  So in 
> that event the client needs to request locations from the resolution 
> service, pick one, and access the resource via that location.
>
> reduce server load and network traffic.   So my original thinking 
> about r-components was that they're parameters to be transmitted to 
> resolution services, now I think that they're more like search 
> constraints implemented on clients.
>
> --
>
>    r-component specifies a default "use" of the URN.  Broadly 
> speaking, "use"s that have
>    for information about the resource ("metadata").  The request may 
> be followed by
>    or set of languages, acceptable media types, or a preference to 
> have the results
>    client applications.  However, it is anticipated that URN 
> resolution services will
>    when they specify a behavior that is not appropriate for the 
> context in which the
>    r-component specifies that the resource should be accessed 
> directly, clicking on the
>    If a URN does not include an r-component, the default use of the 
> URN is determined
>        MAY register such names with IANA but is not required to do 
> so.  Registration

---

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

> but there is some history behind these names.)

Overall I'm still feeling queasy about r-components. It's a large change 
to the spec and I feel that it's strongly tied to resolution. I am 
wondering whether later on (i.e., when and if someone writes a spec that 
updates or obsoletes RFC 2276) we can define r-components as a 
convention used in relation to URN resolution. Because r-components are 
allowed by q-component syntax, this seems feasible. And because they 
represent a significant and untried addition to URNs, this seems 
desirable (at least to me).

Peter

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

---

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

On 04/29/2015 09:47 PM, Peter Saint-Andre - &yet wrote:
>
> Overall I'm still feeling queasy about r-components. It's a large 
> change to the spec and I feel that it's strongly tied to resolution. I 
> am wondering whether later on (i.e., when and if someone writes a spec 
> that updates or obsoletes RFC 2276) we can define r-components as a 
> convention used in relation to URN resolution. Because r-components 
> are allowed by q-component syntax, this seems feasible. And because 
> they represent a significant and untried addition to URNs, this seems 

Of course r-components are strongly tied to resolution, since their 
intended purpose is to affect resolution.  :-)

The essential thing to establish now, IMO, is the separation between a 
query that's passed to a resource and a query that's passed to a 
resolution service (even if part of the logic of that service is 
implemented in the client).    If we don't do that now, code will be 
written that passes everything after the first "?" to the resource as a 
query, and that will make it much more difficult to implement resolution 
services later without breaking things.

However what might work is to define a syntax for r-components in 
2141bis and declare that they're reserved for future use by an IETF 
standard.   And I think we should go ahead and try to define a standard 
framework for resolution, but maybe that doesn't have to be a blocking 
item for 2141bis.

Keith

---

From: "Leslie Daigle (ThinkingCat)" <[email-masked]>
Date: Thu, 30 Apr 2015 16:01:33 -0400

Below...

> framework for resolution, but maybe that doesn't have to be a blocking

is the sort of thing I was thinking of when I said leaving a "hook".

Leslie.

>
> Keith
>
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn