W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2006

Editorial fix: uppercasing "Section" in section references

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 24 Apr 2006 15:55:09 +0200
Message-ID: <444CD8BD.8040409@gmx.de>
To: WebDav WG <w3c-dist-auth@w3.org>
Patch, relative to draft-ietf-webdav-rfc2518bis-latest.xml dated April 
18, attached.

Best regards, Julian

diff -u -r1.41 draft-ietf-webdav-rfc2518bis-latest.xml
--- draft-ietf-webdav-rfc2518bis-latest.xml	18 Apr 2006 06:54:02 -0000	1.41
+++ draft-ietf-webdav-rfc2518bis-latest.xml	24 Apr 2006 13:55:03 -0000
@@ -156,11 +156,11 @@
   <t>
    Since this document describes a set of extensions to the HTTP/1.1 
    protocol, the augmented BNF used herein to describe protocol 
-   elements is exactly the same as described in section 2.1 of 
+   elements is exactly the same as described in Section 2.1 of 
    <xref target="RFC2616"/>, including the rules about 
     implied linear white-space.  
    Since this augmented BNF uses the basic production rules provided in 
-   section 2.2 of <xref target="RFC2616"/>, these rules apply to this document as 
+   Section 2.2 of <xref target="RFC2616"/>, these rules apply to this document as 
    well. 
   </t>
   <t>
@@ -1488,7 +1488,7 @@
     </figure>
     
     <t>The absolute-URI, path-absolute and query productions are defined in 
-      section 4.3, 3.3 and 3.4 of <xref target="RFC3986"/>. 
+      Section 4.3, 3.3 and 3.4 of <xref target="RFC3986"/>. 
     </t>
     
     <t>Within Simple-ref productions, senders MUST NOT:
@@ -1548,7 +1548,7 @@
       some interactions may be undefined. 
 
    Note that HTTP 1.1 requires the Date header in all responses if 
-   possible (see section 14.18, <xref target="RFC2616"></xref>). 
+   possible (see Section 14.18, <xref target="RFC2616"></xref>). 
       </t>
     <t>The server MUST do authorization checks before checking any
       HTTP conditional header. </t>
@@ -1605,7 +1605,7 @@
    HTTP and WebDAV did not use the bodies of most error responses for 
    machine-parsable information until DeltaV introduced a mechanism to 
    include more specific information in the body of an error response 
-   (section 1.6 of <xref target="RFC3253"/>). The error body mechanism is 
+   (Section 1.6 of <xref target="RFC3253"/>). The error body mechanism is 
    appropriate to use with 
    any error response that may take a body but does not already have a 
    body defined. The mechanism is particularly appropriate when a 
@@ -1750,7 +1750,7 @@
     <t>
    Some PROPFIND results MAY be cached, with care as there is no cache validation
       mechanism for most properties.  This method is both 
-   safe and idempotent (see section 9.1 of <xref target="RFC2616"/>).
+   safe and idempotent (see Section 9.1 of <xref target="RFC2616"/>).
     </t>
 
     <section title="PROPFIND status codes">
@@ -2148,7 +2148,7 @@
    set and remove instructions in <xref target="remove-element"/> and <xref target="set-element"/>. 
       </t>
     <t>
-      This method is idempotent, but not safe (see section 9.1 of 
+      This method is idempotent, but not safe (see Section 9.1 of 
       <xref target="RFC2616"/>). Responses to this method MUST NOT be cached.
     </t>    
     
@@ -2292,7 +2292,7 @@
    Media Type) status code. 
     </t>
     <t>
-      This method is idempotent, but not safe (see section 9.1 of 
+      This method is idempotent, but not safe (see Section 9.1 of 
       <xref target="RFC2616"/>). Responses to this method MUST NOT be cached.
     </t>    
     
@@ -2385,7 +2385,7 @@
   
   <section title="DELETE Requirements"> 
     <t>
-      DELETE is defined in <xref target="RFC2616"/>, section 9.7, to "delete the resource
+      DELETE is defined in <xref target="RFC2616"/>, Section 9.7, to "delete the resource
       identified by the Request-URI".  However, WebDAV
       changes some DELETE handling requirements.</t>
 
@@ -2561,7 +2561,7 @@
    server. 
     </t>
     <t>
-      This method is idempotent, but not safe (see section 9.1 of 
+      This method is idempotent, but not safe (see Section 9.1 of 
       <xref target="RFC2616"/>). Responses to this method MUST NOT be cached.
     </t>    
     <section title="COPY for Non-collection Resources">
@@ -2885,7 +2885,7 @@
    the restrictions of the Overwrite header. 
     </t>
     <t>
-      This method is idempotent, but not safe (see section 9.1 of 
+      This method is idempotent, but not safe (see Section 9.1 of 
       <xref target="RFC2616"/>). Responses to this method MUST NOT be cached.
     </t>    
     
@@ -3123,7 +3123,7 @@
    support the XML request and response formats defined herein. 
     </t>
     <t>
-      This method is neither idempotent nor safe (see section 9.1 of 
+      This method is neither idempotent nor safe (see Section 9.1 of 
       <xref target="RFC2616"/>). Responses to this method MUST NOT be cached.
     </t>    
     
@@ -3521,7 +3521,7 @@
    support the UNLOCK method. 
     </t>
     <t>
-      This method is idempotent, but not safe (see section 9.1 of 
+      This method is idempotent, but not safe (see Section 9.1 of 
       <xref target="RFC2616"/>). Responses to this method MUST NOT be cached.
     </t>    
     
@@ -4424,7 +4424,7 @@
     <t><list style="hanging">
       <t hangText="Name: ">location</t>
       <t hangText="Purpose: "> HTTP defines the "Location" header (see 
-        <xref target="RFC2616"/>, section 14.30) for use with some status codes (such as
+        <xref target="RFC2616"/>, Section 14.30) for use with some status codes (such as
         201 and the 300 series codes).  When these codes are used inside a 'multistatus'
         element, the 'location' element can be used to provide the accompanying Location
         header value.</t>
@@ -4760,7 +4760,7 @@
   <t>COPY and MOVE behavior refers to local COPY and MOVE operations.</t>
   
   <t>For properties defined based on HTTP GET response headers (DAV:get*), 
-    the value could include LWS as defined in <xref target="RFC2616"/>, section 4.2.
+    the value could include LWS as defined in <xref target="RFC2616"/>, Section 4.2.
     Server implementors SHOULD NOT include extra LWS in these values, however client
     implementors MUST be prepared to handle extra LWS.</t>
   
@@ -4831,10 +4831,10 @@
       <list style="hanging">
       
    <t hangText="Name: ">getcontentlanguage </t>
-   <t hangText="Purpose: ">Contains the Content-Language header value (from section 14.12
+   <t hangText="Purpose: ">Contains the Content-Language header value (from Section 14.12
             of <xref target="RFC2616"/>) as it would be returned by a GET 
             without accept headers.</t>
-   <t hangText="Value: ">language-tag (language-tag is defined in section 3.10 of 
+   <t hangText="Value: ">language-tag (language-tag is defined in Section 3.10 of 
             <xref target="RFC2616"/>).</t>
    <t hangText="Protected: "> SHOULD NOT be protected, so that clients can reset the 
             language.  Note that servers implementing <xref target="RFC2518"/> might have made this a
@@ -4856,7 +4856,7 @@
    <t hangText="Name: ">getcontentlength </t>
    <t hangText="Purpose: ">Contains the Content-Length header returned by a GET 
         without accept headers. </t>
-   <t hangText="Value: ">See section 14.13 of <xref target="RFC2616"/>. </t>
+   <t hangText="Value: ">See Section 14.13 of <xref target="RFC2616"/>. </t>
    <t hangText="Protected: ">This property is computed, therefore protected.</t>
    <t hangText="Description: ">The DAV:getcontentlength property MUST be defined on any 
             DAV compliant resource that returns the Content-Length 
@@ -4875,10 +4875,10 @@
   <section title="getcontenttype Property">
     <t><list style="hanging">
    <t hangText="Name: ">getcontenttype </t>
-      <t hangText="Purpose: ">Contains the Content-Type header value (from section 14.17
+      <t hangText="Purpose: ">Contains the Content-Type header value (from Section 14.17
         of <xref target="RFC2616"/>) as it would be returned by a GET without 
             accept headers. </t>
-   <t hangText="Value: ">media-type (defined in section 3.7 of <xref target="RFC2616"/>) </t>
+   <t hangText="Value: ">media-type (defined in Section 3.7 of <xref target="RFC2616"/>) </t>
       <t hangText="Protected: ">Potentially protected if the server prefers to assign
         content types on its own (see also discussion in <xref target="put-resources"/>).</t>
    <t hangText="COPY/MOVE behaviour: ">This property value SHOULD be preserved in 
@@ -4896,10 +4896,10 @@
   <section title="getetag Property">
     <t><list style="hanging">
    <t hangText="Name: ">getetag </t>
-      <t hangText="Purpose: ">Contains the ETag header value (from section 14.19
+      <t hangText="Purpose: ">Contains the ETag header value (from Section 14.19
         of <xref target="RFC2616"/>) as it would be returned by a GET without accept 
             headers. </t>
-   <t hangText="Value: ">entity-tag  (defined in section 3.11 of <xref target="RFC2616"/>) </t>
+   <t hangText="Value: ">entity-tag  (defined in Section 3.11 of <xref target="RFC2616"/>) </t>
    <t hangText="Protected:">MUST be protected because this value is created and 
             controlled by the server. </t>
    <t hangText="COPY/MOVE behaviour: ">This property value is dependent on the final 
@@ -4907,7 +4907,7 @@
      property on the source resource. Also note the considerations
      in <xref target="cache-control"/>.</t>
    <t hangText="Description: ">The getetag property MUST be defined on any DAV 
-            compliant resource that returns the Etag header.  Refer to section 3.11 of
+            compliant resource that returns the Etag header.  Refer to Section 3.11 of
             RFC2616 for a complete definition of the semantics of an 
             ETag, and to <xref target="etag"/> for a discussion of ETags in WebDAV.</t>
     </list>
@@ -4920,10 +4920,10 @@
   <section title="getlastmodified Property" anchor="getlastmodified">
     <t><list style="hanging">
    <t hangText="Name: ">getlastmodified </t>
-      <t hangText="Purpose: ">Contains the Last-Modified header value  (from section 14.29
+      <t hangText="Purpose: ">Contains the Last-Modified header value  (from Section 14.29
         of <xref target="RFC2616"/>) as it would be returned by a GET method 
             without accept headers. </t>
-   <t hangText="Value: ">rfc1123-date  (defined in section 3.3.1 of <xref target="RFC2616"/>) </t>
+   <t hangText="Value: ">rfc1123-date  (defined in Section 3.3.1 of <xref target="RFC2616"/>) </t>
    <t hangText="Protected: ">SHOULD be protected because some clients may rely on the 
             value for appropriate caching behavior, or on the value of 
             the Last-Modified header to which this property is linked. </t>
@@ -5220,7 +5220,7 @@
           
               
       <t>Some other useful preconditions and postconditions have been defined in other specifications
-        extending WebDAV, such as <xref target="RFC3744"/> (see particularly section 7.1.1),
+        extending WebDAV, such as <xref target="RFC3744"/> (see particularly Section 7.1.1),
         <xref target="RFC3253"/>, and <xref target="RFC3648"/>.
       </t>
       
@@ -5664,7 +5664,7 @@
   <section title="Implications of XML Entities">
     <t>
    XML supports a facility known as "external entities", defined in 
-   section 4.2.2 of <xref target="REC-XML"/>, which instruct an XML processor to 
+   Section 4.2.2 of <xref target="REC-XML"/>, which instruct an XML processor to 
    retrieve and include additional XML. An external XML entity can be 
    used to append or modify the document type declaration (DTD) 
    associated with an XML document.  An external XML entity can also be 
@@ -5696,7 +5696,7 @@
     </t>
     <t>
    Furthermore, there's also a risk based on the evaluation of "internal entities"
-    as defined in section 4.2.2 of <xref target="REC-XML"/>. 
+    as defined in Section 4.2.2 of <xref target="REC-XML"/>. 
    A small, carefully crafted request using nested internal entities 
     may require enormous amounts of memory and/or processing time to process. Server 
     implementors should be aware of this risk and configure their XML parsers so that
@@ -5710,7 +5710,7 @@
       Unique Identifier (UUID) URN Namespace" (<xref target="RFC4122"/>) for 
       <xref target="lock-tokens">lock tokens</xref>, in order to guarantee 
       their uniqueness across space and time.  
-      Version 1 UUIDs (defined in section 4) MAY contain a "node" field that
+      Version 1 UUIDs (defined in Section 4) MAY contain a "node" field that
       "consists of an IEEE 802 MAC address, usually the host address.  For systems
       with multiple IEEE addresses, any available one can be used".  Since a WebDAV 
       server will issue many  locks over its lifetime, the implication is that it 
@@ -6308,11 +6308,11 @@
    <figure>
      <artwork><![CDATA[
   OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]  
-    ; UUID is defined in section 3 of RFC4122. Note that linear white
+    ; UUID is defined in Section 3 of RFC4122. Note that linear white
     ; space (LWS) is not allowed between elements of this production. 
 
   Extension = path  
-     ; path is defined in section 3.3 of RFC3986 
+     ; path is defined in Section 3.3 of RFC3986 
        ]]>
      </artwork>
    </figure>
@@ -6700,11 +6700,11 @@
     <t>Added reference to RFC4122 for lock tokens and removed section on generating
     UUIDs</t>
     <t>Explained that even with language variation, a property has only one value
-    (section 4.5).</t>
+    (Section 4.5).</t>
     <t>Added section on lock owner (7.1) and what to do if lock requested by 
     unauthenticated user</t>
-    <t>Removed section 4.2 -- justification on why to have metadata, not needed now</t>
-    <t>Removed paragraph in section 5.2 about collections with resource type
+    <t>Removed Section 4.2 -- justification on why to have metadata, not needed now</t>
+    <t>Removed paragraph in Section 5.2 about collections with resource type
       "DAV:collection" but which are non-WebDAV compliant -- not implemented.</t>
 
   </section>
Received on Monday, 24 April 2006 13:57:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:14 GMT