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

From: Foteos Macrides <[email-masked]>
Date: Fri, 23 Jan 1998 16:17:39 -0500 (EST)

"Roy T. Fielding" <[email-masked]> wrote:
>[...] there is already an explicit requirement in the URI
>syntax that there be at most one "#" in a URI reference.  That is
                                           ?????????????
>completely unambiguous and not open to any misunderstanding.
					   
	I must disagree with you that it is completely unambiguous
and not open to any misunderstanding.  Section 2 ("URI Characters and
Escape Sequences") describes the unescaped character restrictions
for "URIs" ("URLs" in the preceding drafts).  It's Section 2.4.3
places crosshatch ('#') in the "delims" group of "Excluded US-ASCII
Characters".  That does make it completely clear that one cannot be
present unescaped in the authinfo field of an ftp or telnet URL, or
anywhere else in an actual URI, to the left of a fragment delimiter.
However, the term "URI-reference" is not defined until Section 3,
which has:

      URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]

and a "plain word explanation" that the fragment is NOT part of the
"URI".  People who are not dummies or fuddy-duddies have argued that
characters allowable in the fragment string (to the right of the '#'
delimiter) are not clearly specified in the URL -> URI drafts
(because they specify what can be in URIs (URLs), and not also in
URI-references (URL-references).  They have also argued that this
is a GOOD THING.  The characters that are allowed/disallowed in
fragments which currently have application conventions are governed
by the HTML/SGML restictions on NAME and ID attribute values.   They
thus cannot have a crosshatch, nor any hex escaped characters
(because '%' is also disallowed in those attribute values).  But
other fragment-handling conventions might be developed as
"instructions to the client", which need not be governed by the
HTML/SGML restrictions on NAME and ID attribute values!!!!

	I therefore feel compelled to insist that a clear statement
of what unescaped characters are allowed in a fragment string be added
in Section 3, and personally feel that another crosshash must be
excluded -- for backward compatibility, because all CERN/W3C libwww
based (except Lynx as of v2.7) and CERN libwww heritage browsers
(including Netscape) parse from right-to-left for a fragment delimiter,
and are tripped up if an unescaped crosshatch which is not the actual
delimiter is present in the fragment string.  To my knowledge, all
deployed browsers first split off the fragment, before actually
parsing the "actual URI".  US-ASCII control character and space
also should be excluded, for obvious reasons, and I have no objection
to excluding others as well, as from "actual URIs" (if that's what
you intend, and think it already does :), but it's debatable whether
exclusion of others is really necessary.

>Perhaps an addition to the "Differences from RFC 1808" section would
>be more appropriate?

	RFC 1808 specified left-to-right parsing, whereas the current
URI draft simply uses left-to-right parsing for its "example parser"
in the Appendix, so that's a change, I guess, but an addition about
that, per se, would not address the larger issue I'm raising.  It
needs to be made clear in Section 3 (or Section 2 must be modified
to make clear that it applies to URI-references, and not just URIs).

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

				Fote

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 23 Jan 1998 14:58:03 -0800

>URI-references (URL-references).

Also in section 3:

      fragment      = *uric

which excludes "#" and the other delims from appearing within the fragment.
People who argue otherwise have not read the specification.  Since this
is almost identical to the definitions in RFCs 1670 and 1808, people who
say it hasn't been clearly specified in the URL -> URI drafts are
just plain wrong.  There is no need for more clarification.

This isn't going to stop people from producing invalid URI.  What to
do when you encounter an invalid URI depends on the application type,
so we don't specify it.

....Roy

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 26 Jan 1998 12:27:07 -0500 (EST)

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

Leslie.

----------------------------------------------------------------------------

  "_Be_                                           Leslie Daigle
             where  you                           
                          _are_."                 Bunyip Information Systems
                                                  (514) 875-8611
                      -- ThinkingCat              [email-masked]
----------------------------------------------------------------------------

---

From: "John C. Mallery" <[email-masked]>
Date: Mon, 26 Jan 1998 14:30:25 -0500

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.

---

From: Larry Masinter <[email-masked]>
Date: Mon, 26 Jan 1998 14:03:24 PST

I meant to post about this before; I think that "?" is the most
appropriate delimeter for what John Mallery wants for PDIs, rather than
"$", since it will be more likely processed correctly when dealing with
relative references that might be contained within returned material.

> Might be worth noting that #fragment is utterly bogus.

It is totally worthless[sic] to attempt to note this.

To put it in less bogus terms: Just because a widely deployed
syntactic construct doesn't do what YOU want, it doesn't mean that
it is "utterly bogus", no matter what school of hyperbole you adhere to.

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

---

From: Al Gilman <[email-masked]>
Date: Mon, 26 Jan 1998 17:25:51 -0500 (EST)

to follow up on what John C. Mallery said:

> 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 can't grok your claim.  The way I interpret current practice
the 'fragment' is not positional at all but reference to a name
in a namespace.  So the client positions the cursor at the start
of the named item which is a text range in this kind of document.
But the URL usage is namewise, not positionwise.

Can you elaborate?

Al Gilman

---

From: "John C. Mallery" <[email-masked]>
Date: Mon, 26 Jan 1998 17:34:51 -0500

>relative references that might be contained within returned material.

No. URNs embedded in URLs will be improperly processed by legacy applications,
not to mention that it overloads the delimiter.

This is analogous to the problem with #.

>it is "utterly bogus", no matter what school of hyperbole you adhere to.

It remains utterly bogus to include it in the URI spec; it's fine in html/http (I use it all the time).

I just get tired of endless thrashing.