RE: Requirements Open Issues from Orem

Seems a bit heavy to require discovery even when your just locking a
single resource but not totally unreasonable.
	Yaron

> -----Original Message-----
> From:	Dylan Barrell [SMTP:dbarrell@bb.opentext.com]
> Sent:	Wednesday, August 06, 1997 12:31 AM
> To:	'Whelan, Dan'; 'Dylan Barrell'; w3c-dist-auth@w3.org; Yaron
> Goland
> Subject:	RE: Requirements Open Issues from Orem
> 
> This is the reason for having an arbitrator for multiple resource
> locking but not the reason for distinguishing between single and
> multiple resource locking. I think WebDAV should always use the
> arbitrator (specifying where the arbritrator is located or how it can
> be located) with an XML request body (this draft anyway contains
> enough XML) containing one or more URIs representing the resources to
> be locked.
> 
> Cheers
> Dylan
> 
> ----------
> From: 	Yaron Goland[SMTP:yarong@microsoft.com]
> Sent: 	Dienstag, 5. August 1997 15:01
> To: 	'Dylan Barrell'; 'Whelan, Dan'; w3c-dist-auth@w3.org
> Subject: 	RE: Requirements Open Issues from Orem
> 
> It is not a matter of advantage, it is a matter of HTTP's design. HTTP
> can only deliver a single message to a single destination. It does not
> have multicast or broadcast capabilities. As such without
> transactioning
> the only way to deliver a message to multiple resources in an atomic
> fashion is to have the message delivered through some mechanism other
> than HTTP. What the arbitrator does is act as the resource which can
> access that out of band mechanism.
> 
> In the case of trying to atomically lock a single resource one can
> skip
> the out of band mechanism since HTTP does support sending a single
> message to a single recipient.
> 
> 			Yaron
> 
> > -----Original Message-----
> > From:	Dylan Barrell [SMTP:dbarrell@bb.opentext.com]
> > Sent:	Tuesday, August 05, 1997 1:30 AM
> > To:	'Whelan, Dan'; 'Dylan Barrell'; w3c-dist-auth@w3.org; Yaron
> > Goland
> > Subject:	RE: Requirements Open Issues from Orem
> > 
> > What is the advantage to be gained from distinguishing between a
> > single resource (whos arbritrator does not have to be "located") and
> > multiple resources (whos arbritrator[s] has to be located first)?
> > 
> > Cheers
> > Dylan
> > 
> > ----------
> > From: 	Yaron Goland[SMTP:yarong@microsoft.com]
> > Sent: 	Montag, 4. August 1997 20:04
> > To: 	'Dylan Barrell'; 'Whelan, Dan'; w3c-dist-auth@w3.org
> > Subject: 	RE: Requirements Open Issues from Orem
> > 
> > There is an arbitrator for single resources, the resource itself, it
> > is
> > kind enough to lock itself on your behalf. 
> > 
> > A server could configure itself such that every resource can serve
> as
> > a
> > lock arbitrator for all resources on that server.
> > 
> > 	Yaron
> > 
> > > -----Original Message-----
> > > From:	Dylan Barrell [SMTP:dbarrell@bb.opentext.com]
> > > Sent:	Monday, August 04, 1997 12:52 AM
> > > To:	'Whelan, Dan'; w3c-dist-auth@w3.org; Yaron Goland
> > > Subject:	RE: Requirements Open Issues from Orem
> > > 
> > > Having an arbitrator for locking multiple resources and the server
> > for
> > > locking single resources is very contrived and doesn't make sense.
> > The
> > > locking part of the standard is anyway optional (the single axis
> of
> > > negotiation) so if a server doesn't want to implement it it
> doesn't
> > > have to but if it does then WebDAV should specify a consistent
> > > standard method by which this can be implemented. If you want an
> > > arbitrator for locking multiple resources then it should be used
> for
> > > locking single resources too.
> > > 
> > > Cheers
> > > Dylan
> > > 
> > > ----------
> > > From: 	Yaron Goland[SMTP:yarong@microsoft.com]
> > > Sent: 	Mittwoch, 30. Juli 1997 21:03
> > > To: 	'Whelan, Dan'; w3c-dist-auth@w3.org
> > > Subject: 	RE: Requirements Open Issues from Orem
> > > 
> > > I suspect we will end up with a LOCK implementation where you have
> > the
> > > concept of a LOCK arbitrator who accepts a list of resources to be
> > > locked and then locks them on your behalf in an atomic fashion. Of
> > > course this means discovering who the lock arbitrator is for all
> the
> > > involved resources, assuming one arbitrator can cover them all.
> > > Alternatively one can discover what arbitrators exist for a
> > particular
> > > server and what namespaces they cover on that server. Either way,
> I
> > > suspect most folks will simply lock each resource individually.
> > > 
> > > 		Yaron
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From:	Whelan, Dan [SMTP:dan@filenet.com]
> > > > Sent:	Wednesday, July 23, 1997 10:50 PM
> > > > To:	w3c-dist-auth@w3.org
> > > > Subject:	RE: Requirements Open Issues from Orem
> > > > 
> > > > I view the proposal to use containers to implement
> multi-resource
> > > > locking as
> > > > a somewhat clumsy way to satisfy this requirement for a number
> of
> > > > reasons
> > > > including:
> > > > 
> > > > 1. The principal may not be authorized to create a container, or
> > to
> > > > file a
> > > >     resource in a container, and hence could not use this
> > mechanism
> > > to
> > > >     perform a multi-resource lock even if he was authorized to
> > lock
> > > > each of
> > > >     the resources.
> > > > 
> > > > 2. Creating a transient container in order to obtain a
> > > multi-resource
> > > > lock
> > > >     is relatively inefficient, requiring O(2N) operations.
> > > > 
> > > > 3. Servers may elect to implement only session based locks or
> > short
> > > > lived
> > > >     timer based locks to provide robust services in an otherwise
> > > > unreliable
> > > >     environment.  In such cases, a client is just as likely to
> > fail
> > > to
> > > > remove
> > > >     a transient container as he is to unlock a lock yet the
> server
> > > has
> > > > no
> > > >     WebDAV sanctioned way of removing these transient
> containers.
> > > > 
> > > > I'd prefer to see the LOCK and UNLOCK methods take an ordered
> list
> > > of
> > > > resources
> > > > to LOCK or UNLOCK respectively.  (I'm not familiar enough with
> > HTTP
> > > to
> > > > know if
> > > > the protocol makes passing a list of resources difficult --
> WebDAV
> > > has
> > > > already addressed
> > > > multi-status responses for the COPY, MOVE and DELETE methods)
> > > > 
> > > > 							Dan
> Whelan
> > > > 							FileNet
> > > > Corporation
> > > > 	----------
> > > > 	From: 	Judith Slein[SMTP:slein@wrc.xerox.com]
> > > > 	Sent: 	Monday, July 21, 1997 12:33 PM
> > > > 	To: 	w3c-dist-auth@w3.org
> > > > 	Subject: 	Requirements Open Issues from Orem
> > > > 
> > > > 	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 Wednesday, 6 August 1997 15:52:48 UTC