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

From: "Svensson, Lars" <[email-masked]>
Date: Tue, 5 Nov 2013 11:21:09 +0000

Juha,

Thanks for your clarifications.
 
> On 4.11.2013 20:43, Svensson, Lars wrote:
> > 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.
> Sorry, I was not specific enough. The idea is that the query is not part of the
> URN namespace specific string.
> > ]] [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?

> 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.

My reading of your answer is that a urn starts with 'urn' and ends with the character before the first '?', the first '#' or with the end of the string, whichever comes first. Is my understanding of your position correct? The reason I keep asking is that I need to understand where the URN starts and where it ends. In my opinion we should not discuss syntactic elements for URNs that are not part of the URN itself. So if query and fragment are not part of the URN (i. e. URN + query != URN), we should leave them out of RFC 2141bis. 

> 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.

Yes, and that is why it might be a better idea not to allow queries in URN syntax. If we agree that they make sense for resolution services but not in other contexts, we should not allow them in URNs (i. e. in RFC 2141bis) but only specify them for resolution services (RFC 2483bis).

> > 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.

So here we seem to agree.

> >>>> I don't understand why we need to pass those queries as part of
> >>>> URNs themselves.
> 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.

What I don't understand is why I need to attach the query to the URN per se. I add the query when I send a resolution request to the resolver, and then I add it to the resolution request, not to the URN. Or put differently: When I want to resolve a URN, I have three parts to consider:
1) the resolution service, available at some address
2) the URN I want to resolve
3) further information targeted at the resolution service (e.g. preferred metadata format, only MD5 hash, etc.).

IMO 3) could (should?) be put into a query, but again, I send that query to the resolver, not to the resource identified by the URN. Thus the query has nothing to do with URNs but only with resolution services (I'm repeating myself...).

> >>>> 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.
> 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.

Again, those are queries targeted at resolution services and should be handled in RFC 2483bis.

> 
> >>> 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.
> 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.

Just in order to keep terminology aligned: "it just pinpoints a location within the *resource* identified by the URN."

> >>> 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.
> 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.

I don't have working examples and my wording was grubby. What I intended to say was that what I see is that people want to pass queries to resolution services and that they don't want to query the identified resource.

When implementing the German URN-NBN resolver [1], we chose to make a work-around to address fragments in resources [2], since the syntax doesn't allow it.

> > 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)?

> 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.

OK, thanks for your response.

> 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 ~?

Yes, this is another open question...

[1] http://nbn-resolving.org/
[2] http://nbn-resolving.org/examples

Best,

Lars

---

From: Bengt Neiss <[email-masked]>
Date: Wed, 6 Nov 2013 13:26:42 +0000

Hello all,

> -----Ursprungligt meddelande-----
> Från: [email-masked] [mailto:[email-masked]] För Svensson,
> Lars
> Skickat: den 5 november 2013 12:21
> Till: Juha Hakala
> Kopia: [email-masked]; [email-masked]; Keith Moore
> Ämne: Re: [urn] Working Group Last Callof draft-ietf-urnbis-rfc2141bis-urn-
> 06.txt
> 
> Juha,
> 
> > Sorry, I was not specific enough. The idea is that the query is not
> > part of the URN namespace specific string.
> > > ]] [1]
> > >
> > 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.
> 
> My reading of your answer is that a urn starts with 'urn' and ends with the
> character before the first '?', the first '#' or with the end of the string,
> whichever comes first. Is my understanding of your position correct? The
> reason I keep asking is that I need to understand where the URN starts and
> where it ends. In my opinion we should not discuss syntactic elements for
> URNs that are not part of the URN itself. So if query and fragment are not
> part of the URN (i. e. URN + query != URN), we should leave them out of RFC
> 2141bis.

As the text in draft-ietf-urnbis-rfc2141bis-urn-06 is written it defines a urn as " assigned-name = "urn" ":" NID ":" NSS " and  " namestring    = assigned-name [ "?" query ] [ "#" fragment ] "
As I understand it a URN corresponds to  the "assigned name" and query and fragment are not part of the URN.

> 
> > 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.
> 
> Yes, and that is why it might be a better idea not to allow queries in URN
> syntax. If we agree that they make sense for resolution services but not in
> other contexts, we should not allow them in URNs (i. e. in RFC 2141bis) but
> only specify them for resolution services (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 agree.

> > 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.
> 
> What I don't understand is why I need to attach the query to the URN per se.
> I add the query when I send a resolution request to the resolver, and then I
> add it to the resolution request, not to the URN. Or put differently: When I
> want to resolve a URN, I have three parts to consider:
> IMO 3) could (should?) be put into a query, but again, I send that query to
> the resolver, not to the resource identified by the URN. Thus the query has
> nothing to do with URNs but only with resolution services (I'm repeating
> myself...).

I guess this depends on what we consider to be a resource.
For us (and our use cases), working at a national library, it is quite obvious (I guess) for what we consider to be a resource. 
For others a resource might be a something totally different where a query sent to the resource might make sense. 

But for me I agree
Query is sent to the resolver, not the resource, so no need to attach the query to the URN per se.

> > >>>> 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.
> > 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.
> >
> > 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).
> >
> > 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.
> 

The text in draft-ietf-urnbis-rfc2141bis-urn-06 section 4.3 (Query Component and Fragment Identifier Component) already gives some directions on where guidelines can be found (refers the question to, for example RFC 2483bis, as I understand it). 
Is the concern that this is not enough and that the text should be more explicit about it?

> 
> >
> > >>> 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.
> > 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.
> 
> > >>> Probably that is not a good idea although I'm not sure I
> > >>> understand all of the implications either way.
> > 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.
> 
> I don't have working examples and my wording was grubby. What I intended
> to say was that what I see is that people want to pass queries to resolution
> services and that they don't want to query the identified resource.
> 
> When implementing the German URN-NBN resolver [1], we chose to make a
> work-around to address fragments in resources [2], since the syntax doesn't
> allow it.
> 
> > 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.
> >
> > URNs are definitely URIs and therefore should follow the letter
> > (syntax) if not the spirit (semantics) of RFC 3986.
> 
> > 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 ~?
> 

All the best,

//Bengt