- From: Martin Duerst <duerst@w3.org>
- Date: Sun, 29 Aug 2004 15:23:42 +0900
- To: Roy T.Fielding <fielding@gbiv.com>, uri@w3.org
Hello Roy - Do you have a version of rfc2396bis that incorporates the changes below hanging around somewhere? Thanks, Martin. At 17:54 04/08/27 -0700, Roy T.Fielding wrote: >A request has been made to remove all usage of the term relative-URI >from the specification, now listed as issue 046-lc-edit-relative-URI. > >The following patch will make that change to draft-06.xml. In spite of >its length, the change remains IMHO editorial in nature. If you do >not think it is allowable in the author's 48 hours of modifications >prior to RFC publication, or if you disagree with the patch, or if >you feel that this level of churn isn't worth it just to satisfy >confusion, then please tell us now by replying to this message. > >Cheers, > >Roy T. Fielding <http://roy.gbiv.com/> >Chief Scientist, Day Software <http://www.day.com/> > >Index: rfc2396bis.xml >=================================================================== >RCS file: /home/cvs/ietf-uri/rev-2002/rfc2396bis.xml,v >retrieving revision 1.121 >diff -u -r1.121 rfc2396bis.xml >--- rfc2396bis.xml 17 Jul 2004 22:26:41 -0000 1.121 >+++ rfc2396bis.xml 28 Aug 2004 00:42:16 -0000 >@@ -470,8 +470,8 @@ > <iref item="relative" primary="true"/> > <t> > It is often the case that a group or "tree" of documents has been >-constructed to serve a common purpose, wherein the vast majority of URIs >-in these documents point to resources within the tree rather than >+constructed to serve a common purpose, wherein the vast majority of URI >+references in these documents point to resources within the tree rather than > outside of it. Similarly, documents located at a particular site are > much more likely to refer to other resources at that site than to > resources at remote sites. >@@ -484,7 +484,7 @@ > changing any of the relative references. > </t> > <t> >-A relative URI reference (<xref target="relative-uri"/>) refers to a >+A relative reference (<xref target="relative-ref"/>) refers to a > resource by describing the difference within a hierarchical name space > between the reference context and the target URI. The reference resolution > algorithm, presented in <xref target="reference-resolution"/>, defines >@@ -1158,8 +1158,8 @@ > either be empty or begin with a slash ("/") character. > If a URI does not contain an authority component, then > the path cannot begin with two slash characters ("//"). >-In addition, a URI reference (<xref target="uri-reference"/>) may begin >-with a relative path, in which case the first path segment cannot >+In addition, a URI reference (<xref target="uri-reference"/>) may be >+a relative-path reference, in which case the first path segment cannot > contain a colon (":") character. The ABNF requires five separate rules > to disambiguate these cases, only one of which will match the path > substring within a given URI reference. We use the generic term >@@ -1208,8 +1208,8 @@ > <t> > The path segments "." and "..", also known as dot-segments, are defined for > relative reference within the path name hierarchy. >-They are intended for use at the beginning of a relative path reference >-(<xref target="relative-uri"/>) for indicating >+They are intended for use at the beginning of a relative-path reference >+(<xref target="relative-ref"/>) for indicating > relative position within the hierarchical tree of names. This is similar > to their role within some operating systems' file directory structure to > indicate the current directory and parent directory, respectively. >@@ -1356,13 +1356,13 @@ > resource identifier. > <iref item="URI grammar" subitem="URI-reference" primary="true"/> > <iref item="URI grammar" subitem="URI" primary="false"/> >-<iref item="URI grammar" subitem="relative-URI" primary="false"/> >+<iref item="URI grammar" subitem="relative-ref" primary="false"/> > </preamble><artwork type="abnf"> >- URI-reference = URI / relative-URI >+ URI-reference = URI / relative-ref > </artwork><postamble> >-A URI-reference may be relative: >-if the reference's prefix matches the syntax of a scheme followed by >-its colon separator, then the reference is a URI rather than a relative-URI. >+A URI-reference is either a URI or a relative reference. >+If the URI-reference's prefix does not match the syntax of a scheme followed >+by its colon separator, then the URI-reference is a relative reference. > </postamble></figure> > <t> > A URI-reference is typically parsed first into the five URI components, >@@ -1377,20 +1377,20 @@ > </t> > </section> > >-<section title="Relative URI" anchor="relative-uri"> >-<iref item="relative-URI" primary="true"/> >+<section title="Relative Reference" anchor="relative-ref"> >+<iref item="relative-ref" primary="true"/> > <iref item="network-path" primary="true"/> > <iref item="absolute-path" primary="true"/> > <iref item="relative-path" primary="true"/> > <figure><preamble> >-A relative URI reference takes advantage of the hierarchical syntax >-(<xref target="hierarchical"/>) in order to express a reference that is >+A relative reference takes advantage of the hierarchical syntax >+(<xref target="hierarchical"/>) in order to express a URI reference > relative to the name space of another hierarchical URI. >-<iref item="URI grammar" subitem="relative-URI" primary="true"/> >+<iref item="URI grammar" subitem="relative-ref" primary="true"/> > <iref item="URI grammar" subitem="query" primary="false"/> > <iref item="URI grammar" subitem="fragment" primary="false"/> > </preamble><artwork type="abnf"> >- relative-URI = relative-part [ "?" query ] [ "#" fragment ] >+ relative-ref = relative-part [ "?" query ] [ "#" fragment ] > > relative-part = "//" authority path-abempty > / path-absolute >@@ -1493,7 +1493,7 @@ > <xref target="RFC1535"/>. > </t> > <t> >-Since a URI suffix has the same syntax as a relative path reference, a >+Since a URI suffix has the same syntax as a relative-path reference, a > suffix reference cannot be used in contexts where a relative reference > is expected. As a result, suffix references are limited to those places > where > there is no defined base URI, such as dialog boxes and off-line > advertisements. >@@ -1508,7 +1508,7 @@ > <t> > This section defines the process of resolving a URI reference within > a context that allows relative references, such that the result is a >-string matching the "URI" syntax rule of <xref target="components"/>. >+string matching the <URI> syntax rule of <xref target="components"/>. > </t> > > <section title="Establishing a Base URI" anchor="base-uri"> >@@ -1860,7 +1860,7 @@ > http://a/b/c/d;p?q > </artwork></figure> > <t> >-a relative URI reference is transformed to its target URI as follows. >+a relative reference is transformed to its target URI as follows. > </t> > > <section title="Normal Examples" anchor="relative-normal"> >@@ -1899,7 +1899,8 @@ > </t> > <t> > Parsers must be careful in handling cases where there are more >-relative path ".." segments than there are hierarchical levels in the >+".." segments in a relative-path reference than there are hierarchical >+levels in the > base URI's path. Note that the ".." syntax cannot be used to change > the authority component of a URI. > </t> >@@ -1921,7 +1922,7 @@ > "..g" = "http://a/b/c/..g" > </artwork></figure> > <t> >-Less likely are cases where the relative URI reference uses unnecessary or >+Less likely are cases where the relative reference uses unnecessary or > nonsensical forms of the "." and ".." complete path segments. > </t> > <figure><artwork> >@@ -1934,7 +1935,7 @@ > </artwork></figure> > <t> > Some applications fail to separate the reference's query and/or >-fragment components from a relative path before merging it with >+fragment components from the path component before merging it with > the base path and removing dot-segments. This error is rarely noticed, > since typical usage of a fragment never includes the hierarchy ("/") > character, and the query component is not normally used within >@@ -1947,7 +1948,7 @@ > "g#s/../x" = "http://a/b/c/g#s/../x" > </artwork></figure> > <t> >-Some parsers allow the scheme name to be present in a relative URI >reference if >+Some parsers allow the scheme name to be present in a relative reference if > it is the same as the base URI scheme. This is considered to be a > loophole in prior specifications of partial URI <xref target="RFC1630"/>. > Its use should be avoided, but is allowed for backward compatibility. >@@ -2007,7 +2008,7 @@ > </t> > <t> > In testing for equivalence, applications should not directly compare >-relative URI references; the references should be converted to their >+relative references; the references should be converted to their > target URI forms before comparison. When URIs are being compared > for the purpose of selecting (or avoiding) a network action, such as > retrieval of a representation, the fragment components (if any) should >@@ -2194,7 +2195,7 @@ > <t>Always provide the host, if any, in lowercase characters.</t> > <t>Only perform percent-encoding where it is essential.</t> > <t>Always use uppercase A-through-F characters when percent-encoding.</t> >- <t>Prevent dot-segments appearing in non-relative URI paths.</t> >+ <t>Prevent dot-segments from appearing in paths.</t> > <t>For schemes that define a default authority, use an empty authority > if the default is desired.</t> > <t>For schemes that define an empty path to be equivalent to a path >@@ -3084,11 +3085,11 @@ > / path-rootless > / path-empty > >- URI-reference = URI / relative-URI >+ URI-reference = URI / relative-ref > > absolute-URI = scheme ":" hier-part [ "?" query ] > >- relative-URI = relative-part [ "?" query ] [ "#" fragment ] >+ relative-ref = relative-part [ "?" query ] [ "#" fragment ] > > relative-part = "//" authority path-abempty > / path-absolute >@@ -3315,7 +3316,7 @@ > and discussion within the W3C Technical Architecture Group. > </t> > <t> >-An ABNF rule for URI has been introduced to correspond to the >+An ABNF rule for URI has been introduced to correspond to one > common usage of the term: an absolute URI with optional fragment. > </t> > </section> >@@ -3349,19 +3350,21 @@ > abs_path, rel_path, path_segments, rel_segment, and mark rules. > All references to "opaque" URIs have been replaced with a better > description of how the path component may be opaque to hierarchy. >+The relativeURI rule has been replaced with relative-ref to avoid >+unnecessary confusion over whether or not they are a subset of URI. > The ambiguity regarding the parsing of URI-reference as a URI or a >-relative-URI with a colon in the first segment has been eliminated >+relative-ref with a colon in the first segment has been eliminated > through the use of five separate path matching rules. > </t> > <t> > The fragment identifier has been moved back into the section on >-generic syntax components and within the URI and relative-URI >+generic syntax components and within the URI and relative-ref > rules, though it remains excluded from absolute-URI. > The number sign ("#") character has been moved back to the reserved set > as a result of reintegrating the fragment syntax. > </t> > <t> >-The ABNF has been corrected to allow a relative path to be empty. >+The ABNF has been corrected to allow the path component to be empty. > This also allows an absolute-URI to consist of nothing after the "scheme:", > as is present in practice with the "dav:" namespace <xref target="RFC2518"/> > and the "about:" scheme used internally by many WWW browser implementations. >
Received on Sunday, 29 August 2004 06:33:11 UTC