- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 24 Apr 2006 15:55:09 +0200
- To: WebDav WG <w3c-dist-auth@w3.org>
- Message-ID: <444CD8BD.8040409@gmx.de>
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 UTC