- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 28 Apr 2006 13:19:19 +0200
- To: WebDav WG <w3c-dist-auth@w3.org>
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>ejw@cse.ucsc.edu</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>
Received on Friday, 28 April 2006 11:22:07 UTC