Re: [URN] Re: URI documents

Foteos Macrides (
Wed, 07 Jan 1998 14:22:29 -0500 (EST)

Date: Wed, 07 Jan 1998 14:22:29 -0500 (EST)
From: Foteos Macrides <>
Subject: Re: [URN] Re: URI documents
Message-id: <01IS3J5873E0003TJC@SCI.WFBR.EDU>

"Roy T. Fielding" <> wrote:
>If the URN group does not want fragments to be in the syntax, then
>a URN is not a URI.  I don't think there is even a tiny bit of logic
>to support the conclusion that a URN would not use fragments, but I
>can't stop people from shooting themselves in the foot.
>Stripping the URL specification such that it is as meaningless as the
>URN specification is not an option --- we know what is and is not
>generic syntax and semantics simply by looking at the parsers which
>implement these things in current practice.  If a URN is not a URI,
>then we should define the URL specification to represent the complete
>scope of locators, and simply ignore URN.

	For what it's worth, I have yet to read a compelling rationale
in this thread for excluding possible use of fragments with URNs, though
of course they should not be used (for neither URNs nor URLs) if no
application convention has been defined, and at present only two have
been defined (for positioning, and for MAPs, in text/html documents).

	I do think, however, that the current draft needs to clarify
whether more than one unescaped hash ('#') can be present.  The
initial RFCs stated that only one can be present, and only if it
indeed is a fragment delimiter.  That made direction of parsing for
the hash irrelevant, and a number of deployed UAs parse from right
to left.  RFC 1808 and the current draft specify left-to-right parsing,
and do not state that only one, actual fragment delimiter, can be
present.  This understandably has led to the (mis?)interpretation
that additional unescaped hashes can present to the right of a
fragment delimiter, and be used for special purposes (one well
developed suggestion, though not submitted as an IETF draft, sought
to use multiple hashes for specifying components of frame documents).
I do hope this issue will be addressed explicitly before the current
draft is finalized (and my preference is to restore the original
contraint of only one unescaped hash which must be a fragment


 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545