- From: Judith Slein <slein@wrc.xerox.com>
- Date: Thu, 3 Jul 1997 06:19:48 PDT
- To: Jim Whitehead <ejw@ics.uci.edu>
- Cc: w3c-dist-auth@w3.org
Thanks, Jim, for starting this conversation. Here's an attempt to summarize the discussion we've seen over the past couple of weeks, and resolve some of the issues. Based on this discussion, it seems to me we should devote most of the requirements discussion at Orem to internationalization. Multi-Resource Locking Jim believes that the multi-resource locking requirement should stand as it is. Rationale: We will need atomic multi-resource locking for exclusive locks (this isn't a problem for shared locks). If locking multiple resources requires that each resource be individually locked (i.e., no atomic locking of multiple resources is available), then if two or more principals try to take out exclusive locks on the same set of resources, no principal will end up with the desired result: having an exclusive lock on all resources. This can only be solved by making an exclusive lock of a set of resources an atomic operation across all resources. Howard Modell believes that multi-resource locking applies to both exclusive and shared locks. For shared locks, it might be necessary to support two behaviors: one where the lock fails unless all the resources in the request can be locked; and one where as many of the resources as possible will be locked. Resolution: The multi-resource locking requirement will stand: 5.3.1.2. Multi-Resource Locking. It must be possible to take out a lock on multiple resources in the same action, and this locking operation must be atomic across these resources. We might consider whether to add a parallel requirement to the Reservations section. ------------- Reservations as shared / advisory locks Discussion: Jim believes that this is just a question of what terminology to use, since shared locks meet the requirements for reservations: 5.4.1.1. Reserve. It must be possible to notify the server that a resource is about to be edited by a given person. If you have a set of principals with equivalent access permissions on a resource, a shared write lock indicates that one of those principals is about to be edited (since presumably the only reason to take out a shared lock (or a reservation) is prior to performing edits). The current locking proposal uses the "shared lock" terminology, so that the requirements would map more clearly to the spec if the terminology matched. Judy: I don't feel strongly about this, but I've always found it confusing to think of reservations as shared locks. Really I think this is because I find the discussion of shared vs. exclusive locks in the locking proposal confusing. It leads you to think that shared vs. exclusive mode is orthogonal to lock type (write, read, existence). In fact, it states that a compliant server may support any combination of shared and exclusive locks for any lock types. But really I don't think this is true. I can't make sense of exclusive locks for any lock type except write locks. The point of a read lock is not to prevent others from reading the resource while I am reading it, but to prevent anyone from writing the resource while I am reading it. The point of an existence lock is to prevent anyone from deleting a resource while I have the lock, but I don't care how many others have existence locks on it while I do. So I'd rather stick with "reservation" till this gets sorted out, or else switch to "shared write lock". ------------ Access Control Has its own block of time reserved at Orem. ------------ Internationalization This is clearly an area that should be discussed at Orem. Topics that came up on the mailing list include: 1. What support for i18n of content is needed over and above what HTTP provides? * Notion of a master variant * Multi-lingual resources (English-language paper that contains quotations in Chinese) 2. What support is needed for i18n of attribute values and version comments? * Being able to display metadata to users in their language of choice 3. What support is needed for i18n in the context of versioning? * Tracking relationships between language variants and nodes in version graphs 4. What support is needed for i18n in the context of collections? * Listing available language variants when we list members of a collection 5. Are we concerned only about character sets? format encodings? anything else? ---------- Alternative Transports (EMail) Einar's has been the lone voice in favor of a stronger requirement for EMail as an alternative transport. Resolution: The general principle regarding alternative transports, which was extracted directly from the Charter, will stand as it is: 4.8: 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. 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 Thursday, 3 July 1997 09:16:56 UTC