Re: Open Requirements Issues

H:From w3c-dist-auth-request@w3.org  Thu Jun  5 18:45:29 1997
H:Resent-Message-Id: <199706060047.UAA07351@www19.w3.org>
H:Date: Thu, 5 Jun 1997 17:48:36 -0700
H:To: w3c-dist-auth@w3.org
H:From: Jim Whitehead <ejw@ics.uci.edu>
H:Subject: Open Requirements Issues
H:X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
H:X-See-Also: http://www.ics.uci.edu/~ejw/authoring
H:X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/861
H:X-Loop: w3c-dist-auth@w3.org
H:
H:I'd like to start a dialog on the last remaining open issues in the
H:requirements document, since I feel that for most issues, a little bit of
H:discussion will resolve the issue.
H:
H:The requirements document lists the following issues as still being under
H:discussion:
H:
H:*       Whether support for multi-resource locking is needed
H:*       Whether reservations should be treated as shared or advisory locks
H:*       What requirements there should be for access control
H:*       What requirements there should be for internationalization
H:*       How far WebDAV should be concerned about compatibility with other
H:transport protocols besides HTTP
H:
H:My views on these issues are as follows:
H:
H:*       Whether support for multi-resource locking is needed
H:
H:I feel we will need atomic multi-resource locking for exclusive locks (this
H:isn't a problem for shared locks).  If locking multiple resources requires
H:that each resource be individually locked (i.e., no atomic locking of
H:multiple resources is available), then if two or more principals try to
H:take out exclusive locks on the same set of resources, no principal will
H:end up with the desired result: having an exclusive lock on all resources.
H:I believe this can only be solved by making an exclusive lock of a set of
H:resources an atomic operation across all resources.
H:
H:So I feel that yes, support for multi-resource locking is needed, and hence
H:the current requirement covering this ability should remain as-is:
H:
H:5.3.1.2. Multi-Resource Locking. It must be possible to take out a lock
H:on multiple resources in the same action, and this locking operation
H:must be atomic across these resources.

I find no problems here.  However, I think it feeds directly into the next one ..

H:
H:*       Whether reservations should be treated as shared or advisory locks
H:
H:In my view, a shared lock meets the requirements for reservations, which
H:are defined as:
H:
H:5.4.1.1. Reserve. It must be possible to notify the server that a
H:resource is about to be edited by a given person.

I think that if "multi-resource locks" are supported, than Reservation must account
for them more strongly.  I think that if one wishes to edit multiple resources, than
the reserve operation should be "atomic", that is, you specify all resources that you
wish to edit "at the same time" and only if you can get a lock on *all* of them should
the server accept the reservation.  If you can't get all of them, the server has to 
inform you of that fact, and stop.

I suppose it could be permissible to request reservation of a set of resources without
the requirement of needing all of them at that moment, in which case being able to
reserve some but not all should be supported.

H:
H:
H:*       What requirements there should be for access control
H:
H:This will be the subject of a draft by Jon Radoff.
H:
H:
H:*       What requirements there should be for internationalization
H:
H:We definitely need some words on this topic, however my lack of experience
H:in this area hinders my ability to construct a good requirement.  Something
H:along the lines of, "All fields which might be displayed to a human user of
H:client software should be fully international."  I'd appreciate some
H:assistance for good wording of "fully international" -- something along the
H:lines of "supports iso character set standard XXX" might work.

is there an assumption that user-interaction with a WEBDAV server will always be 
mediated thru a web browser?  If so, couldn't we simply assert that a WEBDAV
server must have at least the functionality of a non-WEBDAV server with respect
to communicating with a "acculturated" browser?

H:
H:
H:*       How far WebDAV should be concerned about compatibility with other
H:transport protocols besides HTTP
H:
H:Well, since our charter limits us to discussion on HTTP and Email as
H:transport protocols, this open issue really concerns email access.  The
H:sense I have been receiving from the list is the current, "don't shoot,
H:don't spec." (don't shoot ourselves in the foot by making it impossible to
H:do an email mapping in the future, but don't actually write a spec. for
H:this right now) is how most would prefer to proceed.
H:
H:If my reading of the sense of the working group is correct, then we should
H:not have a requirement on this topic, and can declare the issue closed. 

I agree with this.

<signed>
Howard S. Modell
________________________________________________________________________
 Adv.Computing Technologist/2         POBox 3707, m/s 4A-25, Boeing D&SG
 howard.s.modell@boeing.com           Seattle, WA 98124-2207
 http://warlok.ds.boeing.com/~howie/  (206)662-0189[v] (206)662-4018[f]

Received on Friday, 6 June 1997 12:27:47 UTC