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

[[e-mail]]

Hello,

A few comments below.

Quoting "Leslie Daigle" <[e-mail]>:

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

Yes, that is the idea.

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

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.

> For example, you might get a PDF back instead of HTML, and then your  
> 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).

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

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

> For myself, this doesn't make the case that the URN syntax can be  
> 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.

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

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  
> namespace in question

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
>
> Leslie.
>
>
>
> On 3/11/12 9:05 PM, [e-mail] wrote:
>>
>> 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
>>
>> _______________________________________________
>> urn mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/urn
>
> -- 
>
> -------------------------------------------------------------------
> "Reality:
>      Yours to discover."
>                                 -- ThinkingCat
> Leslie Daigle
> [e-mail]
> -------------------------------------------------------------------
> _______________________________________________
> urn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/urn
>