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

[Leslie Daigle <[e-mail]>]

I'm just going to follow up 2 points for now:

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

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

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

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.



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

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, [e-mail] wrote:
> 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
>>
>
>

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[e-mail]
-------------------------------------------------------------------