draft-ietf-webdav-rfc2518bis-16.txt   draft-ietf-webdav-rfc2518bis-17.txt 
WebDAV L. Dusseault, Ed. WebDAV L. Dusseault, Ed.
Internet-Draft CommerceNet Internet-Draft CommerceNet
Obsoletes: 2518 (if approved) November 26, 2006 Obsoletes: 2518 (if approved) December 1, 2006
Intended status: Standards Track Intended status: Standards Track
Expires: May 30, 2007 Expires: June 4, 2007
HTTP Extensions for Distributed Authoring - WebDAV HTTP Extensions for Distributed Authoring - WebDAV
draft-ietf-webdav-rfc2518bis-16 draft-ietf-webdav-rfc2518bis-17
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 30, 2007. This Internet-Draft will expire on June 4, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
WebDAV consists of a set of methods, headers, and content-types WebDAV consists of a set of methods, headers, and content-types
ancillary to HTTP/1.1 for the management of resource properties, ancillary to HTTP/1.1 for the management of resource properties,
creation and management of resource collections, URL namespace creation and management of resource collections, URL namespace
skipping to change at page 7, line 8 skipping to change at page 7, line 8
G.2. Changes in -07 . . . . . . . . . . . . . . . . . . . . . 139 G.2. Changes in -07 . . . . . . . . . . . . . . . . . . . . . 139
G.3. Changes in -08 . . . . . . . . . . . . . . . . . . . . . 140 G.3. Changes in -08 . . . . . . . . . . . . . . . . . . . . . 140
G.4. Changes in -09 . . . . . . . . . . . . . . . . . . . . . 141 G.4. Changes in -09 . . . . . . . . . . . . . . . . . . . . . 141
G.5. Changes in -10 . . . . . . . . . . . . . . . . . . . . . 142 G.5. Changes in -10 . . . . . . . . . . . . . . . . . . . . . 142
G.6. Changes in -11 . . . . . . . . . . . . . . . . . . . . . 142 G.6. Changes in -11 . . . . . . . . . . . . . . . . . . . . . 142
G.7. Changes in -12 . . . . . . . . . . . . . . . . . . . . . 142 G.7. Changes in -12 . . . . . . . . . . . . . . . . . . . . . 142
G.8. Changes in -13 . . . . . . . . . . . . . . . . . . . . . 143 G.8. Changes in -13 . . . . . . . . . . . . . . . . . . . . . 143
G.9. Changes in -14 . . . . . . . . . . . . . . . . . . . . . 143 G.9. Changes in -14 . . . . . . . . . . . . . . . . . . . . . 143
G.10. Changes in -15 . . . . . . . . . . . . . . . . . . . . . 143 G.10. Changes in -15 . . . . . . . . . . . . . . . . . . . . . 143
G.11. Changes in -16 . . . . . . . . . . . . . . . . . . . . . 143 G.11. Changes in -16 . . . . . . . . . . . . . . . . . . . . . 143
G.12. Changes in -17 . . . . . . . . . . . . . . . . . . . . . 144
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 145 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 145
Intellectual Property and Copyright Statements . . . . . . . . . 146 Intellectual Property and Copyright Statements . . . . . . . . . 146
1. Introduction 1. Introduction
This document describes an extension to the HTTP/1.1 protocol that This document describes an extension to the HTTP/1.1 protocol that
allows clients to perform remote web content authoring operations. allows clients to perform remote web content authoring operations.
This extension provides a coherent set of methods, headers, request This extension provides a coherent set of methods, headers, request
entity body formats, and response entity body formats that provide entity body formats, and response entity body formats that provide
operations for: operations for:
skipping to change at page 49, line 32 skipping to change at page 49, line 32
exception to the normal rule that ordering is irrelevant). exception to the normal rule that ordering is irrelevant).
Instructions MUST either all be executed or none executed. Thus if Instructions MUST either all be executed or none executed. Thus if
any error occurs during processing all executed instructions MUST be any error occurs during processing all executed instructions MUST be
undone and a proper error result returned. Instruction processing undone and a proper error result returned. Instruction processing
details can be found in the definition of the set and remove details can be found in the definition of the set and remove
instructions in Section 14.23 and Section 14.26. instructions in Section 14.23 and Section 14.26.
If a server attempts to make any of the property changes in a If a server attempts to make any of the property changes in a
PROPPATCH request (i.e. the request is not rejected for high-level PROPPATCH request (i.e. the request is not rejected for high-level
errors before processing the body), the response MUST be a Multi- errors before processing the body), the response MUST be a Multi-
Status response (Section 13). Status response as described in Section 9.2.1.
This method is idempotent, but not safe (see Section 9.1 of This method is idempotent, but not safe (see Section 9.1 of
[RFC2616]). Responses to this method MUST NOT be cached. [RFC2616]). Responses to this method MUST NOT be cached.
9.2.1. Status Codes for use in 'propstat' Element 9.2.1. Status Codes for use in 'propstat' Element
In PROPPATCH responses, information about individual properties is In PROPPATCH responses, information about individual properties is
returned inside 'propstat' elements (see Section 14.22), each returned inside 'propstat' elements (see Section 14.22), each
containing an individual 'status' element containing information containing an individual 'status' element containing information
about the properties appearing in it. The list below summarizes the about the properties appearing in it. The list below summarizes the
skipping to change at page 106, line 22 skipping to change at page 106, line 22
A "precondition" of a method describes the state of the server that A "precondition" of a method describes the state of the server that
must be true for that method to be performed. A "postcondition" of a must be true for that method to be performed. A "postcondition" of a
method describes the state of the server that must be true after that method describes the state of the server that must be true after that
method has been completed. method has been completed.
Each precondition and postcondition has a unique XML element Each precondition and postcondition has a unique XML element
associated with it. In a 207 Multi-Status response, the XML element associated with it. In a 207 Multi-Status response, the XML element
MUST appear inside an 'error' element in the appropriate 'propstat or MUST appear inside an 'error' element in the appropriate 'propstat or
'response' element depending on whether the condition applies to one 'response' element depending on whether the condition applies to one
or more properties or to the resource as a whole. In all other error or more properties or to the resource as a whole. In all other error
responses, the XML element MUST be returned as the child of a top- responses where this specification's 'error' body is used, the
level 'error' element in the response body, unless otherwise precondition/postcondition XML element MUST be returned as the child
of a top-level 'error' element in the response body, unless otherwise
negotiated by the request, along with an appropriate response status. negotiated by the request, along with an appropriate response status.
The most common response status codes are 403 (Forbidden) if the The most common response status codes are 403 (Forbidden) if the
request should not be repeated because it will always fail, and 409 request should not be repeated because it will always fail, and 409
(Conflict) if it is expected that the user might be able to resolve (Conflict) if it is expected that the user might be able to resolve
the conflict and resubmit the request. The 'error' element MAY the conflict and resubmit the request. The 'error' element MAY
contain child elements with specific error information and MAY be contain child elements with specific error information and MAY be
extended with any custom child elements. extended with any custom child elements.
This mechanism does not take the place of using a correct numeric This mechanism does not take the place of using a correct numeric
status code as defined here or in HTTP, because the client MUST status code as defined here or in HTTP, because the client MUST
skipping to change at page 116, line 31 skipping to change at page 116, line 31
resource, but the integrity of the resource as well. Furthermore, resource, but the integrity of the resource as well. Furthermore,
the introduction of locking functionality requires support for the introduction of locking functionality requires support for
authentication. authentication.
A password sent in the clear over an insecure channel is an A password sent in the clear over an insecure channel is an
inadequate means for protecting the accessibility and integrity of a inadequate means for protecting the accessibility and integrity of a
resource as the password may be intercepted. Since Basic resource as the password may be intercepted. Since Basic
authentication for HTTP/1.1 performs essentially clear text authentication for HTTP/1.1 performs essentially clear text
transmission of a password, Basic authentication MUST NOT be used to transmission of a password, Basic authentication MUST NOT be used to
authenticate a WebDAV client to a server unless the connection is authenticate a WebDAV client to a server unless the connection is
secured by TLS. Furthermore, a WebDAV server MUST NOT send a Basic secure. Furthermore, a WebDAV server MUST NOT send a Basic
authentication challenge in a WWW-Authenticate header unless the authentication challenge in a WWW-Authenticate header unless the
connection is secured by TLS. connection is secure. An examples of a secure connections would be a
Transport Layer Security (TLS) connection employing a strong cipher
suite and server authentication.
WebDAV applications MUST support the Digest authentication scheme WebDAV applications MUST support the Digest authentication scheme
[RFC2617]. Since Digest authentication verifies that both parties to [RFC2617]. Since Digest authentication verifies that both parties to
a communication know a shared secret, a password, without having to a communication know a shared secret, a password, without having to
send that secret in the clear, Digest authentication avoids the send that secret in the clear, Digest authentication avoids the
security problems inherent in Basic authentication while providing a security problems inherent in Basic authentication while providing a
level of authentication which is useful in a wide range of scenarios. level of authentication which is useful in a wide range of scenarios.
20.2. Denial of Service 20.2. Denial of Service
skipping to change at page 145, line 5 skipping to change at page 144, line 26
Made explicit requirement for successful response format for Made explicit requirement for successful response format for
PROPPATCH (bug 238) PROPPATCH (bug 238)
Some fixes for bugs 213, 241, 246, 248, 249, 250 -- all editorial Some fixes for bugs 213, 241, 246, 248, 249, 250 -- all editorial
changes. changes.
Tighten requirements in Security Considerations section for Tighten requirements in Security Considerations section for
authentication over secure channels. authentication over secure channels.
G.12. Changes in -17
Change reference for PROPFIND MultiStatus response format from
section 15 to section 9.2.1
Add another "except" clause to statement requiring pre/postcondition
codes to appear in 'error'
Remove requirement to use TLS -- back to requiring channel to be
secure.
Author's Address Author's Address
Lisa Dusseault (editor) Lisa Dusseault (editor)
CommerceNet CommerceNet
2064 Edgewood Dr. 2064 Edgewood Dr.
Palo Alto, CA 94303 Palo Alto, CA 94303
US US
Email: ldusseault@commerce.net Email: ldusseault@commerce.net
 End of changes. 10 change blocks. 
9 lines changed or deleted 24 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/