On 4/28/10 9:35 AM, Julian Reschke wrote:

We could write a rule that says "don't use fragment ids with a URN
unless those fragment ids are meaningful across all representations of
the resources named by the URN."  But I keep seeing examples that

That would be almost the same rule as for any URL^HI.

True.  But we don't expect ordinary URIs to have persistent URI->resource bindings, which is the entire (original) reason for URNs. 
(Despite URNs being widely used today as unique names with no binding to any resource.)

illustrate that people don't understand URNs or how they're to be used,
even though the rules are quite simple.   I suspect that adding more
rules decreases the likelihood that people will use URNs correctly.

But neither do I want to revise 3986 to say that fragment ids don't
apply to URNs.  That's a huge can of worms I'd prefer to leave closed.

So maybe writing the rule is the best way.   Though I have little
confidence that it will be followed.

What we need to do is to clarify that although fragment identifiers aren't particularly useful unless you have representations, the URN *syntax* - being compatible to RFC 3986 - allows them; and thus the hash character needs to be percent-escaped in a URN.

Certainly so if you want the hash character to be part of the base URN itself.

I think it's also necessary to say something about the persistence (or lack thereof) of a URN#fragment -> resource fragment binding.

Keith

_______________________________________________
urn mailing list
urn <at> ietf.org
https://www.ietf.org/mailman/listinfo/urn