W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1997

Comments on Section 4.1 to 4.8 of the requirements document

From: Yaron Goland <yarong@microsoft.com>
Date: Tue, 11 Feb 1997 17:09:12 -0800
Message-ID: <c=US%a=_%p=msft%l=RED-44-MSG-970212010912Z-456@INET-03-IMC.itg.microsoft.com>
To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
	4.1. Attributes

	Via HTTP, it should be possible to create, modify, query, read and 
	delete arbitrary attributes on resources of any media type.

	***Judy - Query is not supported in the specification.

Judy, please refer to the section on linksearch for information on how
to query an attribute.

	4.3.1.2. Multi-Resource Locking. It should be possible to take out a 
	lock on multiple resources in the same action, and this locking 
	operation must be atomic across these resources.

	***Judy - Multi-resource locking is not in the specification

Judy is correct. It is currently envisioned that this requirement will
be met by a multipart/related MIME type containing a header indicating
that the contents must be executed atomically. I am actually in favor of
using a method for this purpose.

	4.3.1.4. Multi-Person Locking.  It should be possible to assign a lock
	to a single person or to multiple persons with a single action.

	***Judy - Multi-person locking is not in the specification.

Please provide a rational for requirement this or remove it.

	4.3.2.1.  Write Locks. It should be possible, via HTTP, to restrict 
	modification of a resource to a specific person, or list of persons.

	***Fabio - The definition of a write lock should be this:  A write lock
	states that no consistency problem will ever occur by changing the
	resource, not that no one else is allowed access to that resource.  On
	the other hand, it can be said that access rights to successfully
	Unlocked resources should be allowed to all authorized users.

There are two kinds of locks. Advisory and mandatory. Advisory locks are
notes, they say "Hey, someone has locked this." However they prevent no
class of action on the part of a client. A mandatory lock prevents
anyone who doesn't have a lock from executing an action covered by the
lock. So if someone has an exclusive write lock, no one else may write
to that resource. Many systems require a mandatory lock in order to
operate properly. These systems will break if only advisory locks are
available. As such we MUST provide for mandatory locks. This having been
said, we should also ensure that systems which do not use locking will
still function properly.

	4.3.2.2.  Read Locks. It should be possible, via HTTP, to indicate to 
	the HTTP server that the contents of a resource should not be modified 
	until the read lock is released.

	***Judy - Read locks are not in the specification.

We should specify how a read lock is provided but we should not require
that it be implemented, even if a write lock is implemented.

	4.3.2.3. Lock Query. It should be possible to query for whether a given
	URL has any active modification restrictions, and if so, who currently
	has modification permission.

The previous should be modified to read "Subject to access restrictions,
it should be possible to query for whether a given URL has any active
modification restriction...".

	***Judy - Should add Unlock.

I would suggest:
4.3.2.4. Unlock. It must be possible to remove a lock. Locks may only be
removed by those who set the lock or by entities with appropriate access
rights.

	4.4. Notification of Intention to Edit. 

	It should be possible to notify the HTTP server that a resource is
about 
	to be edited by a given person. It should be possible to query the HTTP
	server for the list of people who have notified the server of their 
	intent to edit a resource.

	***Judy - It should be possible to notify the server that one no longer
	intends to edit the resource.

I would suggest adding the following sentence:
It must be possible for those who placed a notification to edit, or a
properly authorized entity, to remove a notification to edit.

	***Judy - Support for notification of intent to edit is found in the
	specification only in the context of version management.  The 
	specification does not allow such notification for non-versioned
	resources.

That is because notification to edit was really meant for versioning. It
was also a design trade off. We MUST not fall into the trap of having a
requirements document which prevents us from making design trade offs.

	4.5. Retrieval of Unprocessed Source for Editing

	The source of any given entity should be retrievable via HTTP.

	***Judy - Not in the specification.

Judy, please refer to the source link in the specification. It has been
part of the specification for some time. In general I think this
requirement is almost meaningless because of the complexity of source -
output relations. As mentioned in the requirement, there are both single
and multistep relationships. These relationships have their own
sub-relationships. There is no way to capture them in a totally generic
way. The best we can do is provide a link mechanism and allow for the
definition of source relationships on a content-type basis.

	4.6. Partial Write. 

	After editing a resource, it should be possible, via HTTP, to write 
	only the changes to the resource, rather than retransmitting the entire
	resource.

	***Judy - Not in the specification.

It is true that the current specification does not provide for support
of partial writes. The authors had mistakenly thought that the HTTP 1.1
content-range header provided for this support.

	4.8. Collections

	4.8.1. List Collection. A listing of all resources, along with
	their media type, and last modified date, which are located in a
	specific collection should be accessible via HTTP.

	***Judy - Not in the specification.

Please refer to the section on collections and their manipulation.
Received on Wednesday, 12 February 1997 10:16:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:42 GMT