Re: [URN] URI documents -- "# fragment"

John C. Mallery (
Mon, 26 Jan 1998 14:30:25 -0500

Message-Id: <v0313030eb0f292e3264b@[]>
In-Reply-To: <>
Date: Mon, 26 Jan 1998 14:30:25 -0500
To: Leslie Daigle <leslie@Bunyip.Com>
From: "John C. Mallery" <>
Cc: Foteos Macrides <>, uri@Bunyip.Com,
Subject: Re: [URN] URI documents -- "# fragment"

Might be worth noting that #fragment is utterly bogus.  It is a positional identifier
and cannot be recycled for server-side fragments because it has been consumed by legacy web applications.

The only relevance for URIs is that applications expecting to move an identifier through
HTTP URLs (e.g, URN resolution) must quote #. This is why PDI switched from # to $.

It is unwise to reify legacy design decisions in all possible future identifiers.
Such over encumbering of URIs reduces degrees of freedoms needed for evolution and 
shortens the longevity of any URI framework, ie hastening the time when all identifiers
must be discarded and one must start from scratch.

At 12:27 PM -0500 98-01-26, Leslie Daigle wrote:
>On Fri, 23 Jan 1998, Foteos Macrides wrote:
>> 	Note also that RFC 1630 had the title "Universal Resource
>> Identifiers in WWW", i.e., was about URIs, not just URLs, and
>> provides for fragments in URIs.  I agree that if URNs are specified
>> such that they could not accept fragments as "instructions to the
>> client", then they should not be considered URIs, and that would
>> be unacceptible (so don't impose that restriction on URNs :).
>URIs as a whole have evolved considerably since RFC1630 -- not the least
>of which is the fact that they are now "Uniform" and not "Universal"
>Resource Identifiers.  
>My point is this:  be careful of claiming that anything that doesn't
>fit with the earliest specifications is not valid; that prevents evolution
>of design.
>  "_Be_                                           Leslie Daigle
>             where  you                           
>                          _are_."                 Bunyip Information Systems
>                                                  (514) 875-8611
>                      -- ThinkingCat