Subject: Re: [urn] Separate schemes for resources and resolution services

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 30 Oct 2013 21:05:12 -0600

Hi Martin, my apologies for the delayed reply to this and other threads.

On 09/23/2013 01:29 AM, "Martin J. Dürst" wrote:
> Hello Juha, John, others,
> 
> Caveat: I have been following the urn WG only with a limited time 
> budget, but see below for my thinking.
> 
> On 2013/09/19 14:21, Juha Hakala wrote:
>> Hello,
>> 
>> On 4.9.2013 6:21, John C Klensin wrote:
>>> 
>>> --On Tuesday, September 03, 2013 21:04 -0600 Peter Saint-Andre 
>>> <[email-masked]> wrote:
>>> 
>>>>> Would it be appropriate to incorporate text into 2141bis 
>>>>> and/or 3406bis that explicitly reserves "agent" as a query 
>>>>> keyword and specifies "agent=resolver" as the default
>>>>> case?
>>>> Personally I'd prefer to avoid reserving key-value pairs for 
>>>> the query component...
>> It might be better to keep 2141bis simple and leave any
>> guidelines of how to use query out of it. Then there will be no
>> need to amend or expand the text in the future as regards the
>> query utilization.
>> 
>> The future version of rfc2483 will not even try to provide an
>> exhaustive list of resolution services, since no such thing can
>> exist. Instead there will be an (IANA) registry of services. This
>> registry should contain a mnemonic (for example I2R for URI to
>> resource) for each service and query syntax for requesting them
>> from resolvers (for example "?s=I2R"). In addition, the registry
>> has to list service-specific parameters.
>> 
>> Instead of supplying the query related information piece by piece
>> in 2141bis, 3406bis, 2483bis and in the (proposed) registry of
>> services it is better to collect it into one place from which the
>> implementers can easily find it and where it is as easy as
>> possible to maintain it.
>> 
>> I am not sure if we need to / can tell the implementers what kind
>> of query combinations make sense. Making such a document
>> exhaustive would be difficult.
>> 
>> IMO it would not do any harm to reserve agent as a query
>> keyword.
> 
> URNs are resource identifiers. As such, I think that if they have
> query parameters, these should be defined by the resource, without
> any influence by resolution services. That's what I'd assume for
> any other URI scheme, too.
> 
> For something close to resolution parameters, I seem to remember
> that an early URI spec defined a place for such parameters after a
> ';'. I can dig up the spec if that helps.
> 
> However, I think that it might be better to create a new scheme, or
> new schemes, for resolution services if they need additional
> parameters. An example generic 'resolution service' scheme might
> look as follows: 
> urn-resolution:urn=urn:isbn:123-45678-90;resolve-to=meta_data 
> Schemes for particular resolver protocols are also possible; some
> of them might not need their own scheme, in particular if they run
> over http.
> 
> This has several advantages: It separates the resource from the 
> resolution, which is conceptually how things should be.[*] It
> allows both resources and resolution to use whatever 'query'
> parameters they deem appropriate, without name conflicts, and it
> allows the query parameter space for resolution services to be
> developed from now on, at a point where we are not sure yet how
> much these parameters will be shared between resolution services.
> 
> Hope this helps,    Martin.
> 
> [*] Just to give an example, nobody would propose to put a "proxy" 
> parameter into an http: URI, although HTTP proxies can be thought
> of as a kind of resolution service. Also, nobody would propose to
> add something to the http: URI syntax in order to e.g. distinguish
> a "GET" request from a "HEAD" request. But this is quite close to
> the distinction between 'resource' and 'metadata' in the URN
> resolver discussions.

Martin, I find these distinctions quite helpful. In previous messages
to this list, I have mentioned that I would find it reasonable for a
URN resolution service to be run as a web service at an HTTP(S) URI,
for example:

https://res.example.com/?urn=urn:isbn:123-45678-90&resolve-to=metadata

(As you suggest, we could define some new URI scheme for resolution,
but using HTTP(S) seems much easier.)

However, I don't really find it reasonable to use URNs to both
identity resources and interact with resoluton services. Although it's
been assumed that this makes sense, I think it's incumbent upon those
who want this feature to make a clear, cogent, persuasive argument for it.

Thus I suggest that we leave 2141bis as the specification for resource
naming only (which is what the acronym "URN" denotes anyway). If those
who use resolution services feel that they need to define a new URI
scheme or to define conventions for resolving URNs via HTTP or some
other protocol, they are free to do so. Overloading the resource
naming scheme (URNs) to also interact with resolution services seems
quite problematic to me.

Peter