W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 1997

Open Requirements Issues

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Thu, 5 Jun 1997 17:48:36 -0700
Message-Id: <afbcfd170e021004649e@[128.195.21.209]>
To: w3c-dist-auth@w3.org
I'd like to start a dialog on the last remaining open issues in the
requirements document, since I feel that for most issues, a little bit of
discussion will resolve the issue.

The requirements document lists the following issues as still being under
discussion:

*       Whether support for multi-resource locking is needed
*       Whether reservations should be treated as shared or advisory locks
*       What requirements there should be for access control
*       What requirements there should be for internationalization
*       How far WebDAV should be concerned about compatibility with other
transport protocols besides HTTP

My views on these issues are as follows:

*       Whether support for multi-resource locking is needed

I feel 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.
I believe this can only be solved by making an exclusive lock of a set of
resources an atomic operation across all resources.

So I feel that yes, support for multi-resource locking is needed, and hence
the current requirement covering this ability should remain as-is:

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.


*       Whether reservations should be treated as shared or advisory locks

In my view, a shared lock meets the requirements for reservations, which
are defined as:

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

Since a shared lock meets the requirement for reservations, the issue
arises whether the terminology for reservations should be modified to use
the term "shared lock" instead of "reservation."  This is a little less
clear.  I think there is better correspondence between the requirements and
the current proposals if the wording is changed, but since the current lock
proposal meets the reservation requirements, the language doesn't have to
be changed.  My inclination is to use the terminology "shared lock" in the
requirements document, but I could go either way.


*       What requirements there should be for access control

This will be the subject of a draft by Jon Radoff.


*       What requirements there should be for internationalization

We definitely need some words on this topic, however my lack of experience
in this area hinders my ability to construct a good requirement.  Something
along the lines of, "All fields which might be displayed to a human user of
client software should be fully international."  I'd appreciate some
assistance for good wording of "fully international" -- something along the
lines of "supports iso character set standard XXX" might work.


*       How far WebDAV should be concerned about compatibility with other
transport protocols besides HTTP

Well, since our charter limits us to discussion on HTTP and Email as
transport protocols, this open issue really concerns email access.  The
sense I have been receiving from the list is the current, "don't shoot,
don't spec." (don't shoot ourselves in the foot by making it impossible to
do an email mapping in the future, but don't actually write a spec. for
this right now) is how most would prefer to proceed.

If my reading of the sense of the working group is correct, then we should
not have a requirement on this topic, and can declare the issue closed.  If
there is strong support for writing a spec. on email access, then Gregory
Woodhouse, who has volunteered to look into this, needs to write up some
requirements, which may or may not end up in future versions of
draft-ietf-webdav-requirements.


Comments?

- Jim
Received on Thursday, 5 June 1997 20:47:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:42 GMT