Re: Open Requirements Issues

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