Requirements Issues and Proposals

To keep the discussion of requirements moving along, please comment on the
following:

1. Fabio's new draft of the versioning part of the requirements paper.  He
sent this out on February 14 in "Re: General Comment on the Requirements Spec".

2. In addition, here is a list of unresolved and new issues, followed by a
list of issues that I think have been resolved, with my proposals for how to
comprehend them in the requirements paper.

UNRESOLVED ISSUES:

How much latitude do compliant servers (server administrators) have to
decide policy?  We’ve said that we want a protocol that is simple for
clients.  One way to make this possible is to enforce a single policy for
servers.  Or we could compromise and allow some small amount of flexibility,
adding a little complexity for clients that we think they can tolerate.  Or
we can expose only a simple level of functionality and let servers do what
they wish beyond that, hiding it from clients.  Or we can let servers have
flexibility, but expose it to clients by a very simple mechanism.  Or…

Is there agreement that "Notification of Intent to Edit" has no use outside
the context of versioning?

Diff/Merge – no requirement for this.  Should we add one?

ServerMerge – no requirement for this.  Should we add one?

UnVersion – no requirement for this.  Should we add one?

Range locking – is this required?

NEW ISSUES:

Should the requirements say anything about which functionality is mandatory
and which is optional?

Is a WebDAV server required to support locking?  Is a WebDAV server required
to support attributes?  Is it required to do versioning?  If so, are there
parts of the versioning functionality that are mandatory and other parts
that are optional?  Etc.

Need to agree on terminology between requirements and specification.
Version
Versioned Resource
Resource
Entity
Principal
User Agent
Server
Client
User

PROPOSALS:

Requirements will be revised to avoid making any design commitments.  In
particular, we will no longer identify extending HTTP as an overall
strategy, and we will remove any suggestion of extending or modifying URL
syntax.

Legacy client support – keep but make more precise.

Attribute query – keep requirement.
 
Multi-resource locks – keep requirement.

Multi-person locks – drop requirement.

Read locks – drop requirement.

Retrieve unprocessed source – keep requirement.

Partial Write – keep requirement.  Do we need to propose a standard way to
encode partial update information?

List collection – keep requirement.

Versioning / navigation.  The requirements state that from any version, it
should be possible to find the root.  It should be possible to navigate to
the predecessor.  – keep requirement.

Versioning.  For any resource, it should be possible to find out whether it
is a version in some version tree.  It should be possible to find out what
versioned object (version handle) it belongs to. – keep requirement, but
express in a design-neutral way

Version / tracking.  "A way for the server to ensure that the user operating
on a resource is the same one who reserved it." – keep requirement.

Uncheckout – add requirement.

Unlock – add requirement.

Destroy, Undelete, CopyHead, MoveHead, Schema Methods (discovery mechanism)
– assuming that these will be dropped from the spec, so that we do not need
to add requirements for them.

Try to express locking and versioning requirements in a design-neutral way.
Will this be possible?

General principle:  Simple client protocol for interoperability with all
compliant servers.

General principle:  If the server did not do what the client requested, it
reports FAILURE with a reason.
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, 17 February 1997 08:55:14 UTC