Subject: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-02.txt

From: [email-masked]
Date: Sun, 11 Mar 2012 18:05:53 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF.

	Title           : Uniform Resource Name (URN) Syntax
	Author(s)       : Alfred Hoenes
	Filename        : draft-ietf-urnbis-rfc2141bis-urn-02.txt
	Pages           : 32
	Date            : 2012-03-11

   Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers.  This document serves as
   the foundation of the 'urn' URI Scheme according to RFC 3986 and sets
   forward the canonical syntax for URNs, which subdivides URNs into
   "namespaces".  A discussion of both existing legacy and new
   namespaces and requirements for URN presentation and transmission are
   presented.  Finally, there is a discussion of URN equivalence and how
   to determine it.  This document supersedes RFC 2141.

   The requirements and procedures for URN Namespace registration
   documents are set forth in BCP 66, for which RFC 3406bis is the
   companion revised specification document replacing RFC 3406.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-urnbis-rfc2141bis-urn-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-urnbis-rfc2141bis-urn-02.txt

---

From: Leslie Daigle <[email-masked]>
Date: Sun, 25 Mar 2012 09:00:16 -0400

Hi,

I am having troubles reconciling this use of fragments with RFC3986, the 
URI syntax document.

My understanding of RFC3986 suggests that fragments are strictly and 
uniquely tied to media, and thus would be applied to the results of a 
URN resolution, irrespective of namespace.

So, if you have <urn>#<fragment>, you resolve <urn> and apply <fragment> 
in whatever way makes sense for the media type of what you got back.

The issue with doing that with URNs is:  they are designed to be 
flexible enough to support multiple types of response -- the URN does 
not designate a type.

For example, you might get a PDF back instead of HTML, and then your 
HTML #<fragment> will be pointless.

Even if you say (as the document currently does) that fragments are 
allowed only on a per-namespace basis, I am concerned that the resulting 
URN namespaces would have to be severely limited in terms of URN 
functionality:  you are essentially saying that those namespaces must be 
architected such that they only ever return single media type responses, 
or responses for which the fragments will make sense across all 
supported types.  That is very constraining on the namespace, and the 
use of URNs, IMO.

For myself, this doesn't make the case that the URN syntax can be 
updated to allow the use of fragment identifiers.

And, if the consensus winds up being that this does make the case to 
allow that, I would further argue that the text describing the 
per-namespace use considerations would need

1/  a very thorough review by URI experts to make sure it actually would 
hold water,

2/ to be clear about the constraints it puts on the overall URN 
namespace in question

3/ to be in a separate document all on its own, because it is severely 
distracting from a document that is meant to be the description of the 
syntax of URNs in general.

Leslie.

On 3/11/12 9:05 PM, [email-masked] wrote:
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: [email-masked]
Date: Mon, 26 Mar 2012 09:46:34 +0300

Hello,

A few comments below.

Quoting "Leslie Daigle" <[email-masked]>:

>
> Hi,
>
> I am having troubles reconciling this use of fragments with RFC3986,  
> the URI syntax document.
>
> uniquely tied to media, and thus would be applied to the results of  
> a URN resolution, irrespective of namespace.
>
> So, if you have <urn>#<fragment>, you resolve <urn> and apply  
> <fragment> in whatever way makes sense for the media type of what  
> you got back.

Yes, that is the idea.

> flexible enough to support multiple types of response -- the URN  
> does not designate a type.

URN in general does not, but there are identifier systems which do.  
One example of this is ISBN (International Standard Book Number). It  
is important for everyone involved in the business - publishers, book  
stores, customers - that books can be identified in this level. If I  
purchase a book in EPUB 3 format, I certainly don't want a PDF version  
of it. Different manifestations often have different look and feel,  
and eventually probably also different intellectual content. This is  
why at least my community prefers to identify each media type  
separately.

> HTML #<fragment> will be pointless.

With URN:ISBN this would not happen, since a book published in PDF  
format will have another ISBN than the book in HTML format (provided  
that the publisher is using the ISBN system correctly). So it makes  
sense to attach a <fragment> to a URN based on ISBN. In the other  
hand, ISTC (International Standard Text Code) identifies a book as an  
immaterial work, and can be used to support retrieval of any  
manifestation of the book. In the case of ISTC we definitely have the  
problem you describe above; it makes absolutely no sense to attach a  
fragment to URNs from the ISTC namespace (which has not been  
registered yet).

> allowed only on a per-namespace basis, I am concerned that the  
> resulting URN namespaces would have to be severely limited in terms  
> of URN functionality:  you are essentially saying that those  
> namespaces must be architected such that they only ever return  
> single media type responses, or responses for which the fragments  
> will make sense across all supported types.  That is very  
> constraining on the namespace, and the use of URNs, IMO.

If the namespace is a priori constrained to single media type  
responses, there is no problem. I don't know how many of the existing  
namespaces have been designed in this way, but both namespaces I have  
been closely involved with (ISBN and NBN) can support fragments  
(provided that the fragment is not part of the NSS).

> updated to allow the use of fragment identifiers.

Fragments certainly cannot be applied in all URN namespaces. But, as  
ISBN indicates, allowing the fragment use will provide additional  
functionality to those namespaces where identifying each manifestation  
of a resource separately is a norm.

> 1/  a very thorough review by URI experts to make sure it actually  
> would hold water,

There was quite a lot of discussion on the list about this in the  
past. The outcome of that discussion is reflected in the current drafts.

> 2/ to be clear about the constraints it puts on the overall URN  

These constraints can be summarized by saying that if the identifier  
system does not require that each manifestation of a resource (say,  
PDF, EPUB 3 or HTML version of a book) receives its own identifier,  
<fragment> MUST NOT be applied. For such namespaces, using <fragment>  
does not make any additional constraints beyond those the identifier  
standard itself has already imposed.

> 3/ to be in a separate document all on its own, because it is  
> severely distracting from a document that is meant to be the  
> description of the syntax of URNs in general.

We should be able to describe the circumstances in which it is OK to  
use <fragment> clearly. If we succeed in this, discussion of this  
functionality will not distract the readers.

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.

Best regards,

Juha
>> A New Internet-Draft is available from the on-line Internet-Drafts  
>> directories. This draft is a work item of the Uniform Resource  
>> Names, Revised Working Group of the IETF.
>>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 26 Mar 2012 16:25:16 +0900

Hello Leslie,

On 2012/03/25 22:00, Leslie Daigle wrote:
> The issue with doing that with URNs is: they are designed to be flexible
> enough to support multiple types of response -- the URN does not
> designate a type.
>
> supported types.

Could this be relaxed to "responses for which there is a commitment that 
the fragments, if interpretable, are interpreted consistenly"? This 
would not exclude media types where a fragment identifier doesn't make 
sense, but would, if implemented diligently, produce consistency across 
all those media types where fragment identifiers make sense.

Regards,    Martin.

> That is very constraining on the namespace, and the use
> of URNs, IMO.
>
>> directories. This draft is a work item of the Uniform Resource Names,
>> Revised Working Group of the IETF.
>>

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 26 Mar 2012 03:55:37 -0400

> URN in general does not, but there are identifier systems which do.

But this is the general URN syntax.  So we should have a syntax that 
supports the general URN, not other identifier systems.

 > that the publisher is using the ISBN system correctly).

Your parenthetical remark is key:  historicaly experience suggests that 
there is little reason to expect they will.  Just looking at the number 
of ISBNs assigned to teddy bears in gift shops, for example.

 > There was quite a lot of discussion on the list about this in the past.
 > The outcome of that discussion is reflected in the current drafts.

I'm not sure that you caught that I said URI experts, there.  Not the 
URNbis WG mailing list.

Leslie.

On 3/26/12 2:46 AM, [email-masked] wrote:
>> <fragment> in whatever way makes sense for the media type of what you
>> got back.
>
> Yes, that is the idea.
>
> URN in general does not, but there are identifier systems which do. One
> example of this is ISBN (International Standard Book Number). It is
> important for everyone involved in the business - publishers, book
> of it. Different manifestations often have different look and feel, and
> eventually probably also different intellectual content. This is why at
> least my community prefers to identify each media type separately.
>
> sense to attach a <fragment> to a URN based on ISBN. In the other hand,
> ISTC (International Standard Text Code) identifies a book as an
> fragment to URNs from the ISTC namespace (which has not been registered
> yet).
>
>> resulting URN namespaces would have to be severely limited in terms of
>> URN functionality: you are essentially saying that those namespaces
>> must be architected such that they only ever return single media type
>> responses, or responses for which the fragments will make sense across
>> all supported types. That is very constraining on the namespace, and
>> the use of URNs, IMO.
>
> If the namespace is a priori constrained to single media type responses,
> there is no problem. I don't know how many of the existing namespaces
> have been designed in this way, but both namespaces I have been closely
> involved with (ISBN and NBN) can support fragments (provided that the
> fragment is not part of the NSS).
>
> There was quite a lot of discussion on the list about this in the past.
> The outcome of that discussion is reflected in the current drafts.
>
> system does not require that each manifestation of a resource (say, PDF,
> EPUB 3 or HTML version of a book) receives its own identifier,
> We should be able to describe the circumstances in which it is OK to use
> <fragment> clearly. If we succeed in this, discussion of this
> <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

--

---

From: [email-masked]
Date: Mon, 26 Mar 2012 13:52:27 +0300

Hello,

> supports the general URN, not other identifier systems.

I am not sure what you mean by the general URN. URN system consists of  
namespaces, which establish their own rules as regards what kind of  
resources they identify and how. There are technical requirements that  
must apply to all the namespaces, but many things must be left to the  
namespace level, use of fragment being one of them.

> Your parenthetical remark is key:  historicaly experience suggests  
> that there is little reason to expect they will.  Just looking at  
> the number of ISBNs assigned to teddy bears in gift shops, for  
> example.

Any identifier system can be misused and alas, ISBN is no exception.  
More alarming than those teddy bears (which got an ISBN so that they  
could be entered into a sales system which required ISBNs) is the  
emerging trend that some publishers especially in the USA would prefer  
to give the same ISBN to all manifestations of a book. However, as a  
rule the ISBN system works well.

When writing rfc2141bis and namespace registrations we should build  
upon the identifier standards and established practices on how to  
apply them, and not on the possibility that someone does not know how  
to implement the standard (or makes a decision to deviate from it on  
purpose).
> I'm not sure that you caught that I said URI experts, there.  Not  
> the URNbis WG mailing list.

OK. Such review is of course welcome. And we need also feedback from  
some identifier communities who may benefit from the <fragment> use.

Best regards,

Juha

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 27 Mar 2012 11:38:47 -0400

Hi Martin,

In-line...

> all those media types where fragment identifiers make sense.

I'm really not sure what this means, in practice.

And, I find myself wondering:  what's the _specified_ behaviour when a 
fragment reference cannot be resolved (by the client)?

Leslie.

--

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 28 Mar 2012 13:51:03 +0900

Hello Leslie,

> I'm really not sure what this means, in practice.

Okay. Assume as an example that the resource can be served as HTML, as 
SVG, and as PDF, and that the last one doesn't allow fragment 
identifiers (that could be wrong, now or in the future). Then what this 
would mean is that one and the same fragment identifier would identify 
one and the same thing (chapter, paragraph, figure, whatever) in both 
the HTML and the SVG version. It's definitely possible to make this 
work, although it's of course also possible to mess this up.

> fragment reference cannot be resolved (by the client)?

A fragment identifier identifies a secondary resource, so if that 
doesn't work, all we know about is the resource. I don't think there's a 
spec for this, but I'd assume that most clients would resolve to the 
resource and then give up. And 'give up' would usually place the user at 
the top of the document.

Actually, I think RFC 3986 is pretty close to what I'm suggesting (third 
paragraph of http://tools.ietf.org/html/rfc3986#section-3.5):

                                                             If the
    primary resource has multiple representations, as is often the case
    for resources whose representation is selected based on attributes of
    the retrieval request (a.k.a., content negotiation), then whatever is
    identified by the fragment should be consistent across all of those
    representations.  Each representation should either define the
    fragment so that it corresponds to the same secondary resource,
    regardless of how it is represented, or should leave the fragment
    undefined (i.e., not found).

So I think I agree with you the URN spec shouldn't mess around with 
fragment identifiers, and that individual URN namespaces also should not 
mess around with fragment identifiers. The only thing these specs may 
want to do is to point to RFC 3986.

Regards,    Martin.

---

From: Juha Hakala <[email-masked]>
Date: Wed, 28 Mar 2012 09:28:53 +0300

Hello,

A few comments below.

> work, although it's of course also possible to mess this up.

The URN namespaces in which I consider it is safe to use <fragment> are 
those and only those which will always assign separate identifiers to 
the different (HTML, SVG, PDF and so on) representations / versions / 
manifestations of the resource. In these namespaces it is never 
necessary to investigate if the <fragment> might work correctly with 
different manifestations of the resource.

Of course these identifier systems also require that if the intellectual 
content of the resource changes (which may have an impact on fragments) 
even if the file format does not change, a new identifier must be assigned.

As Leslie has pointed, it is possible that these identifier systems 
(ISBNs, NBNs, etc.) can be misused. But IMHO we should not drop useful 
functionality from URN docs only because some people (a minority ot all 
users) abuse knowingly or unknowingly identifier systems like ISBN.

As regards identifiers which are not representation-specific: although 
it is possible that different manifestations of the resource have the 
same internal structure now, there is no way we can guarantee this 10 or 
100 years from now. Therefore, if we have an identifier which 
encompasses several or all manifestations of a resource such as 
International Standard Text Code (ISTC), I would never recommend the use 
of <fragment> with it.

You may wonder where the persistence comes from if the URNs are tied to 
a particular representation of a resource. The idea the national 
libraries are considering is that the most persistent thing related to 
the resource is the description of it as immaterial work; a metadata 
record which will have its own URN. All the representations of the work 
will be linked to this record, so the user can pick for instance the 
eldest representation (most authentic, but hard to utilize without 
specialised rendering application) or the newest one (easy to use, but 
with altered look and feel).

It might be useful to discuss somewhere how national libraries and other 
institutions which are involved with the long term (meaning centuries) 
preservation of digital resources intend to do this, and how we plan to 
use URNs  in this work.

> resource and then give up. And 'give up' would usually place the user at 

This sounds like a sensible way of solving the problems which occur when 
the client cannot find the correct place within the resource, or when it 
cannot interprete the <fragment>.
> want to do is to point to RFC 3986.

This is pretty much what we have been trying to do in the URNbis I-Ds. 
But given that URNs are persistent, we have to make it clear that it is 
only safe to use <fragment> if the URN is tied to a single 
representation / manifestation / etc. of the resource.

Juha

-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email [email-masked], tel +358 50 382 7678