[Prev][Next][Index][Thread]
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