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

From: Andrew Newton <[email-masked]>
Date: Tue, 13 Aug 2013 15:33:25 -0400

All,

Today begins a two-week working group last call of
draft-ietf-urnbis-rfc2141bis-urn-06.txt. This last call will end
Tuesday, 27 August 2013.

The document can be found here:
http://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/

Please review and comment on the draft, even if it is only to say on
the record "I have reviewed this document thoroughly and it looks
good."  We would like to have no fewer than five people report that
they have taken a look at the whole document and reported their
findings.

-andy newton, co-chair

---

From: Michael Mealling <[email-masked]>
Date: Tue, 13 Aug 2013 17:03:20 -0400

I have reviewed this document and it looks OK to me. While I'm not suggesting it be added to the document or should stop anything from moving forward, I would personally prefer this paragraph in Section 6:

"If a query component, fragment identifier component, or both have
been appended to the assigned URI, they MUST be ignored for purposes
of determining equivalence."

be in bright red 72 point type on every page .

-MM

Michael Mealling
Co-Founder
Pipefish.com
+1-678-640-6884	@mmealling
Schedule a meeting:  http://meetme.so/michaelmealling

On Aug 13, 2013, at 3:33 PM, Andrew Newton <[email-masked]> wrote:

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

---

From: Juha Hakala <[email-masked]>
Date: Wed, 14 Aug 2013 09:40:47 +0300

Hello,

I have reviewed the text once more and it looks fine.

Juha

-- 

  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

---

From: Keith Moore <[email-masked]>
Date: Sat, 17 Aug 2013 17:26:51 -0400

Section 4.3 needs work.   The text in -06 is worse than the text in 2141.

It is a Very Bad Idea to allow queries and fragments in URNs and not 
define what they mean.  This will lead to conflicts in interpretation of 
queries and/or fragments between different resolution services and/or 
different namespaces (and perhaps also different user interfaces) which 
will then result in inconsistent handling of URNs containing queries 
and/or fragments.

The only interpretation of queries and fragments that is at all 
consistent with RFC 3986, and still makes sense for URNs, is for queries 
and fragments to be evaluated entirely in the context of the referenced 
resource.   They must not be interpreted by URN resolution services, and 
the query and fragment parts of a URN need to be stripped before feeding 
a URN to a resolution service.

Furthermore, more text is needed to explain that even though a URN 
without a query or fragment is a persistent name (has a persistent 
binding to whatever it was originally associated with), there is no 
assurance of persistence for a URN that has a query or fragment portion.

Keith

> 4.3.  Query Component and Fragment Identifier Component
>
>     The URI specification [RFC3986] allows a query component, a fragment
>     identifier component, or both after the path component of a URI,
>     where the character '?' is used as a separator to denote the
>     beginning of the query component and the character '#' is used as a
>     separator to denote the beginning of the fragment identifier
>     component.  The original URN syntax specification [RFC2141] reserved
>     the '?' and '#' characters for future developments.  This
>     specification aligns URN syntax with URI syntax by allowing the query
>     component and fragment identifier component after (not within) the
>     Namespace Specific String (NSS).
>
>     This specification does not define the applicability and semantics of
>     the query component or the fragment identifier component in URNs.
>     Additional specifications might establish these matters for URN-
>     related services (such as resolution) or for individual URN
>     namespaces.  For example, it is possible that the query component
>     might be used in requests to URN resolution services, or that the
>     fragment identifier component might be used to distinguish the
>     integral parts of resources named by URNs.  However, defining such
>     usage is left to specifications for URN resolution services,
>     namespace registration requests and specifications for individual
>     namespaces (which might use some namespace-specific syntax instead of
>     the URI fragment identifier component), and other appropriate
>     documentation (such as policy documents governing the management of a
>     given URN namespace).
>
>     Although URN assignment is often a managed process (see
>     [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]), the query component or
>     fragment identifier component can be appended after the NSS once a
>     URN has been assigned in accordance with the rules for a given
>     namespace.
>

---

From: John C Klensin <[email-masked]>
Date: Sat, 17 Aug 2013 21:55:59 -0400

--On Saturday, 17 August, 2013 17:26 -0400 Keith Moore
<[email-masked]> wrote:

> It is a Very Bad Idea to allow queries and fragments in URNs
> and not define what they mean.  This will lead to conflicts in
> interpretation of queries and/or fragments between different
> resolution services and/or different namespaces (and perhaps
> also different user interfaces) which will then result in
> inconsistent handling of URNs containing queries and/or
> fragments.

To a certain extent, that is inherent in URIs and, more
important, in the notion that different namespaces may actually
be different.

> The only interpretation of queries and fragments that is at
> all consistent with RFC 3986, and still makes sense for URNs,
> is for queries and fragments to be evaluated entirely in the
> context of the referenced resource.   They must not be
> interpreted by URN resolution services, and the query and
> fragment parts of a URN need to be stripped before feeding a
> URN to a resolution service.

Ok to the first.  I think you will find that a requirement for
"stripped before feeding to a resolution service" would simply
be ignored in some cases.  As with other things, I'll rather
explain why some behavior is dangerous and/or provide
alternatives than say "don't do this because we said so".  The
latter merely encourages non-conformance if some namespace
defining both or users decide that they have a requirement.

> Furthermore, more text is needed to explain that even though a
> URN without a query or fragment is a persistent name (has a
> persistent binding to whatever it was originally associated
> with), there is no assurance of persistence for a URN that has
> a query or fragment portion.

I have no problem in principle with more text of that type.

best,
   john

---

From: Keith Moore <[email-masked]>
Date: Sat, 17 Aug 2013 22:14:35 -0400

> important, in the notion that different namespaces may actually

I disagree that this is inherent, though there are certainly other URIs 
that have misused query syntax.   And I certainly don't think it's 
desirable for client code to have to know the particulars of how each 
URN namespace treats fragments and queries.

> be ignored in some cases.
As long as the resolution service ignores the fragment and/or query, it 
won't break anything.   But we really do want a consistent meaning for 
URNs across different clients, which means that client handling of URNs 
containing fragments and/or queries needs to be uniform from one client 
to the next.

Of course, any client implementation is free to violate the 
specifications, we don't have a police force, etc.   But if we don't 
even write our specifications in such a way as to promote 
interoperability, that's a failure on our part.

> As with other things, I'll rather

How about "Don't do this because if you do you'll be violating the 
design principle that URNs mean the same thing everywhere"?

Keith

---

From: "Svensson, Lars" <[email-masked]>
Date: Sun, 18 Aug 2013 02:21:23 +0000

> > consistent with RFC 3986, and still makes sense for URNs, is for
> > queries and fragments to be evaluated entirely in the
> > interpreted by URN resolution services, and the query and fragment
> > parts of a URN need to be stripped before feeding a URN to a
> > resolution service.
> 
> Ok to the first.  I think you will find that a requirement for "stripped before
> feeding to a resolution service" would simply be ignored in some cases. 

I think that if RFC 2616 can mandate that the fragment portion of an http URI is stripped of before sending it to an http server (and implementers seem to accept that) it should be possible to mandate that fragment and query are stripped before sending the URI to a resolution service.

/Lars

---

From: Keith Moore <[email-masked]>
Date: Sat, 17 Aug 2013 22:28:06 -0400

> I think that if RFC 2616 can mandate that the fragment portion of an http URI is stripped of before sending it to an http server (and implementers seem to accept that) it should be possible to mand…

There are actually three issues here that I can identify:

1. Consistent interpretation of URNs.  Even though there's no assurance 
of persistence, a URN with a fragment or a query should still mean the 
same thing no matter where it's being used.

2. Potential conflict between clients, resolution services, and 
resources about what any particular query string or fragment means.   If 
a resource implements a query engine that accepts arbitrary strings, and 
the resolution service also interprets certain kinds of queries as 
indicators that the resolution service should produce a different 
result, there's a conflict that's not easily resolved.

3. Consistent handling of URNs by clients from one namespace to the 
next.    We accept that different namespaces will probably have 
different resolution services.   But we'd like for clients to be able to 
handle those differences by looking up resolution services in DNS or 
some other distributed database, rather than forcing clients to know 
about the particulars of every specific URN namespace and (in this 
particular example) how that namespace interprets fragments.

Keith

---

From: Pekka Järveläinen <[email-masked]>
Date: Mon, 19 Aug 2013 09:47:02 +0300

I have reviewed this document thoroughly and it looks good.

Pekka 

> -------- Original Message -------- 
>                           Subject: 
> [urn] Working Group Last Call of
> draft-ietf-urnbis-rfc2141bis-urn-06.txt
>                              Date: 
> Tue, 13 Aug 2013 15:33:25 -0400
>                              From: 
> Andrew Newton <[email-masked]>
> To: 
> [email-masked] <[email-masked]>
> 
> 
> All,
> 

-- 
Pekka Järveläinen             CSC - IT Center for Science Ltd.
+358 9 457 2467               P.O. BOX 405, FI-02101 Espoo, Finland
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 19 Aug 2013 15:48:50 -0600

On 8/17/13 8:21 PM, Svensson, Lars wrote:
>>> queries and fragments to be evaluated entirely in the context of
>>> the referenced resource.   They must not be interpreted by URN
>>> resolution services, and the query and fragment parts of a URN
>>> need to be stripped before feeding a URN to a resolution
>>> service.
>> 
>> "stripped before feeding to a resolution service" would simply be
>> ignored in some cases.
> 
> I think that if RFC 2616 can mandate that the fragment portion of an
> http URI is stripped of before sending it to an http server (and
> implementers seem to accept that) it should be possible to mandate
> that fragment and query are stripped before sending the URI to a
> resolution service.

As I understand it, so far the only use case envisioned for query
components (and perhaps also fragment identifier components) is exactly
that of passing additional information to a URN resolution service. So I
agree with John that people who really want this feature will ignore
whatever the spec might say.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 19 Aug 2013 15:54:43 -0600

> whatever the spec might say.

Correction: they will ignore any hard prohibition on using query
components and fragment identifier components in that way.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Keith Moore <[email-masked]>
Date: Mon, 19 Aug 2013 18:51:07 -0400

On 08/19/2013 05:48 PM, Peter Saint-Andre wrote:
> that of passing additional information to a URN resolution service.

Why aren't

a) Being able to submit a query to the referenced resource (if that
resource accepts queries), or
b) Being able to reference a fragment of a named resource

valid use cases?

>  So I
I don't see how that follows at all.   It makes no sense to me whatsoever.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 19 Aug 2013 18:52:07 -0400

> components and fragment identifier components in that way.
The most that the standard can do is explain to people why this is a bad
idea.  But that's easy to do.  If people want to build resolution
servers that break URNs, I don't pretend that we can stop them.

Keith

---

From: Juha Hakala <[email-masked]>
Date: Wed, 28 Aug 2013 14:37:13 +0300

Hello,

>>>> whatever the spec might say.
Yes, it is my intention to specify in rfc2483bis a query syntax for 
sending resolution service related requests to URN resolvers. If we do 
not provide such a syntax, there will be a lot of mutually incompatible 
local solutions for how to use query in this manner, even if rfc2141bis 
tries to forbid or disencourage the use of query.

Alfred Hoenes and myself have started the query specification in 
rfc2141bis-urn-03.  Our idea was to use the service names from RFC 2483, 
and to complement them with service related parameters; for instance, 
having just I2C (URI to URC) is not sufficient in the situation where 
there are multiple metadata formats.
>> components and fragment identifier components in that way.
Yes, it would be very difficult to convince the URN users why they 
should not use query, especially when other persistent identifiers are 
using them already.

> servers that break URNs, I don't pretend that we can stop them.
The most that the standard can do is to help people in using query in a 
useful manner. I don't think that it is our task to tell people why they 
should not do something that is allowed elsewhere. And we should not 
write standards in such a way that the users cannot utilize features 
such as query which are likely to be useful for them.

As an aside, this is not the first time there is a need to use query to 
pass service requests. Information retrieval systems use SRU protocol 
(http://www.loc.gov/standards/sru/) for sending queries to remote 
systems like this:

http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=dinosaur&maximumRecords=1&recordSchema=dc

In comparison, the planned use of query in the URN context should be 
relatively simple. But the URN resolvers may need to get smarter. For 
instance, if I want a resource description instead of the resource 
itself, the URN resolver may need to extract the required data elements 
from the URN query into an SRU searchRetrieve URL (if the target system 
prefers SRU to URN queries).

Juha

---

From: "Svensson, Lars" <[email-masked]>
Date: Wed, 28 Aug 2013 14:12:42 +0000

Juha, All,

On Mittwoch, 28. August 2013 13:37, Juha wrote:
> >>>> components (and perhaps also fragment identifier components) is
> >>>> exactly that of passing additional information to a URN resolution
> >>>> service. So I agree with John that people who really want this
> >>>> feature will ignore whatever the spec might say.
> Yes, it is my intention to specify in rfc2483bis a query syntax for sending
> resolution service related requests to URN resolvers. If we do not provide
> such a syntax, there will be a lot of mutually incompatible local solutions for
> how to use query in this manner, even if rfc2141bis tries to forbid or
> disencourage the use of query.

I probably misunderstand how the resolution service and the urn work together, but this is my understanding:

1) I have a resolution service at http://resolver.example.com/.
2) To that service I pass the URN urn:example:something?here=is&a=query#withFragment.
3) In order to tell the service that I want the default URL for the URN I tell the service s=I2L (service = URI to URL). I encode that in a query.

The urn already has a query that has no meaning for the resolver. In order to make the resolver ignore that query (and the fragment), I need to percent-encode the characters '?', '&',  '=' and '#' when passing them on to the resolver. Then I can add the query targeted at the resolver, which gives me

http://resolver.example.com/urn:example:something%3Fhere%3Dis%26a%3Dquery%23withFragment?s=I2L

Then I get a resource back and can apply the query on that resource and the fragment to the answer to that query. Do I understand that correctly?

> Alfred Hoenes and myself have started the query specification in rfc2141bis-
> urn-03.  Our idea was to use the service names from RFC 2483, and to
> complement them with service related parameters; for instance, having just
> I2C (URI to URC) is not sufficient in the situation where there are multiple
> metadata formats.

A side note: is URC formally defined anywhere?

> Yes, it would be very difficult to convince the URN users why they should not
> use query, especially when other persistent identifiers are using them
> already.
> 
> > The most that the standard can do is explain to people why this is a
> > bad idea.  But that's easy to do.  If people want to build resolution
> The most that the standard can do is to help people in using query in a useful
> manner. I don't think that it is our task to tell people why they should not do
> something that is allowed elsewhere. And we should not write standards in
> such a way that the users cannot utilize features such as query which are
> likely to be useful for them.
> 
> As an aside, this is not the first time there is a need to use query to pass
> service requests. Information retrieval systems use SRU protocol
> (http://www.loc.gov/standards/sru/) for sending queries to remote systems
> like this:
> 
> http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&
> query=dinosaur&maximumRecords=1&recordSchema=dc

Yes, and the question (to me) still is if the query attached to the urn is to be applied to the resource identified by that urn or if it is supposed to pass information on to a (http-based) resolution service.
> instance, if I want a resource description instead of the resource itself, the
> URN resolver may need to extract the required data elements from the URN
> query into an SRU searchRetrieve URL (if the target system prefers SRU to
> URN queries).
> 
> Juha
> 

Lars

---

From: Juha Hakala <[email-masked]>
Date: Thu, 29 Aug 2013 09:07:17 +0300

Hello Lars; all,

> I probably misunderstand how the resolution service and the urn work together, but this is my understanding:
The problem we are facing is that currently the URN resolution services 
are too simple. Just mapping URNs to single or multiple URLs is not 
enough, because the user requirements are more complex, and we have an 
increasingly rich technical infrastructure which can supply various 
things for users.

I doubt if anybody understands all the specifics, but at least we have 
some examples of how things might work out.

> Then I get a resource back and can apply the query on that resource and the fragment to the answer to that query. Do I understand that correctly?
It seems to me that you make things a lot more complicated than they 
need to be.

Let us assume that a user wants bibliographic information about a 
resource in Dublin Core format. The user does not know where to get it, 
but the user interface she is using gives an opportunity to request 
metadata about the resource, instead of the thing itself.

If the identifier of the resource (which happens to be an e-book) is 
ISBN 978-952-60-5254-0, we get HTTP URI

http://urn.fi/URN:ISBN:978-952-60-5254-0

which, since there is no query, the resolution service will map into the 
default value of URL

https://aaltodoc.aalto.fi/handle/123456789/10927

from where the user can access to document.

However, if the user wants metadata about the resource, the HTTP URI 
above would be something like

http://urn.fi/URN:ISBN:978-952-60-5254-0?I2C&recordSchema=dc

Please note that there is no point to combine query and fragment unless 
you want the resource itself.

At this point, the URN resolver must know a bibliographic database which 
is capable of fulfilling this request and how to interact with that 
system. Assuming that the URN resolver decides to pass the request to 
the Finnish national bibliography which supports SRU protocol, the HTTP 
URI needs to be migrated into an SRU query which will look something 
like this:

http://fennica.linneanet.fi:7090/voyager?version=1.1&operation=searchRetrieve&
query=9789526052540&maximumRecords=1&recordSchema=dc

This SRU search should return the metadata record the user wants, in the 
form her user interface can deal with. In practice, when we specify 
I2C-related parameters for query, it is necessary to take the existing 
search protocols such as Z39.50, SRU and Opensearch into account.

Migrating the URN + query into a form the interface in the target system 
will understand is not rocket science if these target systems support 
standard APIs. Of course, when technology changes the URN resolver must 
be updated; if for instance the Finnish national bibliography changes 
location, goes from Voyager to some other library system or starts to 
support SRU 1.2 it is necessary to tweak the I2C-related parameters in 
the resolver. Or, when the national library's digital archive goes live, 
we need to add that as a new target system into the resolver and specify 
the services that system will be able to supply, such as providing the 
most original version of the resource.

> A side note: is URC formally defined anywhere?
As far as I know, it is neither used nor properly defined. IMO at 
present Dublin Core has the role that URC was supposed to fulfill. 
However, from I2C point of view the key thing is that no single metadata 
format will ever meet everybody's needs. Some people will be happy with 
simple bibliographic record in DC, some others may want the full record 
in MARC or ONIX, and still others technical metadata in MIX or 
preservation metadata in PREMIS.
>>>> Yes, and the question (to me) still is if the query attached to the urn is to be applied to the resource identified by that urn or if it is supposed to pass information on to a (http-based) reso…
My take on this is that the query will pass information to the 
resolution service, but the resolution service will use that information 
to facilitate retrieval of something that applies to the identified 
resource.

Unlike query, fragment will be applied to the resource by the web 
browser or other tool the end user is utilizing. I would rather avoid 
the complications which may arise if we use the query for passing 
resolution related information both to the resolver and to the user 
interface application.

Juha

-- 

  Juha Hakala
  Senior advisor