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

Re: WEBDAV Requirements Changes

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Tue, 22 Apr 1997 15:57:27 -0700
Message-Id: <af82ed750c021004cd37@[128.195.21.209]>
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 GMT

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