RFC2068 ]. Compliance classes are not necessarily sequential. A resource that is class 2 compliant must also be class 1 compliant; but if additional compliance classes are defined later, a resource t
RFC2068].
Compliance classes are not necessarily sequential. A resource that is
class 2 compliant must also be class 1 compliant; but if additional
compliance classes are defined later, a resource that is class 1, 2,
and 4 compliant might not be class 3 compliant. Also note that
identifiers other than numbers may be used as compliance class
identifiers.
15.1 Class 1
A class 1 compliant resource MUST meet all "MUST" requirements in all
sections of this document.
Class 1 compliant resources MUST return, at minimum, the value "1" in
the DAV header on all responses to the OPTIONS method.
15.2 Class 2
A class 2 compliant resource MUST meet all class 1 requirements and
support the LOCK method, the supportedlock property, the
lockdiscovery property, the Time-Out response header and the Lock-
Token request header. A class "2" compliant resource SHOULD also
support the Time-Out request header and the owner XML element.
Class 2 compliant resources MUST return, at minimum, the values "1"
and "2" in the DAV header on all responses to the OPTIONS method.
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
RFC2026 [
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",
RFC1766, March 1995.
[
RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18,
RFC2277, January 1998.
[
RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14,
RFC2119, March 1997.
[
RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic Syntax",
RFC2396, 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",
RFC2069, January 1997.
[
RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and
T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1",
RFC2068, 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",
RFC2141, May 1997.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of
Unicode and ISO 10646",
RFC2279, January 1998.
21.2 Informational References
[
RFC2026] Bradner, S., "The Internet Standards Process - Revision
3", BCP 9,
RFC2026, October 1996.
[
RFC1807] Lasher, R. and D. Cohen, "A Format for Bibliographic
Records",
RFC1807, 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",
RFC2291, February 1998.
[
RFC2413] Weibel, S., Kunze, J., Lagoze, C. and M. Wolf, "Dublin
Core Metadata for Resource Discovery",
RFC2413, September
1998.
[
RFC2376] Whitehead, E. and M. Murata, "XML Media Types",
RFC2376,
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.