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)
2. Multi-Resource Locking: Do authors need to be able to lock multiple
resources as an atomic operation? (5.3.1.2)
3. Locking Model: Must servers support the WebDAV versioning model in its
complete generality? (5.9.1.3)
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)
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)
6. Backward Compatibility: Should the backward compatibility requirements be
strengthened? (4.3 - 4.4)
7. Structured Documents: Are there requirements for structured documents
beyond what could be supported by collections?
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?

New Requirements:
1. Authentication:  As an extension to HTTP, WEBDAV should make use of
HTTP's authentication support.
2. Access Control:  Access control requirements are TBD, and may eventually
be specified in a separate AC draft.
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
4. Internationalization: (suggestions for what to say here are welcome)
5. It must be possible to take out a write lock on a resource in shared mode
or exclusive mode.

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.
GENERAL: Detailed semantics of copy / move will be removed in favor of
high-level definitions of the copy and move operations.
1. Introduction:  State explicitly that we are extending HTTP.
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.
        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.
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.
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.
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 16:44:47 UTC