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




 
RFC 2518                         WEBDAV                    February 1999


   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.







 
RFC 2518                         WEBDAV                    February 1999


   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.