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/