- From: Judith Slein <slein@wrc.xerox.com>
- Date: Mon, 17 Feb 1997 05:57:21 PST
- To: w3c-dist-auth@w3.org
To keep the discussion of requirements moving along, please comment on the following: 1. Fabio's new draft of the versioning part of the requirements paper. He sent this out on February 14 in "Re: General Comment on the Requirements Spec". 2. In addition, here is a list of unresolved and new issues, followed by a list of issues that I think have been resolved, with my proposals for how to comprehend them in the requirements paper. UNRESOLVED ISSUES: How much latitude do compliant servers (server administrators) have to decide policy? We’ve said that we want a protocol that is simple for clients. One way to make this possible is to enforce a single policy for servers. Or we could compromise and allow some small amount of flexibility, adding a little complexity for clients that we think they can tolerate. Or we can expose only a simple level of functionality and let servers do what they wish beyond that, hiding it from clients. Or we can let servers have flexibility, but expose it to clients by a very simple mechanism. Or… Is there agreement that "Notification of Intent to Edit" has no use outside the context of versioning? Diff/Merge – no requirement for this. Should we add one? ServerMerge – no requirement for this. Should we add one? UnVersion – no requirement for this. Should we add one? Range locking – is this required? NEW ISSUES: Should the requirements say anything about which functionality is mandatory and which is optional? Is a WebDAV server required to support locking? Is a WebDAV server required to support attributes? Is it required to do versioning? If so, are there parts of the versioning functionality that are mandatory and other parts that are optional? Etc. Need to agree on terminology between requirements and specification. Version Versioned Resource Resource Entity Principal User Agent Server Client User PROPOSALS: Requirements will be revised to avoid making any design commitments. In particular, we will no longer identify extending HTTP as an overall strategy, and we will remove any suggestion of extending or modifying URL syntax. Legacy client support – keep but make more precise. Attribute query – keep requirement. Multi-resource locks – keep requirement. Multi-person locks – drop requirement. Read locks – drop requirement. Retrieve unprocessed source – keep requirement. Partial Write – keep requirement. Do we need to propose a standard way to encode partial update information? List collection – keep requirement. Versioning / navigation. The requirements state that from any version, it should be possible to find the root. It should be possible to navigate to the predecessor. – keep requirement. Versioning. For any resource, it should be possible to find out whether it is a version in some version tree. It should be possible to find out what versioned object (version handle) it belongs to. – keep requirement, but express in a design-neutral way Version / tracking. "A way for the server to ensure that the user operating on a resource is the same one who reserved it." – keep requirement. Uncheckout – add requirement. Unlock – add requirement. Destroy, Undelete, CopyHead, MoveHead, Schema Methods (discovery mechanism) – assuming that these will be dropped from the spec, so that we do not need to add requirements for them. Try to express locking and versioning requirements in a design-neutral way. Will this be possible? General principle: Simple client protocol for interoperability with all compliant servers. General principle: If the server did not do what the client requested, it reports FAILURE with a reason. Name: Judith A. Slein E-Mail: slein@wrc.xerox.com Internal Phone: 8*222-5169 External Phone: (716) 422-5169 Fax: (716) 265-7133 MailStop: 128-29E
Received on Monday, 17 February 1997 08:55:14 UTC