Subject: Editorial fix: uppercasing "Section" in section references

From: Julian Reschke <[email-masked]>
Date: Mon, 24 Apr 2006 15:55:09 +0200

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>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Apr 2006 13:19:19 +0200

Hi,

below are some more editorial fixes (for a few typos, reference style, 
the broken reference to the ETag draft, and indentation).

Best regards, Julian

Index: draft-ietf-webdav-rfc2518bis-latest.xml
===================================================================
RCS file: /var/cvsroot/xml2rfc/draft-ietf-webdav-rfc2518bis-latest.xml,v
retrieving revision 1.42
diff -u -r1.42 draft-ietf-webdav-rfc2518bis-latest.xml
--- draft-ietf-webdav-rfc2518bis-latest.xml	28 Apr 2006 06:54:16 -0000	1.42
+++ draft-ietf-webdav-rfc2518bis-latest.xml	28 Apr 2006 11:19:06 -0000
@@ -103,7 +103,7 @@
     Versioning Protocol for the World Wide Web" <xref target="RFC2291"/>.
    </t>
    <t>
-   This standard does not specify the versioning operations suggested
+   This document does not specify the versioning operations suggested
     by <xref target="RFC2291"/>. That work was done in a separate 
document,
     "Versioning Extensions to WebDAV" <xref target="RFC3253"/>.
    </t>
@@ -977,7 +977,7 @@
     the only lock type described in this specification.
    </t>
    <t>
-   An exclusive write lock prevent changes to a resource by
+   An exclusive write lock prevents changes to a resource by
      any principal other than the lock creator and in any case where the
      lock token is not submitted (e.g. by a client process other than 
the one
      holding the lock).
@@ -1152,7 +1152,7 @@
        after locking it, using PUT and possibly PROPPATCH.
      </t>

-    <t>Alternatively and for backwards compatibility to [RFC2518], servers	
+    <t>Alternatively and for backwards compatibility to <xref 
target="RFC2518"/>, servers	
        MAY implement Lock-Null Resources (LNRs) instead (see definition in	
        <xref target="lock-null"/>). Clients can easily interoperate 
both with servers that	
        support the old model LNRs and the recommended model of 
"locked empty	
@@ -1780,7 +1780,6 @@
          well.
        </t>

-      <t><list>
      <t>200 OK - A property exists and/or its value is successfully 
returned.</t>

      <t>401 Unauthorized - The property cannot be viewed without 
appropriate authorization.</t>
@@ -1789,7 +1788,6 @@

      <t>404 Not Found - The property does not exist.</t>

-    </list></t>
      </section>

      <section title="Example - Retrieving Named Properties">
@@ -3728,7 +3726,7 @@
      </figure>

      <t>
-   If the Destination value is an absolute-URI, it may name a different
+   If the Destination value is an absolute-URI (Section 4.3 of <xref 
target="RFC3986"/>), it may name a different
     server (or different port or scheme). If the source server cannot
     attempt a copy to the remote server, it MUST fail the request. Note 
that
        copying and moving resources to remote servers is not fully 
defined in
@@ -3765,7 +3763,7 @@
            </t>
            <t>
              Additionally, the mere fact that a state token appears in 
an If header
-            means that is has been "submitted" with the request.  In 
general, this
+            means that it has been "submitted" with the request.  In 
general, this
              is used to indicate that the client has knowledge of that 
state token.
              The semantics for submitting a state token depend on its 
type (for
              lock tokens, please refer to <xref target="locking"/>).
@@ -4323,8 +4321,7 @@
      </list></t>
      <figure><artwork>
  <![CDATA[<!ELEMENT activelock (lockscope, locktype, depth, owner?, 
timeout?,
-locktoken?, lockroot)>
-     ]]></artwork></figure>
+          locktoken?, lockroot)>]]></artwork></figure>
    </section>

    <section title="allprop XML Element">
@@ -4466,8 +4463,8 @@
        <t hangText="Name: ">lockroot </t>
        <t hangText="Purpose: ">Contains the root URL of the lock, which 
is the URL through
              which the resource was addressed in the LOCK request. </t>
-      <t hangText="Description: ">The href contains an HTTP URL of the 
root of
-            the lock. The server SHOULD include this in all
+      <t hangText="Description: ">he href element contains the root of 
the lock.
+            The server SHOULD include this in all
              DAV:lockdiscovery property values and the response to LOCK
              requests. </t>
      </list></t>
@@ -4647,7 +4644,7 @@
      </list></t>
      <figure><artwork>
  <![CDATA[<!ELEMENT response (href, ((href*, status)|(propstat+)),
-      error?, responsedescription? , location?) > ]]>
+                    error?, responsedescription? , location?) > ]]>
      </artwork></figure>
    </section>

@@ -4696,7 +4693,7 @@
    <section title="status XML Element">
      <t><list style="hanging">
        <t hangText="Name: ">status </t>
-      <t hangText="Purpose: ">Holds a single HTTP status-line </t>
+      <t hangText="Purpose: ">Holds a single HTTP status-line.</t>
        <t hangText="Value: "> status-line (defined in Section 6.1 of 
<xref target="RFC2616"/>)
        </t>
      </list></t>
@@ -6099,24 +6096,28 @@
       &rfc3648;
       &rfc3744;
       &rfc3864;
-  <reference anchor="I-D.draft-whitehead-http-etag">
-    <front>
-      <title>ETags in HTTP PUT Responses</title>
-
-      <author fullname="Jim Whitehead" initials="J." surname="Whitehead">
-        <organization></organization>
-      </author>
-
-      <date day="18" month="February" year="2006" />
-
-    </front>
-
+  <reference anchor="I-D.draft-whitehead-http-etag">
+  <front>
+    <title abbrev="State Identifiers in HTTP/WebDAV">Design 
Considerations for State Identifiers in HTTP and WebDAV</title>
+
+    <author initials="J." surname="Whitehead" fullname="Jim Whitehead">
+      <organization abbrev="U.C. Santa Cruz">UC Santa Cruz, Dept. of 
Computer Science</organization>
+      <address>
+        <postal>
+          <street>1156 High Street</street>
+          <city>Santa Cruz</city>
+          <region>CA</region>
+          <code>95064</code>
+        </postal>
+        <email>[email-masked]</email>
+      </address>
+    </author>
+
+    <date month="February" year="2006" />
+	</front>
      <seriesInfo name="Internet-Draft"
        value="draft-whitehead-http-etag-00" />
-
-    <format target=""
-      type="TXT" />
-  </reference>
+	</reference>
  </references>

@@ -6308,11 +6309,12 @@
     <figure>
       <artwork><![CDATA[
    OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]
-    ; UUID is defined in Section 3 of RFC4122. Note that linear white
-    ; space (LWS) is not allowed between elements of this production.
+    ; 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>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Apr 2006 19:55:57 +0200

Hi,

here are some more fixes (one typo, plus the resolution for BugZilla 
issue 221 (<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=221>).

Best regards, Julian

Index: draft-ietf-webdav-rfc2518bis-latest.xml
===================================================================
RCS file: /var/cvsroot/xml2rfc/draft-ietf-webdav-rfc2518bis-latest.xml,v
retrieving revision 1.43
diff -u -r1.43 draft-ietf-webdav-rfc2518bis-latest.xml
--- draft-ietf-webdav-rfc2518bis-latest.xml	28 Apr 2006 16:08:57 -0000	1.43
+++ draft-ietf-webdav-rfc2518bis-latest.xml	28 Apr 2006 17:54:34 -0000
@@ -4463,7 +4463,7 @@
       <t hangText="Name: ">lockroot </t>
       <t hangText="Purpose: ">Contains the root URL of the lock, which is the URL through
             which the resource was addressed in the LOCK request. </t>
-      <t hangText="Description: ">he href element contains the root of the lock.
+      <t hangText="Description: ">The href element contains the root of the lock.
             The server SHOULD include this in all 
             DAV:lockdiscovery property values and the response to LOCK 
             requests. </t>
@@ -5308,7 +5308,8 @@
             <t hangText="Name:">cannot-modify-protected-property</t>
             <t hangText="Use with:">403 Forbidden</t>
             <t hangText="Purpose:">(precondition) -- The client attempted to set
-                a read-only property in a PROPPATCH (such as DAV:getetag).
+                a protected property in a PROPPATCH (such as DAV:getetag).  See
+                also <xref target="RFC3253"/>, Section 3.12.
             </t>
       </list></t>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Apr 2006 21:30:48 +0200

Hi,

attached is a fix resolving BugZilla issue 210 
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=210>).

Best regards, Julian
Index: draft-ietf-webdav-rfc2518bis-latest.xml
===================================================================
RCS file: /var/cvsroot/xml2rfc/draft-ietf-webdav-rfc2518bis-latest.xml,v
retrieving revision 1.44
diff -u -r1.44 draft-ietf-webdav-rfc2518bis-latest.xml
--- draft-ietf-webdav-rfc2518bis-latest.xml	28 Apr 2006 19:13:36 -0000	1.44
+++ draft-ietf-webdav-rfc2518bis-latest.xml	28 Apr 2006 19:32:16 -0000
@@ -2134,8 +2134,8 @@
     </t>
     <t>
    The request message body of a PROPPATCH method MUST contain the 
-   propertyupdate XML element.  Clients SHOULD NOT alter the same property
-    more than once in a single PROPPATCH request.</t>
+   propertyupdate XML element.
+    </t>
       
       <t>Servers MUST process PROPPATCH instructions in 
    document order (an exception to the normal rule that ordering is