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: firstname.lastname@example.org E. J. Whitehead, Jr. Dept. Of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425 EMail: email@example.com
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
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. 220.127.116.11 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. 18.104.22.168 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.