draft-ietf-webdav-requirements-00.txt   draft-ietf-webdav-requirements-01.txt 
WEBDAV Working Group J.A. Slein WEBDAV Working Group J.A. Slein
INTERNET-DRAFT Xerox Corporation INTERNET-DRAFT Xerox Corporation
<draft-ietf-webdav-requirements-00.txt> F. Vitali <draft-ietf-webdav-requirements-01.txt> F. Vitali
University of Bologna University of Bologna
E.J. Whitehead, Jr. E.J. Whitehead, Jr.
U.C. Irvine U.C. Irvine
D.G. Durand D.G. Durand
Boston University Boston University
May 30, 1997 July 24, 1997
Expires November 30, 1997 Expires January 24, 1998
Requirements for Distributed Authoring and Versioning Requirements for Distributed Authoring and Versioning
on the World Wide Web on the World Wide Web
Status of this Memo Status of this Memo
This document is an Internet draft. Internet drafts are working This document is an Internet draft. Internet drafts are working
documents of the Internet Engineering Task Force (IETF), its areas and documents of the Internet Engineering Task Force (IETF), its areas and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
information as Internet drafts. information as Internet drafts.
skipping to change at line 60 skipping to change at line 60
which, if implemented, would improve the efficiency of common remote which, if implemented, would improve the efficiency of common remote
editing operations, provide a locking mechanism to prevent overwrite editing operations, provide a locking mechanism to prevent overwrite
conflicts, improve link management support between non-HTML conflicts, improve link management support between non-HTML
data types, provide a simple attribute-value metadata facility, provide data types, provide a simple attribute-value metadata facility, provide
for the creation and reading of container data types, and integrate for the creation and reading of container data types, and integrate
versioning into the WWW. versioning into the WWW.
1. Introduction 1. Introduction
This document describes functionality which, if incorporated in an This document describes functionality which, if incorporated in an
extension to the existing HTTP proposed standard [4], would allow tools extension to the existing HTTP proposed standard [HTTP], would allow tools
for remote loading, editing and saving (publishing) of various media for remote loading, editing and saving (publishing) of various media
types on the WWW to interoperate with any compliant Web server. As much types on the WWW to interoperate with any compliant Web server. As much
as possible, this functionality is described without suggesting a as possible, this functionality is described without suggesting a
proposed implementation, since there are many ways to perform the proposed implementation, since there are many ways to perform the
functionality within the WWW framework. It is also possible that a functionality within the WWW framework. It is also possible that a
single mechanism could simultaneously satisfy several requirements. single mechanism could simultaneously satisfy several requirements.
This document is intended to reflect the consensus of the WWW This document is intended to reflect the consensus of the WWW
Distributed Authoring and Versioning working group (WebDAV) as to the Distributed Authoring and Versioning working group (WebDAV) as to the
functionality that needs to be standardized to support distributed functionality that needs to be standardized to support distributed
authoring and versioning on the Web. However, this version still has authoring and versioning on the Web. However, this version still has
some elements that are being debated in the working group. The following some elements that are being debated in the working group. The following
elements are still under discussion: elements are still under discussion:
o Whether support for multi-resource locking is needed o Whether support for multi-resource locking is needed
o Whether reservations should be treated as shared or advisory o Whether support for query on properties and links is needed
locks
o What requirements there should be for access control
o What requirements there should be for internationalization o What requirements there should be for internationalization
o How far WebDAV should be concerned about compatibility with
other transport protocols besides HTTP
2. Rationale 2. Rationale
Current Web standards contain functionality which enables the editing of Current Web standards contain functionality which enables the editing of
Web content at a remote location, without direct access to the storage Web content at a remote location, without direct access to the storage
media via an operating system. This capability is exploited by several media via an operating system. This capability is exploited by several
existing HTML distributed authoring tools, and by a growing number of existing HTML distributed authoring tools, and by a growing number of
mainstream applications (e.g., word processors) which allow users to mainstream applications (e.g., word processors) which allow users to
write (publish) their work to an HTTP server. To date, experience from write (publish) their work to an HTTP server. To date, experience from
the HTML authoring tools has shown they are unable to meet their users' the HTML authoring tools has shown they are unable to meet their users'
skipping to change at line 110 skipping to change at line 106
frustrated. Where this access is available at all, it is through frustrated. Where this access is available at all, it is through
nonstandard extensions to HTTP or other standards that force clients to nonstandard extensions to HTTP or other standards that force clients to
use a different interface for each vendor's service. use a different interface for each vendor's service.
This document describes requirements for a set of standard extensions This document describes requirements for a set of standard extensions
to HTTP that would allow distributed Web authoring tools to provide to HTTP that would allow distributed Web authoring tools to provide
the functionality their users need by means of the same standard the functionality their users need by means of the same standard
syntax across all compliant servers. The broad categories of syntax across all compliant servers. The broad categories of
functionality that need to be standardized are: functionality that need to be standardized are:
Attributes Properties
Links Links
Locking Locking
Reservations Reservations
Retrieval of Unprocessed Source Retrieval of Unprocessed Source
Partial Write Partial Write
Name Space Manipulation Name Space Manipulation
Collections Collections
Versioning Versioning
Security Security
Internationalization Internationalization
3. Terminology 3. Terminology
Where there is overlap, usage is intended to be consistent with that in Where there is overlap, usage is intended to be consistent with that in
the HTTP 1.1 specification [4]. the HTTP 1.1 specification [HTTP].
Attribute
Named descriptive information about a resource.
Client Client
A program which issues HTTP requests and accepts responses. A program which issues HTTP requests and accepts responses.
Collection Collection
A collection is a resource that contains other resources, A collection is a resource that contains other resources,
either directly or by reference. either directly or by reference.
Distributed Authoring Tool Distributed Authoring Tool
A program which can retrieve a source entity via HTTP, allow A program which can retrieve a source entity via HTTP, allow
skipping to change at line 151 skipping to change at line 144
Entity Entity
The information transferred in a request or response. The information transferred in a request or response.
Hierarchical Collection Hierarchical Collection
A hierarchical organization of resources. A hierarchical A hierarchical organization of resources. A hierarchical
collection is a resource that contains other resources, collection is a resource that contains other resources,
including collections, either directly or by reference. including collections, either directly or by reference.
Link Link
A typed connection between two resources. A typed connection between two or more resources.
Lock Lock
A mechanism for preventing anyone other than the owner of the A mechanism for preventing anyone other than the owner of the
lock from accessing a resource. lock from accessing a resource.
Member of Version Graph Member of Version Graph
A resource that is a node in a version graph, and so is derived A resource that is a node in a version graph, and so is derived
from the resources that precede it in the graph, and is the from the resources that precede it in the graph, and is the
basis of those that succeed it. basis of those that succeed it.
Property
Named descriptive information about a resource.
Reservation Reservation
A declaration to the server that one intends to edit a resource. A declaration that one intends to edit a resource.
Resource Resource
A network data object or service that can be identified by A network data object or service that can be identified by
a URI. a URI.
Server Server
A program which receives and responds to HTTP requests. A program which receives and responds to HTTP requests.
Server Attribute
An attribute whose value is generated by the server.
User Agent User Agent
The client that initiates a request. The client that initiates a request.
User Attribute
An attribute whose value is provided by a user or a user agent.
Version Graph Version Graph
A directed acyclic graph with resources as its nodes, where A directed acyclic graph with resources as its nodes, where
each node is derived from its predecessor(s). each node is derived from its predecessor(s).
Write Lock Write Lock
A lock that prevents anyone except its owner from modifying A lock that prevents anyone except its owner from modifying
the resource it applies to. the resource it applies to.
4. General Principles 4. General Principles
skipping to change at line 219 skipping to change at line 209
It should be possible to implement a WebDAV-compliant server in such a It should be possible to implement a WebDAV-compliant server in such a
way that it can interoperate with non-WebDAV clients. Such a server way that it can interoperate with non-WebDAV clients. Such a server
would be able to understand any valid HTTP 1.1 request from an ordinary would be able to understand any valid HTTP 1.1 request from an ordinary
Web client without WebDAV extensions, and to provide a valid HTTP 1.1 Web client without WebDAV extensions, and to provide a valid HTTP 1.1
response that does not require the client to understand the extensions. response that does not require the client to understand the extensions.
4.4. Data Format Compatibility 4.4. Data Format Compatibility
WebDAV-compliant servers should be able to work with existing resources WebDAV-compliant servers should be able to work with existing resources
and URIs [2]. Special additional information should not become a and URIs [URL]. Special additional information should not become a
mandatory part of document formats. mandatory part of document formats.
4.5. Replicated, Distributed Systems 4.5. Replicated, Distributed Systems
Distribution and replication are at the heart of the Internet. All Distribution and replication are at the heart of the Internet. All
WebDAV extensions should be designed to allow for distribution and WebDAV extensions should be designed to allow for distribution and
replication. Version trees should be able to be split across multiple replication. Version trees should be able to be split across multiple
servers. Collections may have members on different servers. Resources servers. Collections may have members on different servers. Resources
may have attributes on different servers. Any resources may be cached may have properties on different servers. Any resources may be cached
or replicated for mobile computing or other reasons. Consequently, the or replicated for mobile computing or other reasons. Consequently, the
WebDAV extensions must be able to operate in a distributed, replicated WebDAV extensions must be able to operate in a distributed, replicated
environment. environment.
4.6 Parsimony in Client-Server Interactions 4.6 Parsimony in Client-Server Interactions
The WebDAV extensions should keep to a minimum the number of The WebDAV extensions should keep to a minimum the number of
interactions between the client and the server needed to perform common interactions between the client and the server needed to perform common
functions. For example, publishing a document to the Web will often mean functions. For example, publishing a document to the Web will often mean
publishing content together with related metadata. A client may often publishing content together with related properties. A client may often
need to find out what version graph a particular resource belongs to, need to find out what version graph a particular resource belongs to,
or to find out which resource in a version graph is the published one. or to find out which resource in a version graph is the published one.
The extensions should make it possible to do these things efficiently. The extensions should make it possible to do these things efficiently.
4.7. Changes to HTTP 4.7. Changes to HTTP
WebDAV adds a number of new types of objects to the Web: links, WebDAV adds a number of new types of objects to the Web: properties,
collections, version graphs, etc. Existing HTTP methods such as collections, version graphs, etc. Existing HTTP methods such as
DELETE and PUT will have to operate in well-defined ways in this DELETE and PUT will have to operate in well-defined ways in this
expanded environment. WebDAV should explicitly address not only new expanded environment. WebDAV should explicitly address not only new
methods, headers, and MIME types, but also any required changes to the methods, headers, and MIME types, but also any required changes to the
existing HTTP methods and headers. existing HTTP methods and headers.
4.8. Alternate Transport Mechanisms 4.8. Alternate Transport Mechanisms
It may be desirable to transport WebDAV requests and responses by other It may be desirable to transport WebDAV requests and responses by other
mechanisms, particularly EMail, in addition to HTTP. The WebDAV protocol mechanisms, particularly EMail, in addition to HTTP. The WebDAV protocol
specification should not preculde a future body from developing an specification should not preclude a future body from developing an
interoperability specification for disconnected operation via EMail. interoperability specification for disconnected operation via EMail.
5. Requirements 5. Requirements
In the requirement descriptions below, the requirement will be stated, In the requirement descriptions below, the requirement will be stated,
followed by its rationale. followed by its rationale.
5.1. Attributes 5.1. Properties
5.1.1. Functional Requirements 5.1.1. Functional Requirements
It must be possible to create, modify, query, read and delete arbitrary It must be possible to create, modify, query, read and delete arbitrary
attributes on resources of any media type. properties on resources of any media type.
5.1.2. Rationale 5.1.2. Rationale
Attributes describe resources of any media type. They may Properties describe resources of any media type. They may
include bibliographic information such as author, title, publisher, include bibliographic information such as author, title, publisher,
and subject, constraints on usage, PICS ratings, etc. These and subject, constraints on usage, PICS ratings, etc. These
attributes have many uses, such as supporting searches on attribute properties have many uses, such as supporting searches on property
values, enforcing copyrights, and the creation of catalog entries as values, enforcing copyrights, and the creation of catalog entries as
placeholders for objects which are not available in electronic form, or placeholders for objects which are not available in electronic form, or
which will be available later. which will be available later.
5.2. Links 5.2. Links
5.2.1. Functional Requirements 5.2.1. Functional Requirements
It must be possible to create, modify, query, read and delete typed It must be possible to create, modify, query, read and delete typed
links between resources of any media type. links between resources of any media type.
skipping to change at line 300 skipping to change at line 289
One type of link between resources is the hypertext link, which is One type of link between resources is the hypertext link, which is
browsable using a hypertext style point-and-click user interface. Links, browsable using a hypertext style point-and-click user interface. Links,
whether they are browsable hypertext links, or simply a means of whether they are browsable hypertext links, or simply a means of
capturing a connection between resources, have many purposes. Links capturing a connection between resources, have many purposes. Links
can support pushbutton printing of a multi-resource document in a can support pushbutton printing of a multi-resource document in a
prescribed order, jumping to the access control page for a resource, prescribed order, jumping to the access control page for a resource,
and quick browsing of related information, such as a table of contents, and quick browsing of related information, such as a table of contents,
an index, a glossary, a bibliographic record, help pages, etc. While an index, a glossary, a bibliographic record, help pages, etc. While
link support is provided by the HTML "LINK" element, this is limited link support is provided by the HTML "LINK" element, this is limited
only to HTML resources [1]. Similar support is needed for bitmap image only to HTML resources [HTML]. Similar support is needed for bitmap image
types, and other non-HTML media types. types, and other non-HTML media types.
5.3. Locking 5.3. Locking
5.3.1. General Principles 5.3.1. General Principles
5.3.1.1. Independence of locks. It must be possible to lock a resource 5.3.1.1. Independence of locks. It must be possible to lock a resource
without re-reading the resource, and without committing to editing the without re-reading the resource, and without committing to editing the
resource. resource.
5.3.1.2. Multi-Resource Locking. It must be possible to take out a 5.3.1.2. Multi-Resource Locking. It must be possible to take out a
lock on multiple resources in the same action, and this locking lock on multiple resources residing on the same server in a single action,
operation must be atomic across these resources. and this locking operation must be atomic across these resources.
5.3.2. Functional Requirements 5.3.2. Functional Requirements
5.3.2.1. Write Locks. It must be possible to restrict modification of 5.3.2.1. Write Locks. It must be possible to restrict modification of
a resource to a specific person. a resource to a specific person.
5.3.2.2. Lock Query. It must be possible to find out whether a given 5.3.2.2. Lock Query. It must be possible to find out whether a given
resource has any active modification restrictions, and if so, who resource has any active locks, and if so, who holds those locks.
currently has modification permission.
5.3.2.3. Unlock. It must be possible to remove a lock. 5.3.2.3. Unlock. It must be possible to remove a lock.
5.3.3. Rationale 5.3.3. Rationale
At present, the Web provides limited support for preventing two or more At present, the Web provides limited support for preventing two or more
people from overwriting each other's modifications when they save to a people from overwriting each other's modifications when they save to a
given URI. Furthermore, there is no way to discover whether someone else given URI. Furthermore, there is no way to discover whether someone else
is currently making modifications to a resource. This is known as the is currently making modifications to a resource. This is known as the
"lost update problem," or the "overwrite problem." Since there can be "lost update problem," or the "overwrite problem." Since there can be
skipping to change at line 363 skipping to change at line 351
on the same set of resources, since with multi-resource locking, one of on the same set of resources, since with multi-resource locking, one of
the two people will get a lock. If this same multiple-resource locking the two people will get a lock. If this same multiple-resource locking
scenario was repeated by using atomic lock operations iterated across scenario was repeated by using atomic lock operations iterated across
the resources, the result would be a splitting of the locks between the the resources, the result would be a splitting of the locks between the
two people, based on resource ordering and race conditions. two people, based on resource ordering and race conditions.
5.4. Reservations 5.4. Reservations
5.4.1. Functional Requirements 5.4.1. Functional Requirements
5.4.1.1. Reserve. It must be possible to notify the server that 5.4.1.1. Reserve. It must be possible for a principal to register with
a resource is about to be edited by a given person. the server an intent to edit a given resource, so that other principals
can discover who intends to edit the resource.
5.4.1.2. Reservation Query. It must be possible to find out whether 5.4.1.2. Reservation Query. It must be possible to find out whether
a given resource has any active reservations, and if so, who currently a given resource has any active reservations, and if so, who currently
holds reservations. holds reservations.
5.4.1.3. Release Reservation. It must be possible to release the 5.4.1.3. Release Reservation. It must be possible to release the
reservation. reservation.
5.4.2. Rationale 5.4.2. Rationale
skipping to change at line 399 skipping to change at line 388
5.5.1. Functional Requirement 5.5.1. Functional Requirement
The source of any given resource must be retrievable. The source of any given resource must be retrievable.
5.5.2. Rationale 5.5.2. Rationale
There are many cases where the source stored on a server does There are many cases where the source stored on a server does
not correspond to the actual entity transmitted in response to an HTTP not correspond to the actual entity transmitted in response to an HTTP
GET. Current known cases are server side include directives, and GET. Current known cases are server side include directives, and
Standard Generalized Markup Language (SGML) source which is Standard Generalized Markup Language (SGML) source which is
converted on the fly to HyperText Markup Language (HTML) [1] output
converted on the fly to HyperText Markup Language (HTML) [HTML] output
entities. There are many possible cases, such as automatic conversion entities. There are many possible cases, such as automatic conversion
of bitmap images into several variant bitmap media types (e.g. GIF, of bitmap images into several variant bitmap media types (e.g. GIF,
JPEG), and automatic conversion of an application's native media type JPEG), and automatic conversion of an application's native media type
into HTML. As an example of this last case, a word processor could into HTML. As an example of this last case, a word processor could
store its native media type on a server which automatically converts store its native media type on a server which automatically converts
it to HTML. A GET of this resource would retrieve the HTML. Retrieving it to HTML. A GET of this resource would retrieve the HTML. Retrieving
the source would retrieve the word processor native format. the source would retrieve the word processor native format.
5.6. Partial Write. 5.6. Partial Write.
skipping to change at line 499 skipping to change at line 489
collection. collection.
5.8.1.3. Add to Collection. It must be possible to add a resource to a 5.8.1.3. Add to Collection. It must be possible to add a resource to a
collection directly or by reference. collection directly or by reference.
5.8.1.4. Remove from Collection. It must be possible to remove a 5.8.1.4. Remove from Collection. It must be possible to remove a
resource from a collection. resource from a collection.
5.8.2. Rationale 5.8.2. Rationale
In [2] it states that, "some URL schemes (such as the ftp, http, and In [URL] it states that, "some URL schemes (such as the ftp, http, and
file schemes) contain names that can be considered hierarchical." file schemes) contain names that can be considered hierarchical."
Especially for HTTP servers which directly map all or part of their URL Especially for HTTP servers which directly map all or part of their URL
name space into a filesystem, it is very useful to get a listing of all name space into a filesystem, it is very useful to get a listing of all
resources located at a particular hierarchy level. This functionality resources located at a particular hierarchy level. This functionality
supports "Save As..." dialog boxes, which provide a listing of the supports "Save As..." dialog boxes, which provide a listing of the
entities at a current hierarchy level, and allow navigation through entities at a current hierarchy level, and allow navigation through
the hierarchy. It also supports the creation of graphical visualizations the hierarchy. It also supports the creation of graphical visualizations
(typically as a network) of the hypertext structure among the entities (typically as a network) of the hypertext structure among the entities
at a hierarchy level, or set of levels. It also supports a tree at a hierarchy level, or set of levels. It also supports a tree
visualization of the entities and their hierarchy levels. visualization of the entities and their hierarchy levels.
skipping to change at line 600 skipping to change at line 589
this graph will be called a "version graph". Each node of this graph this graph will be called a "version graph". Each node of this graph
is a "version" or "member of the version graph". The arcs of the graph is a "version" or "member of the version graph". The arcs of the graph
capture the "derived from" relationships. capture the "derived from" relationships.
It is also possible for a single resource to participate in multiple It is also possible for a single resource to participate in multiple
version graphs. version graphs.
The WebDAV extensions should support this versioning model, though The WebDAV extensions should support this versioning model, though
particular servers may restrict it in various ways. particular servers may restrict it in various ways.
5.9.1.4. Versioning Policies. Many writers, including Feiler [3] and 5.9.1.4. Versioning Policies. Many writers, including Feiler [CM] and
Haake and Hicks [5], have discussed the notion of versioning styles Haake and Hicks [VSE], have discussed the notion of versioning styles
(referred to here as versioning policies, to reflect the nature of (referred to here as versioning policies, to reflect the nature of
client/server interaction) as one way to think about the different client/server interaction) as one way to think about the different
policies that versioning systems implement. Versioning policies include policies that versioning systems implement. Versioning policies include
decisions on the shape of version histories (linear or branched), the decisions on the shape of version histories (linear or branched), the
granularity of change tracking, locking requirements made by a server, granularity of change tracking, locking requirements made by a server,
etc. The protocol should clearly identify the policies that it dictates etc. The protocol should clearly identify the policies that it dictates
and the policies that are left up to versioning system implementors or and the policies that are left up to versioning system implementors or
administrators. administrators.
5.9.1.5. It is possible to version resources of any media type. 5.9.1.5. It is possible to version resources of any media type.
skipping to change at line 666 skipping to change at line 656
5.9.2.5. It must be possible, given a reference to a member of a version 5.9.2.5. It must be possible, given a reference to a member of a version
graph, to find out which version graph(s) that resource belongs to. graph, to find out which version graph(s) that resource belongs to.
This makes it possible to understand the versioning context of the This makes it possible to understand the versioning context of the
resource. It makes it possible to retrieve a version history for the resource. It makes it possible to retrieve a version history for the
graphs to which it belongs, and to browse the version graph. It also graphs to which it belongs, and to browse the version graph. It also
supports some comparison operations: It makes it possible to determine supports some comparison operations: It makes it possible to determine
whether two references designate members of the same version graph. whether two references designate members of the same version graph.
5.9.2.6. Navigation of a version graph. Given a reference to a member 5.9.2.6. Navigation of a version graph. Given a reference to a member
of a version graph, it must be possible to discover and access the of a version graph, it must be possible to discover and access the
following related members of the version graph. following related members of the version graph.
o root member of the graph o root member of the graph
o predecessor member(s) o predecessor member(s)
o successor member(s) o successor member(s)
o default member of the graph o default member of the graph
It must be possible in some way for a versioning client to access It must be possible in some way for a versioning client to access
versions related to a resource currently being exhamined. versions related to a resource currently being examined.
5.9.2.7. Version Topology. There must be a way to retrieve the complete 5.9.2.7. Version Topology. There must be a way to retrieve the complete
version topology for a version graph, including information about all version topology for a version graph, including information about all
members of the version graph. The format for this information must be members of the version graph. The format for this information must be
standardized so that the basic information can be used by all clients. standardized so that the basic information can be used by all clients.
Other specialized formats should be accomodated, for servers and Other specialized formats should be accommodated, for servers and
clients that require information that cannot be included in the clients that require information that cannot be included in the
standard topology. standard topology.
5.9.2.8. A client must be able to propose a version identifier to be 5.9.2.8. A client must be able to propose a version identifier to be
used for a new member of a version graph. The server may refuse to use used for a new member of a version graph. The server may refuse to use
the client's suggested version identifier. The server should tell the the client's suggested version identifier. The server should tell the
client what version identifier it has assigned to the new member of the client what version identifier it has assigned to the new member of the
version graph. version graph.
5.9.2.9. A version identifier must be unique across a version graph. 5.9.2.9. A version identifier must be unique across a version graph.
5.9.2.10. A client must be able to supply version-specific metadata to 5.9.2.10. A client must be able to supply version-specific properties to
be associated with a new member of a version graph. (See Section 5.1 be associated with a new member of a version graph. (See Section 5.1
"Attributes" above.) At a minimum, it must be possible to associate "Properties" above.) At a minimum, it must be possible to associate
comments with the new member, explaining what changes were made. comments with the new member, explaining what changes were made.
5.9.2.11. A client must be able to query the server for information 5.9.2.11. A client must be able to query the server for information
about a version tree, including which versions are locked, which are about a version tree, including which versions are locked, which are
reserved for editing, and by whom (Session Tracking). reserved for editing, and by whom (Session Tracking).
5.9.3. Rationale 5.9.3. Rationale
Versioning in the context of the world-wide web offers a variety of Versioning in the context of the world-wide web offers a variety of
benefits: benefits:
skipping to change at line 746 skipping to change at line 736
multiple states. A versioning system directly represents the fact that multiple states. A versioning system directly represents the fact that
a resource has an explicit history, and a persistent identity across a resource has an explicit history, and a persistent identity across
the various states it has had during the course of that history. the various states it has had during the course of that history.
5.10. Security 5.10. Security
5.10.1. Authentication. The WebDAV specification should state how the 5.10.1. Authentication. The WebDAV specification should state how the
WebDAV extensions interoperate with existing authentication schemes, WebDAV extensions interoperate with existing authentication schemes,
and should make recommendations for using those schemes. and should make recommendations for using those schemes.
5.10.2. Access Control. Access control requirements are TBD, and may 5.10.2. Access Control. Access control requirements are specified
eventually be specified in a separate access control draft. in a separate access control draft [AC].
5.10.3. Interoperability with Security Protocols. The WebDAV 5.10.3. Interoperability with Security Protocols. The WebDAV
specification should provide a minimal list of security protocols specification should provide a minimal list of security protocols
which any compliant server / client should support. These protocols which any compliant server / client should support. These protocols
should insure the authenticity of messages and the privacy and should insure the authenticity of messages and the privacy and
integrity of messages in transit. integrity of messages in transit.
5.11. Internationalization 5.11. Internationalization
Internationalization requirements are TBD. 5.11.1. Functional Requirement
For transmission of information intended for user comprehension,
the full Universal Character Set (UCS) [ISO 10646] must be available.
Language information and negotiation must be available where
appropriate.
5.11.2. Rationale
In the international environment of the Internet, it is important
to insure that any information intended for user comprehension will
be transported in a form that makes it possible to display the
information in any writing system and language agreeable to both the
client and the server. The information encompassed by this requirement
includes not only the content of resources, but also display names
and descriptions of properties, property values, and status messages.
6. Acknowledgements 6. Acknowledgements
Our understanding of these issues has emerged as the result of much Our understanding of these issues has emerged as the result of much
thoughtful discussion, email, and assistance by many people, who thoughtful discussion, email, and assistance by many people, who
deserve recognition for their effort. deserve recognition for their effort.
Terry Allen, tallen@sonic.net
Alan Babich, FileNet, babich@filenet.com
Dylan Barrell, Open Text, dbarrell@opentext.ch Dylan Barrell, Open Text, dbarrell@opentext.ch
Barbara Bazemore, PC DOCS, barbarab@pcdocs.com Barbara Bazemore, PC DOCS, barbarab@pcdocs.com
Martin Cagan, Continuus Software, Marty_Cagan@continuus.com Martin Cagan, Continuus Software, Marty_Cagan@continuus.com
Steve Carter, Novell, srcarter@novell.com Steve Carter, Novell, srcarter@novell.com
Dan Connolly, World Wide Web Consortium, connolly@w3.org Dan Connolly, World Wide Web Consortium, connolly@w3.org
Jim Cunningham, Netscape, jfc@netscape.com Jim Cunningham, Netscape, jfc@netscape.com
Ron Daniel Jr., Los Alamos National Laboratory, rdaniel@lanl.gov Ron Daniel Jr., Los Alamos National Laboratory, rdaniel@lanl.gov
Mark Day, Lotus, Mark_Day@lotus.com Mark Day, Lotus, Mark_Day@lotus.com
Martin J. Duerst, mduerst@ifi.unizh.ch
Asad Faizi, Netscape, asad@netscape.com Asad Faizi, Netscape, asad@netscape.com
Ron Fein, Microsoft, ronfe@microsoft.com Ron Fein, Microsoft, ronfe@microsoft.com
David Fiander, Mortice Kern Systems, davidf@mks.com David Fiander, Mortice Kern Systems, davidf@mks.com
Roy Fielding, U.C. Irvine, fielding@ics.uci.edu Roy Fielding, U.C. Irvine, fielding@ics.uci.edu
Mark Fisher, Thomson Consumer Electronics, FisherM@indy.tce.com
Mark Fisher, FisherM@exch1.indy.tce.com
Yaron Y. Goland, Microsoft, yarong@microsoft.com Yaron Y. Goland, Microsoft, yarong@microsoft.com
Phill Hallam-Baker, MIT, hallam@ai.mit.edu Phill Hallam-Baker, MIT, hallam@ai.mit.edu
Dennis Hamilton, Xerox PARC, hamilton@parc.xerox.com Dennis Hamilton, Xerox PARC, hamilton@parc.xerox.com
Andre van der Hoek, University of Colorado, Boulder, Andre van der Hoek, University of Colorado, Boulder,
andre@bigtime.cs.colorado.edu andre@cs.colorado.edu
Del Jensen, Novell, dcjensen@novell.com Del Jensen, Novell, dcjensen@novell.com
Gail Kaiser, Columbia University, kaiser@cs.columbia.edu Gail Kaiser, Columbia University, kaiser@cs.columbia.edu
Rohit Khare, World Wide Web Consortium, khare@w3.org Rohit Khare, World Wide Web Consortium, khare@w3.org
Mike Little, Bellcore, little@bellcore.com Mike Little, Bellcore, little@bellcore.com
Dave Long, America Online, dave@sb.aol.com Dave Long, America Online, dave@sb.aol.com
Henrik Frystyk Nielsen, World Wide Web Consortium, frystyk@w3.org Henrik Frystyk Nielsen, World Wide Web Consortium, frystyk@w3.org
Ora Lassila, Nokia Research Center, ora.lassila@research.nokia.com Ora Lassila, Nokia Research Center, ora.lassila@research.nokia.com
Larry Masinter, Xerox PARC, masinter@parc.xerox.com Larry Masinter, Xerox PARC, masinter@parc.xerox.com
Murray Maloney, SoftQuad, murray@sq.com Murray Maloney, SoftQuad, murray@sq.com
Jim Miller, World Wide Web Consortium, jmiller@w3.org Jim Miller, World Wide Web Consortium, jmiller@w3.org
Howard S. Modell, Boeing, howard.s.modell@boeing.com
Keith Moore, University of Tennessee, Knoxville, moore@cs.utk.edu Keith Moore, University of Tennessee, Knoxville, moore@cs.utk.edu
Jon Radoff, NovaLink, jradoff@novalink.com Jon Radoff, NovaLink, jradoff@novalink.com
Alan Robertson, alanr@bell-labs.com Alan Robertson, alanr@bell-labs.com
Henry Sanders, Microsoft,
Andrew Schulert, Microsoft, andyschu@microsoft.com Andrew Schulert, Microsoft, andyschu@microsoft.com
Christopher Seiwald, Perforce Software, seiwald@perforce.com Christopher Seiwald, Perforce Software, seiwald@perforce.com
Einar Stefferud, stef@nma.com Einar Stefferud, stef@nma.com
Richard Taylor, U.C. Irvine, taylor@ics.uci.edu Richard Taylor, U.C. Irvine, taylor@ics.uci.edu
Robert Thau, MIT, rst@ai.mit.edu Robert Thau, MIT, rst@ai.mit.edu
Sankar Virdhagriswaran, sv@hunchuen.crystaliz.com Sankar Virdhagriswaran, sv@hunchuen.crystaliz.com
Gregory J. Woodhouse, gjw@wnetc.com Gregory J. Woodhouse, gjw@wnetc.com
7. References 7. References
[1] T. Berners-Lee, D. Connolly, "HyperText Markup Language [AC] J. Radoff, "Requirements for Access Control within
Specification - 2.0", RFC 1866, MIT/LCS, November 1995. Distributed Authoring and Versioning Environments on the World
Wide Web".
[2] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource
Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota,
December 1994.
[3] P. Feiler, "Configuration Management Models in Commercial [CM] P. Feiler, "Configuration Management Models in Commercial
Environments", Software Engineering Institute Technical Report Environments", Software Engineering Institute Technical Report
CMU/SEI-91-TR-7, CMU/SEI-91-TR-7,
<http://www.sei.cmu.edu/products/publications/91.reports/91.tr.007.html> <http://www.sei.cmu.edu/products/publications/91.reports/91.tr.007.html>
[4] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and [HTML] T. Berners-Lee, D. Connolly, "HyperText Markup Language
Specification - 2.0", RFC 1866, MIT/LCS, November 1995.
[HTTP] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and
T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068,
U.C. Irvine, DEC, MIT/LCS, January 1997. U.C. Irvine, DEC, MIT/LCS, January 1997.
[5] A. Haake, D. Hicks, "VerSE: Towards Hypertext Versioning Styles", [ISO 10646] ISO/IEC 10646-1:1993. "International Standard --
Information Technology -- Universal Multiple-Octet Coded Character
Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane."
[URL] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource
Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota,
December 1994.
[VSE] A. Haake, D. Hicks, "VerSE: Towards Hypertext Versioning Styles",
Proc. Hypertext'96, The Seventh ACM Conference on Hypertext, 1996, Proc. Hypertext'96, The Seventh ACM Conference on Hypertext, 1996,
pages 224-234. pages 224-234.
8. Authors' Addresses 8. Authors' Addresses
Judith Slein Judith Slein
Xerox Corporation Xerox Corporation
800 Phillips Road 128-29E 800 Phillips Road 128-29E
Webster, NY 14580 Webster, NY 14580
skipping to change at line 858 skipping to change at line 876
Fax: 714-824-4056 Fax: 714-824-4056
EMail: ejw@ics.uci.edu EMail: ejw@ics.uci.edu
David G. Durand David G. Durand
Department of Computer Science Department of Computer Science
Boston University Boston University
Boston, MA Boston, MA
EMail: dgd@cs.bu.edu EMail: dgd@cs.bu.edu
Expires November 30, 1997 Expires January 24, 1998
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/