Requirements -- Thanks for your comments

Thanks to everyone who wrote comments on requirements issues, but especially
to Yaron and Jim for carefully reading and commenting on the whole list.

Let me try to summarize where things stand.

Larry Masinter suggested that rather than deleting any requirements
altogether, I should move them to a section that discusses requirements that
were considered but rejected. If the same requirement should be proposed
again later, we would have a record of why it was rejected. I'll follow this
advice.

Open Issues List:
1. Optional Server Support for Locking: Should the requirements state that
server support for locking is optional? (5.3.1.4)
Resolution: We'll leave it up to the specification to state which
functionality is mandatory and which is optional.  Requirement 5.3.1.4 will
be deleted.
This issue is closed.

2. Multi-Resource Locking: Do authors need to be able to lock multiple
resources as an atomic operation? (5.3.1.2)
This remains an open issue.

3. Versioning Model: Must servers support the WebDAV versioning model in its
complete generality? (5.9.1.3)
The requirement will stay as it is, except that "must" will be changed to
"should".  So after the description of the WEBDAV versioning model, it will
say: "The WebDAV extensions should support this versioning model, though
particular servers may restrict it in various ways."
This issue is closed.

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)
No.
There is already a requirement that there be a way to refer to each member
of a version graph (5.9.2.2).  There is already a requirement that the
client be able to propose a version identifier to be used for a new version,
which the server can refuse to use (5.9.2.9).  I'll add a sentence to
5.9.2.9 saying that when a new member is added to a version graph, the
server should include the URL of the new member in its response.
This issue is closed.

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)
Requirement 5.9.2.14 for server-side merge will be deleted.
This issue is closed.

6. Backward Compatibility: Should the backward compatibility requirements be
strengthened? (4.3 - 4.4)
Jim: What did you have in mind?
Yaron: Propose something specific.
Based on the Web Browser WEBDAV Support thread started by Jon Radoff, it
looked as if there might be interest in some additional backward
compatibility requirement like:  "It should be possible for the WEBDAV
extensions to be implemented in such a way that standard HTTP browsers can
support them."

7. Structured Documents: Are there requirements for structured documents
beyond what could be supported by collections?
No.
This issue is closed.

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?
No.
This issue is closed.

9. Access control requirements

10. Internationalization: (suggestions for what to say here are welcome)
Related rfc's: 2045, 2047, 2070
WebDAV should support any character set in entity bodies, header values,
metadata definitions and values.
WebDAV should support language negotiation for entity bodies, metadata values.

11. I don't think we have consensus on the relationship between locks and
reservations.  Jim believes that a reservation is a type of lock:  an
advisory lock or a shared lock.  Yaron believes that, although we may choose
to implement reservations as locks, conceptually they are a statement to the
server of an intent to edit, which could be implemented in some other way.
For now, I'll leave the reservations section separate from the section on
locking, and define reservation in a way that does not mention locks, but
this needs further discussion.

12. EMail (back on the list in light of discussions of the past few days)

New Requirements:
1. Authentication:  The wording will be:
"The WebDAV extensions should describe how they interoperate with existing
authentication schemes, and should make recommendations for using those
schemes."

2. Access Control:  Access control requirements are TBD, and may eventually
be specified in a separate AC draft.
(Access control will also be added to the open issues list.)

3. Interoperability with Security Protocols:  The spec should provide a
minimal list of security protocols which any compliant server / client
should support.  These protocols should provide for privacy and integrity of
messages in transit, authenticity of messages, and non-repudiability of origin.

4. Internationalization: Internationalization requirements are TBD.
(Internationalization will also be added to the open issues list.)

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 since WebDAV is using
HTTP 1.1 as the basis of its work, 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 developing an extension to HTTP.

2. Categories of Functionality:
        Attributes
        Links (replaces Relationships)
        Locking
        Reservations
        Retrieval of Unprocessed Source
        Partial Write
        Name Space Manipulation
        Collections
        Versioning
        Security (new)
        Internationalization (new)

3. Terminology
        "Link" replaces "Relationship"
        "Reservation": 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.
[The wording here is taken straight from our charter, so if it's not
acceptable, it needs to be removed from the charter.]

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 requirement for partial-resource locking will be removed.

9. Nothing will be said about who can perform an Unlock operation.

10. The discussion of single-step vs. multi-step source processing in
section 5.5.2 will be removed.

11. 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.

12. 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.

13. The requirements for audit trails of copies and moves will be removed.

14. Section 5.7.3 on the HTTP DELETE method will be removed.

15. Section 5.8.1.4 Remove from Collection will simply say that it must be
possible to remove a resource from a collection.

16. 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.

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 Tuesday, 27 May 1997 11:50:07 UTC