Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 2518

HTTP Extensions for Distributed Authoring -- WEBDAV

Pages: 94
Obsoleted by:  4918
Part 4 of 4 – Pages 76 to 94
First   Prev   None

ToP   noToC   RFC2518 - Page 76   prevText

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
ToP   noToC   RFC2518 - Page 77
   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.
ToP   noToC   RFC2518 - Page 78
   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
ToP   noToC   RFC2518 - Page 79
   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
ToP   noToC   RFC2518 - Page 80
   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.
ToP   noToC   RFC2518 - Page 81
   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.
ToP   noToC   RFC2518 - Page 82

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.
ToP   noToC   RFC2518 - Page 83
   [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.

   [REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Namespaces in
                   XML". World Wide Web Consortium Recommendation REC-

   [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

   [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.
ToP   noToC   RFC2518 - Page 84
   [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.

   [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.

   [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

   [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: E. J. Whitehead, Jr. Dept. Of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425 EMail:
ToP   noToC   RFC2518 - Page 85
   A. Faizi
   685 East Middlefield Road
   Mountain View, CA 94043


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


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

ToP   noToC   RFC2518 - Page 86

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) >
ToP   noToC   RFC2518 - Page 87
   <!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)* >
ToP   noToC   RFC2518 - Page 88

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.
ToP   noToC   RFC2518 - Page 89

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. 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).
ToP   noToC   RFC2518 - Page 90
   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. 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=""> <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=""> </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="">
ToP   noToC   RFC2518 - Page 91

   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.
ToP   noToC   RFC2518 - Page 92

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=""> <del:glidername> Johnny Updraft </del:glidername> <del:glideraccidents/> </del:glider> In this example, the qualified element name "del:glider" is interpreted as the URL "". <bar:glider xmlns:del=""> <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 "" 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=""> <foo:rname> Johnny Updraft </foo:rname> <foo:raccidents/> </foo:r>
ToP   noToC   RFC2518 - Page 93
   This example is semantically identical to the two previous ones.
   Each instance of the namespace name "foo" is replaced with
   "" which is then appended to the local
   name for each element tag, the resulting tag names are identical to
   those in the previous examples.
ToP   noToC   RFC2518 - Page 94

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.