Subject: [urn] use of fragment identifiers: issues are same for urn and all urls

From: Larry Masinter <[email-masked]>
Date: Wed, 1 Apr 2015 23:40:24 +0000

For a fragment identifier to be useful, there needs to be some promise.
Using a fragment identifier with any URI (urn: or some other scheme) is done loosely best-effort; if you want a URI with fragment to work over time, you need the expectation that fragment identifiers won’t change.

The URL and URN
http://tools.ietf.org/html/bcp115  and urn:ietf:bcp:115

are both not good URIs to put a #section-3 fragment on, because when an update to BCP 115 is made, Section 3 might be a totally different topic.

The URL and URN
https://tools.ietf.org/html/rfc4395 and urn:ietf:rfc:4395

should both be good for a #section-3 fragment. The latter because there is a credible policy of not messing with  RFCs once they’re published, and section numbers will remain even if RFCs are republished in different formats.

I think being careful in this kind of commitment needs to be part of namespace authority recognition when considering applicability and longevity of fragment identifiers.

Larry
—
http://larry.masinter.net

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 2 Apr 2015 11:21:47 +0900

I fully agree with Larry.

I think it has been explained earlier on this list, but in the case of 
an URI (incl. URN) potentially being resolved to multiple formats (e.g. 
HTML and PDF,...), the considerations apply across formats. If there are 
some formats that don't handle fragment identifiers, then that's best 
seen as part of the "best effort" that Larry mentions below.

Regards,   Martin.

On 2015/04/02 08:40, Larry Masinter wrote:
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn
>

---

From: Keith Moore <[email-masked]>
Date: Wed, 01 Apr 2015 23:14:43 -0400

> Using a fragment identifier with any URI (urn: or some other scheme) is done loosely best-effort; if you want a URI with fragment to work over time, you need the expectation that fragment identifie…

agree.

> are both not good URIs to put a #section-3 fragment on, because when an update to BCP 115 is made, Section 3 might be a totally different topic.

agree.

> should both be good for a #section-3 fragment. The latter because there is a credible policy of not messing with  RFCs once they’re published, and section numbers will remain even if RFCs are repub…

agree.
> I think being careful in this kind of commitment needs to be part of namespace authority recognition when considering applicability and longevity of fragment identifiers.

either that or we explicitly declare that a URN including a fragment 
identifier is not required to be persistent, even though the base URN is 
required to be persistent.   (or as some people phrase it, the fragment 
identifier is not "part of" the URN.)

So I think it comes down to which is more burdensome:
a) a prohibition on assigning a URN to any document that includes 
internal fragment identifiers that aren't stable
b) not having URN + fragment identifier be persistent
?

(or if it's on a per-namespace basis then the default case must be that 
the URN + fragment identifier can't be assumed to be persistent without 
specific knowledge of the namespace.   but if an individual namespace 
wants to impose this additional constraint on the URNs that it assigns, 
it is free to do so.)

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 01 Apr 2015 23:26:12 -0400

> I think being careful in this kind of commitment needs to be part of namespace authority recognition when considering applicability and longevity of fragment identifiers.

The problem is, for some period of time:
a) Both of the above URNs refer to the same document
b) At least one version of the document may contain fragments
c) The ietf namespace doesn't control whether fragments get added to its 
URNs . Anyone can compose a URI consisting of urn:ietf:bcp:115 and a 
fragment identifier from rfc 4395, and it will work in the near term.

So if IETF wants to make its (URN + fragment identifier) combinations 
persistent, it has two choices:
a) don't assign BCP URNs
b) don't put fragment identifiers in any version of its documents

Neither choice seems very attractive.

Keith

---

From: Larry Masinter <[email-masked]>
Date: Sat, 4 Apr 2015 17:36:30 +0000

>b) don't put fragment identifiers in any version of its documents

there’s another choice:

URN resolution of urn:ietf:bcp:35 (BCP 115 was assigned in error, RFC 4395 is both BCP 35 and 115) doesn’t have to resolve to a document. It could resolve to a landing page with metadata, which handled fragments like #section-3 with scripting.  

URNs are useful without resolution or network accessibility of the “resource" — it lets you define a protocol slot which takes EITHER a URL or URN. No resolution per se is needed.

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Apr 2015 11:45:52 -0400

A few comments on this thread beyond those issues that Keith and
Martin have addressed...

--On Wednesday, April 01, 2015 23:40 +0000 Larry Masinter
<[email-masked]> wrote:

> For a fragment identifier to be useful, there needs to be some
> promise. Using a fragment identifier with any URI (urn: or
> some other scheme) is done loosely best-effort; if you want a
> URI with fragment to work over time, you need the expectation
> that fragment identifiers won't change.
> 
> The URL and URN
> are both not good URIs to put a #section-3 fragment on,
> because when an update to BCP 115 is made, Section 3 might be
> a totally different topic.

A similar comment would apply to 

  http://www.w3.org/TR/fragid-best-practices/#Section-2

would it not?  The URL does not point t0 a single object, but to
a collection of versions, and there is no guarantee that another
version will have the same section numbering.   There is
therefore a case to be made that 

   http://www.w3.org/TR/fragid-best-practices/#Terminology

is better, but, while it is more likely to be stable across
versions than a section number, there are no guarantees about
that either.

And document names sometimes change.  For example, if some
future version of that document were renamed and at 
 
   http://www.w3.org/TR/fragment-best-practices/#Terminology

one could argue that the fragment ID is more stable than the
path.

One could also imagine

    urn:w3c:fragid-best-practices

but it wouldn't add much either substantively or semantically,
with or without a fragment identifier.   

>...
> I think being careful in this kind of commitment needs to be
> part of namespace authority recognition when considering
> applicability and longevity of fragment identifiers.

Sure, but that is where your "expectation" and Martin's "best
efforts" comments come in.  If, given the issues above one can
legitimately write

   http://www.w3.org/TR/fragid-best-practices/#Terminology
and/or
   http://www.w3.org/TR/fragid-best-practices/#Section-2

then it seems to me that it is impossible to claim that 
   http://www.w3.org/TR/fragid-best-practices/#Section-99

is a syntax error.  Whatever handles the object just has to be
prepared to cope with it, just as users need to understand that
the fragment identifiers might identify different material than
what they intended.

Now, if what you are looking for is a statement that, if a
namespace allows fragment (or f-component) with a URN, then the
namespace designers or registrants better be very clear about
what happens to it (and where it is evaluated) and that users
may need to be aware that bad specifications of fragments will
not yield predictable behavior even if the fragments are,
themselves, reasonably stable across whatever the URN might
refer to, I'd be happy with that.  Please send text.

But, if you are looking for guarantees of fragment reliability
or stability that are much stronger than the ones in the
examples above, I think we would have to go into an excursion
about the types of objects that URNs (that resolve to objects or
other identifiers) can point to.  That one is going to be hard
for multiple reasons, especially for network-based resources.
Even for the numbered RFC example, I note that the RFC Editor
had a struggle for years to prevent references to particular
pages in an RFC (rather than section numbers) and that I still
see such references floating around.

   best,
    john

---

From: Keith Moore <[email-masked]>
Date: Mon, 06 Apr 2015 12:23:12 -0400

I think we just need to declare whether URNs that contain f-components 
are persistent, or if only the "assigned" portion of the URN is 
persistent.   To me it does not look like an easy choice.  We'd like to 
be able to have reliable identifiers for portions of a resource, but 
expecting f-components to also be persistent places considerable 
restrictions on what URNs can be assigned to.

One way to look at the question is that since fragment IDs exist 
independent of URNs, and aren't expected to be persistent in ordinary 
use, insisting that the combination of URN and fragment ID be persistent 
is simply unreasonable.   But that's presuming that f-components map 
directly to fragment IDs.

A similar problem exists for paths, for similar reasons.   If in the 
middle of a document there's a link of the form
<A HREF="../xyz/0123">Terminology</A> and a URN is assigned to that 
document, and we expect path-relative references to affect the URN, then 
the namespace or content-maintainer needs to make sure that that path 
always is associated with the Terminology section... something that 
content management systems might not be equipped to do.

---

From: Larry Masinter <[email-masked]>
Date: Wed, 8 Apr 2015 05:40:40 +0000

>see such references floating around.

I don’t think namespace designers or registrants CAN be
“clear" about what happens to it and where it is applied
(“evaluated”) because they have little control over
those things.

Here is some text:
   Namespace designers and registrants might desire to define
   syntax and semantics for f-components, however, in practice,
   URI/IRI/URL processing typically splits the f-component off
   before even looking at the scheme, and then only apply
   fragment processing after the URL has been resolved to
   typed content. There is no place in the data flow for
   a namespace authority to interject any processing to
   ensure longevity of meaning, to allow individual URN
   namespaces to have a namespace-specific interpretation.
   Any namespace designer or registrant attempting to define
   f-component handling for URNs of their namespace MUST 
   specify in Interoperability Considerations how any
   namespace-specific behavior is triggered.

I’m sure you can do better, but perhaps you get the gist.

Larry
—

---

From: "Hakala, Juha E" <[email-masked]>
Date: Tue, 14 Apr 2015 10:40:14 +0000

Hello,

> -----Original Message-----
> From: urn [mailto:[email-masked]] On Behalf Of Keith Moore
> Sent: 2. huhtikuuta 2015 6:26
> To: [email-masked]
> Subject: Re: [urn] use of fragment identifiers: issues are same for urn and all
> urls
> 
> > are both not good URIs to put a #section-3 fragment on, because when an
> update to BCP 115 is made, Section 3 might be a totally different topic.

The problem here is not the use of fragment as such, but naming policy used in urn:ietf namespace. 

It is OK to have an identifier which covers all past and future versions of BCP 115. Such namespace will of course not provide reliable basis for fragment usage, but it can be used to find all versions of the document (and perhaps also related documents, if they are interlinked in metadata records). But there should also be a URN (from another namespace) for each version, so that people who need to refer to a particular version of BCP 115 can do that, and also cite  for instance section 3. Currently, if I want to provide a link to the version which was valid in March 2015 I can use this URI 

https://web.archive.org/web/20150324002113/http://tools.ietf.org/html/bcp115

but it would more convenient to have a version specific URN which resolves to this URL in the Internet Archive (or other places from which the appropriate version can be found).  

> > should both be good for a #section-3 fragment. The latter because there is
> a credible policy of not messing with  RFCs once they’re published, and
> section numbers will remain even if RFCs are republished in different formats.
> > I think being careful in this kind of commitment needs to be part of
> namespace authority recognition when considering applicability and
> longevity of fragment identifiers.

It should not be hard to allocate identifiers for IETF documents in such a way that the users will find what they want. 

> Neither choice seems very attractive.

The best choice is to plan identifier usage so that all the functional requirements can be met. I am sure IETF has solved harder problems than this. But if nothing else helps, ask a librarian ;-).

Juha

---

From: John C Klensin <[email-masked]>
Date: Tue, 14 Apr 2015 11:48:50 -0400

--On Tuesday, April 14, 2015 10:40 +0000 "Hakala, Juha E"
<[email-masked]> wrote:

>> > because when an
> The problem here is not the use of fragment as such, but
> naming policy used in urn:ietf namespace. 
> 
> It is OK to have an identifier which covers all past and
> future versions of BCP 115. Such namespace will of course not
> provide reliable basis for fragment usage, but it can be used
> to find all versions of the document (and perhaps also related
> documents, if they are interlinked in metadata records). But
> there should also be a URN (from another namespace) for each
> version, so that people who need to refer to a particular
> version of BCP 115 can do that, and also cite  for instance
> section 3. Currently, if I want to provide a link to the
> version which was valid in March 2015 I can use this URI 
> 
> but it would more convenient to have a version specific URN
> which resolves to this URL in the Internet Archive (or other
> places from which the appropriate version can be found). 

Of course, we have such an identifier today.  It is 

   urn:ietf:rfc:3999

(assuming a relatively persistent binding between a BCP number
that doesn't identify anything and an RFC number that doesn't
either).  But, for example,
   urn:ietf:bcp:102
refers to an object that may change over time and
   urn:ietf:rfc:4052

refers to the version in effect today.  As with other examples,
fragments applied to the latter are much more likely to be
useful and to match what was intended than fragments that are
applied to the former.

I think one could make persistence arguments that urn:ietf:bcp
should not be allowed at all, but that is an administrative,
registration, and policy matter, not an 2141bis (or 2141 or even
1737) one.  It also involves the same long-standing and much
discussed examples about a URN for the local weather at the
present time.  We aren't going to solve those problems on a
philosophical level even though some conventions and a good
understanding of what is going on will eliminate the practical
issues.

best,
   john