Subject: Re: [urn] Working Group Last Callof draft-ietf-urnbis-rfc2141bis-urn-06.txt

From: "Svensson, Lars" <[email-masked]>
Date: Mon, 4 Nov 2013 18:43:18 +0000

On Monday, November 4, Peter Saint-Andre wrote:

All,

> On 10/31/13 7:00 AM, John C Klensin wrote:
> >
> >
> > --On Wednesday, October 30, 2013 21:26 -0600 Peter Saint-Andre
> > <[email-masked]> wrote:
> >
> >>> As I see it, queries will primarily be used for passing service
> >>> requests to the URN resolvers. Such functionality makes a lot of
> >>> sense, at least from implementer point of view. But in order to
> >>> future proof the syntax it should also be able to specify queries
> >>> which should be processed in the client end.
> >>
> >> I understand why we might want to pass queries to resolvers.

If I understand Juha's arguments correctly, he considers the query not to be part of the URN, but rather attached to it:

[[
Since query is not part of the URN, what is being identified does not change. In that sense the meaning of the URN does not change. But each example above would use different queries to ask the URN resolver to launch different resolution services.
]] [1]

My reading of this is that this would be a URN

urn:example:foo

but this is not a URN

urn:example:foo?query=goes&here=!

@Juha: Can you please confirm (or not) if my reading of your arguments is correct?

I agree with Peter (and possibly others) that queries are good for sending information to resolvers. IMO we should handle those queries in RFC 2483bis. 

> >> I don't understand why we need to pass those queries as part of URNs
> >> themselves. 

I have tried to give a few examples (most of them fairly far-fetched); there search-in-e-book example is probably the most interesting one [2]. That does not mean that I promote queries in URNs, but only for resolution services.

> >> It appears that the designers of some systems currently deployed have
> >> decided that passing queries in URNs is a good idea. As far as I can
> >> see, even though we don't know why they did so, this WG is
> >> essentially being asked to validate that decision.

> > First of all, I think Juha and others have given several reasons why
> > queries "as part of" URNs are necessary, with references into named
> > objects being key among them.  One might be able to meet most of those
> > needs with fragments instead, but doing so would essentially turn
> > fragment identifiers into queries.
> > Probably that is not a good idea although I'm not sure I understand
> > all of the implications either way.

I currently only see that people pass queries to resolution services by using UIs that create an http-URI having a URN and a query in it, not that they actually pass queries in URNs.

I'll finish with two questions to the group:

Do we in the WG have consensus on where a URN ends (and thus if query and fragment are part of the URN or not)?
Do we in the WG have consensus on if URNs (with or without queries and fragments) are URIs or not?

Lars

[1] http://www.ietf.org/mail-archive/web/urn/current/msg02010.html
[2] http://www.ietf.org/mail-archive/web/urn/current/msg02094.html

---

From: Juha Hakala <[email-masked]>
Date: Tue, 05 Nov 2013 10:57:29 +0200

Hello,

> Since query is not part of the URN, what is being identified does not change. In that sense the meaning of the URN does not change. But each example above would use different queries to ask the URN…
Sorry, I was not specific enough. The idea is that the query is not part 
of the URN namespace specific string.
> @Juha: Can you please confirm (or not) if my reading of your arguments is correct?
Both URIs above contain the same URN.  That is, they have the same NSS 
(example) and NID (foo) and therefore identify the same resource. The 
difference between these URNs lies in the resolution process. The former 
resolves to whatever is the default thing supplied by the resolver which 
deals with the URN namespace "example", while the latter specifies a 
service the resolver is expected to provide.

It should be noted that according to RFC 3986, the thing that the latter 
URN resolves to (e.g. a metadata record describing the identified 
resource) is identified by the URN + query. This would extend the scope 
of some (most?) existing URN namespaces far beyond what is acceptable 
and make identification process very hard to manage.
> I agree with Peter (and possibly others) that queries are good for sending information to resolvers. IMO we should handle those queries in RFC 2483bis.
Fine. The work on RFC 2483bis will start in earnest once the URNBIS WG 
is in full agreement on how to proceed.
>>>> I don't understand why we need to pass those queries as part of URNs
Because it seems that that may be the easiest way of passing service 
requests to resolvers. The first URN WG could not consider that option 
because back then the URI generic syntax did not specify query. Now that 
the specification is in place, we should use it if and when possible. 
And we must in any case tell how query and fragment are to be understood 
in the URN context, since the RFC 3986 approach is not palatable for 
most URN namespaces.
>>>> essentially being asked to validate that decision.
I do not agree with this view. Most URN resolvers do not support 
queries. I do not know any applications which do (but Lars seems to be 
familiar with some; see below) Most implementers are waiting for the new 
URN syntax and related documentation (such as RFC 2483bis) to tell them 
exactly how to proceed.

Some PIDs (most notably ARK) have developed their own, non-RFC 3986 
compliant ways of passing service requests to resolvers. Although one 
may argue that this is OK (since ARK resolver will know how to deal with 
"?" or "??" in the end of the ARK identifier) my gut feeling is that 
solutions such as these should be avoided if the same thing can be done 
using the plain vanilla URI syntax. If in some distant future ARKs have 
to be resolved by e.g. URN resolvers non-standard syntactical features 
may become a pain in the neck.

The challenge URN implementers are facing is that there are more and 
more resolution services that could / should be supported, but the 
existing means for specifying services (RFC 2483) and mechanisms for 
passing them to resolvers (DDDS) do not meet the requirements. Since the 
implementations of DDDS are for some reason few and far between, we need 
something that should be easier to implement (and could be used by other 
PIDs as well).

If the WG does not provide any quidelines for the use of query of even 
excludes it from the URN syntax, there is a risk that people start using 
them in any case. This will inevitably lead to interoperability problems 
and duplication of effort. IMO ARK is a good example of what will happen 
if we fail to tell the implementers what to do with the query.

>>> fragment identifiers into queries.
Yes, and that is something I definitely don't want to do. URN fragments 
should not be functionally any different from URI fragments. Otherwise 
there is of course the difference that from URN point of view, fragment 
does not identify anything, it just pinpoints a location within the 
document identified by the URN.
> I currently only see that people pass queries to resolution services by using UIs that create an http-URI having a URN and a query in it, not that they actually pass queries in URNs.
Lars, can you give me examples of these resolvers? The functionality you 
describe above is exactly what we have in mind in e.g. my library. What 
is missing is the specifications of services, service parameters and 
syntax in which to express them as a query. Existing implementations, 
although premature, might give an idea of what works and perhaps also of 
what does not.
> Do we in the WG have consensus on where a URN ends (and thus if query and fragment are part of the URN or not)?
Neither fragment nor query should part of the NID. So if we say that 
URNs consist of "urn:", NSS and NID, then fragment and query are not 
part of the URN, although they are part of the HTTP URI which is resolved.

However, since the WG intends to provide quidelines on how to construct 
queries, I prefer a solution (which is at least implicitly embedded into 
the current RFC 2141bis) where query and fragment are seen as part of 
the URN, although they do not have a role in identification.

> Do we in the WG have consensus on if URNs (with or without queries and fragments) are URIs or not?
URNs are definitely URIs and therefore should follow the letter (syntax) 
if not the spirit (semantics) of RFC 3986.

Juha

PS. Lars noted 24.9 that:

> In my opinion we also do not have consensus on the allowed/reserved characters, particularly ~, / and &.
Correct. Initially I thought that we may reserve all these characters in 
NIDs. But a colleague told me that he is involved with a project which 
wants to use / in NID and does not want  to percent encode the 
character. If we allow /, should we then allow also & and ~?

-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. +358 9 191 44293
  Mobile +358 50 3827678