Requirements Issues

The version of the requirements document that I distributed today tried to
consolidate the two earlier requirements papers without changing their
content.  Some changes will need to be made before the new document is ready
to be submitted as an Internet Draft.

The requirements are inconsistent with the current specification on many
points, and these need to be resolved.  In addition, the requirements
document takes positions on many issues that have turned out to be
controversial.  The group needs to come to some consensus on these issues.

Since our schedule calls for the requirements document to be submitted as an
Internet Draft by the end of February, I hope that we will be able to
discuss and resolve many of these questions by Monday, February 24.
Whatever issues have been resolved by then can be reflected in the
requirements paper that gets submitted.

Requirements not satisfied by the specification:

1.  Attributes.  The current specification says almost nothing explicitly
about attributes, although it is possible to deduce a lot about how
attributes would be manipulated from the discussion of links.  I believe
that all the requirements about attributes are satisfied except one: "Via
HTTP, it should be possible to ... query ... arbitrary attributes ..."  We
need to decide whether we want to define a query syntax.  If not, we need to
decide whether we want to support a weaker requirement, for example that the
model of attributes we define should be capable of supporting some query
mechanism.

2.  Locks.  "It should be possible to take out a lock on multiple resources
in the same action."

3.  Locks.  "It should be possible to assign a lock to a single person or to
multiple persons with a single action."

4.  Locks.  The requirements call for support of read locks, which are not
in the specification.

5.  Notification of Intent to Edit.  "It should be possible to notify the
HTTP server that a resource is about to be edited by a given person."  This
requirement is stated independent of versioning, implying that it should be
possible to give this notification even for non-versioned resources.
However, the specification supports notification of intent to edit only in
the context of versioning.

6.  Retrieval of unprocessed source for editing.  Support for this
requirement was accidentally dropped from the specification.

7.  Partial Write.  "After editing a resource, it should be possible via
HTTP to write only the changes to the resource, rather than retransmitting
the entire resource."  Not mentioned in the specification.  Does it need to
be, or is it adequately supported by HTTP already?

8.  List URL Hierarchy Level.  Support for this requirement was accidentally
dropped from the specification.

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

10.  Versioning.  For any URL, it should be possible to find out whether its
resource is a version in some version tree.  It should be possible to find
out what versioned object (version handle) it belongs to.

11.  Version - tracking.  "A way for the server to ensure that the user
operating on a resource is the same one who reserved it." 

Functionality in the specification that is not in the requirements:

1.  Destroy

2.  Undelete

3.  CopyHead

4.  MoveHead

3.  Schema Methods (discovery mechanism)

4.  Diff/Merge

5.  ServerMerge

6.  UnVersion

The following controversial issues need to be resolved:

1.  The requirements (as well as the charter) say that we are extending
HTTP.  Discussions at Irvine made it clear that there is no consensus on
this in the group.

2.  Locking.  The requirements say that it should be possible to lock
subsections of a resource.  The specification does allow this.  But at
Irvine it appeared that there was not consensus on this point.

3.  Copy, Move / Rename.  Discussions at Irvine made it clear that there is
controversy about the desired semantics of these operations, especially for
complex resources like collections, versioned resources, and resources with
attributes.  The requirements are vague and don't address the hard
questions.  Do we want to leave them that way?

4.  Versioning General Principles need to be revisited.  

        - It is not clear that the specification obeys the "Stableness of
Versions" principle. If a user requested to overwrite an existing version
rather than create a new one, there is nothing to prevent that, and nothing
to prevent the server from complying.  Should there be?

        - "Separation of resource retrieval and concurrency control" is
supported by the Request-Lock, Request-Intent, and Request-Working-Loc
parameters to the CheckOut method and the discovery mechanism. This is all
embroiled in the controversy over how much latitude we want to give servers,
how simple we want to make things for clients, whether we want to rely on
the discovery mechanism, etc.

5.  Versioning - uncheckout.  Neither in the requirements nor in the
specification.  Is it needed?
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, 10 February 1997 14:21:01 UTC