- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Tue, 22 Apr 1997 15:57:27 -0700
- To: w3c-dist-auth@w3.org
A few clarifications. >At 01:25 PM 4/10/97 PDT, Mike Little wrote: >>Judy, >> Thanks for the list of requirements issues, it's much appreciated. >>I'd like to ask for some clarification on a couple of the issues. >> >> >>While I have the editor running, I have the following comments concerning >>the changes asked for by Jim and Yaron: >> >>>3. Do not say which functionality is mandatory or optional. >> >> If this is to expedite discussion and keep the work moving >> along where it has otherwise led to unresolved discussion, >> I support this. Otherwise, I can't see the point of continuing >> the working group if the decision is just to publish a document >> of good suggestions of things that can be done concerning >> web distributed authoring and versioning. I can see ironing out >> the "must" and "should" near the end of the effort, but I can't >> see dropping it completely. >> > >They were just talking about the requirements document, not the protocol >spec. They certainly do intend to be clear about what is required for >compliance in the spec. Our intent was to push statements about which functionality is optional or mandatory into the protocol specification. The Design Team found that the dependencies between features in the protocol specification changed as we considered different designs, and these changing dependencies have some affect on whether a feature should be mandatory or optional. Rather than hardwire statements about mandatory or optional functionality into the requirements, which would then need to be changed based on changes in the design, it seemed more prudent to treat the requirements document as a series of MUST statements about what functionality should be in the interface described in the protocol specification document, but let the protocol document be the final word on whether a particular functionality was mandatory or optional. >>>12. Get rid of the requirements that copy and move leave audit trails. >> >>Are audit trails being dropped altogehter? If one wants to worry about >>authenticating users then one should be worrying about audit trails in >>a versioning system (at least, in the presence of versioning semantics >>such as "give me the newest version" or any time there are multiple >>participants potentially involved in the same activity). Lest I sound >>too harsh, are audits being kept for version establishment, but not for >>intermediate actions such as move or delete? That would be reasonable. >> > >Good questions. We haven't been paying enough attention to security issues >up till now. I'm not sure whether this request from Jim and Yaron was just >part of their general campaign to get me to be less detailed in the >requirements, or whether they really are opposed to requiring WEBDAV servers >to keep audit trails for copy and move operations. The view of the Design Team is that while audit trails are a good thing, and should be supported in a WebDAV server, we found that requiring audit trails had no effect on the interface for performing WebDAV operations (it's a side effect of other operations). Since we view the requirements document as describing what should be supported by the interfaces given in the protocol document, a requirement which doesn't impact any interface is viewed as useless. Hence our recommendation to remove the requirement. Also, by audit trail we were intending an operation similar to the current logging employed by servers. So, for example, if you perform a move, the server would record the move, along with the source and destination URLs. We had been viewing the history recording operations of a versioning system as being something different from this kind of audit trail, however, I can definitely understand viewing them similarly. Versioning operations will definitely have to record predecessor and successor relationships, as well as the principal who performed edits on a particular revision. - Jim
Received on Tuesday, 22 April 1997 19:06:05 UTC