Re: Requirements Changes for Your Review

Here are my comments on your requirements changes.

>Open Issues List:
>1. Optional Server Support for Locking: Should the requirements state that
>server support for locking is optional? (5.3.1.4)

I still feel most comfortable leaving declarations of MUST, SHOULD, MAY to
the protocol specification, so I feel this topic should not be addressed by
the requirements document.

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

Hmm.  I differ with Yaron here, in that I feel this should definitely be
addressed in the requirements document.  It also is an open issue.

>3. Locking Model: Must servers support the WebDAV versioning model in its
>complete generality? (5.9.1.3)

I think the language currently in 5.9.1.3 is correct, expect that I would
change the sentence,

"The WebDAV extensions must support this versioning model, though
particular servers may restrict it in various ways."

so that the first must is a should, which is what is really means anyway.

If you have an SCCS back end, you won't can't easily support DAG version
histories, so such a system would only provide linear versioning.  However,
a system with an RCS back end, which can support DAGs, should support the
full versioning model.

I thought this was pretty well settled -- what made you think this was an
open issue?

>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)

This does look strange.  I think the best course is to delete 5.9.2.8 since
5.9.2.9 adequately describes the behavior we desire (a client can specify
an identifier, which the server does not have to use, in which case the
server generates its own version identifier.)

>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)

I'd be happy to remove this requirement.

>6. Backward Compatibility: Should the backward compatibility requirements be
>strengthened? (4.3 - 4.4)

I'm not sure how 4.4 could be strengthened since it is already quite
strong.  Similarly, I think 4.3 is sufficiently strong for our needs.  Did
you have something in mind?

>7. Structured Documents: Are there requirements for structured documents
>beyond what could be supported by collections?

I don't believe so.

>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?

I think not.  As you know, the fundamental difficulty is making a
requirement that can be satisfied without server to server communication.
Furthermore, even on one server, there is the issue of making move and
delete have scope beyond just the resource on which the method is being
invoked, and the wide range of issues this raises (e.g., what should happen
if move goes to update a link on another resource but that resource is
exclusively locked by another principal?).

My preference is to not make requirements that would lead to extremely
complex move and delete commands -- they are getting quite complex just
with handling on-resource metadata.

>New Requirements:
>1. Authentication:  As an extension to HTTP, WEBDAV should make use of
>HTTP's authentication support.

I agree with Yaron that this statement is not needed, however, I think a
statement along the lines of:

The WebDAV extensions should describe how they interoperate with existing
authentication schemes, and recommendations for use."

Would be useful.  For example, we may end up having a section on
interoperability with the simple public key infrastructure (SPKI) work, so
the requirement should be inclusive enough to allow this.

>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

I think this is a good requirement, although I think the MUST is too
restrictive, and should be changed to a SHOULD.  There may be times when I
don't care whether a security layer is present, and there is plenty of
current distributed authoring practice which doesn't require a security
layer (e.g. the BSCW system).

>4. Internationalization: (suggestions for what to say here are welcome)

A statement on internationalization is definitely worthwhile -- I'm not
sure if there are any RFCs which give standard requirements for
international capability.  Perhaps check other protocols for their
internationalization requirements?

>5. It must be possible to take out a write lock on a resource in shared mode
>or exclusive mode.

Well, the shared write lock currently is what was intended by a
reservation, as described in 5.4.  So if this requirement is adopted, I
feel section 5.4 can be removed.

I think dividing this into two requirements makes sense.

Exclusion.  It must be possible to limit the scope of a lock to a single
principal.

Shared.  It must be possible to share the scope of a lock across multiple
principals.

Also, 5.3.2.1 should have "person" changed to "principal".

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

I like this.

>GENERAL: Detailed semantics of copy / move will be removed in favor of
>high-level definitions of the copy and move operations.

I like this.

>1. Introduction:  State explicitly that we are extending HTTP.

I'm not as hung up on the precise semantics as Yaron, but it is probably
more correct to state that we are developing an "extension to HTTP" than
"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)

Except for the fact that I think the reservations section should just be
deleted, I like this outline.  It will definitely help us issue this as an
Informational RFC to have the security and internationalization sections.

>3. Terminology
>        "Link" replaces "Relationship"

*sniff*  OK. :-)

>        "Reservation": An advisory lock, a declaration to the server
>that one intends to edit a resource.

Just get rid of the term altogether.

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

I like these.

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

I like this.

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

OK.

>8. The section on reservations will be folded into the section on locking.
>Reservations will be treated as one type of lock.

As I've said, my preference is to delete the entire reservation section.

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

OK.

Whew!  Thank you for your hard work producing this list!

- Jim

Received on Tuesday, 20 May 1997 22:27:50 UTC