draft-ietf-webdav-requirements-01.txt   draft-ietf-webdav-requirements-02.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-01.txt> F. Vitali <draft-ietf-webdav-requirements-02.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
July 24, 1997 August 29, 1997
Expires January 24, 1998 Expires February 28, 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 71 skipping to change at line 71
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.
some elements that are being debated in the working group. The following
elements are still under discussion:
o Whether support for multi-resource locking is needed
o Whether support for query on properties and links is needed
o What requirements there should be for internationalization
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 115 skipping to change at line 109
Properties 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
Variants
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 [HTTP]. the HTTP 1.1 specification [HTTP].
Client Client
A program which issues HTTP requests and accepts responses. A program which issues HTTP requests and accepts responses.
skipping to change at line 171 skipping to change at line 166
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.
User Agent User Agent
The client that initiates a request. The client that initiates a request.
Variant
A representation of a resource. A resource may have one or more
representations associated with it at any given time.
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 258 skipping to change at line 257
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. Properties 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, read and delete arbitrary
properties on resources of any media type. properties on resources of any media type.
5.1.2. Rationale 5.1.2. Rationale
Properties 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
properties have many uses, such as supporting searches on property 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, read and delete typed
links between resources of any media type. links between resources of any media type.
5.2.2. Rationale 5.2.2. Rationale
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,
skipping to change at line 721 skipping to change at line 721
It allows browsing through past and alternative versions of a resource. It allows browsing through past and alternative versions of a resource.
Frequently the modification and authorship history of a resource is Frequently the modification and authorship history of a resource is
critical information in itself. critical information in itself.
It provides stable names that can support externally stored links for It provides stable names that can support externally stored links for
annotation and link-server support. Both annotation and link servers annotation and link-server support. Both annotation and link servers
frequently need to store stable references to portions of resources frequently need to store stable references to portions of resources
that are not under their direct control. By providing stable states of that are not under their direct control. By providing stable states of
resources, version control systems allow not only stable pointers into resources, version control systems allow not only stable pointers into
those resources, but also well-defined methods to determine the those resources, but also well-defined methods to determine the
relationships of those states of a resource. relationships of those states of a resource.
It allows explicit semantic representation of single resources with It allows explicit semantic representation of single resources with
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. Variants
5.10.1. Authentication. The WebDAV specification should state how the 5.10.1. Functional Requirements
It must be possible to send variants to the server, describing the
relationships between the variants and their parent resource. In
addition, it must be possible to write and retrieve variants of
property labels, property descriptions, and property values.
5.10.2. Rationale
The HTTP working group is addressing problems of content negotiation
and retrieval of variants of a resource. To extend this work to an
authoring environment, WEBDAV must standardize mechanisms for authors
to use when submitting variants to a server. Authors need to be able
to provide variants in different file or document formats, for different
uses. They need to provide variants optimized for different for different
clients and for different output devices. They need to be able to provide
variants in different languages in the international environment of the Web.
In support of internationalization requirements (See 5.12 below), variants
need to be supported not just for the content of resources, but for any
information intended for human use, such as property values, labels, and
descriptions.
5.11. Security
5.11.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 specified 5.11.2. Access Control. Access control requirements are specified
in a separate access control draft [AC]. in a separate access control draft [AC].
5.10.3. Interoperability with Security Protocols. The WebDAV 5.11.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.12. Internationalization
5.11.1. Functional Requirement 5.12.1. Character Sets and Languages
For transmission of information intended for user comprehension, Since Web distributed authoring occurs in a multi-lingual
the full Universal Character Set (UCS) [ISO 10646] must be available. environment, information intended for user comprehension must
Language information and negotiation must be available where conform to the IETF Character Set Policy [CHAR]. This policy
appropriate. addresses character sets and encodings, and language tagging.
5.11.2. Rationale 5.12.2. Rationale
In the international environment of the Internet, it is important In the international environment of the Internet, it is important
to insure that any information intended for user comprehension will to insure that any information intended for user comprehension can be
be transported in a form that makes it possible to display the displayed in a writing system and language agreeable to both the
information in any writing system and language agreeable to both the
client and the server. The information encompassed by this requirement client and the server. The information encompassed by this requirement
includes not only the content of resources, but also display names includes not only the content of resources, but also such things as
and descriptions of properties, property values, and status messages. 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 Terry Allen, tallen@sonic.net
Alan Babich, FileNet, babich@filenet.com Alan Babich, FileNet, babich@filenet.com
Dylan Barrell, Open Text, dbarrell@opentext.ch Dylan Barrell, Open Text, dbarrell@opentext.ch
skipping to change at line 795 skipping to change at line 818
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, Thomson Consumer Electronics, FisherM@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@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
Ora Lassila, Nokia Research Center, ora.lassila@research.nokia.com
Ben Laurie, A.L. Digital, ben@algroup.co.uk
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
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 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
Henrik Frystyk Nielsen, World Wide Web Consortium, frystyk@w3.org
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, 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
Dan Whelan, FileNet, dan@FILENET.COM
Gregory J. Woodhouse, gjw@wnetc.com Gregory J. Woodhouse, gjw@wnetc.com
7. References 7. References
[AC] J. Radoff, "Requirements for Access Control within [AC] J. Radoff, "Requirements for Access Control within
Distributed Authoring and Versioning Environments on the World Distributed Authoring and Versioning Environments on the World
Wide Web". Wide Web".
[CHAR] H.T. Alvestrand, "IETF Policy on Character Sets and Languages",
June 1997, working draft, draft-alvestrand-charset-policy-00.txt.
[CM] 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>
[HTML] T. Berners-Lee, D. Connolly, "HyperText Markup Language [HTML] T. Berners-Lee, D. Connolly, "HyperText Markup Language
Specification - 2.0", RFC 1866, MIT/LCS, November 1995. Specification - 2.0", RFC 1866, MIT/LCS, November 1995.
[HTTP] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and [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,
skipping to change at line 876 skipping to change at line 905
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 January 24, 1998 Expires February 28, 1998
 End of changes. 

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