--- 1/draft-ietf-webdav-rfc2518bis-16.txt 2006-12-05 22:12:30.000000000 +0100 +++ 2/draft-ietf-webdav-rfc2518bis-17.txt 2006-12-05 22:12:31.000000000 +0100 @@ -1,19 +1,19 @@ WebDAV L. Dusseault, Ed. Internet-Draft CommerceNet -Obsoletes: 2518 (if approved) November 26, 2006 +Obsoletes: 2518 (if approved) December 1, 2006 Intended status: Standards Track -Expires: May 30, 2007 +Expires: June 4, 2007 HTTP Extensions for Distributed Authoring - WebDAV - draft-ietf-webdav-rfc2518bis-16 + draft-ietf-webdav-rfc2518bis-17 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,21 +24,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at 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 (C) The Internet Society (2006). Abstract WebDAV consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace @@ -273,20 +273,21 @@ G.2. Changes in -07 . . . . . . . . . . . . . . . . . . . . . 139 G.3. Changes in -08 . . . . . . . . . . . . . . . . . . . . . 140 G.4. Changes in -09 . . . . . . . . . . . . . . . . . . . . . 141 G.5. Changes in -10 . . . . . . . . . . . . . . . . . . . . . 142 G.6. Changes in -11 . . . . . . . . . . . . . . . . . . . . . 142 G.7. Changes in -12 . . . . . . . . . . . . . . . . . . . . . 142 G.8. Changes in -13 . . . . . . . . . . . . . . . . . . . . . 143 G.9. Changes in -14 . . . . . . . . . . . . . . . . . . . . . 143 G.10. Changes in -15 . . . . . . . . . . . . . . . . . . . . . 143 G.11. Changes in -16 . . . . . . . . . . . . . . . . . . . . . 143 + G.12. Changes in -17 . . . . . . . . . . . . . . . . . . . . . 144 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 145 Intellectual Property and Copyright Statements . . . . . . . . . 146 1. Introduction This document describes an extension to the HTTP/1.1 protocol that allows clients to perform remote web content authoring operations. This extension provides a coherent set of methods, headers, request entity body formats, and response entity body formats that provide operations for: @@ -2030,21 +2031,21 @@ exception to the normal rule that ordering is irrelevant). Instructions MUST either all be executed or none executed. Thus if any error occurs during processing all executed instructions MUST be undone and a proper error result returned. Instruction processing details can be found in the definition of the set and remove instructions in Section 14.23 and Section 14.26. 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 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 [RFC2616]). Responses to this method MUST NOT be cached. 9.2.1. Status Codes for use in 'propstat' Element In PROPPATCH responses, information about individual properties is returned inside 'propstat' elements (see Section 14.22), each containing an individual 'status' element containing information about the properties appearing in it. The list below summarizes the @@ -4532,22 +4533,23 @@ 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 method describes the state of the server that must be true after that method has been completed. Each precondition and postcondition has a unique 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 'response' element depending on whether the condition applies to one 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- - level 'error' element in the response body, unless otherwise + responses where this specification's 'error' body is used, the + 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. The most common response status codes are 403 (Forbidden) if the 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 the conflict and resubmit the request. The 'error' element MAY contain child elements with specific error information and MAY be extended with any custom child elements. This mechanism does not take the place of using a correct numeric status code as defined here or in HTTP, because the client MUST @@ -4871,23 +4873,25 @@ resource, but the integrity of the resource as well. Furthermore, the introduction of locking functionality requires support for authentication. A password sent in the clear over an insecure channel is an inadequate means for protecting the accessibility and integrity of a resource as the password may be intercepted. Since Basic authentication for HTTP/1.1 performs essentially clear text transmission of a password, Basic authentication MUST NOT be used to 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 - 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 [RFC2617]. Since Digest authentication verifies that both parties to a communication know a shared secret, a password, without having to send that secret in the clear, Digest authentication avoids the security problems inherent in Basic authentication while providing a level of authentication which is useful in a wide range of scenarios. 20.2. Denial of Service @@ -6012,20 +6016,31 @@ Made explicit requirement for successful response format for PROPPATCH (bug 238) Some fixes for bugs 213, 241, 246, 248, 249, 250 -- all editorial changes. Tighten requirements in Security Considerations section for 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 Lisa Dusseault (editor) CommerceNet 2064 Edgewood Dr. Palo Alto, CA 94303 US Email: ldusseault@commerce.net