Requirements Open Issues from Orem

A new version of the requirements draft will be submitted to the IETF on
Thursday, 7/24.  Your comments on these issues discussed at Orem will be
helpful.

------------

Multiple Resource Locking

As a result of the discussion at Orem, I was asked to raise the issue of
atomic locking of multiple resources to the mailing list one more time.

In an informal vote by those present for the discussion, 9 voted to keep the
requirement, 4 to remove it.  The rest (about 10 others) did not vote.

At the moment, the requirement reads as follows:

5.3.1.2. Multi-Resource Locking. It must be possible to take out a 
lock on multiple resources residing on the same server in a single action,
and this locking operation must be atomic across these resources.

("residing on the same server" was added at the request of the group at Orem.)

The rationale for the requirement is to prevent livelocks.  That is, if the
requirement is not satisfied, it will be possible for 2 principals to try to
lock the same group of resources, and for neither to get all the locks he
needs.  Each may end up with only some of the locks he needs. In addition,
the requirement is meant to lessen the burden on the server that would be
caused by multiple individual lock requests.

The current locking draft does not satisfy the requirement.  The difficulty
is that it defines a LOCK method where the request URI is the resource to be
locked.  If we tried to accommodate multiple URIs by moving them into the
body of the request, it is not clear what request URI would be appropriate.

One suggestion was that the user put all the resources to be locked into a
container, and then lock the container.  The server would be required to
treat the lock request as atomic to whatever depth was requested.

------------

The requirement concerning EMail transport will stay as is.

------------

Internationalization

The consensus of the group at Orem was that we should stay away from issues
around variants, which are not specific to internationalization and would
add enormously to the work of WEBDAV.  Jim will make sure that this position
is acceptable to the area directors.

The question was raised whether we need to be concerned about collation.  We
think that we do not -- we do not sort any query result sets, and we do not
define greater-than or less-than operators for pattern matching.

We think that we need only to insure that any information intended for user
comprehension should be expressed in a way that makes it possible to display
the information in any desired writing system and language.  The proposed
internationalization requirement is the following:

"All information intended for user comprehension must be expressed in one of
the ISO-10646 character sets and must have a language tag." 

------------

Reservations

The consensus of the group at Orem was to leave the reservations section
separate, as it is now, and to continue to use the same terminology.  The
locking draft will discuss the standard use of the word "reservation" and
explain how the shared lock satisfies the need for reservations.

The language of 5.4.1.1 will change to make it clear that the point of
reservations is to inform other users, not the server, of an intent to edit.
The new 5.4.1.1 will say:

"It must be possible for a principal to register with the server an intent
to edit a given resource, so that other principals can discover who intends
to edit the resource."

-----------

--Judy

Name:		Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Phone:  	(716) 422-5169
Fax:		(716) 265-7133

Xerox Corporation
Mail Stop 105-50C
800 Phillips Road
Webster, NY 14580

Received on Monday, 21 July 1997 15:29:50 UTC