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

Hello Leslie,

On 2012/03/25 22:00, Leslie Daigle wrote:
>
> 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.

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.
>
> 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, internet-drafts@ietf.org 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
>> urn@ietf.org
>> https://www.ietf.org/mailman/listinfo/urn
>