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

From: "Sam Sun" <[email-masked]>
Date: Thu, 8 Jan 1998 16:57:39 -0500

>> > Sam Sun wrote:
>> > > In the case of URL, The " [ "#" fragment ] " is only used or useful
by some
>> > > URL schemes. So my question is: is it acceptable to say that the
fragment
>> > > is scheme dependent, and don't bring it up in the URI definition?
>>
>> Dan Said:
>> > No; that is, to say that is not consistent with current
>> > implementations, and I would find it unacceptable.
>>
>> The current implementation (eg. Netscape browser) append the "#fragment"
to
>> whatever the base URI is. I don't quite understand on where it would be
inconsistent?
>
>Uh... you said it yourself: "whatever the base URI is" regardless
>of scheme.
>

The point I wanted to show you is that "# fragment" doesn't work by itself.
It's actually worked as a relative URL. And the generic URI parser may never
get the "# fragment" alone. (ie, in your example, the <a href="#foo"> ... is
a relative URL, not just a "# fragment".)

On the other hand, I don't see any usage of "# fragment" for "mailto" or
"ldap" URLs as defined in the HTML document. So, if "# fragment" is not
needed for all of the URI schemes, I wonder if we could drop it from the
overall URI definition?

[ ......lots of cutting.......]
>> In fact, using %25 to replace the '#' character will fail.
>
>That seems like a bug to me. But I suppose Draft Standard
>is the time to describe what happens rather than prescribe
>something else.
[ ......lots of cutting.......]

To me, there are two ways to look at whether it's a bug or not.

>From the existing standard point of view, it could be a bug, if the standard
spelled it out explicitly. But from the user's point of view, it's a nice
feature. (I feel that hex encoding can be very annoying to the user.) But if
the URI Syntax is to become a new standard, maybe we can loose it a little
bit so that new URI schemes can be defined for different kinds of user need.

Lastly, I'm wondering if the "# fragment" requirement is inherited from the
earlier URL standards when there're few URL schemes defined. If we drop the
requirement of "# fragment" from URI as a whole, it can still be defined by
those URL schemes that need it, in their respective RFCs. And the only thing
I see broken is that the generic URI parser can not catch the "#fragment",
and decide what to do, which is not happening and I think really doesn't
have to.

Regards,
Sam

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 22 Jan 1998 21:33:57 -0800

[reposted, since the uri lists were down last week]

>a relative URL, not just a "# fragment".)

I seem to be having a hard time getting this point across.  The generic
URI parser *is* the thing that takes a string and does the handling
and interpretation needed to

   1) determine whether it is absolute or relative
   2) convert it to absolute form if needed
   3) give the resulting URI to the scheme-specific handler

There is no purpose for a generic URI syntax beyond that.  Likewise,
it is only that syntax which is needed by other protocols as a
Draft Standard reference.

>needed for all of the URI schemes, I wonder if we could drop it from the

Because you cannot do so and produce an interoperable parser.

>and decide what to do, which is not happening and I think really doesn't

The "#fragment" is removed from the URI whether the URI is defined
to use it or not.  I cannot show you this using Netscape Navigator
because its parser is the only one I know of which is so hopelessly
broken that they use a fixed set of scheme names.  Other applications
allow the user to pass unknown URI schemes to a proxy for resolution,
and on those systems you will find that the "#fragment" is stripped
before being sent to the proxy.  It is therefore IMPOSSIBLE for "#"
to be used as anything else in the URI syntax and still retain
interoperability between new and deployed systems.

There is very little room for discussion of what is being defined by
the specification and in the syntax itself, since that is governed by
the most interoperable subset of what is implemented.  The only question
still to be determined is whether we call these things URI or URL,
and thus whether or not a URN should be referred to as a URI or a URL
when it is used by HTTP, HTML, XML, etc.

.....Roy