- From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
- Date: Wed, 07 Jan 1998 14:22:29 -0500 (EST)
- To: fielding@kiwi.ics.uci.edu
- Cc: uri@bunyip.com, urn-ietf@bunyip.com
"Roy T. Fielding" <fielding@kiwi.ics.uci.edu> 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 delimiter). Fote ========================================================================= Foteos Macrides Worcester Foundation for Biomedical Research MACRIDES@SCI.WFBR.EDU 222 Maple Avenue, Shrewsbury, MA 01545 =========================================================================
Received on Wednesday, 7 January 1998 14:29:48 UTC