- From: Judith Slein <slein@wrc.xerox.com>
- Date: Mon, 21 Jul 1997 12:33:02 PDT
- To: w3c-dist-auth@w3.org
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