16 Internationalization Considerations

   In the realm of internationalization, this specification complies
   with the IETF Character Set Policy [RFC2277]. In this specification,
   human-readable fields can be found either in the value of a property,
   or in an error message returned in a response entity body.  In both
   cases, the human-readable content is encoded using XML, which has
   explicit provisions for character set tagging and encoding, and
   requires that XML processors read XML elements encoded, at minimum,
   using the UTF-8 [UTF-8] encoding of the ISO 10646 multilingual plane.
   XML examples in this specification demonstrate use of the charset
   parameter of the Content-Type header, as defined in [RFC2376], as
   well as the XML "encoding" attribute, which together provide charset
   identification information for MIME and XML processors.

   XML also provides a language tagging capability for specifying the
   language of the contents of a particular XML element.  XML uses
   either IANA registered language tags (see [RFC1766]) or ISO 639
   language tags [ISO-639] in the "xml:lang" attribute of an XML element
   to identify the language of its content and attributes.

   WebDAV applications MUST support the character set tagging, character
   set encoding, and the language tagging functionality of the XML
   specification.  Implementors of WebDAV applications are strongly
   encouraged to read "XML Media Types" [RFC2376] for instruction on
   which MIME media type to use for XML transport, and on use of the
   charset parameter of the Content-Type header.

   Names used within this specification fall into three categories:
   names of protocol elements such as methods and headers, names of XML
   elements, and names of properties.  Naming of protocol elements
   follows the precedent of HTTP, using English names encoded in USASCII
   for methods and headers.  Since these protocol elements are not
   visible to users, and are in fact simply long token identifiers, they
   do not need to support encoding in multiple character sets.
   Similarly, though the names of XML elements used in this
   specification are English names encoded in UTF-8, these names are not
   visible to the user, and hence do not need to support multiple
   character set encodings.

   The name of a property defined on a resource is a URI.  Although some
   applications (e.g., a generic property viewer) will display property
   URIs directly to their users, it is expected that the typical
   application will use a fixed set of properties, and will provide a
   mapping from the property name URI to a human-readable field when
   displaying the property name to a user.  It is only in the case where

   the set of properties is not known ahead of time that an application
   need display a property name URI to a user. We recommend that
   applications provide human-readable property names wherever feasible.

   For error reporting, we follow the convention of HTTP/1.1 status
   codes, including with each status code a short, English description
   of the code (e.g., 423 (Locked)).  While the possibility exists that
   a poorly crafted user agent would display this message to a user,
   internationalized applications will ignore this message, and display
   an appropriate message in the user's language and character set.

   Since interoperation of clients and servers does not require locale
   information, this specification does not specify any mechanism for
   transmission of this information.

17 Security Considerations

   This section is provided to detail issues concerning security
   implications of which WebDAV applications need to be aware.

   All of the security considerations of HTTP/1.1 (discussed in
   [RFC2068]) and XML (discussed in [RFC2376]) also apply to WebDAV. In
   addition, the security risks inherent in remote authoring require
   stronger authentication technology, introduce several new privacy
   concerns, and may increase the hazards from poor server design.
   These issues are detailed below.

17.1 Authentication of Clients

   Due to their emphasis on authoring, WebDAV servers need to use
   authentication technology to protect not just access to a network
   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
   secure. Furthermore, a WebDAV server MUST NOT send Basic
   authentication credentials in a WWW-Authenticate header unless the
   connection is secure.  Examples of secure connections include a
   Transport Layer Security (TLS) connection employing a strong cipher
   suite with mutual authentication of client and server, or a
   connection over a network which is physically secure, for example, an
   isolated network in a building with restricted access.

   WebDAV applications MUST support the Digest authentication scheme
   [RFC2069]. 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.

17.2 Denial of Service

   Denial of service attacks are of special concern to WebDAV servers.
   WebDAV plus HTTP enables denial of service attacks on every part of a
   system's resources.

   The underlying storage can be attacked by PUTting extremely large
   files.

   Asking for recursive operations on large collections can attack
   processing time.

   Making multiple pipelined requests on multiple connections can attack
   network connections.

   WebDAV servers need to be aware of the possibility of a denial of
   service attack at all levels.

17.3 Security through Obscurity

   WebDAV provides, through the PROPFIND method, a mechanism for listing
   the member resources of a collection.  This greatly diminishes the
   effectiveness of security or privacy techniques that rely only on the
   difficulty of discovering the names of network resources.  Users of
   WebDAV servers are encouraged to use access control techniques to
   prevent unwanted access to resources, rather than depending on the
   relative obscurity of their resource names.

17.4 Privacy Issues Connected to Locks

   When submitting a lock request a user agent may also submit an owner
   XML field giving contact information for the person taking out the
   lock (for those cases where a person, rather than a robot, is taking
   out the lock). This contact information is stored in a lockdiscovery
   property on the resource, and can be used by other collaborators to
   begin negotiation over access to the resource.  However, in many
   cases this contact information can be very private, and should not be
   widely disseminated.  Servers SHOULD limit read access to the
   lockdiscovery property as appropriate.  Furthermore, user agents

   SHOULD provide control over whether contact information is sent at
   all, and if contact information is sent, control over exactly what
   information is sent.

17.5 Privacy Issues Connected to Properties

   Since property values are typically used to hold information such as
   the author of a document, there is the possibility that privacy
   concerns could arise stemming from widespread access to a resource's
   property data.  To reduce the risk of inadvertent release of private
   information via properties, servers are encouraged to develop access
   control mechanisms that separate read access to the resource body and
   read access to the resource's properties.  This allows a user to
   control the dissemination of their property data without overly
   restricting access to the resource's contents.

17.6 Reduction of Security due to Source Link

   HTTP/1.1 warns against providing read access to script code because
   it may contain sensitive information.  Yet WebDAV, via its source
   link facility, can potentially provide a URI for script resources so
   they may be authored.  For HTTP/1.1, a server could reasonably
   prevent access to source resources due to the predominance of read-
   only access.  WebDAV, with its emphasis on authoring, encourages read
   and write access to source resources, and provides the source link
   facility to identify the source.  This reduces the security benefits
   of eliminating access to source resources.  Users and administrators
   of WebDAV servers should be very cautious when allowing remote
   authoring of scripts, limiting read and write access to the source
   resources to authorized principals.

17.7 Implications of XML External Entities

   XML supports a facility known as "external entities", defined in
   section 4.2.2 of [REC-XML], which instruct an XML processor to
   retrieve and perform an inline include of XML located at a particular
   URI. 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 used to include XML within the
   content of an XML document.  For non-validating XML, such as the XML
   used in this specification, including an external XML entity is not
   required by [REC-XML]. However, [REC-XML] does state that an XML
   processor may, at its discretion, include the external XML entity.

   External XML entities have no inherent trustworthiness and are
   subject to all the attacks that are endemic to any HTTP GET request.
   Furthermore, it is possible for an external XML entity to modify the
   DTD, and hence affect the final form of an XML document, in the worst

   case significantly modifying its semantics, or exposing the XML
   processor to the security risks discussed in [RFC2376].  Therefore,
   implementers must be aware that external XML entities should be
   treated as untrustworthy.

   There is also the scalability risk that would accompany a widely
   deployed application which made use of external XML entities.  In
   this situation, it is possible that there would be significant
   numbers of requests for one external XML entity, potentially
   overloading any server which fields requests for the resource
   containing the external XML entity.

17.8 Risks Connected with Lock Tokens

   This specification, in section 6.4, requires the use of Universal
   Unique Identifiers (UUIDs) for lock tokens, in order to guarantee
   their uniqueness across space and time.  UUIDs, as defined in [ISO-
   11578], contain a "node" field which "consists of the IEEE address,
   usually the host address.  For systems with multiple IEEE 802 nodes,
   any available node address can be used."  Since a WebDAV server will
   issue many locks over its lifetime, the implication is that it will
   also be publicly exposing its IEEE 802 address.

   There are several risks associated with exposure of IEEE 802
   addresses.  Using the IEEE 802 address:

   * It is possible to track the movement of hardware from subnet to
   subnet.

   * It may be possible to identify the manufacturer of the hardware
   running a WebDAV server.

   * It may be possible to determine the number of each type of computer
   running WebDAV.

   Section 6.4.1 of this specification details an alternate mechanism
   for generating the "node" field of a UUID without using an IEEE 802
   address, which alleviates the risks associated with exposure of IEEE
   802 addresses by using an alternate source of uniqueness.

18 IANA Considerations

   This document defines two namespaces, the namespace of property
   names, and the namespace of WebDAV-specific XML elements used within
   property values.

   URIs are used for both names, for several reasons. Assignment of a
   URI does not require a request to a central naming authority, and
   hence allow WebDAV property names and XML elements to be quickly
   defined by any WebDAV user or application.  URIs also provide a
   unique address space, ensuring that the distributed users of WebDAV
   will not have collisions among the property names and XML elements
   they create.

   This specification defines a distinguished set of property names and
   XML elements that are understood by all WebDAV applications.  The
   property names and XML elements in this specification are all derived
   from the base URI DAV: by adding a suffix to this URI, for example,
   DAV:creationdate for the "creationdate" property.

   This specification also defines a URI scheme for the encoding of lock
   tokens, the opaquelocktoken URI scheme described in section 6.4.

   To ensure correct interoperation based on this specification, IANA
   must reserve the URI namespaces starting with "DAV:" and with
   "opaquelocktoken:" for use by this specification, its revisions, and
   related WebDAV specifications.

19 Intellectual Property

   The following notice is copied from RFC 2026 [RFC2026], section 10.4,
   and describes the position of the IETF concerning intellectual
   property claims made against this document.

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use other technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

20 Acknowledgements

   A specification such as this thrives on piercing critical review and
   withers from apathetic neglect.  The authors gratefully acknowledge
   the contributions of the following people, whose insights were so
   valuable at every stage of our work.

   Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan
   Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-
   Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith
   Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee
   Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan
   Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis
   Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der
   Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven
   Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten,
   Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff,
   Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike
   Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi,
   Richard N. Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran,
   Fabio Vitali, Gregory Woodhouse, and Lauren Wood.

   Two from this list deserve special mention.  The contributions by
   Larry Masinter have been invaluable, both in helping the formation of
   the working group and in patiently coaching the authors along the
   way.  In so many ways he has set high standards we have toiled to
   meet. The contributions of Judith Slein in clarifying the
   requirements, and in patiently reviewing draft after draft, both
   improved this specification and expanded our minds on document
   management.

   We would also like to thank John Turner for developing the XML DTD.

21 References

21.1 Normative References

   [RFC1766]       Alvestrand, H., "Tags for the Identification of
                   Languages", RFC 1766, March 1995.

   [RFC2277]       Alvestrand, H., "IETF Policy on Character Sets and
                   Languages", BCP 18, RFC 2277, January 1998.

   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2396]       Berners-Lee, T., Fielding, R. and L. Masinter,
                   "Uniform Resource Identifiers (URI): Generic Syntax",
                   RFC 2396, August 1998.

   [REC-XML]       T. Bray, J. Paoli, C. M. Sperberg-McQueen,
                   "Extensible Markup Language (XML)." World Wide Web
                   Consortium Recommendation REC-xml-19980210.
                   http://www.w3.org/TR/1998/REC-xml-19980210.

   [REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Namespaces in
                   XML". World Wide Web Consortium Recommendation REC-
                   xml-names-19990114.  http://www.w3.org/TR/1999/REC-
                   xml-names-19990114/

   [RFC2069]       Franks, J., Hallam-Baker, P., Hostetler, J., Leach,
                   P, Luotonen, A., Sink, E. and L. Stewart, "An
                   Extension to HTTP :  Digest Access Authentication",
                   RFC 2069, January 1997.

   [RFC2068]       Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and
                   T. Berners-Lee, "Hypertext Transfer Protocol --
                   HTTP/1.1", RFC 2068, January 1997.

   [ISO-639]       ISO (International Organization for Standardization).
                   ISO 639:1988. "Code for the representation of names
                   of languages."

   [ISO-8601]      ISO (International Organization for Standardization).
                   ISO 8601:1988. "Data elements and interchange formats
                   - Information interchange - Representation of dates
                   and times."

   [ISO-11578]     ISO (International Organization for Standardization).
                   ISO/IEC 11578:1996. "Information technology - Open
                   Systems Interconnection - Remote Procedure Call
                   (RPC)"

   [RFC2141]       Moats, R., "URN Syntax", RFC 2141, May 1997.

   [UTF-8]         Yergeau, F., "UTF-8, a transformation format of
                   Unicode and ISO 10646", RFC 2279, January 1998.

21.2 Informational References

   [RFC2026]  Bradner, S., "The Internet Standards Process - Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC1807]  Lasher, R. and D. Cohen, "A Format for Bibliographic
              Records", RFC 1807, June 1995.

   [WF]       C. Lagoze, "The Warwick Framework: A Container
              Architecture for Diverse Sets of Metadata", D-Lib
              Magazine, July/August 1996.
              http://www.dlib.org/dlib/july96/lagoze/07lagoze.html

   [USMARC]   Network Development and MARC Standards, Office, ed. 1994.
              "USMARC Format for Bibliographic Data", 1994. Washington,
              DC: Cataloging Distribution Service, Library of Congress.

   [REC-PICS] J. Miller, T. Krauskopf, P. Resnick, W. Treese, "PICS
              Label Distribution Label Syntax and Communication
              Protocols" Version 1.1, World Wide Web Consortium
              Recommendation REC-PICS-labels-961031.
              http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html.

   [RFC2291]  Slein, J., Vitali, F., Whitehead, E. and D. Durand,
              "Requirements for Distributed Authoring and Versioning
              Protocol for the World Wide Web", RFC 2291, February 1998.

   [RFC2413]  Weibel, S.,  Kunze, J., Lagoze, C. and M. Wolf, "Dublin
              Core Metadata for Resource Discovery", RFC 2413, September
              1998.

   [RFC2376]  Whitehead, E. and M. Murata, "XML Media Types", RFC 2376,
              July 1998.

22 Authors' Addresses

   Y. Y. Goland
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399

   EMail: yarong@microsoft.com


   E. J. Whitehead, Jr.
   Dept. Of Information and Computer Science
   University of California, Irvine
   Irvine, CA 92697-3425

   EMail: ejw@ics.uci.edu

   A. Faizi
   Netscape
   685 East Middlefield Road
   Mountain View, CA 94043

   EMail: asad@netscape.com


   S. R. Carter
   Novell
   1555 N. Technology Way
   M/S ORM F111
   Orem, UT 84097-2399

   EMail: srcarter@novell.com


   D. Jensen
   Novell
   1555 N. Technology Way
   M/S ORM F111
   Orem, UT 84097-2399

   EMail: dcjensen@novell.com

23 Appendices

23.1 Appendix 1 - WebDAV Document Type Definition

   This section provides a document type definition, following the rules
   in [REC-XML], for the XML elements used in the protocol stream and in
   the values of properties. It collects the element definitions given
   in sections 12 and 13.

   <!DOCTYPE webdav-1.0 [

   <!--============ XML Elements from Section 12 ==================-->

   <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
   locktoken?) >

   <!ELEMENT lockentry (lockscope, locktype) >
   <!ELEMENT lockinfo (lockscope, locktype, owner?) >

   <!ELEMENT locktype (write) >
   <!ELEMENT write EMPTY >

   <!ELEMENT lockscope (exclusive | shared) >
   <!ELEMENT exclusive EMPTY >
   <!ELEMENT shared EMPTY >

   <!ELEMENT depth (#PCDATA) >

   <!ELEMENT owner ANY >

   <!ELEMENT timeout (#PCDATA) >

   <!ELEMENT locktoken (href+) >

   <!ELEMENT href (#PCDATA) >

   <!ELEMENT link (src+, dst+) >
   <!ELEMENT dst (#PCDATA) >
   <!ELEMENT src (#PCDATA) >

   <!ELEMENT multistatus (response+, responsedescription?) >

   <!ELEMENT response (href, ((href*, status)|(propstat+)),
   responsedescription?) >
   <!ELEMENT status (#PCDATA) >
   <!ELEMENT propstat (prop, status, responsedescription?) >
   <!ELEMENT responsedescription (#PCDATA) >

   <!ELEMENT prop ANY >

   <!ELEMENT propertybehavior (omit | keepalive) >
   <!ELEMENT omit EMPTY >

   <!ELEMENT keepalive (#PCDATA | href+) >

   <!ELEMENT propertyupdate (remove | set)+ >
   <!ELEMENT remove (prop) >
   <!ELEMENT set (prop) >

   <!ELEMENT propfind (allprop | propname | prop) >
   <!ELEMENT allprop EMPTY >
   <!ELEMENT propname EMPTY >

   <!ELEMENT collection EMPTY >

   <!--=========== Property Elements from Section 13 ===============-->
   <!ELEMENT creationdate (#PCDATA) >
   <!ELEMENT displayname (#PCDATA) >
   <!ELEMENT getcontentlanguage (#PCDATA) >
   <!ELEMENT getcontentlength (#PCDATA) >
   <!ELEMENT getcontenttype (#PCDATA) >
   <!ELEMENT getetag (#PCDATA) >
   <!ELEMENT getlastmodified (#PCDATA) >
   <!ELEMENT lockdiscovery (activelock)* >
   <!ELEMENT resourcetype ANY >
   <!ELEMENT source (link)* >
   <!ELEMENT supportedlock (lockentry)* >
   ]>

23.2 Appendix 2 - ISO 8601 Date and Time Profile

   The creationdate property specifies the use of the ISO 8601 date
   format [ISO-8601].  This section defines a profile of the ISO 8601
   date format for use with this specification.  This profile is quoted
   from an Internet-Draft by Chris Newman, and is mentioned here to
   properly attribute his work.

   date-time       = full-date "T" full-time

   full-date       = date-fullyear "-" date-month "-" date-mday
   full-time       = partial-time time-offset

   date-fullyear   = 4DIGIT
   date-month      = 2DIGIT  ; 01-12
   date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
   month/year
   time-hour       = 2DIGIT  ; 00-23
   time-minute     = 2DIGIT  ; 00-59
   time-second     = 2DIGIT  ; 00-59, 00-60 based on leap second rules
   time-secfrac    = "." 1*DIGIT
   time-numoffset  = ("+" / "-") time-hour ":" time-minute
   time-offset     = "Z" / time-numoffset

   partial-time    = time-hour ":" time-minute ":" time-second
                    [time-secfrac]

   Numeric offsets are calculated as local time minus UTC (Coordinated
   Universal Time).  So the equivalent time in UTC can be determined by
   subtracting the offset from the local time.  For example, 18:50:00-
   04:00 is the same time as 22:58:00Z.

   If the time in UTC is known, but the offset to local time is unknown,
   this can be represented with an offset of "-00:00".  This differs
   from an offset of "Z" which implies that UTC is the preferred
   reference point for the specified time.

23.3 Appendix 3 - Notes on Processing XML Elements

23.3.1 Notes on Empty XML Elements

   XML supports two mechanisms for indicating that an XML element does
   not have any content.  The first is to declare an XML element of the
   form <A></A>.  The second is to declare an XML element of the form
   <A/>.  The two XML elements are semantically identical.

   It is a violation of the XML specification to use the <A></A> form if
   the associated DTD declares the element to be EMPTY (e.g., <!ELEMENT
   A EMPTY>).  If such a statement is included, then the empty element
   format, <A/> must be used.  If the element is not declared to be
   EMPTY, then either form <A></A> or <A/> may be used for empty
   elements.

23.3.2 Notes on Illegal XML Processing

   XML is a flexible data format that makes it easy to submit data that
   appears legal but in fact is not.  The philosophy of "Be flexible in
   what you accept and strict in what you send" still applies, but it
   must not be applied inappropriately.  XML is extremely flexible in
   dealing with issues of white space, element ordering, inserting new
   elements, etc.  This flexibility does not require extension,
   especially not in the area of the meaning of elements.

   There is no kindness in accepting illegal combinations of XML
   elements.  At best it will cause an unwanted result and at worst it
   can cause real damage.

23.3.2.1  Example - XML Syntax Error

   The following request body for a PROPFIND method is illegal.

   <?xml version="1.0" encoding="utf-8" ?>
   <D:propfind xmlns:D="DAV:">
     <D:allprop/>
     <D:propname/>
   </D:propfind>

   The definition of the propfind element only allows for the allprop or
   the propname element, not both.  Thus the above is an error and must
   be responded to with a 400 (Bad Request).

   Imagine, however, that a server wanted to be "kind" and decided to
   pick the allprop element as the true element and respond to it.  A
   client running over a bandwidth limited line who intended to execute
   a propname would be in for a big surprise if the server treated the
   command as an allprop.

   Additionally, if a server were lenient and decided to reply to this
   request, the results would vary randomly from server to server, with
   some servers executing the allprop directive, and others executing
   the propname directive. This reduces interoperability rather than
   increasing it.

23.3.2.2  Example - Unknown XML Element

   The previous example was illegal because it contained two elements
   that were explicitly banned from appearing together in the propfind
   element.  However, XML is an extensible language, so one can imagine
   new elements being defined for use with propfind.  Below is the
   request body of a PROPFIND and, like the previous example, must be
   rejected with a 400 (Bad Request) by a server that does not
   understand the expired-props element.

   <?xml version="1.0" encoding="utf-8" ?>
   <D:propfind xmlns:D="DAV:"
   xmlns:E="http://www.foo.bar/standards/props/">
     <E:expired-props/>
   </D:propfind>

   To understand why a 400 (Bad Request) is returned let us look at the
   request body as the server unfamiliar with expired-props sees it.

   <?xml version="1.0" encoding="utf-8" ?>
   <D:propfind xmlns:D="DAV:"
               xmlns:E="http://www.foo.bar/standards/props/">
   </D:propfind>

   As the server does not understand the expired-props element,
   according to the WebDAV-specific XML processing rules specified in
   section 14, it must ignore it.  Thus the server sees an empty
   propfind, which by the definition of the propfind element is illegal.

   Please note that had the extension been additive it would not
   necessarily have resulted in a 400 (Bad Request).  For example,
   imagine the following request body for a PROPFIND:

   <?xml version="1.0" encoding="utf-8" ?>
   <D:propfind xmlns:D="DAV:"
               xmlns:E="http://www.foo.bar/standards/props/">

     <D:propname/>
     <E:leave-out>*boss*</E:leave-out>
   </D:propfind>

   The previous example contains the fictitious element leave-out. Its
   purpose is to prevent the return of any property whose name matches
   the submitted pattern.  If the previous example were submitted to a
   server unfamiliar with leave-out, the only result would be that the
   leave-out element would be ignored and a propname would be executed.

23.4 Appendix 4 -- XML Namespaces for WebDAV

23.4.1 Introduction

   All DAV compliant systems MUST support the XML namespace extensions
   as specified in [REC-XML-NAMES].

23.4.2 Meaning of Qualified Names

   [Note to the reader: This section does not appear in [REC-XML-NAMES],
   but is necessary to avoid ambiguity for WebDAV XML processors.]

   WebDAV compliant XML processors MUST interpret a qualified name as a
   URI constructed by appending the LocalPart to the namespace name URI.

   Example

   <del:glider xmlns:del="http://www.del.jensen.org/">
     <del:glidername>
          Johnny Updraft
     </del:glidername>
     <del:glideraccidents/>
   </del:glider>

   In this example, the qualified element name "del:glider" is
   interpreted as the URL "http://www.del.jensen.org/glider".

   <bar:glider xmlns:del="http://www.del.jensen.org/">
     <bar:glidername>
          Johnny Updraft
     </bar:glidername>
     <bar:glideraccidents/>
   </bar:glider>

   Even though this example is syntactically different from the previous
   example, it is semantically identical.  Each instance of the
   namespace name "bar" is replaced with "http://www.del.jensen.org/"
   and then appended to the local name for each element tag.  The
   resulting tag names in this example are exactly the same as for the
   previous example.

   <foo:r xmlns:foo="http://www.del.jensen.org/glide">
     <foo:rname>
          Johnny Updraft
     </foo:rname>
     <foo:raccidents/>
   </foo:r>

   This example is semantically identical to the two previous ones.
   Each instance of the namespace name "foo" is replaced with
   "http://www.del.jensen.org/glide" which is then appended to the local
   name for each element tag, the resulting tag names are identical to
   those in the previous examples.

24.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.