RE: Requirements Changes for Your Review

Please see comments below.

> -----Original Message-----
> From:	Judith Slein [SMTP:slein@wrc.xerox.com]
> Sent:	Monday, May 19, 1997 1:48 PM
> To:	w3c-dist-auth@w3.org
> Subject:	Requirements Changes for Your Review
> 
> I intend to submit a new draft of the webdav requirements to the IETF
> by the
> end of the month.  Here are three lists for you to review:
> a list of open issues, a list of new requirements, and a list of
> changes to
> existing requirements.
> 
> The open issues will appear in the introduction of the requirements ID
> unless they can be resolved.  The new requirements and changes will go
> into
> the ID unless I hear objections.  They are based on discussion at the
> Memphis IETF meeting, requests from the specification authors team,
> and
> discussion on the mailing list since Memphis.
> 
> Open Issues List:
> 1. Optional Server Support for Locking: Should the requirements state
> that
> server support for locking is optional? (5.3.1.4)
> 
> [Yaron Goland]  One can at best ask if certain types of locks will be
> required. Given that the current agreement within the group is that
> locking is one axis where totally flexibility must be allowed, it
> would seem inappropriate to place requirements on support.
> 
> 2. Multi-Resource Locking: Do authors need to be able to lock multiple
> resources as an atomic operation? (5.3.1.2)
> 
> [Yaron Goland]  Clearly authors have circumstances when they need to
> be able to lock multiple resources atomically, the relevant question
> is - what are those circumstances? However this requires an additional
> consideration, what sort of functionality is required? Is it
> sufficient to develop a mechanism by which one may ask for a lock on
> multiple resources in an atomic manner? Must we require that the
> server provide the mechanisms to allow such lock requests to succeed?
> I believe that these questions should not be addressed by the
> requirements document. The document should only address the
> fundamental need for some sort of locking mechanism, which clients and
> servers may optionally make use of. The rest of the questions, such as
> atomicity, are really implementation questions which need to be more
> fully examined within the domain of the protocol specification.
> 
> 3. Locking Model: Must servers support the WebDAV versioning model in
> its
> complete generality? (5.9.1.3)
> 
> [Yaron Goland]  I am not familiar with anyone who has stated that a
> base level DAV server must support versioning. It has always been the
> case that we would provide different levels of functionality, at
> minimum between versioning and non-versioning systems.
>  
> 4. Server-generated version ids: Is there a requirement for clients to
> be
> able to request that the server generate an id for a new version?
> (5.9.2.8)
> 
> [Yaron Goland]  Deciding to use version ids or just URLs is something
> to be debated and settled as part of the protocol. The best the
> requirements can say is that there must exist some method for
> addressing particular versions. 
> 
> 5. Server-side Merge: Is there a requirement for authors to be able to
> request a server to merge two or more resources? (5.9.2.14)
> 
> [Yaron Goland]  I will be writing a spec to do server side merges but
> I don't particularly care if it is in the protocol spec or a separate
> RFC.
> 
> 6. Backward Compatibility: Should the backward compatibility
> requirements be
> strengthened? (4.3 - 4.4)
> 
> [Yaron Goland]  The requirement statement is too vague to allow a
> response.
> 
> 7. Structured Documents: Are there requirements for structured
> documents
> beyond what could be supported by collections?
> 
> [Yaron Goland]  Currently no proposals or objections exist to any of
> the general collection mechanisms. Until one is brought up, this point
> should be removed.
> 
> 8. Link Integrity:  A lot of webdav functionality is likely to be
> implemented with links.  Should servers be required to do anything to
> help
> insure link integrity when resources are moved / deleted?
> 
> [Yaron Goland]  This is not a requirement, this is a sentiment. Until
> there is a specific proposal for requirements language there is no
> open issue. This point should be removed.
> 
> New Requirements:
> 1. Authentication:  As an extension to HTTP, WEBDAV should make use of
> HTTP's authentication support.
> 
> [Yaron Goland]  We are based on HTTP 1.1, we therefore use all HTTP
> 1.1 mechanisms. There is no need for this requirement, it should be
> removed.
> 
> 2. Access Control:  Access control requirements are TBD, and may
> eventually
> be specified in a separate AC draft.
> 
> [Yaron Goland]  Shouldn't this be listed as an open issue then?
> 
> 3. Interoperability with Security Protocols:  The spec should provide
> a
> minimal list of security protocols which any compliant server / client
> must
> support.  These protocols should provide for privacy and integrity of
> messages in transit, authenticity of messages (mutual authentication
> of
> client and server), non-repudiability of origin. should prevent
> forgery of
> messages
> 
> [Yaron Goland]  Two specs already exist which fully address the issue,
> RFC 2068 and RFC 2069.
> 
> 4. Internationalization: (suggestions for what to say here are
> welcome)
> 
> [Yaron Goland] If there is no requirements language, there is no
> proposal.
>  
> 5. It must be possible to take out a write lock on a resource in
> shared mode
> or exclusive mode.
> 
> [Yaron Goland]  The argument over what kind of lock type to support
> has been a long and contentious one. The requirements spec should only
> say that a locking mechanism must be defined. The actual nature of it
> should be decided by the protocol based on negotiations over what
> features to maintain and which to drop. This requirement should be
> removed.
> 
> Proposed changes:
> GENERAL: All specific requirements related to existing HTTP methods
> will be
> replaced by a general principle to the effect that the WebDAV spec
> must
> explicitly address needed changes to existing HTTP methods.
> 
> [Yaron Goland]  We are not changing HTTP 1.1. We are not extending
> HTTP 1.1. We are using HTTP 1.1 as a generic application level
> transport upon which to build new functionality. To say we are
> extending HTTP 1.1 is like saying one is extending C when one defines
> a new function. C has not changed, one has simply taken advantage of
> C's facilities to define desired functionality.
> 
> GENERAL: Detailed semantics of copy / move will be removed in favor of
> high-level definitions of the copy and move operations.
> 
> [Yaron Goland]  Without having seen the actual language there is not
> much I can say but given the painful lengths we have gone through just
> to define copy and move and given that even Jim's heroic attempts do
> not appear to be sufficient, I should think the requirement spec would
> want to keep the definitions at as general a level as possible in
> order to allow the group to bring its full creativity to the issue.
> 
> 1. Introduction:  State explicitly that we are extending HTTP.
> 
> [Yaron Goland]  Please see my previous comment on the issue.
>  
> 2. Categories of Functionality:
>         Attributes
>         Links (replaces Relationships)
>         Locking (merged with Reservations)
>         Retrieval of Unprocessed Source
>         Partial Write
>         Name Space Manipulation
>         Collections
>         Versioning
>         Security (new)
>         Internationalization (new)
> 3. Terminology
>         "Link" replaces "Relationship"
>         "Reservation": An advisory lock, a declaration to the server
> that one intends to edit a resource.
> 
> [Yaron Goland]  The requirement should only say that there must be
> some mechanism to indicate an intent to edit. How this mechanism is
> defined is up to the protocol. We might do it as a header, we might do
> it as a method, currently we do it with LOCK. Either way, that is an
> implementation issue and should not be specified in the requirements.
> So language such as "advisory lock" should disappear.
> 
>         Shared Lock:  A locking mode that allows additional locks to
> be
> placed on a resource while the shared lock is in force.
>         Exclusive Lock:  A locking mode that prevents any other locks
> from
> being placed on the resource while the exclusive lock is in force.
> 4. New General Principle (replaces all specific discussions of
> implications
> for existing HTTP methods):  Changes to HTTP:  WebDAV adds a number of
> new
> types of objects to the Web: links, collections, version graphs, etc.
> Existing HTTP methods such as DELETE and PUT will have to operate in
> well-defined ways in this expanded environment. WebDAV should
> explicitly
> address not only new methods, headers, and mime types, but also any
> required
> changes to the existing HTTP methods and headers.
> 
> [Yaron Goland]  Please see my previous comments on the topic of DAV
> and HTTP 1.1.
> 
> 5. General Principle 4.7: Alternate Transport Mechanisms: It may be
> desirable to transport WebDAV requests and responses by other
> mechanisms,
> particularly EMail, in addition to HTTP.  The WebDAV protocol
> specification
> should not preclude a future body from developing an interoperability
> specification for disconnected operation via EMail.
> 
> [Yaron Goland]  If we need to do something that breaks e-mail, so be
> it. We are not about distributed authoring over e-mail. We are about
> distributed authoring over HTTP. It is very nice to keep in
> consideration e-mail issues but we should not randomize the group by
> requiring ourselves to maintain interoperability. The last requirement
> should be removed.
> 
> 6. Attributes:  This requirement will be simplified to say only that
> it must
> be possible to create, modify, query, read, and delete arbitrary
> attributes
> on resources of any media type.
> 7. "Relationship" will be changed to "Link" throughout.  The
> requirement for
> links will say simply that it must be possible to create, modify,
> query,
> read and delete links between resources of any media type.
> 8. The section on reservations will be folded into the section on
> locking.
> Reservations will be treated as one type of lock.
> 
> [Yaron Goland]  Please see my previous comments on the issue.
> 
> 9. The requirement for partial-resource locking will be removed.
> 10. Nothing will be said about who can perform an Unlock operation.
> 11. The discussion of single-step vs. multi-step source processing in
> section 5.5.2 will be removed.
> 12. All but the first paragraph of 5.7.1.1 (functional requirements
> for
> Copy) will be removed.  There will no longer be any discussion of the
> semantics of copy for attributes, links, collections, or versions.
> 13. All but the first paragraph of 5.7.2.1 (functional requirements
> for
> Move) will be removed.  There will no longer be any discussion of the
> semantics of move for attributes, links, collections, or versions.
> 14. The requirements for audit trails of copies and moves will be
> removed.
> 15. Section 5.7.3 on the HTTP DELETE method will be removed.
> 16. Section 5.8.1.4 Remove from Collection will simply say that it
> must be
> possible to remove a resource from a collection.
> 17. Section 5.9.2.13 will say that it must be possible for a client to
> request (not get) from the server a list of the differences between
> two or
> more resources of the same media type.
> 
> --Judy
> 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, 19 May 1997 22:30:03 UTC