Re: [URN] Re: The UR* scheme registry, Citing URL/URI specs

The "#fragment" notation is only used for named components.

A lot of us have, at some point, imagined using it for more: byte ranges,
pages, chapters, hytime designators, etc. However, I've come to the conclusion
that doing so is inappropriate, and we should leave it alone. Client-side
sub-location is likely to be scheme specific.

With that restriction, #fragment works as well for URNs as it does for
URLs -- the creator of the work assigns names to elements that are intended
to be named, and if the work changes enough that the names disappear, well,
it's no different from any other kind of incompatible modification that
could be made.

> My point is that if all of the URL syntax/semantics is to be applied
> to URIs in general, a careful and informed analysis by people who understand
> what _has_ been done in _both_ areas is necessary.  And, I don't see
> that in this discussion. 

I'm willing to assert that I have an 'informed' analysis (as someone who
has read as much mail on the topic of URLs and URNs as anyone else on the
planet). I don't see any reason to *not* claim that a URN is a special
kind of a URL, which, like many other URL schemes, sets its rules for
the syntax & semantics of the scheme-specific part.

> Bear in mind that with URNs you are not referring to a single media
> type -- a single URN _can_ refer to an ascii file, a PS file, a word
> document, a bitmapped image of a page, etc.  You can't even reliably
> define "paragraph", "page", "file". 

Bear in mind that with URLs you are not necessarily referring to a single
media type -- a single URL _can_ refer to an ascii file, a PS file, a word
document, a bitmapped image of a page, etc. It can refer to a page in
French and a page in English, depending on the language preferences of
the person that accessed it. You can't even reliably define "paragraph",
"page", "file". Fortunately, none of those terms are required to be
defined by any of the mechanisms in the URL syntax & semantics.

> What I have seen done with the URL syntax/semantics spec in the past is
> that any feature in it that is described as "optional" then becomes _expected_
> of any "scheme" that falls within its purview.  E.g., people would
> expect retrofitted implementations of "# fragment" semantics to URN identifiers
> because the spec says they _could_.  That's a lot of  baggage that I
> don't see URNs needing to inherit.

So, who expects #fragment to work with "telnet:" URLs? I don't believe
it is reasonable to avoid a design just because someone who hadn't
actually read the spec might guess that it said something that it didn't.

The only constraint the URL document places on URNs is syntactic: don't
use the reserved characters for purposes different than they're used for
in URLs. That is, it assigns semantics to the syntactic characters ("/ means
hierarchy") and that assignment of semantics should be there for URNs too:
don't use "/" for, say, delimiting the authority's private key. That's
a good idea.

I don't see any reason to change draft-fielding-url-syntax-09.txt again,
as what it says is fine as far as it goes.

Larry
--
http://www.parc.xerox.com/masinter

Received on Tuesday, 28 October 1997 14:18:49 UTC