RFC 2518                         WEBDAV                    February 1999


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






 
RFC 2518                         WEBDAV                    February 1999


   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