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

From: Foteos Macrides <[email-masked]>
Date: Fri, 23 Jan 1998 19:08:13 -0500 (EST)

"Roy T. Fielding" <[email-masked]> wrote:
>[...]
>Also in section 3:
>
>      fragment      = *uric
>
>which excludes "#" and the other delims from appearing within the fragment.

	Duh...  OK (time to log out and go traveling :).

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 [email-masked]         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

---

From: Foteos Macrides <[email-masked]>
Date: Mon, 26 Jan 1998 15:17:55 -0500 (EST)

Leslie Daigle <[email-masked]> 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.

	I much prefer "Uniform" over "Universal" (URIs won't also
be universal until the i18n provisions are fully worked out and
incorporated :).

	However, to be uniform, I still think URIs must be parsable for
fragment instructions which apply to media types, not to schemes, and
regardless of whether particular schemes might actually have fragments,
i.e., any crosshatch which is not a fragment delimiter should be escaped.

				Fote

---

From: Foteos Macrides <[email-masked]>
Date: Mon, 26 Jan 1998 17:11:33 -0500 (EST)

"John C. Mallery" <[email-masked]> wrote:
>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.

	I perhaps should not have included that paragraph under
circumstances in which I have only occassional access to this account
and cannot participate in an extended discussion about the matter,
but since I'm logged in again now...

	I do not see how these references to "bogus" and "legacy web
applications" serve any useful purpose in the "evolution" of the Web.
The #fragment was specified as a way of providing instructions to a
client via a URI-reference, is positional, and is not considered part
of the URI.  I realize that there are only so many US-ASCII characters
which can be used as delims in a platform-independent manner, and most
if not all of them are "taken" for something or other at this point.
If you which to support server-side instructions, then it presumeably
must be via something to the left of any crosshash in an overall
URI-reference.  The '?' and '@' in URLs in effect delimit instructions
to the server, and perhaps could be used for instructions sets in URNs.

>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 $.

	Fragment instructions apply to media types (presently defined
and widely implemented fragment instructions apply to text/html), not
to schemes, i.e., not specifically to HTTP.

>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.

	The concern is that existing, interoperable implementations
are not broken needlessly in new IETF specs.  Terminology such as
"reify legacy design decisions" is stone throwing, and that often
leads to breakage.

				Fote