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. 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.
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.
SHOULD provide control over whether contact information is sent at all, and if contact information is sent, control over exactly what information is sent. 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.
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. 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.
[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. [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.
A. Faizi Netscape 685 East Middlefield Road Mountain View, CA 94043 EMail: firstname.lastname@example.org S. R. Carter Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399 EMail: email@example.com D. Jensen Novell 1555 N. Technology Way M/S ORM F111 Orem, UT 84097-2399 EMail: firstname.lastname@example.org
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)* > ]>
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.
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.
<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.
REC-XML-NAMES]. 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.