Subject: [urn] Finalizing items from IETF 83

From: Andy Newton <[email-masked]>
Date: Tue, 26 Jun 2012 12:10:28 -0400

All,

There are two items that surfaced during the URNBIS working group meeting in Paris (IETF 83) which I should have explicitly noted on this mailing list but neglected to do so. That is my fault.

The first item was brought forward in the presentations on 2141bis and 3406bis. The editors of these drafts have noted, in these documents, issues they feel are closed. At IETF 83 I asked for a review of these issues by working group participants and for any notes of dissent or inquiries to be sent to this mailing list by April 16. Given this request was never explicitly stated here, I would like to re-invite working group participants to review the 2141bis and 3406bis issues. If possible, I would ask that concerns raised from these reviews be given on this mailing list before July 13.

Second, at IETF 83 Leslie Daigle proposed removing the fragment language from 2141bis and placing it in a separate draft to be moved forward as an Experimental RFC. If you have objections to this approach, please let us know (again, before July 13).

-andy
(obviously over-paid co-chair).

---

From: Juha Hakala <[email-masked]>
Date: Thu, 28 Jun 2012 09:17:44 +0300

Hello,

Concerning this:

> Second, at IETF 83 Leslie Daigle proposed removing the fragment language from 2141bis and placing it in a separate draft to be moved forward as an Experimental RFC. If you have objections to this a…

I have an objection, but the fragment related sections of RFC2141bis 
must be made more clear.

The terms and conditions governing the fragment use are on the one hand 
technical, and on the other hand identifier system dependent. From 
technical point of view, fragments are part of the URI but they are not 
part of the NSS. From identifier system point of view, fragments are 
only applicable when a) the identifier system covers only manifestations 
and b) single manifestation of a resource only gets one identifier, 
which is never re-assigned.

In practice, this means that fragments are not applicable if the 
identifier covers immaterial works (like International Standard Text 
Code). Also, fragments cannot be used if the identifier covers multiple 
manifestations (for instance International Standard Serial Number 
applies to the entire journal). But fragments can be used with e.g. 
ISBNs since each ISBN is assigned to single manifestation of a book, 
such as PDF or XML version.

Since fragment is not part of the namespace specific string, a user who 
for instance wants to cite a certain paragraph of an e-book may add a 
fragment to the existing URN:ISBN of the book in order to provide a 
persistent link to the paragraph (assuming that the e-book is structured 
in such a way that this is possible).

When an e-book is migrated to another file format in order to preserve 
it, then according to the ISBN user guide the new version of the book 
must get another ISBN. Any identifier system which allows identification 
of multiple manifestations with a single identifier is not applicable 
for fragment use.

Depending on what the list attendees agree on, we may place a text to 
the above effect into rfc2141bis or into an experimental document. But I 
hope that RFC2141bis will say at least that fragments are not part of 
the NSS but they can be used in those namespaces which specifically 
allow that.

Best regards,

Juha

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

-- 

  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

---

From: "Svensson, Lars" <[email-masked]>
Date: Thu, 28 Jun 2012 09:42:33 +0000

Juha wrote:

> But
> I hope that RFC2141bis will say at least that fragments are not part of

I'll second that RFC 2141bis says that fragment identifiers are allowed in URNs but that they are not part of the NSS. Further, RFCs for new namespaces must specify if they allow the use of fragment identifiers or not but I guess that is something for RFC 3406bis.

All the best,

Lars

***Lesen. Hören. Wissen. 100 Jahre Deutsche Nationalbibliothek***
***Reading. Listening. Understanding. A century of the German National Library***

-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek / Informationstechnik
http://www.dnb.de/
[email-masked]
http://www.dnb.de/100jahre

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
> Juha Hakala
> Gesendet: Donnerstag, 28. Juni 2012 08:18
> An: [email-masked]
> Betreff: Re: [urn] Finalizing items from IETF 83
> 
> Hello,
> 
> Concerning this:
> 
> > Second, at IETF 83 Leslie Daigle proposed removing the fragment
> language from 2141bis and placing it in a separate draft to be moved
> forward as an Experimental RFC. If you have objections to this
> approach, please let us know (again, before July 13).
> 
> only applicable when a) the identifier system covers only
> manifestations and b) single manifestation of a resource only gets one
> identifier, which is never re-assigned.
> 
> persistent link to the paragraph (assuming that the e-book is
> structured in such a way that this is possible).
> 
> must get another ISBN. Any identifier system which allows
> identification of multiple manifestations with a single identifier is
> not applicable for fragment use.
> 
> the above effect into rfc2141bis or into an experimental document. But
> I hope that RFC2141bis will say at least that fragments are not part of

---

From: Julian Reschke <[email-masked]>
Date: Thu, 28 Jun 2012 12:01:48 +0200

> I'll second that RFC 2141bis says that fragment identifiers are allowed in URNs but that they are not part of the NSS. Further, RFCs for new namespaces must specify if they allow the use of fragmen…

No.

Namespace specifications define the namespace-specific part; nothing 
else. Fragment syntax and semantics are defined by RFC 3986.

A spec *can* point out that the URN does not identify something from 
which a payload + media type can be retrieved, in which fragment 
identifiers are not applicable. But that's different from disallowing them.

Best regards, Julian

---

From: Juha Hakala <[email-masked]>
Date: Thu, 28 Jun 2012 14:52:53 +0300

Hello,

>> I'll second that RFC 2141bis says that fragment identifiers are
>> allowed in URNs but that they are not part of the NSS. Further, RFCs
>> for new namespaces must specify if they allow the use of fragment
>> identifiers or not but I guess that is something for RFC 3406bis.
>
> No.
>

OK. It should be possible to adjust the text in rfc2141bis to say that 
there are namespaces in which fragment usage is not applicable since the 
resources which can be identified within than namespace - say, textual 
works as abstract entities in URN:ISTC - will not have fragments in the 
RFC 3986 sense of the word.

As far as I am concerned, it does no harm if the namespace registration 
request confirms that it is possible to use fragment to augment the 
functionality of the URNs from that particular namespace. For instance, 
I asked a permission from the ISBN Registration Authority to use 
fragments in the URN:ISBN namespace. Since this point will be made in 
the namespace registration request the national ISBN agencies and other 
ISBN users do not need to ask if fragments are allowed. And while some 
examples could be given in the namespace registration request it is 
definitely up to the URI Generic Syntax and other relevant technical 
documents to provide the necessary details for each document format.

All the best,

Juh

-- 

  Juha Hakala

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 29 Jun 2012 19:17:52 +0900

> RFC 3986 sense of the word.

Strictly speaking, that's not true. It's perfectly possible to imagine 
(and even to set up, although that will require quite a bit of 
coordination) to have an identifier for "Much Ado about Nothing" and 
have fragment identifiers e.g. for Act I, II, III, IV, and V. These may 
not work with all resolution systems, or all representations, but that's 
not a problem. If a fragment identifier cannot be resolved, we just get 
the whole work. The only problem is when a fragment identifier leads to 
obviously different pieces in different representations (e.g. Act I in 
an XML representation and Act V in a mobi representation,...).

All this isn't new for URNs, it's exactly the same as for 
content-negotiated HTTP resources (different languages, HTML vs. XML vs. 
SVG vs. JSON vs. RDF, just to name a few).

> ISBN users do not need to ask if fragments are allowed.

Nobody should have to ask. If it works, you can use it. If you can't 
make it work, it's a bad idea.

> And while some

Yes indeed.

Regards,    Martin.

---

From: Jonathan A Rees <[email-masked]>
Date: Fri, 29 Jun 2012 10:00:45 -0400

I think the goal is for URIs of the form urn:x#fragid to also have
URN-like properties, just as urn:x does., i.e. name-like and
persistent. RIght? And this appears to be in conflict with the fact
that the semantics of such URIs is determined by 3986, not by the URI
scheme registration.

I offer (again) the following compromise for your consideration; I
have no dog in this race:

If those registering namespaces want to constrain the semantics of
urn: URIs with fragment identifiers, it would be possible to do so
indirectly, by constraining the possible representations yielded by
URN resolver infrastructure.  E.g. if urn:x#part1 was supposed to name
part 1 of <urn:x>, then the registration could say (or imply) that a
resolver MUST only yield representations in which #part1 names part 1.

Or perhaps it would be OK to yield some representations in which
#part1 did not name anything at all. Then you would say: A resolver
MUST NOT yield a representation in which the semantics of #part1 is
inconsistent with  urn:x#part1 being a name for (whatever). Whether
this would work in one of the many unclear aspects of fragment
identifier semantics (see
http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-05-28.html ).

That is, per 3986, fragment id semantics depends on media types, so if
a spec wants to constrain fragment id semantics, its only option is to
do so indirectly, by constraining the representations to which the URN
resolves.

A weakness of this approach would be differentiating between
persistent fragment identifiers and ephemeral ones. If someone gets a
representation, and discovers a fragment identifier definition inside
it, they will have no way of knowing the persistence commitment of
that fragment identifier.

Best
Jonathan

On Fri, Jun 29, 2012 at 6:17 AM, "Martin J. Dürst"
<[email-masked]> wrote:
> Strictly speaking, that's not true. It's perfectly possible to imagine (and
> even to set up, although that will require quite a bit of coordination) to
> have an identifier for "Much Ado about Nothing" and have fragment
> identifiers e.g. for Act I, II, III, IV, and V. These may not work with all
> resolution systems, or all representations, but that's not a problem. If a
> fragment identifier cannot be resolved, we just get the whole work. The only
> problem is when a fragment identifier leads to obviously different pieces in
> different representations (e.g. Act I in an XML representation and Act V in
> a mobi representation,...).
>
> All this isn't new for URNs, it's exactly the same as for content-negotiated
> HTTP resources (different languages, HTML vs. XML vs. SVG vs. JSON vs. RDF,
> just to name a few).
>
>
>
> Nobody should have to ask. If it works, you can use it. If you can't make it
> work, it's a bad idea.
>
>
>> And while some