- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Fri, 27 Aug 2004 17:54:45 -0700
- To: uri@w3.org
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 Saturday, 28 August 2004 00:54:24 UTC