- From: Yaron Goland <yarong@microsoft.com>
- Date: Tue, 11 Feb 1997 17:09:12 -0800
- 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 UTC