Keith Moore | 17 Jun 2013 07:03

several different proposals for URN syntax to include fragments and queries

I've attached a plain text document to this message that outlines 
several different proposals for URN syntax to include fragments and 
queries.   This is a result of brainstorming to see how many different 
ways I could think of to compromise between the different competing 
concerns of which I'm aware.    I like some of these ideas better than 
others, but I don't have a strong favorite at the moment.   Some of them 
are mentioned just for completeness, to make it easier to compare those 
proposals with others that are (IMO) more refined.

(I hope everyone can read this without much difficulty.  I didn't want 
to put it in the message body because I've seen too many cases where 
mail readers screwed things up in presentation and/or reply, nor (for 
various reasons) did I want to publish this as an internet-draft (at 
least not yet).)

What I'm hoping is that this list can be narrowed down into a small 
number of candidates, or at least provide some concrete examples for 
discussion.

Keith

What follows is a list of several distinct proposals for how to adapt
URN syntax to accommmodate query strings and/or fragment IDs.   This
list is a result of some personal brainstorming about the different
ways to do this given some conflicting goals, e.g.:

- Desire to retain the meaning of urn: as 'persistent identifier', or
  at least to be able to distinguish persistent identifiers from those
(Continue reading)

John C Klensin | 13 Jun 2013 23:17

Thoughts on fragments, queries, and new URN namespaces

Hi.

I've been trying to watch this WG from a safe distance and not
comment in order to avoid repeating arguments from the original
URN design discussions or the more recent 2141 versus 3986 one.
But a review of the correspondence of the last several weeks has
convinced me that a few important principles are getting lost in
the shuffle.

So, some thoughts.  This note may turn out to be long.  If so
consider the text length averaged over the last few years.   

Summary:  While I believe that fragment identifiers on URNs are
architecturally difficult and unattractive and queries even more
so, I think prohibiting them is a mistake on interoperability
grounds. I think we can also extrapolate from other things that
have gone on with the Internet to conclude, however sadly, that
having the IETF try to either hold up or deny registration of
URN namespaces on aesthetic grounds or to assert authority over
namespaces for which it has no real knowledge will only lead to
the use of unregistered namespace names and the consequent
interoperability problems.

Details:

In an ideal world, URNs would point to atomic objects.    If
chapters of books are the relevant atomic objects, then URNs
should identify those chapters with some sort of aggregate URN
associated with the book and reflecting the chapter URNs, rather
than having a book URN and fragments or queries to identify the
(Continue reading)

John C Klensin | 13 Jun 2013 12:00

Re: 2141bis: abstract and intro

--Keith Moore wrote:

> I'm not sure that the errata system even existed until several
> years after 3986 came out.   But basically there were a set of
> people who weren't well plugged into IETF who didn't think
> that URNs should exist, and the text about URNs in 3986 was
> written to promote that view.  So if you wonder why 3986 is
> inconsistent with 2141, that's why.  3986 was written in part
> to try to undermine 2141.

Keith,

I'm no fan of 3986 (and far less a fan of 3987).  I loathe
fragment identifiers in particular.   But 3986 managed to get
approved as a full Internet Standard.  There are, as Peter
points out, no errata that support your point of view -- even if
the errata system didn't exist in its present form then, it does
now.  More important, there are no published RFCs, or, as far as
I can tell, even expired I-Ds, that summarize the history and
counterarguments or even provide a "use of URIs as specified in
3986 that were not permitted in 2141 considered harmful"
argument.

That combination creates an extremely strong presumption that
3987 describes a community consensus, regardless of you taste
(or mine) and of our concerns about how that consensus was
arrived at.

If you don't like it, you know better than most what to do about
it:
(Continue reading)

Peter Saint-Andre | 11 Jun 2013 06:16
Favicon

2141bis: abstract and intro


While reading RFC 3986 and RFC 3305 recently, I noticed that RFC 2141
contains some archaic language, which 2141bis inherits. Therefore I
propose the following changes...

OLD
   A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI)
   that is intended to serve as a persistent, location-independent
   resource identifier.  The general class of URNs is differentiated
   from all other URIs through the use of the 'urn' URI scheme.  This
   document defines the canonical syntax for URNs, guidelines for URN
   namespaces, requirements for URN presentation and transmission, and
   methods for determining URN equivalence.  This document obsoletes RFC
   2141.

NEW
   A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI)
   that is intended to serve as a persistent, location-independent
   resource identifier.  Historically, the term "URN" has referred to
   both URIs under the "urn" scheme and to any other URIs with the
   properties of a name.  This document defines the canonical syntax for
   URIs under the "urn" scheme, guidelines for URN namespaces,
   requirements for URN presentation and transmission, and methods for
   determining URN equivalence.  This document obsoletes RFC 2141.

Peter

--

-- 
Peter Saint-Andre
https://stpeter.im/
(Continue reading)

Michael Mealling | 30 May 2013 16:20

Re: Queries in URNs

(Yes, I'm eavesdropping…)

That language needs to be much clearer when it uses "part of" and "append to". What is being suggested is that
you can include a query string along with a URN that you can then send to the resource but that DOES NOT make
that query string part of the URN itself. It is a separate thing. There is no 'query part' to a URN. You can
carry around a bag of characters with the URN that you send to the resource, and you can even specify a syntax
for how you carry them around together, but the query string is still something that is evaluated by the Resource.

So be very very careful about language such as "part of" or "URN with". URNs stand alone.

-MM

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

On May 30, 2013, at 10:11 AM, "Svensson, Lars" <L.Svensson <at> dnb.de> wrote:
> This specification adds no syntactical restriction on queries as parts of URNs other than those
specified in RFC 3986. When a query is appended to the URN, the query is transmitted to the resource named by
the URN.
> 
> The exact semantics of the query part of the URN depends on the type of the resource the URN identifies and is
beyond the scope of this specification. It should be noted -- however -- that queries are not meaningful
for all resource types and not compatible with all access protocols; the exact meaning of a query can only
be determined when those two are known. As an example, urn:isbn:0-123-45678-9?page=12 might be
meaningful if urn:isbn:0-123-45678-9 resolves to a web page at
http://example.com/isbn/0-123-45678-9 and that http resource is a service that can handle queries (in
which case page 12 might be displayed). If -- however -- urn:isbn:0-123-45678-9 identifies a PDF
(Continue reading)

Svensson, Lars | 23 May 2013 14:47
Picon

Queries in URNs (was: AW: URN fragments)

All,

I revive this thread about queries in URNs again since we need a resolution on this in order to proceed with
standardization in other (bibliographic) areas [1].

SHORT VERSION

I propose the following:

1) We do not allow queries in URNs, since they only make sense in the context of URN resolution services.
2) We defer the question of how to handle queries in resolution services to RFC2483bis.

If someone can give me a compelling case for the use of queries in URNs *outside* of URN resolution services,
I'd be most happy to discuss that and to withdraw my proposal.

LONGER VERSION

Starting point was the question, if adding a query to a URN creates a new resource or not and if the query is
part of the URN or not:

[Julian]
> > > It's up to the URN or NIS syntax to describe what the query part
> > > means, and how it applies to different namespaces. But in *general*,
> > > adding a query part to a URI changes the resource being identified.

Even if it doesn't change the resource, at least it identifies another (primary) resource (as opposed to
fragment, where adding a fragment makes it a different identifier while still identifying the same
primary resource).

[Juha]
(Continue reading)

Julian Reschke | 22 May 2013 17:52
Picon
Picon

registry format

Hi there,

looking at 
<http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml>:

1) It has a "value" column (and it is sorted by "value"). What is this 
good for?

2) It mixes lowercase and uppercase NIS notations, where the NIS is 
supposed to be case-insensitive, right?

Should I notify IANA?

Best regards, Julian
Julian Reschke | 8 Mar 2013 12:45
Picon
Picon

draft-saintandre-urn-example-03

Hi,

I was looking for discussion about draft-saintandre-urn-example-03 
(which is in status "publication requested"), but almost everything I 
could find on the mailing list were unrelated discussions (about what 
type of resources URNs should be used for).

If anybody is disagreeing to the introduction of the "example" 
namespace, please speak up.

Best regards, Julian
Andrew Allen | 8 Mar 2013 12:44
Favicon

draft-montemurro-gsma-imei-urn-13 defining a URN namespace for the GSMA and sub namespace for the IMEI

 

The following revised draft was submitted a few weeks ago.

 

http://www.ietf.org/id/draft-montemurro-gsma-imei-urn-13.txt

 

 

the abstract is as follows:

 

   This specification defines a Uniform Resource Name namespace for the

   GSMA (GSM Association)and a sub-namespace for the IMEI (International

   Mobile station Equipment Identity), and associated parameter for the

   IMEISV (International Mobile station Equipment Identity and Software

   Version number).  The IMEI is 15 decimal digits long and the IMEISV

   is 16 decimal digits long and both are encoded using Binary Encoded

   Decimal (BCD).  The IMEI and IMEISV were introduced as part of the

   specification for Global System for Mobile communications(GSM) and

   are also now incorporated by the 3rd Generation Partnership Project

   (3GPP) as part of the 3GPP specification for GSM, the Universal

   Mobile Telecommunications System (UMTS) and 3GPP LTE (Long Term

   Evolution).  The IMEI and IMEISV are used to uniquely identify Mobile

   Equipment within these systems and are managed by the GSMA.

 

 

Review of this draft by the URN experts is requested.

 

This internet draft is a dependency for 3GPP work.

 

Thank you

Andrew Allen

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________
urn mailing list
urn <at> ietf.org
https://www.ietf.org/mailman/listinfo/urn
Juha Hakala | 21 Feb 2013 12:36
Picon
Picon

URN fragments

Hello Peter; all, Concerning this:
Could you also explain (perhaps in a separate thread) the intended use of the fragment identifier?
It took a while before the bibliographic community got a sufficient grasp of how fragment can best be used in the URN context. Initially we thought that fragment should be part of the URN namespace specific string, but we realized soon that that would complicate things a lot. Since many (most, probably) standard namespaces do not allow add-ons to identifier strings, this: Ex. 1 http://urn.fi/URN:ISBN:978-952-10-7670-1 would have been possible, but not this (NOTE: this is only an example) Ex. 2 http://urn.fi/URN:ISBN:978-952-10-7670-1#chapter2 Moreover, adding a fragment to an existing URN would in this case have been an act of identifier assignment, which in some namespaces is a managed process, so too few people would have been allowed to use fragments with URNs. Eventually Alfred Hoenes, myself and others concluded that the best solution is to separate identification & URN assignment from fragment assignment, that is, not to include fragment in the NSS. Which means that fragments can be added to the URN by anybody, any time after the URN has been assigned and the document made available (via URN resolution) in the Internet. Then a typical use case is a scientist who wants to cite a structured (and identified) resource. For instance, citation to chapter 2 of the book with ISBN 978-952-10-7670-1 could now be done with the HTTP URI in Example 2 above. Of course, using fragment is only possible if the URN is actionable, supports resolution to the resource and the file format of that resource supports fragment in the spirit of RFC 3986. There are a lot of if's here, but this infrastructure is maintained by a national library / archive, service is likely to persist for quite some time. As an aside, standard guidelines for citing & referencing are out of date. When PIDs are not assigned to start with, people have to use URLs when citing networked resources. In some cases URLs are used even if there is a resolvable PID. Most of us have probably seen 5 -10 year old documents in which most URL links in the reference list are already dead. This will make it very difficult to confirm that citing and referencing has been made correctly, or that the cited document has ever even existed. It is important to improve the situation by using PIDs such as URNs and DOIs, and by providing guidelines on how to use them in citing & referencing. When fragment usage was last discussed on the list, the IETF community disapproved of the idea (if I remember correctly) on the basis that URNs will not be bound to a single manifestation of a resource, such as a PDF version of a book. When the file format changes, the probability that the fragment no longer works is too close for comfort to 1. There are two responses to this. The obvious one is that if the fragment is not part of the URN itself (but just tells the browser a location where to go within the identified resource) the URN will nevertheless still be valid, and the user will get a modernized version of the resource. The other one, with which the bibliographic community did not get anywhere, was that there are namespaces where identifiers must be assigned separately for each manifestation of a resource. ISBN is an example of this, and although some publishers do misuse the system, the vast majority of ISBNs have been correctly assigned - which means that we have a good reason to believe that fragments would work fine longer than the browsers are able to cope with the ancient file formats. Guaranteeing access to original versions of resources, or digital archaeology, may well keep the memory institutions busy in the future... There may of course exist namespaces where fragments cannot be used. There are identifier systems for immaterial works (libraries do make a difference between the original english version of "Hamlet"; its expressions in other languages, and physical manifestations of these). There are identifiers for names, collections, metadata elements, and so on. These identifiers do not have URN namespace registrations yet, but such registrations can be made in the future. Therefore namespace registrations should say whether fragment usage is applicable at least in theory. In the same way, they could provide examples of resolution services that can be supported. Even if the IETF URN syntax specification would not say anything about the usage of fragment, the Finnish standard will. Given that RFC 3986 specifies fragment usage and all popular browsers support this functionality, it is more or less certain that people start using fragments with URNs (expressed as HTTP URIs) when e.g. citing documents. If guidelines for doing this are given in RFCs or other standards, it will be easier to co-ordinate and perhaps even foster this process, and to renew for instance ISO 690, the standard for bibliographic referencing (http://en.wikipedia.org/wiki/ISO_690). Best regards, Juha -- Juha Hakala Senior advisor The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503) FIN-00014 Helsinki University tel +358 9 191 44293
_______________________________________________
urn mailing list
urn <at> ietf.org
https://www.ietf.org/mailman/listinfo/urn
Peter Saint-Andre | 21 Feb 2013 05:49
Favicon

query component in URNs


In the interest of moving forward with rfc2141bis and with my document
editor hat on, I've been reviewing list discussions and earlier
document versions so that we can be clear about open issues.

Because the fragment identifier issue is quite large and has received
a lot of discussion, I've decided to focus first on the issue of query
components in URNs.

Juha Hakala mentioned the topic in late 2010:

https://www.ietf.org/mail-archive/web/urn/current/msg01485.html

"From the PersID point of view, both <query> and <fragment> are
vitally important. We support the idea of reserving <query> for the
transfer of service parameters as a part of the resolution process."

In March 2011, Juha again mentioned query components:

https://www.ietf.org/mail-archive/web/urn/current/msg01507.html

"As regards the URN syntax, the key issue - at least from my point of
view - that should be discussed more widely is the usage of <fragment>
and <query> in the way suggested in RFC2141bis. The reason why it is
vital to make firm decisions concerning these features is that there
are projects that intend to use both of them, and must have explicit
permission and guidelines for doing that."

Martin Duerst pointed out that nothing is really stopping us from
allowing query components:

https://www.ietf.org/mail-archive/web/urn/current/msg01510.html

"That's quite different from the query part; if the urn spec wants to
allow a "?" and some following stuff, it can do so, and it can put on
the syntactic restrictions (as long as they are within the bounds of
the URI spec) and semantic restrictions the WG deems appropriate."

Although I don't claim to fully understand the proposed use of query
components in URNs, it appears to be something that could be supported
in, say, an HTTP-based resolution service. Thus a URN of
urn:isbn:978-951-1-25645-8 could be resolved over HTTP:

http://resolver.example.com/urn:isbn:978-951-1-25645-8?param=value

However, that would not necessitate adding query components to URNs
themselves. This appears to be consistent with something that Juha
sent in August of 2011:

https://www.ietf.org/mail-archive/web/urn/current/msg01574.html

"The reason why URN:ISBN namespace does not allow fragments has to do
with ISBN syntax. This is OK:

http://urn.fi/URN:ISBN:978-952-10-7060-0

but I am not allowed to add anything to the namespace specific string
even if the media type in which this book is published would allow
that. Of course, adding <query> would be OK since it would not be part
of the identifier. "

And:

https://www.ietf.org/mail-archive/web/urn/current/msg01582.html

"According to the RFC2141bis, fragment ID - if we allow its use in the
URN syntax - will be part of the identifier. An identifier which
consists of and ISBN and a fragment no longer identifies the book as a
whole but a component part of it. Whereas ISBN with <query> still
identifies the book as a whole; the role of the <query> is to specify
the resolution service the user wants."

The issue arose again in December of 2011:

https://www.ietf.org/mail-archive/web/urn/current/msg01665.html

"No, I was just emphasizing the point that if we piggyback service
parameters in <query> they will not be part of the URN itself.
Whenever there are fundamental changes in technology, the URN itself
remains the same, but the service parameters may be encoded differently."

Confusingly (at least to me), in March of 2012 Juha made the following
statement:

https://www.ietf.org/mail-archive/web/urn/current/msg01735.html

"As an aside, rfc3187bis is still out of date in the sense that it
assumes (erroneously) that the <fragment> is part of the NSS. If this
were so, you could not use <fragment> in the ISBN namespace since the
ISBN standard does not allow the users to add anything to the ISBN
string. But a construct where ISBN forms the NSS and <fragment> and
<query> may be added to it, gives us free hands. I shall revise the
I-D in this respect in the near future. Such revision requires also
discussions with the International ISBN Agency, since via <fragment>
usage URN:ISBN gains functionality which is not available in the ISBN
itself. "

Notwithstanding that statement, Section 2.3 of
draft-ietf-urnbis-rfc2141bis-urn-03 contained the following text:

   The <query> part MUST NOT be present in any *assigned* URN.  A
   <query> part can only be added to an assigned URN and appear in a URI
   *reference* [RFC3986] to a URN that is intended to be used with URN
   resolution services, and, in the spirit of the general specification
   of this part in RFC 3986, its purpose is restricted to indicate the
   requested URN resolution service and particular service aspects of
   the intended resolution response, e.g., the kind of metadata or
   content sought that are bound to a given object identified by the
   basic, assigned URN.

I draw two conclusions:

1. A query component would not be needed to provide a persistent,
location-independent identifer for, say, an ISBN resource like
978-951-1-25645-8.

2. Aside from a possibly ambiguous statement from Juha, no one has
proposed that we modify the URN syntax to allow query components in URNs.

Unless someone objects, I shall consider this issue closed.

Peter

--

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


Gmane