From w3c-dist-auth-request@w3.org  Sat Jan  1 11:26:50 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27127
	for <webdav-archive@odin.ietf.org>; Sat, 1 Jan 2000 11:26:50 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA21425;
	Sat, 1 Jan 2000 11:15:37 -0500 (EST)
Resent-Date: Sat, 1 Jan 2000 11:15:37 -0500 (EST)
Resent-Message-Id: <200001011615.LAA21425@www19.w3.org>
Date: Sat, 1 Jan 2000 11:15:24 -0500
Message-Id: <10001011615.AA16972@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <05256858.00804FA6.00@D51MTA03.pok.ibm.com> (ccjason@us.ibm.com)
Subject: Re: Locking URIs rather than Resources
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3774
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

   From: ccjason@us.ibm.com

   <ja/> Now some locking questions. If LOCK applies to the name, not the
   resource, /x/y.htm is locked, and /b/c.htm is bound to the same
   resource as /x/y.htm, is /b/c.htm locked too? Probably not.

   <gmc/> Correct.  But modifying the resource identified by /b/c.htm
   does require the lock token for the /x/y.htm lock.  This does not make
   /b/c.htm locked.

   <jc/> Geoff, you agreed that "/b/c.html" is not locked.  In this case I
   think we'd preferably say the "the resource at" either/both URI's is
   locked... but only one of those URI's is locked.  My point is that we
   should probably come up clearer vocabulary/notation for making a
   distinction between the URI and the resource.  For example, we used to
   say the URI was protected and/or the resource was locked.

I agree.  If we say that a URL is locked, then we need a term to
describe a resource that is identified by a locked URL.  Let's try
just using the word "protect".  So a locked URL "protects" the
resource that it identifies.  If it does not (at a particular moment)
identify a resource, it does not (at that moment) protect any resource
(i.e. there is no "lock null resource").

So in the example above, we would say that the resource identified by
/b/c.html is protected by the lock on /x/y.htm.

   <ja/> What about LOCK  /b/c.htm?

   <gmc/> That is fine.

   <jc/> Hmmm.  Jim said they are the same resource.  I don't think he meant a
   null-mapped resource.  That being the case, I think you mean to say
   that the second lock can only be placed if it doesn't conflict with
   the lock already acting on the resource at that URI.  I think you must
   have assumed he meant a shared lock when you said that is fine.

Actually not.  I was using the "exclusive" aspect of a lock to be
completely URL based.  So you couldn't have two exclusive locks on the
same URL (i.e. you can't have a depth:infinity exclusive lock on /x
and an exclusive lock on /x/y), but you *could* have a resource that
is protected by two exclusive locks.

Although this simplifies LOCK/UNLOCK implementation for a server, I 
(believe I) agree that a client would rather the "exclusive" aspect
of a lock apply to the resource.  So a particular resource can only
be protected by one exclusive lock of a given type.  This modifies
the last line of the latest locking proposal, which would now state:

"A lock can be placed on a URL with a LOCK request.  This URL is called
 the "lock base".  If the lock is Depth:N, then a lock is induced on
 any URL that consists of the lock base extended by N or fewer
 segments.  Only an authorized holder of a lock token for a locked URL
 can modify either the state of the resource identified by the URL, or
 which resource is identified by the URL.  If a locked URL identifies a
 resource, the lock "protects" that resource.  A resource may not be
 protected by two exclusive locks with the same locktype."

This would then change my answer to Jim's question.  The revised
definition would not allow an exclusive write lock on /x/y.htm and
one on /b/c.htm, since that would result in a resource being protected
by two exclusive locks of the same type.

   <gmc/>  One user has /x/y.htm locked.  The other user has /b/c.htm
   locked.  That means you can't modify that resource unless you have both
   lock tokens.  In this model, a LOCK prevents a certain kind of change
   to something, but does *not* guarantee the ability to make such a change,
   since other access rights or locks can come into play.

   <jc/> I agree with what you said about not guarantee'ing a right to change,
   but what about requiring two tokens?  As far as I know, the situation
   you outlined can only happen if shared locks are used.  In that case,
   only one lock token is required.

Yes, for the situation where two URL's identify the same resource.
But there still will be operations that will require the use of
multiple lock tokens.  An example would be the original scenario
described by Yaron, where:

- /x identifies a collection
- /x/y does not identify a resource
- there is a depth:0 exclusive write lock on /x
- there is an exclusive write lock on /x/y

In order to do a "PUT /x/y", you would need a Lock-Token for both
the /x lock and the /x/y lock, since you are modifying the state of
both /x and /x/y.

Cheers,
Geoff




From w3c-dist-auth-request@w3.org  Sun Jan  2 08:25:29 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08085
	for <webdav-archive@odin.ietf.org>; Sun, 2 Jan 2000 08:25:28 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id IAA01481;
	Sun, 2 Jan 2000 08:14:27 -0500 (EST)
Resent-Date: Sun, 2 Jan 2000 08:14:27 -0500 (EST)
Resent-Message-Id: <200001021314.IAA01481@www19.w3.org>
Message-Id: <4.1.20000102093420.00b4f5c0@pop.xs4all.nl>
X-Sender: jdavis@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sun, 02 Jan 2000 09:54:46 +0100
To: w3c-dist-auth@w3.org
From: Jim Davis <jrd3@alum.mit.edu>
In-Reply-To: <9912302233.AA16478@tantalum>
References: <7DE119D3D0E15543874F7561EECBDBED02619DE5@BEG.platinum.corp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Re: Creating a lock-null in a locked collection
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3775
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

At 05:33 PM 12/30/99 -0500, Geoffrey M. Clemm wrote:
>
>As an addendum to Yaron's response, I'll note that there is a proposal
>that WebDAV locking is better understood as locks on URL's rather than
>on resources. 

I am not sure I understand what "is better understood as" means here. 

I would like it to be the case that if I have a datastore (file system, an
object oriented database, an RDBMS, whatever) that *does* support locking,
I can use the WebDAV to set a lock on a resource in the datastore,  and
expect the lock to actually be set on the resource such that other
applications accessing that very same resource likewise see the lock, even
if they use a different protocol or API to do so.

I may be reading more into the nuances of language than is intended, but
does this mean that WebDAV locks would only be visible at the WebDAV layer
(or perhaps to other protocols that also use URLs) but *not* to other
protocols or APIs that were accessing the same resource?

I would be very unhappy with a design change that asserted that the locks
were only in some "namespace" that only affected WebDAV, or HTTP-based
applications, but not the datastore itself.

I would probably prefer to give up the functionality of BIND than lose the
ability to set locks on underlying resources.

But again, I am not sure that Geoff was actually suggesting this.

regards and happy Y2K

Jim




From w3c-dist-auth-request@w3.org  Mon Jan  3 04:34:52 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28480
	for <webdav-archive@odin.ietf.org>; Mon, 3 Jan 2000 04:34:51 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id EAA15669;
	Mon, 3 Jan 2000 04:23:10 -0500 (EST)
Resent-Date: Mon, 3 Jan 2000 04:23:10 -0500 (EST)
Resent-Message-Id: <200001030923.EAA15669@www19.w3.org>
Message-ID: <00ba01bf55cc$1a312160$9a114498@us.oracle.com>
From: "Eric Sedlar" <esedlar@us.oracle.com>
To: <w3c-dist-auth@w3.org>
References: <05256858.00804FA6.00@D51MTA03.pok.ibm.com>
Date: Mon, 3 Jan 2000 01:22:48 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Subject: Re: Locking URIs rather than Resources
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3776
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

I think the existing proposals are kind of crufty, because there is no
sensible abstraction that people can understand and expand on.  They either
have the yucky lock-null, or they introduce a new kind of object (a URL)
that is not a resource, the "atom" (basic building block) of web
applications.

Here are the fundamental issues I see:

1) are the list of names in a collection logically part of the collection,
or do they live in some separate space outside the domain of resources?
(I'm using the word name the way jra uses "binding"--the relationship
between a containing collection and a particular resource which is given a
unique name within that collection).

To me the answer must be that they are a part of the collection.  The only
type of object that can be identified within this model is a resource.  You
are going to have (in a real system) access control on resources, and not a
separate access control model for names.  There are too many concepts in the
world of the web to introduce another type of object other than a resource.
Every filesystem in the world stores the list of filenames as a part of the
directory, and locks & access control on the directory affects all names
within.  Let's stick with current usage unless we have compelling reasons to
deviate.

2) what kind of locks are there?

IMHO, there must be two kinds of locks--name locks and resource locks.  The
problem with just locking a collection resource is that it is to
coarse-grained--there are lots of applications that will want to just lock a
single name in a collection, and resource locking every collection in a path
will reduce concurrency too much.  I think of this like table level and row
level locks in a database--a lock on the collection is like a table level
lock, locking all names (rows) in that collection.  Another way to think of
a name is like a fragment within the collection document.

3) what about the notion of a lock "depth"?

There is no such thing.  However, depth may be one way that a protocol
request can specify a particular set of locks.

Now that we understand that, what do we do about RFC 2518 LOCK's?  (I'm
using a capitalized LOCK to distinguish the RFC 2518 protocol request from
name locks and resource locks).

The requirements are:

* a LOCK on must prevent the resource from being moved, for compatability
with existing applications.
* a LOCK on must prevent any changes to that resource (updates, deletes,
etc.) if it exists
* a LOCK token must be associated with the locked resource and URL

So, it seems like that the following solution is the right abstraction:

1) add the notion of name and resource locks.  A name lock applies to a
single level name within a collection.  A resource lock applies to the data
identified by a particular URL.  If that URL identifies a collection, a
resource lock locks ALL of the names in that collection, and is blocked by
any name lock within, and vice versa.

2) we introduce the notion of a lock "set".  A lock set is a group of any
number of name and resource locks.  Each lock set as a single associated
lock token.  An RFC 2518 LOCK request applied to an existing non-collection
resource will grant name locks to each name in the path from the root down
to the bottom, and a resource lock on the identified resource, create a lock
set from this group, and grant an identifying LOCK token.  An RFC 2518 LOCK
request applied to a collection will work in the same way, except that if
the depth header is specified, name and resource locks will be given
recursively for each contained resource.  A LOCK request on a URL giving a
nonexistent name in a existing collection will issue only name locks on the
path elements.  If the URL minus the last path element does not refer to an
existing collection, the LOCK request will fail.

3) the activelocks property displays all name locks active for this
collection as well as all resource locks.

4) the "locktype" property is used to distinguish between name and resource
locks.  If locktype "resource" is specified, only the specified resource
lock is granted in that lock set.  If locktype "name" is specified, the
names from root to the resource are locked, if the Depth header is not
specified.  If the URL "/a/b/c.html" is given, negative depth values can be
given to lock fractions of the path.  E.g. if Depth:0 is specified, the name
"c.html" is reserved in collection /a/b, but no other locks are granted.  If
Depth:-1 is specified, the name "b" in "/a" is also reserved (etc.)  Only if
locktype is not specified does the LOCK request behave as it point #2
(granting resource & name locks simoultaneously), basically for
compatability with existing applications.

--Eric



From w3c-dist-auth-request@w3.org  Mon Jan  3 11:21:28 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03587
	for <webdav-archive@odin.ietf.org>; Mon, 3 Jan 2000 11:21:27 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA24099;
	Mon, 3 Jan 2000 11:09:55 -0500 (EST)
Resent-Date: Mon, 3 Jan 2000 11:09:55 -0500 (EST)
Resent-Message-Id: <200001031609.LAA24099@www19.w3.org>
From: jamsden@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <8525685B.0058C2FD.00@d54mta03.raleigh.ibm.com>
Date: Mon, 3 Jan 2000 11:07:54 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: Creating a lock-null in a locked collection
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3777
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list



Jim,
WebDAV locking semantics are defined independently of the actual server
implementation. If a server provides multiple protocol access to some
underlying storage system, including WebDAV and say ftp, then that server
is free to implement locks in such a way that both protocols are effected
as long as the semantics for WebDAV locks are honored when doing WebDAV
access.





Jim Davis <jrd3@alum.mit.edu>@w3.org on 01/02/2000 03:54:46 AM

Sent by:  w3c-dist-auth-request@w3.org


To:   w3c-dist-auth@w3.org
cc:

Subject:  Re: Creating a lock-null in a locked collection


At 05:33 PM 12/30/99 -0500, Geoffrey M. Clemm wrote:
>
>As an addendum to Yaron's response, I'll note that there is a proposal
>that WebDAV locking is better understood as locks on URL's rather than
>on resources.

I am not sure I understand what "is better understood as" means here.

I would like it to be the case that if I have a datastore (file system, an
object oriented database, an RDBMS, whatever) that *does* support locking,
I can use the WebDAV to set a lock on a resource in the datastore,  and
expect the lock to actually be set on the resource such that other
applications accessing that very same resource likewise see the lock, even
if they use a different protocol or API to do so.

I may be reading more into the nuances of language than is intended, but
does this mean that WebDAV locks would only be visible at the WebDAV layer
(or perhaps to other protocols that also use URLs) but *not* to other
protocols or APIs that were accessing the same resource?

I would be very unhappy with a design change that asserted that the locks
were only in some "namespace" that only affected WebDAV, or HTTP-based
applications, but not the datastore itself.

I would probably prefer to give up the functionality of BIND than lose the
ability to set locks on underlying resources.

But again, I am not sure that Geoff was actually suggesting this.

regards and happy Y2K

Jim







From w3c-dist-auth-request@w3.org  Mon Jan  3 13:28:23 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05543
	for <webdav-archive@odin.ietf.org>; Mon, 3 Jan 2000 13:28:22 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA27012;
	Mon, 3 Jan 2000 13:15:45 -0500 (EST)
Resent-Date: Mon, 3 Jan 2000 13:15:45 -0500 (EST)
Resent-Message-Id: <200001031815.NAA27012@www19.w3.org>
Message-ID: <001d01bf5616$7e60de10$9a114498@us.oracle.com>
From: "Eric Sedlar" <esedlar@us.oracle.com>
To: <jamsden@us.ibm.com>, <w3c-dist-auth@w3.org>
References: <8525685B.0058C2FD.00@d54mta03.raleigh.ibm.com>
Date: Mon, 3 Jan 2000 10:15:19 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Subject: Re: Creating a lock-null in a locked collection
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3778
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

I think the point is that if the WebDAV locking model is too strange, it
will be hard to reconcile the WebDAV locking mechanism with the other
locking mechanisms.  Introducing new concepts like lock-null's makes it much
more difficult and less intuitive to reconcile in this way.

Perhaps we should discuss other locking mechanisms in filesystems and
RDBMS's to validate this.

My understanding is that both Windows & UNIX filesystems lock all of the
names in a directory when the directory is explicitly locked (via
lockf()/flock() or something similar).  In Windows filesystems, this
guarantees that the name cannot change since each file can be in only one
directory.

--Eric

----- Original Message -----
From: <jamsden@us.ibm.com>
To: <w3c-dist-auth@w3.org>
Sent: Monday, January 03, 2000 8:07 AM
Subject: Re: Creating a lock-null in a locked collection


>
>
> Jim,
> WebDAV locking semantics are defined independently of the actual server
> implementation. If a server provides multiple protocol access to some
> underlying storage system, including WebDAV and say ftp, then that server
> is free to implement locks in such a way that both protocols are effected
> as long as the semantics for WebDAV locks are honored when doing WebDAV
> access.
>
>
>
>
>
> Jim Davis <jrd3@alum.mit.edu>@w3.org on 01/02/2000 03:54:46 AM
>
> Sent by:  w3c-dist-auth-request@w3.org
>
>
> To:   w3c-dist-auth@w3.org
> cc:
>
> Subject:  Re: Creating a lock-null in a locked collection
>
>
> At 05:33 PM 12/30/99 -0500, Geoffrey M. Clemm wrote:
> >
> >As an addendum to Yaron's response, I'll note that there is a proposal
> >that WebDAV locking is better understood as locks on URL's rather than
> >on resources.
>
> I am not sure I understand what "is better understood as" means here.
>
> I would like it to be the case that if I have a datastore (file system, an
> object oriented database, an RDBMS, whatever) that *does* support locking,
> I can use the WebDAV to set a lock on a resource in the datastore,  and
> expect the lock to actually be set on the resource such that other
> applications accessing that very same resource likewise see the lock, even
> if they use a different protocol or API to do so.
>
> I may be reading more into the nuances of language than is intended, but
> does this mean that WebDAV locks would only be visible at the WebDAV layer
> (or perhaps to other protocols that also use URLs) but *not* to other
> protocols or APIs that were accessing the same resource?
>
> I would be very unhappy with a design change that asserted that the locks
> were only in some "namespace" that only affected WebDAV, or HTTP-based
> applications, but not the datastore itself.
>
> I would probably prefer to give up the functionality of BIND than lose the
> ability to set locks on underlying resources.
>
> But again, I am not sure that Geoff was actually suggesting this.
>
> regards and happy Y2K
>
> Jim
>
>
>
>
>
>



From w3c-dist-auth-request@w3.org  Mon Jan  3 13:48:18 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05925
	for <webdav-archive@odin.ietf.org>; Mon, 3 Jan 2000 13:48:17 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA28024;
	Mon, 3 Jan 2000 13:36:58 -0500 (EST)
Resent-Date: Mon, 3 Jan 2000 13:36:58 -0500 (EST)
Resent-Message-Id: <200001031836.NAA28024@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A016@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'Geoffrey M. Clemm'" <geoffrey.clemm@rational.com>, w3c-dist-auth@w3.org
Date: Mon, 3 Jan 2000 10:35:46 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: RE: Creating a lock-null in a locked collection
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3779
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Geoff said: "It sometimes acts like a resource (modifies the parent
collection), and sometimes does not (returns a 404 when you GET it)."

In HTTP, as I understand it, one sends a method to a resource identified by
a URI. As such any response one gets must have come from a resource.
Therefore a 404 must be issued by a resource. This is why the object model I
suggested for WebDAV has the universal NULL resource that handles things
such as issuing 404s. As such how can one say that because a resource issues
a 404 it is not acting like a resource?

			Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com]
> Sent: Thursday, December 30, 1999 7:35 PM
> To: w3c-dist-auth@w3.org
> Subject: Re: Creating a lock-null in a locked collection
> 
> 
> 
>    From: Joe Orton <joe@orton.demon.co.uk>
> 
>    ... It just seemed slightly weird, that if you LOCK or UNLOCK a
>    lock-null resource, you are modifying the state of the 
> parent collection;
>    when if you do the same to a normal resource, you are not.
> 
> Yes, that is one of the reasons I strongly object to the notion of a
> "lock null resource".  It sometimes acts like a resource (modifies the
> parent collection), and sometimes does not (returns a 404 when you GET
> it).  This makes it very hard to predict what its behavior should be
> whenever you extend the protocol (i.e. should it act like a resource,
> or act like not a resource).  For example:
> 
> - the BIND protocol (can you "BIND" a lock null resource to
>   another URL?)
> - the versioning protocol (do you have to checkout a 
> versioned collection
>   in order to add a lock null resource to it?)
> 
> Cheers,
> Geoff
> 



From w3c-dist-auth-request@w3.org  Mon Jan  3 15:04:04 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06817
	for <webdav-archive@odin.ietf.org>; Mon, 3 Jan 2000 15:04:04 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA29699;
	Mon, 3 Jan 2000 14:51:08 -0500 (EST)
Resent-Date: Mon, 3 Jan 2000 14:51:08 -0500 (EST)
Resent-Message-Id: <200001031951.OAA29699@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619DE9@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'Eric Sedlar'" <esedlar@us.oracle.com>, w3c-dist-auth@w3.org,
        "'gclemm@atria.com'" <gclemm@atria.com>
Date: Mon, 3 Jan 2000 11:50:09 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Translation in the Tower of Babble
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3780
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

I believe that there are too many different unstated assumptions held by
members of this group for this group to be ready to deal with specific
locking proposals. The fact that Geoff, Eric and RFC 2518 can come out with
such different proposals helps to illustrate the issue. Rather than
attempting to achieve consensus in one fell swoop by having everyone read
and critique full proposals I would suggest that we start from a simpler
basis. Let us first see if we can establish agreement on some very basic
precepts. I will start with just one precept and see if we can get agreement
on just that.

Precept #1 - HTTP clients send HTTP request messages to resources that
respond with HTTP response messages.

Corollary #1.1 - All HTTP proposals can only be written in terms of how a
resource processes a HTTP request from a HTTP client and generates a HTTP
response as a result.

Corollary #1.2 - HTTP requests do not necessarily have to be handled by HTTP
resources. For example, it is possible to send a HTTP request with a FTP
request-URI. Some HTTP proxies are set up to act as gateways that can handle
translating the HTTP request into a FTP request and then translate the FTP
response into a HTTP response. That is why precept #1 states "...to
resources..." rather than specifying a HTTP resource.

Corollary #1.3 - Since HTTP request messages can only be handled by
resources which respond with HTTP response messages then even error messages
such as "Not Found" must have been generated by a resource.

Let's see if we can just get agreement on this single precept and its
corollaries.

	Merci,

			Yaron



From w3c-dist-auth-request@w3.org  Mon Jan  3 16:21:00 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07809
	for <webdav-archive@odin.ietf.org>; Mon, 3 Jan 2000 16:20:59 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id QAA01353;
	Mon, 3 Jan 2000 16:09:43 -0500 (EST)
Resent-Date: Mon, 3 Jan 2000 16:09:43 -0500 (EST)
Resent-Message-Id: <200001032109.QAA01353@www19.w3.org>
Message-ID: <004501bf562e$ceafdf20$9a114498@us.oracle.com>
From: "Eric Sedlar" <esedlar@us.oracle.com>
To: "Yaron Goland" <yarong@Exchange.Microsoft.com>
Cc: <w3c-dist-auth@w3.org>
References: <7DE119D3D0E15543874F7561EECBDBED02619DEA@BEG.platinum.corp.microsoft.com>
Date: Mon, 3 Jan 2000 13:09:22 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0042_01BF55EB.C05821A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Subject: Re: Your proposal
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3781
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This is a multi-part message in MIME format.

------=_NextPart_000_0042_01BF55EB.C05821A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Your proposalOne problem with your qualms about properties is that we =
are trying to map WebDAV data to object representation systems that do =
not have functional semantics, like XML.  We should define an interface =
that doesn't rely on the distinction between functional interfaces and =
properties for maximum implementability on various servers.  (This =
distinction is something may programmers have trouble with--does =
everyone always bother to create accessor methods for everything?  ...)  =
The benefit of using live properties as a representation is that object =
properties are more "portable" to the other types of systems that may =
want to access the same data, presumably through another means than the =
HTTP protocol (which isn't particularly efficient).  (Which brings me to =
another unrelated issue--should there be a functional interface to =
WebDAV methods for programs living in the same server as the data =
repository, given the performance costs of HTTP within a single =
process--more on that later).

Yes you need a set of clear rules for how live properties are used, and =
unless their use is rigorously controlled, you will have compatability =
problems of the type you cite, but this is a problem with any loosely =
written standard.
I think of properties in the JavaBeans sense--in an OO language binding, =
they would actually be functional interfaces to set and retrieve them, =
but could be overridden to provide customized behaviour.  Any JavaBeans =
user has no idea whether or not this piece of data is live or not, and =
this model works well.

--Eric
  ----- Original Message -----=20
  From: Yaron Goland=20
  To: 'Eric Sedlar'=20
  Sent: Monday, January 03, 2000 11:18 AM
  Subject: Your proposal


  Eric, I read your analysis of Geoff's proposal and was really =
impressed by your deep grasp of both HTTP and WebDAV.=20

  I have a series of issues with your counter-proposal but I'm going to =
hold off on commenting until we can build up more of a common base for =
conversation. Please see my post on the mailing list in regards to this.

  I did, however, want to point out a general design issue regarding =
your proposal that isn't directly related to locks. In your proposal you =
suggest using properties to provide various bits of protocol =
information, such as which names are currently locked. I would caution =
against using properties in this way, see =
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0302.html =
for more details. For a history of how we ended up in this mess in the =
first place see =
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0074.html =
and =
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html. =
BTW, all of these posts are collected in the WebDAV Book of Why =
available at =
http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html.

                  Thanks,=20
                                  Yaron=20


------=_NextPart_000_0042_01BF55EB.C05821A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Your proposal</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>One problem with your qualms about =
properties is=20
that we are trying to map WebDAV data to object representation systems =
that do=20
not have functional semantics, like XML.&nbsp; We should define an =
interface=20
that doesn't rely on the distinction between functional interfaces and=20
properties for maximum implementability on various servers.&nbsp; (This=20
distinction is something may programmers have trouble with--does =
everyone always=20
bother to create accessor methods for everything?&nbsp; ...)&nbsp; The =
benefit=20
of using live properties as a representation is that object properties =
are more=20
"portable" to the other types of systems that may want to access the =
same data,=20
presumably through another means than the HTTP protocol (which isn't=20
particularly efficient).&nbsp; (Which brings me to another unrelated=20
issue--should there be a functional interface to WebDAV methods for =
programs=20
living in the same server as the data repository, given the performance =
costs of=20
HTTP within a single process--more on that later).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Yes you need a set of clear rules for =
how live=20
properties are used, and unless their use is rigorously controlled, you =
will=20
have compatability problems of the type you cite, but this is a problem =
with any=20
loosely written standard.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I think of properties in the JavaBeans =
sense--in an=20
OO language binding, they would actually be functional interfaces to set =
and=20
retrieve them, but could be overridden to provide customized =
behaviour.&nbsp;=20
Any JavaBeans user has no idea whether or not this piece of data is live =
or not,=20
and this model works well.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>--Eric</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:yarong@Exchange.Microsoft.com"=20
  title=3Dyarong@Exchange.Microsoft.com>Yaron Goland</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  href=3D"mailto:esedlar@us.oracle.com" =
title=3Desedlar@us.oracle.com>'Eric=20
  Sedlar'</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, January 03, 2000 =
11:18=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Your proposal</DIV>
  <DIV><BR></DIV>
  <P><FONT face=3DArial size=3D2>Eric, I read your analysis of Geoff's =
proposal and=20
  was really impressed by your deep grasp of both HTTP and =
WebDAV.</FONT> </P>
  <P><FONT face=3DArial size=3D2>I have a series of issues with your=20
  counter-proposal but I'm going to hold off on commenting until we can =
build up=20
  more of a common base for conversation. Please see my post on the =
mailing list=20
  in regards to this.</FONT></P>
  <P><FONT face=3DArial size=3D2>I did, however, want to point out a =
general design=20
  issue regarding your proposal that isn't directly related to locks. In =
your=20
  proposal you suggest using properties to provide various bits of =
protocol=20
  information, such as which names are currently locked. I would caution =
against=20
  using properties in this way, see <A=20
  =
href=3D"http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0302=
.html"=20
  =
target=3D_blank>http://lists.w3.org/Archives/Public/w3c-dist-auth/1998Oct=
Dec/0302.html</A>=20
  for more details. For a history of how we ended up in this mess in the =
first=20
  place see <A=20
  =
href=3D"http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0074=
.html"=20
  =
target=3D_blank>http://lists.w3.org/Archives/Public/w3c-dist-auth/1998Oct=
Dec/0074.html</A>=20
  and <A=20
  =
href=3D"http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303=
.html"=20
  =
target=3D_blank>http://lists.w3.org/Archives/Public/w3c-dist-auth/1998Oct=
Dec/0303.html</A>.=20
  BTW, all of these posts are collected in the WebDAV Book of Why =
available at=20
  <A=20
  =
href=3D"http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129=
.html"=20
  =
target=3D_blank>http://lists.w3.org/Archives/Public/w3c-dist-auth/1999Jan=
Mar/0129.html</A>.</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=3DArial=20
  size=3D2>Thanks,</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=3DArial=20
  size=3D2>Yaron</FONT> </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0042_01BF55EB.C05821A0--



From w3c-dist-auth-request@w3.org  Mon Jan  3 18:58:30 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09200
	for <webdav-archive@odin.ietf.org>; Mon, 3 Jan 2000 18:58:30 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA04545;
	Mon, 3 Jan 2000 18:47:26 -0500 (EST)
Resent-Date: Mon, 3 Jan 2000 18:47:26 -0500 (EST)
Resent-Message-Id: <200001032347.SAA04545@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619DEC@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'Eric Sedlar'" <esedlar@us.oracle.com>
Cc: w3c-dist-auth@w3.org
Date: Mon, 3 Jan 2000 15:45:23 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF5644.D81E20E2"
Subject: RE: Your proposal
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3782
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF5644.D81E20E2
Content-Type: text/plain;
	charset="iso-8859-1"

I wouldn't accept a blanket statement that HTTP has lousy performance. I
have seen it repeatedly beat the pants off all competing systems. 
 
For example, we did a speed comparison of a super optimized SMB
implementation and DAV in W2K. DAV won hands down. The reason is that SMB,
like most protocols of its ilk, is unbelievably chatty. They are basically
RPCs rather than protocols. DAV, on the other hand, is extremely optimized.
So even though the SMB implementation could process some ridiculous number
of messages per second DAV still had better performance because it sent a
hell of a lot less messages.
 
As for the use of properties, I assert that there is no difference between
executing a GETLOCKEDNAME method and getting the lockedname property in
terms of how you write your back end. However, the first is a hell of a lot
easier to deal with in terms of specifying and extending the protocol than
the second. So the issue isn't one of back end implementation, it is one of
front end convenience.
 
In other words, just say NO to live properties.
 
            Yaron

-----Original Message-----
From: Eric Sedlar [mailto:esedlar@us.oracle.com]
Sent: Monday, January 03, 2000 1:09 PM
To: Yaron Goland
Cc: w3c-dist-auth@w3.org
Subject: Re: Your proposal


One problem with your qualms about properties is that we are trying to map
WebDAV data to object representation systems that do not have functional
semantics, like XML.  We should define an interface that doesn't rely on the
distinction between functional interfaces and properties for maximum
implementability on various servers.  (This distinction is something may
programmers have trouble with--does everyone always bother to create
accessor methods for everything?  ...)  The benefit of using live properties
as a representation is that object properties are more "portable" to the
other types of systems that may want to access the same data, presumably
through another means than the HTTP protocol (which isn't particularly
efficient).  (Which brings me to another unrelated issue--should there be a
functional interface to WebDAV methods for programs living in the same
server as the data repository, given the performance costs of HTTP within a
single process--more on that later).
 
Yes you need a set of clear rules for how live properties are used, and
unless their use is rigorously controlled, you will have compatability
problems of the type you cite, but this is a problem with any loosely
written standard.
I think of properties in the JavaBeans sense--in an OO language binding,
they would actually be functional interfaces to set and retrieve them, but
could be overridden to provide customized behaviour.  Any JavaBeans user has
no idea whether or not this piece of data is live or not, and this model
works well.
 
--Eric

----- Original Message ----- 
From: Yaron Goland <mailto:yarong@Exchange.Microsoft.com>  
To: 'Eric  <mailto:esedlar@us.oracle.com> Sedlar' 
Sent: Monday, January 03, 2000 11:18 AM
Subject: Your proposal


Eric, I read your analysis of Geoff's proposal and was really impressed by
your deep grasp of both HTTP and WebDAV. 

I have a series of issues with your counter-proposal but I'm going to hold
off on commenting until we can build up more of a common base for
conversation. Please see my post on the mailing list in regards to this.

I did, however, want to point out a general design issue regarding your
proposal that isn't directly related to locks. In your proposal you suggest
using properties to provide various bits of protocol information, such as
which names are currently locked. I would caution against using properties
in this way, see
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0302.html
<http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0302.html>
for more details. For a history of how we ended up in this mess in the first
place see
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0074.html
<http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0074.html>
and http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html
<http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html> .
BTW, all of these posts are collected in the WebDAV Book of Why available at
http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html
<http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html> .

                Thanks, 
                                Yaron 


------_=_NextPart_001_01BF5644.D81E20E2
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Your proposal</TITLE>

<META content="MSHTML 5.00.2920.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=352403723-03012000>I 
wouldn't accept a blanket statement that HTTP has lousy performance. I have seen 
it repeatedly beat the pants off all competing systems. </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=352403723-03012000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=352403723-03012000>For 
example, we did a speed comparison of a super optimized SMB implementation and 
DAV in W2K. DAV won hands down. The reason is that SMB, like most protocols of 
its ilk,&nbsp;is unbelievably chatty. They are basically RPCs rather than 
protocols. DAV, on the other hand, is extremely optimized. So even though the 
SMB implementation could process some ridiculous number of messages per second 
DAV still had better performance because it sent a hell of a lot less 
messages.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=352403723-03012000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=352403723-03012000>As for 
the use of properties, I assert that there is no difference between executing a 
GETLOCKEDNAME method and getting the lockedname property in terms of how you 
write your back end. However, the first is a hell of a lot easier to deal with 
in terms of specifying and extending the protocol than the second. So the issue 
isn't one of back end implementation, it is one of front end 
convenience.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=352403723-03012000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=352403723-03012000>In 
other words, just say NO to live properties.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=352403723-03012000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=352403723-03012000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Yaron</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Eric Sedlar 
  [mailto:esedlar@us.oracle.com]<BR><B>Sent:</B> Monday, January 03, 2000 1:09 
  PM<BR><B>To:</B> Yaron Goland<BR><B>Cc:</B> 
  w3c-dist-auth@w3.org<BR><B>Subject:</B> Re: Your proposal<BR><BR></DIV></FONT>
  <DIV><FONT face=Arial size=2>One problem with your qualms about properties is 
  that we are trying to map WebDAV data to object representation systems that do 
  not have functional semantics, like XML.&nbsp; We should define an interface 
  that doesn't rely on the distinction between functional interfaces and 
  properties for maximum implementability on various servers.&nbsp; (This 
  distinction is something may programmers have trouble with--does everyone 
  always bother to create accessor methods for everything?&nbsp; ...)&nbsp; The 
  benefit of using live properties as a representation is that object properties 
  are more "portable" to the other types of systems that may want to access the 
  same data, presumably through another means than the HTTP protocol (which 
  isn't particularly efficient).&nbsp; (Which brings me to another unrelated 
  issue--should there be a functional interface to WebDAV methods for programs 
  living in the same server as the data repository, given the performance costs 
  of HTTP within a single process--more on that later).</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>Yes you need a set of clear rules for how live 
  properties are used, and unless their use is rigorously controlled, you will 
  have compatability problems of the type you cite, but this is a problem with 
  any loosely written standard.</FONT></DIV>
  <DIV><FONT face=Arial size=2>I think of properties in the JavaBeans sense--in 
  an OO language binding, they would actually be functional interfaces to set 
  and retrieve them, but could be overridden to provide customized 
  behaviour.&nbsp; Any JavaBeans user has no idea whether or not this piece of 
  data is live or not, and this model works well.</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>--Eric</FONT></DIV>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
    <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV 
    style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
    <A href="mailto:yarong@Exchange.Microsoft.com" 
    title=yarong@Exchange.Microsoft.com>Yaron Goland</A> </DIV>
    <DIV style="FONT: 10pt arial"><B>To:</B> <A 
    href="mailto:esedlar@us.oracle.com" title=esedlar@us.oracle.com>'Eric 
    Sedlar'</A> </DIV>
    <DIV style="FONT: 10pt arial"><B>Sent:</B> Monday, January 03, 2000 11:18 
    AM</DIV>
    <DIV style="FONT: 10pt arial"><B>Subject:</B> Your proposal</DIV>
    <DIV><BR></DIV>
    <P><FONT face=Arial size=2>Eric, I read your analysis of Geoff's proposal 
    and was really impressed by your deep grasp of both HTTP and WebDAV.</FONT> 
    </P>
    <P><FONT face=Arial size=2>I have a series of issues with your 
    counter-proposal but I'm going to hold off on commenting until we can build 
    up more of a common base for conversation. Please see my post on the mailing 
    list in regards to this.</FONT></P>
    <P><FONT face=Arial size=2>I did, however, want to point out a general 
    design issue regarding your proposal that isn't directly related to locks. 
    In your proposal you suggest using properties to provide various bits of 
    protocol information, such as which names are currently locked. I would 
    caution against using properties in this way, see <A 
    href="http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0302.html" 
    target=_blank>http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0302.html</A> 
    for more details. For a history of how we ended up in this mess in the first 
    place see <A 
    href="http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0074.html" 
    target=_blank>http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0074.html</A> 
    and <A 
    href="http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html" 
    target=_blank>http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html</A>. 
    BTW, all of these posts are collected in the WebDAV Book of Why available at 
    <A 
    href="http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html" 
    target=_blank>http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html</A>.</FONT></P>
    <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial 
    size=2>Thanks,</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial 
    size=2>Yaron</FONT> </P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BF5644.D81E20E2--



From w3c-dist-auth-request@w3.org  Mon Jan  3 19:12:13 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09319
	for <webdav-archive@odin.ietf.org>; Mon, 3 Jan 2000 19:12:12 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id TAA05024;
	Mon, 3 Jan 2000 19:01:27 -0500 (EST)
Resent-Date: Mon, 3 Jan 2000 19:01:27 -0500 (EST)
Resent-Message-Id: <200001040001.TAA05024@www19.w3.org>
Message-ID: <387139FF.100634F4@us.oracle.com>
Date: Mon, 03 Jan 2000 16:08:31 -0800
From: Eric Sedlar <esedlar@us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Yaron Goland <yarong@Exchange.Microsoft.com>
CC: w3c-dist-auth@w3.org, "'gclemm@atria.com'" <gclemm@atria.com>
References: <7DE119D3D0E15543874F7561EECBDBED02619DE9@BEG.platinum.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Translation in the Tower of Babble
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3783
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

Yaron,

The problem with discussing abstractions like this without concrete examples is
like trying to write legislation without loopholes--you don't really know if
it's well written until you see its effects.

My guess is that the direction you are heading in is defining a resource as the
base class of all WebDAV objects capable of responding to an HTTP request.
This is a good abstraction.  It follows from this that an HTTP method like LOCK
should not apply to a URL that does not identify a resource, since there is no
resource to respond to the request, which would outlaw the lock-null approach.

It might be useful to give more of an "agenda" for where this thread is going
(even without filling in the details), so people can better place your
discussion in context of the world of WebDAV problems.

In general, however, I think that any solution to the locking problems
discussed recently has to fit in some general model like the one I anticipate
that Yaron will propose.  However, I prefer a complete model to be laid out
before me before I comment on particular precepts of the model.

For example, following this level of abstraction, we should define a resource
better.  I would say that a resource has a set of properties, which can be
represented via an XML document.  Some of these properties are
"live" properties, which are read-only and are set as a side effect of other
methods ( for example a modification date).  Attempts to set the value of a
live property directly via generic property mutator method(s) (e.g. PROPPATCH,
PUT, etc.) should always be ignored.  A collection is a subclass of resource
that has a live property containing a list of tuples including at least a name
(and possibly with other values such as a resource ID associated with that
name).  A BIND request is treated as a method that modifies the values of the
collection's name tuple list.

This should all be worked into the versioning model document
(http://www.ics.uci.edu/pub/ietf/webdav/versioning/model990209/), which while
defining some of the functional methods available on a resource, doesn't define
the properties on a resource as well as a number of the other assumptions along
the lines Yaron proposes.

--Eric



Yaron Goland wrote:

> I believe that there are too many different unstated assumptions held by
> members of this group for this group to be ready to deal with specific
> locking proposals. The fact that Geoff, Eric and RFC 2518 can come out with
> such different proposals helps to illustrate the issue. Rather than
> attempting to achieve consensus in one fell swoop by having everyone read
> and critique full proposals I would suggest that we start from a simpler
> basis. Let us first see if we can establish agreement on some very basic
> precepts. I will start with just one precept and see if we can get agreement
> on just that.
>
> Precept #1 - HTTP clients send HTTP request messages to resources that
> respond with HTTP response messages.
>
> Corollary #1.1 - All HTTP proposals can only be written in terms of how a
> resource processes a HTTP request from a HTTP client and generates a HTTP
> response as a result.
>
> Corollary #1.2 - HTTP requests do not necessarily have to be handled by HTTP
> resources. For example, it is possible to send a HTTP request with a FTP
> request-URI. Some HTTP proxies are set up to act as gateways that can handle
> translating the HTTP request into a FTP request and then translate the FTP
> response into a HTTP response. That is why precept #1 states "...to
> resources..." rather than specifying a HTTP resource.
>
> Corollary #1.3 - Since HTTP request messages can only be handled by
> resources which respond with HTTP response messages then even error messages
> such as "Not Found" must have been generated by a resource.
>
> Let's see if we can just get agreement on this single precept and its
> corollaries.
>
>         Merci,
>
>                         Yaron



From w3c-dist-auth-request@w3.org  Mon Jan  3 19:38:23 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09482
	for <webdav-archive@odin.ietf.org>; Mon, 3 Jan 2000 19:38:23 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id TAA06162;
	Mon, 3 Jan 2000 19:26:11 -0500 (EST)
Resent-Date: Mon, 3 Jan 2000 19:26:11 -0500 (EST)
Resent-Message-Id: <200001040026.TAA06162@www19.w3.org>
Message-ID: <38713FCB.ED63D67C@us.oracle.com>
Date: Mon, 03 Jan 2000 16:33:15 -0800
From: Eric Sedlar <esedlar@us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Yaron Goland <yarong@Exchange.Microsoft.com>
CC: w3c-dist-auth@w3.org
References: <7DE119D3D0E15543874F7561EECBDBED02619DEC@BEG.platinum.corp.microsoft.com>
Content-Type: multipart/alternative;
 boundary="------------D4BB2E8C9D1D7669A2F5C3EA"
Subject: Re: Your proposal
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3784
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


--------------D4BB2E8C9D1D7669A2F5C3EA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Now we get into our areas of disagreement.

* I mentioned HTTP as having lousy performance WITHIN A SINGLE PROCESS.
 I guarantee you that a function call is much cheaper than formatting
the request into a stream, writing into a loopback socket, reading the
result back, parsing it,  and then the reverse.  Another example is
SQL access to properties of a resource.  If I want to query the resource
data efficiently, I need to be able to treat properties of the resource
as "virtual data", not make a series of function calls on each item in
the query set.  If I want to write a servlet that takes an HTML form
input and changes WebDAV properties, I definitely want a functional API
(in Java).  Everyone knows that SMB sucks and is incredibly chatty.  As
far as HTTP performance, it mostly depends on the amount of
functionality you can pack into one request.  If I have to issue a
GETLOCKED name request followed by a bunch of other requests to get all
of the state of a particular resource, HTTP will suck.

My point was that the WebDAV model is actually bigger than HTTP--other
data access systems (like SQL and XML technologies) should also be able
to manipulate the data easily.

* Another reason for making all information about a resource available
as properties is using XSL to format an HTML page giving access to all
of this data.  There is a lot of support for not requiring a lot of
programming (ala JSPs or ASPs) to format data within a page.

* I don't understand why you think it will be easier to handle protocol
extensions on the client side by using additional HTTP methods rather
than resources.  XML applications are used to ignoring elements that
they don't care about--extensibility is one of the key wins of XML vs.
traditional OO languages.  It allows DOM objects to be passed around
multiple areas of the system better.  For example, let's say that I have
some client library which implements the client side of the
HTTP protocol, and allows plugins to that client to access the
XML DOM for each resource.  I can install a new client plugin to handle
new properties that appear in that DOM, but I won't be able to extend
the HTTP protocol.  HTTP protocol implementation is typically at a lower
level of the client or server than properties.

HTTP request/response parsers are not generic technology like
XML parsers are

* It sounds like you are arguing against the general trend of making all
of your data available via XML, which is counter to the general
strategies most technology companies are following now, including
Microsoft and Oracle.  With your proposal, you are going to render all
of the burgeoning XML technology base useless, which is why the WebDAV
people built around XML in the first place.

Is anyone thinking about a thin-client WebDAV implementation (HTML only)
running in a browser?  I should be able to do stuff like changing RSRs,
manipulate directories, etc. with a web app.

--Eric

Yaron Goland wrote:

> I wouldn't accept a blanket statement that HTTP has lousy performance.
> I have seen it repeatedly beat the pants off all competing
> systems. For example, we did a speed comparison of a super optimized
> SMB implementation and DAV in W2K. DAV won hands down. The reason is
> that SMB, like most protocols of its ilk, is unbelievably chatty. They
> are basically RPCs rather than protocols. DAV, on the other hand, is
> extremely optimized. So even though the SMB implementation could
> process some ridiculous number of messages per second DAV still had
> better performance because it sent a hell of a lot less messages.As
> for the use of properties, I assert that there is no difference
> between executing a GETLOCKEDNAME method and getting the lockedname
> property in terms of how you write your back end. However, the first
> is a hell of a lot easier to deal with in terms of specifying and
> extending the protocol than the second. So the issue isn't one of back
> end implementation, it is one of front end convenience.In other words,
> just say NO to live properties.            Yaron
>
>      -----Original Message-----
>      From: Eric Sedlar [mailto:esedlar@us.oracle.com]
>      Sent: Monday, January 03, 2000 1:09 PM
>      To: Yaron Goland
>      Cc: w3c-dist-auth@w3.org
>      Subject: Re: Your proposal
>
>      One problem with your qualms about properties is that we are
>      trying to map WebDAV data to object representation systems
>      that do not have functional semantics, like XML.  We should
>      define an interface that doesn't rely on the distinction
>      between functional interfaces and properties for maximum
>      implementability on various servers.  (This distinction is
>      something may programmers have trouble with--does everyone
>      always bother to create accessor methods for everything?
>      ...)  The benefit of using live properties as a
>      representation is that object properties are more "portable"
>      to the other types of systems that may want to access the
>      same data, presumably through another means than the HTTP
>      protocol (which isn't particularly efficient).  (Which
>      brings me to another unrelated issue--should there be a
>      functional interface to WebDAV methods for programs living
>      in the same server as the data repository, given the
>      performance costs of HTTP within a single process--more on
>      that later). Yes you need a set of clear rules for how live
>      properties are used, and unless their use is rigorously
>      controlled, you will have compatability problems of the type
>      you cite, but this is a problem with any loosely written
>      standard.I think of properties in the JavaBeans sense--in an
>      OO language binding, they would actually be functional
>      interfaces to set and retrieve them, but could be overridden
>      to provide customized behaviour.  Any JavaBeans user has no
>      idea whether or not this piece of data is live or not, and
>      this model works well. --Eric
>
>           ----- Original Message -----
>           From: Yaron Goland
>           To: 'Eric Sedlar'
>           Sent: Monday, January 03, 2000 11:18 AM
>           Subject: Your proposal
>            Eric, I read your analysis of Geoff's proposal
>           and was really impressed by your deep grasp of
>           both HTTP and WebDAV.
>
>           I have a series of issues with your
>           counter-proposal but I'm going to hold off on
>           commenting until we can build up more of a common
>           base for conversation. Please see my post on the
>           mailing list in regards to this.
>
>           I did, however, want to point out a general design
>           issue regarding your proposal that isn't directly
>           related to locks. In your proposal you suggest
>           using properties to provide various bits of
>           protocol information, such as which names are
>           currently locked. I would caution against using
>           properties in this way, see
>           http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0302.html
>           for more details. For a history of how we ended up
>           in this mess in the first place see
>           http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0074.html
>           and
>           http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html.
>           BTW, all of these posts are collected in the
>           WebDAV Book of Why available at
>           http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html.
>
>                           Thanks,
>                                           Yaron
>

--------------D4BB2E8C9D1D7669A2F5C3EA
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
Now we get into our areas of disagreement.
<p>*&nbsp;I mentioned HTTP as having lousy performance WITHIN&nbsp;A&nbsp;SINGLE&nbsp;PROCESS.
&nbsp;I&nbsp;guarantee you that a function call is much cheaper than formatting
the request into a stream, writing into a loopback socket, reading the
result back, parsing it,&nbsp; and then the reverse.&nbsp; Another example
is SQL&nbsp;access to properties of a resource.&nbsp; If I&nbsp;want to
query the resource data efficiently, I&nbsp;need to be able to treat properties
of the resource as "virtual data", not make a series of function calls
on each item in the query set.&nbsp; If I&nbsp;want to write a servlet
that takes an HTML&nbsp;form input and changes WebDAV properties, I&nbsp;definitely
want a functional API (in Java).&nbsp; Everyone knows that SMB&nbsp;sucks
and is incredibly chatty.&nbsp; As far as HTTP&nbsp;performance, it mostly
depends on the amount of functionality you can pack into one request.&nbsp;
If I&nbsp;have to issue a GETLOCKED&nbsp;name request followed by a bunch
of other requests to get all of the state of a particular resource, HTTP&nbsp;will
suck.
<p>My point was that the WebDAV&nbsp;model is actually bigger than HTTP--other
data access systems (like SQL and XML technologies) should also be able
to manipulate the data easily.
<p>*&nbsp;Another reason for making all information about a resource available
as properties is using XSL&nbsp;to format an HTML&nbsp;page giving access
to all of this data.&nbsp; There is a lot of support for not requiring
a lot of programming (ala JSPs or ASPs)&nbsp;to format data within a page.
<p>*&nbsp;I&nbsp;don't understand why you think it will be easier to handle
protocol extensions on the client side by using additional HTTP&nbsp;methods
rather than resources.&nbsp; XML&nbsp;applications are used to ignoring
elements that they don't care about--extensibility is one of the key wins
of XML&nbsp;vs. traditional OO&nbsp;languages.&nbsp; It allows DOM&nbsp;objects
to be passed around multiple areas of the system better.&nbsp; For example,
let's say that I&nbsp;have some client library which implements the client
side of the HTTP&nbsp;protocol, and allows plugins to that client to access
the XML&nbsp;DOM&nbsp;for each resource.&nbsp; I&nbsp;can install a new
client plugin to handle new properties that appear in that DOM, but I&nbsp;won't
be able to extend the HTTP&nbsp;protocol.&nbsp; HTTP protocol implementation
is typically at a lower level of the client or server than properties.
<p>HTTP&nbsp;request/response parsers are not generic technology like XML&nbsp;parsers
are
<p>*&nbsp;It sounds like you are arguing against the general trend of making
all of your data available via XML, which is counter to the general strategies
most technology companies are following now, including Microsoft and Oracle.&nbsp;
With your proposal, you are going to render all of the burgeoning XML&nbsp;technology
base useless, which is why the WebDAV people built around XML&nbsp;in the
first place.
<p>Is anyone thinking about a thin-client WebDAV&nbsp;implementation (HTML&nbsp;only)
running in a browser?&nbsp; I&nbsp;should be able to do stuff like changing
RSRs, manipulate directories, etc. with a web app.
<p>--Eric
<p>Yaron Goland wrote:
<blockquote TYPE=CITE><style></style>
<span class=352403723-03012000><font face="Arial"><font color="#0000FF"><font size=-1>I
wouldn't accept a blanket statement that HTTP has lousy performance. I
have seen it repeatedly beat the pants off all competing systems.&nbsp;</font></font></font></span><span 
class=352403723-03012000></span><span class=352403723-03012000><font face="Arial"><font color="#0000FF"><font size=-1>For
example, we did a speed comparison of a super optimized SMB implementation
and DAV in W2K. DAV won hands down. The reason is that SMB, like most protocols
of its ilk, is unbelievably chatty. They are basically RPCs rather than
protocols. DAV, on the other hand, is extremely optimized. So even though
the SMB implementation could process some ridiculous number of messages
per second DAV still had better performance because it sent a hell of a
lot less messages.</font></font></font></span><span 
class=352403723-03012000></span><span class=352403723-03012000><font face="Arial"><font color="#0000FF"><font size=-1>As
for the use of properties, I assert that there is no difference between
executing a GETLOCKEDNAME method and getting the lockedname property in
terms of how you write your back end. However, the first is a hell of a
lot easier to deal with in terms of specifying and extending the protocol
than the second. So the issue isn't one of back end implementation, it
is one of front end convenience.</font></font></font></span><span 
class=352403723-03012000></span><span class=352403723-03012000><font face="Arial"><font color="#0000FF"><font size=-1>In
other words, just say NO to live properties.</font></font></font></span><span 
class=352403723-03012000></span><span 
class=352403723-03012000><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Yaron</font></font></font></span>
<blockquote 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
<div class="OutlookMessageHeader" dir="ltr"><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Eric Sedlar [<A HREF="mailto:esedlar@us.oracle.com">mailto:esedlar@us.oracle.com</A>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Monday, January 03,
2000 1:09 PM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> Yaron Goland</font></font>
<br><font face="Tahoma"><font size=-1><b>Cc:</b> w3c-dist-auth@w3.org</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> Re: Your proposal</font></font>
<br>&nbsp;</div>
<font face="Arial"><font size=-1>One problem with your qualms about properties
is that we are trying to map WebDAV data to object representation systems
that do not have functional semantics, like XML.&nbsp; We should define
an interface that doesn't rely on the distinction between functional interfaces
and properties for maximum implementability on various servers.&nbsp; (This
distinction is something may programmers have trouble with--does everyone
always bother to create accessor methods for everything?&nbsp; ...)&nbsp;
The benefit of using live properties as a representation is that object
properties are more "portable" to the other types of systems that may want
to access the same data, presumably through another means than the HTTP
protocol (which isn't particularly efficient).&nbsp; (Which brings me to
another unrelated issue--should there be a functional interface to WebDAV
methods for programs living in the same server as the data repository,
given the performance costs of HTTP within a single process--more on that
later).</font></font>&nbsp;<font face="Arial"><font size=-1>Yes you need
a set of clear rules for how live properties are used, and unless their
use is rigorously controlled, you will have compatability problems of the
type you cite, but this is a problem with any loosely written standard.</font></font><font face="Arial"><font size=-1>I
think of properties in the JavaBeans sense--in an OO language binding,
they would actually be functional interfaces to set and retrieve them,
but could be overridden to provide customized behaviour.&nbsp; Any JavaBeans
user has no idea whether or not this piece of data is live or not, and
this model works well.</font></font>&nbsp;<font face="Arial"><font size=-1>--Eric</font></font>
<blockquote 
  style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
<div style="FONT: 10pt arial">----- Original Message -----</div>

<div 
    style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><b>From:</b>
<a href="mailto:yarong@Exchange.Microsoft.com" title="yarong@Exchange.Microsoft.com">Yaron
Goland</a></div>

<div style="FONT: 10pt arial"><b>To:</b> <a href="mailto:esedlar@us.oracle.com" title="esedlar@us.oracle.com">'Eric
Sedlar'</a></div>

<div style="FONT: 10pt arial"><b>Sent:</b> Monday, January 03, 2000 11:18
AM</div>

<div style="FONT: 10pt arial"><b>Subject:</b> Your proposal</div>
&nbsp;<font face="Arial"><font size=-1>Eric, I read your analysis of Geoff's
proposal and was really impressed by your deep grasp of both HTTP and WebDAV.</font></font>
<p><font face="Arial"><font size=-1>I have a series of issues with your
counter-proposal but I'm going to hold off on commenting until we can build
up more of a common base for conversation. Please see my post on the mailing
list in regards to this.</font></font>
<p><font face="Arial"><font size=-1>I did, however, want to point out a
general design issue regarding your proposal that isn't directly related
to locks. In your proposal you suggest using properties to provide various
bits of protocol information, such as which names are currently locked.
I would caution against using properties in this way, see <a href="http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0302.html" target="_blank">http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0302.html</a>
for more details. For a history of how we ended up in this mess in the
first place see <a href="http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0074.html" target="_blank">http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0074.html</a>
and <a href="http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html" target="_blank">http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html</a>.
BTW, all of these posts are collected in the WebDAV Book of Why available
at <a href="http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html" target="_blank">http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html</a>.</font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<font face="Arial"><font size=-1>Thanks,</font></font>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<font face="Arial"><font size=-1>Yaron</font></font></blockquote>
</blockquote>
</blockquote>

</body>
</html>

--------------D4BB2E8C9D1D7669A2F5C3EA--



From w3c-dist-auth-request@w3.org  Tue Jan  4 00:27:27 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13782
	for <webdav-archive@odin.ietf.org>; Tue, 4 Jan 2000 00:27:27 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id AAA10996;
	Tue, 4 Jan 2000 00:16:19 -0500 (EST)
Resent-Date: Tue, 4 Jan 2000 00:16:19 -0500 (EST)
Resent-Message-Id: <200001040516.AAA10996@www19.w3.org>
Date: Tue, 4 Jan 2000 00:15:56 -0500
Message-Id: <10001040515.AA17718@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <4.1.20000102093420.00b4f5c0@pop.xs4all.nl> (message from Jim
	Davis on Sun, 02 Jan 2000 09:54:46 +0100)
Subject: Re: Creating a lock-null in a locked collection
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3785
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

   From: Jim Davis <jrd3@alum.mit.edu>

   At 05:33 PM 12/30/99 -0500, Geoffrey M. Clemm wrote:
   >
   >As an addendum to Yaron's response, I'll note that there is a proposal
   >that WebDAV locking is better understood as locks on URL's rather than
   >on resources. 

   I am not sure I understand what "is better understood as" means here. 

By this, I just meant that in order to make sense out of the locking
behavior described in 2518, it is better to think of the lock as being
applied to the URL (rather than to the resource identified by that URL).

In a simple model where every URL identifies a different resource, this
distinction is unimportant (except possibly to make sense of a "lock null
resource").  In a model where two distinct URL's can identify the same
resource (e.g. as a result of a BIND request), this distinction is
very significant.

   I would like it to be the case that if I have a datastore (file system, an
   object oriented database, an RDBMS, whatever) that *does* support locking,
   I can use the WebDAV to set a lock on a resource in the datastore,  and
   expect the lock to actually be set on the resource such that other
   applications accessing that very same resource likewise see the lock, even
   if they use a different protocol or API to do so.

I agree with JimA's response, namely, that the protection of the state
of a resource implied by a URL lock can be exposed and enforced for
alternative protocols that access the same resources, but as Eric has
pointed out, some locking semantics are much easier for current implementations
to enforce.

Cheers,
Geoff





From w3c-dist-auth-request@w3.org  Tue Jan  4 04:31:16 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26726
	for <webdav-archive@odin.ietf.org>; Tue, 4 Jan 2000 04:31:15 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id EAA14111;
	Tue, 4 Jan 2000 04:20:17 -0500 (EST)
Resent-Date: Tue, 4 Jan 2000 04:20:17 -0500 (EST)
Resent-Message-Id: <200001040920.EAA14111@www19.w3.org>
Date: Tue, 4 Jan 2000 10:21:15 +0100 (MET)
From: Yves Lafon <ylafon@w3.org>
X-Sender: ylafon@tarantula.inria.fr
To: Yaron Goland <yarong@Exchange.Microsoft.com>
cc: "'Eric Sedlar'" <esedlar@us.oracle.com>, w3c-dist-auth@w3.org,
        "'gclemm@atria.com'" <gclemm@atria.com>
In-Reply-To: <7DE119D3D0E15543874F7561EECBDBED02619DE9@BEG.platinum.corp.microsoft.com>
Message-ID: <Pine.GSO.4.21.0001041007490.27564-100000@tarantula.inria.fr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: Translation in the Tower of Babble
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3786
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

On Mon, 3 Jan 2000, Yaron Goland wrote:

> Precept #1 - HTTP clients send HTTP request messages to resources that
> respond with HTTP response messages.
> 
> Corollary #1.1 - All HTTP proposals can only be written in terms of how a
> resource processes a HTTP request from a HTTP client and generates a HTTP
> response as a result.
> 
> Corollary #1.2 - HTTP requests do not necessarily have to be handled by HTTP
> resources. For example, it is possible to send a HTTP request with a FTP
> request-URI. Some HTTP proxies are set up to act as gateways that can handle
> translating the HTTP request into a FTP request and then translate the FTP
> response into a HTTP response. That is why precept #1 states "...to
> resources..." rather than specifying a HTTP resource.

Hum, if you see the proxy as a HTTP resource, The HTTP resource acting as
a proxy may issue an ftp request then return a HTTP response to the HTTP
client", so even if it end up being a ftp request, the first HTTP request
was handled by an HTTP resource.
No matter how the content is generated, it always an HTTP resource that is
handling an HTTP request.
So Precept #1 should use "HTTP resources" and not resources. Also a
resource may be at the same time an HTTP resource, and answer according to
another protocol.

> Corollary #1.3 - Since HTTP request messages can only be handled by
> resources which respond with HTTP response messages then even error messages
> such as "Not Found" must have been generated by a resource.

Well if the resource can't handle HTTP request, the daemon that will ask
this resource to generate an HTTP reply should return to the client an
error stating that the resource doesn't support this protocol, like a Not
Found with a good explanation in the body.

      /\          - Yves Lafon - World Wide Web Consortium - 
  /\ /  \        Architecture Domain - Jigsaw Activity Leader
 /  \    \/\    
/    \   /  \   http://www.w3.org/People/Lafon - ylafon@w3.org    




From w3c-dist-auth-request@w3.org  Tue Jan  4 09:16:07 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28597
	for <webdav-archive@odin.ietf.org>; Tue, 4 Jan 2000 09:16:06 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id JAA19338;
	Tue, 4 Jan 2000 09:01:39 -0500 (EST)
Resent-Date: Tue, 4 Jan 2000 09:01:39 -0500 (EST)
Resent-Message-Id: <200001041401.JAA19338@www19.w3.org>
Message-Id: <4.1.20000104140118.00b4f470@pop.xs4all.nl>
X-Sender: contact@pop.lanminds.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 04 Jan 2000 14:16:48 +0100
To: w3c-dist-auth@w3.org
From: Jim Davis <jrd3@alum.mit.edu>
In-Reply-To: <7DE119D3D0E15543874F7561EECBDBED02619DE9@BEG.platinum.corp
 .microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Re: Precepts of Goland
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3787
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

At 11:50 AM 1/3/00 -0800, Yaron Goland wrote:
>...Let us first see if we can establish agreement on some very basic
>precepts. I will start with just one precept and see if we can get agreement
>on just that...

This is a good strategy to clarify the issues.

But there are two things I am unclear on.

First is procedural.  RFC 2518 exists, and has a fixed and known set of
authors.  When we have discussions like this, is the underlying assumption
that the conceptual model of RFC 2518 was either unclear, internally
inconsistent, or mistaken (perhaps because it can't be extended to support
new ideas like BIND?)  another way to say this, are we trying to
retroactively induce a consistent conceptual model for something that
already exists, or design something for the future.

Second concerns Precept #1

>
>Precept #1 - HTTP clients send HTTP request messages to resources that
>respond with HTTP response messages.

This seems reasonable, but there is at least one alternative.

Precept #1a - An HTTP client sends an HTTP request message  to a server
(which is a process running on a specific host at a specific port).  The
server interprets the URL in the request.  If the URL identifies a
resource, the server relays the method to the resource.  If not, server
interprets the method. For some methods, a 404 is issued.  For others,
something else happens.  What that something else is depends, on a case by
case basis.

This precept is more complicated, but does not require the ficticious "null
resource" neeed in Corollary #1.3  

>Corollary #1.3 - Since HTTP request messages can only be handled by
>resources which respond with HTTP response messages then even error messages
>such as "Not Found" must have been generated by a resource.

I have no position on whether 1a should be prefered to 1, nor do I claim
that this is the only other alternative to #1.



From w3c-dist-auth-request@w3.org  Tue Jan  4 11:45:02 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02115
	for <webdav-archive@odin.ietf.org>; Tue, 4 Jan 2000 11:45:01 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA24124;
	Tue, 4 Jan 2000 11:30:30 -0500 (EST)
Resent-Date: Tue, 4 Jan 2000 11:30:30 -0500 (EST)
Resent-Message-Id: <200001041630.LAA24124@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619DEE@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'Eric Sedlar'" <esedlar@us.oracle.com>
Cc: w3c-dist-auth@w3.org, "'gclemm@atria.com'" <gclemm@atria.com>
Date: Mon, 3 Jan 2000 18:00:03 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: RE: Translation in the Tower of Babble
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3788
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Actually I started down the path of trying to write a general model for
WebDAV in
http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0020.html but
no one seemed really enthusiastic about the project.

> -----Original Message-----
> From: Eric Sedlar [mailto:esedlar@us.oracle.com]
> Sent: Monday, January 03, 2000 4:09 PM
> To: Yaron Goland
> Cc: w3c-dist-auth@w3.org; 'gclemm@atria.com'
> Subject: Re: Translation in the Tower of Babble
> 
> 
> Yaron,
> 
> The problem with discussing abstractions like this without 
> concrete examples is
> like trying to write legislation without loopholes--you don't 
> really know if
> it's well written until you see its effects.
> 
> My guess is that the direction you are heading in is defining 
> a resource as the
> base class of all WebDAV objects capable of responding to an 
> HTTP request.
> This is a good abstraction.  It follows from this that an 
> HTTP method like LOCK
> should not apply to a URL that does not identify a resource, 
> since there is no
> resource to respond to the request, which would outlaw the 
> lock-null approach.
> 
> It might be useful to give more of an "agenda" for where this 
> thread is going
> (even without filling in the details), so people can better place your
> discussion in context of the world of WebDAV problems.
> 
> In general, however, I think that any solution to the locking problems
> discussed recently has to fit in some general model like the 
> one I anticipate
> that Yaron will propose.  However, I prefer a complete model 
> to be laid out
> before me before I comment on particular precepts of the model.
> 
> For example, following this level of abstraction, we should 
> define a resource
> better.  I would say that a resource has a set of properties, 
> which can be
> represented via an XML document.  Some of these properties are
> "live" properties, which are read-only and are set as a side 
> effect of other
> methods ( for example a modification date).  Attempts to set 
> the value of a
> live property directly via generic property mutator method(s) 
> (e.g. PROPPATCH,
> PUT, etc.) should always be ignored.  A collection is a 
> subclass of resource
> that has a live property containing a list of tuples 
> including at least a name
> (and possibly with other values such as a resource ID 
> associated with that
> name).  A BIND request is treated as a method that modifies 
> the values of the
> collection's name tuple list.
> 
> This should all be worked into the versioning model document
> (http://www.ics.uci.edu/pub/ietf/webdav/versioning/model990209
/), which while
defining some of the functional methods available on a resource, doesn't
define
the properties on a resource as well as a number of the other assumptions
along
the lines Yaron proposes.

--Eric



Yaron Goland wrote:

> I believe that there are too many different unstated assumptions held by
> members of this group for this group to be ready to deal with specific
> locking proposals. The fact that Geoff, Eric and RFC 2518 can come out
with
> such different proposals helps to illustrate the issue. Rather than
> attempting to achieve consensus in one fell swoop by having everyone read
> and critique full proposals I would suggest that we start from a simpler
> basis. Let us first see if we can establish agreement on some very basic
> precepts. I will start with just one precept and see if we can get
agreement
> on just that.
>
> Precept #1 - HTTP clients send HTTP request messages to resources that
> respond with HTTP response messages.
>
> Corollary #1.1 - All HTTP proposals can only be written in terms of how a
> resource processes a HTTP request from a HTTP client and generates a HTTP
> response as a result.
>
> Corollary #1.2 - HTTP requests do not necessarily have to be handled by
HTTP
> resources. For example, it is possible to send a HTTP request with a FTP
> request-URI. Some HTTP proxies are set up to act as gateways that can
handle
> translating the HTTP request into a FTP request and then translate the FTP
> response into a HTTP response. That is why precept #1 states "...to
> resources..." rather than specifying a HTTP resource.
>
> Corollary #1.3 - Since HTTP request messages can only be handled by
> resources which respond with HTTP response messages then even error
messages
> such as "Not Found" must have been generated by a resource.
>
> Let's see if we can just get agreement on this single precept and its
> corollaries.
>
>         Merci,
>
>                         Yaron



From w3c-dist-auth-request@w3.org  Tue Jan  4 13:02:44 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03389
	for <webdav-archive@odin.ietf.org>; Tue, 4 Jan 2000 13:02:43 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA26983;
	Tue, 4 Jan 2000 12:49:33 -0500 (EST)
Resent-Date: Tue, 4 Jan 2000 12:49:33 -0500 (EST)
Resent-Message-Id: <200001041749.MAA26983@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A021@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'Jim Davis'" <jrd3@alum.mit.edu>, w3c-dist-auth@w3.org
Date: Tue, 4 Jan 2000 09:48:27 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: RE: Precepts of Goland
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3789
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

So Spoke Jim Davis:

> First is procedural.  RFC 2518 exists, and has a fixed and 
> known set of
> authors.  When we have discussions like this, is the 
> underlying assumption
> that the conceptual model of RFC 2518 was either unclear, internally
> inconsistent, or mistaken (perhaps because it can't be 
> extended to support
> new ideas like BIND?)  another way to say this, are we trying to
> retroactively induce a consistent conceptual model for something that
> already exists, or design something for the future.
> 

My own goal would be to establish what the object model for DAV SHOULD be.
If that requires us to violate RFC 2518, so be it. That is why it is called
a Proposed Standard. That means it can and will change. But, BTW, we should
not be to ready to change RFC 2518. If we do we will be required, if not by
IETF process then by common sense/market pressures, to make changes in such
a way that RFC 2518 clients/servers can continue to operate correctly.

> Precept #1a - An HTTP client sends an HTTP request message  
> to a server
> (which is a process running on a specific host at a specific 
> port).  The
> server interprets the URL in the request.  If the URL identifies a
> resource, the server relays the method to the resource.  If 
> not, server
> interprets the method. For some methods, a 404 is issued.  For others,
> something else happens.  What that something else is depends, 
> on a case by
> case basis.
> 
> This precept is more complicated, but does not require the 
> ficticious "null
> resource" neeed in Corollary #1.3  
> 

What is the difference between throwing in a new object, called a server,
and describing an instance of a resource called the null resource? They are,
point for point, the exact same idea. The big difference is that a null
resource allows us to leverage an object model with a single object and
describe behaviors with it. Talking about the server throws us into a lot of
really awful questions about how an implementation is put together. What
happens when a proxy is involved? What happens when I have a server farm?
What about a three tier system? I generally prefer to opt for the cleanest
abstraction, I believe that declaring there is one and only one object - a
resource and then basing everything off that single object will be the
cleanest way to go. Therefore I strongly prefer Precept #1.

		Yaron



From w3c-dist-auth-request@w3.org  Tue Jan  4 14:01:36 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04088
	for <webdav-archive@odin.ietf.org>; Tue, 4 Jan 2000 14:01:34 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA29075;
	Tue, 4 Jan 2000 13:49:00 -0500 (EST)
Resent-Date: Tue, 4 Jan 2000 13:49:00 -0500 (EST)
Resent-Message-Id: <200001041849.NAA29075@www19.w3.org>
From: ccjason@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: "Eric Sedlar" <esedlar@us.oracle.com>
cc: w3c-dist-auth@w3.org
Message-ID: <8525685C.006741AD.00@D51MTA03.pok.ibm.com>
Date: Tue, 4 Jan 2000 13:48:23 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: Creating a lock-null in a locked collection
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3790
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


>>
I think the point is that if the WebDAV locking model is too strange, it
will be hard to reconcile the WebDAV locking mechanism with the other
locking mechanisms.  Introducing new concepts like lock-null's makes it
much
more difficult and less intuitive to reconcile in this way.
>>
I agree that that was the real point in regard to LNR's.  I think most of
us are willing
to accept that complication if there is also sufficient benefit derived
from it, but based on previous discussions, it doesn't seem folks value
LNR's very much.


>>
Perhaps we should discuss other locking mechanisms in filesystems and
RDBMS's to validate this.
>>
Sounds good.


>>
My understanding is that both Windows & UNIX filesystems lock all of the
names in a directory when the directory is explicitly locked (via
lockf()/flock() or something similar).
>>
If so, that's fortunate because it's what all recent proposals have
suggested.
I don't think this is the case on Unix though (except by convention)
because
the locks there appear to be advisory.  I haven't tried any *directory*
locking in Windows but what you suggest sounds likely.

>>
  In Windows filesystems, this
guarantees that the name cannot change since each file can be in only one
directory.
>>
On Linux anyone can come along and modify or delete/unlink the (f)locked
resource.  The (f)locks are purely advisory... but are on the resource
itself.  That is, the locks don't prevent operations like
read/write/delete/etc... only other attempts to lock the resource.  And
those attempts to exclusively lock will fail no matter which filename is
used to specify an already locked resource.  -- FWIW, UNIX does  have
shared and exclusive locks.  They don't have read vs. write locks... but
essentially the exclusive lock is a "write" lock and the shared lock is a
"read" lock by convension.  Anyway, my point here is that the lock is on
the resource... and the path is in no sense protected.

On Windows, that's not the case.  Both the resource and the URI path are
locked.. but I haven't seen Windows do multiple bindings in the FS, so
that may change/refine the story here.

Anyone savvy in Window or Unix should feel free to correct me on any of
this.  All of the above is the result of both reading and testing.

Jason.




From w3c-dist-auth-request@w3.org  Tue Jan  4 15:35:50 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05909
	for <webdav-archive@odin.ietf.org>; Tue, 4 Jan 2000 15:35:47 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA01794;
	Tue, 4 Jan 2000 15:19:07 -0500 (EST)
Resent-Date: Tue, 4 Jan 2000 15:19:07 -0500 (EST)
Resent-Message-Id: <200001042019.PAA01794@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619DF1@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'Yves Lafon'" <ylafon@w3.org>
Cc: "'Eric Sedlar'" <esedlar@us.oracle.com>, w3c-dist-auth@w3.org,
        "'gclemm@atria.com'" <gclemm@atria.com>
Date: Tue, 4 Jan 2000 12:17:37 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: RE: Translation in the Tower of Babble
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3791
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

So spoke Yves:

> Hum, if you see the proxy as a HTTP resource, The HTTP 
> resource acting as
> a proxy may issue an ftp request then return a HTTP response 
> to the HTTP
> client", so even if it end up being a ftp request, the first 
> HTTP request
> was handled by an HTTP resource.
> No matter how the content is generated, it always an HTTP 
> resource that is
> handling an HTTP request.
> So Precept #1 should use "HTTP resources" and not resources. Also a
> resource may be at the same time an HTTP resource, and answer 
> according to
> another protocol.

I think the issue here is - does the object model deal with end-to-end or
hop-by-hop? That is, do we want to model a conversation between a client and
server differently just because there is a proxy in the middle? If we do
then I agree that we should change Precept #1 to state "HTTP resources". If
not then we may want to be more vague.

I suspect that we DO want to model hop-by-hop and we DO want to come up with
a simple shorthand for specifying end-to-end operations where the presence
or absence of proxies isn't of any relevance. Therefore I am amending
Precept #1 to state "HTTP resources".

> 
> > Corollary #1.3 - Since HTTP request messages can only be handled by
> > resources which respond with HTTP response messages then 
> even error messages
> > such as "Not Found" must have been generated by a resource.
> 
> Well if the resource can't handle HTTP request, the daemon 
> that will ask
> this resource to generate an HTTP reply should return to the client an
> error stating that the resource doesn't support this 
> protocol, like a Not
> Found with a good explanation in the body.
> 

Perhaps I'm misunderstanding but I assume you are just confirming that you
agree with #1.3. The resource which sent the "HTTP not supported" response
is an HTTP resource. What the resource is saying is "I don't want to talk to
you in HTTP." However the only way he could say that is if he supported
HTTP. He is still an HTTP compliant resource and therefore it was a resource
(in the object model) that generated the response.

>       /\          - Yves Lafon - World Wide Web Consortium - 
>   /\ /  \        Architecture Domain - Jigsaw Activity Leader
>  /  \    \/\    
> /    \   /  \   http://www.w3.org/People/Lafon - ylafon@w3.org    
> 
> 

So when the hell will Jigsaw support WebDAV?!?!? I can't figure out why,
when we are completing the vision that TBL laid out in his book, that
support for WebDAV from the W3C has been largely non-existent. It is very
kind of the W3C to host the mailing lists and make the archives available
but that is a far cry from actually embracing WebDAV. What am I missing? Has
the W3C decided to invest in WebDAV and I just missed the announcement?

		Thanks,
				Yaron



From w3c-dist-auth-request@w3.org  Wed Jan  5 02:15:23 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27996
	for <webdav-archive@odin.ietf.org>; Wed, 5 Jan 2000 02:15:23 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id CAA14672;
	Wed, 5 Jan 2000 02:04:21 -0500 (EST)
Resent-Date: Wed, 5 Jan 2000 02:04:21 -0500 (EST)
Resent-Message-Id: <200001050704.CAA14672@www19.w3.org>
Message-Id: <4.1.20000104232108.009fa820@pop.xs4all.nl>
Message-Id: <4.1.20000104232108.009fa820@pop.xs4all.nl>
X-Sender: contact@pop.lanminds.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 04 Jan 2000 23:28:35 +0100
To: w3c-dist-auth@w3.org
From: Jim Davis <jrd3@alum.mit.edu>
In-Reply-To: <7DE119D3D0E15543874F7561EECBDBED0261A021@BEG.platinum.corp
 .microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Precepts of Goland
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3792
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

At 09:48 AM 1/4/00 -0800, Yaron Goland wrote:
>So Spoke Jim Davis:
>
>> Precept #1a - An HTTP client sends an HTTP request message  
>> to a server...
>> 
>
>What is the difference between throwing in a new object, called a server,
>and describing an instance of a resource called the null resource? 

Well, this is just my intuition speaking, but I think many people are
comfortable with the idea of a "web server" being some chunk of software
that listens on a port, accepts HTTP requests, and interprets them somehow.
 It's a relatively familiar notion.  Surely if I talk about "the Apache Web
server" or Microsoft's IIS, people know roughly what I mean.  I am less
sure that people have an intuition about a null resource, especially since
we seem to need both a "plain" null resource and a "locked null" resource.
but again, this is just a hunch.

Even if I am right, it could also be that that very familiarity makes it
treacherous -- because t might be carrying conceptual baggage that does not
belong, e.g. people might start expecting WebDAV to provide a live property
that contains recent log entries or something.

Rather than debate this point any further, I will be silent a while and see
if anyone else has anything more principled to offer than a bare intuition.
 Or perhaps there is yet another Initial Precept.

regards

Jim



From w3c-dist-auth-request@w3.org  Wed Jan  5 02:23:13 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27995
	for <webdav-archive@odin.ietf.org>; Wed, 5 Jan 2000 02:15:23 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id CAA14694;
	Wed, 5 Jan 2000 02:04:27 -0500 (EST)
Resent-Date: Wed, 5 Jan 2000 02:04:27 -0500 (EST)
Resent-Message-Id: <200001050704.CAA14694@www19.w3.org>
Message-Id: <4.1.20000104231923.00b5c5f0@pop.xs4all.nl>
Message-Id: <4.1.20000104231923.00b5c5f0@pop.xs4all.nl>
X-Sender: contact@pop.lanminds.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 04 Jan 2000 23:21:06 +0100
To: w3c-dist-auth@w3.org
From: Jim Davis <jrd3@alum.mit.edu>
In-Reply-To: <7DE119D3D0E15543874F7561EECBDBED0261A021@BEG.platinum.corp
 .microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Precepts of Goland
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3793
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

At 09:48 AM 1/4/00 -0800, Yaron Goland wrote:
>So Spoke Jim Davis:
>
>>... are we trying to
>> retroactively induce a consistent conceptual model for something that
>> already exists, or design something for the future?
>> 
>My own goal would be to establish what the object model for DAV SHOULD be.
>If that requires us to violate RFC 2518, so be it. That is why it is called
>a Proposed Standard. That means it can and will change. But, BTW, we should
>not be too ready to change RFC 2518. If we do we will be required, if not by
>IETF process then by common sense/market pressures, to make changes in such
>a way that RFC 2518 clients/servers can continue to operate correctly.

Great, that's just how I see it too.  So on with the precepts then.



From w3c-dist-auth-request@w3.org  Wed Jan  5 04:53:52 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00341
	for <webdav-archive@odin.ietf.org>; Wed, 5 Jan 2000 04:53:52 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id EAA17727;
	Wed, 5 Jan 2000 04:41:59 -0500 (EST)
Resent-Date: Wed, 5 Jan 2000 04:41:59 -0500 (EST)
Resent-Message-Id: <200001050941.EAA17727@www19.w3.org>
Message-ID: <00de01bf5761$0e0de8a0$9a114498@us.oracle.com>
From: "Eric Sedlar" <esedlar@us.oracle.com>
To: "Yaron Goland" <yarong@Exchange.Microsoft.com>
Cc: <w3c-dist-auth@w3.org>, <gclemm@atria.com>
References: <7DE119D3D0E15543874F7561EECBDBED02619DEE@BEG.platinum.corp.microsoft.com>
Date: Wed, 5 Jan 2000 01:41:34 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Subject: Re: Translation in the Tower of Babble
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3794
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

Well the bottom line is whether or not Geoff is interested in using such a
model ;-)

--Eric

----- Original Message -----
From: "Yaron Goland" <yarong@Exchange.Microsoft.com>
To: "'Eric Sedlar'" <esedlar@us.oracle.com>
Cc: <w3c-dist-auth@w3.org>; <gclemm@atria.com>
Sent: Monday, January 03, 2000 6:00 PM
Subject: RE: Translation in the Tower of Babble


> Actually I started down the path of trying to write a general model for
> WebDAV in
> http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0020.html but
> no one seemed really enthusiastic about the project.
>
> > -----Original Message-----
> > From: Eric Sedlar [mailto:esedlar@us.oracle.com]
> > Sent: Monday, January 03, 2000 4:09 PM
> > To: Yaron Goland
> > Cc: w3c-dist-auth@w3.org; 'gclemm@atria.com'
> > Subject: Re: Translation in the Tower of Babble
> >
> >
> > Yaron,
> >
> > The problem with discussing abstractions like this without
> > concrete examples is
> > like trying to write legislation without loopholes--you don't
> > really know if
> > it's well written until you see its effects.
> >
> > My guess is that the direction you are heading in is defining
> > a resource as the
> > base class of all WebDAV objects capable of responding to an
> > HTTP request.
> > This is a good abstraction.  It follows from this that an
> > HTTP method like LOCK
> > should not apply to a URL that does not identify a resource,
> > since there is no
> > resource to respond to the request, which would outlaw the
> > lock-null approach.
> >
> > It might be useful to give more of an "agenda" for where this
> > thread is going
> > (even without filling in the details), so people can better place your
> > discussion in context of the world of WebDAV problems.
> >
> > In general, however, I think that any solution to the locking problems
> > discussed recently has to fit in some general model like the
> > one I anticipate
> > that Yaron will propose.  However, I prefer a complete model
> > to be laid out
> > before me before I comment on particular precepts of the model.
> >
> > For example, following this level of abstraction, we should
> > define a resource
> > better.  I would say that a resource has a set of properties,
> > which can be
> > represented via an XML document.  Some of these properties are
> > "live" properties, which are read-only and are set as a side
> > effect of other
> > methods ( for example a modification date).  Attempts to set
> > the value of a
> > live property directly via generic property mutator method(s)
> > (e.g. PROPPATCH,
> > PUT, etc.) should always be ignored.  A collection is a
> > subclass of resource
> > that has a live property containing a list of tuples
> > including at least a name
> > (and possibly with other values such as a resource ID
> > associated with that
> > name).  A BIND request is treated as a method that modifies
> > the values of the
> > collection's name tuple list.
> >
> > This should all be worked into the versioning model document
> > (http://www.ics.uci.edu/pub/ietf/webdav/versioning/model990209
> /), which while
> defining some of the functional methods available on a resource, doesn't
> define
> the properties on a resource as well as a number of the other assumptions
> along
> the lines Yaron proposes.
>
> --Eric
>
>
>
> Yaron Goland wrote:
>
> > I believe that there are too many different unstated assumptions held by
> > members of this group for this group to be ready to deal with specific
> > locking proposals. The fact that Geoff, Eric and RFC 2518 can come out
> with
> > such different proposals helps to illustrate the issue. Rather than
> > attempting to achieve consensus in one fell swoop by having everyone
read
> > and critique full proposals I would suggest that we start from a simpler
> > basis. Let us first see if we can establish agreement on some very basic
> > precepts. I will start with just one precept and see if we can get
> agreement
> > on just that.
> >
> > Precept #1 - HTTP clients send HTTP request messages to resources that
> > respond with HTTP response messages.
> >
> > Corollary #1.1 - All HTTP proposals can only be written in terms of how
a
> > resource processes a HTTP request from a HTTP client and generates a
HTTP
> > response as a result.
> >
> > Corollary #1.2 - HTTP requests do not necessarily have to be handled by
> HTTP
> > resources. For example, it is possible to send a HTTP request with a FTP
> > request-URI. Some HTTP proxies are set up to act as gateways that can
> handle
> > translating the HTTP request into a FTP request and then translate the
FTP
> > response into a HTTP response. That is why precept #1 states "...to
> > resources..." rather than specifying a HTTP resource.
> >
> > Corollary #1.3 - Since HTTP request messages can only be handled by
> > resources which respond with HTTP response messages then even error
> messages
> > such as "Not Found" must have been generated by a resource.
> >
> > Let's see if we can just get agreement on this single precept and its
> > corollaries.
> >
> >         Merci,
> >
> >                         Yaron
>



From w3c-dist-auth-request@w3.org  Wed Jan  5 10:24:05 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07530
	for <webdav-archive@odin.ietf.org>; Wed, 5 Jan 2000 10:24:03 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id KAA23225;
	Wed, 5 Jan 2000 10:05:31 -0500 (EST)
Resent-Date: Wed, 5 Jan 2000 10:05:31 -0500 (EST)
Resent-Message-Id: <200001051505.KAA23225@www19.w3.org>
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24555@crte147.wc.eso.mc.xerox.com>
From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'Eric Sedlar'" <esedlar@us.oracle.com>, Jim Whitehead <ejw@ics.uci.edu>,
        WebDAV WG <w3c-dist-auth@w3.org>
Cc: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
Date: Wed, 5 Jan 2000 10:05:11 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WG Last Call: Bindings Protocol
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3795
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Thanks for your comments on the bindings spec.

> -----Original Message-----
> From: Eric Sedlar [mailto:esedlar@us.oracle.com]
> Sent: Tuesday, December 28, 1999 1:28 AM
> To: Jim Whitehead; WebDAV WG
> Cc: Geoffrey M. Clemm
> Subject: Re: WG Last Call: Bindings Protocol
> 
> 
> This looks pretty good, as it addresses the circular 
> reference issue.  I'd
> still like to see an optional weak binding that is guaranteed 
> not to dangle
> but that also does not affect the reference count, as I think 
> that is needed
> when the implementor chooses not to allow circular BINDings affecting
> references.

When we first started talking about developing an advanced collections spec
two years ago, there was a lot of discussion about different flavors of
references/links/bindings that different servers might want to support.  The
upshot was so much confusion that we resolved not to touch issues of
weak/strong and their variants.

We have had to retreat from that resolve, in order to make sure clients will
understand exactly what they are getting when they create a binding or a
reference.  But we don't want to define semantics for all the possible
variants.  Instead we've chosen one flavor of binding and one flavor of
reference to specify, which we believe will be widely useful and which
complement each other.

It's quite possible that other flavors of bindings and references will be
specified in the future, and of course you are welcome to write a draft
specifying the sort of weak binding you are looking for.

> 
> A couple of other comments:
> 
> * on the security issue of revealing the set of bindings with the
> dav:bindings property:  I recommend some comment to the 
> effect that BINDings
> from unreadable collections should not be readable.  So, the list of
> bindings in this property would only show READABLE bindings 
> (and thus would
> be different depending on who was examining the property)

We do say in Section 11:

"A PROPFIND requesting DAV:bindings MUST return only those bindings that the
client is authorized to see."

So your suggestion is that in addition we say that if the client is not
authorized to read the collection C in which a binding C:(S->R) appears, the
client is also not authorized to see that value of the DAV:bindings property
on the resource R.  Then we could get rid of the security concern described
in 16.4.  Is that right?

> * some comment to the effect that if the URL is a versioned 
> resource, and
> the currently selected revision is changed, the resourceid 
> will not change.
> (I'm assuming that is what you want.)  So even though two 
> people might see
> different data from a GET request from the same URL (because 
> they would get
> a different revision selected), they would still have the 
> same resourceid.
> Therefore, people should NOT use resourceid to invalidate 
> caches or any
> other application that assumes a one to one correspondence between
> resourceid and data.

I think that your conclusions are all exactly correct, but I agree with
Jason that it would be better to discuss ramifications for versioning in the
DeltaV spec.

Thanks again for your comments.

--Judy



From w3c-dist-auth-request@w3.org  Wed Jan  5 13:07:09 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12221
	for <webdav-archive@odin.ietf.org>; Wed, 5 Jan 2000 13:07:07 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA28565;
	Wed, 5 Jan 2000 12:54:00 -0500 (EST)
Resent-Date: Wed, 5 Jan 2000 12:54:00 -0500 (EST)
Resent-Message-Id: <200001051754.MAA28565@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A043@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'Eric Sedlar'" <esedlar@us.oracle.com>
Cc: w3c-dist-auth@w3.org, gclemm@atria.com
Date: Wed, 5 Jan 2000 09:53:01 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Translation in the Tower of Babble
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3796
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

A'int that the truth.

Although I'm now in negotiations for a new position at MS that would allow
me to return my attentions to WebDAV. So Geoff, don't get too comfy. =)

			Yaron

> -----Original Message-----
> From: Eric Sedlar [mailto:esedlar@us.oracle.com]
> Sent: Wed, January 05, 2000 1:42 AM
> To: Yaron Goland
> Cc: w3c-dist-auth@w3.org; gclemm@atria.com
> Subject: Re: Translation in the Tower of Babble
> 
> 
> Well the bottom line is whether or not Geoff is interested in 
> using such a
> model ;-)
> 
> --Eric
> 
> ----- Original Message -----
> From: "Yaron Goland" <yarong@Exchange.Microsoft.com>
> To: "'Eric Sedlar'" <esedlar@us.oracle.com>
> Cc: <w3c-dist-auth@w3.org>; <gclemm@atria.com>
> Sent: Monday, January 03, 2000 6:00 PM
> Subject: RE: Translation in the Tower of Babble
> 
> 
> > Actually I started down the path of trying to write a 
> general model for
> > WebDAV in
> > 
> http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0
> 020.html but
> > no one seemed really enthusiastic about the project.
> >
> > > -----Original Message-----
> > > From: Eric Sedlar [mailto:esedlar@us.oracle.com]
> > > Sent: Monday, January 03, 2000 4:09 PM
> > > To: Yaron Goland
> > > Cc: w3c-dist-auth@w3.org; 'gclemm@atria.com'
> > > Subject: Re: Translation in the Tower of Babble
> > >
> > >
> > > Yaron,
> > >
> > > The problem with discussing abstractions like this without
> > > concrete examples is
> > > like trying to write legislation without loopholes--you don't
> > > really know if
> > > it's well written until you see its effects.
> > >
> > > My guess is that the direction you are heading in is defining
> > > a resource as the
> > > base class of all WebDAV objects capable of responding to an
> > > HTTP request.
> > > This is a good abstraction.  It follows from this that an
> > > HTTP method like LOCK
> > > should not apply to a URL that does not identify a resource,
> > > since there is no
> > > resource to respond to the request, which would outlaw the
> > > lock-null approach.
> > >
> > > It might be useful to give more of an "agenda" for where this
> > > thread is going
> > > (even without filling in the details), so people can 
> better place your
> > > discussion in context of the world of WebDAV problems.
> > >
> > > In general, however, I think that any solution to the 
> locking problems
> > > discussed recently has to fit in some general model like the
> > > one I anticipate
> > > that Yaron will propose.  However, I prefer a complete model
> > > to be laid out
> > > before me before I comment on particular precepts of the model.
> > >
> > > For example, following this level of abstraction, we should
> > > define a resource
> > > better.  I would say that a resource has a set of properties,
> > > which can be
> > > represented via an XML document.  Some of these properties are
> > > "live" properties, which are read-only and are set as a side
> > > effect of other
> > > methods ( for example a modification date).  Attempts to set
> > > the value of a
> > > live property directly via generic property mutator method(s)
> > > (e.g. PROPPATCH,
> > > PUT, etc.) should always be ignored.  A collection is a
> > > subclass of resource
> > > that has a live property containing a list of tuples
> > > including at least a name
> > > (and possibly with other values such as a resource ID
> > > associated with that
> > > name).  A BIND request is treated as a method that modifies
> > > the values of the
> > > collection's name tuple list.
> > >
> > > This should all be worked into the versioning model document
> > > (http://www.ics.uci.edu/pub/ietf/webdav/versioning/model990209
> > /), which while
> > defining some of the functional methods available on a 
> resource, doesn't
> > define
> > the properties on a resource as well as a number of the 
> other assumptions
> > along
> > the lines Yaron proposes.
> >
> > --Eric
> >
> >
> >
> > Yaron Goland wrote:
> >
> > > I believe that there are too many different unstated 
> assumptions held by
> > > members of this group for this group to be ready to deal 
> with specific
> > > locking proposals. The fact that Geoff, Eric and RFC 2518 
> can come out
> > with
> > > such different proposals helps to illustrate the issue. 
> Rather than
> > > attempting to achieve consensus in one fell swoop by 
> having everyone
> read
> > > and critique full proposals I would suggest that we start 
> from a simpler
> > > basis. Let us first see if we can establish agreement on 
> some very basic
> > > precepts. I will start with just one precept and see if we can get
> > agreement
> > > on just that.
> > >
> > > Precept #1 - HTTP clients send HTTP request messages to 
> resources that
> > > respond with HTTP response messages.
> > >
> > > Corollary #1.1 - All HTTP proposals can only be written 
> in terms of how
> a
> > > resource processes a HTTP request from a HTTP client and 
> generates a
> HTTP
> > > response as a result.
> > >
> > > Corollary #1.2 - HTTP requests do not necessarily have to 
> be handled by
> > HTTP
> > > resources. For example, it is possible to send a HTTP 
> request with a FTP
> > > request-URI. Some HTTP proxies are set up to act as 
> gateways that can
> > handle
> > > translating the HTTP request into a FTP request and then 
> translate the
> FTP
> > > response into a HTTP response. That is why precept #1 
> states "...to
> > > resources..." rather than specifying a HTTP resource.
> > >
> > > Corollary #1.3 - Since HTTP request messages can only be 
> handled by
> > > resources which respond with HTTP response messages then 
> even error
> > messages
> > > such as "Not Found" must have been generated by a resource.
> > >
> > > Let's see if we can just get agreement on this single 
> precept and its
> > > corollaries.
> > >
> > >         Merci,
> > >
> > >                         Yaron
> >
> 



From w3c-dist-auth-request@w3.org  Wed Jan  5 15:29:11 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15499
	for <webdav-archive@odin.ietf.org>; Wed, 5 Jan 2000 15:29:08 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA03648;
	Wed, 5 Jan 2000 15:14:36 -0500 (EST)
Resent-Date: Wed, 5 Jan 2000 15:14:36 -0500 (EST)
Resent-Message-Id: <200001052014.PAA03648@www19.w3.org>
Message-ID: <003f01bf57b9$a31609c0$79442382@us.oracle.com>
From: "Eric Sedlar" <esedlar@us.oracle.com>
To: "Slein, Judith A" <JSlein@crt.xerox.com>,
        "Jim Whitehead" <ejw@ics.uci.edu>, "WebDAV WG" <w3c-dist-auth@w3.org>
Cc: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
References: <8E3CFBC709A8D21191A400805F15E0DBD24555@crte147.wc.eso.mc.xerox.com>
Date: Wed, 5 Jan 2000 12:15:40 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: Re: WG Last Call: Bindings Protocol
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3797
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

Responses are inlined...

----- Original Message -----
From: Slein, Judith A <JSlein@crt.xerox.com>
To: 'Eric Sedlar' <esedlar@us.oracle.com>; Jim Whitehead <ejw@ics.uci.edu>;
WebDAV WG <w3c-dist-auth@w3.org>
Cc: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Sent: Wednesday, January 05, 2000 7:05 AM
Subject: RE: WG Last Call: Bindings Protocol
[snip]

>
> We do say in Section 11:
>
> "A PROPFIND requesting DAV:bindings MUST return only those bindings that
the
> client is authorized to see."
>
> So your suggestion is that in addition we say that if the client is not
> authorized to read the collection C in which a binding C:(S->R) appears,
the
> client is also not authorized to see that value of the DAV:bindings
property
> on the resource R.  Then we could get rid of the security concern
described
> in 16.4.  Is that right?
>

Right.

> > * some comment to the effect that if the URL is a versioned
> > resource, and
> > the currently selected revision is changed, the resourceid
> > will not change.
> > (I'm assuming that is what you want.)  So even though two
> > people might see
> > different data from a GET request from the same URL (because
> > they would get
> > a different revision selected), they would still have the
> > same resourceid.
> > Therefore, people should NOT use resourceid to invalidate
> > caches or any
> > other application that assumes a one to one correspondence between
> > resourceid and data.
>
> I think that your conclusions are all exactly correct, but I agree with
> Jason that it would be better to discuss ramifications for versioning in
the
> DeltaV spec.
>

I still think it would be useful to have a reference in the Binding spec,
even if
you move the discussion to the DeltaV spec.

--Eric




From w3c-dist-auth-request@w3.org  Wed Jan  5 19:02:41 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18508
	for <webdav-archive@odin.ietf.org>; Wed, 5 Jan 2000 19:02:41 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA09478;
	Wed, 5 Jan 2000 18:50:28 -0500 (EST)
Resent-Date: Wed, 5 Jan 2000 18:50:28 -0500 (EST)
Resent-Message-Id: <200001052350.SAA09478@www19.w3.org>
From: ccjason@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: Yaron Goland <yarong@Exchange.Microsoft.com>
cc: "'Eric Sedlar'" <esedlar@us.oracle.com>, w3c-dist-auth@w3.org,
        gclemm@atria.com
Message-ID: <8525685D.0082C9B5.00@D51MTA03.pok.ibm.com>
Date: Wed, 5 Jan 2000 18:49:10 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: RE: Translation in the Tower of Babble
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3798
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


> Well the bottom line is whether or not Geoff is interested in
> using such a
> model ;-)

A model would be good.  The document that Yaron originally came up
with was in conflict with the bindings document that was almost
finished and that everyone basically seemed comfortable with.

A revised and debugged model document would be a good thing.




From w3c-dist-auth-request@w3.org  Wed Jan  5 23:37:20 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22694
	for <webdav-archive@odin.ietf.org>; Wed, 5 Jan 2000 23:37:19 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id XAA15046;
	Wed, 5 Jan 2000 23:25:40 -0500 (EST)
Resent-Date: Wed, 5 Jan 2000 23:25:40 -0500 (EST)
Resent-Message-Id: <200001060425.XAA15046@www19.w3.org>
Date: Wed, 5 Jan 2000 23:25:29 -0500
Message-Id: <10001060425.AA18642@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: 
	<7DE119D3D0E15543874F7561EECBDBED0261A043@BEG.platinum.corp.microsoft.com>
	(message from Yaron Goland on Wed, 5 Jan 2000 09:53:01 -0800)
Subject: Re: Translation in the Tower of Babble
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3799
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


   From: Eric Sedlar [mailto:esedlar@us.oracle.com]
   Well the bottom line is whether or not Geoff is interested in 
   using such a model ;-)

   From: Yaron Goland <yarong@Exchange.Microsoft.com>
   A'int that the truth.
   Although I'm now in negotiations for a new position at MS that would allow
   me to return my attentions to WebDAV. So Geoff, don't get too comfy. =)

Well, I'm far more interested in getting it right than being
comfortable (:-), so I'm all for any change that increases Yaron's
participation.

Now, as for the object model.  I am an enthusiastic supporter of
the creation of an object model, and support most of Yaron's first
pass at such a beast (except for the semantics of DELETE).

In fact, his model clearly illustrates (to me, anyway :-) the
problems associated with trying to postulate a "null resource"
that handles methods applied to URL's that are not bound to a
"real" resource.

For example, consider the PUT method.  Yaron models this as:
   PUT(N,G):
   R = NR(N);
   If (R != NULL) {
      R.GET = G; // Future responses to GET will be G
      return;  }
   R' = R.CreateNewResource();
   NR(N) = R';
   R'.GET = G;
   return;

Note that this is not modeled as functions on resources,
but rather as a computation being performed by some other
entity (I'll call it a "server") that has the key piece of
data, "NR", which defines the current name-to-resource mapping
defined by that server.  But to be fair, we should examine
whether this function could be recast as a function on the
current resource identified by that URL.

I'm willing to let the "R = NR(N)" slide, and agree that could
be modeled as the implicit dereferencing of a name that is
automagically performed before any request is "handled".

The "If" statement could be just a placeholder for a type dispatch,
and then the R.GET=G is clearly a method on the resource, so we're
fine until then.

But then we get to the case where the method is being handled by
the "null resource" (R == NULL).  Having "CreateNewResource" as
a method on R is somewhat suspect, but I probably could live with that.
It's the next line, "NR(N) = R", that illustrates the problem.
Where did NR come from?  My answer would just be that the PUT method
is really being handled by the *server* (which has an "NR" feature),
and is only dispatched to a resource when there already is a resource
bound to the specified name.

The DELETE method is also clearly handled by the object that owns the
NR map (i.e. what I'm calling the server).  Here, I'll use my
definition of DELETE (but the same argument applies to Yaron's
definition):

   DELETE(N):
   If (NR(N) == NULL) {
      error("no resource at specified URL");
      return;
   }
   NR(N) = NULL;
   return;

Again, DELETE is a method that is handled by the server (i.e. the
object that owns the NR attribute), not by the resource currently
bound to the specified URL.

As Jason points out though, Yaron's initial model (which I think
is a good model for HTTP, and so I'll call it "the HTTP model")
does not adequately model the collection semantics of WebDAV.
To do so, we have to supplement the "NR" feature of a server with
the "bindings" feature of a collection.  Since this is probably
a separate thread, I'll address this in a subsequent message.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Thu Jan  6 00:05:12 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22941
	for <webdav-archive@odin.ietf.org>; Thu, 6 Jan 2000 00:05:11 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id XAA15881;
	Wed, 5 Jan 2000 23:53:57 -0500 (EST)
Resent-Date: Wed, 5 Jan 2000 23:53:57 -0500 (EST)
Resent-Message-Id: <200001060453.XAA15881@www19.w3.org>
Date: Wed, 5 Jan 2000 23:53:48 -0500
Message-Id: <10001060453.AA18659@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: 
	<7DE119D3D0E15543874F7561EECBDBED02619DF1@BEG.platinum.corp.microsoft.com>
	(message from Yaron Goland on Tue, 4 Jan 2000 12:17:37 -0800)
Subject: Re: Translation in the Tower of Babble
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3800
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

   From: Yaron Goland <yarong@Exchange.Microsoft.com>

   <yg/>
   Corollary #1.3 - Since HTTP request messages can only be handled by
   resources which respond with HTTP response messages then 
   even error messages
   such as "Not Found" must have been generated by a resource.

   <yl/>
   Well if the resource can't handle HTTP request, the daemon 
   that will ask
   this resource to generate an HTTP reply should return to the client an
   error stating that the resource doesn't support this 
   protocol, like a Not
   Found with a good explanation in the body.

   <yg/>
   Perhaps I'm misunderstanding but I assume you are just confirming that you
   agree with #1.3. The resource which sent the "HTTP not supported" response
   is an HTTP resource. What the resource is saying is "I don't want to talk to
   you in HTTP." However the only way he could say that is if he supported
   HTTP. He is still an HTTP compliant resource and therefore it was a resource
   (in the object model) that generated the response.

For me, saying that "every resource must be an HTTP resource so that
it at least can say that it doesn't understand HTTP requests" is
another result of trying to eliminate the concept of a "server" (what
Yves calls a "daemon") from the model.  I believe a simpler (and more
intuitive) model is to just say that there is a server, and if the
server sees that a resource at a URL is not an HTTP resource, it
returns an "HTTP not supported" response.  This is the same server
object that owns the NR (name-to-resource) mapping data.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Thu Jan  6 00:32:15 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23314
	for <webdav-archive@odin.ietf.org>; Thu, 6 Jan 2000 00:32:13 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id AAA16729;
	Thu, 6 Jan 2000 00:20:48 -0500 (EST)
Resent-Date: Thu, 6 Jan 2000 00:20:48 -0500 (EST)
Resent-Message-Id: <200001060520.AAA16729@www19.w3.org>
Date: Thu, 6 Jan 2000 00:20:42 -0500
From: gclemm@atria.com (Geoffrey M. Clemm)
Message-Id: <10001060520.AA18685@tantalum>
To: w3c-dist-auth@w3.org
Subject: Re: WG Last Call: Bindings Protocol
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3801
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

> From: "Eric Sedlar" <esedlar@us.oracle.com>
> 
> * some comment to the effect that if the URL is a versioned resource, and
> the currently selected revision is changed, the resourceid will not change.
> (I'm assuming that is what you want.)  So even though two people might see
> different data from a GET request from the same URL (because they would get
> a different revision selected), they would still have the same resourceid.
> Therefore, people should NOT use resourceid to invalidate caches or any
> other application that assumes a one to one correspondence between
> resourceid and data.

Yes, I believe that is what we want, and will insert some wording of
this kind in the versioning protocol (unless anyone objects).  I agree
with Judy that this is better placed in the versioning protocol
document, since resourceid's are likely to matter and be understood by
anyone reading the versioning document (we have various id's), while
the notion of a revision and a versioned resource is much less likely
to be matter or be understood by someone reading the bindings document.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Thu Jan  6 12:57:37 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18230
	for <webdav-archive@odin.ietf.org>; Thu, 6 Jan 2000 12:57:34 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA05791;
	Thu, 6 Jan 2000 12:44:45 -0500 (EST)
Resent-Date: Thu, 6 Jan 2000 12:44:45 -0500 (EST)
Resent-Message-Id: <200001061744.MAA05791@www19.w3.org>
From: ccjason@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <8525685E.0061610F.00@D51MTA03.pok.ibm.com>
Date: Thu, 6 Jan 2000 12:44:09 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: Translation in the Tower of Babble
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3802
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list



   For me, saying that "every resource must be an HTTP resource so that
   it at least can say that it doesn't understand HTTP requests" is
   another result of trying to eliminate the concept of a "server" (what
   Yves calls a "daemon") from the model.  I believe a simpler (and more
   intuitive) model is to just say that there is a server, and if the
   server sees that a resource at a URL is not an HTTP resource, it
   returns an "HTTP not supported" response.  This is the same server
   object that owns the NR (name-to-resource) mapping data.

Based on what I've seen so far, I tend to agree.  I can understand
NR() returning NULL (not that I think that NR() should be the basis
of the model), but I don't feel that we can say that it's a "NULL
resource".

I think we should also determine if we should be formally declare that
a collection is fundamentally different than a non-collection... or
just a matter of having or not having children.

I'd also like to say, that in some ways I like EricS's "model".  There are
a bunch of things that
I don't like or feel need to be cleaned up (if possible), but he has
presented a way to achieve the
LNR functionality without actually having null resources.  His model also
achieves URI protection
without talking about the namespace.  I've sent Eric a note with my
reservations.
Hopefully he'll be presenting an improved version of his model here.

Finally, it was LOCKING that kicked off this renewed discussion of our
model.  It's not clear to me
if the model should drive the locking proposal... or if the locking
proposal should drive it.  Or if
they really need to affect each other at all at this point.  I certainly
wouldn't want to delay progress
on locking if we don't need to.

Jason.




From w3c-dist-auth-request@w3.org  Thu Jan  6 18:23:13 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24890
	for <webdav-archive@odin.ietf.org>; Thu, 6 Jan 2000 18:23:11 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA16469;
	Thu, 6 Jan 2000 18:09:20 -0500 (EST)
Resent-Date: Thu, 6 Jan 2000 18:09:20 -0500 (EST)
Resent-Message-Id: <200001062309.SAA16469@www19.w3.org>
Date: Thu, 6 Jan 2000 18:08:50 -0500
Message-Id: <10001062308.AA19169@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
Subject: Anomaly in the DAV:prop element usage
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3803
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


In rfc2518, the example of propfind in 8.1.1 issues a PROPFIND
request with a DAV:prop element of the form:

     <D:prop xmlns:R="http://www.foo.bar/boxschema/">
          <R:bigbox/>
          <R:author/>
          <R:DingALing/>
          <R:Random/>
     </D:prop>

It is very likely that this violates at least some of the element
definitions for R:bigbox, R:author, R:DingALing, and R:Random.

I have gone to some trouble to avoid this kind of element definition
violation in the versioning spec, but since it didn't bother the
authors of 2518, should I not let it bother me?  As was pointed out
in an earlier thread, there are other reasons why WebDAV XML will be
rejected by validating parsers ...

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Thu Jan  6 18:32:34 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25125
	for <webdav-archive@odin.ietf.org>; Thu, 6 Jan 2000 18:32:33 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA17224;
	Thu, 6 Jan 2000 18:21:17 -0500 (EST)
Resent-Date: Thu, 6 Jan 2000 18:21:17 -0500 (EST)
Resent-Message-Id: <200001062321.SAA17224@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619DFD@BEG.platinum.corp.microsoft.com>
From: =?utf-8?B?WWFyb24gR29sYW5k?= <yarong@Exchange.Microsoft.com>
To: =?utf-8?B?R2VvZmZyZXkgTS4gQ2xlbW0=?= <geoffrey.clemm@rational.com>,
        w3c-dist-auth@w3.org
Date: Thu, 6 Jan 2000 15:20:12 -0800 
X-MS-TNEF-Correlator: <7DE119D3D0E15543874F7561EECBDBED02619DFD@BEG.platinum.corp.microsoft.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01BF589C.B513D402"
Subject: =?utf-8?B?UkU6IEFub21hbHkgaW4gdGhlIERBVjpwcm9wIGVsZW1lbnQgdXNh?= 	=?utf-8?B?Z2U=?=
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3804
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BF589C.B513D402
Content-Type: text/plain;
	charset="utf-8"

I wouldn't worry about this issue at all. Any element used inside of a prop
element must be a WebDAV property and hence must be defined using WebDAV
rules.
 
                  Yaron

-----Original Message-----  
From: Geoffrey M. Clemm 
Sent: 1/6/2000 3:08 PM  
To: w3c-dist-auth@w3.org 
Cc: 
Subject: Anomaly  in the DAV:prop element usage




In rfc2518, the example of propfind in 8.1.1 issues a  PROPFIND 
request with a DAV:prop element of the  form: 

     <D:prop xmlns:R=" http://www.foo.bar/boxschema/
<http://www.foo.bar/boxschema/> "> 
          <R:bigbox/> 
          <R:author/> 
          <R:DingALing/> 
          <R:Random/> 
     </D:prop> 

It is very likely that this violates at least some of the  element 
definitions for R:bigbox, R:author,  R:DingALing, and R:Random. 

I have gone to some trouble to avoid this kind of element  definition 
violation in the versioning spec, but since  it didn't bother the 
authors of 2518, should I not let  it bother me?  As was pointed out 
in an earlier  thread, there are other reasons why WebDAV XML will be 
rejected by validating parsers ... 

Cheers, 
Geoff 


------_=_NextPart_000_01BF589C.B513D402
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IggXAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEFgAMADgAAANAHAQAGAA8A
FAAMAAQAEQEBCYABACEAAABCQzY1NTFDOTlBQzhBQjRGOEE2NTM0NTg0NzJCMUEyMwAyBwEggAMA
DgAAANAHAQAGAA8AFQAGAAQADAEBDYAEAAIAAAACAAIAAQOQBgA8EQAALgAAAEAAOQDQmACVnFi/
AR8AMUABAAAADgAAAFkAQQBSAE8ATgBHAAAAAAADABpAAAAAAB8AMEABAAAADgAAAFkAQQBSAE8A
TgBHAAAAAAADABlAAAAAAB8ASQABAAAATAAAAEEAbgBvAG0AYQBsAHkAIABpAG4AIAB0AGgAZQAg
AEQAQQBWADoAcAByAG8AcAAgAGUAbABlAG0AZQBuAHQAIAB1AHMAYQBnAGUAAABAAE4AAO0K/ppY
vwEfAFoAAQAAACQAAABHAGUAbwBmAGYAcgBlAHkAIABNAC4AIABDAGwAZQBtAG0AAAADAB1AAAAA
AB8AcAABAAAATAAAAEEAbgBvAG0AYQBsAHkAIABpAG4AIAB0AGgAZQAgAEQAQQBWADoAcAByAG8A
cAAgAGUAbABlAG0AZQBuAHQAIAB1AHMAYQBnAGUAAAACAXEAAQAAABsAAAABv1ibKEULizf2xIkR
07TtAFCLLNjlAABQZ0YAHwB0AAEAAAAqAAAAdwAzAGMALQBkAGkAcwB0AC0AYQB1AHQAaABAAHcA
MwAuAG8AcgBnAAAAAAACAQkQAQAAAMYKAADCCgAACS0AAExaRnWhcWNbAwAKAHJjcGcxMjWCMgND
aHRtbDEDMD8BAwH3CoACpAPjAgBjaMEKwHNldDAgBxMCgP8QAwBQBFYIVQeyEdUOUQMB3RDXMgYA
BsMR1TMERhDZbxLrEeMI7wn3OxjPDjA1OxHSDGBjAFALCQFkMzaTEWALpTQgEAIqXA6yvQGQZxTw
CqMR4x3oNBTwADwhRE9DVFlQAEUgSFRNTCBQAFVCTElDICItIC8vVzNDIYBEVCJEIJQzLjIhgEVO
nCI+Hu0ejyPBMTgf8G8goiMPJB8mkDMdgCVwRXxBRCXNDvEm7ylvJPQ2QQ7wPE1FVEEHsEExLGA9
IkcJ8ASQYXRFBbAiEtBPTlQi0FQTLPAF4UV4EPFuZ2U9BlJ2EzEvQQCQAiAgNoAuMC40MTcxMBAn
Iv4qzyUDNzcf8FRJuFRMRSXOMEARcG4DcYhseSALgCB0aC7wIERBVjpwA2BwIBhlbGUHgAIwIHVz
1SaQZSRuNR/wLzNPMX+/JkU0kTgwKE8mnzwENRFg4DxCT0RZO30c8TyfiGc5Nh/wRElWO3B7O+MA
ISAAAEEVEWA7uTZGNED/QgJJIHcIYGyYZG4nBUBEgHJyNSD/AaAIYAVANXAEADUwBBAKUOdFYAVA
B0BsLjSxNSA2SE8JgDUxAJABACBvQXBh/iA18zocPzVDJwMwQbc2RhZtNsAFQGJGYSBXZa5iNbFI
wwSQdEVRbkfw+TWAbmMu8Ew2AQELgEfhezbAC4BnTMZJL0o/QdVy+0SgB5AuO7kBwEMXCqJDF/sK
cSR8MCgRIeBAy1TYHZy/Py9AP0FPQl9bTjubOB2AYCZuYnNwAoBdJ1z8J2EBQFu/U79Uz1XfVu//
Xg9ZD1ofXU9cP2k/Xl9fb/9ge2x/bY9un2+vcL9xz3Lf/3PvdP92D3cfeC95P3pPe1//fG99f36P
f5+Ar4G/gs+D3/+E74X/hw+IH4kvij+LT4xf/41vjn+Pj5Cfka+Sv5PPlN9/le+W/5gPmR9qA1A/
Z2NZ/wrAAiBhT2JfY29kf2WPZp8LZ6894EwgMEtRVU/jLfBO4GlyPTwgBcBMUAZ5NlAuMUFSR0lO
EC1SSUcgoDogMPxweCLxm+gKsRACp3EKsfOqYhDwXHEDIaOfpK8fOY+dMaVfaKNGoWlnbqdg/wFx
pyZo+6tCqn9pz2rfszetshBpHNIkfDQlUUYt0emnoGl6p/AyaPsL4ksJ6i254k8FEGcLgAdABdD/
B5A20rnjnV9RT6ufmwWufvYxLBA90VKpSrAALTAKga+9n5r2PeBo+2JLCUYDYbY6rqwf4S/DaqN5
IC0Qq0iAA1BlNSBNRuBDNlH+bbZNwD/BT8Jfw2+zNwZgDwIwxU/GX5zXMS82LycB0NIAInA6MCVQ
UE3/u4+8n8ufvr/Jj8qf1O/MvznEDlRvzw/QH5zXdzNMYy2nMExQLWFFoGj6QN8ALgWwT7DWj9ef
2K/n2b/az7NkQ2PcX91vnN8f4N/h7+L/5A/N3nViav8FkM7/5y/oODTG0s/T3+tv/9X3NU82Wujf
6e/q//fv+P/r+g8k1jVokS+3cvA/YP//n8+g36Hv/1/6nx/h+9yqA78FD6yPrZ87m7RwH/BQBu+/
tUm0v7XPtt+377j9SfXwLnIWgBsAJUAs9gNleHxhbRwQSGNI0k8RR/Ig/DguMHA68EYjRgBIsPIv
B/M/CC/V91BST1BG/ahgRP2//s/oH/sP/B8Yn28QLxE/uP3IQHEWMUTxaf/2EEyh9l9IgfYSFp8X
ryBP/dX3Zi2AxT0br8b+AW8Cdf8MbyjPAPTv8QwxCJ8Jrwq//wvPDm8PfyGfIq8wL5r/nA//Ot87
7zz/Pg8/H0AvQT9CT68dT0RVM+BFCTz/6ET2hMJ4KDBuczpSqADr39ZBMuRSEGjIQGaoACgQQHRw
Oi8vd0ygLhEqcG8uYi/QL2JvTHhzqxAl4GEvqTp71zpgFSAlwGQzcmZPIPXgASSQe0hZUEVSTJmo
YEsgTC9NPH19OgEJTyByczPgXGNmMfxcdataUL9NSixfDcoE/03vakEe8EovJmdHyj7/WB8rPyxP
Rl+eJylP1m8er/8fvzefOK85v2S/RH9Fj2if/2mvar9rz2zfbe9u/3APcR//ci9zP3RPdV92b3d/
eI95n/96r3u/fM9930XvX99g74PPY0evAAZSOmK6UE1hL/+FD1svfy9dT15fHZ9i/2QP/2UfZiNL
ZWZ/Z4+IL4Cvft//lO+V/5cPmB+ZL5o/m0+cX/+db55/n4+gn6Gvor+jz6Tf/6Xvpv+oD6kfqi+N
L4MvhD//hU+GX4dj35LgEIgfiS+rH/+LT4xfjW+Of4+PkJ+Rr5K//5PPq9+s78AfwS/CP8NPxF//
xW/Gf8ePyJ/Jr8q/y8/M3//N787/0A/RH9Iv0z/UT9VfP9Zvrl+vb7B/sY+ynzpE8RVwZ0FM38G0
H7Uv1x//t0+4X7lvun+7j7yfva++v/+/z9ff2O/sT+1f7m/vf/CP//Gf8q/zv/TP9d/27/f/+Q//
+h/7L/w//U/+X/9vAH8Bj38Cn9pf22/cf92P3p9J8GH5FUBvbeBP4V8DT+N/5I//5Z/mr+e/6M9m
H+tfFG8Ef/8FjxhPGV8abxt/HI8dnx6vvx+/EY8HjwifCa8Kvy9JNP8mbw1vII8PjxCfS7Antkti
31gIFAgkwxQPM6Y3WZI1occRy1dRJO9nMjQjsSZNPjZLETMBFrlW6BPAMzYPFK8VvxbP3xZJdCBp
gHMgdmVyeSATwO5rTxA80LPQYTxQs9A8cmhpb2w9gGU8gD2BbBxlYU/QOhAMIGUgb/9IYLPQP1Aj
7zRCJ7cXryWb408QTcBlbnQr/y0PEQ8/Eh8TL0HvOT86TxdtZGWxTvBuaXQ+EE/AIFUQ++pgh5Ys
s4dPAD/vQP9Jj98l19+ZTwAL8Qu3LkQfRS//Lh8vLzA/Ub8yXzNvNH81j782nzevSf9LD0wfO+Ug
PXCZPKAgZ04AP1B0bz8UcnQpMHViPsBmImWgb/ZpVHA9s2tJAFRwP3FDpf9Pv1DPWp8lyE2IVS9W
P0Y//0dPSF9rH2JvY38XbT4ETfH/PGB3YD+iPKF0wE4A38F0sGhwZWNPAGJPUHSxbv5jP89qD3LP
JblN0E1wZ5D8bic8UIfgP6HqYD+hbX//bo9vn3Cvcb97r3PfdO8XbYeztDyAP3EyNTE4TwCyc7Pg
dWxUcGVwbn4Qfz6xaP96n4P/fLx+BT9AP1cpbyIPIxtBPIB3PuAg9nBngEPwZWhBT1B+r3+//4DP
gd+C74w/hQ+GHxdtd4H/C/BogOpQl7B+QYo/i0+YT+sl17PQcj7QZE8AfiI/UD/qUD9RfiOhAT8g
ThF3aAE80FdlYkRBViCIWE1MkdBpbGx48P9+n5PflO+V/5cPnx/pP+pPt5rf3zShAGp4wJJiYjzQ
dHZhqSBkdyF4cV1hc/l4ASAusBCkT6VfV09YX/9Zb6mPW49cn12vXr9fz2Dfb6ovmc+sv980Qz+w
eAEs/7BPsV+mb6d/qI+1r72Pvp/pF21HZT9wZsEPwh/DLz+df7M/tE+1X7ZvuMwxMAG68S9CTE9D
S1HwVU9URcw/0b+4T9cPjc3nNasR1HBPRFm3bZfS4NjPuYE3y8FIVKOgBcUgfd2AAAAfAEcQAQAA
AB4AAABtAGUAcwBzAGEAZwBlAC8AcgBmAGMAOAAyADIAAAAAAAMAJgAAAAAAAwA2AAAAAAADAN4/
6f0AAAMA8T8JBAAAAwD9P+QEAAALAPIQAQAAAAsA9BAAAAAACwD1EAAAAAALAPYQAAAAAB8A8xAB
AAAAZAAAAFIARQAlADMAQQAgAEEAbgBvAG0AYQBsAHkAIABpAG4AIAB0AGgAZQAgAEQAQQBWACUA
MwBBAHAAcgBvAHAAIABlAGwAZQBtAGUAbgB0ACAAdQBzAGEAZwBlAC4ARQBNAEwAAAACAUcAAQAA
AC0AAABjPXVzO2E9IDtwPUFQUFMtV0dBO2w9QkVHLTAwMDEwNjIzMjAxMlotMjAwNgAAAAACAfk/
AQAAAB4AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAALgAAAB8A+D8BAAAAKgAAAFMAeQBz
AHQAZQBtACAAQQBkAG0AaQBuAGkAcwB0AHIAYQB0AG8AcgAAAAAAHwA4QAEAAAAEAAAALgAAAAIB
+z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAuAAAAHwD6PwEAAAAqAAAAUwB5
AHMAdABlAG0AIABBAGQAbQBpAG4AaQBzAHQAcgBhAHQAbwByAAAAAAAfADlAAQAAAA4AAABZAEEA
UgBPAE4ARwAAAAAAQAAHML6IGJWcWL8BQAAIMALUE7WcWL8BHwAaAAEAAAASAAAASQBQAE0ALgBO
AE8AVABFAAAAAAAfADcAAQAAAFQAAABSAEUAOgAgAEEAbgBvAG0AYQBsAHkAIABpAG4AIAB0AGgA
ZQAgAEQAQQBWADoAcAByAG8AcAAgAGUAbABlAG0AZQBuAHQAIAB1AHMAYQBnAGUAAAAfAD0AAQAA
AAoAAABSAEUAOgAgAAAAAAAfAB0OAQAAAEwAAABBAG4AbwBtAGEAbAB5ACAAaQBuACAAdABoAGUA
IABEAEEAVgA6AHAAcgBvAHAAIABlAGwAZQBtAGUAbgB0ACAAdQBzAGEAZwBlAAAAHwA1EAEAAACW
AAAAPAA3AEQARQAxADEAOQBEADMARAAwAEUAMQA1ADUANAAzADgANwA0AEYANwA1ADYAMQBFAEUA
QwBCAEQAQgBFAEQAMAAyADYAMQA5AEQARgBEAEAAQgBFAEcALgBwAGwAYQB0AGkAbgB1AG0ALgBj
AG8AcgBwAC4AbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQA+AAAAAAALACkAAAAAAAsAIwAAAAAA
AwAGEC30Lp4DAAcQQAMAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABJV09VTEROVFdPUlJZ
QUJPVVRUSElTSVNTVUVBVEFMTEFOWUVMRU1FTlRVU0VESU5TSURFT0ZBUFJPUEVMRU1FTlRNVVNU
QkVBV0VCREFWUFJPUEVSVFlBTkRIRU5DRU1VU1RCAAAAAAIBfwABAAAASwAAADw3REUxMTlEM0Qw
RTE1NTQzODc0Rjc1NjFFRUNCREJFRDAyNjE5REZEQEJFRy5wbGF0aW51bS5jb3JwLm1pY3Jvc29m
dC5jb20+AAD2yA==

------_=_NextPart_000_01BF589C.B513D402--



From w3c-dist-auth-request@w3.org  Thu Jan  6 19:12:04 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25634
	for <webdav-archive@odin.ietf.org>; Thu, 6 Jan 2000 19:12:03 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id TAA18317;
	Thu, 6 Jan 2000 19:00:48 -0500 (EST)
Resent-Date: Thu, 6 Jan 2000 19:00:48 -0500 (EST)
Resent-Message-Id: <200001070000.TAA18317@www19.w3.org>
Message-ID: <028a01bf58a1$a4f98c60$0201a8c0@everest.com>
From: "Kaelin Colclasure" <kaelin@everest.com>
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>, <w3c-dist-auth@w3.org>
References: <10001062308.AA19169@tantalum>
Date: Thu, 6 Jan 2000 15:56:26 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: Re: Anomaly in the DAV:prop element usage
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3805
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

----- Original Message ----- 
From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
To: <w3c-dist-auth@w3.org>
Sent: Thursday, January 06, 2000 3:08 PM
Subject: Anomaly in the DAV:prop element usage


> In rfc2518, the example of propfind in 8.1.1 issues a PROPFIND
> request with a DAV:prop element of the form:
> 
>      <D:prop xmlns:R="http://www.foo.bar/boxschema/">
>           <R:bigbox/>
>           <R:author/>
>           <R:DingALing/>
>           <R:Random/>
>      </D:prop>
> 
> It is very likely that this violates at least some of the element
> definitions for R:bigbox, R:author, R:DingALing, and R:Random.
> 
> I have gone to some trouble to avoid this kind of element definition
> violation in the versioning spec, but since it didn't bother the
> authors of 2518, should I not let it bother me?  As was pointed out
> in an earlier thread, there are other reasons why WebDAV XML will be
> rejected by validating parsers ...

The use of a validating parser makes little sense in the context of
WebDAV properties -- because it is intended to expose a storage mechnism
for arbitrary element definitions (in the form of property values),
which themselves may or may not have a defined DTD or schema somewhere.

Is the versioning specification defining a similar mechanism whereby
arbitrarily defined elements would need to be incorporated? If not,
then indeed you should be sensitive to the requirements of validation.
But if so, the same argument stated above for property values applies.

-- Kaelin




From w3c-dist-auth-request@w3.org  Thu Jan  6 20:07:44 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26240
	for <webdav-archive@odin.ietf.org>; Thu, 6 Jan 2000 20:07:44 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id TAA19029;
	Thu, 6 Jan 2000 19:56:17 -0500 (EST)
Resent-Date: Thu, 6 Jan 2000 19:56:17 -0500 (EST)
Resent-Message-Id: <200001070056.TAA19029@www19.w3.org>
Message-ID: <00a801bf58a9$f068caa0$9a114498@us.oracle.com>
From: "Eric Sedlar" <esedlar@us.oracle.com>
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>, <w3c-dist-auth@w3.org>
Cc: <anovosel@us.oracle.com>, <dbeech@us.oracle.com>,
        "Vishu Krishnamurthy" <vkrishna@us.oracle.com>, <jjc@jclark.com>
References: <10001062308.AA19169@tantalum>
Date: Thu, 6 Jan 2000 16:55:49 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Subject: Re: Anomaly in the DAV:prop element usage
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3806
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

This is an interesting issue--how do specify some set of XML elements that
you want out of a document not available to you.  This is basically the XML
equivalent of a SELECT list in SQL.

I raised this issue in the database context with the W3C people a few months
ago, to raise the issue of a simplified form of XPath for this purpose.  I
proposed basically using a list of XPath identifiers, omitting elements in
the predicate that reference the value of any node.

I'm copying this to some relevant XML & XPath people to highlight WebDAV
PROPFIND requests as another application for this usage in addition to
database data retrieval.  It's kind of disturbing to me to see invalid XML
used for this--I'd prefer a comma separated list of XPath specifications,
omitting predicates, like:

<D:prop xmlns:R="http://www.foo.bar/boxschema/">
 R:bigbox, R:author, D:supportedlock/lockentry/lockscope
</D:prop>

I think this will avoid confusion, since a list of XML element names
shouldn't appear as empty elements.

--Eric

----- Original Message -----
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: <w3c-dist-auth@w3.org>
Sent: Thursday, January 06, 2000 3:08 PM
Subject: Anomaly in the DAV:prop element usage


>
> In rfc2518, the example of propfind in 8.1.1 issues a PROPFIND
> request with a DAV:prop element of the form:
>
>      <D:prop xmlns:R="http://www.foo.bar/boxschema/">
>           <R:bigbox/>
>           <R:author/>
>           <R:DingALing/>
>           <R:Random/>
>      </D:prop>
>
> It is very likely that this violates at least some of the element
> definitions for R:bigbox, R:author, R:DingALing, and R:Random.
>
> I have gone to some trouble to avoid this kind of element definition
> violation in the versioning spec, but since it didn't bother the
> authors of 2518, should I not let it bother me?  As was pointed out
> in an earlier thread, there are other reasons why WebDAV XML will be
> rejected by validating parsers ...
>
> Cheers,
> Geoff
>
>



From w3c-dist-auth-request@w3.org  Thu Jan  6 22:54:11 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29269
	for <webdav-archive@odin.ietf.org>; Thu, 6 Jan 2000 22:54:10 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id WAA21756;
	Thu, 6 Jan 2000 22:42:17 -0500 (EST)
Resent-Date: Thu, 6 Jan 2000 22:42:17 -0500 (EST)
Resent-Message-Id: <200001070342.WAA21756@www19.w3.org>
Date: Thu, 6 Jan 2000 22:42:08 -0500
Message-Id: <10001070342.AA19317@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: esedlar@us.oracle.com
Cc: geoffrey.clemm@rational.com, w3c-dist-auth@w3.org, anovosel@us.oracle.com,
        dbeech@us.oracle.com, vkrishna@us.oracle.com, jjc@jclark.com
In-Reply-To: <00a801bf58a9$f068caa0$9a114498@us.oracle.com>
	(esedlar@us.oracle.com)
Subject: Re: Anomaly in the DAV:prop element usage
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3807
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


   From: "Eric Sedlar" <esedlar@us.oracle.com>

   This is an interesting issue--how do specify some set of XML elements that
   you want out of a document not available to you.  This is basically the XML
   equivalent of a SELECT list in SQL.

Yes!  (It is comforting to know that at least one other person out
there worries about this kind of thing :-).  In the versioning
context, it comes up in the REPORT method.  An important report is a
DAV:available-reports report (analagous to an OPTIONS call, but
returning the reports available, rather than the methods applicable).

   I raised this issue in the database context with the W3C people a few months
   ago, to raise the issue of a simplified form of XPath for this purpose.  I
   proposed basically using a list of XPath identifiers, omitting elements in
   the predicate that reference the value of any node.

   I'm copying this to some relevant XML & XPath people to highlight WebDAV
   PROPFIND requests as another application for this usage in addition to
   database data retrieval.  It's kind of disturbing to me to see invalid XML
   used for this--I'd prefer a comma separated list of XPath specifications,
   omitting predicates, like:

   <D:prop xmlns:R="http://www.foo.bar/boxschema/">
    R:bigbox, R:author, D:supportedlock/lockentry/lockscope
   </D:prop>

   I think this will avoid confusion, since a list of XML element names
   shouldn't appear as empty elements.

My concern with this approach is that the parser won't know that this
identifier is an element name, so the application would have to do the
processing itself (e.g. keeping track of the namespaces defined in that
context, and replacing the namespace prefix with the appropriate URL).
This is feasible, but does require the application to internally contain
parsing knowledge.

The alternative, using empty elements that violate the element definition
avoids this problem, at the cost of being invalid XML.

For the DAV:available-report REPORT, I have avoided the problem by
defining DAV:xxx-report to be the element returned in the
DAV:available-reports response, DAV:xxx-report-request be the element
in the request body for that kind of report, and
DAV:xxx-report-response be the element in the response body for that
kind of report.

But for the (recently added) DAV:property-report REPORT (which does
a PROPFIND on the resources referenced by properties that are a
list of href's), I can't avoid the "XML-select" problem.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Thu Jan  6 23:05:09 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29354
	for <webdav-archive@odin.ietf.org>; Thu, 6 Jan 2000 23:05:08 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id WAA22117;
	Thu, 6 Jan 2000 22:53:51 -0500 (EST)
Resent-Date: Thu, 6 Jan 2000 22:53:51 -0500 (EST)
Resent-Message-Id: <200001070353.WAA22117@www19.w3.org>
Date: Thu, 6 Jan 2000 22:53:44 -0500
Message-Id: <10001070353.AA19329@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <028a01bf58a1$a4f98c60$0201a8c0@everest.com> (kaelin@everest.com)
Subject: Re: Anomaly in the DAV:prop element usage
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3808
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


   From: "Kaelin Colclasure" <kaelin@everest.com>

   The use of a validating parser makes little sense in the context of
   WebDAV properties -- because it is intended to expose a storage mechnism
   for arbitrary element definitions (in the form of property values),
   which themselves may or may not have a defined DTD or schema somewhere.

Yes, that makes sense (although you do have to at least specify the
namespace of those elements, even if you don't have the DTD's).  But
in those cases where you do have the DTD's available (such as for the
DAV:xxx properties), it does provide some cognitive dissonance to
see an element like <DAV:creationdate/> in a PROPFIND request,
when the DTD for creationdate is:
   <!ELEMENT creationdate (#PCDATA) >


Cheers,
Geoff





From w3c-dist-auth-request@w3.org  Fri Jan  7 04:35:26 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13431
	for <webdav-archive@odin.ietf.org>; Fri, 7 Jan 2000 04:35:25 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id EAA27523;
	Fri, 7 Jan 2000 04:24:27 -0500 (EST)
Resent-Date: Fri, 7 Jan 2000 04:24:27 -0500 (EST)
Resent-Message-Id: <200001070924.EAA27523@www19.w3.org>
Message-Id: <4.1.20000107085600.00b6ced0@pop.xs4all.nl>
X-Sender: contact@pop.lanminds.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 07 Jan 2000 09:11:10 +0100
To: w3c-dist-auth@w3.org
From: Jim Davis <jrd3@alum.mit.edu>
In-Reply-To: <10001070353.AA19329@tantalum>
References: <028a01bf58a1$a4f98c60$0201a8c0@everest.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Re: Anomaly in the DAV:prop element usage
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3809
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

At 10:53 PM 1/6/00 -0500, Geoffrey M. Clemm wrote:
>
>   From: "Kaelin Colclasure" <kaelin@everest.com>
>
>   The use of a validating parser makes little sense in the context of
>   WebDAV properties -- because it is intended to expose a storage mechnism
>   for arbitrary element definitions (in the form of property values),
>   which themselves may or may not have a defined DTD or schema somewhere.
>
>Yes, that makes sense (although you do have to at least specify the
>namespace of those elements, even if you don't have the DTD's).  But
>in those cases where you do have the DTD's available (such as for the
>DAV:xxx properties), it does provide some cognitive dissonance to
>see an element like <DAV:creationdate/> in a PROPFIND request,

I agree that it is dissonant.   But there may be no better choice.

Let me make a suggestion - let he who thinks WebDAv should validate create
a DTD that will work.  The constraint is that it has to work even if there
is no DTD for some properties, and whatever mechanism you use should also
not have the bad network effect of needing to fetch the DTD with each
attempt to validate.  otherwise performance would be bad.  I am no XML
expert, so I can't tell whether this is easy or even possible.

I would certainly be willing to see changes to the DTD that would *allow*
webDAV XMl to be validating, if I didn't have to give up on expressivity
(ability to use properties without a DTD)

All things being equal, this would be better for DASL as well.  As one of
the authors I can say that I did spend some time trying to write a DTD for
DASL, mostly because I wanted to be able to check for dumb mistakes that *I
made.

Note also that RFC 2518 says that WebDAV's xml is not valid.  (but only in
passing in 17.7)  i think, given the amount of discussion that this has
brought up over history, it needs a passage in the WebDAV book of Why, if
not in the next Specification.



From w3c-dist-auth-request@w3.org  Fri Jan  7 15:50:08 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27026
	for <webdav-archive@odin.ietf.org>; Fri, 7 Jan 2000 15:49:57 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA19724;
	Fri, 7 Jan 2000 15:36:22 -0500 (EST)
Resent-Date: Fri, 7 Jan 2000 15:36:22 -0500 (EST)
Resent-Message-Id: <200001072036.PAA19724@www19.w3.org>
From: ccjason@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <8525685F.00711A4B.00@D51MTA03.pok.ibm.com>
Date: Fri, 7 Jan 2000 15:35:58 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: Locking URIs rather than Resources
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3810
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


Just forwarding Eric's response below to the dist-authoring list since I
suspect it's more relevant there and that's where the discussion was
previously...


---------------------- Forwarded by Jason Crawford/Watson/IBM on 01/07/2000
03:34 PM ---------------------------

"Eric Sedlar" <esedlar@us.oracle.com> on 01/07/2000 02:36:33 PM

To:   Jason Crawford/Watson/IBM@IBMUS
cc:   <ietf-dav-versioning@w3.org>
Subject:  Re: Locking URIs rather than Resources



More discussion of the model I propose for LOCKs.

----- Original Message -----
From: <ccjason@us.ibm.com>
To: "Eric Sedlar" <esedlar@us.oracle.com>
Sent: Tuesday, January 04, 2000 4:52 PM
Subject: Re: Locking URIs rather than Resources


>
> Offline note.  Feel free to reply on the list if you like...
>
>    1) are the list of names in a collection logically part of the
> collection,
>    or do they live in some separate space outside the domain of
resources?
>    To me the answer must be that they are a part of the collection.
>
> I think all recent proposals agree that the binding is part of the state
of
> the collection.  You shouldn't get much debate about that.
>
>   type of object that can be identified within this model is a resource.
> You
>   are going to have (in a real system) access control on resources, and
not
> a
>   separate access control model for names.  There are too many concepts
in
> the
>   world of the web to introduce another type of object other than a
> resource.
>   Every filesystem in the world stores the list of filenames as a part of
> the
>   directory, and locks & access control on the directory affects all
names
>   within.  Let's stick with current usage unless we have compelling
reasons
> to
>   deviate.
>
>
>    2) what kind of locks are there?
>
>    IMHO, there must be two kinds of locks--name locks and resource locks.
> The
>    problem with just locking a collection resource is that it is to
>    coarse-grained--there are lots of applications that will want to just
> lock a
>    single name in a collection, and resource locking every collection in
a
> path
>    will reduce concurrency too much.  I think of this like table level
and
> row
>    level locks in a database--a lock on the collection is like a table
> level
>    lock, locking all names (rows) in that collection.  Another way to
think
> of
>    a name is like a fragment within the collection document.
>
> I agree with your taxonomy of requirements, but I don't agree that a name
> lock has
> to be a formal concept.  We have talked about URI protection in previous
> locking
> models. UP also probably filfills the same need and isn't a new kind of
> lock.
> It's just a behavior.
>
>
>
>
>    Now that we understand that, what do we do about RFC 2518 LOCK's?
(I'm
>    using a capitalized LOCK to distinguish the RFC 2518 protocol request
> from
>    name locks and resource locks).
>
>    The requirements are:
>
>    * a LOCK on must prevent the resource from being moved, for
> compatability
>    with existing applications.
> Yup.  We've seemed to settle on this.
>
>    * a LOCK on must prevent any changes to that resource (updates,
deletes,
>    etc.) if it exists
> Yup, but FWIW, most of us consider DELETE to fall in the category of
MOVE.
> It's not a modification of the resource itself.
>
>    * a LOCK token must be associated with the locked resource and URL
> Umm?  This doesn't sound like a requirement.  At least not a fundamental
> one.  Feel free to explain what you mean if you think this is an
important
> point.
>

I had this as a requirement for compatability with RFC 2518.  Are you
suggesting that lock tokens are superfluous and should be removed?

>
>    So, it seems like that the following solution is the right
abstraction:
>
>    1) add the notion of name and resource locks.  A name lock applies to
a
>    single level name within a collection.  A resource lock applies to the
> data
>    identified by a particular URL.  If that URL identifies a collection,
a
>    resource lock locks ALL of the names in that collection, and is
blocked
> by
>    any name lock within, and vice versa.
>
> Understood.  I'm uncomfortable speaking of name locks as a formal entity,
> but I find them as an acceptable way of explaining URI protection.  If we
> do speak of name locks, I suspect we're also going to have to mention
> things
> like them being implicitly shared rather than exclusive.

It wasn't clear to me in general if shared locks were the default rather
than exclusive, but it seems natural that this should be the case for both
name and resource locks.  As far as treating name locks as a formal entity,
that is a better way of describing what you are doing when you want a lock
on a URL not associated with a resource--you're locking only that PART of
the collection resource corresponding to that name in its set of bindings,
you aren't locking some resource that that name will be associated with
later.

I think that people who have worked with locking before understand the
difference between locking an aggregate object and an individual item in
that aggregate, as there are many examples of that in software today
(locking a file vs. locking a byte range in that file, table locks vs. row
locks in a SQL database, etc.).  I don't think people are comfortable with
the idea of treating namespaces as lockable entities separate from the
entities the names refer to, since that isn't generally done.  Once you
agree that the set of bindings are part of the state of a collection, you
are treating the collection resource as an aggregate that can be locked, as
well as one or more bindings it contains.  The model I propose is simpler,
in that only one kind of object WebDAV requests can refer to--the resource,
without treating URLs as something separate.

>
>    2) we introduce the notion of a lock "set".  A lock set is a group of
> any
>    number of name and resource locks.
>
> I agree with the semantics, but I'm uncomfortable with creating a new
> concept
> called a "lock set".  This also rings of "implementation".
> Hopefully this can be avoided.  Anyway...

The lock set is just a group of locks associated with a single lock token.
Given that the Depth: infinity header effectively gets many locks (rather
than one big lock) and associates them with a single token, you were
already
doing this before, just without a name.  It just seemed to me to be easier
to understand if you have a term for describing what a lock token
identifies.  This is just a terminology issue.

>
>    Each lock set as a single associated
>    lock token.  An RFC 2518 LOCK request applied to an existing
> non-collection
>    resource will grant name locks to each name in the path from the root
   > down
>    to the bottom, and a resource lock on the identified resource, create
a
> lock
>    set from this group, and grant an identifying LOCK token.
>
> Sounds fine.  We'll have to go over details later.  So far this is
exactly
> like
> some of our other models... just explained differently.  Perhaps folks
will
> find
> this phrasing easier to approve.  :-)
>
>
>    An RFC 2518 LOCK
>    request applied to a collection will work in the same way, except that
> if
>    the depth header is specified, name and resource locks will be given
>    recursively for each contained resource.
>
> Hmmm.  Or perhaps just resource locks.  No, that won't work either.
> Okay...
> You're going to have to explain some of the
> complications of this.  Like, are all of these resources still locked if
> you
> remove the binding that put them under the influence of the original lock
> request?

No.  The LOCK protocol request is a shorthand way of requesting a set of
names and resources to lock.  Deleting one of the names or resources you
have locked removes the locks, since you have nothing there remaining to
lock.  The validity of the relationships between the set of names that are
locked and the resources they apply to is not maintained.  Here's a
boundary
case to illustrate the issue:

Let's say I have resource ID 1 bound by foo.html, ID 2 bound by bar.html,
and ID 3 bound by werf.html, all in the same collection.  Now, I issue 3
LOCK requests on each URL, and get lock tokens T1, T2, & T3.  Now (using a
temporary URL) I MOVE everything around so that foo.html refers to resource
ID 2, bar.html refers to ID 3, and werf.html refers to ID 1.  LOCK token T1
still refers to foo.html and resource ID 1, even though foo.html now refers
to resource ID 2, and if I UNLOCK with token T1, foo.html and resource ID 1
are unlocked.  I have to provide token T2 to UNLOCK resource ID 1.

> And does adding a resource to a depth locked collection, create a
> resource and name lock for the newly bound resource?

I would say that the default for this would be no, since again the
relationships between the names and resources is not something that the
server enforces--only clients can do that via use of locks.  Since the
collection is locked, you would have to provide the lock token to insert
the
new resource into the locked collection anyway.

However, there may be some need for combining the PUT and LOCK into the
same
request to avoid race conditions.  I can see this being an issue with a
number of protocol requests (BIND & LOCK, etc.).  There probably needs to
be
a way to add a lock as a part of any WebDAV request.

> And do name locks remain
> if a subtree is separated from the tree where the original LOCK request
> was submitted.

Yes.  That is why each name in the path (logically) is locked separately,
to
simplify the task of tracking all of these types of issues.
> If you delete a locked binding, is the name lock automatically deleted?
>
If you DELETE a locked resource, the resource lock is removed from the lock
set, leaving only the name locks.  I.e. I Lock /a/foo.html.  Then I delete
/a/foo.html.  I still have the name lock, so nobody else can put something
at /a/foo.html (I'm reserving the namespace like an LNR).  I think this
will
be needed for doing certain types of tree manipulations as an atomic unit.

>    A LOCK request on a URL giving a
>    nonexistent name in a existing collection will issue only name locks
on
> the
>    path elements.  If the URL minus the last path element does not refer
to
> an
>    existing collection, the LOCK request will fail.
>
> Thus we get the benefit of LNR's without having to create a pseudo
resource
> there.  Presumably PROPFIND will not pretend there is a resource there
> either.
> This sounds very good.  It's the main positive point I see in this
> proposal.
>

Right.  This is the main goal of my proposal, to create an abstraction that
is general.

>    3) the activelocks property displays all name locks active for this
>    collection as well as all resource locks.
>
> Hmm.  I've been wondering.  (This is actually a question for everyone
else.
> Especially Yaron.)   Why do we even have the activelocks or lockdiscovery
> property at all?  Just so clients can figure out who has a lock
> that is preventing them from doing something?
>

It would be nice to give an error message to people saying "sorry, you
can't
modify that--it is currently locked by Geoff" or whatever, so that they
know
who is blocking them.  I think Windows does this in some cases.

> BTW, Would activelocks on a collection would reveal name locks on
> descendents
> rather than the name locks of bindings to the collection?  Hopefully.
>

Yes.  The activelocks property (as a property of the collection) should
only
reveal state belonging to that collection.  Since the list of bindings to
descendants is the state of the collection, activelocks would list any
locks
on those names.

>    4) the "locktype" property is used to distinguish between name and
> resource
>    locks.  If locktype "resource" is specified, only the specified
resource
>    lock is granted in that lock set.  If locktype "name" is specified,
the
>    names from root to the resource are locked, if the Depth header is not
>    specified.
>
>
>    If the URL "/a/b/c.html" is given, negative depth values can be
>    given to lock fractions of the path.  E.g. if Depth:0 is specified,
the
> name
>    "c.html" is reserved in collection /a/b, but no other locks are
granted.
> If
>    Depth:-1 is specified, the name "b" in "/a" is also reserved (etc.)
> Only if
>    locktype is not specified does the LOCK request behave as it point #2
>    (granting resource & name locks simoultaneously), basically for
>    compatability with existing applications.
>
> Is all this needed? I thought the point in locking the name was to insure
> that
> the locked resource remained accessable to the client at a known URI?
"-1"
> doesn't achieve that and may prevent trivial implementations on top of
some
> respositories.  I'm also not sure I understand the motivation (at least
> given our
> current capabilities) of a client locking a resource without also locking
> the
> namespace.  Currently it doesn't seem helpful to lock a resource if you
> can't
> get at it subsequently.
>

I can see the value of allowing a URL reference that is derived from a
resource ID, like "/resources/1234" or something in some implementations
(Oracle's implementation will have this).  Resource ID is constant
regardless of BINDings.  I recommend adding something like this to the
protocol.

--Eric







From w3c-dist-auth-request@w3.org  Fri Jan  7 17:46:57 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28738
	for <webdav-archive@odin.ietf.org>; Fri, 7 Jan 2000 17:46:55 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id RAA23110;
	Fri, 7 Jan 2000 17:35:13 -0500 (EST)
Resent-Date: Fri, 7 Jan 2000 17:35:13 -0500 (EST)
Resent-Message-Id: <200001072235.RAA23110@www19.w3.org>
From: ccjason@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: "Eric Sedlar" <esedlar@us.oracle.com>
cc: w3c-dist-auth@w3.org
Message-ID: <8525685F.007BF688.00@D51MTA03.pok.ibm.com>
Date: Fri, 7 Jan 2000 17:34:35 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: Locking URIs rather than Resources
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3811
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


>    * a LOCK token must be associated with the locked resource and URL
  > Umm?  This doesn't sound like a requirement.  At least not a
fundamental
  > one.  Feel free to explain what you mean if you think this is an
important
  > point.
  >

  I had this as a requirement for compatability with RFC 2518.  Are you
  suggesting that lock tokens are superfluous and should be removed?

No.  Just that lock tokens are an implementation of a requirement, not
a requirement in and of themselves.  If the same can be achieved in some
other way, that's fine.  You seem to be shooting for compatibility in which
case LT are the mechanism to use.  -- I didn't actually understand the
point of your statement either.  That's fine though.  What's most important
is what you say below.



   It wasn't clear to me in general if shared locks were the default rather
   than exclusive, but it seems natural that this should be the case for
both
   name and resource locks.

I hadn't considered the possibility of name locks being exclusive.  The
need
for this wasn't one of our requirements.  We just wanted to protect a URI
from
having it's mapping change.  This was purely for the sanity of the client.

My initial vote for resource locks is that there be no default.  One must
specify what one wants.

   As far as treating name locks as a formal entity,
   that is a better way of describing what you are doing when you want a
lock
   on a URL not associated with a resource--you're locking only that PART
of
   the collection resource corresponding to that name in its set of
bindings,
   you aren't locking some resource that that name will be associated with
   later.

I'll just try harder to assimilate this view.

   I think that people who have worked with locking before understand the
   difference between locking an aggregate object and an individual item in
   that aggregate, as there are many examples of that in software today
   (locking a file vs. locking a byte range in that file, table locks vs.
row
   locks in a SQL database, etc.).  I don't think people are comfortable
with
   the idea of treating namespaces as lockable entities separate from the
   entities the names refer to, since that isn't generally done.

Actually, only Geoff's most recent proposal couched it that way.  All
others
have tended to say that a predetermined set of bindings are "protected".
The
term "locked" wasn't used... and after it was set up, it wasn't based on
namespace... just bindings.


  Once you
  agree that the set of bindings are part of the state of a collection, you
  are treating the collection resource as an aggregate that can be locked,
as
  well as one or more bindings it contains.  The model I propose is
simpler,
  in that only one kind of object WebDAV requests can refer to--the
resource,
  without treating URLs as something separate.

A good thing. URL's are just a side effect.  I forget the word Geoff used
to
use to refer to this.



  > I agree with the semantics, but I'm uncomfortable with creating a new
  > concept
  > called a "lock set".  This also rings of "implementation".
  > Hopefully this can be avoided.  Anyway...

  The lock set is just a group of locks associated with a single lock
token.
  Given that the Depth: infinity header effectively gets many locks (rather
  than one big lock) and associates them with a single token, you were
already
  doing this before, just without a name.  It just seemed to me to be
easier
  to understand if you have a term for describing what a lock token
  identifies.  This is just a terminology issue.

I am still uncomfortable speaking of sets of locks.  Also, that's not what
we had before except in one proposal that someone made (twice) but that
proposal didn't last long.  People liked the dynamic nature of this.
That's
not to say that it had to be based on namespace.  Just parentage.

Perhaps I shoudln't say this, but with the advent locking of collections,
do
we still need depth locks?  I forget why this was important and what set of
people felt it was important.  I know Jim Whitehead was one of the people
and I believed the others were document management folks that wanted to
to lock composite entities.  Anyway, I just wanted to check if we still
need them.  If so, I'd like to explicitly note this in the locking doc I'm
doing.


Re: Depth locking...

  >    An RFC 2518 LOCK
  >    request applied to a collection will work in the same way, except
that
  >    if
  >    the depth header is specified, name and resource locks will be given
  >    recursively for each contained resource.
  >
  > Hmmm.  Or perhaps just resource locks.  No, that won't work either.
  > Okay...
  > You're going to have to explain some of the
  > complications of this.  Like, are all of these resources still locked
if
  > you
  > remove the binding that put them under the influence of the original
lock
  > request?

  No.  The LOCK protocol request is a shorthand way of requesting a set of
  names and resources to lock.  Deleting one of the names or resources you
  have locked removes the locks, since you have nothing there remaining to
  lock.

The DELETE only removes the binding.  The resource may still exist and
be exposed at other URI's.  More below.

  The validity of the relationships between the set of names that are
  locked and the resources they apply to is not maintained.  Here's a
boundary
  case to illustrate the issue:

  Let's say I have resource ID 1 bound by foo.html, ID 2 bound by bar.html,
  and ID 3 bound by werf.html, all in the same collection.  Now, I issue 3
  LOCK requests on each URL, and get lock tokens T1, T2, & T3.  Now (using
a
  temporary URL) I MOVE everything around so that foo.html refers to
resource
  ID 2, bar.html refers to ID 3, and werf.html refers to ID 1.  LOCK token
T1
  still refers to foo.html and resource ID 1, even though foo.html now
refers
  to resource ID 2, and if I UNLOCK with token T1, foo.html and resource ID
1
  are unlocked.

Yucky!  A very nice clean model, but it doesn't serve the client very
well if the methods will act this way.  Letting a LT's name locks get
separated
from it's resource locks seems like a bad idea and probably serves no
purpose.
In addition, the client can't release one type of locks (name) without
releasing the
other (resource)... unless the client creates two lock sets explicitly.

  >  I have to provide token T2 to UNLOCK resource ID 1.

I think you mean you have to use T1 to unlock ID 1, but you have to use T2
to
unlock the name/binding/slot that currently maps to ID 1.


  > And does adding a resource to a depth locked collection, create a
  > resource and name lock for the newly bound resource?

  I would say that the default for this would be no, since again the
  relationships between the names and resources is not something that the
  server enforces--only clients can do that via use of locks.  Since the
  collection is locked, you would have to provide the lock token to insert
the
  new resource into the locked collection anyway.

The thinking on the list has been that they want it automatically extended
to
the children.  Folks have questioned this on occasion and the folks that
value
depth locks have always expressed a preference for the locks automatically
being extended to children.  In addition, they liked having the lock stop
applying to any child resource that leaves the locked tree.

  However, there may be some need for combining the PUT and LOCK into the
same
  request to avoid race conditions.  I can see this being an issue with a
  number of protocol requests (BIND & LOCK, etc.).  There probably needs to
be
  a way to add a lock as a part of any WebDAV request.

Perhaps folks would find this acceptable.  That is, if a client is adding
to a
locked collection, the client can specify that the lock be extended to what
it is
adding to that collection. -- Or perhaps we'd make the default to extend
any
depth locks affecting the collection into which a resource is added.  Noone
has mentioned actually wanting it NOT to be added.


  > And do name locks remain
  > if a subtree is separated from the tree where the original LOCK request
  > was submitted.

  Yes.  That is why each name in the path (logically) is locked separately,
to
  simplify the task of tracking all of these types of issues.

When stated as I did above, people have expressed a preference to having
the
inherited locks stop acting on the resources that move/delete away.  But
if it was the resource
itself that was originally locked (not via inheritance) many folks like it
to
continue to affect the resource even after movement/unbinding.

  > If you delete a locked binding, is the name lock automatically deleted?

  If you DELETE a locked resource, the resource lock is removed from the
lock
  set, leaving only the name locks.  I.e. I Lock /a/foo.html.  Then I
delete
  /a/foo.html.  I still have the name lock, so nobody else can put
something
  at /a/foo.html (I'm reserving the namespace like an LNR).
  I think this will
  be needed for doing certain types of tree manipulations as an atomic
unit.

Reserving the namespace can be a good thing.

As for unlocking the resource that was deleted... remember, DELETE just
removes a binding, and does not necessarily destroy the resource.  It may
or may not having other bindings and mappings.   I don't disagree that
this might be the right thing to do, but if we do decide to unlock that
resource, we have have to cross our fingers when we say the resource lock
is on a resource.

  > Thus we get the benefit of LNR's without having to create a pseudo
  > resource
  > there.  Presumably PROPFIND will not pretend there is a resource there
  > either.
  > This sounds very good.  It's the main positive point I see in this
  > proposal.

  Right.  This is the main goal of my proposal, to create an abstraction
that
  is general.

  >    3) the activelocks property displays all name locks active for this
  >    collection as well as all resource locks.
  >
  > BTW, Would activelocks on a collection would reveal name locks on
  > descendents
  > rather than the name locks of bindings to the collection?  Hopefully.


  Yes.  The activelocks property (as a property of the collection) should
only
  reveal state belonging to that collection.  Since the list of bindings to
  descendants is the state of the collection, activelocks would list any
locks
  on those names.

Yea!  So "LNR"s will reject PROPFIND requests just like ordinary null
resources.
Good stuff.

  >    4) the "locktype" property is used to distinguish between name and
  >    resource
  >    locks.  If locktype "resource" is specified, only the specified
  >    resource
  >    lock is granted in that lock set.  If locktype "name" is specified,
the
  >    names from root to the resource are locked, if the Depth header is
not
  >    specified.
  >
  >
  >    If the URL "/a/b/c.html" is given, negative depth values can be
  >    given to lock fractions of the path.  E.g. if Depth:0 is specified,
the
  >    name
  >    "c.html" is reserved in collection /a/b, but no other locks are
  >    granted.
  >    If
  >    Depth:-1 is specified, the name "b" in "/a" is also reserved (etc.)
  >    Only if
  >    locktype is not specified does the LOCK request behave as it point
#2
  >    (granting resource & name locks simoultaneously), basically for
  >    compatability with existing applications.
  >
  > Is all this needed? I thought the point in locking the name was to
insure
  > that
  > the locked resource remained accessable to the client at a known URI?
  > "-1"
  > doesn't achieve that and may prevent trivial implementations on top of
  > some
  > respositories.  I'm also not sure I understand the motivation (at least
  > given our
  > current capabilities) of a client locking a resource without also
locking
  > the
  > namespace.  Currently it doesn't seem helpful to lock a resource if you
  > can't
  > get at it subsequently.

  I can see the value of allowing a URL reference that is derived from a
  resource ID, like "/resources/1234" or something in some implementations
  (Oracle's implementation will have this).  Resource ID is constant
  regardless of BINDings.  I recommend adding something like this to the
  protocol.

I can see the value in that too.  It sounds like something that could
neatly
go in a separate proposal.  It doesn't impact anything else.

Still though... I have my doubts that all of the above concerning negative
depths is worthwhile. And in fact for platforms like IIS that want to use
native capabilities, I don't think they'll be albe to do anything other
than
lock all of the bindingss up to the root.





From w3c-dist-auth-request@w3.org  Fri Jan  7 18:49:13 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29168
	for <webdav-archive@odin.ietf.org>; Fri, 7 Jan 2000 18:49:13 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA25035;
	Fri, 7 Jan 2000 18:37:52 -0500 (EST)
Resent-Date: Fri, 7 Jan 2000 18:37:52 -0500 (EST)
Resent-Message-Id: <200001072337.SAA25035@www19.w3.org>
Message-ID: <38767A78.FC32B010@us.oracle.com>
Date: Fri, 07 Jan 2000 15:44:56 -0800
From: Eric Sedlar <esedlar@us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ccjason@us.ibm.com
CC: w3c-dist-auth@w3.org
References: <8525685F.007BF688.00@D51MTA03.pok.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Locking URIs rather than Resources
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3812
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

You make a bunch of comments about lock sets and Depth locks, and you don't
seem particularly comfortable with any of this stuff.  This is all coming from
Document Management requirements for compound documents.  I think the correct
solution to these issues comes from understanding that requirement.  Here is a
counterexample to your dynamic lock preference...

Let's say that I have a "book" entity that I want to manifest as a collection
resource (with some additional XML properties describing the book's state).
In the collection is a set of HTML resources corresponding to each chapter of
a book.  Let's say that this book is a programmer's guide  for a software
product, and a couple of these chapters are about "Getting Started".  Now we
add an administration manual (another collection somewhere else) and I want to
share the Getting Started (GS) info between books, so I want to move those
chapters into a third collection containing shared resources between the
manuals.  I have the following collections now:

/manuals/prguide
/manuals/common
/manuals/admin

When I started working on the programmer's guide (PG), I depth:infinity lock
the entire collection with a shared lock, to make sure nobody messes with the
chapters while I am working.  When I move the GS info out of the locked
collection I want to retain these locks, since they are still part of the
manual.

The automatic assumptions Jason proposes regarding when locks are removed in
the face of BINDs, MOVEs, etc. are not going to be correct in all cases.  If
I depth lock a collection, I have a perfectly valid example of when I want to
retain the lock when members of a collection are moved out.  There is no
recourse in this situation, since reestablishing the lock introduces a race
condition.

Therefore, I think it is better that the client (i.e. the application) have
specific control of the locking semantics, and that the server not try to do a
lot of funny stuff with guessing what the client wants.

---------

Other miscellaneous responses:

* the negative depth proposal, along with a header to allow name locking
separate from resource locking, are for the functional completeness of the
model.  The problem with locks is that you often want to get a bunch of them
at once (and have the server handle any deadlock detection issues).  Another
way to handle this is to allow a list of URLs to be LOCKed to be attached to
ANY request.

* when I refer to DELETEing a resource in my proposal earlier, I mean a DELETE
that removes the last binding, deleting the associated resource.

--Eric


ccjason@us.ibm.com wrote:

> >    * a LOCK token must be associated with the locked resource and URL
>   > Umm?  This doesn't sound like a requirement.  At least not a
> fundamental
>   > one.  Feel free to explain what you mean if you think this is an
> important
>   > point.
>   >
>
>   I had this as a requirement for compatability with RFC 2518.  Are you
>   suggesting that lock tokens are superfluous and should be removed?
>
> No.  Just that lock tokens are an implementation of a requirement, not
> a requirement in and of themselves.  If the same can be achieved in some
> other way, that's fine.  You seem to be shooting for compatibility in which
> case LT are the mechanism to use.  -- I didn't actually understand the
> point of your statement either.  That's fine though.  What's most important
> is what you say below.
>
>    It wasn't clear to me in general if shared locks were the default rather
>    than exclusive, but it seems natural that this should be the case for
> both
>    name and resource locks.
>
> I hadn't considered the possibility of name locks being exclusive.  The
> need
> for this wasn't one of our requirements.  We just wanted to protect a URI
> from
> having it's mapping change.  This was purely for the sanity of the client.
>
> My initial vote for resource locks is that there be no default.  One must
> specify what one wants.
>
>    As far as treating name locks as a formal entity,
>    that is a better way of describing what you are doing when you want a
> lock
>    on a URL not associated with a resource--you're locking only that PART
> of
>    the collection resource corresponding to that name in its set of
> bindings,
>    you aren't locking some resource that that name will be associated with
>    later.
>
> I'll just try harder to assimilate this view.
>
>    I think that people who have worked with locking before understand the
>    difference between locking an aggregate object and an individual item in
>    that aggregate, as there are many examples of that in software today
>    (locking a file vs. locking a byte range in that file, table locks vs.
> row
>    locks in a SQL database, etc.).  I don't think people are comfortable
> with
>    the idea of treating namespaces as lockable entities separate from the
>    entities the names refer to, since that isn't generally done.
>
> Actually, only Geoff's most recent proposal couched it that way.  All
> others
> have tended to say that a predetermined set of bindings are "protected".
> The
> term "locked" wasn't used... and after it was set up, it wasn't based on
> namespace... just bindings.
>
>   Once you
>   agree that the set of bindings are part of the state of a collection, you
>   are treating the collection resource as an aggregate that can be locked,
> as
>   well as one or more bindings it contains.  The model I propose is
> simpler,
>   in that only one kind of object WebDAV requests can refer to--the
> resource,
>   without treating URLs as something separate.
>
> A good thing. URL's are just a side effect.  I forget the word Geoff used
> to
> use to refer to this.
>
>   > I agree with the semantics, but I'm uncomfortable with creating a new
>   > concept
>   > called a "lock set".  This also rings of "implementation".
>   > Hopefully this can be avoided.  Anyway...
>
>   The lock set is just a group of locks associated with a single lock
> token.
>   Given that the Depth: infinity header effectively gets many locks (rather
>   than one big lock) and associates them with a single token, you were
> already
>   doing this before, just without a name.  It just seemed to me to be
> easier
>   to understand if you have a term for describing what a lock token
>   identifies.  This is just a terminology issue.
>
> I am still uncomfortable speaking of sets of locks.  Also, that's not what
> we had before except in one proposal that someone made (twice) but that
> proposal didn't last long.  People liked the dynamic nature of this.
> That's
> not to say that it had to be based on namespace.  Just parentage.
>
> Perhaps I shoudln't say this, but with the advent locking of collections,
> do
> we still need depth locks?  I forget why this was important and what set of
> people felt it was important.  I know Jim Whitehead was one of the people
> and I believed the others were document management folks that wanted to
> to lock composite entities.  Anyway, I just wanted to check if we still
> need them.  If so, I'd like to explicitly note this in the locking doc I'm
> doing.
>
> Re: Depth locking...
>
>   >    An RFC 2518 LOCK
>   >    request applied to a collection will work in the same way, except
> that
>   >    if
>   >    the depth header is specified, name and resource locks will be given
>   >    recursively for each contained resource.
>   >
>   > Hmmm.  Or perhaps just resource locks.  No, that won't work either.
>   > Okay...
>   > You're going to have to explain some of the
>   > complications of this.  Like, are all of these resources still locked
> if
>   > you
>   > remove the binding that put them under the influence of the original
> lock
>   > request?
>
>   No.  The LOCK protocol request is a shorthand way of requesting a set of
>   names and resources to lock.  Deleting one of the names or resources you
>   have locked removes the locks, since you have nothing there remaining to
>   lock.
>
> The DELETE only removes the binding.  The resource may still exist and
> be exposed at other URI's.  More below.
>
>   The validity of the relationships between the set of names that are
>   locked and the resources they apply to is not maintained.  Here's a
> boundary
>   case to illustrate the issue:
>
>   Let's say I have resource ID 1 bound by foo.html, ID 2 bound by bar.html,
>   and ID 3 bound by werf.html, all in the same collection.  Now, I issue 3
>   LOCK requests on each URL, and get lock tokens T1, T2, & T3.  Now (using
> a
>   temporary URL) I MOVE everything around so that foo.html refers to
> resource
>   ID 2, bar.html refers to ID 3, and werf.html refers to ID 1.  LOCK token
> T1
>   still refers to foo.html and resource ID 1, even though foo.html now
> refers
>   to resource ID 2, and if I UNLOCK with token T1, foo.html and resource ID
> 1
>   are unlocked.
>
> Yucky!  A very nice clean model, but it doesn't serve the client very
> well if the methods will act this way.  Letting a LT's name locks get
> separated
> from it's resource locks seems like a bad idea and probably serves no
> purpose.
> In addition, the client can't release one type of locks (name) without
> releasing the
> other (resource)... unless the client creates two lock sets explicitly.
>
>   >  I have to provide token T2 to UNLOCK resource ID 1.
>
> I think you mean you have to use T1 to unlock ID 1, but you have to use T2
> to
> unlock the name/binding/slot that currently maps to ID 1.
>
>   > And does adding a resource to a depth locked collection, create a
>   > resource and name lock for the newly bound resource?
>
>   I would say that the default for this would be no, since again the
>   relationships between the names and resources is not something that the
>   server enforces--only clients can do that via use of locks.  Since the
>   collection is locked, you would have to provide the lock token to insert
> the
>   new resource into the locked collection anyway.
>
> The thinking on the list has been that they want it automatically extended
> to
> the children.  Folks have questioned this on occasion and the folks that
> value
> depth locks have always expressed a preference for the locks automatically
> being extended to children.  In addition, they liked having the lock stop
> applying to any child resource that leaves the locked tree.
>
>   However, there may be some need for combining the PUT and LOCK into the
> same
>   request to avoid race conditions.  I can see this being an issue with a
>   number of protocol requests (BIND & LOCK, etc.).  There probably needs to
> be
>   a way to add a lock as a part of any WebDAV request.
>
> Perhaps folks would find this acceptable.  That is, if a client is adding
> to a
> locked collection, the client can specify that the lock be extended to what
> it is
> adding to that collection. -- Or perhaps we'd make the default to extend
> any
> depth locks affecting the collection into which a resource is added.  Noone
> has mentioned actually wanting it NOT to be added.
>
>   > And do name locks remain
>   > if a subtree is separated from the tree where the original LOCK request
>   > was submitted.
>
>   Yes.  That is why each name in the path (logically) is locked separately,
> to
>   simplify the task of tracking all of these types of issues.
>
> When stated as I did above, people have expressed a preference to having
> the
> inherited locks stop acting on the resources that move/delete away.  But
> if it was the resource
> itself that was originally locked (not via inheritance) many folks like it
> to
> continue to affect the resource even after movement/unbinding.
>
>   > If you delete a locked binding, is the name lock automatically deleted?
>
>   If you DELETE a locked resource, the resource lock is removed from the
> lock
>   set, leaving only the name locks.  I.e. I Lock /a/foo.html.  Then I
> delete
>   /a/foo.html.  I still have the name lock, so nobody else can put
> something
>   at /a/foo.html (I'm reserving the namespace like an LNR).
>   I think this will
>   be needed for doing certain types of tree manipulations as an atomic
> unit.
>
> Reserving the namespace can be a good thing.
>
> As for unlocking the resource that was deleted... remember, DELETE just
> removes a binding, and does not necessarily destroy the resource.  It may
> or may not having other bindings and mappings.   I don't disagree that
> this might be the right thing to do, but if we do decide to unlock that
> resource, we have have to cross our fingers when we say the resource lock
> is on a resource.
>
>   > Thus we get the benefit of LNR's without having to create a pseudo
>   > resource
>   > there.  Presumably PROPFIND will not pretend there is a resource there
>   > either.
>   > This sounds very good.  It's the main positive point I see in this
>   > proposal.
>
>   Right.  This is the main goal of my proposal, to create an abstraction
> that
>   is general.
>
>   >    3) the activelocks property displays all name locks active for this
>   >    collection as well as all resource locks.
>   >
>   > BTW, Would activelocks on a collection would reveal name locks on
>   > descendents
>   > rather than the name locks of bindings to the collection?  Hopefully.
>
>   Yes.  The activelocks property (as a property of the collection) should
> only
>   reveal state belonging to that collection.  Since the list of bindings to
>   descendants is the state of the collection, activelocks would list any
> locks
>   on those names.
>
> Yea!  So "LNR"s will reject PROPFIND requests just like ordinary null
> resources.
> Good stuff.
>
>   >    4) the "locktype" property is used to distinguish between name and
>   >    resource
>   >    locks.  If locktype "resource" is specified, only the specified
>   >    resource
>   >    lock is granted in that lock set.  If locktype "name" is specified,
> the
>   >    names from root to the resource are locked, if the Depth header is
> not
>   >    specified.
>   >
>   >
>   >    If the URL "/a/b/c.html" is given, negative depth values can be
>   >    given to lock fractions of the path.  E.g. if Depth:0 is specified,
> the
>   >    name
>   >    "c.html" is reserved in collection /a/b, but no other locks are
>   >    granted.
>   >    If
>   >    Depth:-1 is specified, the name "b" in "/a" is also reserved (etc.)
>   >    Only if
>   >    locktype is not specified does the LOCK request behave as it point
> #2
>   >    (granting resource & name locks simoultaneously), basically for
>   >    compatability with existing applications.
>   >
>   > Is all this needed? I thought the point in locking the name was to
> insure
>   > that
>   > the locked resource remained accessable to the client at a known URI?
>   > "-1"
>   > doesn't achieve that and may prevent trivial implementations on top of
>   > some
>   > respositories.  I'm also not sure I understand the motivation (at least
>   > given our
>   > current capabilities) of a client locking a resource without also
> locking
>   > the
>   > namespace.  Currently it doesn't seem helpful to lock a resource if you
>   > can't
>   > get at it subsequently.
>
>   I can see the value of allowing a URL reference that is derived from a
>   resource ID, like "/resources/1234" or something in some implementations
>   (Oracle's implementation will have this).  Resource ID is constant
>   regardless of BINDings.  I recommend adding something like this to the
>   protocol.
>
> I can see the value in that too.  It sounds like something that could
> neatly
> go in a separate proposal.  It doesn't impact anything else.
>
> Still though... I have my doubts that all of the above concerning negative
> depths is worthwhile. And in fact for platforms like IIS that want to use
> native capabilities, I don't think they'll be albe to do anything other
> than
> lock all of the bindingss up to the root.



From w3c-dist-auth-request@w3.org  Sat Jan  8 21:45:45 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08953
	for <webdav-archive@odin.ietf.org>; Sat, 8 Jan 2000 21:45:44 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id VAA11686;
	Sat, 8 Jan 2000 21:34:11 -0500 (EST)
Resent-Date: Sat, 8 Jan 2000 21:34:11 -0500 (EST)
Resent-Message-Id: <200001090234.VAA11686@www19.w3.org>
From: ccjason@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: Eric Sedlar <esedlar@us.oracle.com>
cc: w3c-dist-auth@w3.org
Message-ID: <85256861.000E114B.00@D51MTA03.pok.ibm.com>
Date: Sat, 8 Jan 2000 21:33:14 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: Locking URIs rather than Resources
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3813
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list





  Let's say that I have a "book" entity that I want to manifest as a
collection
  resource (with some additional XML properties describing the book's
state).
  In the collection is a set of HTML resources corresponding to each
chapter of
  a book.  Let's say that this book is a programmer's guide  for a software
  product, and a couple of these chapters are about "Getting Started".  Now
we
  add an administration manual (another collection somewhere else) and I
want to
  share the Getting Started (GS) info between books, so I want to move
those
  chapters into a third collection containing shared resources between the
  manuals.  I have the following collections now:

  /manuals/prguide
  /manuals/common
  /manuals/admin

  When I started working on the programmer's guide (PG), I depth:infinity
lock
  the entire collection with a shared lock, to make sure nobody messes with
the
  chapters while I am working.  When I move the GS info out of the locked
  collection I want to retain these locks, since they are still part of the
  manual.

  The automatic assumptions Jason proposes regarding when locks are removed
in
  the face of BINDs, MOVEs, etc. are not going to be correct in all cases.
If
  I depth lock a collection, I have a perfectly valid example of when I
want to
  retain the lock when members of a collection are moved out.  There is no
  recourse in this situation, since reestablishing the lock introduces a
race
  condition.

Of course it sounds like you don't need to (or want to) move it out of the
locked
collection though.  You just need to add a binding from the common
collection.  You get the right result that way.  Even for
exclusive locks.


  * when I refer to DELETEing a resource in my proposal earlier, I mean a
DELETE
  that removes the last binding, deleting the associated resource.

And if it is the last binding, whether the resource is locked or not is
probably moot.
If it isn't the last binding, then I take it you feel the resource remains
locked?




From w3c-dist-auth-request@w3.org  Sun Jan  9 04:05:40 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05689
	for <webdav-archive@odin.ietf.org>; Sun, 9 Jan 2000 04:05:39 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id DAA14650;
	Sun, 9 Jan 2000 03:53:57 -0500 (EST)
Resent-Date: Sun, 9 Jan 2000 03:53:57 -0500 (EST)
Resent-Message-Id: <200001090853.DAA14650@www19.w3.org>
Message-Id: <4.1.20000109085404.00b64a80@pop.xs4all.nl>
X-Sender: contact@pop.lanminds.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sun, 09 Jan 2000 09:08:13 +0100
To: w3c-dist-auth@w3.org
From: Jim Davis <jrd3@alum.mit.edu>
In-Reply-To: <38767A78.FC32B010@us.oracle.com>
References: <8525685F.007BF688.00@D51MTA03.pok.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Re: Locking URIs rather than Resources
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3814
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

At 03:44 PM 1/7/00 -0800, Eric Sedlar wrote:

>Let's say that I have a "book" entity that I want to manifest as a collection
>resource ...Let's say that this book is a programmer's guide  for a software
>product, and a couple of these chapters are about "Getting Started".  Now
... I want to move those
>chapters into a third collection containing shared resources between the
>manuals.  I have the following collections now:
>
>/manuals/prguide
>/manuals/common
>/manuals/admin
>
>When I started working on the programmer's guide (PG), I depth:infinity lock
>the entire collection with a shared lock, to make sure nobody messes with the
>chapters while I am working.  

This is a good use case, thanks for contributing it.  I think it's
reasonable to require that something like this work.  But I don't agree
that it shows a problem.  I think there are at least three ways to use
WebDAV and meet your requirements.  

1) lock the common collection with depth infinity.  Then when you move the
files, they are added to the lock. 

2) Create a temp collection, depth lock it, move the files there.  edit
them until you are ready to release the lock, then move them to the common
collection, where they will be seen by your co-workers.

3) For each file that you wish to move to common, lock a null resource in
the common collection.  then do the moves.  the formerly locked-null
resources will become locked "normal" resources.

Is at least one of these acceptable?

Note that I am talking about  WebDAV as in RFC 2518, I am not completely
sure these apply to the newer proposals for lock. 

>Therefore, I think it is better that the client (i.e. the application) have
>specific control of the locking semantics, and that the server not try to do a
>lot of funny stuff with guessing what the client wants.

That's a good principle in general.



From w3c-dist-auth-request@w3.org  Tue Jan 11 17:28:25 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22631
	for <webdav-archive@odin.ietf.org>; Tue, 11 Jan 2000 17:28:24 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id RAA29668;
	Tue, 11 Jan 2000 17:16:45 -0500 (EST)
Resent-Date: Tue, 11 Jan 2000 17:16:45 -0500 (EST)
Resent-Message-Id: <200001112216.RAA29668@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: Fredy Ortiz <ortizf@prodigy.net>, w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at gremlin-relay.ics.uci.edu
Date: Tue, 11 Jan 2000 14:13:08 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJIELNCLAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <LPBBKOMFMFLLEPKAEFGNGEHCCAAA.ortizf@prodigy.net>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: RE: [Moderator Action] WEBDAV Mailing List
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3815
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Fredy,

I have added you to the WebDAV mailing list -- welcome!

As for implementing the specification, there are currently several people
involved in this activity, some open source, some commercial.  A complete
list of projects can be found at http://www.webdav.org/projects/ and the
open source projects especially are always looking for volunteers.  If you
were interested in doing commercial WebDAV implementation work, I could
recommend some people to talk with...

- Jim

> -----Original Message-----
> From: Fredy Ortiz [mailto:ortizf@prodigy.net]
> Sent: Monday, January 10, 2000 4:44 AM
> To: w3c-dist-auth@w3.org
> Subject: [Moderator Action] WEBDAV Mailing List
>
>
> Hello,
>
> I would like to be added to this mailing list and I am interested in be
> involved in the WEBDAV specification implementation. Here's a copy of my
> resume. Hope I can be of some assistant.
>
> Thanks,
>
> Fredy Ortiz
>



From w3c-dist-auth-request@w3.org  Tue Jan 11 17:52:43 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22947
	for <webdav-archive@odin.ietf.org>; Tue, 11 Jan 2000 17:52:40 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id RAA00636;
	Tue, 11 Jan 2000 17:31:39 -0500 (EST)
Resent-Date: Tue, 11 Jan 2000 17:31:39 -0500 (EST)
Resent-Message-Id: <200001112231.RAA00636@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at gremlin-relay.ics.uci.edu
Date: Tue, 11 Jan 2000 14:28:05 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJKELPCLAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <NDBBIKLAGLCOPGKGADOJIELNCLAA.ejw@ics.uci.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: RE: [Moderator Action] WEBDAV Mailing List
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3816
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit


D'oh -- pesky "reply to all" key!  Sorry for sending this out to everyone on
the list. :-(

- Jim

> I have added you to the WebDAV mailing list -- welcome!
>
> As for implementing the specification, there are currently several people
> involved in this activity, some open source, some commercial.  A complete
> list of projects can be found at http://www.webdav.org/projects/ and the
> open source projects especially are always looking for volunteers.  If you
> were interested in doing commercial WebDAV implementation work, I could
> recommend some people to talk with...
>
>



From w3c-dist-auth-request@w3.org  Wed Jan 12 09:31:35 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16829
	for <webdav-archive@odin.ietf.org>; Wed, 12 Jan 2000 09:31:34 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id JAA25431;
	Wed, 12 Jan 2000 09:20:27 -0500 (EST)
Resent-Date: Wed, 12 Jan 2000 09:20:27 -0500 (EST)
Resent-Message-Id: <200001121420.JAA25431@www19.w3.org>
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD2455F@crte147.wc.eso.mc.xerox.com>
From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'WebDAV'" <w3c-dist-auth@w3.org>
Cc: "'Owen_Ambur@fws.gov'" <Owen_Ambur@fws.gov>
Date: Wed, 12 Jan 2000 09:20:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: FW: WebDAV & DoD 5015.2
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3817
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

I haven't seen any discussion of DoD 5015.2, but I'm forwarding your note to
the WebDAV mailing list, where implementers of WebDAV servers will see it.
I'll also refer you to the web site http://www.webdav.org/projects/ for a
list of implementations of both servers and clients.

--Judy

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580


-----Original Message-----
From: Owen_Ambur@fws.gov [mailto:Owen_Ambur@fws.gov] 
Sent: Tuesday, January 11, 2000 6:07 PM
To: jslein@crt.xerox.com
Subject: WebDAV & DoD 5015.2


Judy, since your name is associated with the topic of "WebDAV Collections"
at
<http://www.ietf.org/proceedings/99mar/slides/webdav-collect-99mar/sld001.ht
m>,

can you tell me if Xerox or any of the other WebDAV vendors are planning to
obtain direct or pair certification under DoD's 5015.2 standard for records
management?

See <http://www.fws.gov/laws/firmstand/FIRMstand.htm>.

Owen Ambur, Acting Chief
Branch of  Management Services
Division of IRM, U.S. Fish & Wildlife Service



From w3c-dist-auth-request@w3.org  Wed Jan 12 18:24:22 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26719
	for <webdav-archive@odin.ietf.org>; Wed, 12 Jan 2000 18:24:22 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA18449;
	Wed, 12 Jan 2000 18:12:54 -0500 (EST)
Resent-Date: Wed, 12 Jan 2000 18:12:54 -0500 (EST)
Resent-Message-Id: <200001122312.SAA18449@www19.w3.org>
Date: Wed, 12 Jan 2000 18:12:43 -0500
Message-Id: <10001122312.AA22058@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
Subject: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3818
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


Eric suggests that a URL-based locking model should be mapped into the
underlying collection resources that implement the namespace.  I agree
with both this conclusion and the reasoning leading up to it.

But I think it is simpler to model namespace protection and state
protection as being two results of a single kind of lock, as opposed
to the result of two different kinds of locks.  This avoids the
problem of describing how namespace locks and state locks interact.

In an attempt to make the proposal both understandable and complete,
I've broken it into two parts.  The first part is a series of bullets,
which largely correspond to the "URL-based locking" proposal I mailed out
a while ago.  The second part is the same series of bullets fleshed out
with a more formal description of each bullet in terms of an underlying
resource model and effects on the visible lock state of resources.

**************************

GULP: Part I

- A URL identifies a resource.
- A LOCK request creates a lock on the request URL.
- An UNLOCK request removes all locks with the specified lock token.
- A lock on a URL protects which resource is identified by that URL.
- A Depth:N lock on a URL locks any URL that extends the locked URL by no
more than N segments.
- A Depth:infinity lock on a URL locks all URL's that extend the locked URL.
- If an exclusive lock identifies a resource, no other lock of that type can
identify that resource.
- A write-lock on a URL protects the body and dead properties of any
resource identified by that URL.

**************************

GULP: Part II

- A URL identifies a resource.

The URL "/" identifies a resource. A collection contains a set of bindings,
where a binding is a mapping from a URL segment to a resource. If "/path"
identifies a collection C, and C contains a binding that maps the segment
"x" to resource R, then the URL "/path/x" identifies resource R.

- A lock is on a URL. Every lock has a lock token and a lock owner.

Every lock on a resource has a name which is a relative URL (i.e. a slash
separated sequence of URL segments). Every LOCK request that succeeds
results in a new globally unique lock token. Every lock token has an owner
that is the principal of the LOCK request.

- A LOCK request creates a lock on the request URL.

When a request of the form "LOCK /pathX" succeeds, a lock named "pathY/."
with a new lock token is added to the resource identified by "/", where
"pathY" is the result of applying standard URL path transformations to
remove all segments named "." or ".." from "pathX". If a collection C has a
binding from "segX" to resource R, and a request adds a lock named
"segX/pathZ" with token "L" to C, then the request adds a lock named "pathZ"
with token "L" to R. Similarly, if a collection C has a lock named
"segX/pathZ" with token "L", and a request (e.g. PUT, COPY, MOVE, BIND) adds
a binding in C from "segX" to resource R, then the request adds a lock named
"pathZ" with token "L" to R. If the attempt to add the lock named "pathZ" to
R fails, the request MUST fail.

- An UNLOCK request removes all locks with the specified lock token.

When a request of the form "UNLOCK /pathX; Lock-Token L" succeeds, then the
lock with token "L" is removed from the resource identified by "/". If a
collection C has a binding from "segX" to resource R, and a request removes
a lock named "segX/pathZ" with token "L" from C, then the request removes a
lock named "pathZ" with token "L" from R. Similarly, if a collection has a
lock named "segX/pathZ" with token "L", and a request (e.g. DELETE, MOVE)
removes a binding in C from "segX" to resource R, then a lock named "pathZ"
with token "L" is removed from R.

- A lock on a URL protects which resource is identified by that URL.

If a collection identified by the URL "/colX" contains a lock named "pathZ"
with token "L", if a request would change the resource identified by
"/colX/pathZ", the request MUST specify token "L" in an IF header and the
request principal MUST be the owner of token "L".

- A Depth:N lock on a URL locks any URL that extends the locked URL by no
more than N segments.

If a collection C has a binding to resource R, and a request adds a Depth:N
lock named "." with token "L" to C, then the request adds a Depth:N-1 lock
named "." with token "L" to R. Similarly, if a collection C has a Depth:N
lock named "." with token "L", and a request adds a binding in C to resource
R, then the request adds a Depth:N-1 lock named "." with token "L" to R. If
the attempt to add the lock named "." to R fails, the request MUST fail.
Conversely, the Depth:N-1 lock is removed from R whenever a binding to R or
the Depth:N lock is removed from C.

- A Depth:infinity lock on a URL locks all URL's that extend the locked URL.

If a collection C has a binding to resource R, and a request adds a
Depth:infinity lock named "." with token "L" to C, and this is the first
Depth:infinity lock named "." with token "L" on C, then the request adds a
Depth:infinity lock named "." with token "L" to R. Similarly, if a
collection C has a Depth:infinity lock named "." with token "L", and a
request adds a binding in C to resource R, then the request adds a
Depth:infinity lock named "." with token "L" to R. If the attempt to add the
lock named "." to R fails, the request MUST fail. If a collection C has a
binding to resource R, and a request removes the last Depth:infinity lock
named "." with token "L" from C, then the request removes a Depth:infinity
lock named "." with token "L" from R. Similarly, if a collection has a
Depth:infinity lock named "." with token "L", and a request removes a
binding in C to resource R, then a Depth:infinity lock named "." with token
"L" is removed from R. Note that multiple Depth:infinity locks named "."
with the same token can be placed on the same resource due to multiple
bindings to that resource in a Depth:infinity locked collection.

- If an exclusive lock identifies a resource, no other lock of that type can
identify that resource.

If a request attempts to add a lock named "pathZ" with token "L" and type T
to resource R, and R already has an exclusive lock named "pathZ" with type
"L" but with a different token, the request MUST fail. Similarly, if a
request attempts to add an exclusive lock named "pathZ" with token "L" and
type T to resource R, and R already has a lock named "pathZ" with type T but
with a different token, the request MUST fail.

- A write-lock on a URL protects the body and dead properties of any
resource identified by that URL.

If a resource has a write lock named "." with token "L", in order to modify
the body or dead properties of that resource, a request MUST specify token
"L" in an IF header and the request principal must be the principal that
created the lock.

**************************

OK, Jason, Yaron, Eric, et. al, what did I forget this time? (:-)

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Thu Jan 13 14:33:49 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24285
	for <webdav-archive@odin.ietf.org>; Thu, 13 Jan 2000 14:33:46 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA12063;
	Thu, 13 Jan 2000 14:16:49 -0500 (EST)
Resent-Date: Thu, 13 Jan 2000 14:16:49 -0500 (EST)
Resent-Message-Id: <200001131916.OAA12063@www19.w3.org>
From: ccjason@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
cc: w3c-dist-auth@w3.org
Message-ID: <85256865.0069D72C.00@D51MTA03.pok.ibm.com>
Date: Thu, 13 Jan 2000 14:15:39 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3819
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


Wow.  This is dense.  Here goes...


   GULP: Part II

   - A URL identifies a resource.

Cool. I notice there is no mention of null resources.  Perhaps that's
intentional?


   - A lock is on a URL. Every lock has a lock token and a lock owner.

  Every lock on a resource has a name which is a relative URL (i.e. a slash
  separated sequence of URL segments). Every LOCK request that succeeds
  results in a new globally unique lock token. Every lock token has an
owner
  that is the principal of the LOCK request.

Just vocab.  "Name" doesn't seem to be the right word.  I'd expect a "name"
to be unique and be equivalent to a token.  -- Otherwise, A-OK.

  - A LOCK request creates a lock on the request URL.

  When a request of the form "LOCK /pathX" succeeds, a lock named "pathY/."
  with a new lock token is added to the resource identified by "/", where
  "pathY" is the result of applying standard URL path transformations to
  remove all segments named "." or ".." from "pathX". If a collection C has
a
  binding from "segX" to resource R, and a request adds a lock named
  "segX/pathZ" with token "L" to C, then the request adds a lock named
"pathZ"
  with token "L" to R. Similarly, if a collection C has a lock named
  "segX/pathZ" with token "L", and a request (e.g. PUT, COPY, MOVE, BIND)
adds
  a binding in C from "segX" to resource R, then the request adds a lock
named
  "pathZ" with token "L" to R. If the attempt to add the lock named "pathZ"
to
  R fails, the request MUST fail.

I'd prefer not to say the lock is on a URL, but hey, let's give it a
shot....  Oh..
I think I understand what you mean by that. The phrase just threw me off.
You are
talking about what Eric calls namespace locks.

All this does ring of implementation rather than model.  You're basically
describing
how URI protection would have to be implemented to be efficient.  For this
reason,
there is a lot of detail here.  Mention and emphasis of the overall effect
would be
good: URI protection.



   - An UNLOCK request removes all locks with the specified lock token.

   When a request of the form "UNLOCK /pathX; Lock-Token L" succeeds, then
the
   lock with token "L" is removed from the resource identified by "/". If a
   collection C has a binding from "segX" to resource R, and a request
removes
   a lock named "segX/pathZ" with token "L" from C, then the request
removes a
   lock named "pathZ" with token "L" from R.

Hmm.  Couldn't you just say that the lock with token L is removed
everywhere
it existed?  At least as a summary statement?  This rings of implemenation
again.

   Similarly, if a collection has a
   lock named "segX/pathZ" with token "L", and a request (e.g. DELETE,
MOVE)
   removes a binding in C from "segX" to resource R, then a lock named
"pathZ"
   with token "L" is removed from R.

This should be a different bullet. -- Also, we seem to talk of specific
situations.
If so, doesn't the above descriptions also cover the situation for
descendents of
R (assuming R is a collection)?

   - A lock on a URL protects which resource is identified by that URL.

   If a collection identified by the URL "/colX" contains a lock named
"pathZ"
   with token "L", if a request would change the resource identified by
   "/colX/pathZ", the request MUST specify token "L" in an IF header and
the
   request principal MUST be the owner of token "L".

OK.  The "lock on URL" phrase threw me off again, but the details sound
right.

Does this include null mapped resources?  Or are we leaving that issue out
for
now?

Note: this only protects the mapping of the resource explicitly locked.
Not
*necessarily* any of the bindings to the root.  Just an observation.  Later
we might have to decide to allow servers to also protect those bindings if
they wish.

If this is the way we're going to describe the semantics we want, will we
later need to use "If there exists..." type phrasing?

You don't say what will happen if the request does include all the right
tokens and the sumitter is the owner of all those tokens.  That is the
main area where recent proposals semantically distinguish themselves.


  - A Depth:N lock on a URL locks any URL that extends the locked URL by no
  more than N segments.

  If a collection C has a binding to resource R, and a request adds a
Depth:N
  lock named "." with token "L" to C, then the request adds a Depth:N-1
lock
  named "." with token "L" to R. Similarly, if a collection C has a Depth:N
  lock named "." with token "L", and a request adds a binding in C to
resource
  R, then the request adds a Depth:N-1 lock named "." with token "L" to R.
If
  the attempt to add the lock named "." to R fails, the request MUST fail.
  Conversely, the Depth:N-1 lock is removed from R whenever a binding to R
or
  the Depth:N lock is removed from C.

Dynamic depth lccks.  Okay.

I guess technically you have declare what happens at depth 0.




  - A Depth:infinity lock on a URL locks all URL's that extend the locked
URL.

  If a collection C has a binding to resource R, and a request adds a
  Depth:infinity lock named "." with token "L" to C, and this is the first
  Depth:infinity lock named "." with token "L" on C, then the request adds
a
  Depth:infinity lock named "." with token "L" to R. Similarly, if a
  collection C has a Depth:infinity lock named "." with token "L", and a
  request adds a binding in C to resource R, then the request adds a
  Depth:infinity lock named "." with token "L" to R. If the attempt to add
the
  lock named "." to R fails, the request MUST fail.

  If a collection C has a
  binding to resource R, and a request removes the last Depth:infinity lock
  named "." with token "L" from C, then the request removes a
Depth:infinity
  lock named "." with token "L" from R. Similarly, if a collection has a
  Depth:infinity lock named "." with token "L", and a request removes a
  binding in C to resource R, then a Depth:infinity lock named "." with
token
  "L" is removed from R.

Sounds like this wording also handles the recursive removal of locks from
the whole tree.  Good.  -- There is a bit of messiness dealing with loops
I think.  If didn't couch this all in detailed implementation based way,
we might not have to mention that.

BTW, you speak of the "*last* Depth:infinity lock".  What is the
significance of "last".  (I also notice you mentioning "first" earlier.)

  Note that multiple Depth:infinity locks named "."
  with the same token can be placed on the same resource due to multiple
  bindings to that resource in a Depth:infinity locked collection.

Right.  IOW, "do the right thing". :-)



  - If an exclusive lock identifies a resource, no other lock of that type
can
  identify that resource.

  If a request attempts to add a lock named "pathZ" with token "L" and type
T
  to resource R, and R already has an exclusive lock named "pathZ" with
type
  "L" but with a different token, the request MUST fail. Similarly, if a
  request attempts to add an exclusive lock named "pathZ" with token "L"
and
  type T to resource R, and R already has a lock named "pathZ" with type T
but
  with a different token, the request MUST fail.

Hmmm. Exclusivenss of exclusive locks also apply to the name space aspect
of
the lock?  This isn't good.  It means only one exclusive lock can exist in
the
system at a time.  I'd prefer the lock to be shared unless the resource is
at
a lock URI.  (Resource Lock, not Namespace lock)

  - A write-lock on a URL protects the body and dead properties of any
  resource identified by that URL.

  If a resource has a write lock named "." with token "L", in order to
modify
  the body or dead properties of that resource, a request MUST specify
token
  "L" in an IF header and the request principal must be the principal that
  created the lock.

So we now need to define "lock".  Based on how you are using it in this
document,
a LOCK request can create many locks.  And all of those locks will
basically have
the "same" (expanded) name.  Except if it's a depth lock in which case
there might
be a lot of locks with "." as their name so their "expanded" names will
differ.
Anyway, my point here is that a LOCK request creates many "lock"s.  If you
couch
it as you have, I think you're obligated to use Eric's "lock set" term.

You haven't really said what happens in null mapped URI space.  The actual
document
might not need to mention it, but since we've talked a lot about it, you
probably
should clarify that for us on the list.

   OK, Jason, Yaron, Eric, et. al, what did I forget this time? (:-)

Well, overall my impression is that the semantics outlined here so far are
good, but that the explanation is very dense and that it probably
doesn't need to be.   Although a few of the semantic details are differnt,
Eric's way of describing it might be a LOT simplier.  Perhaps starting with
Eric's proposal and altering that match your semantics might work better.


Jason.





From w3c-dist-auth-request@w3.org  Thu Jan 13 16:02:08 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25187
	for <webdav-archive@odin.ietf.org>; Thu, 13 Jan 2000 16:02:06 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA15870;
	Thu, 13 Jan 2000 15:47:10 -0500 (EST)
Resent-Date: Thu, 13 Jan 2000 15:47:10 -0500 (EST)
Resent-Message-Id: <200001132047.PAA15870@www19.w3.org>
Message-ID: <007401bf5e07$4771de10$9a114498@us.oracle.com>
From: "Eric Sedlar" <esedlar@us.oracle.com>
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>, <w3c-dist-auth@w3.org>
References: <10001122312.AA22058@tantalum>
Date: Thu, 13 Jan 2000 12:46:34 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Subject: Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3820
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

This is pretty dense, but let me see if I get the gist of how your proposal
differs from mine:

You want to avoid having name and resource locks as separate entities, so
you basically say that a name lock (as in my proposal) locks the resource it
is bound to, if any.  If the lock is exclusive, you can't lock any other
name applied to that resource.  For example, if I have /a/foo.html and
/b/foo.html both identifying the same resource, if I exclusive lock
/a/foo.html, I can't protect the name "/b/foo.html" since I can't lock it.

Since the LOCK protocol request currently doesn't distinguish between name
and resource locks, you couldn't lock /b/foo.html anyway (which is why you
are ok with the restriction above), since the protocol request would try to
lock the resource identified by /b/foo.html as well as the name.

However, it does seem like there will be reasons to protect the namespace in
this way, and I think you are paying a price for reducing the number of
locks.

> - If an exclusive lock identifies a resource, no other lock of that type
can
> identify that resource.

Here's a scenario: it seems like if application A has an exclusive lock on
/a/foo.html (say because it is planning on updating the resource to create a
new version, and it wants to prevent lost updates) and application B wants
to only read /b/foo.html and protect the namespace so that it can find it
again later, application B cannot create a shared lock on /b/foo.html,
correct?  The problem is that application A will not actually update the
resource that app B is working with--it will just create a new revision.
(Although this may affect the revision selected by app B).  Is this an issue
your versioned locks deal with?

--Eric

----- Original Message -----
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: <w3c-dist-auth@w3.org>
Sent: Wednesday, January 12, 2000 3:12 PM
Subject: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)


>
> Eric suggests that a URL-based locking model should be mapped into the
> underlying collection resources that implement the namespace.  I agree
> with both this conclusion and the reasoning leading up to it.
>
> But I think it is simpler to model namespace protection and state
> protection as being two results of a single kind of lock, as opposed
> to the result of two different kinds of locks.  This avoids the
> problem of describing how namespace locks and state locks interact.
>
> In an attempt to make the proposal both understandable and complete,
> I've broken it into two parts.  The first part is a series of bullets,
> which largely correspond to the "URL-based locking" proposal I mailed out
> a while ago.  The second part is the same series of bullets fleshed out
> with a more formal description of each bullet in terms of an underlying
> resource model and effects on the visible lock state of resources.
>
> **************************
>
> GULP: Part I
>
> - A URL identifies a resource.
> - A LOCK request creates a lock on the request URL.
> - An UNLOCK request removes all locks with the specified lock token.
> - A lock on a URL protects which resource is identified by that URL.
> - A Depth:N lock on a URL locks any URL that extends the locked URL by no
> more than N segments.
> - A Depth:infinity lock on a URL locks all URL's that extend the locked
URL.
> - If an exclusive lock identifies a resource, no other lock of that type
can
> identify that resource.
> - A write-lock on a URL protects the body and dead properties of any
> resource identified by that URL.
>
> **************************
>
> GULP: Part II
>
> - A URL identifies a resource.
>
> The URL "/" identifies a resource. A collection contains a set of
bindings,
> where a binding is a mapping from a URL segment to a resource. If "/path"
> identifies a collection C, and C contains a binding that maps the segment
> "x" to resource R, then the URL "/path/x" identifies resource R.
>
> - A lock is on a URL. Every lock has a lock token and a lock owner.
>
> Every lock on a resource has a name which is a relative URL (i.e. a slash
> separated sequence of URL segments). Every LOCK request that succeeds
> results in a new globally unique lock token. Every lock token has an owner
> that is the principal of the LOCK request.
>
> - A LOCK request creates a lock on the request URL.
>
> When a request of the form "LOCK /pathX" succeeds, a lock named "pathY/."
> with a new lock token is added to the resource identified by "/", where
> "pathY" is the result of applying standard URL path transformations to
> remove all segments named "." or ".." from "pathX". If a collection C has
a
> binding from "segX" to resource R, and a request adds a lock named
> "segX/pathZ" with token "L" to C, then the request adds a lock named
"pathZ"
> with token "L" to R. Similarly, if a collection C has a lock named
> "segX/pathZ" with token "L", and a request (e.g. PUT, COPY, MOVE, BIND)
adds
> a binding in C from "segX" to resource R, then the request adds a lock
named
> "pathZ" with token "L" to R. If the attempt to add the lock named "pathZ"
to
> R fails, the request MUST fail.
>
> - An UNLOCK request removes all locks with the specified lock token.
>
> When a request of the form "UNLOCK /pathX; Lock-Token L" succeeds, then
the
> lock with token "L" is removed from the resource identified by "/". If a
> collection C has a binding from "segX" to resource R, and a request
removes
> a lock named "segX/pathZ" with token "L" from C, then the request removes
a
> lock named "pathZ" with token "L" from R. Similarly, if a collection has a
> lock named "segX/pathZ" with token "L", and a request (e.g. DELETE, MOVE)
> removes a binding in C from "segX" to resource R, then a lock named
"pathZ"
> with token "L" is removed from R.
>
> - A lock on a URL protects which resource is identified by that URL.
>
> If a collection identified by the URL "/colX" contains a lock named
"pathZ"
> with token "L", if a request would change the resource identified by
> "/colX/pathZ", the request MUST specify token "L" in an IF header and the
> request principal MUST be the owner of token "L".
>
> - A Depth:N lock on a URL locks any URL that extends the locked URL by no
> more than N segments.
>
> If a collection C has a binding to resource R, and a request adds a
Depth:N
> lock named "." with token "L" to C, then the request adds a Depth:N-1 lock
> named "." with token "L" to R. Similarly, if a collection C has a Depth:N
> lock named "." with token "L", and a request adds a binding in C to
resource
> R, then the request adds a Depth:N-1 lock named "." with token "L" to R.
If
> the attempt to add the lock named "." to R fails, the request MUST fail.
> Conversely, the Depth:N-1 lock is removed from R whenever a binding to R
or
> the Depth:N lock is removed from C.
>
> - A Depth:infinity lock on a URL locks all URL's that extend the locked
URL.
>
> If a collection C has a binding to resource R, and a request adds a
> Depth:infinity lock named "." with token "L" to C, and this is the first
> Depth:infinity lock named "." with token "L" on C, then the request adds a
> Depth:infinity lock named "." with token "L" to R. Similarly, if a
> collection C has a Depth:infinity lock named "." with token "L", and a
> request adds a binding in C to resource R, then the request adds a
> Depth:infinity lock named "." with token "L" to R. If the attempt to add
the
> lock named "." to R fails, the request MUST fail. If a collection C has a
> binding to resource R, and a request removes the last Depth:infinity lock
> named "." with token "L" from C, then the request removes a Depth:infinity
> lock named "." with token "L" from R. Similarly, if a collection has a
> Depth:infinity lock named "." with token "L", and a request removes a
> binding in C to resource R, then a Depth:infinity lock named "." with
token
> "L" is removed from R. Note that multiple Depth:infinity locks named "."
> with the same token can be placed on the same resource due to multiple
> bindings to that resource in a Depth:infinity locked collection.
>
> - If an exclusive lock identifies a resource, no other lock of that type
can
> identify that resource.
>
> If a request attempts to add a lock named "pathZ" with token "L" and type
T
> to resource R, and R already has an exclusive lock named "pathZ" with type
> "L" but with a different token, the request MUST fail. Similarly, if a
> request attempts to add an exclusive lock named "pathZ" with token "L" and
> type T to resource R, and R already has a lock named "pathZ" with type T
but
> with a different token, the request MUST fail.
>
> - A write-lock on a URL protects the body and dead properties of any
> resource identified by that URL.
>
> If a resource has a write lock named "." with token "L", in order to
modify
> the body or dead properties of that resource, a request MUST specify token
> "L" in an IF header and the request principal must be the principal that
> created the lock.
>
> **************************
>
> OK, Jason, Yaron, Eric, et. al, what did I forget this time? (:-)
>
> Cheers,
> Geoff
>
>



From w3c-dist-auth-request@w3.org  Thu Jan 13 17:06:52 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25824
	for <webdav-archive@odin.ietf.org>; Thu, 13 Jan 2000 17:06:49 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id QAA17612;
	Thu, 13 Jan 2000 16:53:52 -0500 (EST)
Resent-Date: Thu, 13 Jan 2000 16:53:52 -0500 (EST)
Resent-Message-Id: <200001132153.QAA17612@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: WebDAV WG <w3c-dist-auth@w3.org>
Date: Thu, 13 Jan 2000 13:50:11 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJIEOHCLAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: Reminder: WG Last Call, Bindings Protocol
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3821
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

This is a reminder that we are about 2/3 of the way through a working group
last call for comments period on the WebDAV Bindings Protocol specification:

<draft-ietf-webdav-binding-protocol-02>
http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-binding-
protocol-02

The last call period ends January 24, 2000, at midnight, Pacific time.  The
intent of the last call period is to allow working group members to perform
a final review of the specification before it is submitted to the IESG for
approval as a Proposed Standard.

For more details on the last call, please consult the original message
announcing the start of the last call period:

http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0337.html

- Jim Whitehead
Chair, IETF WebDAV Working Group




From w3c-dist-auth-request@w3.org  Thu Jan 13 17:44:14 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26029
	for <webdav-archive@odin.ietf.org>; Thu, 13 Jan 2000 17:44:14 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id RAA00037;
	Thu, 13 Jan 2000 17:33:33 -0500 (EST)
Resent-Date: Thu, 13 Jan 2000 17:33:33 -0500 (EST)
Resent-Message-Id: <200001132233.RAA00037@www19.w3.org>
From: ccjason@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: "Eric Sedlar" <esedlar@us.oracle.com>
cc: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>, w3c-dist-auth@w3.org
Message-ID: <85256865.007BDF15.00@D51MTA03.pok.ibm.com>
Date: Thu, 13 Jan 2000 17:32:36 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3822
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


Ah... Eric's note brings up another possibility.  It might be a red
herring, but as Geoff's
proposal is currently written (and Eric's too I think) it still is a
possibly unexpected behavior.

User B  locks /a/b/ exclusively.

User D tries to do a shared lock on /a/b/c/d.html but fails because in the
proposal that
will also create a lock (or will it?) on /a/b/ which already has an
exclusive lock on it.

I'm not saying this is good or bad.  I'm just pointing it out as what
sounds like a difference
in the recent proposals relative to what we were proposing a month or more
ago.

Jason.




From w3c-dist-auth-request@w3.org  Thu Jan 13 20:17:41 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26971
	for <webdav-archive@odin.ietf.org>; Thu, 13 Jan 2000 20:17:40 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA12878;
	Thu, 13 Jan 2000 20:06:29 -0500 (EST)
Resent-Date: Thu, 13 Jan 2000 20:06:29 -0500 (EST)
Resent-Message-Id: <200001140106.UAA12878@www19.w3.org>
Date: Thu, 13 Jan 2000 20:06:23 -0500
Message-Id: <10001140106.AA22868@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <85256865.0069D72C.00@D51MTA03.pok.ibm.com> (ccjason@us.ibm.com)
Subject: Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3823
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

First, thanks for the prompt review!  Based on Jason's comments, I will
rewrite the "headers", write a few key examples, and will give each of
the "rules" a number, so that I can explain the example by reference to
which rule produces the behavior in the example.

I will make no changes to the actual rules, so there will be no semantic
changes in this rewrite.

And now for a few responses:

   From: ccjason@us.ibm.com

      GULP: Part II

      - A URL identifies a resource.

   Cool. I notice there is no mention of null resources.  Perhaps that's
   intentional?

I'll change this to say "A URL can identify a resource".
I did not intend to imply that all URL's identify a resource.
This model does not have the notion of a null resource.

      - A lock is on a URL. Every lock has a lock token and a lock owner.

     Every lock on a resource has a name which is a relative URL (i.e. a slash
     separated sequence of URL segments). Every LOCK request that succeeds
     results in a new globally unique lock token. Every lock token has an owner
     that is the principal of the LOCK request.

   Just vocab.  "Name" doesn't seem to be the right word.  I'd expect a "name"
   to be unique and be equivalent to a token.  -- Otherwise, A-OK.

I'm open to whatever term folks prefer.  All that really matters is
that it be a string which has relative URL syntax.

     - A LOCK request creates a lock on the request URL.
     When a request of the form "LOCK /pathX" succeeds, a lock named "pathY/."
     with a new lock token is added to the resource identified by "/", where
     "pathY" is the result of applying standard URL path transformations to
     remove all segments named "." or ".." from "pathX". If a collection C has a
     binding from "segX" to resource R, and a request adds a lock named
     "segX/pathZ" with token "L" to C, then the request adds a lock named "pathZ"
     with token "L" to R. Similarly, if a collection C has a lock named
     "segX/pathZ" with token "L", and a request (e.g. PUT, COPY, MOVE, BIND) adds
     a binding in C from "segX" to resource R, then the request adds a lock named
     "pathZ" with token "L" to R. If the attempt to add the lock named "pathZ" to
     R fails, the request MUST fail.

   I'd prefer not to say the lock is on a URL, but hey, let's give it a
   shot....  Oh..  I think I understand what you mean by that. The phrase
   just threw me off.  You are talking about what Eric calls namespace
   locks.

The only sense in which there are two kinds of locks in this model is
that locks named "." have some additional properties, but the
preceding paragraph applies to *all* locks, not just locks named "."

   All this does ring of implementation rather than model.  You're
   basically describing how URI protection would have to be implemented
   to be efficient.

How this is implemented is completely up to the server.  This is
intended to define the effect of locking in terms of resource
properties visible via the protocol.  These semantics describe both
under what conditions a request MUST fail, and what the state on the
server will be following a successful request.

   For this reason, there is a lot of detail here.
   Mention and emphasis of the overall effect would be good: URI
   protection.

That comes later.  This is just a detailed description of how the
locking properties must appear on the server following various
operations.  This is modeled in terms of the underlying binding
model instead of trying to enumerate all WebDAV methods, in order
to provide guidance when new methods are defined.  This way,
you can just look at the effect of a new method on the binding model,
and conclude what the locking effect will be, rather than having
to reconvene the locking working group whenever a new method is
added to HTTP.

      - An UNLOCK request removes all locks with the specified lock token.

      When a request of the form "UNLOCK /pathX; Lock-Token L" succeeds, then the
      lock with token "L" is removed from the resource identified by "/". If a
      collection C has a binding from "segX" to resource R, and a request removes
      a lock named "segX/pathZ" with token "L" from C, then the request removes a
      lock named "pathZ" with token "L" from R.

   Hmm.  Couldn't you just say that the lock with token L is removed
   everywhere it existed?  At least as a summary statement?  This rings
   of implemenation again.

That statement only applies to the UNLOCK request.  The second
sentence applies to all methods that result in a lock being removed,
whether it is from an UNLOCK, a DELETE, a MOVE, or some new method not
yet defined.

      Similarly, if a collection has a
      lock named "segX/pathZ" with token "L", and a request (e.g. DELETE, MOVE)
      removes a binding in C from "segX" to resource R, then a lock named "pathZ"
      with token "L" is removed from R.

   This should be a different bullet.

I intended this bullet to be about lock removal in general, not just about
the UNLOCK command.  I'll retitle this section: "A lock can be removed from a
resource by UNLOCK or by removing a resource from a locked
collection."

   Also, we seem to talk of specific situations.

If you can think of a situation this doesn't cover, please let me know.
The wording here was intended to be the minimal number of rules that
completely define the semantics.

   If so, doesn't the above descriptions also cover
   the situation for descendents of R (assuming R is a collection)?

Yes, it does.  (All of these rules are applied recursively).

      - A lock on a URL protects which resource is identified by that URL.

      If a collection identified by the URL "/colX" contains a lock named "pathZ"
      with token "L", if a request would change the resource identified by
      "/colX/pathZ", the request MUST specify token "L" in an IF header and the
      request principal MUST be the owner of token "L".

   OK.  The "lock on URL" phrase threw me off again, but the details
   sound right.

   Does this include null mapped resources? 

Definitely yes!  (That was one of the interesting challenges :-).

   Note: this only protects the mapping of the resource explicitly
   locked.  Not *necessarily* any of the bindings to the root.  Just an
   observation.   Later we might have to decide to allow servers to also
   protect those bindings if they wish.

It is designed to protect all the bindings from the resource to the
root.  Can you come up with an example of how a binding could be removed
without violating one of the rules?

   If this is the way we're going to describe the semantics we want, will
   we later need to use "If there exists..." type phrasing?

Shouldn't have to.  Let me know if you have an example where you think
the current semantics aren't sufficient.

   You don't say what will happen if the request does include all the
   right tokens and the sumitter is the owner of all those tokens.  That
   is the main area where recent proposals semantically distinguish
   themselves.

Actually, this proposal very carefully deals only with the lock
state of properties, the two locking operations (LOCK and UNLOCK),
and when a method will fail because of violating a lock.  The semantics
of non-locking methods is left undefined except where it results in
a modification to the lock state of a resource.

     - A Depth:N lock on a URL locks any URL that extends the locked URL by no
     more than N segments.

     If a collection C has a binding to resource R, and a request adds a Depth:N
     lock named "." with token "L" to C, then the request adds a Depth:N-1 lock
     named "." with token "L" to R. Similarly, if a collection C has a Depth:N
     lock named "." with token "L", and a request adds a binding in C to resource
     R, then the request adds a Depth:N-1 lock named "." with token "L" to R. If
     the attempt to add the lock named "." to R fails, the request MUST fail.
     Conversely, the Depth:N-1 lock is removed from R whenever a binding to R or
     the Depth:N lock is removed from C.

   Dynamic depth lccks.  Okay.
   I guess technically you have declare what happens at depth 0.

Shouldn't have to.  Just substitute "0" for N in the above paragraph,
and you know what happens at depth 0.  Only "infinity" is special.

     - A Depth:infinity lock on a URL locks all URL's that extend the locked
   URL.

     If a collection C has a binding to resource R, and a request adds a
     Depth:infinity lock named "." with token "L" to C, and this is the first
     Depth:infinity lock named "." with token "L" on C, then the request adds a
     Depth:infinity lock named "." with token "L" to R. Similarly, if a
     collection C has a Depth:infinity lock named "." with token "L", and a
     request adds a binding in C to resource R, then the request adds a
     Depth:infinity lock named "." with token "L" to R. If the attempt to add the
     lock named "." to R fails, the request MUST fail.

     If a collection C has a
     binding to resource R, and a request removes the last Depth:infinity lock
     named "." with token "L" from C, then the request removes a Depth:infinity
     lock named "." with token "L" from R. Similarly, if a collection has a
     Depth:infinity lock named "." with token "L", and a request removes a
     binding in C to resource R, then a Depth:infinity lock named "." with token
     "L" is removed from R.

   Sounds like this wording also handles the recursive removal of locks
   from the whole tree.  Good.  -- There is a bit of messiness dealing
   with loops I think.  If didn't couch this all in detailed
   implementation based way, we might not have to mention that.

I continue to maintain that this is pure semantics (albeit described
in the form of state transition rules).  Getting the semantics to handle loops
was one of the hardest parts of this protocol.  If I got it wrong,
let me know.

   BTW, you speak of the "*last* Depth:infinity lock".  What is the
   significance of "last".  (I also notice you mentioning "first"
   earlier.)

You can have multiple occurrences of the same lock on a resource.
Certain state changes occur only on the first application of a given
lock to a resource, and on the removal of the last occurrence of a
given lock on a resource.

     Note that multiple Depth:infinity locks named "."
     with the same token can be placed on the same resource due to multiple
     bindings to that resource in a Depth:infinity locked collection.

   Right.  IOW, "do the right thing". :-)

Actually, this was intended to be a pre-emptive answer to the question
you raised above (:-).  In particular, it is wrong to not add a lock to
a resource because one like it is already there (i.e. it is not a set).

     - If an exclusive lock identifies a resource, no other lock of that type can
     identify that resource.

     If a request attempts to add a lock named "pathZ" with token "L" and type T
     to resource R, and R already has an exclusive lock named "pathZ" with type
     "L" but with a different token, the request MUST fail. Similarly, if a
     request attempts to add an exclusive lock named "pathZ" with token "L" and
     type T to resource R, and R already has a lock named "pathZ" with type T but
     with a different token, the request MUST fail.

   Hmmm. Exclusivenss of exclusive locks also apply to the name space
   aspect of the lock?  This isn't good.

I'm not sure what you mean by this.  In particular, what do you mean
by the "name space aspect of a lock"?

   It means only one exclusive
   lock can exist in the system at a time.

How so?  You can get an exclusive lock conflict only if there are
two locks on the same resource *and* they are of the same type 
*and* they have the same name *and* they have different tokens
*and* one of them is exclusive.  That leaves room for lots of exclusive
locks.

   I'd prefer the lock to be
   shared unless the resource is at a lock URI.  (Resource Lock, not
   Namespace lock)

Just one kind of lock, but each lock has a "name" and exclusive locks
don't conflict unless they have the same name.

     - A write-lock on a URL protects the body and dead properties of any
     resource identified by that URL.

     If a resource has a write lock named "." with token "L", in order to modify
     the body or dead properties of that resource, a request MUST specify token
     "L" in an IF header and the request principal must be the principal that
     created the lock.

   So we now need to define "lock".  Based on how you are using it in
   this document, a LOCK request can create many locks.

Yes.

   And all of those
   locks will basically have the "same" (expanded) name.

There is no concept of an "expanded" lock name.  A lock has exactly
one name (just as it has one token and one type and one owner).

   Except if it's
   a depth lock in which case there might be a lot of locks with "." as
   their name so their "expanded" names will differ.

Yes, there will be a lot of locks with "." as their name
(for a given resource, locks will differ in their token, unless
they are shared locks).

   Anyway, my point
   here is that a LOCK request creates many "lock"s.  If you couch it as
   you have, I think you're obligated to use Eric's "lock set" term.

I haven't found the need to do so.  I can just say "all locks with the
same token" if I need to refer to that set (and I only needed to do
so for the UNLOCK definition).

   You haven't really said what happens in null mapped URI space.

Actually, I have (:-).  Run through the rules for a URL that does
not (currently) identify a resource, and all should work.

   The
   actual document might not need to mention it, but since we've talked a
   lot about it, you probably should clarify that for us on the list.

Yes, and example is clearly called for.

      OK, Jason, Yaron, Eric, et. al, what did I forget this time? (:-)

   Well, overall my impression is that the semantics outlined here so far
   are good, but that the explanation is very dense and that it probably
   doesn't need to be.

I believe that you couldn't delete any of the rules without losing
some key semantics.  I'm always interested in seeing alternative
formulations, though.  (Then I can take the potshots :-).

   Although a few of the semantic details are
   differnt, Eric's way of describing it might be a LOT simplier.

Eric's description did not handle cyclic bindings, some of the
subtler cases of locks on URL's not bound to resources, or of the
behavior of LOCK's when the state of collections are modified.
That does make it simpler (:-).

   Perhaps starting with Eric's proposal and altering that match your
   semantics might work better.

Anything that gets us to a complete and understandable set of
semantics works for me!

Cheers,
Geoff





From w3c-dist-auth-request@w3.org  Thu Jan 13 20:17:45 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26982
	for <webdav-archive@odin.ietf.org>; Thu, 13 Jan 2000 20:17:45 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA12923;
	Thu, 13 Jan 2000 20:07:02 -0500 (EST)
Resent-Date: Thu, 13 Jan 2000 20:07:02 -0500 (EST)
Resent-Message-Id: <200001140107.UAA12923@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>, w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at gremlin-relay.ics.uci.edu
Date: Thu, 13 Jan 2000 17:03:15 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJKEOOCLAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <10001122312.AA22058@tantalum>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: RE: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3824
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

A problem with this proposal (and, to be fair, the same problem is shared by
RFC 2518) is it never defines what a lock *is*. That is, there is no
sentence here that begins, "A lock is a ...". As a result, this makes it
hard to assess whether statements such as the following make sense: "A lock
is on a URL. Every lock has a lock token and a lock owner."

Initially, a lock was a metaphor, extending the meaning of real-world locks
into the realm of computer data.  Real-world locks have several properties.
They have mass and volume.  That is, there is a physical lock mechanism that
takes up space, and hence be located someplace.  Examples are a lock set
into a door, and a padlock, where the lock is separate from the thing being
locked, and is connected by hooks, or a chain. Locks also have some way to
open them, and provide access to the locked item, either via a key, or a
combination.  When locking a volume of space, such as a room, it is possible
to simultaneously lock people out (prevent access), and lock people in
(guarantee exclusive access).  Ownership of a real world lock is separate
from the ability to lock and unlock it.  While typically the owner of a lock
also has the ability to lock and unlock it, there are often others who have
the same ability. Think of your office door -- you probably don't own the
door, but you can unlock it.

A WebDAV lock is an abstraction that arbitrates operations on resources. A
WebDAV write lock simultaneously guarantees that only the lock owner (or
owners, in the case of a shared lock), can write to the resource, and that
non-lock-owners are prevented from writing to the resource. Lock ownership
in WebDAV is synonymous having the ability to perform the lock-arbitrated
operation and unlock the locked resource.

WebDAV locks have state, the equivalent to mass and volume for real-world
locks.  The only description of the state of a lock in RFC 2518 can be found
in the lock discovery property, which gives the state of a lock as
containing:

  - lock type
  - lock scope
  - lock depth
  - lock timeout time
  - lock token
  - lock owner
  - lock URL (implicit)

For any stateful abstraction, such as a lock, there are several meaningful
questions.  Is the abstraction a first-class object?  That is, is its state
and existence independent of other system objects, and does it have its own
independent identity?  Or is the abstraction a component of some other
object.  Following the real-world lock analogy, is the lock more akin to a
padlock, independent of the items being locked, or a door lock, where the
lock is a component of the door.

So far in WebDAV, lock state has been part of a resource, since resources
are the only stateful objects in HTTP.  The GULP proposal, with statements
like, "a LOCK request creates a lock on the request URL," seems to imply
that lock state is part of a URL.  This is a troubling assertion since URLs
have not, to date, been stateful objects.  But, a further examination of
GULP (in the section "a LOCK request creates a lock on the request URL")
shows that the lock state is kept on the locked resource's collection, and
perhaps on the locked resource as well. Thus the lock is not "on" the URL at
all, but is instead on the locked resource's parent collection, and on the
resource.  The lock certaintly affects the URL, but it isn't "on" the URL.

Having the lock state as part of the collection is troublesome, since it
implies that only WebDAV resources inside WebDAV collections may be locked.
This is an additional (and unnecessary) restriction over anything specified
in RFC 2518.  Furthermore, duplicating the lock state in the resource and
its parent collection seems unnecessary.

So, before we proceed, I would like to see a definition of a lock that
begins with "A lock is a ...", and I'd like to see a better description of
what constitutes the state of a lock, and where this state is kept.
Answering these questions will help clarify the rest of the semantics
described in the GULP proposal.

- Jim


> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Geoffrey M. Clemm
> Sent: Wednesday, January 12, 2000 3:13 PM
> To: w3c-dist-auth@w3.org
> Subject: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)
>
>
>
> Eric suggests that a URL-based locking model should be mapped into the
> underlying collection resources that implement the namespace.  I agree
> with both this conclusion and the reasoning leading up to it.
>
> But I think it is simpler to model namespace protection and state
> protection as being two results of a single kind of lock, as opposed
> to the result of two different kinds of locks.  This avoids the
> problem of describing how namespace locks and state locks interact.
>
> In an attempt to make the proposal both understandable and complete,
> I've broken it into two parts.  The first part is a series of bullets,
> which largely correspond to the "URL-based locking" proposal I mailed out
> a while ago.  The second part is the same series of bullets fleshed out
> with a more formal description of each bullet in terms of an underlying
> resource model and effects on the visible lock state of resources.
>
> **************************
>
> GULP: Part I
>
> - A URL identifies a resource.
> - A LOCK request creates a lock on the request URL.
> - An UNLOCK request removes all locks with the specified lock token.
> - A lock on a URL protects which resource is identified by that URL.
> - A Depth:N lock on a URL locks any URL that extends the locked URL by no
> more than N segments.
> - A Depth:infinity lock on a URL locks all URL's that extend the
> locked URL.
> - If an exclusive lock identifies a resource, no other lock of
> that type can
> identify that resource.
> - A write-lock on a URL protects the body and dead properties of any
> resource identified by that URL.
>
> **************************
>
> GULP: Part II
>
> - A URL identifies a resource.
>
> The URL "/" identifies a resource. A collection contains a set of
> bindings,
> where a binding is a mapping from a URL segment to a resource. If "/path"
> identifies a collection C, and C contains a binding that maps the segment
> "x" to resource R, then the URL "/path/x" identifies resource R.
>
> - A lock is on a URL. Every lock has a lock token and a lock owner.
>
> Every lock on a resource has a name which is a relative URL (i.e. a slash
> separated sequence of URL segments). Every LOCK request that succeeds
> results in a new globally unique lock token. Every lock token has an owner
> that is the principal of the LOCK request.
>
> - A LOCK request creates a lock on the request URL.
>
> When a request of the form "LOCK /pathX" succeeds, a lock named "pathY/."
> with a new lock token is added to the resource identified by "/", where
> "pathY" is the result of applying standard URL path transformations to
> remove all segments named "." or ".." from "pathX". If a
> collection C has a
> binding from "segX" to resource R, and a request adds a lock named
> "segX/pathZ" with token "L" to C, then the request adds a lock
> named "pathZ"
> with token "L" to R. Similarly, if a collection C has a lock named
> "segX/pathZ" with token "L", and a request (e.g. PUT, COPY, MOVE,
> BIND) adds
> a binding in C from "segX" to resource R, then the request adds a
> lock named
> "pathZ" with token "L" to R. If the attempt to add the lock named
> "pathZ" to
> R fails, the request MUST fail.
>
> - An UNLOCK request removes all locks with the specified lock token.
>
> When a request of the form "UNLOCK /pathX; Lock-Token L"
> succeeds, then the
> lock with token "L" is removed from the resource identified by "/". If a
> collection C has a binding from "segX" to resource R, and a
> request removes
> a lock named "segX/pathZ" with token "L" from C, then the request
> removes a
> lock named "pathZ" with token "L" from R. Similarly, if a collection has a
> lock named "segX/pathZ" with token "L", and a request (e.g. DELETE, MOVE)
> removes a binding in C from "segX" to resource R, then a lock
> named "pathZ"
> with token "L" is removed from R.
>
> - A lock on a URL protects which resource is identified by that URL.
>
> If a collection identified by the URL "/colX" contains a lock
> named "pathZ"
> with token "L", if a request would change the resource identified by
> "/colX/pathZ", the request MUST specify token "L" in an IF header and the
> request principal MUST be the owner of token "L".
>
> - A Depth:N lock on a URL locks any URL that extends the locked URL by no
> more than N segments.
>
> If a collection C has a binding to resource R, and a request adds
> a Depth:N
> lock named "." with token "L" to C, then the request adds a Depth:N-1 lock
> named "." with token "L" to R. Similarly, if a collection C has a Depth:N
> lock named "." with token "L", and a request adds a binding in C
> to resource
> R, then the request adds a Depth:N-1 lock named "." with token
> "L" to R. If
> the attempt to add the lock named "." to R fails, the request MUST fail.
> Conversely, the Depth:N-1 lock is removed from R whenever a
> binding to R or
> the Depth:N lock is removed from C.
>
> - A Depth:infinity lock on a URL locks all URL's that extend the
> locked URL.
>
> If a collection C has a binding to resource R, and a request adds a
> Depth:infinity lock named "." with token "L" to C, and this is the first
> Depth:infinity lock named "." with token "L" on C, then the request adds a
> Depth:infinity lock named "." with token "L" to R. Similarly, if a
> collection C has a Depth:infinity lock named "." with token "L", and a
> request adds a binding in C to resource R, then the request adds a
> Depth:infinity lock named "." with token "L" to R. If the attempt
> to add the
> lock named "." to R fails, the request MUST fail. If a collection C has a
> binding to resource R, and a request removes the last Depth:infinity lock
> named "." with token "L" from C, then the request removes a Depth:infinity
> lock named "." with token "L" from R. Similarly, if a collection has a
> Depth:infinity lock named "." with token "L", and a request removes a
> binding in C to resource R, then a Depth:infinity lock named "."
> with token
> "L" is removed from R. Note that multiple Depth:infinity locks named "."
> with the same token can be placed on the same resource due to multiple
> bindings to that resource in a Depth:infinity locked collection.
>
> - If an exclusive lock identifies a resource, no other lock of
> that type can
> identify that resource.
>
> If a request attempts to add a lock named "pathZ" with token "L"
> and type T
> to resource R, and R already has an exclusive lock named "pathZ" with type
> "L" but with a different token, the request MUST fail. Similarly, if a
> request attempts to add an exclusive lock named "pathZ" with token "L" and
> type T to resource R, and R already has a lock named "pathZ" with
> type T but
> with a different token, the request MUST fail.
>
> - A write-lock on a URL protects the body and dead properties of any
> resource identified by that URL.
>
> If a resource has a write lock named "." with token "L", in order
> to modify
> the body or dead properties of that resource, a request MUST specify token
> "L" in an IF header and the request principal must be the principal that
> created the lock.
>
> **************************
>
> OK, Jason, Yaron, Eric, et. al, what did I forget this time? (:-)
>
> Cheers,
> Geoff
>



From w3c-dist-auth-request@w3.org  Thu Jan 13 20:43:21 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27118
	for <webdav-archive@odin.ietf.org>; Thu, 13 Jan 2000 20:43:20 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA14051;
	Thu, 13 Jan 2000 20:32:29 -0500 (EST)
Resent-Date: Thu, 13 Jan 2000 20:32:29 -0500 (EST)
Resent-Message-Id: <200001140132.UAA14051@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: WebDAV WG <w3c-dist-auth@w3.org>
Date: Thu, 13 Jan 2000 17:28:48 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJAEPCCLAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: Adelaide/IETF-47
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3825
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

At present, it is my intention to *not* hold a WebDAV working group meeting
in Adelaide, Australia, at IETF-47.  I could potentially be convinced
otherwise, but at present I don't think many WebDAV WG members are intending
on going, due to the expense, and hence I don't think we would get much work
done.

- Jim



From w3c-dist-auth-request@w3.org  Thu Jan 13 20:47:18 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27152
	for <webdav-archive@odin.ietf.org>; Thu, 13 Jan 2000 20:47:18 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA14254;
	Thu, 13 Jan 2000 20:36:33 -0500 (EST)
Resent-Date: Thu, 13 Jan 2000 20:36:33 -0500 (EST)
Resent-Message-Id: <200001140136.UAA14254@www19.w3.org>
Date: Thu, 13 Jan 2000 20:36:25 -0500
Message-Id: <10001140136.AA22895@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <NDBBIKLAGLCOPGKGADOJKEOOCLAA.ejw@ics.uci.edu> (message from Jim
	Whitehead on Thu, 13 Jan 2000 17:03:15 -0800)
Subject: Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3826
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


Basically, I agree with all of Jim's points.  In particular, I'll try
out the "lock is on the resource" approach in the next draft of GULP.
As Jim noted, in GULP the locking semantics *are* in fact all defined
in terms of affect on the states of resources, so the "lock is on a URL"
is at best a metaphor.  So I'll leave the semantics alone, and just
change the metaphor.

I'll also modify the way I refer to a lock in the semantics so that it
always is in the form of a tuple (e.g. [x, y, z]) so it is clearer when
a "lock" appears in the rules.

Finally, I believe it is sufficient to say that "lock discovery only
displays the locks on WebDAV resources", so that the locks on non-WebDAV
collections above the WebDAV are logically there, but you just can't inspect
them with PROPFIND.  (Jim et. al, does this work for you? Or maybe
you can't really say, until you see it written up.)

Cheers,
Geoff


   From: Jim Whitehead <ejw@ics.uci.edu>

   A problem with this proposal (and, to be fair, the same problem is shared by
   RFC 2518) is it never defines what a lock *is*. That is, there is no
   sentence here that begins, "A lock is a ...". As a result, this makes it
   hard to assess whether statements such as the following make sense: "A lock
   is on a URL. Every lock has a lock token and a lock owner."

Good point.  I'll add such a statement in the next rev.

   A WebDAV lock is an abstraction that arbitrates operations on resources. A
   WebDAV write lock simultaneously guarantees that only the lock owner (or
   owners, in the case of a shared lock), can write to the resource, and that
   non-lock-owners are prevented from writing to the resource. Lock ownership
   in WebDAV is synonymous having the ability to perform the lock-arbitrated
   operation and unlock the locked resource.

   WebDAV locks have state, the equivalent to mass and volume for real-world
   locks.  The only description of the state of a lock in RFC 2518 can be found
   in the lock discovery property, which gives the state of a lock as
   containing:

     - lock type
     - lock scope
     - lock depth
     - lock timeout time
     - lock token
     - lock owner
     - lock URL (implicit)

   For any stateful abstraction, such as a lock, there are several meaningful
   questions.  Is the abstraction a first-class object?  That is, is its state
   and existence independent of other system objects, and does it have its own
   independent identity?  Or is the abstraction a component of some other
   object.  Following the real-world lock analogy, is the lock more akin to a
   padlock, independent of the items being locked, or a door lock, where the
   lock is a component of the door.

   So far in WebDAV, lock state has been part of a resource, since resources
   are the only stateful objects in HTTP.  The GULP proposal, with statements
   like, "a LOCK request creates a lock on the request URL," seems to imply
   that lock state is part of a URL.  This is a troubling assertion since URLs
   have not, to date, been stateful objects.  But, a further examination of
   GULP (in the section "a LOCK request creates a lock on the request URL")
   shows that the lock state is kept on the locked resource's collection, and
   perhaps on the locked resource as well. Thus the lock is not "on" the URL at
   all, but is instead on the locked resource's parent collection, and on the
   resource.  The lock certaintly affects the URL, but it isn't "on" the URL.

   Having the lock state as part of the collection is troublesome, since it
   implies that only WebDAV resources inside WebDAV collections may be locked.
   This is an additional (and unnecessary) restriction over anything specified
   in RFC 2518.  Furthermore, duplicating the lock state in the resource and
   its parent collection seems unnecessary.

   So, before we proceed, I would like to see a definition of a lock that
   begins with "A lock is a ...", and I'd like to see a better description of
   what constitutes the state of a lock, and where this state is kept.
   Answering these questions will help clarify the rest of the semantics
   described in the GULP proposal.

   - Jim



From w3c-dist-auth-request@w3.org  Thu Jan 13 21:05:26 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27288
	for <webdav-archive@odin.ietf.org>; Thu, 13 Jan 2000 21:05:26 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA15019;
	Thu, 13 Jan 2000 20:53:29 -0500 (EST)
Resent-Date: Thu, 13 Jan 2000 20:53:29 -0500 (EST)
Resent-Message-Id: <200001140153.UAA15019@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>, w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at gremlin-relay.ics.uci.edu
Date: Thu, 13 Jan 2000 17:49:47 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJIEPFCLAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <10001070353.AA19329@tantalum>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: RE: Anomaly in the DAV:prop element usage
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3827
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

Geoff Clemm writes:

> But
> in those cases where you do have the DTD's available (such as for the
> DAV:xxx properties), it does provide some cognitive dissonance to
> see an element like <DAV:creationdate/> in a PROPFIND request,
> when the DTD for creationdate is:
>    <!ELEMENT creationdate (#PCDATA) >


Actually, in this specific case the XML is valid.  The construction
<element/> is defined to be the same as <element></element> (an element with
no contents).  Since an empty element is consistent with the *DTD* for
creationdate, <creationdate/> is valid.  But, your point still holds for
properties like lockdiscovery, which have a list of subelements as part of
their DTD specification, so my objection is to your example, not to your
general point.  That said, I still think using a list of empty elements is
fine within prop.

- Jim



From w3c-dist-auth-request@w3.org  Fri Jan 14 01:22:55 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02051
	for <webdav-archive@odin.ietf.org>; Fri, 14 Jan 2000 01:22:55 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id BAA19490;
	Fri, 14 Jan 2000 01:12:02 -0500 (EST)
Resent-Date: Fri, 14 Jan 2000 01:12:02 -0500 (EST)
Resent-Message-Id: <200001140612.BAA19490@www19.w3.org>
Date: Fri, 14 Jan 2000 01:11:54 -0500
Message-Id: <10001140611.AA22980@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <NDBBIKLAGLCOPGKGADOJKEOOCLAA.ejw@ics.uci.edu> (message from Jim
	Whitehead on Thu, 13 Jan 2000 17:03:15 -0800)
Subject: GULP, version 2
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3828
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Here is a second version of the GULP.  I've updated the descriptive
text based on the feedback from Jason, Jim, and Eric (not that I've
successfully addressed their issues, but it was based on it :-).
Jason: I'm now using "target" instead of "name" ... let me know if
you think that works better.

The only semantic change has been the deletion of Depth:N behavior,
for N other than 0 and infinity (this brings it more in line with 2518).

I need some more examples, and I still need to address the use cases
raised by Eric and Jason ...  I believe they are handled properly by
the proposal, but I probably should get some sleep first before
working them through (:-).

Cheers,
Geoff


**************************

GULP: Part I

- A URL is a string that can identify a resource.

- A collection is a resource that contains a set of named members.

- A lock is 7-tuple, consisting of a target, token, type, scope,
depth, timeout, and owner.

- Locking a resource means to add a lock to the state of that
resource.

- Unlocking a resource means to remove a lock from the state of that
resource.

- A lock will cause certain requests to fail with a 423 (Locked)
status code, where that request would have succeeded if the lock had
not been present.

- A resource can be locked by multiple locks concurrently.

- One or more resources can be locked with a LOCK request.

- Locking a collection can lock one or more members of that
collection.

- Adding a resource to a locked collectin can lock that resource.

- One or more resources can be unlocked with an UNLOCK request.

- Unlocking a collection can unlock one or more members of that
collection.

- Removing a resource from a locked collection can unlock that resource.

- The depth of a lock can be a 0 or infinity.  If a collection has a
depth infinity lock, all members of that collection are also locked.

- If a member is added to a depth:infinity locked collection, that
member is locked by that depth:infinity lock.

- A lock protects which resource is identified by that lock.

- If a resource has an exclusive lock, that resource cannot be locked
with another lock with the same type and target but a different token.

- If a resource has a write lock with target ".", the body and
properties of that resource are protected from unauthorized
modification.


**************************

GULP: Part II


- A URL is a string that can identify a resource.

A server initially defines what resource (if any) is identified by a
URL.  Most URL's do not identify a resource, but a client can cause
a URL to identify a resource, and later change which resource is
identified by that URL.

Examples of methods that can cause a URL to identify a resource (or
change the resource identified by a URL) are PUT, MKRESOURCE, MKCOL,
BIND, MOVE, and COPY.  Examples of methods that can cause a URL to no
longer identify a resource are DELETE and MOVE.


- A lock is 7-tuple, consisting of a target, token, type, scope, depth,
timeout, and owner.

The "target" is an extension to locks as defined in rfc2518.  This new
field is defined to distinguish the implicit locks on the state of a
collection implied by the locking semantics of rfc2518, from the
explicit locks that are defined by rfc2518.  The explicit locks in
rfc2518 correspond to locks with target "." in this proposal.

Since all locks with the same token will share the same type, scope,
depth, timeout, and owner, a lock will be represented in this proposal
as a string of the form "[target, token]".

For example, ["x/.", "K"] defines a lock with target "x/." and token "K".


- A collection is a resource that contains a set of named members.

A collection contains a set of bindings, where a binding is a mapping
from a URL segment to a resource.  If a URL identifies a collection,
that URL extended by the URL segment will identify the bound resource.

For example, If "/path" identifies a collection C, and C contains a
binding that binds the segment "x" to resource R, then the URL
"/path/x" identifies resource R.


- Locking a resource means to add a lock to the state of that
resource.

The lock is added to the DAV:lockdiscovery property of the resource.


- Unlocking a resource means to remove a lock from the state of that
resource.

The lock is deleted from the DAV:lockdiscovery property of the
resource.


- A lock will cause certain requests to fail with a 423 (Locked)
status code, where that request would have succeeded if the lock had
not been present.

Whether a particular request will fail can depends on the
target, token, type, scope, and owner of the lock.


- A resource can be locked by multiple locks concurrently.

A lock can be locked by multiple locks with different values or
multiple identical locks.  Some lock combinations will be disallowed
based on information such as the the scope of the lock.


- One or more resources can be locked with a LOCK request.

When a LOCK request succeeds, a lock is added to the resource
identified by shortest sequence of initial segments of the request URL
that identifies a WebDAV resource.

The lock target is the relative URL formed by using standard URL
transformations to remove all segments of the request-URL named "." or
"..", then removing the prefix that identifies the locked resource,
and then appending a segment named ".".

For example, if "LOCK /seg1/seg2/seg3/.../segN" succeeds, and if
/seg1 does not identify a WebDAV resource but /seg1/seg2 does,
then a lock with target "seg3/.../segN/." is added to the resource
identified by "/seg1/seg2".

The type and scope, and owner of the lock is specified in the LOCK
request body.  The depth and timeout of the lock is specified in the
LOCK request headers.  The token of the lock is a unique string
allocated for that LOCK request by the server.

The principal that issued the LOCK request is called the "owner" of
the lock.


- Locking a collection can lock one or more members of that collection.

If a collection C has a binding from "segX" to resource R, and a
request adds a ["segX/pathZ", "K"] lock to C, then the request adds a
["pathZ", "K"] lock to R.


- Adding a resource to a locked collectin can lock that resource.

If a collection C has a ["segX/pathZ", "K"] lock, and a request adds a
binding in C from "segX" to resource R, then the request adds a
["pathZ", "K"] lock to R. If the attempt to add this lock to R fails,
the request MUST fail.


- One or more resources can be unlocked with an UNLOCK request.

When a request of the form "UNLOCK /pathX; Lock-Token K" succeeds,
then all locks with token "K" are removed.


- Unlocking a collection can unlock one or more members of that
collection.

If a collection C has a binding from "segX" to resource R, and a
request removes a ["segX/pathZ", "K"] lock from C, then the request
removes a ["pathZ", "K"] lock from R.


- Removing a resource from a locked collection can unlock that resource.

If a collection has a ["segX/pathZ", "K"] lock, and a request removes
a binding in C from "segX" to resource R, then a ["pathZ", "K"] lock
is removed from R.


- The depth of a lock can be a 0 or infinity.  If a collection has a
depth infinity lock, all members of that collection are also locked.

If a collection C has a binding to resource R, and a request adds a
Depth:infinity [".", "K"] lock to C, and this is the first [".", "K"]
lock on C, then the request adds a [".", "K"] lock to R.  Conversely,
if a collection C has a binding to resource R, and a request removes
the last Depth:infinity [".", "K"] lock from C, then the request
removes a [".", "K"] lock from R.

Note that multiple Depth:infinity locks with target "." and with the
same token can be placed on the same resource due to multiple bindings
to that resource in a Depth:infinity locked collection.  Only the
first such lock on a particular collection adds locks to the members
of that collection to avoid generating an infinite number of locks for
cyclic bindings.


- If a member is added to a depth:infinity locked collection, that
member is locked by that depth:infinity lock.

If a collection C has a Depth:infinity [".", "K"] lock, and a request
adds a binding in C to resource R, then the request adds a [".","K"]
lock to R. If the attempt to add this lock to R fails, the request
MUST fail.  Conversely, if a collection has a Depth:infinity [".",
"K"] lock, and a request removes a binding in C to resource R, then a
[".", "K"] lock removed from R.


- A lock protects which resource is identified by that lock.

More precisely, if a collection has a ["X/....", "K"] lock, a request
cannot delete the member named X from that collection unless the
principal of the request owns all locks with target "X/..." and the
tokens of all those locks are specified in an IF header.


- If a resource has an exclusive lock, that resource cannot be locked
with another locks with the same type and target but a different
token.

If a request attempts to add a type T ["pathZ", "K"] lock to resource
R, and R already has an exclusive lock with target "pathZ" and type T
but with a different token, the request MUST fail. Similarly, if a
request attempts to add an exclusive type T ["pathZ", "K"] lock to
resource R, and R already has a lock with target "pathZ" and type T
but with a different token, the request MUST fail.


- If a resource has a write lock with target ".", the body and
properties of that resource are protected from unauthorized
modification.

If a resource has a write lock with target ".", a request cannot
modify the body or dead properties of that resource unless the
principal of the request owns a write lock with target "." on that
resource and the token of that write lock is specified in an IF
header.


**************************



From w3c-dist-auth-request@w3.org  Fri Jan 14 05:10:40 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14028
	for <webdav-archive@odin.ietf.org>; Fri, 14 Jan 2000 05:10:36 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id EAA22611;
	Fri, 14 Jan 2000 04:59:17 -0500 (EST)
Resent-Date: Fri, 14 Jan 2000 04:59:17 -0500 (EST)
Resent-Message-Id: <200001140959.EAA22611@www19.w3.org>
Message-ID: <002101bf5e75$ee294590$9a114498@us.oracle.com>
From: "Eric Sedlar" <esedlar@us.oracle.com>
To: <ccjason@us.ibm.com>
Cc: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>, <w3c-dist-auth@w3.org>
References: <85256865.007BDF15.00@D51MTA03.pok.ibm.com>
Date: Fri, 14 Jan 2000 01:58:38 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Subject: Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3829
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

This is what is supposed to happen when you lock a collection--you lock all
of the names within it, probably given that you are going to do a
reorganization.  For you to demonstrate that this is a problem, give a
scenario where a versioning-unaware application is going to lock a
collection.

--Eric

----- Original Message -----
From: <ccjason@us.ibm.com>
To: "Eric Sedlar" <esedlar@us.oracle.com>
Cc: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>;
<w3c-dist-auth@w3.org>
Sent: Thursday, January 13, 2000 2:32 PM
Subject: Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)


>
> Ah... Eric's note brings up another possibility.  It might be a red
> herring, but as Geoff's
> proposal is currently written (and Eric's too I think) it still is a
> possibly unexpected behavior.
>
> User B  locks /a/b/ exclusively.
>
> User D tries to do a shared lock on /a/b/c/d.html but fails because in the
> proposal that
> will also create a lock (or will it?) on /a/b/ which already has an
> exclusive lock on it.
>
> I'm not saying this is good or bad.  I'm just pointing it out as what
> sounds like a difference
> in the recent proposals relative to what we were proposing a month or more
> ago.
>
> Jason.
>
>
>



From w3c-dist-auth-request@w3.org  Fri Jan 14 09:05:40 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16948
	for <webdav-archive@odin.ietf.org>; Fri, 14 Jan 2000 09:05:39 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id IAA28204;
	Fri, 14 Jan 2000 08:52:29 -0500 (EST)
Resent-Date: Fri, 14 Jan 2000 08:52:29 -0500 (EST)
Resent-Message-Id: <200001141352.IAA28204@www19.w3.org>
Date: Fri, 14 Jan 2000 08:52:21 -0500
Message-Id: <10001141352.AA23127@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <007401bf5e07$4771de10$9a114498@us.oracle.com>
	(esedlar@us.oracle.com)
Subject: Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3830
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

   From: "Eric Sedlar" <esedlar@us.oracle.com>

   You want to avoid having name and resource locks as separate entities, so
   you basically say that a name lock (as in my proposal) locks the resource it
   is bound to, if any.

Yes.

   If the lock is exclusive, you can't lock any other
   name applied to that resource.  For example, if I have /a/foo.html and
   /b/foo.html both identifying the same resource, if I exclusive lock
   /a/foo.html, I can't protect the name "/b/foo.html" since I can't lock it.

You cannot apply an exclusive lock of the same type to /b/foo.html,
but if you just wanted to protect the name /b/foo.html, you could
request a lock of a different type on /b/foo.html (exclusivity is
lock-type specific).

Alternatively, if your server only supports one kind of lock type, you
could lock /b/foo.html/dummy-namespace-lock, which would have a similar effect
(and does not conflict with the exclusive lock already on /b/foo.html.

   Since the LOCK protocol request currently doesn't distinguish between name
   and resource locks, you couldn't lock /b/foo.html anyway (which is why you
   are ok with the restriction above), since the protocol request would try to
   lock the resource identified by /b/foo.html as well as the name.

GULP does not distinguish between "locking the resource" and "locking the
name", although it does distinguish "a lock whose target is X/." and 
"a lock whose target is ."

   However, it does seem like there will be reasons to protect the namespace in
   this way, and I think you are paying a price for reducing the number of
   locks.

If you wanted to introduce a "namespace lock", you could do so with the
standard lock extension mechanism (i.e. allow both "write" and "namespace"
locks), but that is different from saying there are two different kinds
of locks in the underlying locking model.

   > - If an exclusive lock identifies a resource, no other lock of that type
   can
   > identify that resource.

Note that I have modified this statement to read:

- If a resource has an exclusive lock, that resource cannot be locked
with another locks with the same type and target but a different
token.

This ties the semantics to the lock state of a single resource, rather
than using the vaguer concept of "the resource identified by a lock".

   Here's a scenario: it seems like if application A has an exclusive lock on
   /a/foo.html (say because it is planning on updating the resource to create a
   new version, and it wants to prevent lost updates) and application B wants
   to only read /b/foo.html and protect the namespace so that it can find it
   again later, application B cannot create a shared lock on /b/foo.html,
   correct?

They can add a lock with a different type from the exclusive lock,
or if there are no other lock types available, they can do the "dummy lock"
approach of locking "/b/foo.html/dummy-namespace-lock".

   The problem is that application A will not actually update the
   resource that app B is working with--it will just create a new revision.
   (Although this may affect the revision selected by app B).  Is this an issue
   your versioned locks deal with?

Versioning is (of course :-) somewhat trickier.  A lock in the presence of
versioning isn't so much concerned with locking the state of a resource
(the majority of the visible resources will be checked-in revisions, and
couldn't be modified even if you wanted to), but rather is concerned with
locking the target selection (so that you don't end up effectively getting
a namespace or state change because new revisions are selected).  This
issue (as you suggest) is addressed with the "revision selection freezing"
I've proposed for the versioning protocol.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Fri Jan 14 09:20:40 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17263
	for <webdav-archive@odin.ietf.org>; Fri, 14 Jan 2000 09:20:39 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id JAA28990;
	Fri, 14 Jan 2000 09:09:43 -0500 (EST)
Resent-Date: Fri, 14 Jan 2000 09:09:43 -0500 (EST)
Resent-Message-Id: <200001141409.JAA28990@www19.w3.org>
Date: Fri, 14 Jan 2000 09:09:33 -0500
Message-Id: <10001141409.AA23145@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <85256865.007BDF15.00@D51MTA03.pok.ibm.com> (ccjason@us.ibm.com)
Subject: Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3831
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

I'll flesh out Jason's example with the resulting lock state (as defined
by GULP).

   From: ccjason@us.ibm.com

   Ah... Eric's note brings up another possibility.  It might be a red
   herring, but as Geoff's proposal is currently written (and Eric's too
   I think) it still is a possibly unexpected behavior.

   User B  locks /a/b/ exclusively.

Suppose / does not identify a WebDAV resource, but /a does.
Suppose that /a/b/c identifies a resource, but /a/b/c/d.html does not.

Then the user B lock results in a ["b/.", "tok153"] lock on /a
and a [".", "tok153"] lock on /a/b.  All locks with token "tok153"
have exclusive scope.  Although according to 2518, a lock is by
default depth:infinity (which I believe is broken, and should be
replaced by a default depth of zero), I believe Jason intended a
depth:0 lock, so we'll postulate that all locks with token "tok153"
are depth:0.

   User D tries to do a shared lock on /a/b/c/d.html but fails because in
   the proposal that will also create a lock (or will it?) on /a/b/ which
   already has an exclusive lock on it.

If user D's request succeeded, it would add a ["b/c/d.html/.",
"tok192"] lock to /a and a ["c/d.html/.", "tok192"] lock on /a/b and a
["d.html/.", "tok192"] lock on /a/b/c.  Since none of these locks
conflict with any of the existing locks, user D's request succeeds.
In particular, the ["b/c/d.html/.", "tok192"] lock on /a has a
different target from the ["b/.", "tok153"] lock on /a, so there is no
conflict there.

   I'm not saying this is good or bad.  I'm just pointing it out as what
   sounds like a difference in the recent proposals relative to what we
   were proposing a month or more ago.

I don't think it is acceptable for the exclusive lock on /a/b to conflict
with an exclusive lock on /a/b/c/d.html (so it's a good thing GULP allows
it :-).

Cheers,
Geoff






From w3c-dist-auth-request@w3.org  Fri Jan 14 09:39:42 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17776
	for <webdav-archive@odin.ietf.org>; Fri, 14 Jan 2000 09:39:40 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id JAA29548;
	Fri, 14 Jan 2000 09:28:39 -0500 (EST)
Resent-Date: Fri, 14 Jan 2000 09:28:39 -0500 (EST)
Resent-Message-Id: <200001141428.JAA29548@www19.w3.org>
Date: Fri, 14 Jan 2000 09:28:32 -0500
Message-Id: <10001141428.AA23157@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <002101bf5e75$ee294590$9a114498@us.oracle.com>
	(esedlar@us.oracle.com)
Subject: Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3832
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


   From: "Eric Sedlar" <esedlar@us.oracle.com>

   This is what is supposed to happen when you lock a collection--you lock all
   of the names within it, probably given that you are going to do a
   reorganization. 

Here I believe Eric is assuming the lock on /a/b was a depth:infinity
lock (correct default 2518 behavior), in which case one would expect
a conflict between an exclusive depth:infinity lock on /a/b and an
exclusive lock on /a/b/c/d.html (in my response, I postulated a
depth:0 lock on /a/b).

Currently, GULP would not detect this conflict until someone tried to
create a resource named /a/b/c/d.html, at which point the exclusive
lock conflict would prevent the creation of that resource.

We could either just say that it is OK to defer the conflict detection
until resource creation time, or we could make GULP smarter about
detecting exclusive lock conflicts on resources that do not yet exist.
The downside of doing so is that it adds complexity to the
specification.  I could go either way ... does anyone have a strong
preference?  I'll go ahead and add clause to the exclusive lock
conflict rule to handle this, and we can always rip it out if it
doesn't seem worth the added complexity.

Cheers,
Geoff

   ----- Original Message -----
   From: <ccjason@us.ibm.com>
   To: "Eric Sedlar" <esedlar@us.oracle.com>
   Cc: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>;
   <w3c-dist-auth@w3.org>
   Sent: Thursday, January 13, 2000 2:32 PM
   Subject: Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)


   >
   > Ah... Eric's note brings up another possibility.  It might be a red
   > herring, but as Geoff's
   > proposal is currently written (and Eric's too I think) it still is a
   > possibly unexpected behavior.
   >
   > User B  locks /a/b/ exclusively.
   >
   > User D tries to do a shared lock on /a/b/c/d.html but fails because in the
   > proposal that
   > will also create a lock (or will it?) on /a/b/ which already has an
   > exclusive lock on it.
   >
   > I'm not saying this is good or bad.  I'm just pointing it out as what
   > sounds like a difference
   > in the recent proposals relative to what we were proposing a month or more
   > ago.



From w3c-dist-auth-request@w3.org  Fri Jan 14 10:14:30 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18216
	for <webdav-archive@odin.ietf.org>; Fri, 14 Jan 2000 10:14:27 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id KAA00790;
	Fri, 14 Jan 2000 10:03:28 -0500 (EST)
Resent-Date: Fri, 14 Jan 2000 10:03:28 -0500 (EST)
Resent-Message-Id: <200001141503.KAA00790@www19.w3.org>
Date: Fri, 14 Jan 2000 10:03:22 -0500
Message-Id: <10001141503.AA23191@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
Subject: GULP: revised exclusive locking rule
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3833
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


The revised rule is as follows:

************

Two locks are said to "overlap" if the targets of those locks are
equal or if one of the locks is a depth:infinity lock and the target
of that lock is a prefix of the target of the other lock.  If a
request attempts to add a type T lock to a resource that has an
overlapping exclusive type T lock with a different token, the request
MUST fail.  Similarly, if a request attempts to add an exclusive type
T lock to resource that already has an overlapping type T lock with a
different token, the request MUST fail.

************

This will then cause the desired failure when:
- /a/b/c exists but /a/b/c/d.html does not
- /a/b has a depth:infinity exclusive lock
- an attempt is made to place a depth:infinity exclusive lock on /a/b/c/d.html

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Fri Jan 14 13:48:08 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21144
	for <webdav-archive@odin.ietf.org>; Fri, 14 Jan 2000 13:48:08 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA06750;
	Fri, 14 Jan 2000 13:36:37 -0500 (EST)
Resent-Date: Fri, 14 Jan 2000 13:36:37 -0500 (EST)
Resent-Message-Id: <200001141836.NAA06750@www19.w3.org>
Message-ID: <00a401bf5ebe$72ba1c60$79442382@us.oracle.com>
From: "Eric Sedlar" <esedlar@us.oracle.com>
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>, <w3c-dist-auth@w3.org>
References: <10001141352.AA23127@tantalum>
Date: Fri, 14 Jan 2000 10:37:44 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3834
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

Why are you still allowing the "lock-null" approach (now renamed as the
dummy namespace lock)?  I thought one of the goals of GULP was to get rid of
that horrible concept.

--Eric

----- Original Message -----
From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
To: <w3c-dist-auth@w3.org>
Sent: Friday, January 14, 2000 5:52 AM
Subject: Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)


>    From: "Eric Sedlar" <esedlar@us.oracle.com>
>
>    You want to avoid having name and resource locks as separate entities,
so
>    you basically say that a name lock (as in my proposal) locks the
resource it
>    is bound to, if any.
>
> Yes.
>
>    If the lock is exclusive, you can't lock any other
>    name applied to that resource.  For example, if I have /a/foo.html and
>    /b/foo.html both identifying the same resource, if I exclusive lock
>    /a/foo.html, I can't protect the name "/b/foo.html" since I can't lock
it.
>
> You cannot apply an exclusive lock of the same type to /b/foo.html,
> but if you just wanted to protect the name /b/foo.html, you could
> request a lock of a different type on /b/foo.html (exclusivity is
> lock-type specific).
>
> Alternatively, if your server only supports one kind of lock type, you
> could lock /b/foo.html/dummy-namespace-lock, which would have a similar
effect
> (and does not conflict with the exclusive lock already on /b/foo.html.
>
>    Since the LOCK protocol request currently doesn't distinguish between
name
>    and resource locks, you couldn't lock /b/foo.html anyway (which is why
you
>    are ok with the restriction above), since the protocol request would
try to
>    lock the resource identified by /b/foo.html as well as the name.
>
> GULP does not distinguish between "locking the resource" and "locking the
> name", although it does distinguish "a lock whose target is X/." and
> "a lock whose target is ."
>
>    However, it does seem like there will be reasons to protect the
namespace in
>    this way, and I think you are paying a price for reducing the number of
>    locks.
>
> If you wanted to introduce a "namespace lock", you could do so with the
> standard lock extension mechanism (i.e. allow both "write" and "namespace"
> locks), but that is different from saying there are two different kinds
> of locks in the underlying locking model.
>
>    > - If an exclusive lock identifies a resource, no other lock of that
type
>    can
>    > identify that resource.
>
> Note that I have modified this statement to read:
>
> - If a resource has an exclusive lock, that resource cannot be locked
> with another locks with the same type and target but a different
> token.
>
> This ties the semantics to the lock state of a single resource, rather
> than using the vaguer concept of "the resource identified by a lock".
>
>    Here's a scenario: it seems like if application A has an exclusive lock
on
>    /a/foo.html (say because it is planning on updating the resource to
create a
>    new version, and it wants to prevent lost updates) and application B
wants
>    to only read /b/foo.html and protect the namespace so that it can find
it
>    again later, application B cannot create a shared lock on /b/foo.html,
>    correct?
>
> They can add a lock with a different type from the exclusive lock,
> or if there are no other lock types available, they can do the "dummy
lock"
> approach of locking "/b/foo.html/dummy-namespace-lock".
>
>    The problem is that application A will not actually update the
>    resource that app B is working with--it will just create a new
revision.
>    (Although this may affect the revision selected by app B).  Is this an
issue
>    your versioned locks deal with?
>
> Versioning is (of course :-) somewhat trickier.  A lock in the presence of
> versioning isn't so much concerned with locking the state of a resource
> (the majority of the visible resources will be checked-in revisions, and
> couldn't be modified even if you wanted to), but rather is concerned with
> locking the target selection (so that you don't end up effectively getting
> a namespace or state change because new revisions are selected).  This
> issue (as you suggest) is addressed with the "revision selection freezing"
> I've proposed for the versioning protocol.
>
> Cheers,
> Geoff
>
>



From w3c-dist-auth-request@w3.org  Sat Jan 15 01:29:58 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29869
	for <webdav-archive@odin.ietf.org>; Sat, 15 Jan 2000 01:29:57 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id BAA20424;
	Sat, 15 Jan 2000 01:15:39 -0500 (EST)
Resent-Date: Sat, 15 Jan 2000 01:15:39 -0500 (EST)
Resent-Message-Id: <200001150615.BAA20424@www19.w3.org>
Date: Sat, 15 Jan 2000 01:15:24 -0500
Message-Id: <10001150615.AA23572@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
Subject: GULP, version 3
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3835
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


Jason just pointed out that the "ref-counting" lock token approach
in GULP fails in the presence of cycles (an embarassing mistake :-).
So here is GULP version 3.

**************************

GULP: Part I

- A URL is a string that can identify a resource.

- A collection is a resource that contains a set of named members.

- A lock is 7-tuple, consisting of a target, token, type, scope,
depth, timeout, and owner.

- Locking a resource means to add a lock to that resource.

- When a resource is locked, certain requests will fail with a 423
(Locked) status code, where that request would have succeeded if the
lock had not been present.

- A resource can be locked by multiple locks concurrently.

- A LOCK request locks one or more resources.

- Locking a collection can lock one or more members of the collection.

- The depth of a lock can be a 0 or infinity.  If a collection is the
target of a depth infinity lock, all members of that collection are
also locked.

- An UNLOCK request unlocks one or more resources.

- Adding or removing members from a locked collection can add or remove
locks on those members.

- A lock protects which resource is identified by that lock.

- If a resource has an exclusive lock, that resource cannot be locked
with another lock with the same type and target but a different token.

- If a resource has a write lock with target ".", the body and
properties of that resource are protected from unauthorized
modification.


**************************

GULP: Part II


- A URL is a string that can identify a resource.

A server initially defines what resource (if any) is identified by a
URL.  Most URL's do not identify a resource, but a client can cause
a URL to identify a resource, and later change which resource is
identified by that URL.

Examples of methods that can cause a URL to identify a resource (or
change the resource identified by a URL) are PUT, MKRESOURCE, MKCOL,
BIND, MOVE, and COPY.  Examples of methods that can cause a URL to no
longer identify a resource are DELETE and MOVE.


- A collection is a resource that contains a set of named members.

A collection contains a set of bindings, where a binding is a mapping
from a URL segment to a resource.  If a URL identifies a collection,
that URL extended by the URL segment will identify the bound resource.

For example, If "/path" identifies a collection C, and C contains a
binding that binds the segment "x" to resource R, then the URL
"/path/x" identifies resource R.


- A lock is 7-tuple, consisting of a target, token, type, scope, depth,
timeout, and owner.

The "target" is an extension to locks as defined in rfc2518.  This new
field is defined to distinguish the implicit locks on the state of a
collection implied by the locking semantics of rfc2518, from the
explicit locks that are defined by rfc2518.  The explicit locks in
rfc2518 correspond to locks with target "." in this proposal.

Since all locks with the same token will share the same type, scope,
depth, timeout, and owner, a lock will be represented in this proposal
as a string of the form "[target, token]".

For example, ["x/.", "K"] defines a lock with target "x/." and token "K".


- Locking a resource means to add a lock to that resource.

The current set of locks on a resource can be obtained from the
DAV:lockdiscovery property of the resource.


- When a resource is locked, certain requests will fail with a 423
(Locked) status code, where that request would have succeeded if the
lock had not been present.

Whether a particular request will fail can depends on the
target, token, type, scope, and owner of the lock.


- A resource can be locked by multiple locks concurrently.

Some lock combinations will be disallowed
based on information such as the the scope of the lock.


- A LOCK request locks one or more resources.

R1: When a LOCK request succeeds, a lock is added to the resource
identified by shortest sequence of initial segments of the request URL
that identifies a WebDAV resource.

For example, if "LOCK /seg1/seg2/seg3/.../segN" succeeds, and if
/seg1 does not identify a WebDAV resource but /seg1/seg2 does,
then a lock is added to the resource identified by "/seg1/seg2".

The lock target is the relative URL formed by using standard URL
transformations to remove all segments of the request-URL named "." or
"..", then removing the prefix that identifies the locked resource,
and then appending a segment named ".".

For example, if "LOCK /seg1/seg2/../seg3/./seg4" succeeds, and if "/"
does not identify a WebDAV resource but "/seg1" does, then a lock with
target "seg3/seg4/." is added to the resource identified by "/seg1".

The type and scope, and owner of the lock is specified in the LOCK
request body.  The depth and timeout of the lock is specified in the
LOCK request headers.  The token of the lock is a unique string
allocated for that LOCK request by the server.

The principal that issued the LOCK request is called the "owner" of
the lock.


- Locking a collection can lock one or more members of the collection.

R2: If a collection C has a binding from "segX" to resource R, and a
request adds a ["segX/pathZ", "K"] lock to C, then the request adds a
["pathZ", "K"] lock to R.  This rule is applied recursively.


- The depth of a lock can be a 0 or infinity.  If a collection is the
target of a depth infinity lock, all members of that collection are
also locked.

R3: If a collection C has a binding to resource R, and a request adds
a Depth:infinity [".", "K"] lock to C, and there is no [".", "K"] lock
on R, then the request adds a [".", "K"] lock to R.  This rule is
applied recursively.  If the lock cannot be added to R, the request
fails.


- An UNLOCK request unlocks one or more resources.

R4: When a request of the form "UNLOCK /pathX; Lock-Token K" succeeds,
then all locks with token "K" are removed.


- Adding or removing members from a locked collection can add or remove
locks on those members.

R5: If a collection C has a lock with token "K" and a request adds
or removes a member from C, all locks with token "K" are removed except for
those that would result from re-executing the LOCK command that
created the token "K" locks.   If any of these locks cannot be added,
the request MUST fail.


- A lock protects which resource is identified by that lock.

R6: If a collection has a ["X/....", "K"] lock, a request cannot delete
the member named X from that collection unless the principal of the
request owns all locks with target "X/..." and the tokens of all those
locks are specified in an IF header.


- If a resource has an exclusive lock, that resource cannot be locked
with another locks with the same type and target but a different
token.

R7: Two locks are said to "overlap" if the targets of those locks are
equal or if one of the locks is a depth:infinity lock and the target
of that lock is a prefix of the target of the other lock.  If a
request attempts to add a type T lock to a resource that has an
overlapping exclusive type T lock with a different token, the request
MUST fail.  Similarly, if a request attempts to add an exclusive type
T lock to resource that already has an overlapping type T lock with a
different token, the request MUST fail.


- If a resource has a write lock with target ".", the body and
properties of that resource are protected from unauthorized
modification.

R8: If a resource has a write lock with target ".", a request cannot
modify the body or dead properties of that resource unless the
principal of the request owns a write lock with target "." on that
resource and the token of that write lock is specified in an IF
header.


**************************



From w3c-dist-auth-request@w3.org  Sat Jan 15 01:41:23 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00561
	for <webdav-archive@odin.ietf.org>; Sat, 15 Jan 2000 01:41:22 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id BAA21000;
	Sat, 15 Jan 2000 01:27:21 -0500 (EST)
Resent-Date: Sat, 15 Jan 2000 01:27:21 -0500 (EST)
Resent-Message-Id: <200001150627.BAA21000@www19.w3.org>
Date: Sat, 15 Jan 2000 01:27:15 -0500
Message-Id: <10001150627.AA23587@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <00a401bf5ebe$72ba1c60$79442382@us.oracle.com>
	(esedlar@us.oracle.com)
Subject: Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3836
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

   From: "Eric Sedlar" <esedlar@us.oracle.com>

   Why are you still allowing the "lock-null" approach (now renamed as the
   dummy namespace lock)?  I thought one of the goals of GULP was to get rid of
   that horrible concept.

Actually, it is the "lock null resource" concept that I strenuously
object to, not the concept that a lock can be on a target that does
not yet exist.

I believe being able to create a lock on a target that does not yet
exist is no worse/harder than namespace protection, so I would include
it in any proposal that includes namespace protection.

Also, the "grand unified" aspect of GULP was intended to allow us to
model everything that folks have been asking for, and then with that
in hand, we can decide which parts to defer (possibly indefinitely).

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Sun Jan 16 20:37:17 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12330
	for <webdav-archive@odin.ietf.org>; Sun, 16 Jan 2000 20:37:16 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA05933;
	Sun, 16 Jan 2000 20:26:34 -0500 (EST)
Resent-Date: Sun, 16 Jan 2000 20:26:34 -0500 (EST)
Resent-Message-Id: <200001170126.UAA05933@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E1F@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: w3c-dist-auth@w3.org
Date: Sun, 16 Jan 2000 17:25:35 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF6089.DAA94298"
Subject: WebDAV Bindings - Issue Yaron.ApplePie3
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3838
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6089.DAA94298
Content-Type: text/plain;
	charset="iso-8859-1"

Section 11 of the BIND spec states: "A PROPFIND requesting DAV:bindings MUST
return only those bindings that the client is authorized to see."

This brings up a couple of questions. The first question is "How do I ever
know if I have the definitive list of bindings?" I suspect the answer is
"you don't" since there may be bindings you aren't authorized to see.

This then brings us to another sentence in section 11 which reads "If the
DAV:bindings property exists on a given resource, it MUST contain a complete
list of all bindings to that resource."

However this means that the dav:bindings property must always return a
complete list of bindings which the sentence following it (given at the
start of this letter) contradicts.

One should never have two MUST level requirements that are in direct
contradiction. The reason for the contradiction is that we have raised the
bar too high on the contents of the dav:bindings property value. We have
already specified that due to security concerns it is absolutely impossible
for you to ever be sure that you necessarily have the complete list of
bindings. Therefore requiring that the complete list be returned, even as
the default in the absence of security concerns, is self defeating.

Therefore I move that the language in section 11 be changed to read that the
dav:bindings property may contain zero or more of the bindings available on
a resource rather than the definitive set since it is impossible to
meaningfully require that the definitive set be returned.

------_=_NextPart_001_01BF6089.DAA94298
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>WebDAV Bindings - Issue Yaron.ApplePie3</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Section 11 of the BIND spec states: =
&quot;A PROPFIND requesting DAV:bindings MUST return only those =
bindings that the client is authorized to see.&quot;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This brings up a couple of questions. =
The first question is &quot;How do I ever know if I have the definitive =
list of bindings?&quot; I suspect the answer is &quot;you don't&quot; =
since there may be bindings you aren't authorized to see.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This then brings us to another =
sentence in section 11 which reads &quot;If the DAV:bindings property =
exists on a given resource, it MUST contain a complete list of all =
bindings to that resource.&quot;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">However this means that the =
dav:bindings property must always return a complete list of bindings =
which the sentence following it (given at the start of this letter) =
contradicts.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">One should never have two MUST level =
requirements that are in direct contradiction. The reason for the =
contradiction is that we have raised the bar too high on the contents =
of the dav:bindings property value. We have already specified that due =
to security concerns it is absolutely impossible for you to ever be =
sure that you necessarily have the complete list of bindings. Therefore =
requiring that the complete list be returned, even as the default in =
the absence of security concerns, is self defeating.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Therefore I move that the language in =
section 11 be changed to read that the dav:bindings property may =
contain zero or more of the bindings available on a resource rather =
than the definitive set since it is impossible to meaningfully require =
that the definitive set be returned.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01BF6089.DAA94298--



From w3c-dist-auth-request@w3.org  Sun Jan 16 20:38:03 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12342
	for <webdav-archive@odin.ietf.org>; Sun, 16 Jan 2000 20:38:03 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA05705;
	Sun, 16 Jan 2000 20:25:13 -0500 (EST)
Resent-Date: Sun, 16 Jan 2000 20:25:13 -0500 (EST)
Resent-Message-Id: <200001170125.UAA05705@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E14@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: w3c-dist-auth@w3.org
Date: Sun, 16 Jan 2000 17:24:14 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF6089.A9AC7160"
Subject: Review of Bindings
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3837
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6089.A9AC7160
Content-Type: text/plain;
	charset="iso-8859-1"

I have just finished a detailed review of the bindings spec.

After having given it a lot of thought I have come to agree with the
conclusions given in the bind spec, the WebDAV collection model is broken
and needs to be fixed. I further agree that the proposed model in BIND is a
definite improvement. While I'm still not convinced of some of the mostly
philosophical details (is a bind recorded in the collection or on the
resource?, for example), none of these details are sufficiently weighty to
merit holding up the spec. If we find that some of the niggling issues
aren't correct then we will fix it later.

After reviewing the draft I find that I have 17 issues. I have identified
each issue with a name. Following WebDAV mailing list tradition each issue
is addressed in its own letter.

The complete list of issues I am raising, in no particular order, are:

Yaron.PublishBind
Yaron.WeScrewedUp
Yaron.4Huh?
Yaron.5.3Huh?
Yaron.5.4Huh?
Yaron.507
Yaron.Insulting2616
Yaron.AtomicMove
Yaron.AtomicDelete
Yaron.NoSlash
Yaron.BindSyntax
Yaron.403
Yaron.ApplePie
Yaron.MrIntegrity
Yaron.ApplePie3
Yaron.BindingsProperty
Yaron.ApplePieToo

------_=_NextPart_001_01BF6089.A9AC7160
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>Review of Bindings</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have just finished a detailed review =
of the bindings spec.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">After having given it a lot of thought =
I have come to agree with the conclusions given in the bind spec, the =
WebDAV collection model is broken and needs to be fixed. I further =
agree that the proposed model in BIND is a definite improvement. While =
I'm still not convinced of some of the mostly philosophical details (is =
a bind recorded in the collection or on the resource?, for example), =
none of these details are sufficiently weighty to merit holding up the =
spec. If we find that some of the niggling issues aren't correct then =
we will fix it later.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">After reviewing the draft I find that =
I have 17 issues. I have identified each issue with a name. Following =
WebDAV mailing list tradition each issue is addressed in its own =
letter.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The complete list of issues I am =
raising, in no particular order, are:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Yaron.PublishBind</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Yaron.WeScrewedUp</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Yaron.4Huh?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Yaron.5.3Huh?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Yaron.5.4Huh?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Yaron.507</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Yaron.Insulting2616</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Yaron.AtomicMove</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Yaron.AtomicDelete</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Yaron.NoSlash</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Yaron.BindSyntax</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Yaron.403</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Yaron.ApplePie</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Yaron.MrIntegrity</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Yaron.ApplePie3</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Yaron.BindingsProperty</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Yaron.ApplePieToo</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF6089.A9AC7160--



From w3c-dist-auth-request@w3.org  Sun Jan 16 20:38:10 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12353
	for <webdav-archive@odin.ietf.org>; Sun, 16 Jan 2000 20:38:09 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA06139;
	Sun, 16 Jan 2000 20:27:28 -0500 (EST)
Resent-Date: Sun, 16 Jan 2000 20:27:28 -0500 (EST)
Resent-Message-Id: <200001170127.UAA06139@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E1E@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: w3c-dist-auth@w3.org
Date: Sun, 16 Jan 2000 17:26:30 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF6089.FB719818"
Subject: WebDAV Bindings - Issue Yaron.BindingsProperty
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3839
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6089.FB719818
Content-Type: text/plain;
	charset="iso-8859-1"

Section 11 of the BIND specification defines the dav:bindings property. What
is not clear to me from the text in this section is if it is possible to
have the dav:bindings property accessible through one binding but not
another? 

One could imagine that two servers share access to the same disk drive and
hence are able to map names to the same "resource" (as they understand the
term). In order to keep things consistent both servers agree to record all
the names they use to refer to the same resource. However only one of the
servers actually supports the BIND method and the dav:bindings property and
the other doesn't. I can still do a GET on each server and the result will
be from the same resource but only one of the servers will be able to serve
up the dav:bindings property. Unfortunately the language in section 11
speaks of the dav:bindings property being on a resource so the presumption
is that if I can get the dav:bindings property through one binding then I
MUST be able to get it through the other. I believe this is too strict a
requirement.

As such I move that the language in section 11 be clarified so as to specify
that the dav:bindings property may not necessarily be available through all
bindings on the resource.

------_=_NextPart_001_01BF6089.FB719818
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>WebDAV Bindings - Issue Yaron.BindingsProperty</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Section 11 of the BIND specification =
defines the dav:bindings property. What is not clear to me from the =
text in this section is if it is possible to have the dav:bindings =
property accessible through one binding but not another? </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">One could imagine that two servers =
share access to the same disk drive and hence are able to map names to =
the same &quot;resource&quot; (as they understand the term). In order =
to keep things consistent both servers agree to record all the names =
they use to refer to the same resource. However only one of the servers =
actually supports the BIND method and the dav:bindings property and the =
other doesn't. I can still do a GET on each server and the result will =
be from the same resource but only one of the servers will be able to =
serve up the dav:bindings property. Unfortunately the language in =
section 11 speaks of the dav:bindings property being on a resource so =
the presumption is that if I can get the dav:bindings property through =
one binding then I MUST be able to get it through the other. I believe =
this is too strict a requirement.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">As such I move that the language in =
section 11 be clarified so as to specify that the dav:bindings property =
may not necessarily be available through all bindings on the =
resource.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01BF6089.FB719818--



From w3c-dist-auth-request@w3.org  Sun Jan 16 20:39:36 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12364
	for <webdav-archive@odin.ietf.org>; Sun, 16 Jan 2000 20:39:36 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA06348;
	Sun, 16 Jan 2000 20:28:53 -0500 (EST)
Resent-Date: Sun, 16 Jan 2000 20:28:53 -0500 (EST)
Resent-Message-Id: <200001170128.UAA06348@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E1D@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: w3c-dist-auth@w3.org
Date: Sun, 16 Jan 2000 17:27:55 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF608A.2E251A00"
Subject: WebDAV Bindings - Issue Yaron.ApplePieToo
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3840
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF608A.2E251A00
Content-Type: text/plain;
	charset="iso-8859-1"

Section 9 of the draft attempts to tackle the problem of how to
differentiate the behavior of a resource based on its bindings. It attempts
to discuss the difference between a static and non-static resource. However
the difference between these two types of resources is so unbelievably
arbitrary that I fail to see how attempting to differentiate between them
enhances interoperability.

For example, let us pretend we have the CurrentURI property. The value of
the property will be the Request-URI of the PROPFIND method used to retrieve
the value of the CurrentURI property. Now let us pretend we have two
servers, A and B. A runs a version of WebDAV that automatically generates
the CurrentURI property on top of whatever resources it supports. What this
means is that even if the underlying data store where the resource is
recorded doesn't know about the CurrentURI property, I can still get the
CurrentURI property through PROPFIND because A's server will intercept the
PROPFIND and insert the data itself. Server B doesn't support CurrentURI at
all. I now have a resource R that has bindings into A and B. This means that
if I ask for the CurrentURI property through the binding on A, I will get a
result with the URI on A. If I ask for the CurrentURI property through the
binding on B, I will not even see the property at all.

So the question is - Well is this a dynamic resource? Is it not? Can I have
the same resourceID on both URIs in this example? How does the language in
section 9 help me deal with this? Does it actually clarify anything in a
useful way?

As far as I can tell the language in section 9 is just motherhood and apple
pie language and that always makes for bad standard language.

Therefore I move that all the paragraphs in section 9 but the first
paragraph be stricken from the BIND spec.

------_=_NextPart_001_01BF608A.2E251A00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>WebDAV Bindings - Issue Yaron.ApplePieToo</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Section 9 of the draft attempts to =
tackle the problem of how to differentiate the behavior of a resource =
based on its bindings. It attempts to discuss the difference between a =
static and non-static resource. However the difference between these =
two types of resources is so unbelievably arbitrary that I fail to see =
how attempting to differentiate between them enhances =
interoperability.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">For example, let us pretend we have =
the CurrentURI property. The value of the property will be the =
Request-URI of the PROPFIND method used to retrieve the value of the =
CurrentURI property. Now let us pretend we have two servers, A and B. A =
runs a version of WebDAV that automatically generates the CurrentURI =
property on top of whatever resources it supports. What this means is =
that even if the underlying data store where the resource is recorded =
doesn't know about the CurrentURI property, I can still get the =
CurrentURI property through PROPFIND because A's server will intercept =
the PROPFIND and insert the data itself. Server B doesn't support =
CurrentURI at all. I now have a resource R that has bindings into A and =
B. This means that if I ask for the CurrentURI property through the =
binding on A, I will get a result with the URI on A. If I ask for the =
CurrentURI property through the binding on B, I will not even see the =
property at all.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">So the question is - Well is this a =
dynamic resource? Is it not? Can I have the same resourceID on both =
URIs in this example? How does the language in section 9 help me deal =
with this? Does it actually clarify anything in a useful =
way?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">As far as I can tell the language in =
section 9 is just motherhood and apple pie language and that always =
makes for bad standard language.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Therefore I move that all the =
paragraphs in section 9 but the first paragraph be stricken from the =
BIND spec.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF608A.2E251A00--



From w3c-dist-auth-request@w3.org  Sun Jan 16 20:48:22 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12399
	for <webdav-archive@odin.ietf.org>; Sun, 16 Jan 2000 20:48:22 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA08099;
	Sun, 16 Jan 2000 20:37:35 -0500 (EST)
Resent-Date: Sun, 16 Jan 2000 20:37:35 -0500 (EST)
Resent-Message-Id: <200001170137.UAA08099@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E1B@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: w3c-dist-auth@w3.org
Date: Sun, 16 Jan 2000 17:36:39 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF608B.6556491C"
Subject: WebDAV Bindings - Issue Yaron.AtomicDelete
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3841
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF608B.6556491C
Content-Type: text/plain;
	charset="iso-8859-1"

The second to last paragraph in section 6 reads: "Although [WebDAV] allows a
DELETE to be a non-atomic operation, the DELETE operation defined here is
atomic.  In particular, a DELETE on a hierarchy of resources is simply the
removal of a binding to the collection identified by the Request-URI, and so
is a single (and therefore atomic) operation."

Because BIND redefines how collections work the effect of this paragraph is
to directly amend the behavior of RFC 2518 in a manner that is not compliant
with how RFC 2518 is currently written. 

Things brings up the first issue. Redefining DELETE to be atomic without
using the mandatory mechanism to prevent confusion on the part of clients
and servers will destroy interoperability with RFC 2518 systems. A BIND
enhanced client issuing a DELETE against a RFC 2518 server will expect
atomic behavior and probably won't get it. This is a failure of
interoperability. There are too many deployed RFC 2518 systems for us to
simply hide our heads in the sand and say "Well gee, BIND redefines RFC 2518
so everyone should change their functionality.".

There are cases where it is worth creating incompatibilities, for example,
if you find out that their is a serious flaw in the protocol. However no one
has demonstrated that the non-atomic behavior of DELETE is a flaw. It is a
pain, that is true. It certainly makes it difficult to write clients. But as
evidenced by the number of WebDAV clients it is clear that the requirement
is one that can be met. Heck, as evidenced by the number of file system
clients written in the last 30 years, it is clear that the requirement to
handle non-atomic behavior can be met.

Changing DELETE to atomic is especially egregious given that WebDAV does not
prevent a server from implementing DELETE atomically. Rather it puts the
client in the unfortunate situation of having to deal with systems that
can't necessarily support atomic DELETE. There are, I freely admit,
circumstances in which a client MUST be able to ensure that a DELETE is
issued atomically. Clients in those cases will have to choose to not
interoperate with many WebDAV servers in order to gain atomic delete. The
proper way for them to express their requirement that a delete be atomic is
either to issue DELETE with a MAN extension or to create a new method. But
the behavior of the DELETE method is well defined by RFC 2518 and given that
there is no evidence that this behavior is broken in any way. In fact, given
that their is over whelming evidence that non-atomic DELETE works just fine
and leads to interoperable implementations.

Let me clarify that DELETE was defined to not be atomic with malice of fore
thought. The non-atomic delete language was the result of nearly three years
of negotiations and represented a deep and broad consensus built up amongst
a huge community. Might I respectfully suggest to the BIND authors that they
should not be so ready to overthrow years of careful consensus building.

Do not imagine that the lack of screaming on this issue reflects consensus.
Rather it reflects the fact that most of the WebDAV community is too busy
implementing RFC 2518 to pay much attention to BIND. The BIND functionality,
while I believe it will be important to WebDAV, is a bit ahead of the
majority of implementers so they just aren't reading or reviewing it, yet.

The key reason DELETE was not allowed to be atomic (which certainly would
have been a nice thing to be able to do) has to do with the way file systems
work. Most file systems do not support depth operations atomically. So, for
example, when you delete a directory what actually happens is that the
program does a depth first walk of the directory tree and deletes all the
individual files, walking backwards up the tree until finally deleting the
parent directory.

This brings us to our second issue, the argument has been made that a file
system could simulate an atomic DELETE by issuing a MOVE command against a
directory and ensuring that nothing exists at the destination. This would
make it appear that all the files have been deleted. The file system could
then later delete the files at its convenience. In addition this sort of
implementation would allow the type of functionality you see today in the
Windows GUI where deleted files are first placed into the waste basket
before actually being deleted.

This theory has several problems in practice.

Problem #1 - There exists a write ACL (which covers MOVE) and a delete ACL
(which covers DELETE). It is possible, therefore, to have the right to
delete a file but not the right to move it. As such if a user is running a
WebDAV server under their own authentication then the server will have to
fail the DELETE command, even if they have the right access settings for
delete, because the server can't move the file first in order to simulate
the atomic DELETE behavior. The prevents file system based servers from
implementing the "MOVE is an atomic DELETE" hack.

Problem #2 - The required mechanism could actually form a denial of service
attack. Imagine a server gives a space allocation to all of their users. A
user then shows up and knows that the server is running low on space.
Therefore the user decides to fill up their allocation with junk, delete it,
fill it up again, delete it, etc. Each time the server will have to move all
the user's junk to some temp space in order to simulate the atomic delete.
If the server can't delete the temp files fast enough then the server's disk
space will be overrun. One could attempt to counter this attack by
specifying that one can only DELETE something if one has enough space left
in one's space allocation for the MOVE. Of course this means that if one has
filled up one's allocation and wants to delete some files to get more space
the delete will fail because there is no room to do the move. Of course, if
there was room to do the move then one wouldn't have wanted to delete the
files since one would still have space. Catch-22.

Problem #3 - File system servers are now getting smart enough to add
eventing support to their file systems. The idea is that you can register to
be told when a file is deleted or moved. However the delete and move events
are different. Forcing WebDAV file system servers to simulate a DELETE as a
move would cause the wrong event to get triggered. This means that one can
never be sure if that MOVE event was received because the user intended to
MOVE a file or because it was part of a DELETE operation. This is especially
important when one has a store that is accessible through multiple means,
say WebDAV and FTP. The events are registered directly on the file system,
not in the WebDAV or FTP implementation. So there is no way for the WebDAV
implementation to say "I know I'm doing a MOVE but you really should just
trigger the delete event."

There is then the third and final issue, WebDAV begins with a "D" for a
reason. It's goal is to be distributed. Requiring atomic DELETEs would
essentially hinder all but the most expensive of systems from being able to
implement distributed namespaces across multiple physical servers. The
reason being that the atomic requirement means that these systems will have
to establish transactioning systems between themselves in order to issue
DELETEs if they share namespace.

As such I move that the atomic DELETE language be struck from the BIND spec
on the grounds that it destroys interoperability, requires behavior that
would preclude file system based systems from supporting WebDAV and
significantly increases the cost of implementing WebDAV in a distributed
manner.

------_=_NextPart_001_01BF608B.6556491C
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>WebDAV Bindings - Issue Yaron.AtomicDelete</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">The second to last paragraph in =
section 6 reads: &quot;Although [WebDAV] allows a DELETE to be a =
non-atomic operation, the DELETE operation defined here is =
atomic.&nbsp; In particular, a DELETE on a hierarchy of resources is =
simply the removal of a binding to the collection identified by the =
Request-URI, and so is a single (and therefore atomic) =
operation.&quot;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Because BIND redefines how collections =
work the effect of this paragraph is to directly amend the behavior of =
RFC 2518 in a manner that is not compliant with how RFC 2518 is =
currently written. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Things brings up the first issue. =
Redefining DELETE to be atomic without using the mandatory mechanism to =
prevent confusion on the part of clients and servers will destroy =
interoperability with RFC 2518 systems. A BIND enhanced client issuing =
a DELETE against a RFC 2518 server will expect atomic behavior and =
probably won't get it. This is a failure of interoperability. There are =
too many deployed RFC 2518 systems for us to simply hide our heads in =
the sand and say &quot;Well gee, BIND redefines RFC 2518 so everyone =
should change their functionality.&quot;.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">There are cases where it is worth =
creating incompatibilities, for example, if you find out that their is =
a serious flaw in the protocol. However no one has demonstrated that =
the non-atomic behavior of DELETE is a flaw. It is a pain, that is =
true. It certainly makes it difficult to write clients. But as =
evidenced by the number of WebDAV clients it is clear that the =
requirement is one that can be met. Heck, as evidenced by the number of =
file system clients written in the last 30 years, it is clear that the =
requirement to handle non-atomic behavior can be met.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Changing DELETE to atomic is =
especially egregious given that WebDAV does not prevent a server from =
implementing DELETE atomically. Rather it puts the client in the =
unfortunate situation of having to deal with systems that can't =
necessarily support atomic DELETE. There are, I freely admit, =
circumstances in which a client MUST be able to ensure that a DELETE is =
issued atomically. Clients in those cases will have to choose to not =
interoperate with many WebDAV servers in order to gain atomic delete. =
The proper way for them to express their requirement that a delete be =
atomic is either to issue DELETE with a MAN extension or to create a =
new method. But the behavior of the DELETE method is well defined by =
RFC 2518 and given that there is no evidence that this behavior is =
broken in any way. In fact, given that their is over whelming evidence =
that non-atomic DELETE works just fine and leads to interoperable =
implementations.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Let me clarify that DELETE was defined =
to not be atomic with malice of fore thought. The non-atomic delete =
language was the result of nearly three years of negotiations and =
represented a deep and broad consensus built up amongst a huge =
community. Might I respectfully suggest to the BIND authors that they =
should not be so ready to overthrow years of careful consensus =
building.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Do not imagine that the lack of =
screaming on this issue reflects consensus. Rather it reflects the fact =
that most of the WebDAV community is too busy implementing RFC 2518 to =
pay much attention to BIND. The BIND functionality, while I believe it =
will be important to WebDAV, is a bit ahead of the majority of =
implementers so they just aren't reading or reviewing it, yet.</FONT></P=
>

<P><FONT SIZE=3D2 FACE=3D"Arial">The key reason DELETE was not allowed =
to be atomic (which certainly would have been a nice thing to be able =
to do) has to do with the way file systems work. Most file systems do =
not support depth operations atomically. So, for example, when you =
delete a directory what actually happens is that the program does a =
depth first walk of the directory tree and deletes all the individual =
files, walking backwards up the tree until finally deleting the parent =
directory.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This brings us to our second issue, =
the argument has been made that a file system could simulate an atomic =
DELETE by issuing a MOVE command against a directory and ensuring that =
nothing exists at the destination. This would make it appear that all =
the files have been deleted. The file system could then later delete =
the files at its convenience. In addition this sort of implementation =
would allow the type of functionality you see today in the Windows GUI =
where deleted files are first placed into the waste basket before =
actually being deleted.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This theory has several problems in =
practice.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Problem #1 - There exists a write ACL =
(which covers MOVE) and a delete ACL (which covers DELETE). It is =
possible, therefore, to have the right to delete a file but not the =
right to move it. As such if a user is running a WebDAV server under =
their own authentication then the server will have to fail the DELETE =
command, even if they have the right access settings for delete, =
because the server can't move the file first in order to simulate the =
atomic DELETE behavior. The prevents file system based servers from =
implementing the &quot;MOVE is an atomic DELETE&quot; hack.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Problem #2 - The required mechanism =
could actually form a denial of service attack. Imagine a server gives =
a space allocation to all of their users. A user then shows up and =
knows that the server is running low on space. Therefore the user =
decides to fill up their allocation with junk, delete it, fill it up =
again, delete it, etc. Each time the server will have to move all the =
user's junk to some temp space in order to simulate the atomic delete. =
If the server can't delete the temp files fast enough then the server's =
disk space will be overrun. One could attempt to counter this attack by =
specifying that one can only DELETE something if one has enough space =
left in one's space allocation for the MOVE. Of course this means that =
if one has filled up one's allocation and wants to delete some files to =
get more space the delete will fail because there is no room to do the =
move. Of course, if there was room to do the move then one wouldn't =
have wanted to delete the files since one would still have space. =
Catch-22.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Problem #3 - File system servers are =
now getting smart enough to add eventing support to their file systems. =
The idea is that you can register to be told when a file is deleted or =
moved. However the delete and move events are different. Forcing WebDAV =
file system servers to simulate a DELETE as a move would cause the =
wrong event to get triggered. This means that one can never be sure if =
that MOVE event was received because the user intended to MOVE a file =
or because it was part of a DELETE operation. This is especially =
important when one has a store that is accessible through multiple =
means, say WebDAV and FTP. The events are registered directly on the =
file system, not in the WebDAV or FTP implementation. So there is no =
way for the WebDAV implementation to say &quot;I know I'm doing a MOVE =
but you really should just trigger the delete event.&quot;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">There is then the third and final =
issue, WebDAV begins with a &quot;D&quot; for a reason. It's goal is to =
be distributed. Requiring atomic DELETEs would essentially hinder all =
but the most expensive of systems from being able to implement =
distributed namespaces across multiple physical servers. The reason =
being that the atomic requirement means that these systems will have to =
establish transactioning systems between themselves in order to issue =
DELETEs if they share namespace.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">As such I move that the atomic DELETE =
language be struck from the BIND spec on the grounds that it destroys =
interoperability, requires behavior that would preclude file system =
based systems from supporting WebDAV and significantly increases the =
cost of implementing WebDAV in a distributed manner.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01BF608B.6556491C--



From w3c-dist-auth-request@w3.org  Sun Jan 16 20:54:54 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12471
	for <webdav-archive@odin.ietf.org>; Sun, 16 Jan 2000 20:54:53 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA08683;
	Sun, 16 Jan 2000 20:44:11 -0500 (EST)
Resent-Date: Sun, 16 Jan 2000 20:44:11 -0500 (EST)
Resent-Message-Id: <200001170144.UAA08683@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E1C@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: w3c-dist-auth@w3.org
Date: Sun, 16 Jan 2000 17:43:14 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF608C.50FAF458"
Subject: WebDAV Bindings - Issue Yaron.AtomicMove
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3842
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF608C.50FAF458
Content-Type: text/plain;
	charset="iso-8859-1"

The last paragraph of section 8 reads: "Although [WebDAV] allows a MOVE on a
collection to be a non-atomic operation, the MOVE operation defined here
MUST be atomic.  Even when the Request-URI identifies a collection, the MOVE
operation involves only removing one binding to that collection and adding
another.  There are no operations on bindings to any of its children, so the
case of MOVE on a collection is the same as the case of MOVE on a
non-collection resource.  Both are atomic."

As there is no way to tell the difference between a URI that was mapped
through a BIND method and a URI that was mapped through a MKCOL the effect
of this paragraph is to re-write RFC 2518 to make MOVE atomic. The issue
here is largely a repeat of the issues addressed in Yaron.AtomicDelete.

An additional issue, beyond Yaron.AtomicDelete, is that MOVE in most file
systems is actually implemented as a copy followed by a delete, at least in
the case of directories. Hence file systems can not implement atomic moves.
Hence requiring atomic moves means that file systems can not implement
WebDAV.

Furthermore even though some of the more advanced file systems can handle
atomic MOVEs, they can only do so within a single volume. This would mean
that a server which had more than one file volume would have to refuse user
requests to move files across the volumes solely because it could not do so
atomically.

Finally, the title of DAV begins with a D for a very specific reason.
Requiring atomic behavior on MOVEs will prevent all but the highest end
systems from being able to MOVE files between systems because the
cooperating systems would have to implement a transactioning system between
themselves.

As such I move that the atomic MOVE language be struck from the BIND spec on
the grounds that it reduces interoperability, requires behavior that would
preclude file system based systems from supporting WebDAV and significantly
hinders WebDAV's ability to act in a distributed manner.

------_=_NextPart_001_01BF608C.50FAF458
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>WebDAV Bindings - Issue Yaron.AtomicMove</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">The last paragraph of section 8 reads: =
&quot;Although [WebDAV] allows a MOVE on a collection to be a =
non-atomic operation, the MOVE operation defined here MUST be =
atomic.&nbsp; Even when the Request-URI identifies a collection, the =
MOVE operation involves only removing one binding to that collection =
and adding another.&nbsp; There are no operations on bindings to any of =
its children, so the case of MOVE on a collection is the same as the =
case of MOVE on a non-collection resource.&nbsp; Both are =
atomic.&quot;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">As there is no way to tell the =
difference between a URI that was mapped through a BIND method and a =
URI that was mapped through a MKCOL the effect of this paragraph is to =
re-write RFC 2518 to make MOVE atomic. The issue here is largely a =
repeat of the issues addressed in Yaron.AtomicDelete.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">An additional issue, beyond =
Yaron.AtomicDelete, is that MOVE in most file systems is actually =
implemented as a copy followed by a delete, at least in the case of =
directories. Hence file systems can not implement atomic moves. Hence =
requiring atomic moves means that file systems can not implement =
WebDAV.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Furthermore even though some of the =
more advanced file systems can handle atomic MOVEs, they can only do so =
within a single volume. This would mean that a server which had more =
than one file volume would have to refuse user requests to move files =
across the volumes solely because it could not do so =
atomically.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Finally, the title of DAV begins with =
a D for a very specific reason. Requiring atomic behavior on MOVEs will =
prevent all but the highest end systems from being able to MOVE files =
between systems because the cooperating systems would have to implement =
a transactioning system between themselves.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">As such I move that the atomic MOVE =
language be struck from the BIND spec on the grounds that it reduces =
interoperability, requires behavior that would preclude file system =
based systems from supporting WebDAV and significantly hinders WebDAV's =
ability to act in a distributed manner.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01BF608C.50FAF458--



From w3c-dist-auth-request@w3.org  Sun Jan 16 20:57:20 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12489
	for <webdav-archive@odin.ietf.org>; Sun, 16 Jan 2000 20:57:19 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA09505;
	Sun, 16 Jan 2000 20:46:25 -0500 (EST)
Resent-Date: Sun, 16 Jan 2000 20:46:25 -0500 (EST)
Resent-Message-Id: <200001170146.UAA09505@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E16@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: w3c-dist-auth@w3.org
Date: Sun, 16 Jan 2000 17:45:30 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF608C.A1476784"
Subject: WebDAV Bindings - Issue Yaron.NoSlash
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3843
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF608C.A1476784
Content-Type: text/plain;
	charset="iso-8859-1"

The first sentence of section 5.1 reads: The BIND method creates a new
binding between the resource identified by the Request-URI and the final
segment of the Destination header (minus any trailing slash)." 

This requirement makes it impossible to directly address a collection in the
manner allowed by section 5.2 of RFC 2518. For example, if a user wishes to
bind the resource pointed to by http://foo/bar/blah to the name
http://icky/bicky/boo/ then the result of the bind method will be, due to
the removal of the trailing slash, a binding to "boo" instead of "boo/". The
second to last paragraph of section 5.2 of RFC 2518 states that
http://icky/bicky/boo/ and http://icky/bicky/boo SHOULD be the same resource
but are not required to be the same resource. Therefore the result of the
BIND method would be to cause a binding to http://icky/bicky/boo which may
be a completely different resource from the resource specified by the user,
http://ficky/bicky/boo/.

It would appear that the essential problem is that HTTP URLs can end in a
"/". In an ideal world this would not have been allowed. We would only use
"/" as a separator and therefore having it at the end of the a HTTP URL
wouldn't make any sense as there would be nothing to separate. This would
solve a lot of problems for WebDAV. Unfortunately the cat is already out of
the bag. RFC 2616 allows a "/" at the end of a URI. Implementers of RFC 2616
already use the "/" to mean a different resource from the slash less
version. Even RFC 2518 explicitly recognizes that the trailing slash and
non-trailing slash version of a HTTP URL may be different resources.
Therefore the BIND spec is directly violating RFC 2518. You absolutely can
not do this without at least pointing out, explicitly, that you are doing
this.

That having been said, what the hell? The trailing slash issue has been
dogging us forever. I would LOVE to upgrade the SHOULD in RFC 2518 to a
MUST. This, essentially, is what the BIND spec has done. But the onus is on
the BIND authors to prove that upgrading the requirement from a SHOULD to a
MUST won't cause an interoperability issue.

Therefore the BIND authors have, in my opinion, two options:

Option 1 - Change the BIND spec to allow a trailing slash and watch your
model get shredded as you attempt to deal with the semantics of a trailing
slash.

Option 2 - Keep the current language but add a note specifically stating
that you are violating RFC 2518 and, on the mailing list, provide a listing
of existing WebDAV client/server implementations and see if any of them
actually differentiate resources based on the trailing slash. If the answer
(as I suspect) is that no one differentiates based on the trailing "/" then
I think we have the basis for declaring consensus on the change. However, if
the authors fail to perform this analysis then I believe the chair MUST
strike down the BIND draft by declaring that in the absence of such an
analysis it is impossible to declare a consensus on the issue of upgrading
the SHOULD to a MUST. We can't use silence as a sign of assent on such a
serious change.

I move that we force the authors with threats of jeering and paying for
every IETF dinner from here to eternity to adopt Option 2 and free us from
the nonsense of the trailing slash.

			Yaron

P.S. The requirement that http://foo/blah/ and http://foo/blah point to the
same resource would ONLY apply to WebDAV compliant resources. So we are not
changing 2616. We are only saying "If you voluntarily choose to support
WebDAV THEN you must follow this rule." That way the only spec that needs to
change is 2518, NOT 2616. That having been said, I would LOVE to get 2616
changed to say this as well but I don't have enough free time on my hands to
push for this change to 2616.

P.P.S. Normally I would ante up under the rule of "put your money where your
mouth is" and do the analysis myself but I have to fly to Israel on the 19th
to make the last day of my Grand Father's Shiva. Unfortunately my schedule
is already completely filled and now I have to fly off to Israel at the last
second to attend to family duties. So I'm completely swamped until February.
So unless we want to hold up the spec until sometime in late February
someone else is going to have to perform the analysis. As it is I am sending
in my comments on the BIND spec during the weekend because I am so swamped.

------_=_NextPart_001_01BF608C.A1476784
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>WebDAV Bindings - Issue Yaron.NoSlash</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">The first sentence of section 5.1 =
reads: The BIND method creates a new binding between the resource =
identified by the Request-URI and the final segment of the Destination =
header (minus any trailing slash).&quot; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This requirement makes it impossible =
to directly address a collection in the manner allowed by section 5.2 =
of RFC 2518. For example, if a user wishes to bind the resource pointed =
to by <A HREF=3D"http://foo/bar/blah" =
TARGET=3D"_blank">http://foo/bar/blah</A> to the name <A =
HREF=3D"http://icky/bicky/boo/" =
TARGET=3D"_blank">http://icky/bicky/boo/</A> then the result of the =
bind method will be, due to the removal of the trailing slash, a =
binding to &quot;boo&quot; instead of &quot;boo/&quot;. The second to =
last paragraph of section 5.2 of RFC 2518 states that <A =
HREF=3D"http://icky/bicky/boo/" =
TARGET=3D"_blank">http://icky/bicky/boo/</A> and <A =
HREF=3D"http://icky/bicky/boo" =
TARGET=3D"_blank">http://icky/bicky/boo</A> SHOULD be the same resource =
but are not required to be the same resource. Therefore the result of =
the BIND method would be to cause a binding to <A =
HREF=3D"http://icky/bicky/boo" =
TARGET=3D"_blank">http://icky/bicky/boo</A> which may be a completely =
different resource from the resource specified by the user, <A =
HREF=3D"http://ficky/bicky/boo/" =
TARGET=3D"_blank">http://ficky/bicky/boo/</A>.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It would appear that the essential =
problem is that HTTP URLs can end in a &quot;/&quot;. In an ideal world =
this would not have been allowed. We would only use &quot;/&quot; as a =
separator and therefore having it at the end of the a HTTP URL wouldn't =
make any sense as there would be nothing to separate. This would solve =
a lot of problems for WebDAV. Unfortunately the cat is already out of =
the bag. RFC 2616 allows a &quot;/&quot; at the end of a URI. =
Implementers of RFC 2616 already use the &quot;/&quot; to mean a =
different resource from the slash less version. Even RFC 2518 =
explicitly recognizes that the trailing slash and non-trailing slash =
version of a HTTP URL may be different resources. Therefore the BIND =
spec is directly violating RFC 2518. You absolutely can not do this =
without at least pointing out, explicitly, that you are doing =
this.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">That having been said, what the hell? =
The trailing slash issue has been dogging us forever. I would LOVE to =
upgrade the SHOULD in RFC 2518 to a MUST. This, essentially, is what =
the BIND spec has done. But the onus is on the BIND authors to prove =
that upgrading the requirement from a SHOULD to a MUST won't cause an =
interoperability issue.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Therefore the BIND authors have, in my =
opinion, two options:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Option 1 - Change the BIND spec to =
allow a trailing slash and watch your model get shredded as you attempt =
to deal with the semantics of a trailing slash.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Option 2 - Keep the current language =
but add a note specifically stating that you are violating RFC 2518 =
and, on the mailing list, provide a listing of existing WebDAV =
client/server implementations and see if any of them actually =
differentiate resources based on the trailing slash. If the answer (as =
I suspect) is that no one differentiates based on the trailing =
&quot;/&quot; then I think we have the basis for declaring consensus on =
the change. However, if the authors fail to perform this analysis then =
I believe the chair MUST strike down the BIND draft by declaring that =
in the absence of such an analysis it is impossible to declare a =
consensus on the issue of upgrading the SHOULD to a MUST. We can't use =
silence as a sign of assent on such a serious change.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I move that we force the authors with =
threats of jeering and paying for every IETF dinner from here to =
eternity to adopt Option 2 and free us from the nonsense of the =
trailing slash.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Yaron</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">P.S. The requirement that <A =
HREF=3D"http://foo/blah/" TARGET=3D"_blank">http://foo/blah/</A> and <A =
HREF=3D"http://foo/blah" TARGET=3D"_blank">http://foo/blah</A> point to =
the same resource would ONLY apply to WebDAV compliant resources. So we =
are not changing 2616. We are only saying &quot;If you voluntarily =
choose to support WebDAV THEN you must follow this rule.&quot; That way =
the only spec that needs to change is 2518, NOT 2616. That having been =
said, I would LOVE to get 2616 changed to say this as well but I don't =
have enough free time on my hands to push for this change to =
2616.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">P.P.S. Normally I would ante up under =
the rule of &quot;put your money where your mouth is&quot; and do the =
analysis myself but I have to fly to Israel on the 19th to make the =
last day of my Grand Father's Shiva. Unfortunately my schedule is =
already completely filled and now I have to fly off to Israel at the =
last second to attend to family duties. So I'm completely swamped until =
February. So unless we want to hold up the spec until sometime in late =
February someone else is going to have to perform the analysis. As it =
is I am sending in my comments on the BIND spec during the weekend =
because I am so swamped.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01BF608C.A1476784--



From w3c-dist-auth-request@w3.org  Sun Jan 16 20:58:45 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12514
	for <webdav-archive@odin.ietf.org>; Sun, 16 Jan 2000 20:58:45 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA09711;
	Sun, 16 Jan 2000 20:47:58 -0500 (EST)
Resent-Date: Sun, 16 Jan 2000 20:47:58 -0500 (EST)
Resent-Message-Id: <200001170147.UAA09711@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E1A@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: w3c-dist-auth@w3.org
Date: Sun, 16 Jan 2000 17:47:00 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF608C.D89BDA26"
Subject: WebDAV Bindings - Issue Yaron.BindSyntax
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3844
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF608C.D89BDA26
Content-Type: text/plain;
	charset="iso-8859-1"

The BIND spec defines that a binding is created by sending a message to the
source and instructing it to create a binding at the destination. This is
completely consistent with how WebDAV normally operates in methods such as
COPY/MOVE where the source is instructed to make changes at the destination.
Unfortunately, in the case of BIND, it introduces a very serious problem
when (not if, but when) we introduce weak bindings. The problem is that the
current bind syntax requires the active participation of the source to
create a bind at the destination. In the case of a weak binding it is
expected that the source may not even be aware of the binding. This is one
of the main benefits of introducing weak bindings, it allows for bind like
behavior without requiring the participation of the source. This enables
many resources to have weak bindings against a resource without overloading
the resource.

An example may help here. Imagine a user wants to create a weak binding to
http://www.yahoo.com/foo/bar. Currently, to create this weak binding, the
user would have to issue the bind method to http://www.yahoo.com/foo/bar and
ask the Yahoo server to somehow communicate with the destination server and
create a weak binding. This is like telling people that before they can add
a hyperlink to their HTML document they have to first get the resource
pointed to by the hyperlink to somehow participate in the process. The
ability to link to resources without the knowledge of the source (as the
term is used in the BIND method) has been one of the key aspects of the
scalability of the Web.

In my mind the proper solution is to introduce a source header that, when
used on a BIND method, would mean that the request-URI specifies the
destination rather than the source.

That having been said I really have no desire to prolong the agony of the
BIND authors by asking them to add a new header and deal with all the
complexities it would introduce. As such I am happy to settle for the
following paragraph being added to section 5.1: "The BIND method MUST fail
if it does not include a destination header. Note, however, that future
specifications MAY introduce additional headers that resources could honor
in the place of the destination header and so allow the BIND method to
succeed in the absence of a destination header."

This would allow us, in the future, to introduce a weak binding spec that
could still use the BIND method without forcing us to use MAN or introduce a
new method.


------_=_NextPart_001_01BF608C.D89BDA26
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>WebDAV Bindings - Issue Yaron.BindSyntax</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">The BIND spec defines that a binding =
is created by sending a message to the source and instructing it to =
create a binding at the destination. This is completely consistent with =
how WebDAV normally operates in methods such as COPY/MOVE where the =
source is instructed to make changes at the destination. Unfortunately, =
in the case of BIND, it introduces a very serious problem when (not if, =
but when) we introduce weak bindings. The problem is that the current =
bind syntax requires the active participation of the source to create a =
bind at the destination. In the case of a weak binding it is expected =
that the source may not even be aware of the binding. This is one of =
the main benefits of introducing weak bindings, it allows for bind like =
behavior without requiring the participation of the source. This =
enables many resources to have weak bindings against a resource without =
overloading the resource.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">An example may help here. Imagine a =
user wants to create a weak binding to <A =
HREF=3D"http://www.yahoo.com/foo/bar" =
TARGET=3D"_blank">http://www.yahoo.com/foo/bar</A>. Currently, to =
create this weak binding, the user would have to issue the bind method =
to <A HREF=3D"http://www.yahoo.com/foo/bar" =
TARGET=3D"_blank">http://www.yahoo.com/foo/bar</A> and ask the Yahoo =
server to somehow communicate with the destination server and create a =
weak binding. This is like telling people that before they can add a =
hyperlink to their HTML document they have to first get the resource =
pointed to by the hyperlink to somehow participate in the process. The =
ability to link to resources without the knowledge of the source (as =
the term is used in the BIND method) has been one of the key aspects of =
the scalability of the Web.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In my mind the proper solution is to =
introduce a source header that, when used on a BIND method, would mean =
that the request-URI specifies the destination rather than the =
source.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">That having been said I really have no =
desire to prolong the agony of the BIND authors by asking them to add a =
new header and deal with all the complexities it would introduce. As =
such I am happy to settle for the following paragraph being added to =
section 5.1: &quot;The BIND method MUST fail if it does not include a =
destination header. Note, however, that future specifications MAY =
introduce additional headers that resources could honor in the place of =
the destination header and so allow the BIND method to succeed in the =
absence of a destination header.&quot;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This would allow us, in the future, to =
introduce a weak binding spec that could still use the BIND method =
without forcing us to use MAN or introduce a new method.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01BF608C.D89BDA26--



From w3c-dist-auth-request@w3.org  Sun Jan 16 20:59:31 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12525
	for <webdav-archive@odin.ietf.org>; Sun, 16 Jan 2000 20:59:31 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA10033;
	Sun, 16 Jan 2000 20:48:50 -0500 (EST)
Resent-Date: Sun, 16 Jan 2000 20:48:50 -0500 (EST)
Resent-Message-Id: <200001170148.UAA10033@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E19@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: w3c-dist-auth@w3.org
Date: Sun, 16 Jan 2000 17:47:55 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF608C.F7CC7D88"
Subject: WebDAV Bindings - Issue Yaron.403
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3845
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF608C.F7CC7D88
Content-Type: text/plain;
	charset="iso-8859-1"

Section 5.2 of the Bind spec instructs the reader that if a server wishes to
reject a BIND request because it would cause a loop then the server should
return a 403 (Forbidden). However 403 is overloaded as it is. For example, a
403 could mean that the method is banned at the moment for some reason even
though it is normally supported. This means that someone trying to write an
API to issue a BIND never really knows what a 403 means and so doesn't know
if they should tell the user that the server is currently just not going to
let the user perform this action or if the problem is that the action would
result in a loop. Therefore the use of 403 introduces a vagueness into the
response.
	Therefore I move that a new 4xx error code be introduced to cover
the case when a server refuses a BIND because it would cause a loop.

		Yaron

P.S. I think that the introduction of all these new error codes is a
mistake. A new error code should only be, in my opinion, introduced when it
provides a very high level error description that could be reasonably used
by members of the HTTP infrastructure, meaning firewalls and proxies.
Otherwise only the x00 errors should be used for everything and either new
headers or a body should be introduced to give detailed error information.
But I'm way too busy to try and push for this change so for the moment let's
just throw another error code on the barbie until people go insane with
them. It will be interesting to see how bad things have to become before we
can get this fixed.

------_=_NextPart_001_01BF608C.F7CC7D88
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>WebDAV Bindings - Issue Yaron.403</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Section 5.2 of the Bind spec instructs =
the reader that if a server wishes to reject a BIND request because it =
would cause a loop then the server should return a 403 (Forbidden). =
However 403 is overloaded as it is. For example, a 403 could mean that =
the method is banned at the moment for some reason even though it is =
normally supported. This means that someone trying to write an API to =
issue a BIND never really knows what a 403 means and so doesn't know if =
they should tell the user that the server is currently just not going =
to let the user perform this action or if the problem is that the =
action would result in a loop. Therefore the use of 403 introduces a =
vagueness into the response.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Therefore I move that a new 4xx error code be introduced =
to cover the case when a server refuses a BIND because it would cause a =
loop.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Yaron</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">P.S. I think that the introduction of =
all these new error codes is a mistake. A new error code should only =
be, in my opinion, introduced when it provides a very high level error =
description that could be reasonably used by members of the HTTP =
infrastructure, meaning firewalls and proxies. Otherwise only the x00 =
errors should be used for everything and either new headers or a body =
should be introduced to give detailed error information. But I'm way =
too busy to try and push for this change so for the moment let's just =
throw another error code on the barbie until people go insane with =
them. It will be interesting to see how bad things have to become =
before we can get this fixed.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01BF608C.F7CC7D88--



From w3c-dist-auth-request@w3.org  Sun Jan 16 21:00:08 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12544
	for <webdav-archive@odin.ietf.org>; Sun, 16 Jan 2000 21:00:08 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA10250;
	Sun, 16 Jan 2000 20:49:25 -0500 (EST)
Resent-Date: Sun, 16 Jan 2000 20:49:25 -0500 (EST)
Resent-Message-Id: <200001170149.UAA10250@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E17@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: w3c-dist-auth@w3.org
Date: Sun, 16 Jan 2000 17:48:28 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF608D.0CC0E88C"
Subject: WebDAV Bindings - Issue Yaron.ApplePie
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3846
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF608D.0CC0E88C
Content-Type: text/plain;
	charset="iso-8859-1"

The second to last paragraph of section 5.1 reads "After successful
processing of a BIND request, it MUST be possible for clients to use the URI
in the Destination header to submit requests to the resource identified by
the Request-URI." This is a motherhood and apple pie requirement. It sounds
good but in practice it doesn't enhance interoperability. What does it mean
to "submit requests"? What period of time is covered by "After"? For
example, if user A successfully issues a BIND and then user B using FTP
deletes the mapped in resource and when user A tries to "submit requests" to
the resource the requests fail, is the system in non-compliance? There is no
way to tell the difference between the previous scenario and a scenario in
which the system accepted the BIND and decided to do nothing with it. This
is called being a sucky server but such behavior has absolutely no effect on
interoperability because it is indistinguishable from the original example I
provided about User A & B.

As such I move that this paragraph be removed from the draft.

------_=_NextPart_001_01BF608D.0CC0E88C
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>WebDAV Bindings - Issue Yaron.ApplePie</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">The second to last paragraph of =
section 5.1 reads &quot;After successful processing of a BIND request, =
it MUST be possible for clients to use the URI in the Destination =
header to submit requests to the resource identified by the =
Request-URI.&quot; This is a motherhood and apple pie requirement. It =
sounds good but in practice it doesn't enhance interoperability. What =
does it mean to &quot;submit requests&quot;? What period of time is =
covered by &quot;After&quot;? For example, if user A successfully =
issues a BIND and then user B using FTP deletes the mapped in resource =
and when user A tries to &quot;submit requests&quot; to the resource =
the requests fail, is the system in non-compliance? There is no way to =
tell the difference between the previous scenario and a scenario in =
which the system accepted the BIND and decided to do nothing with it. =
This is called being a sucky server but such behavior has absolutely no =
effect on interoperability because it is indistinguishable from the =
original example I provided about User A &amp; B.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">As such I move that this paragraph be =
removed from the draft.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF608D.0CC0E88C--



From w3c-dist-auth-request@w3.org  Sun Jan 16 21:00:57 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12564
	for <webdav-archive@odin.ietf.org>; Sun, 16 Jan 2000 21:00:57 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA10582;
	Sun, 16 Jan 2000 20:50:13 -0500 (EST)
Resent-Date: Sun, 16 Jan 2000 20:50:13 -0500 (EST)
Resent-Message-Id: <200001170150.UAA10582@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E15@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: w3c-dist-auth@w3.org
Date: Sun, 16 Jan 2000 17:49:15 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF608D.291A5EB4"
Subject: WebDAV Bindings - Issue Yaron.MrIntegrity
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3847
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF608D.291A5EB4
Content-Type: text/plain;
	charset="iso-8859-1"

The last sentence of the last paragraph of section 4 reads "Implementations
MUST ensure the integrity of bindings." Similar language is used in the
second paragraph of section 5.1. However the term "integrity" was never well
defined inside of the specification. As such it is impossible to comply with
this requirement in an interoperable way. I would strongly caution against
attempting to specify the definition for integrity, English is much too
inexact a language for such an attempt to be successful.
	As such, I move that both sentences be removed and be replaced with
a series of statements that define, in exact language, the requirements that
are to be represented by the term "integrity", each sentence properly
qualified with a MUST.

------_=_NextPart_001_01BF608D.291A5EB4
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>WebDAV Bindings - Issue Yaron.MrIntegrity</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">The last sentence of the last =
paragraph of section 4 reads &quot;Implementations MUST ensure the =
integrity of bindings.&quot; Similar language is used in the second =
paragraph of section 5.1. However the term &quot;integrity&quot; was =
never well defined inside of the specification. As such it is =
impossible to comply with this requirement in an interoperable way. I =
would strongly caution against attempting to specify the definition for =
integrity, English is much too inexact a language for such an attempt =
to be successful.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">As such, I move that both sentences be removed and be =
replaced with a series of statements that define, in exact language, =
the requirements that are to be represented by the term =
&quot;integrity&quot;, each sentence properly qualified with a =
MUST.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01BF608D.291A5EB4--



From w3c-dist-auth-request@w3.org  Sun Jan 16 21:02:04 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12630
	for <webdav-archive@odin.ietf.org>; Sun, 16 Jan 2000 21:02:04 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA10824;
	Sun, 16 Jan 2000 20:50:59 -0500 (EST)
Resent-Date: Sun, 16 Jan 2000 20:50:59 -0500 (EST)
Resent-Message-Id: <200001170150.UAA10824@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E20@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: w3c-dist-auth@w3.org
Date: Sun, 16 Jan 2000 17:50:00 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF608D.43EA70DA"
Subject: WebDAV Bindings - Issue Yaron.PublishBind
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3848
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF608D.43EA70DA
Content-Type: text/plain;
	charset="iso-8859-1"

The spec refers to the redirect resource draft, even attempting to refer to
its RFC number. This means that the bind spec can not be published as an RFC
until the redirect resource draft is approved. While it is nice to point out
that the redirect resource draft exists I can find no compelling reason to
mention it when doing so restricts the schedule for the Bind draft's
standardization. Therefore I move that all references to the redirect
resource draft be stricken from the Bind spec, specifically the removal of
the last paragraph of the abstract, the 2nd, 4th and 5th to last paragraphs
of the Introduction and the reference [RR].

------_=_NextPart_001_01BF608D.43EA70DA
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>WebDAV Bindings - Issue Yaron.PublishBind</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">The spec refers to the redirect =
resource draft, even attempting to refer to its RFC number. This means =
that the bind spec can not be published as an RFC until the redirect =
resource draft is approved. While it is nice to point out that the =
redirect resource draft exists I can find no compelling reason to =
mention it when doing so restricts the schedule for the Bind draft's =
standardization. Therefore I move that all references to the redirect =
resource draft be stricken from the Bind spec, specifically the removal =
of the last paragraph of the abstract, the 2nd, 4th and 5th to last =
paragraphs of the Introduction and the reference [RR].</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01BF608D.43EA70DA--



From w3c-dist-auth-request@w3.org  Sun Jan 16 21:02:31 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12641
	for <webdav-archive@odin.ietf.org>; Sun, 16 Jan 2000 21:02:31 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA11042;
	Sun, 16 Jan 2000 20:51:46 -0500 (EST)
Resent-Date: Sun, 16 Jan 2000 20:51:46 -0500 (EST)
Resent-Message-Id: <200001170151.UAA11042@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E21@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: w3c-dist-auth@w3.org
Date: Sun, 16 Jan 2000 17:50:48 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF608D.602C0F7E"
Subject: WebDAV Bindings - Issue Yaron.WeScrewedUp
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3849
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF608D.602C0F7E
Content-Type: text/plain;
	charset="iso-8859-1"

The bind draft makes a heroic attempt to map its philosophy of the naming
relationships of collections and resources to the statements made in the
WebDAV spec. The end result are sections like the "Internal Member URI"
section. Unfortunately the attempts to try and reverse engineer the WebDAV
language into something sensible only makes the draft significantly more
confusing to the reader. I think the optimal solution would be to remove the
language attempting to explain how one could make some sense out of WebDAV
and instead say "WebDAV was wrong, we are right, just read this." For the
truly dedicated we can add the "internal member URI" section to the appendix
where it, along with WebDAV's mistakes, will hopefully be soon forgotten.
	BTW, we should obviously fix the WebDAV draft but that will take a
while and I can't think of a good reason to hold the bind draft up until
that happens. Therefore the bind draft should introduce the new language and
we will roll that language into WebDAV at the appropriate time.
	As such I propose that ALL mentions of "Internal Member URIs" be
stricken from the main body of the spec and only be mentioned, if at all, in
an appendix.


------_=_NextPart_001_01BF608D.602C0F7E
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>WebDAV Bindings - Issue Yaron.WeScrewedUp</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">The bind draft makes a heroic attempt =
to map its philosophy of the naming relationships of collections and =
resources to the statements made in the WebDAV spec. The end result are =
sections like the &quot;Internal Member URI&quot; section. =
Unfortunately the attempts to try and reverse engineer the WebDAV =
language into something sensible only makes the draft significantly =
more confusing to the reader. I think the optimal solution would be to =
remove the language attempting to explain how one could make some sense =
out of WebDAV and instead say &quot;WebDAV was wrong, we are right, =
just read this.&quot; For the truly dedicated we can add the =
&quot;internal member URI&quot; section to the appendix where it, along =
with WebDAV's mistakes, will hopefully be soon forgotten.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">BTW, we should obviously fix the WebDAV draft but that =
will take a while and I can't think of a good reason to hold the bind =
draft up until that happens. Therefore the bind draft should introduce =
the new language and we will roll that language into WebDAV at the =
appropriate time.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">As such I propose that ALL mentions of &quot;Internal =
Member URIs&quot; be stricken from the main body of the spec and only =
be mentioned, if at all, in an appendix.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01BF608D.602C0F7E--



From w3c-dist-auth-request@w3.org  Sun Jan 16 21:02:44 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12652
	for <webdav-archive@odin.ietf.org>; Sun, 16 Jan 2000 21:02:43 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA11270;
	Sun, 16 Jan 2000 20:52:00 -0500 (EST)
Resent-Date: Sun, 16 Jan 2000 20:52:00 -0500 (EST)
Resent-Message-Id: <200001170152.UAA11270@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E22@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: w3c-dist-auth@w3.org
Date: Sun, 16 Jan 2000 17:51:01 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF608D.6848AFB4"
Subject: WebDAV Bindings - Issue Yaron.4Huh?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3850
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF608D.6848AFB4
Content-Type: text/plain;
	charset="iso-8859-1"

I have read the following sentence three times from section 4 and I still
can't figure out what it means - "The URI segment associated with a resource
by one of a collection's bindings is also the final segment of one or more
of the collection's internal member URIs." This is probably because it
mentions 'internal member URI'. If we adopt Yaron:WeScrewedUp then this
issue becomes irrelevant. Otherwise I move that this sentence be re-written.

------_=_NextPart_001_01BF608D.6848AFB4
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>WebDAV Bindings - Issue Yaron.4Huh?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have read the following sentence =
three times from section 4 and I still can't figure out what it means - =
&quot;The URI segment associated with a resource by one of a =
collection's bindings is also the final segment of one or more of the =
collection's internal member URIs.&quot; This is probably because it =
mentions 'internal member URI'. If we adopt Yaron:WeScrewedUp then this =
issue becomes irrelevant. Otherwise I move that this sentence be =
re-written.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01BF608D.6848AFB4--



From w3c-dist-auth-request@w3.org  Sun Jan 16 21:03:30 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12663
	for <webdav-archive@odin.ietf.org>; Sun, 16 Jan 2000 21:03:30 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA11738;
	Sun, 16 Jan 2000 20:52:49 -0500 (EST)
Resent-Date: Sun, 16 Jan 2000 20:52:49 -0500 (EST)
Resent-Message-Id: <200001170152.UAA11738@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E23@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: w3c-dist-auth@w3.org
Date: Sun, 16 Jan 2000 17:51:50 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF608D.859EDF20"
Subject: WebDAV Bindings - Issue Yaron.5.3Huh?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3851
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF608D.859EDF20
Content-Type: text/plain;
	charset="iso-8859-1"

The first paragraph of section 5.3 reads "Suppose a BIND request causes a
binding from "Binding-Name" to resource R to be added to a collection, C.
Then if C-MAP is the set of URI's that were mapped to C before the BIND
request, then for each URI "C-URI" in C-MAP, the URI "C-URI/Binding-Name" is
mapped to resource R following the BIND request." 
	I have a B.S. in CS & EE and got A's in my classes on set theory and
I still can't read this paragraph. I tried over and over again and I just
couldn't figure it out. If you are going to try to write set theory in
English you should at least translate it faithfully using the appropriate
terms such as "for all" and "there is an instance of". Personally I would
recommend just using an ASCII version of set code notation. Whatever you do,
the current paragraph MUST go. It is unfathomable. In fact here is the best
translation I have been able to come up with: Imagine I have a collection
http://icky/bop which contains http://icky/bop/blah. Imagine I now want to
map http://zizbang/rocky to http://icky/bop/rack. According to this language
it would seem I would have to create a bind to http://icky/bop/blah/rack. I
know this makes no sense but I swear that is what the sentence seemed to
mean when I tried to read it four or five times. As such I move that the
paragraph be rewritten.



------_=_NextPart_001_01BF608D.859EDF20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>WebDAV Bindings - Issue Yaron.5.3Huh?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">The first paragraph of section 5.3 =
reads &quot;Suppose a BIND request causes a binding from =
&quot;Binding-Name&quot; to resource R to be added to a collection, =
C.&nbsp; Then if C-MAP is the set of URI's that were mapped to C before =
the BIND request, then for each URI &quot;C-URI&quot; in C-MAP, the URI =
&quot;C-URI/Binding-Name&quot; is mapped to resource R following the =
BIND request.&quot; </FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">I have a B.S. in CS &amp; EE and got A's in my classes =
on set theory and I still can't read this paragraph. I tried over and =
over again and I just couldn't figure it out. If you are going to try =
to write set theory in English you should at least translate it =
faithfully using the appropriate terms such as &quot;for all&quot; and =
&quot;there is an instance of&quot;. Personally I would recommend just =
using an ASCII version of set code notation. Whatever you do, the =
current paragraph MUST go. It is unfathomable. In fact here is the best =
translation I have been able to come up with: Imagine I have a =
collection <A HREF=3D"http://icky/bop" =
TARGET=3D"_blank">http://icky/bop</A> which contains <A =
HREF=3D"http://icky/bop/blah" =
TARGET=3D"_blank">http://icky/bop/blah</A>. Imagine I now want to map =
<A HREF=3D"http://zizbang/rocky" =
TARGET=3D"_blank">http://zizbang/rocky</A> to <A =
HREF=3D"http://icky/bop/rack" =
TARGET=3D"_blank">http://icky/bop/rack</A>. According to this language =
it would seem I would have to create a bind to <A =
HREF=3D"http://icky/bop/blah/rack" =
TARGET=3D"_blank">http://icky/bop/blah/rack</A>. I know this makes no =
sense but I swear that is what the sentence seemed to mean when I tried =
to read it four or five times. As such I move that the paragraph be =
rewritten.</FONT></P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BF608D.859EDF20--



From w3c-dist-auth-request@w3.org  Sun Jan 16 21:04:00 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12674
	for <webdav-archive@odin.ietf.org>; Sun, 16 Jan 2000 21:04:00 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA12063;
	Sun, 16 Jan 2000 20:53:18 -0500 (EST)
Resent-Date: Sun, 16 Jan 2000 20:53:18 -0500 (EST)
Resent-Message-Id: <200001170153.UAA12063@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E24@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: w3c-dist-auth@w3.org
Date: Sun, 16 Jan 2000 17:52:20 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF608D.9763E5E8"
Subject: WebDAV Bindings - Issue Yaron.5.4Huh?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3852
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF608D.9763E5E8
Content-Type: text/plain;
	charset="iso-8859-1"

I had to read the example in section 5.4 a bunch of times before I finally,
slowly, started to understand what it said. It is written in such an obscure
manner that it was really difficult to follow what it was saying. Please,
please, please, re-write it! I will try to find time to do a rewrite myself
but right now I need to focus in on getting out these comments in order to
make sure the issue is on the table. As such I move that the paragraph be
rewritten.

------_=_NextPart_001_01BF608D.9763E5E8
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>WebDAV Bindings - Issue Yaron.5.4Huh?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">I had to read the example in section =
5.4 a bunch of times before I finally, slowly, started to understand =
what it said. It is written in such an obscure manner that it was =
really difficult to follow what it was saying. Please, please, please, =
re-write it! I will try to find time to do a rewrite myself but right =
now I need to focus in on getting out these comments in order to make =
sure the issue is on the table. As such I move that the paragraph be =
rewritten.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01BF608D.9763E5E8--



From w3c-dist-auth-request@w3.org  Sun Jan 16 21:04:53 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12685
	for <webdav-archive@odin.ietf.org>; Sun, 16 Jan 2000 21:04:52 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA12386;
	Sun, 16 Jan 2000 20:54:11 -0500 (EST)
Resent-Date: Sun, 16 Jan 2000 20:54:11 -0500 (EST)
Resent-Message-Id: <200001170154.UAA12386@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E25@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: w3c-dist-auth@w3.org
Date: Sun, 16 Jan 2000 17:53:14 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF608D.B670C604"
Subject: WebDAV Bindings - Issue Yaron.507
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3853
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF608D.B670C604
Content-Type: text/plain;
	charset="iso-8859-1"

In section 5.5 the 507 error code is written as "507 (Cross-Server Binding
Forbidden): The server is unable to create the requested binding because it
would bind a segment in a collection on one server to a resource on a
different server." 
	What does a server have to do with anything? If you try to bind two
resources in different volumes on a FrontPage server the server will have to
fail the BIND even though the resources are on the same server. In general
bringing in the server is almost always a bad idea since resources can be
spread out all over the place and the reasons for various failures may or
may not have anything to do with how those resources are laid out on the
servers. As such I move that the language for the 507 error code be altered
to read that the resource was unable to create a binding to a destination
and to leave the matter at that. All mentions of the word server should be
stricken.

------_=_NextPart_001_01BF608D.B670C604
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>WebDAV Bindings - Issue Yaron.507</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">In section 5.5 the 507 error code is =
written as &quot;507 (Cross-Server Binding Forbidden): The server is =
unable to create the requested binding because it would bind a segment =
in a collection on one server to a resource on a different =
server.&quot; </FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">What does a server have to do with anything? If you try =
to bind two resources in different volumes on a FrontPage server the =
server will have to fail the BIND even though the resources are on the =
same server. In general bringing in the server is almost always a bad =
idea since resources can be spread out all over the place and the =
reasons for various failures may or may not have anything to do with =
how those resources are laid out on the servers. As such I move that =
the language for the 507 error code be altered to read that the =
resource was unable to create a binding to a destination and to leave =
the matter at that. All mentions of the word server should be =
stricken.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01BF608D.B670C604--



From w3c-dist-auth-request@w3.org  Mon Jan 17 13:03:00 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04927
	for <webdav-archive@odin.ietf.org>; Mon, 17 Jan 2000 13:03:00 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA10993;
	Mon, 17 Jan 2000 12:50:12 -0500 (EST)
Resent-Date: Mon, 17 Jan 2000 12:50:12 -0500 (EST)
Resent-Message-Id: <200001171750.MAA10993@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E26@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: w3c-dist-auth@w3.org
Date: Mon, 17 Jan 2000 09:43:06 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF6113.3C34726A"
Subject: WebDAV Bindings - Issue Yaron.Insulting2616
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3854
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6113.3C34726A
Content-Type: text/plain;
	charset="iso-8859-1"

The language used in the first paragraph of section 6 makes certain
assertions regarding the intentions of the authors of RFC 2616 that I
believe may not necessarily be accurate. As such I move that the authors of
the BIND spec send an e-mail to all the authors of RFC 2616 and ask them to
validate the accuracy of the proposed language.

------_=_NextPart_001_01BF6113.3C34726A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>WebDAV Bindings - Issue Yaron.Insulting2616</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">The language used in the first =
paragraph of section 6 makes certain assertions regarding the =
intentions of the authors of RFC 2616 that I believe may not =
necessarily be accurate. As such I move that the authors of the BIND =
spec send an e-mail to all the authors of RFC 2616 and ask them to =
validate the accuracy of the proposed language.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01BF6113.3C34726A--



From w3c-dist-auth-request@w3.org  Mon Jan 17 14:43:36 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07250
	for <webdav-archive@odin.ietf.org>; Mon, 17 Jan 2000 14:43:36 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA15875;
	Mon, 17 Jan 2000 14:30:18 -0500 (EST)
Resent-Date: Mon, 17 Jan 2000 14:30:18 -0500 (EST)
Resent-Message-Id: <200001171930.OAA15875@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at gremlin-relay.ics.uci.edu
Cc: Roy Fielding <fielding@ics.uci.edu>
Date: Mon, 17 Jan 2000 11:26:29 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJEECFCMAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0004_01BF60DD.B2ED5380"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <7DE119D3D0E15543874F7561EECBDBED02619E26@BEG.platinum.corp.microsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: RE: WebDAV Bindings - Issue Yaron.Insulting2616
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3855
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This is a multi-part message in MIME format.

------=_NextPart_000_0004_01BF60DD.B2ED5380
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

WebDAV Bindings - Issue Yaron.Insulting2616I currently have an email pending
with Roy Fielding asking him about this issue.

- Jim
  -----Original Message-----
  From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Yaron Goland
  Sent: Monday, January 17, 2000 9:43 AM
  To: w3c-dist-auth@w3.org
  Subject: WebDAV Bindings - Issue Yaron.Insulting2616


  The language used in the first paragraph of section 6 makes certain
assertions regarding the intentions of the authors of RFC 2616 that I
believe may not necessarily be accurate. As such I move that the authors of
the BIND spec send an e-mail to all the authors of RFC 2616 and ask them to
validate the accuracy of the proposed language.


------=_NextPart_000_0004_01BF60DD.B2ED5380
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>WebDAV Bindings - Issue Yaron.Insulting2616</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D700422519-17012000>I=20
currently have an email&nbsp;pending with Roy Fielding asking him about =
this=20
issue.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D700422519-17012000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D700422519-17012000>-=20
Jim</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
w3c-dist-auth-request@w3.org=20
  [mailto:w3c-dist-auth-request@w3.org]<B>On Behalf Of </B>Yaron=20
  Goland<BR><B>Sent:</B> Monday, January 17, 2000 9:43 AM<BR><B>To:</B>=20
  w3c-dist-auth@w3.org<BR><B>Subject:</B> WebDAV Bindings - Issue=20
  Yaron.Insulting2616<BR><BR></DIV></FONT>
  <P><FONT face=3DArial size=3D2>The language used in the first =
paragraph of section=20
  6 makes certain assertions regarding the intentions of the authors of =
RFC 2616=20
  that I believe may not necessarily be accurate. As such I move that =
the=20
  authors of the BIND spec send an e-mail to all the authors of RFC 2616 =
and ask=20
  them to validate the accuracy of the proposed=20
language.</FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0004_01BF60DD.B2ED5380--



From w3c-dist-auth-request@w3.org  Mon Jan 17 14:48:35 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07389
	for <webdav-archive@odin.ietf.org>; Mon, 17 Jan 2000 14:48:34 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA16889;
	Mon, 17 Jan 2000 14:37:07 -0500 (EST)
Resent-Date: Mon, 17 Jan 2000 14:37:07 -0500 (EST)
Resent-Message-Id: <200001171937.OAA16889@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at gremlin-relay.ics.uci.edu
Date: Mon, 17 Jan 2000 11:33:18 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJKECFCMAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <7DE119D3D0E15543874F7561EECBDBED02619E21@BEG.platinum.corp.microsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: RE: WebDAV Bindings - Issue Yaron.WeScrewedUp
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3856
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

I'm comfortable with moving this section to an appendix.  This section is
only needed for reconciling the collection terminology of RFC 2518 with the
terminology in the binding specification, not for understanding the spec.
itself, and hence the reconciliation langugage could easily be moved to an
appendix.

- Jim

-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Yaron Goland
Sent: Sunday, January 16, 2000 5:51 PM
To: w3c-dist-auth@w3.org
Subject: WebDAV Bindings - Issue Yaron.WeScrewedUp


The bind draft makes a heroic attempt to map its philosophy of the naming
relationships of collections and resources to the statements made in the
WebDAV spec. The end result are sections like the "Internal Member URI"
section. Unfortunately the attempts to try and reverse engineer the WebDAV
language into something sensible only makes the draft significantly more
confusing to the reader. I think the optimal solution would be to remove the
language attempting to explain how one could make some sense out of WebDAV
and instead say "WebDAV was wrong, we are right, just read this." For the
truly dedicated we can add the "internal member URI" section to the appendix
where it, along with WebDAV's mistakes, will hopefully be soon forgotten.
        BTW, we should obviously fix the WebDAV draft but that will take a
while and I can't think of a good reason to hold the bind draft up until
that happens. Therefore the bind draft should introduce the new language and
we will roll that language into WebDAV at the appropriate time.
        As such I propose that ALL mentions of "Internal Member URIs" be
stricken from the main body of the spec and only be mentioned, if at all, in
an appendix.



From w3c-dist-auth-request@w3.org  Mon Jan 17 14:48:42 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07401
	for <webdav-archive@odin.ietf.org>; Mon, 17 Jan 2000 14:48:41 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA17030;
	Mon, 17 Jan 2000 14:37:44 -0500 (EST)
Resent-Date: Mon, 17 Jan 2000 14:37:44 -0500 (EST)
Resent-Message-Id: <200001171937.OAA17030@www19.w3.org>
Message-ID: <018001bf6122$77087ad0$79442382@us.oracle.com>
From: "Eric Sedlar" <esedlar@us.oracle.com>
To: "Yaron Goland" <yarong@Exchange.Microsoft.com>, <w3c-dist-auth@w3.org>
References: <7DE119D3D0E15543874F7561EECBDBED02619E1A@BEG.platinum.corp.microsoft.com>
Date: Mon, 17 Jan 2000 11:38:44 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_017D_01BF60DF.68BD8E90"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: Re: WebDAV Bindings - Issue Yaron.BindSyntax
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3857
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This is a multi-part message in MIME format.

------=_NextPart_000_017D_01BF60DF.68BD8E90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

WebDAV Bindings - Issue Yaron.BindSyntaxIt depends on the kind of weak =
binding you want.  If it's something like a symbolic link, redirect =
references work reasonably well for that.  If you want a weak binding =
(weak, in that it is not affecting the persistence of the item being =
bound) that doesn't dangle, you have to notify the source, so that it =
can send the destination an event when the source is deleted.

--Eric
  ----- Original Message -----=20
  From: Yaron Goland=20
  To: w3c-dist-auth@w3.org=20
  Sent: Sunday, January 16, 2000 5:47 PM
  Subject: WebDAV Bindings - Issue Yaron.BindSyntax


  The BIND spec defines that a binding is created by sending a message =
to the source and instructing it to create a binding at the destination. =
This is completely consistent with how WebDAV normally operates in =
methods such as COPY/MOVE where the source is instructed to make changes =
at the destination. Unfortunately, in the case of BIND, it introduces a =
very serious problem when (not if, but when) we introduce weak bindings. =
The problem is that the current bind syntax requires the active =
participation of the source to create a bind at the destination. In the =
case of a weak binding it is expected that the source may not even be =
aware of the binding. This is one of the main benefits of introducing =
weak bindings, it allows for bind like behavior without requiring the =
participation of the source. This enables many resources to have weak =
bindings against a resource without overloading the resource.

  An example may help here. Imagine a user wants to create a weak =
binding to http://www.yahoo.com/foo/bar. Currently, to create this weak =
binding, the user would have to issue the bind method to =
http://www.yahoo.com/foo/bar and ask the Yahoo server to somehow =
communicate with the destination server and create a weak binding. This =
is like telling people that before they can add a hyperlink to their =
HTML document they have to first get the resource pointed to by the =
hyperlink to somehow participate in the process. The ability to link to =
resources without the knowledge of the source (as the term is used in =
the BIND method) has been one of the key aspects of the scalability of =
the Web.

  In my mind the proper solution is to introduce a source header that, =
when used on a BIND method, would mean that the request-URI specifies =
the destination rather than the source.

  That having been said I really have no desire to prolong the agony of =
the BIND authors by asking them to add a new header and deal with all =
the complexities it would introduce. As such I am happy to settle for =
the following paragraph being added to section 5.1: "The BIND method =
MUST fail if it does not include a destination header. Note, however, =
that future specifications MAY introduce additional headers that =
resources could honor in the place of the destination header and so =
allow the BIND method to succeed in the absence of a destination =
header."

  This would allow us, in the future, to introduce a weak binding spec =
that could still use the BIND method without forcing us to use MAN or =
introduce a new method.


------=_NextPart_000_017D_01BF60DF.68BD8E90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>WebDAV Bindings - Issue Yaron.BindSyntax</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>It depends on the kind of weak binding =
you=20
want.&nbsp; If it's something like a symbolic link, redirect references =
work=20
reasonably well for that.&nbsp; If you want a weak binding (weak, in =
that it is=20
not affecting the persistence of the item being bound) that doesn't =
dangle, you=20
have to notify the source, so that it can send the destination an event =
when the=20
source is deleted.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>--Eric</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:yarong@Exchange.Microsoft.com"=20
  title=3Dyarong@Exchange.Microsoft.com>Yaron Goland</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:w3c-dist-auth@w3.org"=20
  title=3Dw3c-dist-auth@w3.org>w3c-dist-auth@w3.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, January 16, 2000 =
5:47=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> WebDAV Bindings - =
Issue=20
  Yaron.BindSyntax</DIV>
  <DIV><BR></DIV>
  <P><FONT face=3DArial size=3D2>The BIND spec defines that a binding is =
created by=20
  sending a message to the source and instructing it to create a binding =
at the=20
  destination. This is completely consistent with how WebDAV normally =
operates=20
  in methods such as COPY/MOVE where the source is instructed to make =
changes at=20
  the destination. Unfortunately, in the case of BIND, it introduces a =
very=20
  serious problem when (not if, but when) we introduce weak bindings. =
The=20
  problem is that the current bind syntax requires the active =
participation of=20
  the source to create a bind at the destination. In the case of a weak =
binding=20
  it is expected that the source may not even be aware of the binding. =
This is=20
  one of the main benefits of introducing weak bindings, it allows for =
bind like=20
  behavior without requiring the participation of the source. This =
enables many=20
  resources to have weak bindings against a resource without overloading =
the=20
  resource.</FONT></P>
  <P><FONT face=3DArial size=3D2>An example may help here. Imagine a =
user wants to=20
  create a weak binding to <A href=3D"http://www.yahoo.com/foo/bar"=20
  target=3D_blank>http://www.yahoo.com/foo/bar</A>. Currently, to create =
this weak=20
  binding, the user would have to issue the bind method to <A=20
  href=3D"http://www.yahoo.com/foo/bar"=20
  target=3D_blank>http://www.yahoo.com/foo/bar</A> and ask the Yahoo =
server to=20
  somehow communicate with the destination server and create a weak =
binding.=20
  This is like telling people that before they can add a hyperlink to =
their HTML=20
  document they have to first get the resource pointed to by the =
hyperlink to=20
  somehow participate in the process. The ability to link to resources =
without=20
  the knowledge of the source (as the term is used in the BIND method) =
has been=20
  one of the key aspects of the scalability of the Web.</FONT></P>
  <P><FONT face=3DArial size=3D2>In my mind the proper solution is to =
introduce a=20
  source header that, when used on a BIND method, would mean that the=20
  request-URI specifies the destination rather than the =
source.</FONT></P>
  <P><FONT face=3DArial size=3D2>That having been said I really have no =
desire to=20
  prolong the agony of the BIND authors by asking them to add a new =
header and=20
  deal with all the complexities it would introduce. As such I am happy =
to=20
  settle for the following paragraph being added to section 5.1: "The =
BIND=20
  method MUST fail if it does not include a destination header. Note, =
however,=20
  that future specifications MAY introduce additional headers that =
resources=20
  could honor in the place of the destination header and so allow the =
BIND=20
  method to succeed in the absence of a destination header."</FONT></P>
  <P><FONT face=3DArial size=3D2>This would allow us, in the future, to =
introduce a=20
  weak binding spec that could still use the BIND method without forcing =
us to=20
  use MAN or introduce a new =
method.</FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_017D_01BF60DF.68BD8E90--



From w3c-dist-auth-request@w3.org  Mon Jan 17 14:54:59 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07703
	for <webdav-archive@odin.ietf.org>; Mon, 17 Jan 2000 14:54:58 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA18195;
	Mon, 17 Jan 2000 14:44:01 -0500 (EST)
Resent-Date: Mon, 17 Jan 2000 14:44:01 -0500 (EST)
Resent-Message-Id: <200001171944.OAA18195@www19.w3.org>
Message-ID: <01c701bf6123$565d7be0$79442382@us.oracle.com>
From: "Eric Sedlar" <esedlar@us.oracle.com>
To: "Yaron Goland" <yarong@Exchange.Microsoft.com>, <w3c-dist-auth@w3.org>
References: <7DE119D3D0E15543874F7561EECBDBED02619E14@BEG.platinum.corp.microsoft.com>
Date: Mon, 17 Jan 2000 11:44:57 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_01C4_01BF60E0.471DF670"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: Re: Review of Bindings
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3858
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This is a multi-part message in MIME format.

------=_NextPart_000_01C4_01BF60E0.471DF670
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Review of BindingsI second all of Yaron's motions, with the exception of =
Yaron.BindSyntax (addressed separately) and Yaron.Insulting2616, which I =
have no comment on.

--Eric
  ----- Original Message -----=20
  From: Yaron Goland=20
  To: w3c-dist-auth@w3.org=20
  Sent: Sunday, January 16, 2000 5:24 PM
  Subject: Review of Bindings


  I have just finished a detailed review of the bindings spec.=20

  After having given it a lot of thought I have come to agree with the =
conclusions given in the bind spec, the WebDAV collection model is =
broken and needs to be fixed. I further agree that the proposed model in =
BIND is a definite improvement. While I'm still not convinced of some of =
the mostly philosophical details (is a bind recorded in the collection =
or on the resource?, for example), none of these details are =
sufficiently weighty to merit holding up the spec. If we find that some =
of the niggling issues aren't correct then we will fix it later.

  After reviewing the draft I find that I have 17 issues. I have =
identified each issue with a name. Following WebDAV mailing list =
tradition each issue is addressed in its own letter.

  The complete list of issues I am raising, in no particular order, are: =


  Yaron.PublishBind=20
  Yaron.WeScrewedUp=20
  Yaron.4Huh?=20
  Yaron.5.3Huh?=20
  Yaron.5.4Huh?=20
  Yaron.507=20
  Yaron.Insulting2616=20
  Yaron.AtomicMove=20
  Yaron.AtomicDelete=20
  Yaron.NoSlash=20
  Yaron.BindSyntax=20
  Yaron.403=20
  Yaron.ApplePie=20
  Yaron.MrIntegrity=20
  Yaron.ApplePie3=20
  Yaron.BindingsProperty=20
  Yaron.ApplePieToo=20


------=_NextPart_000_01C4_01BF60E0.471DF670
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Review of Bindings</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I second all of Yaron's motions, with =
the=20
exception</FONT><FONT face=3DArial size=3D2> of Yaron.BindSyntax =
(addressed=20
separately) and Yaron.Insulting2616, which I have no comment =
on.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>--Eric</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:yarong@Exchange.Microsoft.com"=20
  title=3Dyarong@Exchange.Microsoft.com>Yaron Goland</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:w3c-dist-auth@w3.org"=20
  title=3Dw3c-dist-auth@w3.org>w3c-dist-auth@w3.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, January 16, 2000 =
5:24=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Review of =
Bindings</DIV>
  <DIV><BR></DIV>
  <P><FONT face=3DArial size=3D2>I have just finished a detailed review =
of the=20
  bindings spec.</FONT> </P>
  <P><FONT face=3DArial size=3D2>After having given it a lot of thought =
I have come=20
  to agree with the conclusions given in the bind spec, the WebDAV =
collection=20
  model is broken and needs to be fixed. I further agree that the =
proposed model=20
  in BIND is a definite improvement. While I'm still not convinced of =
some of=20
  the mostly philosophical details (is a bind recorded in the collection =
or on=20
  the resource?, for example), none of these details are sufficiently =
weighty to=20
  merit holding up the spec. If we find that some of the niggling issues =
aren't=20
  correct then we will fix it later.</FONT></P>
  <P><FONT face=3DArial size=3D2>After reviewing the draft I find that I =
have 17=20
  issues. I have identified each issue with a name. Following WebDAV =
mailing=20
  list tradition each issue is addressed in its own letter.</FONT></P>
  <P><FONT face=3DArial size=3D2>The complete list of issues I am =
raising, in no=20
  particular order, are:</FONT> </P>
  <P><FONT face=3DArial size=3D2>Yaron.PublishBind</FONT> <BR><FONT =
face=3DArial=20
  size=3D2>Yaron.WeScrewedUp</FONT> <BR><FONT face=3DArial =
size=3D2>Yaron.4Huh?</FONT>=20
  <BR><FONT face=3DArial size=3D2>Yaron.5.3Huh?</FONT> <BR><FONT =
face=3DArial=20
  size=3D2>Yaron.5.4Huh?</FONT> <BR><FONT face=3DArial =
size=3D2>Yaron.507</FONT>=20
  <BR><FONT face=3DArial size=3D2>Yaron.Insulting2616</FONT> <BR><FONT =
face=3DArial=20
  size=3D2>Yaron.AtomicMove</FONT> <BR><FONT face=3DArial=20
  size=3D2>Yaron.AtomicDelete</FONT> <BR><FONT face=3DArial=20
  size=3D2>Yaron.NoSlash</FONT> <BR><FONT face=3DArial=20
  size=3D2>Yaron.BindSyntax</FONT> <BR><FONT face=3DArial =
size=3D2>Yaron.403</FONT>=20
  <BR><FONT face=3DArial size=3D2>Yaron.ApplePie</FONT> <BR><FONT =
face=3DArial=20
  size=3D2>Yaron.MrIntegrity</FONT> <BR><FONT face=3DArial=20
  size=3D2>Yaron.ApplePie3</FONT> <BR><FONT face=3DArial=20
  size=3D2>Yaron.BindingsProperty</FONT> <BR><FONT face=3DArial=20
  size=3D2>Yaron.ApplePieToo</FONT> </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_01C4_01BF60E0.471DF670--



From w3c-dist-auth-request@w3.org  Mon Jan 17 15:13:53 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08039
	for <webdav-archive@odin.ietf.org>; Mon, 17 Jan 2000 15:13:52 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA19901;
	Mon, 17 Jan 2000 15:02:46 -0500 (EST)
Resent-Date: Mon, 17 Jan 2000 15:02:46 -0500 (EST)
Resent-Message-Id: <200001172002.PAA19901@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E27@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'Eric Sedlar'" <esedlar@us.oracle.com>, w3c-dist-auth@w3.org
Date: Mon, 17 Jan 2000 12:01:33 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF6125.CE113382"
Subject: RE: WebDAV Bindings - Issue Yaron.BindSyntax
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3859
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6125.CE113382
Content-Type: text/plain;
	charset="iso-8859-1"

What I am specifically looking for is the ability to have the server handle
all conversations with the resource on my behalf but with the possibility of
dangling references.
 
For example, I want to be able to create a collection that contains a bunch
of weak links to random resources all over the planet. Then I want to issue
a depth infinity PROPFIND against that collection and get back a bunch of
properties. In the background what is happening is that the server is
actually going out and performing the PROPFIND on my behalf to the
destination resources. However my experience as a client is that I make a
single PROPFIND request and get back a single PROPFIND result. This sort of
behavior is very important when dealing with very limited clients (hand
helds for example) or when using a very high latency link (wireless).
 
I am NOT suggesting that this group adopt a weak link of this type. At least
not yet. What I am proposing is that the language I suggested be put into
the BIND spec so that if we WANT to create links of this type we are ABLE to
do so.
 
In other words, I am not asking for consensus that the type of link I want
to create is a good idea. I am just asking that we put in language in the
BIND spec that will allow us to create a link of this type at a later date
if we choose to do so. Since the proposed language would not cause ANY
change in the way a BIND client/server behaves I can't think of a good
reason to refuse my request.

-----Original Message-----
From: Eric Sedlar [mailto:esedlar@us.oracle.com]
Sent: Mon, January 17, 2000 11:39 AM
To: Yaron Goland; w3c-dist-auth@w3.org
Subject: Re: WebDAV Bindings - Issue Yaron.BindSyntax


It depends on the kind of weak binding you want.  If it's something like a
symbolic link, redirect references work reasonably well for that.  If you
want a weak binding (weak, in that it is not affecting the persistence of
the item being bound) that doesn't dangle, you have to notify the source, so
that it can send the destination an event when the source is deleted.
 
--Eric

----- Original Message ----- 
From: Yaron Goland <mailto:yarong@Exchange.Microsoft.com>  
To: w3c-dist-auth@w3.org <mailto:w3c-dist-auth@w3.org>  
Sent: Sunday, January 16, 2000 5:47 PM
Subject: WebDAV Bindings - Issue Yaron.BindSyntax


The BIND spec defines that a binding is created by sending a message to the
source and instructing it to create a binding at the destination. This is
completely consistent with how WebDAV normally operates in methods such as
COPY/MOVE where the source is instructed to make changes at the destination.
Unfortunately, in the case of BIND, it introduces a very serious problem
when (not if, but when) we introduce weak bindings. The problem is that the
current bind syntax requires the active participation of the source to
create a bind at the destination. In the case of a weak binding it is
expected that the source may not even be aware of the binding. This is one
of the main benefits of introducing weak bindings, it allows for bind like
behavior without requiring the participation of the source. This enables
many resources to have weak bindings against a resource without overloading
the resource.

An example may help here. Imagine a user wants to create a weak binding to
http://www.yahoo.com/foo/bar <http://www.yahoo.com/foo/bar> . Currently, to
create this weak binding, the user would have to issue the bind method to
http://www.yahoo.com/foo/bar <http://www.yahoo.com/foo/bar>  and ask the
Yahoo server to somehow communicate with the destination server and create a
weak binding. This is like telling people that before they can add a
hyperlink to their HTML document they have to first get the resource pointed
to by the hyperlink to somehow participate in the process. The ability to
link to resources without the knowledge of the source (as the term is used
in the BIND method) has been one of the key aspects of the scalability of
the Web.

In my mind the proper solution is to introduce a source header that, when
used on a BIND method, would mean that the request-URI specifies the
destination rather than the source.

That having been said I really have no desire to prolong the agony of the
BIND authors by asking them to add a new header and deal with all the
complexities it would introduce. As such I am happy to settle for the
following paragraph being added to section 5.1: "The BIND method MUST fail
if it does not include a destination header. Note, however, that future
specifications MAY introduce additional headers that resources could honor
in the place of the destination header and so allow the BIND method to
succeed in the absence of a destination header."

This would allow us, in the future, to introduce a weak binding spec that
could still use the BIND method without forcing us to use MAN or introduce a
new method.


------_=_NextPart_001_01BF6125.CE113382
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>WebDAV Bindings - Issue Yaron.BindSyntax</TITLE>

<META content="MSHTML 5.00.2920.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=064375419-17012000>What I 
am specifically looking for is the ability to have the server handle all 
conversations with the resource on my behalf but with the possibility of 
dangling references.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=064375419-17012000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=064375419-17012000>For 
example, I want to be able to create a collection that contains a bunch of weak 
links to random resources all over the planet. Then I want to issue a depth 
infinity PROPFIND against that collection and get back a bunch of properties. In 
the background what is happening is that the server is actually going out and 
performing the PROPFIND on my behalf to the destination resources. However my 
experience as a client is that I make a single PROPFIND request and get back a 
single PROPFIND result. This sort of behavior is very important when dealing 
with very limited clients (hand helds for example) or when using a very high 
latency link (wireless).</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=064375419-17012000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=064375419-17012000>I am 
NOT suggesting that this group adopt a weak link of this type. At least not yet. 
What I am proposing is that the language I suggested be put into the BIND spec 
so that if we WANT to create links of this type we are ABLE to do 
so.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=064375419-17012000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=064375419-17012000>In 
other words, I am not asking for consensus that the type of link I want to 
create is a good idea. I am just asking that we put in language in the BIND spec 
that will allow us to create a link of this type at a later date if we choose to 
do so. Since the proposed language would not cause ANY change in the way a BIND 
client/server behaves I can't think of a good reason to refuse my 
request.</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Eric Sedlar 
  [mailto:esedlar@us.oracle.com]<BR><B>Sent:</B> Mon, January 17, 2000 11:39 
  AM<BR><B>To:</B> Yaron Goland; w3c-dist-auth@w3.org<BR><B>Subject:</B> Re: 
  WebDAV Bindings - Issue Yaron.BindSyntax<BR><BR></DIV></FONT>
  <DIV><FONT face=Arial size=2>It depends on the kind of weak binding you 
  want.&nbsp; If it's something like a symbolic link, redirect references work 
  reasonably well for that.&nbsp; If you want a weak binding (weak, in that it 
  is not affecting the persistence of the item being bound) that doesn't dangle, 
  you have to notify the source, so that it can send the destination an event 
  when the source is deleted.</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>--Eric</FONT></DIV>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
    <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV 
    style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
    <A href="mailto:yarong@Exchange.Microsoft.com" 
    title=yarong@Exchange.Microsoft.com>Yaron Goland</A> </DIV>
    <DIV style="FONT: 10pt arial"><B>To:</B> <A 
    href="mailto:w3c-dist-auth@w3.org" 
    title=w3c-dist-auth@w3.org>w3c-dist-auth@w3.org</A> </DIV>
    <DIV style="FONT: 10pt arial"><B>Sent:</B> Sunday, January 16, 2000 5:47 
    PM</DIV>
    <DIV style="FONT: 10pt arial"><B>Subject:</B> WebDAV Bindings - Issue 
    Yaron.BindSyntax</DIV>
    <DIV><BR></DIV>
    <P><FONT face=Arial size=2>The BIND spec defines that a binding is created 
    by sending a message to the source and instructing it to create a binding at 
    the destination. This is completely consistent with how WebDAV normally 
    operates in methods such as COPY/MOVE where the source is instructed to make 
    changes at the destination. Unfortunately, in the case of BIND, it 
    introduces a very serious problem when (not if, but when) we introduce weak 
    bindings. The problem is that the current bind syntax requires the active 
    participation of the source to create a bind at the destination. In the case 
    of a weak binding it is expected that the source may not even be aware of 
    the binding. This is one of the main benefits of introducing weak bindings, 
    it allows for bind like behavior without requiring the participation of the 
    source. This enables many resources to have weak bindings against a resource 
    without overloading the resource.</FONT></P>
    <P><FONT face=Arial size=2>An example may help here. Imagine a user wants to 
    create a weak binding to <A href="http://www.yahoo.com/foo/bar" 
    target=_blank>http://www.yahoo.com/foo/bar</A>. Currently, to create this 
    weak binding, the user would have to issue the bind method to <A 
    href="http://www.yahoo.com/foo/bar" 
    target=_blank>http://www.yahoo.com/foo/bar</A> and ask the Yahoo server to 
    somehow communicate with the destination server and create a weak binding. 
    This is like telling people that before they can add a hyperlink to their 
    HTML document they have to first get the resource pointed to by the 
    hyperlink to somehow participate in the process. The ability to link to 
    resources without the knowledge of the source (as the term is used in the 
    BIND method) has been one of the key aspects of the scalability of the 
    Web.</FONT></P>
    <P><FONT face=Arial size=2>In my mind the proper solution is to introduce a 
    source header that, when used on a BIND method, would mean that the 
    request-URI specifies the destination rather than the source.</FONT></P>
    <P><FONT face=Arial size=2>That having been said I really have no desire to 
    prolong the agony of the BIND authors by asking them to add a new header and 
    deal with all the complexities it would introduce. As such I am happy to 
    settle for the following paragraph being added to section 5.1: "The BIND 
    method MUST fail if it does not include a destination header. Note, however, 
    that future specifications MAY introduce additional headers that resources 
    could honor in the place of the destination header and so allow the BIND 
    method to succeed in the absence of a destination header."</FONT></P>
    <P><FONT face=Arial size=2>This would allow us, in the future, to introduce 
    a weak binding spec that could still use the BIND method without forcing us 
    to use MAN or introduce a new 
method.</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BF6125.CE113382--



From w3c-dist-auth-request@w3.org  Mon Jan 17 15:17:25 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08084
	for <webdav-archive@odin.ietf.org>; Mon, 17 Jan 2000 15:17:24 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA20287;
	Mon, 17 Jan 2000 15:06:29 -0500 (EST)
Resent-Date: Mon, 17 Jan 2000 15:06:29 -0500 (EST)
Resent-Message-Id: <200001172006.PAA20287@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A0BC@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'Jim Whitehead'" <ejw@ics.uci.edu>, w3c-dist-auth@w3.org
Cc: Roy Fielding <fielding@ics.uci.edu>
Date: Mon, 17 Jan 2000 12:05:27 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF6126.540C1916"
Subject: RE: WebDAV Bindings - Issue Yaron.Insulting2616
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3860
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6126.540C1916
Content-Type: text/plain;
	charset="iso-8859-1"

With all due respect, I think ALL of the 2616 authors should have a chance
to respond as they all are indicted by your comments.

-----Original Message-----
From: Jim Whitehead [mailto:ejw@ics.uci.edu]
Sent: Mon, January 17, 2000 11:26 AM
To: w3c-dist-auth@w3.org
Cc: Roy Fielding
Subject: RE: WebDAV Bindings - Issue Yaron.Insulting2616


I currently have an email pending with Roy Fielding asking him about this
issue.
 
- Jim

-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Yaron Goland
Sent: Monday, January 17, 2000 9:43 AM
To: w3c-dist-auth@w3.org
Subject: WebDAV Bindings - Issue Yaron.Insulting2616



The language used in the first paragraph of section 6 makes certain
assertions regarding the intentions of the authors of RFC 2616 that I
believe may not necessarily be accurate. As such I move that the authors of
the BIND spec send an e-mail to all the authors of RFC 2616 and ask them to
validate the accuracy of the proposed language.


------_=_NextPart_001_01BF6126.540C1916
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>WebDAV Bindings - Issue Yaron.Insulting2616</TITLE>

<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=348270520-17012000>With 
all due respect, I think ALL of the 2616 authors should have a chance to respond 
as they all are indicted by your comments.</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Jim Whitehead 
  [mailto:ejw@ics.uci.edu]<BR><B>Sent:</B> Mon, January 17, 2000 11:26 
  AM<BR><B>To:</B> w3c-dist-auth@w3.org<BR><B>Cc:</B> Roy 
  Fielding<BR><B>Subject:</B> RE: WebDAV Bindings - Issue 
  Yaron.Insulting2616<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=700422519-17012000>I 
  currently have an email&nbsp;pending with Roy Fielding asking him about this 
  issue.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=700422519-17012000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=700422519-17012000>- 
  Jim</SPAN></FONT></DIV>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> 
    w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]<B>On 
    Behalf Of </B>Yaron Goland<BR><B>Sent:</B> Monday, January 17, 2000 9:43 
    AM<BR><B>To:</B> w3c-dist-auth@w3.org<BR><B>Subject:</B> WebDAV Bindings - 
    Issue Yaron.Insulting2616<BR><BR></DIV></FONT>
    <P><FONT face=Arial size=2>The language used in the first paragraph of 
    section 6 makes certain assertions regarding the intentions of the authors 
    of RFC 2616 that I believe may not necessarily be accurate. As such I move 
    that the authors of the BIND spec send an e-mail to all the authors of RFC 
    2616 and ask them to validate the accuracy of the proposed 
    language.</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BF6126.540C1916--



From w3c-dist-auth-request@w3.org  Mon Jan 17 15:33:19 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08322
	for <webdav-archive@odin.ietf.org>; Mon, 17 Jan 2000 15:33:18 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA21343;
	Mon, 17 Jan 2000 15:22:16 -0500 (EST)
Resent-Date: Mon, 17 Jan 2000 15:22:16 -0500 (EST)
Resent-Message-Id: <200001172022.PAA21343@www19.w3.org>
Message-ID: <023e01bf6127$d2136b10$79442382@us.oracle.com>
From: "Eric Sedlar" <esedlar@us.oracle.com>
To: "Yaron Goland" <yarong@Exchange.Microsoft.com>, <w3c-dist-auth@w3.org>
References: <7DE119D3D0E15543874F7561EECBDBED02619E27@BEG.platinum.corp.microsoft.com>
Date: Mon, 17 Jan 2000 12:17:00 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0238_01BF60E4.C1B30C50"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: Re: WebDAV Bindings - Issue Yaron.BindSyntax
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3861
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This is a multi-part message in MIME format.

------=_NextPart_000_0238_01BF60E4.C1B30C50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

WebDAV Bindings - Issue Yaron.BindSyntaxSounds like a good idea, and I'm =
in favor of it.  However, one of your statements was:

"Unfortunately, in the case of BIND, it introduces a very serious =
problem when (not if, but when) we introduce weak bindings."

I'm just pointing out that you're only addressing a particular class of =
weak bindings, which weakens your "not if, but when" statement as it =
applies to your proposal.

--Eric
  ----- Original Message -----=20
  From: Yaron Goland=20
  To: 'Eric Sedlar' ; w3c-dist-auth@w3.org=20
  Sent: Monday, January 17, 2000 12:01 PM
  Subject: RE: WebDAV Bindings - Issue Yaron.BindSyntax


  What I am specifically looking for is the ability to have the server =
handle all conversations with the resource on my behalf but with the =
possibility of dangling references.
  =20
  For example, I want to be able to create a collection that contains a =
bunch of weak links to random resources all over the planet. Then I want =
to issue a depth infinity PROPFIND against that collection and get back =
a bunch of properties. In the background what is happening is that the =
server is actually going out and performing the PROPFIND on my behalf to =
the destination resources. However my experience as a client is that I =
make a single PROPFIND request and get back a single PROPFIND result. =
This sort of behavior is very important when dealing with very limited =
clients (hand helds for example) or when using a very high latency link =
(wireless).
  =20
  I am NOT suggesting that this group adopt a weak link of this type. At =
least not yet. What I am proposing is that the language I suggested be =
put into the BIND spec so that if we WANT to create links of this type =
we are ABLE to do so.
  =20
  In other words, I am not asking for consensus that the type of link I =
want to create is a good idea. I am just asking that we put in language =
in the BIND spec that will allow us to create a link of this type at a =
later date if we choose to do so. Since the proposed language would not =
cause ANY change in the way a BIND client/server behaves I can't think =
of a good reason to refuse my request.
    -----Original Message-----
    From: Eric Sedlar [mailto:esedlar@us.oracle.com]
    Sent: Mon, January 17, 2000 11:39 AM
    To: Yaron Goland; w3c-dist-auth@w3.org
    Subject: Re: WebDAV Bindings - Issue Yaron.BindSyntax


    It depends on the kind of weak binding you want.  If it's something =
like a symbolic link, redirect references work reasonably well for that. =
 If you want a weak binding (weak, in that it is not affecting the =
persistence of the item being bound) that doesn't dangle, you have to =
notify the source, so that it can send the destination an event when the =
source is deleted.

    --Eric
      ----- Original Message -----=20
      From: Yaron Goland=20
      To: w3c-dist-auth@w3.org=20
      Sent: Sunday, January 16, 2000 5:47 PM
      Subject: WebDAV Bindings - Issue Yaron.BindSyntax


      The BIND spec defines that a binding is created by sending a =
message to the source and instructing it to create a binding at the =
destination. This is completely consistent with how WebDAV normally =
operates in methods such as COPY/MOVE where the source is instructed to =
make changes at the destination. Unfortunately, in the case of BIND, it =
introduces a very serious problem when (not if, but when) we introduce =
weak bindings. The problem is that the current bind syntax requires the =
active participation of the source to create a bind at the destination. =
In the case of a weak binding it is expected that the source may not =
even be aware of the binding. This is one of the main benefits of =
introducing weak bindings, it allows for bind like behavior without =
requiring the participation of the source. This enables many resources =
to have weak bindings against a resource without overloading the =
resource.

      An example may help here. Imagine a user wants to create a weak =
binding to http://www.yahoo.com/foo/bar. Currently, to create this weak =
binding, the user would have to issue the bind method to =
http://www.yahoo.com/foo/bar and ask the Yahoo server to somehow =
communicate with the destination server and create a weak binding. This =
is like telling people that before they can add a hyperlink to their =
HTML document they have to first get the resource pointed to by the =
hyperlink to somehow participate in the process. The ability to link to =
resources without the knowledge of the source (as the term is used in =
the BIND method) has been one of the key aspects of the scalability of =
the Web.

      In my mind the proper solution is to introduce a source header =
that, when used on a BIND method, would mean that the request-URI =
specifies the destination rather than the source.

      That having been said I really have no desire to prolong the agony =
of the BIND authors by asking them to add a new header and deal with all =
the complexities it would introduce. As such I am happy to settle for =
the following paragraph being added to section 5.1: "The BIND method =
MUST fail if it does not include a destination header. Note, however, =
that future specifications MAY introduce additional headers that =
resources could honor in the place of the destination header and so =
allow the BIND method to succeed in the absence of a destination =
header."

      This would allow us, in the future, to introduce a weak binding =
spec that could still use the BIND method without forcing us to use MAN =
or introduce a new method.


------=_NextPart_000_0238_01BF60E4.C1B30C50
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>WebDAV Bindings - Issue Yaron.BindSyntax</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Sounds like a good idea, and I'm in =
favor of=20
it.&nbsp; However, one of your statements was:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>"Unfortunately, in the case of BIND, it =
introduces=20
a very serious problem when (not if, but when) we introduce weak=20
bindings."</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I'm just pointing out that you're only =
addressing a=20
particular class of weak bindings, which weakens your "not if, but when" =

statement as it applies to your proposal.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>--Eric</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:yarong@Exchange.Microsoft.com"=20
  title=3Dyarong@Exchange.Microsoft.com>Yaron Goland</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  href=3D"mailto:esedlar@us.oracle.com" =
title=3Desedlar@us.oracle.com>'Eric=20
  Sedlar'</A> ; <A href=3D"mailto:w3c-dist-auth@w3.org"=20
  title=3Dw3c-dist-auth@w3.org>w3c-dist-auth@w3.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, January 17, 2000 =
12:01=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: WebDAV Bindings - =
Issue=20
  Yaron.BindSyntax</DIV>
  <DIV><BR></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D064375419-17012000>What=20
  I am specifically looking for is the ability to have the server handle =
all=20
  conversations with the resource on my behalf but with the possibility =
of=20
  dangling references.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D064375419-17012000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D064375419-17012000>For=20
  example, I want to be able to create a collection that contains a =
bunch of=20
  weak links to random resources all over the planet. Then I want to =
issue a=20
  depth infinity PROPFIND against that collection and get back a bunch =
of=20
  properties. In the background what is happening is that the server is =
actually=20
  going out and performing the PROPFIND on my behalf to the destination=20
  resources. However my experience as a client is that I make a single =
PROPFIND=20
  request and get back a single PROPFIND result. This sort of behavior =
is very=20
  important when dealing with very limited clients (hand helds for =
example) or=20
  when using a very high latency link (wireless).</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D064375419-17012000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D064375419-17012000>I am=20
  NOT suggesting that this group adopt a weak link of this type. At =
least not=20
  yet. What I am proposing is that the language I suggested be put into =
the BIND=20
  spec so that if we WANT to create links of this type we are ABLE to do =

  so.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D064375419-17012000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D064375419-17012000>In=20
  other words, I am not asking for consensus that the type of link I =
want to=20
  create is a good idea. I am just asking that we put in language in the =
BIND=20
  spec that will allow us to create a link of this type at a later date =
if we=20
  choose to do so. Since the proposed language would not cause ANY =
change in the=20
  way a BIND client/server behaves I can't think of a good reason to =
refuse my=20
  request.</SPAN></FONT></DIV>
  <BLOCKQUOTE=20
  style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Eric Sedlar=20
    [mailto:esedlar@us.oracle.com]<BR><B>Sent:</B> Mon, January 17, 2000 =
11:39=20
    AM<BR><B>To:</B> Yaron Goland; =
w3c-dist-auth@w3.org<BR><B>Subject:</B> Re:=20
    WebDAV Bindings - Issue Yaron.BindSyntax<BR><BR></DIV></FONT>
    <DIV><FONT face=3DArial size=3D2>It depends on the kind of weak =
binding you=20
    want.&nbsp; If it's something like a symbolic link, redirect =
references work=20
    reasonably well for that.&nbsp; If you want a weak binding (weak, in =
that it=20
    is not affecting the persistence of the item being bound) that =
doesn't=20
    dangle, you have to notify the source, so that it can send the =
destination=20
    an event when the source is deleted.</FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>--Eric</FONT></DIV>
    <BLOCKQUOTE=20
    style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
      <DIV style=3D"FONT: 10pt arial">----- Original Message ----- =
</DIV>
      <DIV=20
      style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
      <A href=3D"mailto:yarong@Exchange.Microsoft.com"=20
      title=3Dyarong@Exchange.Microsoft.com>Yaron Goland</A> </DIV>
      <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
      href=3D"mailto:w3c-dist-auth@w3.org"=20
      title=3Dw3c-dist-auth@w3.org>w3c-dist-auth@w3.org</A> </DIV>
      <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, January 16, =
2000 5:47=20
      PM</DIV>
      <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> WebDAV Bindings - =
Issue=20
      Yaron.BindSyntax</DIV>
      <DIV><BR></DIV>
      <P><FONT face=3DArial size=3D2>The BIND spec defines that a =
binding is created=20
      by sending a message to the source and instructing it to create a =
binding=20
      at the destination. This is completely consistent with how WebDAV =
normally=20
      operates in methods such as COPY/MOVE where the source is =
instructed to=20
      make changes at the destination. Unfortunately, in the case of =
BIND, it=20
      introduces a very serious problem when (not if, but when) we =
introduce=20
      weak bindings. The problem is that the current bind syntax =
requires the=20
      active participation of the source to create a bind at the =
destination. In=20
      the case of a weak binding it is expected that the source may not =
even be=20
      aware of the binding. This is one of the main benefits of =
introducing weak=20
      bindings, it allows for bind like behavior without requiring the=20
      participation of the source. This enables many resources to have =
weak=20
      bindings against a resource without overloading the =
resource.</FONT></P>
      <P><FONT face=3DArial size=3D2>An example may help here. Imagine a =
user wants=20
      to create a weak binding to <A =
href=3D"http://www.yahoo.com/foo/bar"=20
      target=3D_blank>http://www.yahoo.com/foo/bar</A>. Currently, to =
create this=20
      weak binding, the user would have to issue the bind method to <A=20
      href=3D"http://www.yahoo.com/foo/bar"=20
      target=3D_blank>http://www.yahoo.com/foo/bar</A> and ask the Yahoo =
server to=20
      somehow communicate with the destination server and create a weak =
binding.=20
      This is like telling people that before they can add a hyperlink =
to their=20
      HTML document they have to first get the resource pointed to by =
the=20
      hyperlink to somehow participate in the process. The ability to =
link to=20
      resources without the knowledge of the source (as the term is used =
in the=20
      BIND method) has been one of the key aspects of the scalability of =
the=20
      Web.</FONT></P>
      <P><FONT face=3DArial size=3D2>In my mind the proper solution is =
to introduce=20
      a source header that, when used on a BIND method, would mean that =
the=20
      request-URI specifies the destination rather than the =
source.</FONT></P>
      <P><FONT face=3DArial size=3D2>That having been said I really have =
no desire=20
      to prolong the agony of the BIND authors by asking them to add a =
new=20
      header and deal with all the complexities it would introduce. As =
such I am=20
      happy to settle for the following paragraph being added to section =
5.1:=20
      "The BIND method MUST fail if it does not include a destination =
header.=20
      Note, however, that future specifications MAY introduce additional =
headers=20
      that resources could honor in the place of the destination header =
and so=20
      allow the BIND method to succeed in the absence of a destination=20
      header."</FONT></P>
      <P><FONT face=3DArial size=3D2>This would allow us, in the future, =
to=20
      introduce a weak binding spec that could still use the BIND method =
without=20
      forcing us to use MAN or introduce a new=20
  =
method.</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0238_01BF60E4.C1B30C50--



From w3c-dist-auth-request@w3.org  Mon Jan 17 15:33:21 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08325
	for <webdav-archive@odin.ietf.org>; Mon, 17 Jan 2000 15:33:19 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA21337;
	Mon, 17 Jan 2000 15:22:15 -0500 (EST)
Resent-Date: Mon, 17 Jan 2000 15:22:15 -0500 (EST)
Resent-Message-Id: <200001172022.PAA21337@www19.w3.org>
Message-ID: <023f01bf6127$d2e7d210$79442382@us.oracle.com>
From: "Eric Sedlar" <esedlar@us.oracle.com>
To: "Yaron Goland" <yarong@Exchange.Microsoft.com>, <w3c-dist-auth@w3.org>
References: <7DE119D3D0E15543874F7561EECBDBED02619E27@BEG.platinum.corp.microsoft.com>
Date: Mon, 17 Jan 2000 12:17:03 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_023B_01BF60E4.C31A3D70"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: Re: WebDAV Bindings - Issue Yaron.BindSyntax
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3862
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This is a multi-part message in MIME format.

------=_NextPart_000_023B_01BF60E4.C31A3D70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

WebDAV Bindings - Issue Yaron.BindSyntaxSounds like a good idea, and I'm =
in favor of it.  However, one of your statements was:

"Unfortunately, in the case of BIND, it introduces a very serious =
problem when (not if, but when) we introduce weak bindings."

I'm just pointing out that you're only addressing a particular class of =
weak bindings, which weakens your "not if, but when" statement as it =
applies to your proposal.

--Eric
  ----- Original Message -----=20
  From: Yaron Goland=20
  To: 'Eric Sedlar' ; w3c-dist-auth@w3.org=20
  Sent: Monday, January 17, 2000 12:01 PM
  Subject: RE: WebDAV Bindings - Issue Yaron.BindSyntax


  What I am specifically looking for is the ability to have the server =
handle all conversations with the resource on my behalf but with the =
possibility of dangling references.
  =20
  For example, I want to be able to create a collection that contains a =
bunch of weak links to random resources all over the planet. Then I want =
to issue a depth infinity PROPFIND against that collection and get back =
a bunch of properties. In the background what is happening is that the =
server is actually going out and performing the PROPFIND on my behalf to =
the destination resources. However my experience as a client is that I =
make a single PROPFIND request and get back a single PROPFIND result. =
This sort of behavior is very important when dealing with very limited =
clients (hand helds for example) or when using a very high latency link =
(wireless).
  =20
  I am NOT suggesting that this group adopt a weak link of this type. At =
least not yet. What I am proposing is that the language I suggested be =
put into the BIND spec so that if we WANT to create links of this type =
we are ABLE to do so.
  =20
  In other words, I am not asking for consensus that the type of link I =
want to create is a good idea. I am just asking that we put in language =
in the BIND spec that will allow us to create a link of this type at a =
later date if we choose to do so. Since the proposed language would not =
cause ANY change in the way a BIND client/server behaves I can't think =
of a good reason to refuse my request.
    -----Original Message-----
    From: Eric Sedlar [mailto:esedlar@us.oracle.com]
    Sent: Mon, January 17, 2000 11:39 AM
    To: Yaron Goland; w3c-dist-auth@w3.org
    Subject: Re: WebDAV Bindings - Issue Yaron.BindSyntax


    It depends on the kind of weak binding you want.  If it's something =
like a symbolic link, redirect references work reasonably well for that. =
 If you want a weak binding (weak, in that it is not affecting the =
persistence of the item being bound) that doesn't dangle, you have to =
notify the source, so that it can send the destination an event when the =
source is deleted.

    --Eric
      ----- Original Message -----=20
      From: Yaron Goland=20
      To: w3c-dist-auth@w3.org=20
      Sent: Sunday, January 16, 2000 5:47 PM
      Subject: WebDAV Bindings - Issue Yaron.BindSyntax


      The BIND spec defines that a binding is created by sending a =
message to the source and instructing it to create a binding at the =
destination. This is completely consistent with how WebDAV normally =
operates in methods such as COPY/MOVE where the source is instructed to =
make changes at the destination. Unfortunately, in the case of BIND, it =
introduces a very serious problem when (not if, but when) we introduce =
weak bindings. The problem is that the current bind syntax requires the =
active participation of the source to create a bind at the destination. =
In the case of a weak binding it is expected that the source may not =
even be aware of the binding. This is one of the main benefits of =
introducing weak bindings, it allows for bind like behavior without =
requiring the participation of the source. This enables many resources =
to have weak bindings against a resource without overloading the =
resource.

      An example may help here. Imagine a user wants to create a weak =
binding to http://www.yahoo.com/foo/bar. Currently, to create this weak =
binding, the user would have to issue the bind method to =
http://www.yahoo.com/foo/bar and ask the Yahoo server to somehow =
communicate with the destination server and create a weak binding. This =
is like telling people that before they can add a hyperlink to their =
HTML document they have to first get the resource pointed to by the =
hyperlink to somehow participate in the process. The ability to link to =
resources without the knowledge of the source (as the term is used in =
the BIND method) has been one of the key aspects of the scalability of =
the Web.

      In my mind the proper solution is to introduce a source header =
that, when used on a BIND method, would mean that the request-URI =
specifies the destination rather than the source.

      That having been said I really have no desire to prolong the agony =
of the BIND authors by asking them to add a new header and deal with all =
the complexities it would introduce. As such I am happy to settle for =
the following paragraph being added to section 5.1: "The BIND method =
MUST fail if it does not include a destination header. Note, however, =
that future specifications MAY introduce additional headers that =
resources could honor in the place of the destination header and so =
allow the BIND method to succeed in the absence of a destination =
header."

      This would allow us, in the future, to introduce a weak binding =
spec that could still use the BIND method without forcing us to use MAN =
or introduce a new method.


------=_NextPart_000_023B_01BF60E4.C31A3D70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>WebDAV Bindings - Issue Yaron.BindSyntax</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Sounds like a good idea, and I'm in =
favor of=20
it.&nbsp; However, one of your statements was:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>"Unfortunately, in the case of BIND, it =
introduces=20
a very serious problem when (not if, but when) we introduce weak=20
bindings."</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I'm just pointing out that you're only =
addressing a=20
particular class of weak bindings, which weakens your "not if, but when" =

statement as it applies to your proposal.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>--Eric</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:yarong@Exchange.Microsoft.com"=20
  title=3Dyarong@Exchange.Microsoft.com>Yaron Goland</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  href=3D"mailto:esedlar@us.oracle.com" =
title=3Desedlar@us.oracle.com>'Eric=20
  Sedlar'</A> ; <A href=3D"mailto:w3c-dist-auth@w3.org"=20
  title=3Dw3c-dist-auth@w3.org>w3c-dist-auth@w3.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, January 17, 2000 =
12:01=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: WebDAV Bindings - =
Issue=20
  Yaron.BindSyntax</DIV>
  <DIV><BR></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D064375419-17012000>What=20
  I am specifically looking for is the ability to have the server handle =
all=20
  conversations with the resource on my behalf but with the possibility =
of=20
  dangling references.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D064375419-17012000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D064375419-17012000>For=20
  example, I want to be able to create a collection that contains a =
bunch of=20
  weak links to random resources all over the planet. Then I want to =
issue a=20
  depth infinity PROPFIND against that collection and get back a bunch =
of=20
  properties. In the background what is happening is that the server is =
actually=20
  going out and performing the PROPFIND on my behalf to the destination=20
  resources. However my experience as a client is that I make a single =
PROPFIND=20
  request and get back a single PROPFIND result. This sort of behavior =
is very=20
  important when dealing with very limited clients (hand helds for =
example) or=20
  when using a very high latency link (wireless).</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D064375419-17012000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D064375419-17012000>I am=20
  NOT suggesting that this group adopt a weak link of this type. At =
least not=20
  yet. What I am proposing is that the language I suggested be put into =
the BIND=20
  spec so that if we WANT to create links of this type we are ABLE to do =

  so.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D064375419-17012000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D064375419-17012000>In=20
  other words, I am not asking for consensus that the type of link I =
want to=20
  create is a good idea. I am just asking that we put in language in the =
BIND=20
  spec that will allow us to create a link of this type at a later date =
if we=20
  choose to do so. Since the proposed language would not cause ANY =
change in the=20
  way a BIND client/server behaves I can't think of a good reason to =
refuse my=20
  request.</SPAN></FONT></DIV>
  <BLOCKQUOTE=20
  style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Eric Sedlar=20
    [mailto:esedlar@us.oracle.com]<BR><B>Sent:</B> Mon, January 17, 2000 =
11:39=20
    AM<BR><B>To:</B> Yaron Goland; =
w3c-dist-auth@w3.org<BR><B>Subject:</B> Re:=20
    WebDAV Bindings - Issue Yaron.BindSyntax<BR><BR></DIV></FONT>
    <DIV><FONT face=3DArial size=3D2>It depends on the kind of weak =
binding you=20
    want.&nbsp; If it's something like a symbolic link, redirect =
references work=20
    reasonably well for that.&nbsp; If you want a weak binding (weak, in =
that it=20
    is not affecting the persistence of the item being bound) that =
doesn't=20
    dangle, you have to notify the source, so that it can send the =
destination=20
    an event when the source is deleted.</FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>--Eric</FONT></DIV>
    <BLOCKQUOTE=20
    style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
      <DIV style=3D"FONT: 10pt arial">----- Original Message ----- =
</DIV>
      <DIV=20
      style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
      <A href=3D"mailto:yarong@Exchange.Microsoft.com"=20
      title=3Dyarong@Exchange.Microsoft.com>Yaron Goland</A> </DIV>
      <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
      href=3D"mailto:w3c-dist-auth@w3.org"=20
      title=3Dw3c-dist-auth@w3.org>w3c-dist-auth@w3.org</A> </DIV>
      <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, January 16, =
2000 5:47=20
      PM</DIV>
      <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> WebDAV Bindings - =
Issue=20
      Yaron.BindSyntax</DIV>
      <DIV><BR></DIV>
      <P><FONT face=3DArial size=3D2>The BIND spec defines that a =
binding is created=20
      by sending a message to the source and instructing it to create a =
binding=20
      at the destination. This is completely consistent with how WebDAV =
normally=20
      operates in methods such as COPY/MOVE where the source is =
instructed to=20
      make changes at the destination. Unfortunately, in the case of =
BIND, it=20
      introduces a very serious problem when (not if, but when) we =
introduce=20
      weak bindings. The problem is that the current bind syntax =
requires the=20
      active participation of the source to create a bind at the =
destination. In=20
      the case of a weak binding it is expected that the source may not =
even be=20
      aware of the binding. This is one of the main benefits of =
introducing weak=20
      bindings, it allows for bind like behavior without requiring the=20
      participation of the source. This enables many resources to have =
weak=20
      bindings against a resource without overloading the =
resource.</FONT></P>
      <P><FONT face=3DArial size=3D2>An example may help here. Imagine a =
user wants=20
      to create a weak binding to <A =
href=3D"http://www.yahoo.com/foo/bar"=20
      target=3D_blank>http://www.yahoo.com/foo/bar</A>. Currently, to =
create this=20
      weak binding, the user would have to issue the bind method to <A=20
      href=3D"http://www.yahoo.com/foo/bar"=20
      target=3D_blank>http://www.yahoo.com/foo/bar</A> and ask the Yahoo =
server to=20
      somehow communicate with the destination server and create a weak =
binding.=20
      This is like telling people that before they can add a hyperlink =
to their=20
      HTML document they have to first get the resource pointed to by =
the=20
      hyperlink to somehow participate in the process. The ability to =
link to=20
      resources without the knowledge of the source (as the term is used =
in the=20
      BIND method) has been one of the key aspects of the scalability of =
the=20
      Web.</FONT></P>
      <P><FONT face=3DArial size=3D2>In my mind the proper solution is =
to introduce=20
      a source header that, when used on a BIND method, would mean that =
the=20
      request-URI specifies the destination rather than the =
source.</FONT></P>
      <P><FONT face=3DArial size=3D2>That having been said I really have =
no desire=20
      to prolong the agony of the BIND authors by asking them to add a =
new=20
      header and deal with all the complexities it would introduce. As =
such I am=20
      happy to settle for the following paragraph being added to section =
5.1:=20
      "The BIND method MUST fail if it does not include a destination =
header.=20
      Note, however, that future specifications MAY introduce additional =
headers=20
      that resources could honor in the place of the destination header =
and so=20
      allow the BIND method to succeed in the absence of a destination=20
      header."</FONT></P>
      <P><FONT face=3DArial size=3D2>This would allow us, in the future, =
to=20
      introduce a weak binding spec that could still use the BIND method =
without=20
      forcing us to use MAN or introduce a new=20
  =
method.</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_023B_01BF60E4.C31A3D70--



From w3c-dist-auth-request@w3.org  Mon Jan 17 16:04:37 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08825
	for <webdav-archive@odin.ietf.org>; Mon, 17 Jan 2000 16:04:35 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA23884;
	Mon, 17 Jan 2000 15:53:28 -0500 (EST)
Resent-Date: Mon, 17 Jan 2000 15:53:28 -0500 (EST)
Resent-Message-Id: <200001172053.PAA23884@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A0BD@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'Eric Sedlar'" <esedlar@us.oracle.com>, w3c-dist-auth@w3.org
Date: Mon, 17 Jan 2000 12:52:12 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF612C.DF818188"
Subject: RE: WebDAV Bindings - Issue Yaron.BindSyntax
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3863
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF612C.DF818188
Content-Type: text/plain;
	charset="iso-8859-1"

Good point. 
 
I had meant that I was confident that this group would address weak
bindings. I did not mean to say that the proposal I had would be the one
adopted. Only that I wanted to make sure that IF the group wanted to adopt
my proposal for how weak bindings should work THEN it would be possible.
Without the change in language I have requested the group would be unable to
adopt the proposal I intend to make.
 
Thanks for catching this.
 
        Yaron
 

-----Original Message-----
From: Eric Sedlar [mailto:esedlar@us.oracle.com]
Sent: Mon, January 17, 2000 12:17 PM
To: Yaron Goland; w3c-dist-auth@w3.org
Subject: Re: WebDAV Bindings - Issue Yaron.BindSyntax


Sounds like a good idea, and I'm in favor of it.  However, one of your
statements was:
 
"Unfortunately, in the case of BIND, it introduces a very serious problem
when (not if, but when) we introduce weak bindings."
 
I'm just pointing out that you're only addressing a particular class of weak
bindings, which weakens your "not if, but when" statement as it applies to
your proposal.
 
--Eric

----- Original Message ----- 
From: Yaron Goland <mailto:yarong@Exchange.Microsoft.com>  
To: 'Eric  <mailto:esedlar@us.oracle.com> Sedlar' ; w3c-dist-auth@w3.org
<mailto:w3c-dist-auth@w3.org>  
Sent: Monday, January 17, 2000 12:01 PM
Subject: RE: WebDAV Bindings - Issue Yaron.BindSyntax

What I am specifically looking for is the ability to have the server handle
all conversations with the resource on my behalf but with the possibility of
dangling references.
 
For example, I want to be able to create a collection that contains a bunch
of weak links to random resources all over the planet. Then I want to issue
a depth infinity PROPFIND against that collection and get back a bunch of
properties. In the background what is happening is that the server is
actually going out and performing the PROPFIND on my behalf to the
destination resources. However my experience as a client is that I make a
single PROPFIND request and get back a single PROPFIND result. This sort of
behavior is very important when dealing with very limited clients (hand
helds for example) or when using a very high latency link (wireless).
 
I am NOT suggesting that this group adopt a weak link of this type. At least
not yet. What I am proposing is that the language I suggested be put into
the BIND spec so that if we WANT to create links of this type we are ABLE to
do so.
 
In other words, I am not asking for consensus that the type of link I want
to create is a good idea. I am just asking that we put in language in the
BIND spec that will allow us to create a link of this type at a later date
if we choose to do so. Since the proposed language would not cause ANY
change in the way a BIND client/server behaves I can't think of a good
reason to refuse my request.

-----Original Message-----
From: Eric Sedlar [mailto:esedlar@us.oracle.com]
Sent: Mon, January 17, 2000 11:39 AM
To: Yaron Goland; w3c-dist-auth@w3.org
Subject: Re: WebDAV Bindings - Issue Yaron.BindSyntax


It depends on the kind of weak binding you want.  If it's something like a
symbolic link, redirect references work reasonably well for that.  If you
want a weak binding (weak, in that it is not affecting the persistence of
the item being bound) that doesn't dangle, you have to notify the source, so
that it can send the destination an event when the source is deleted.
 
--Eric

----- Original Message ----- 
From: Yaron Goland <mailto:yarong@Exchange.Microsoft.com>  
To: w3c-dist-auth@w3.org <mailto:w3c-dist-auth@w3.org>  
Sent: Sunday, January 16, 2000 5:47 PM
Subject: WebDAV Bindings - Issue Yaron.BindSyntax


The BIND spec defines that a binding is created by sending a message to the
source and instructing it to create a binding at the destination. This is
completely consistent with how WebDAV normally operates in methods such as
COPY/MOVE where the source is instructed to make changes at the destination.
Unfortunately, in the case of BIND, it introduces a very serious problem
when (not if, but when) we introduce weak bindings. The problem is that the
current bind syntax requires the active participation of the source to
create a bind at the destination. In the case of a weak binding it is
expected that the source may not even be aware of the binding. This is one
of the main benefits of introducing weak bindings, it allows for bind like
behavior without requiring the participation of the source. This enables
many resources to have weak bindings against a resource without overloading
the resource.

An example may help here. Imagine a user wants to create a weak binding to
http://www.yahoo.com/foo/bar <http://www.yahoo.com/foo/bar> . Currently, to
create this weak binding, the user would have to issue the bind method to
http://www.yahoo.com/foo/bar <http://www.yahoo.com/foo/bar>  and ask the
Yahoo server to somehow communicate with the destination server and create a
weak binding. This is like telling people that before they can add a
hyperlink to their HTML document they have to first get the resource pointed
to by the hyperlink to somehow participate in the process. The ability to
link to resources without the knowledge of the source (as the term is used
in the BIND method) has been one of the key aspects of the scalability of
the Web.

In my mind the proper solution is to introduce a source header that, when
used on a BIND method, would mean that the request-URI specifies the
destination rather than the source.

That having been said I really have no desire to prolong the agony of the
BIND authors by asking them to add a new header and deal with all the
complexities it would introduce. As such I am happy to settle for the
following paragraph being added to section 5.1: "The BIND method MUST fail
if it does not include a destination header. Note, however, that future
specifications MAY introduce additional headers that resources could honor
in the place of the destination header and so allow the BIND method to
succeed in the absence of a destination header."

This would allow us, in the future, to introduce a weak binding spec that
could still use the BIND method without forcing us to use MAN or introduce a
new method.


------_=_NextPart_001_01BF612C.DF818188
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>WebDAV Bindings - Issue Yaron.BindSyntax</TITLE>

<META content="MSHTML 5.00.2920.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=319305020-17012000>Good 
point. </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=319305020-17012000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=319305020-17012000>I had 
meant that I was confident that this group would address weak bindings. I did 
not mean to say that the proposal I had would be the one adopted. Only that I 
wanted to make sure that IF the group wanted to adopt my proposal for how weak 
bindings should work THEN it would be possible. Without the change in language I 
have requested the group would be unable to adopt the proposal I intend to 
make.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=319305020-17012000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=319305020-17012000>Thanks 
for catching this.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=319305020-17012000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=319305020-17012000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Yaron</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=319305020-17012000></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Eric Sedlar 
  [mailto:esedlar@us.oracle.com]<BR><B>Sent:</B> Mon, January 17, 2000 12:17 
  PM<BR><B>To:</B> Yaron Goland; w3c-dist-auth@w3.org<BR><B>Subject:</B> Re: 
  WebDAV Bindings - Issue Yaron.BindSyntax<BR><BR></DIV></FONT>
  <DIV><FONT face=Arial size=2>Sounds like a good idea, and I'm in favor of 
  it.&nbsp; However, one of your statements was:</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>"Unfortunately, in the case of BIND, it 
  introduces a very serious problem when (not if, but when) we introduce weak 
  bindings."</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>I'm just pointing out that you're only addressing 
  a particular class of weak bindings, which weakens your "not if, but when" 
  statement as it applies to your proposal.</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>--Eric</FONT></DIV>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
    <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV 
    style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
    <A href="mailto:yarong@Exchange.Microsoft.com" 
    title=yarong@Exchange.Microsoft.com>Yaron Goland</A> </DIV>
    <DIV style="FONT: 10pt arial"><B>To:</B> <A 
    href="mailto:esedlar@us.oracle.com" title=esedlar@us.oracle.com>'Eric 
    Sedlar'</A> ; <A href="mailto:w3c-dist-auth@w3.org" 
    title=w3c-dist-auth@w3.org>w3c-dist-auth@w3.org</A> </DIV>
    <DIV style="FONT: 10pt arial"><B>Sent:</B> Monday, January 17, 2000 12:01 
    PM</DIV>
    <DIV style="FONT: 10pt arial"><B>Subject:</B> RE: WebDAV Bindings - Issue 
    Yaron.BindSyntax</DIV>
    <DIV><BR></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=064375419-17012000>What I am specifically looking for is the ability 
    to have the server handle all conversations with the resource on my behalf 
    but with the possibility of dangling references.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=064375419-17012000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=064375419-17012000>For example, I want to be able to create a 
    collection that contains a bunch of weak links to random resources all over 
    the planet. Then I want to issue a depth infinity PROPFIND against that 
    collection and get back a bunch of properties. In the background what is 
    happening is that the server is actually going out and performing the 
    PROPFIND on my behalf to the destination resources. However my experience as 
    a client is that I make a single PROPFIND request and get back a single 
    PROPFIND result. This sort of behavior is very important when dealing with 
    very limited clients (hand helds for example) or when using a very high 
    latency link (wireless).</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=064375419-17012000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=064375419-17012000>I 
    am NOT suggesting that this group adopt a weak link of this type. At least 
    not yet. What I am proposing is that the language I suggested be put into 
    the BIND spec so that if we WANT to create links of this type we are ABLE to 
    do so.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=064375419-17012000></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=064375419-17012000>In 
    other words, I am not asking for consensus that the type of link I want to 
    create is a good idea. I am just asking that we put in language in the BIND 
    spec that will allow us to create a link of this type at a later date if we 
    choose to do so. Since the proposed language would not cause ANY change in 
    the way a BIND client/server behaves I can't think of a good reason to 
    refuse my request.</SPAN></FONT></DIV>
    <BLOCKQUOTE 
    style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
      <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> Eric Sedlar 
      [mailto:esedlar@us.oracle.com]<BR><B>Sent:</B> Mon, January 17, 2000 11:39 
      AM<BR><B>To:</B> Yaron Goland; w3c-dist-auth@w3.org<BR><B>Subject:</B> Re: 
      WebDAV Bindings - Issue Yaron.BindSyntax<BR><BR></DIV></FONT>
      <DIV><FONT face=Arial size=2>It depends on the kind of weak binding you 
      want.&nbsp; If it's something like a symbolic link, redirect references 
      work reasonably well for that.&nbsp; If you want a weak binding (weak, in 
      that it is not affecting the persistence of the item being bound) that 
      doesn't dangle, you have to notify the source, so that it can send the 
      destination an event when the source is deleted.</FONT></DIV>
      <DIV>&nbsp;</DIV>
      <DIV><FONT face=Arial size=2>--Eric</FONT></DIV>
      <BLOCKQUOTE 
      style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
        <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
        <DIV 
        style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
        <A href="mailto:yarong@Exchange.Microsoft.com" 
        title=yarong@Exchange.Microsoft.com>Yaron Goland</A> </DIV>
        <DIV style="FONT: 10pt arial"><B>To:</B> <A 
        href="mailto:w3c-dist-auth@w3.org" 
        title=w3c-dist-auth@w3.org>w3c-dist-auth@w3.org</A> </DIV>
        <DIV style="FONT: 10pt arial"><B>Sent:</B> Sunday, January 16, 2000 5:47 
        PM</DIV>
        <DIV style="FONT: 10pt arial"><B>Subject:</B> WebDAV Bindings - Issue 
        Yaron.BindSyntax</DIV>
        <DIV><BR></DIV>
        <P><FONT face=Arial size=2>The BIND spec defines that a binding is 
        created by sending a message to the source and instructing it to create 
        a binding at the destination. This is completely consistent with how 
        WebDAV normally operates in methods such as COPY/MOVE where the source 
        is instructed to make changes at the destination. Unfortunately, in the 
        case of BIND, it introduces a very serious problem when (not if, but 
        when) we introduce weak bindings. The problem is that the current bind 
        syntax requires the active participation of the source to create a bind 
        at the destination. In the case of a weak binding it is expected that 
        the source may not even be aware of the binding. This is one of the main 
        benefits of introducing weak bindings, it allows for bind like behavior 
        without requiring the participation of the source. This enables many 
        resources to have weak bindings against a resource without overloading 
        the resource.</FONT></P>
        <P><FONT face=Arial size=2>An example may help here. Imagine a user 
        wants to create a weak binding to <A href="http://www.yahoo.com/foo/bar" 
        target=_blank>http://www.yahoo.com/foo/bar</A>. Currently, to create 
        this weak binding, the user would have to issue the bind method to <A 
        href="http://www.yahoo.com/foo/bar" 
        target=_blank>http://www.yahoo.com/foo/bar</A> and ask the Yahoo server 
        to somehow communicate with the destination server and create a weak 
        binding. This is like telling people that before they can add a 
        hyperlink to their HTML document they have to first get the resource 
        pointed to by the hyperlink to somehow participate in the process. The 
        ability to link to resources without the knowledge of the source (as the 
        term is used in the BIND method) has been one of the key aspects of the 
        scalability of the Web.</FONT></P>
        <P><FONT face=Arial size=2>In my mind the proper solution is to 
        introduce a source header that, when used on a BIND method, would mean 
        that the request-URI specifies the destination rather than the 
        source.</FONT></P>
        <P><FONT face=Arial size=2>That having been said I really have no desire 
        to prolong the agony of the BIND authors by asking them to add a new 
        header and deal with all the complexities it would introduce. As such I 
        am happy to settle for the following paragraph being added to section 
        5.1: "The BIND method MUST fail if it does not include a destination 
        header. Note, however, that future specifications MAY introduce 
        additional headers that resources could honor in the place of the 
        destination header and so allow the BIND method to succeed in the 
        absence of a destination header."</FONT></P>
        <P><FONT face=Arial size=2>This would allow us, in the future, to 
        introduce a weak binding spec that could still use the BIND method 
        without forcing us to use MAN or introduce a new 
      method.</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BF612C.DF818188--



From w3c-dist-auth-request@w3.org  Mon Jan 17 16:31:13 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09226
	for <webdav-archive@odin.ietf.org>; Mon, 17 Jan 2000 16:31:12 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id QAA25904;
	Mon, 17 Jan 2000 16:19:43 -0500 (EST)
Resent-Date: Mon, 17 Jan 2000 16:19:43 -0500 (EST)
Resent-Message-Id: <200001172119.QAA25904@www19.w3.org>
To: Yaron Goland <yarong@exchange.microsoft.com>
cc: "'Jim Whitehead'" <ejw@ics.uci.edu>, w3c-dist-auth@w3.org
In-reply-to: Your message of "Mon, 17 Jan 2000 12:05:27 PST."
             <7DE119D3D0E15543874F7561EECBDBED0261A0BC@BEG.platinum.corp.microsoft.com> 
Date: Mon, 17 Jan 2000 13:19:26 -0800
From: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
Message-ID:  <200001171319.aa14524@gremlin-relay.ics.uci.edu>
Subject: Re: WebDAV Bindings - Issue Yaron.Insulting2616 
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3864
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

>With all due respect, I think ALL of the 2616 authors should have a chance
>to respond as they all are indicted by your comments.

You are welcome to get comments from the others, but the words being
referred to were written by myself and Henrik, with me being responsible
for any bits having to do with the semantics of the interface.  So if
it is intentions you want to hear about, Jim asked the right person.

Now all I have to do is put enough free time together to read the
spec I printed out over the weekend.

To answer the question in partial ignorance (having only read prior
discussions and the actual paragraph quoted by Jim), my intention was
that DELETE would apply to the resource and that all naming operations
would be applied to the collection resource (which was an easy punt, since
nobody else wanted to define collections in the base HTTP/1.1).
For example, TimBL's notion of creating a new resource was to POST it
to the collection resource.

Note, however, that from the client's perspective, deleting a binding
and deleting a resource are the same thing.  That is because there is
no mechanism for determining whether or not two different URI identify
the same resource.  The only difference from the WebDAV perspective is
that a resource DELETE may effect multiple bindings (but even this is
no different than saying any indirect name, including URNs, is ultimately
impacted by the deletion of identifers that they indirect towards).
Bugger.

And whatever you think while reading this, keep in mind that the resource
is not the storage thingy on the back-end -- it is the concept being
referenced by the originator of the URI.  I don't understand how
the server is supposed to know what the resource is when the user is
allowed to create new bindings willy-nilly.  Therefore, either the
server needs to be told what the resource is when the bindings are
created (which doesn't seem likely, since most of the users wouldn't
understand the difference) or the definition of DELETE should be changed
to reflect the easier-to-grasp notion of removing the binding.

This confusion has been brought to you by the design trade-off of
scalable indirect references within uncontrolled hypertext source.
We reference resources, not bindings and not storage objects, because
the concept being referenced is the least likely to change over time.
A good namespace has a 1:1 correspondence between bindings and resources.

....Roy

[p.s. I hate HTML mail]



From w3c-dist-auth-request@w3.org  Mon Jan 17 20:41:45 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11030
	for <webdav-archive@odin.ietf.org>; Mon, 17 Jan 2000 20:41:40 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA04009;
	Mon, 17 Jan 2000 20:30:29 -0500 (EST)
Resent-Date: Mon, 17 Jan 2000 20:30:29 -0500 (EST)
Resent-Message-Id: <200001180130.UAA04009@www19.w3.org>
From: ccjason@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
cc: w3c-dist-auth@w3.org
Message-ID: <8525686A.00083CEA.00@D51MTA03.pok.ibm.com>
Date: Mon, 17 Jan 2000 20:29:17 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: WebDAV Bindings - Issue Yaron.Insulting2616, definition of 	 resource
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3865
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


Roy, thanks for what you said in the first part of this note.

  And whatever you think while reading this, keep in mind that the resource
  is not the storage thingy on the back-end -- it is the concept being
  referenced by the originator of the URI.

Agreed.

  I don't understand how
  the server is supposed to know what the resource is when the user is
  allowed to create new bindings willy-nilly.  Therefore, either the
  server needs to be told what the resource is when the bindings are
  created (which doesn't seem likely, since most of the users wouldn't
  understand the difference) or the definition of DELETE should be changed
  to reflect the easier-to-grasp notion of removing the binding.

Are those the only choices?...

Can't we leave the definition of resource suitably vague as we and
our predecessors have?  If we do I suspect servers will drive a
WebDAV compliant definition that content authors on their site will
use.  Not the opposite.

  Almost all servers will support the model of
flat/dead file or repository object that basically is just an echo of
a PUT/GET.provide their own underlying meaning of resource.    A server
might also offer support for more intelligent objects like servlets or
perl scripts and also treat those as resources.  The author's job is
to encapsulate his concept of a resource within the one of the server's
concepts of a resource which is probably a file or some sort of
repostiory object.

As I just said, most of the time, the server will drive a WebDAV compliant
concept of a resource that that the content authors will use.
One likely  exceptions is the concept of a resource essentially being
at the URI.  This model doesn't need server support and may not leverage
the server model or even necessarily the WebDAV model of resource.  An
example is,
"page_of_the_day.html".  Certainly the author could use a proxy
resource that essentially gets it's contents from other resources depending
on today's date, but it's more likely that the author will just choose to
rebind that URI each day.  Sure, the casual referencer's
concept of the resource will not be the same as the server's, but the right
thing happens.  Does it matter that the author chose to have one foot in
each model?

Jason.

PS. I hate HTML mail too.




From w3c-dist-auth-request@w3.org  Mon Jan 17 23:42:59 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14012
	for <webdav-archive@odin.ietf.org>; Mon, 17 Jan 2000 23:42:58 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id XAA08935;
	Mon, 17 Jan 2000 23:26:23 -0500 (EST)
Resent-Date: Mon, 17 Jan 2000 23:26:23 -0500 (EST)
Resent-Message-Id: <200001180426.XAA08935@www19.w3.org>
To: ccjason@us.ibm.com
cc: w3c-dist-auth@w3.org
In-reply-to: Your message of "Mon, 17 Jan 2000 20:29:17 EST."
             <8525686A.00083CEA.00@D51MTA03.pok.ibm.com> 
Date: Mon, 17 Jan 2000 20:26:12 -0800
From: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
Message-ID:  <200001172026.aa08575@gremlin-relay.ics.uci.edu>
Subject: Re: WebDAV Bindings - Issue Yaron.Insulting2616, definition of resource 
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3866
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

>> I don't understand how
>> the server is supposed to know what the resource is when the user is
>> allowed to create new bindings willy-nilly.  Therefore, either the
>> server needs to be told what the resource is when the bindings are
>> created (which doesn't seem likely, since most of the users wouldn't
>> understand the difference) or the definition of DELETE should be changed
>> to reflect the easier-to-grasp notion of removing the binding.
>
>Are those the only choices?...

All that I can think of at the moment.  Another way to put it is:
if the server is not informed of the difference between a new binding to
an existing resource and a new binding representing a new resource that
happens to currently point to an existing resource, then the server must
treat all bindings as unique resources.  The alternative---that all
bindings to the same resource represent a single resource---is known
to be false.  If the server is treating all bindings as unique resources,
then DELETE on a binding is equivalent to DELETE on a resource.

Since we have a good grasp of what it means to DELETE a binding, and
we can assume that the server can be configured to act appropriately
when the last accessible binding is deleted from a resource, I think it
is reasonable to alter the definition of DELETE so that it follows the
spirit of what is defined in RFC 2616 rather than the exact terminology.

Well, either that or simply declare that every binding is a separate
resource, even when it isn't.

Or, declare a new method called UNBIND that removes bindings but not
resources.  I guess then the WG would have to figure out what should
happen when the client attempts to UNBIND the last binding attached to
a resource, and likewise BIND would have to indicate whether the new
binding should be considered a new resource or an alias of an existing
resource.  I pretty much assumed that the WG had already discussed this
option and moved on.

>Can't we leave the definition of resource suitably vague as we and
>our predecessors have?  If we do I suspect servers will drive a
>WebDAV compliant definition that content authors on their site will
>use.  Not the opposite.

Hmmm, my experience is that most implementers will randomly stagger
towards the first implementation that appears to work for their limited
test set, and then refuse to fix it out of fear of breaking backwards
compatibility.  Only those who understand the overall architecture are
likely to get it right the first time.

>  Almost all servers will support the model of
>flat/dead file or repository object that basically is just an echo of
>a PUT/GET.provide their own underlying meaning of resource.    A server
>might also offer support for more intelligent objects like servlets or
>perl scripts and also treat those as resources.  The author's job is
>to encapsulate his concept of a resource within the one of the server's
>concepts of a resource which is probably a file or some sort of
>repostiory object.

Actually, no.  If we treat the web as if it were a distributed filesystem,
it will eventually lose those qualities that make it better than a
distributed filesystem.  The most important goal of WebDAV is to enable
manipulation of resources without assuming anything about how the
resource is implemented; it is okay to learn how it is implemented
during the process of interaction, but only to the extent that the
server reveals that information to the client.  So we build up this
interface model where the client makes operations on the generic interface
and then the server translates those operations into the mechanism
applicable for that resource.

Namespace operations are a little unnatural in that, even though the
request-URI consists of the target name, the actual mechanism targeted
by the request is the collection resource that governs that namespace.
Hence, MOVE changes the collection, not the resource.

[Gack! I just noticed that the request target of a BIND request is,
well, wrong in the spec. More on this later.]

>As I just said, most of the time, the server will drive a WebDAV compliant
>concept of a resource that that the content authors will use.
>One likely  exceptions is the concept of a resource essentially being
>at the URI.  This model doesn't need server support and may not leverage
>the server model or even necessarily the WebDAV model of resource.  An
>example is,
>"page_of_the_day.html".  Certainly the author could use a proxy
>resource that essentially gets it's contents from other resources depending
>on today's date, but it's more likely that the author will just choose to
>rebind that URI each day.  Sure, the casual referencer's
>concept of the resource will not be the same as the server's, but the right
>thing happens.  Does it matter that the author chose to have one foot in
>each model?

I don't follow that -- I only see one model there, even if the
"page_of_the_day.html" is a physical file on the server.  How it is
implemented doesn't make any difference to the interface presented
to the client except during the authoring operations.

A better example is a collection consisting of "Fred", "Frederick",
and "Douglass".  Those could be three different resources (for example,
individuals within a team of coders) or three different aliases for
the same resource.  The only person who really knows the answer is the
person defining the namespace -- it just isn't something that a server
can figure out by analyzing the implementation, because what differentiates
one resource from another is the semantics given to them when each URI is
used within some external reference.  The server can't even rely on the
implementation giving some indication of the difference, since the
implementation is allowed to change over time, whereas the semantics of
a resource does not (legitimately) change over time.

....Roy



From w3c-dist-auth-request@w3.org  Tue Jan 18 09:39:21 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00089
	for <webdav-archive@odin.ietf.org>; Tue, 18 Jan 2000 09:39:21 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id JAA21661;
	Tue, 18 Jan 2000 09:28:12 -0500 (EST)
Resent-Date: Tue, 18 Jan 2000 09:28:12 -0500 (EST)
Resent-Message-Id: <200001181428.JAA21661@www19.w3.org>
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24565@crte147.wc.eso.mc.xerox.com>
From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'Yaron Goland'" <yarong@Exchange.Microsoft.com>, w3c-dist-auth@w3.org
Date: Tue, 18 Jan 2000 09:27:44 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.BindingsProperty
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3867
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This seems right to me.  It also points out that till now we've been
thinking that capabilities vary by resource, so that responses to OPTIONS
vary by resource.  When we consider situations where there are multiple
bindings to the same resource, it turns out that capabilities really vary by
URI, and responses to OPTIONS with different request-URI but the same
resource may be different.
 
So we need also to take another look at the wording of section 15 Capability
Discovery, as well as 9 (which you discuss in another note).
 
--Judy 
 

-----Original Message-----
From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
Sent: Sunday, January 16, 2000 8:27 PM
To: w3c-dist-auth@w3.org
Subject: WebDAV Bindings - Issue Yaron.BindingsProperty



Section 11 of the BIND specification defines the dav:bindings property. What
is not clear to me from the text in this section is if it is possible to
have the dav:bindings property accessible through one binding but not
another? 

One could imagine that two servers share access to the same disk drive and
hence are able to map names to the same "resource" (as they understand the
term). In order to keep things consistent both servers agree to record all
the names they use to refer to the same resource. However only one of the
servers actually supports the BIND method and the dav:bindings property and
the other doesn't. I can still do a GET on each server and the result will
be from the same resource but only one of the servers will be able to serve
up the dav:bindings property. Unfortunately the language in section 11
speaks of the dav:bindings property being on a resource so the presumption
is that if I can get the dav:bindings property through one binding then I
MUST be able to get it through the other. I believe this is too strict a
requirement.

As such I move that the language in section 11 be clarified so as to specify
that the dav:bindings property may not necessarily be available through all
bindings on the resource.



From w3c-dist-auth-request@w3.org  Tue Jan 18 09:40:32 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00110
	for <webdav-archive@odin.ietf.org>; Tue, 18 Jan 2000 09:40:31 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id JAA22039;
	Tue, 18 Jan 2000 09:29:33 -0500 (EST)
Resent-Date: Tue, 18 Jan 2000 09:29:33 -0500 (EST)
Resent-Message-Id: <200001181429.JAA22039@www19.w3.org>
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24566@crte147.wc.eso.mc.xerox.com>
From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'Yaron Goland'" <yarong@Exchange.Microsoft.com>, w3c-dist-auth@w3.org
Date: Tue, 18 Jan 2000 09:29:12 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.ApplePie
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3868
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

I have no problem with removing this statement.
 
--Judy

-----Original Message-----
From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
Sent: Sunday, January 16, 2000 8:48 PM
To: w3c-dist-auth@w3.org
Subject: WebDAV Bindings - Issue Yaron.ApplePie



The second to last paragraph of section 5.1 reads "After successful
processing of a BIND request, it MUST be possible for clients to use the URI
in the Destination header to submit requests to the resource identified by
the Request-URI." This is a motherhood and apple pie requirement. It sounds
good but in practice it doesn't enhance interoperability. What does it mean
to "submit requests"? What period of time is covered by "After"? For
example, if user A successfully issues a BIND and then user B using FTP
deletes the mapped in resource and when user A tries to "submit requests" to
the resource the requests fail, is the system in non-compliance? There is no
way to tell the difference between the previous scenario and a scenario in
which the system accepted the BIND and decided to do nothing with it. This
is called being a sucky server but such behavior has absolutely no effect on
interoperability because it is indistinguishable from the original example I
provided about User A & B.

As such I move that this paragraph be removed from the draft. 



From w3c-dist-auth-request@w3.org  Tue Jan 18 10:46:07 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01119
	for <webdav-archive@odin.ietf.org>; Tue, 18 Jan 2000 10:46:06 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id KAA25169;
	Tue, 18 Jan 2000 10:31:40 -0500 (EST)
Resent-Date: Tue, 18 Jan 2000 10:31:40 -0500 (EST)
Resent-Message-Id: <200001181531.KAA25169@www19.w3.org>
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24567@crte147.wc.eso.mc.xerox.com>
From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'Yaron Goland'" <yarong@Exchange.Microsoft.com>, w3c-dist-auth@w3.org
Date: Tue, 18 Jan 2000 10:31:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.ApplePieToo
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3869
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

The first paragraph doesn't really say anything substantive.  It just
introduces the section, listing the methods to which it applies.  The one
substantive statement that I think we would want to keep is "For these
methods, no new complexities are introduced by allowing explicit creation of
multiple bindings to the same resource."
 
I could be persuaded to reduce the section to just that.
 
But it still might be worth pointing out that BIND will make it much more
common to have multiple bindings to the same resource (even though that was
always possible).  And when there are multiple bindings to a resource, it is
possible for a resource's behavior in response to GET, HEAD, PROPFIND, etc.,
to be sensitive to the URI that was used to make the request.  Maybe we
wouldn't have to discuss the distinction between static and dynamic
resources in order to make that point.
 
--Judy
 

-----Original Message-----
From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
Sent: Sunday, January 16, 2000 8:28 PM
To: w3c-dist-auth@w3.org
Subject: WebDAV Bindings - Issue Yaron.ApplePieToo



Section 9 of the draft attempts to tackle the problem of how to
differentiate the behavior of a resource based on its bindings. It attempts
to discuss the difference between a static and non-static resource. However
the difference between these two types of resources is so unbelievably
arbitrary that I fail to see how attempting to differentiate between them
enhances interoperability.

For example, let us pretend we have the CurrentURI property. The value of
the property will be the Request-URI of the PROPFIND method used to retrieve
the value of the CurrentURI property. Now let us pretend we have two
servers, A and B. A runs a version of WebDAV that automatically generates
the CurrentURI property on top of whatever resources it supports. What this
means is that even if the underlying data store where the resource is
recorded doesn't know about the CurrentURI property, I can still get the
CurrentURI property through PROPFIND because A's server will intercept the
PROPFIND and insert the data itself. Server B doesn't support CurrentURI at
all. I now have a resource R that has bindings into A and B. This means that
if I ask for the CurrentURI property through the binding on A, I will get a
result with the URI on A. If I ask for the CurrentURI property through the
binding on B, I will not even see the property at all.

So the question is - Well is this a dynamic resource? Is it not? Can I have
the same resourceID on both URIs in this example? How does the language in
section 9 help me deal with this? Does it actually clarify anything in a
useful way?

As far as I can tell the language in section 9 is just motherhood and apple
pie language and that always makes for bad standard language.

Therefore I move that all the paragraphs in section 9 but the first
paragraph be stricken from the BIND spec. 



From w3c-dist-auth-request@w3.org  Tue Jan 18 10:50:25 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01187
	for <webdav-archive@odin.ietf.org>; Tue, 18 Jan 2000 10:50:25 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id KAA25617;
	Tue, 18 Jan 2000 10:36:15 -0500 (EST)
Resent-Date: Tue, 18 Jan 2000 10:36:15 -0500 (EST)
Resent-Message-Id: <200001181536.KAA25617@www19.w3.org>
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24568@crte147.wc.eso.mc.xerox.com>
From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'Yaron Goland'" <yarong@Exchange.Microsoft.com>, w3c-dist-auth@w3.org
Date: Tue, 18 Jan 2000 10:36:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.ApplePie3
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3870
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Comments in <js> </js> below.
 
 -----Original Message-----
From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
Sent: Sunday, January 16, 2000 8:26 PM
To: w3c-dist-auth@w3.org
Subject: WebDAV Bindings - Issue Yaron.ApplePie3



Section 11 of the BIND spec states: "A PROPFIND requesting DAV:bindings MUST
return only those bindings that the client is authorized to see."

This brings up a couple of questions. The first question is "How do I ever
know if I have the definitive list of bindings?" I suspect the answer is
"you don't" since there may be bindings you aren't authorized to see. 

<js> Right. </js>

This then brings us to another sentence in section 11 which reads "If the
DAV:bindings property exists on a given resource, it MUST contain a complete
list of all bindings to that resource."

However this means that the dav:bindings property must always return a
complete list of bindings which the sentence following it (given at the
start of this letter) contradicts. 

<js> I don't see this as contradictory.  The value of the property on the
resource is the complete list of bindings.  What gets returned in response
to any particular PROPFIND request is some subset of that value. </js> 

One should never have two MUST level requirements that are in direct
contradiction. The reason for the contradiction is that we have raised the
bar too high on the contents of the dav:bindings property value. We have
already specified that due to security concerns it is absolutely impossible
for you to ever be sure that you necessarily have the complete list of
bindings. Therefore requiring that the complete list be returned, even as
the default in the absence of security concerns, is self defeating.

Therefore I move that the language in section 11 be changed to read that the
dav:bindings property may contain zero or more of the bindings available on
a resource rather than the definitive set since it is impossible to
meaningfully require that the definitive set be returned.



From w3c-dist-auth-request@w3.org  Tue Jan 18 11:14:18 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01824
	for <webdav-archive@odin.ietf.org>; Tue, 18 Jan 2000 11:14:18 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA26997;
	Tue, 18 Jan 2000 11:03:21 -0500 (EST)
Resent-Date: Tue, 18 Jan 2000 11:03:21 -0500 (EST)
Resent-Message-Id: <200001181603.LAA26997@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E2B@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'Slein, Judith A'" <JSlein@crt.xerox.com>, w3c-dist-auth@w3.org
Date: Tue, 18 Jan 2000 08:02:16 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.ApplePie3
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3871
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

I suspect the issue is better described as "Can a user rely on getting back
a complete list of all the bindings they are allowed to see when they ask
for a dav:bindings property?"

I suspect Judy's answer will be "yes". Which is certainly reasonable. If so,
then we need to clarify the language in the spec to make this clear. This is
definitely a conclusion one can come to from reading the spec but it would
be useful if the conclusion was explicitly addressed. Language such as "A
client can rely upon the contents of the DAV:bindings property specifying
all bindings for that resource that the client is authorized to know about."

That having been said, it is also fairly clear that a design for weak
bindings will most likely want to use the DAV:bindings property. The reason
being that if one is performing a search one will almost certainly want to
search on both weak and strong bindings. If one wants one over the other,
one can always select the search based on resource type as weak bindings
will almost certainly have their own resource type. Strong bindings
obviously don't require their own resource type as, by definition, every
WebDAV resource (to some extent or another) is a strong binding.

As such I would like to see the DAV:bindings definition language tweaked to
say something along the lines of "DAV:bindings, when used with bindings as
defined in this specification,...."

By putting in the parenthetical phrase the weak bindings spec will be able
to say "DAV:bindings, when used with weak bindings, provides a list of
available bindings. This list may not necessarily be complete."

			Yaron


> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Tue, January 18, 2000 7:36 AM
> To: 'Yaron Goland'; w3c-dist-auth@w3.org
> Subject: RE: WebDAV Bindings - Issue Yaron.ApplePie3
> 
> 
> Comments in <js> </js> below.
>  
>  -----Original Message-----
> From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
> Sent: Sunday, January 16, 2000 8:26 PM
> To: w3c-dist-auth@w3.org
> Subject: WebDAV Bindings - Issue Yaron.ApplePie3
> 
> 
> 
> Section 11 of the BIND spec states: "A PROPFIND requesting 
> DAV:bindings MUST
> return only those bindings that the client is authorized to see."
> 
> This brings up a couple of questions. The first question is 
> "How do I ever
> know if I have the definitive list of bindings?" I suspect 
> the answer is
> "you don't" since there may be bindings you aren't authorized to see. 
> 
> <js> Right. </js>
> 
> This then brings us to another sentence in section 11 which 
> reads "If the
> DAV:bindings property exists on a given resource, it MUST 
> contain a complete
> list of all bindings to that resource."
> 
> However this means that the dav:bindings property must always return a
> complete list of bindings which the sentence following it 
> (given at the
> start of this letter) contradicts. 
> 
> <js> I don't see this as contradictory.  The value of the 
> property on the
> resource is the complete list of bindings.  What gets 
> returned in response
> to any particular PROPFIND request is some subset of that 
> value. </js> 
> 
> One should never have two MUST level requirements that are in direct
> contradiction. The reason for the contradiction is that we 
> have raised the
> bar too high on the contents of the dav:bindings property 
> value. We have
> already specified that due to security concerns it is 
> absolutely impossible
> for you to ever be sure that you necessarily have the complete list of
> bindings. Therefore requiring that the complete list be 
> returned, even as
> the default in the absence of security concerns, is self defeating.
> 
> Therefore I move that the language in section 11 be changed 
> to read that the
> dav:bindings property may contain zero or more of the 
> bindings available on
> a resource rather than the definitive set since it is impossible to
> meaningfully require that the definitive set be returned.
> 



From w3c-dist-auth-request@w3.org  Tue Jan 18 11:21:02 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02004
	for <webdav-archive@odin.ietf.org>; Tue, 18 Jan 2000 11:21:02 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA27546;
	Tue, 18 Jan 2000 11:09:35 -0500 (EST)
Resent-Date: Tue, 18 Jan 2000 11:09:35 -0500 (EST)
Resent-Message-Id: <200001181609.LAA27546@www19.w3.org>
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24569@crte147.wc.eso.mc.xerox.com>
From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'Yaron Goland'" <yarong@Exchange.Microsoft.com>,
        "Slein, Judith A"
	 <JSlein@crt.xerox.com>, w3c-dist-auth@w3.org
Date: Tue, 18 Jan 2000 11:09:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.ApplePie3
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3872
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This resolution sounds good to me.

--Judy

> -----Original Message-----
> From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
> Sent: Tuesday, January 18, 2000 11:02 AM
> To: 'Slein, Judith A'; w3c-dist-auth@w3.org
> Subject: RE: WebDAV Bindings - Issue Yaron.ApplePie3
> 
> 
> I suspect the issue is better described as "Can a user rely 
> on getting back
> a complete list of all the bindings they are allowed to see 
> when they ask
> for a dav:bindings property?"
> 
> I suspect Judy's answer will be "yes". Which is certainly 
> reasonable. If so,
> then we need to clarify the language in the spec to make this 
> clear. This is
> definitely a conclusion one can come to from reading the spec 
> but it would
> be useful if the conclusion was explicitly addressed. 
> Language such as "A
> client can rely upon the contents of the DAV:bindings 
> property specifying
> all bindings for that resource that the client is authorized 
> to know about."
> 
> That having been said, it is also fairly clear that a design for weak
> bindings will most likely want to use the DAV:bindings 
> property. The reason
> being that if one is performing a search one will almost 
> certainly want to
> search on both weak and strong bindings. If one wants one 
> over the other,
> one can always select the search based on resource type as 
> weak bindings
> will almost certainly have their own resource type. Strong bindings
> obviously don't require their own resource type as, by 
> definition, every
> WebDAV resource (to some extent or another) is a strong binding.
> 
> As such I would like to see the DAV:bindings definition 
> language tweaked to
> say something along the lines of "DAV:bindings, when used 
> with bindings as
> defined in this specification,...."
> 
> By putting in the parenthetical phrase the weak bindings spec 
> will be able
> to say "DAV:bindings, when used with weak bindings, provides a list of
> available bindings. This list may not necessarily be complete."
> 
> 			Yaron
> 
> 
> > -----Original Message-----
> > From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> > Sent: Tue, January 18, 2000 7:36 AM
> > To: 'Yaron Goland'; w3c-dist-auth@w3.org
> > Subject: RE: WebDAV Bindings - Issue Yaron.ApplePie3
> > 
> > 
> > Comments in <js> </js> below.
> >  
> >  -----Original Message-----
> > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
> > Sent: Sunday, January 16, 2000 8:26 PM
> > To: w3c-dist-auth@w3.org
> > Subject: WebDAV Bindings - Issue Yaron.ApplePie3
> > 
> > 
> > 
> > Section 11 of the BIND spec states: "A PROPFIND requesting 
> > DAV:bindings MUST
> > return only those bindings that the client is authorized to see."
> > 
> > This brings up a couple of questions. The first question is 
> > "How do I ever
> > know if I have the definitive list of bindings?" I suspect 
> > the answer is
> > "you don't" since there may be bindings you aren't 
> authorized to see. 
> > 
> > <js> Right. </js>
> > 
> > This then brings us to another sentence in section 11 which 
> > reads "If the
> > DAV:bindings property exists on a given resource, it MUST 
> > contain a complete
> > list of all bindings to that resource."
> > 
> > However this means that the dav:bindings property must 
> always return a
> > complete list of bindings which the sentence following it 
> > (given at the
> > start of this letter) contradicts. 
> > 
> > <js> I don't see this as contradictory.  The value of the 
> > property on the
> > resource is the complete list of bindings.  What gets 
> > returned in response
> > to any particular PROPFIND request is some subset of that 
> > value. </js> 
> > 
> > One should never have two MUST level requirements that are in direct
> > contradiction. The reason for the contradiction is that we 
> > have raised the
> > bar too high on the contents of the dav:bindings property 
> > value. We have
> > already specified that due to security concerns it is 
> > absolutely impossible
> > for you to ever be sure that you necessarily have the 
> complete list of
> > bindings. Therefore requiring that the complete list be 
> > returned, even as
> > the default in the absence of security concerns, is self defeating.
> > 
> > Therefore I move that the language in section 11 be changed 
> > to read that the
> > dav:bindings property may contain zero or more of the 
> > bindings available on
> > a resource rather than the definitive set since it is impossible to
> > meaningfully require that the definitive set be returned.
> > 
> 



From w3c-dist-auth-request@w3.org  Tue Jan 18 11:24:36 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02121
	for <webdav-archive@odin.ietf.org>; Tue, 18 Jan 2000 11:24:35 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA28129;
	Tue, 18 Jan 2000 11:13:26 -0500 (EST)
Resent-Date: Tue, 18 Jan 2000 11:13:26 -0500 (EST)
Resent-Message-Id: <200001181613.LAA28129@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E2C@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'Slein, Judith A'" <JSlein@crt.xerox.com>, w3c-dist-auth@w3.org
Date: Tue, 18 Jan 2000 08:12:05 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.ApplePieToo
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3873
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

I agree that we want to keep the sentence you identified below.

I also agree that we want to address the issue of a resource acting
differently based on the URI it is addressed from.

I suspect my problem with the language in the section derives from the
differentiation made between static and dynamic resources. In my experience
one can not really make the distinction because even if a "resource" is just
a file in a file system, there is always a server on top of it that may or
may not alter its presentation. If the language in section 9 were to be
re-written with the assumption that ALL resources are dynamic then I suspect
we would find the resulting language mutually acceptable. 

In other words, we should remove the terms dynamic/static completely and
instead talk about resources and the fact that their presentation can change
based solely on what URI they are accessed from. We shouldn't even try to
address the fact that in some cases, some resources for some period of time
may choose to look identical regardless of what URI they are accessed from.

		Yaron

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Tue, January 18, 2000 7:31 AM
> To: 'Yaron Goland'; w3c-dist-auth@w3.org
> Subject: RE: WebDAV Bindings - Issue Yaron.ApplePieToo
> 
> 
> The first paragraph doesn't really say anything substantive.  It just
> introduces the section, listing the methods to which it 
> applies.  The one
> substantive statement that I think we would want to keep is "For these
> methods, no new complexities are introduced by allowing 
> explicit creation of
> multiple bindings to the same resource."
>  
> I could be persuaded to reduce the section to just that.
>  
> But it still might be worth pointing out that BIND will make 
> it much more
> common to have multiple bindings to the same resource (even 
> though that was
> always possible).  And when there are multiple bindings to a 
> resource, it is
> possible for a resource's behavior in response to GET, HEAD, 
> PROPFIND, etc.,
> to be sensitive to the URI that was used to make the request. 
>  Maybe we
> wouldn't have to discuss the distinction between static and dynamic
> resources in order to make that point.
>  
> --Judy
>  
> 
> -----Original Message-----
> From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
> Sent: Sunday, January 16, 2000 8:28 PM
> To: w3c-dist-auth@w3.org
> Subject: WebDAV Bindings - Issue Yaron.ApplePieToo
> 
> 
> 
> Section 9 of the draft attempts to tackle the problem of how to
> differentiate the behavior of a resource based on its 
> bindings. It attempts
> to discuss the difference between a static and non-static 
> resource. However
> the difference between these two types of resources is so unbelievably
> arbitrary that I fail to see how attempting to differentiate 
> between them
> enhances interoperability.
> 
> For example, let us pretend we have the CurrentURI property. 
> The value of
> the property will be the Request-URI of the PROPFIND method 
> used to retrieve
> the value of the CurrentURI property. Now let us pretend we have two
> servers, A and B. A runs a version of WebDAV that 
> automatically generates
> the CurrentURI property on top of whatever resources it 
> supports. What this
> means is that even if the underlying data store where the resource is
> recorded doesn't know about the CurrentURI property, I can 
> still get the
> CurrentURI property through PROPFIND because A's server will 
> intercept the
> PROPFIND and insert the data itself. Server B doesn't support 
> CurrentURI at
> all. I now have a resource R that has bindings into A and B. 
> This means that
> if I ask for the CurrentURI property through the binding on 
> A, I will get a
> result with the URI on A. If I ask for the CurrentURI 
> property through the
> binding on B, I will not even see the property at all.
> 
> So the question is - Well is this a dynamic resource? Is it 
> not? Can I have
> the same resourceID on both URIs in this example? How does 
> the language in
> section 9 help me deal with this? Does it actually clarify 
> anything in a
> useful way?
> 
> As far as I can tell the language in section 9 is just 
> motherhood and apple
> pie language and that always makes for bad standard language.
> 
> Therefore I move that all the paragraphs in section 9 but the first
> paragraph be stricken from the BIND spec. 
> 



From w3c-dist-auth-request@w3.org  Tue Jan 18 11:37:25 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02281
	for <webdav-archive@odin.ietf.org>; Tue, 18 Jan 2000 11:37:24 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA29532;
	Tue, 18 Jan 2000 11:26:23 -0500 (EST)
Resent-Date: Tue, 18 Jan 2000 11:26:23 -0500 (EST)
Resent-Message-Id: <200001181626.LAA29532@www19.w3.org>
Date: Tue, 18 Jan 2000 11:25:46 -0500
Message-Id: <10001181625.AA24765@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: 
	<7DE119D3D0E15543874F7561EECBDBED02619E1E@BEG.platinum.corp.microsoft.com>
	(message from Yaron Goland on Sun, 16 Jan 2000 17:26:30 -0800)
Subject: Re: WebDAV Bindings - Issue Yaron.BindingsProperty
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3874
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


One possiblity is to say that "all dead properties of a resource must
be available from all bindings to that resource".  This acknowledges
that the behavior of live properties can be "special", including
acting differently at different bindings to that resource.

   From: Yaron Goland <yarong@Exchange.Microsoft.com>

   Section 11 of the BIND specification defines the dav:bindings property. What
   is not clear to me from the text in this section is if it is possible to
   have the dav:bindings property accessible through one binding but not
   another? 

   One could imagine that two servers share access to the same disk drive and
   hence are able to map names to the same "resource" (as they understand the
   term). In order to keep things consistent both servers agree to record all
   the names they use to refer to the same resource. However only one of the
   servers actually supports the BIND method and the dav:bindings property and
   the other doesn't. I can still do a GET on each server and the result will
   be from the same resource but only one of the servers will be able to serve
   up the dav:bindings property. Unfortunately the language in section 11
   speaks of the dav:bindings property being on a resource so the presumption
   is that if I can get the dav:bindings property through one binding then I
   MUST be able to get it through the other. I believe this is too strict a
   requirement.

   As such I move that the language in section 11 be clarified so as to specify
   that the dav:bindings property may not necessarily be available through all
   bindings on the resource.



From w3c-dist-auth-request@w3.org  Tue Jan 18 11:51:51 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02452
	for <webdav-archive@odin.ietf.org>; Tue, 18 Jan 2000 11:51:50 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA00995;
	Tue, 18 Jan 2000 11:39:59 -0500 (EST)
Resent-Date: Tue, 18 Jan 2000 11:39:59 -0500 (EST)
Resent-Message-Id: <200001181639.LAA00995@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E2D@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'Geoffrey M. Clemm'" <geoffrey.clemm@rational.com>, w3c-dist-auth@w3.org
Date: Tue, 18 Jan 2000 08:38:53 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: RE: WebDAV Bindings - Issue Yaron.BindingsProperty
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3875
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

One of the big mistakes WebDAV, in my opinion, made was differentiating
between live and dead properties. I think this is a meaningless
differentiation. For example, one can take any property, declare it "alive"
and instantly get around the requirement that dead properties be available
everywhere.

"Maul, I have you now, that is a dead property and therefore must be
available through all bindings!"

"I see you are weak in the ways of WebDAV Qui-Gon, my server is enhanced so
that all properties are treated as alive, therefore I do not have to make
them all available through all bindings!"

"But Maul, No! Ahhhhhhhhhhhhhhhhhhhhh...." (or whatever sound one makes when
a light saber is thrust through one's chest)

			Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com]
> Sent: Tue, January 18, 2000 8:26 AM
> To: w3c-dist-auth@w3.org
> Subject: Re: WebDAV Bindings - Issue Yaron.BindingsProperty
> 
> 
> 
> One possiblity is to say that "all dead properties of a resource must
> be available from all bindings to that resource".  This acknowledges
> that the behavior of live properties can be "special", including
> acting differently at different bindings to that resource.
> 
>    From: Yaron Goland <yarong@Exchange.Microsoft.com>
> 
>    Section 11 of the BIND specification defines the 
> dav:bindings property. What
>    is not clear to me from the text in this section is if it 
> is possible to
>    have the dav:bindings property accessible through one 
> binding but not
>    another? 
> 
>    One could imagine that two servers share access to the 
> same disk drive and
>    hence are able to map names to the same "resource" (as 
> they understand the
>    term). In order to keep things consistent both servers 
> agree to record all
>    the names they use to refer to the same resource. However 
> only one of the
>    servers actually supports the BIND method and the 
> dav:bindings property and
>    the other doesn't. I can still do a GET on each server and 
> the result will
>    be from the same resource but only one of the servers will 
> be able to serve
>    up the dav:bindings property. Unfortunately the language 
> in section 11
>    speaks of the dav:bindings property being on a resource so 
> the presumption
>    is that if I can get the dav:bindings property through one 
> binding then I
>    MUST be able to get it through the other. I believe this 
> is too strict a
>    requirement.
> 
>    As such I move that the language in section 11 be 
> clarified so as to specify
>    that the dav:bindings property may not necessarily be 
> available through all
>    bindings on the resource.
> 



From w3c-dist-auth-request@w3.org  Tue Jan 18 11:53:44 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02481
	for <webdav-archive@odin.ietf.org>; Tue, 18 Jan 2000 11:53:43 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA01375;
	Tue, 18 Jan 2000 11:42:15 -0500 (EST)
Resent-Date: Tue, 18 Jan 2000 11:42:15 -0500 (EST)
Resent-Message-Id: <200001181642.LAA01375@www19.w3.org>
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD2456A@crte147.wc.eso.mc.xerox.com>
From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'Yaron Goland'" <yarong@Exchange.Microsoft.com>, w3c-dist-auth@w3.org
Date: Tue, 18 Jan 2000 11:41:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.BindSyntax
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3876
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

There was a lot of discussion among the authors about the meanings of the
request-URI and the Destination header in the BIND request.
 
It was actually initially written so that it asked for the creation of a
binding at the Request-URI to the resource identified by the Destination
header.  The rationale for this was that it seemed more intuitive to have
the syntax of the request reflect the natural-language request: Create a
binding from this segment to this resource.  (Anyhow, that's how the spec
always expresses the request in English.)  And it seems as if the
Request-URI should identify the resource for which authorization would be
required to fulfill the request.  It's the collection where the binding
lives that gets modified, and so update permission would be needed on that
collection, and so that collection should be identified by the Request-URI.
 
We changed this to be consistent with the usage in COPY and MOVE, thinking
that it would be too confusing otherwise.  And servers would have to
interpret the Overwrite header differently for BIND than for COPY / MOVE if
we used the Request-URI and the Destination header differently than COPY /
MOVE.
 
We did not consider the implications of adding weak bindings.
 
But I would personally rather go back to the original syntax than introduce
a new header (or even suggest that such a header be introduced in the
future) that would flip the meanings of the Request-URI and Destination
header in a given request.  That is, I would propose that in all BIND
requests, the Request-URI identify the new binding, and the Destination
header identify the existing resource being bound to.
 
If it still seems unacceptable to be in conflict with the syntax of MOVE /
COPY, I would rather just go ahead and define a new header now that would
always be used in BIND requests to identify the resource being bound to.
That is, we would not use the Destination header at all.
 

- -Judy

 -----Original Message-----
From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
Sent: Sunday, January 16, 2000 8:47 PM
To: w3c-dist-auth@w3.org
Subject: WebDAV Bindings - Issue Yaron.BindSyntax



The BIND spec defines that a binding is created by sending a message to the
source and instructing it to create a binding at the destination. This is
completely consistent with how WebDAV normally operates in methods such as
COPY/MOVE where the source is instructed to make changes at the destination.
Unfortunately, in the case of BIND, it introduces a very serious problem
when (not if, but when) we introduce weak bindings. The problem is that the
current bind syntax requires the active participation of the source to
create a bind at the destination. In the case of a weak binding it is
expected that the source may not even be aware of the binding. This is one
of the main benefits of introducing weak bindings, it allows for bind like
behavior without requiring the participation of the source. This enables
many resources to have weak bindings against a resource without overloading
the resource.

An example may help here. Imagine a user wants to create a weak binding to
http://www.yahoo.com/foo/bar <http://www.yahoo.com/foo/bar> . Currently, to
create this weak binding, the user would have to issue the bind method to
http://www.yahoo.com/foo/bar <http://www.yahoo.com/foo/bar>  and ask the
Yahoo server to somehow communicate with the destination server and create a
weak binding. This is like telling people that before they can add a
hyperlink to their HTML document they have to first get the resource pointed
to by the hyperlink to somehow participate in the process. The ability to
link to resources without the knowledge of the source (as the term is used
in the BIND method) has been one of the key aspects of the scalability of
the Web.

In my mind the proper solution is to introduce a source header that, when
used on a BIND method, would mean that the request-URI specifies the
destination rather than the source.

That having been said I really have no desire to prolong the agony of the
BIND authors by asking them to add a new header and deal with all the
complexities it would introduce. As such I am happy to settle for the
following paragraph being added to section 5.1: "The BIND method MUST fail
if it does not include a destination header. Note, however, that future
specifications MAY introduce additional headers that resources could honor
in the place of the destination header and so allow the BIND method to
succeed in the absence of a destination header."

This would allow us, in the future, to introduce a weak binding spec that
could still use the BIND method without forcing us to use MAN or introduce a
new method.



From w3c-dist-auth-request@w3.org  Tue Jan 18 12:08:00 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02906
	for <webdav-archive@odin.ietf.org>; Tue, 18 Jan 2000 12:08:00 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA02966;
	Tue, 18 Jan 2000 11:56:54 -0500 (EST)
Resent-Date: Tue, 18 Jan 2000 11:56:54 -0500 (EST)
Resent-Message-Id: <200001181656.LAA02966@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E2E@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'Slein, Judith A'" <JSlein@crt.xerox.com>, w3c-dist-auth@w3.org
Date: Tue, 18 Jan 2000 08:55:43 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.BindSyntax
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3877
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

I believe that eventually we will be forced to make it possible to specify a
bind both ways. That is, one can send the request either to the source or
the destination.

The reason has to do with how many tightly bound (and weakly bound) systems
are likely to be implemented.

I will use a real world example to help illustrate.

Imagine I have server S1 and server S2. They both share the same tightly
replicated NTFS volume. Both servers map onto a particular file in the NTFS
volume. Following the specification provided by both the Exchange and NT
WebDAV implementations the WebDAV properties associated with that file are
recorded as an "alternate" stream on that file. Alternate streams are a
feature in Windows 2000 implementation of NTFS that allows one to have
multiple independent named streams off a file. What this means is that
someone can come in through SMB, move a file and all its WebDAV properties
will remain because the file system will move all the streams associated
with the file. (Yes, I recognize the problems this can cause)

Anyway, S1 is just a standard issue W2K WebDAV server and so serves off
files from the NTFS volume. S2, on the other hand, is an enhanced WebDAV
server that has support for BIND. S1 and S2 can both refer to the same file
on the NTFS volume and still meet all the BIND integrity requirements.
However only S2 can explicitly create new bindings since S1 doesn't support
the BIND method.

Therefore if one wants to creating a binding to a file currently pointed to
by S1 then the request must be sent to S2 (S2, btw, can figure out what file
S1 is pointing at by checking the metabase, but that is a whole other
story). However the reverse is also true, if one wants to create a binding
to a file pointed to by S2 then the request MUST also go to S2 because S1
doesn't understand BIND.

Therefore what is needed is the ability to specify a BIND request which can
choose to either have the source or the destination in the request-URI.

I expect that eventually the exact same thing will happen to COPY and MOVE.
The only reason it didn't happen in RFC 2518 is that we all knew that for a
really long time COPY and MOVE would only work within a single server so we
weren't particularly worried about the issue. We probably should have been
but one has to pick one's battles. Don't be too surprised to see the same
source/destination flexibility introduced into the next version of RFC 2518.

Either way, I don't care if we solve this problem in the current BIND spec
so long as we leave the door open to solving the problem later. That is why
I asked for the very limited language. If the authors really want to tackle
the whole problem that is fine with me but I didn't want to force them to do
so.

			Yaron

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Tue, January 18, 2000 8:42 AM
> To: 'Yaron Goland'; w3c-dist-auth@w3.org
> Subject: RE: WebDAV Bindings - Issue Yaron.BindSyntax
> 
> 
> There was a lot of discussion among the authors about the 
> meanings of the
> request-URI and the Destination header in the BIND request.
>  
> It was actually initially written so that it asked for the 
> creation of a
> binding at the Request-URI to the resource identified by the 
> Destination
> header.  The rationale for this was that it seemed more 
> intuitive to have
> the syntax of the request reflect the natural-language 
> request: Create a
> binding from this segment to this resource.  (Anyhow, that's 
> how the spec
> always expresses the request in English.)  And it seems as if the
> Request-URI should identify the resource for which 
> authorization would be
> required to fulfill the request.  It's the collection where 
> the binding
> lives that gets modified, and so update permission would be 
> needed on that
> collection, and so that collection should be identified by 
> the Request-URI.
>  
> We changed this to be consistent with the usage in COPY and 
> MOVE, thinking
> that it would be too confusing otherwise.  And servers would have to
> interpret the Overwrite header differently for BIND than for 
> COPY / MOVE if
> we used the Request-URI and the Destination header 
> differently than COPY /
> MOVE.
>  
> We did not consider the implications of adding weak bindings.
>  
> But I would personally rather go back to the original syntax 
> than introduce
> a new header (or even suggest that such a header be introduced in the
> future) that would flip the meanings of the Request-URI and 
> Destination
> header in a given request.  That is, I would propose that in all BIND
> requests, the Request-URI identify the new binding, and the 
> Destination
> header identify the existing resource being bound to.
>  
> If it still seems unacceptable to be in conflict with the 
> syntax of MOVE /
> COPY, I would rather just go ahead and define a new header 
> now that would
> always be used in BIND requests to identify the resource 
> being bound to.
> That is, we would not use the Destination header at all.
>  
> 
> - -Judy
> 
>  -----Original Message-----
> From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
> Sent: Sunday, January 16, 2000 8:47 PM
> To: w3c-dist-auth@w3.org
> Subject: WebDAV Bindings - Issue Yaron.BindSyntax
> 
> 
> 
> The BIND spec defines that a binding is created by sending a 
> message to the
> source and instructing it to create a binding at the 
> destination. This is
> completely consistent with how WebDAV normally operates in 
> methods such as
> COPY/MOVE where the source is instructed to make changes at 
> the destination.
> Unfortunately, in the case of BIND, it introduces a very 
> serious problem
> when (not if, but when) we introduce weak bindings. The 
> problem is that the
> current bind syntax requires the active participation of the source to
> create a bind at the destination. In the case of a weak binding it is
> expected that the source may not even be aware of the 
> binding. This is one
> of the main benefits of introducing weak bindings, it allows 
> for bind like
> behavior without requiring the participation of the source. 
> This enables
> many resources to have weak bindings against a resource 
> without overloading
> the resource.
> 
> An example may help here. Imagine a user wants to create a 
> weak binding to
> http://www.yahoo.com/foo/bar <http://www.yahoo.com/foo/bar> . 
> Currently, to
> create this weak binding, the user would have to issue the 
> bind method to
> http://www.yahoo.com/foo/bar <http://www.yahoo.com/foo/bar>  
> and ask the
> Yahoo server to somehow communicate with the destination 
> server and create a
> weak binding. This is like telling people that before they can add a
> hyperlink to their HTML document they have to first get the 
> resource pointed
> to by the hyperlink to somehow participate in the process. 
> The ability to
> link to resources without the knowledge of the source (as the 
> term is used
> in the BIND method) has been one of the key aspects of the 
> scalability of
> the Web.
> 
> In my mind the proper solution is to introduce a source 
> header that, when
> used on a BIND method, would mean that the request-URI specifies the
> destination rather than the source.
> 
> That having been said I really have no desire to prolong the 
> agony of the
> BIND authors by asking them to add a new header and deal with all the
> complexities it would introduce. As such I am happy to settle for the
> following paragraph being added to section 5.1: "The BIND 
> method MUST fail
> if it does not include a destination header. Note, however, 
> that future
> specifications MAY introduce additional headers that 
> resources could honor
> in the place of the destination header and so allow the BIND method to
> succeed in the absence of a destination header."
> 
> This would allow us, in the future, to introduce a weak 
> binding spec that
> could still use the BIND method without forcing us to use MAN 
> or introduce a
> new method.
> 



From w3c-dist-auth-request@w3.org  Tue Jan 18 14:17:51 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04886
	for <webdav-archive@odin.ietf.org>; Tue, 18 Jan 2000 14:17:50 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA08238;
	Tue, 18 Jan 2000 14:06:30 -0500 (EST)
Resent-Date: Tue, 18 Jan 2000 14:06:30 -0500 (EST)
Resent-Message-Id: <200001181906.OAA08238@www19.w3.org>
From: ccjason@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
cc: w3c-dist-auth@w3.org
Message-ID: <8525686A.0068EAF0.00@D51MTA03.pok.ibm.com>
Date: Tue, 18 Jan 2000 14:05:19 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: WebDAV Bindings - Issue Yaron.Insulting2616, definition of 	 resource
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3878
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


I agreed or didn't understand various parts of your note until I got to the
following.  I think
it explains what you're trying to get at when you speak of the server
knowing if something
is the same resource or not.

>>
  A better example is a collection consisting of "Fred", "Frederick",
  and "Douglass".  Those could be three different resources (for example,
  individuals within a team of coders) or three different aliases for
  the same resource.  The only person who really knows the answer is the
  person defining the namespace -- it just isn't something that a server
  can figure out by analyzing the implementation, because what
differentiates
  one resource from another is the semantics given to them when each URI is
  used within some external reference.  The server can't even rely on the
  implementation giving some indication of the difference, since the
  implementation is allowed to change over time, whereas the semantics of
  a resource does not (legitimately) change over time.
>>

You are trying to emphasize the definition of a resource as being in
the eyes of the author.
And that you want the server somehow be able to know and track the author's
concept of "the resource"... and distinguish it from the current
implementation
of the resource.   And because bindings remove the tight one-to-one
association
of the conceptual resource from its implementation, you feel the advent of
bindings is a good place to have the server start maintaining that
separation
and support both concepts fully.

It sounds like you'd like to be able to insert another level of indirection
in our model.  A "a-resource" is the author's conceptual resource.  A
"s-resource"
is a server's concept of a resource and represents an implementation.

   URI:  leadprogrammer.html     john.html       fred.html

----------------

   aresource: lead_programmer_personal_page   aresource: john  aresource:
fred

-----------------

   sresource: John.html   sresource: John.pl   sresource: Fred.html

-------------------

 states of sresources: John.html.001  John.html.002  John.pl.001
Fred.html.001


The "binding" from URI to aresource is pretty static.  The URI basically
should
continue to point to the same concept until the end of time.... ideally.
OTOH
over time the author might
change the implementation to use a different sresource for a given
conceptual
resource.  And over time the implementation of the sresource might evolve
as it is debugged.

So what we've done in WebDAV is compressed the URI and conceptual resource
layers together since ideally they should remain as a one:one mapping for
eternity.  That means if we have a situation like...

 leadprog.html  john.html  fred.html
    |               |          |
  lead_prog       john       fred
     \             /           |
      \          /             |
        John.html            Fred.html

In webdav we'd create a situation like the following.

 leadprog.html  john.html  fred.html
     \             /           |
      \          /             |
        John.html            Fred.html




>>
And you are thinking of the resource as an implementation of the resource
rather than the resource.
>>
Actually I was thinking both.  I was emphasizing the server's concept
as something that the author could still leverage to maintain his
concept.  I didn't feel it was important for the server to maintain
the author's concept of a resource, but I felt that if the author
wanted the server to, it could.  That's what I meant when I spoke
about a proxy object.

What I was saying about a proxy object is that
the author could actually create a server resource to represent his
concept of a resource and distinguish it from its implementation.  That
object
would not implement anything.  It's only job would be to redirect
to the server object that currently implements the authors concept.
The server could manage both the conceptual resource and the implementation
resource as WebDAV resources.

The fly in the ointment is that ideally we'd like the proxy object
to have a ***strong*** link/binding (whatever you want to call it) to its
implemenation object.  The only type
of strong links that we provide right now are bindings.  And they are only
kept by collections.   So this proxy object would basically need to be a
collection.  Presumably that collection would only be allowed one child
and it would always internally redirect to it.  Of course it can't always
redirect ALL requests.  Presumably there are operations that we might want
to do on the proxy itself.  (Maybe there aren't.)

Anyway, the basic ground work is there to do this if the author wants to.
It isn't explicitly supported in the protocol though.  It could be at a
later date though.  As I said, the ground work is there.

BTW... you mentioned that BIND acts on the wrong object.  I think most of
us recognize this, but I just wanted to remind you to get back to us with
your commments and insight on that.

Jason.




From w3c-dist-auth-request@w3.org  Tue Jan 18 15:48:31 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05681
	for <webdav-archive@odin.ietf.org>; Tue, 18 Jan 2000 15:48:30 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA11755;
	Tue, 18 Jan 2000 15:33:37 -0500 (EST)
Resent-Date: Tue, 18 Jan 2000 15:33:37 -0500 (EST)
Resent-Message-Id: <200001182033.PAA11755@www19.w3.org>
From: ccjason@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: Yaron Goland <yarong@Exchange.Microsoft.com>
cc: w3c-dist-auth@w3.org
Message-ID: <8525686A.0070E47D.00@D51MTA03.pok.ibm.com>
Date: Tue, 18 Jan 2000 15:32:25 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: WebDAV Bindings - Issue Yaron.AtomicDelete
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3879
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


>>
Because BIND redefines how collections work the effect of this paragraph is
to directly amend the behavior of RFC 2518 in a manner that is not
compliant with how RFC 2518 is currently written.
>>
That is correct.  We should consider amending the follow-on document to
2518 to use this revised defintion of DELETE.

>>
Things brings up the first issue. Redefining DELETE to be atomic without
using the mandatory mechanism to prevent confusion on the part of clients
and servers will destroy interoperability with RFC 2518 systems. A BIND
enhanced client issuing a DELETE against a RFC 2518 server will expect
atomic behavior and probably won't get it.
>>
That depends on the server.  2518 servers were free to implement it in the
fashion defined in the binding spec.  Some servers will interoperate with
no modification.  As for clients, it is unlikely that a client would
actually code itself to depend on the 2518 behavior.


>>
There are cases where it is worth creating incompatibilities, for example,
if you find out that their is a serious flaw in the protocol. However no
one has demonstrated that the non-atomic behavior of DELETE is a flaw.
>>
It is a serious flaw in the protocol.   It causes undeterministic behavior
and risks broken bindings other than the one requested... and the requester
is unlikely to detect this.  But other folks using other bindings into the
tree WILL notice.  It will impact others using the same tree.  And
correcting it after the fact is difficult.    In addition, a server
implementing the 2518 behavior in the way you suggest will almost certainly
be slow.  There is no need for this behavior and it needlessly complicates
the protocol.

>>
It is a pain, that is true. It certainly makes it difficult to write
clients. But as evidenced by the number of WebDAV clients it is clear that
the requirement is one that can be met.
>>
And what do those existing clients do in this situation?  If the operation
succeeds, they are unlikely to notice and even consider the damage that was
done.   Most of them interact on a single operation basis and don't care.
They just display the end result.  But if the DELETE is part of a sequence,
there's not much they can do with the 2518 behavior partial failure.   All
they can do is abort and perhaps beg the user to use some out of band
mechanism to restore the damage that has been done.

>>
Heck, as evidenced by the number of file system clients written in the last
30 years, it is clear that the requirement to handle non-atomic behavior
can be met.
>>
In systems that support multiple bindings, they all provide a mechanism to
remove a single binding.  Even in other systems the action is often atomic.
History doesn't suggest that the iterative delete is the proper semantic
for the client.


>>
Changing DELETE to atomic is especially egregious given that WebDAV does
not prevent a server from implementing DELETE atomically. Rather it puts
the client in the unfortunate situation of having to deal with systems that
can't necessarily support atomic DELETE.
>>
????

>>
 There are, I freely admit, circumstances in which a client MUST be able to
ensure that a DELETE is issued atomically. Clients in those cases will have
to choose to not interoperate with many WebDAV servers in order to gain
atomic delete.
>>
These clients can interoperate with an old iterative server just fine if
they also include 2518 support.  That's their choice.

We have asked around and it seems that server authors appreciate and are
willing to comply with semantic of an "atomic" removal of a single binding.


>>
 The proper way for them to express their requirement that a delete be
atomic is either to issue DELETE with a MAN extension or to create a new
method.
>>
The only reason this would be needed is if there actually were a client
side requirement to actually have it act in an iterative fashion.  There
does not seem to be any pressing client need for this and the possiblity of
damage is great... even if it isn't the requester that suffers from that
damage..
The only other reason would be for a client to  declare that it must *NOT*
act iteratively.  But of course old 2518 based servers wouldn't be looking
for this flag.  For this reason, the possibility of an UNBIND method
wouldn't be a bad thing, but the presence of this UNBIND method doesn't
mean that the DELETE method should be allowed to iteratively break bindings
other than the requested binding.


>>
But the behavior of the DELETE method is well defined by RFC 2518 and given
that there is no evidence that this behavior is broken in any way. In fact,
given that their is over whelming evidence that non-atomic DELETE works
just fine and leads to interoperable implementations.
>>
It's very broken.  It deletes bindings other than the requested binding.
Even upon success.  This can affect folks accessing a tree via another
binding.  For this reason it is very broken even when the request succeeds.
And because DELETE is a legacy method, it may be used by folks that aren't
aware of the damage that can be done.

>>
Let me clarify that DELETE was defined to not be atomic with malice of fore
thought. The non-atomic delete language was the result of nearly three
years of negotiations and represented a deep and broad consensus built up
amongst a huge community. Might I respectfully suggest to the BIND authors
that they should not be so ready to overthrow years of careful consensus
building.
>>
We've asked around.  Folks appreciate this behavior and are willing to
support it.

>>
Do not imagine that the lack of screaming on this issue reflects consensus.
Rather it reflects the fact that most of the WebDAV community is too busy
implementing RFC 2518 to pay much attention to BIND. The BIND
functionality, while I believe it will be important to WebDAV, is a bit
ahead of the majority of implementers so they just aren't reading or
reviewing it, yet.
>>
We have asked around and we didn't accept silence as a response.

>>
The key reason DELETE was not allowed to be atomic (which certainly would
have been a nice thing to be able to do) has to do with the way file
systems work. Most file systems do not support depth operations atomically.
So, for example, when you delete a directory what actually happens is that
the program does a depth first walk of the directory tree and deletes all
the individual files, walking backwards up the tree until finally deleting
the parent directory.
>>
You've pointed out that this is a problem on your file system.  We've found
no other.   We've tested it and our testing indicates that the MOVE option
you mention below works.  (We did not test with ACL's though... or multiple
bindings.)    We've also contacted folks at your organization and they
didn't see a problem.

>>
This brings us to our second issue, the argument has been made that a file
system could simulate an atomic DELETE by issuing a MOVE command against a
directory and ensuring that nothing exists at the destination. This would
make it appear that all the files have been deleted. The file system could
then later delete the files at its convenience. In addition this sort of
implementation would allow the type of functionality you see today in the
Windows GUI where deleted files are first placed into the waste basket
before actually being deleted.

This theory has several problems in practice.

Problem #1 - There exists a write ACL (which covers MOVE) and a delete ACL
(which covers DELETE).
It is possible, therefore, to have the right to delete a file but not the
right to move it. As such if a user is running a WebDAV server under their
own authentication then the server will have to fail the DELETE command,
even if they have the right access settings for delete, because the server
can't move the file first in order to simulate the atomic DELETE behavior.
The prevents file system based servers from implementing the "MOVE is an
atomic DELETE" hack.
>>
This ACL situation did not come up before.  so I just tested it.   It is
indeed possible to prevent deletion of an object via ACL's.  By deletion, I
mean the file system's concept of DELETE.   On the other hand, my testing
has shown that ACL's in a tree do not prevent the movement of the tree.
The only acl that can prevent this is an ACL on the collection resource
that is to be removed.  Testing that is quick.  It doesn't require
iterating through all the children to determine if there is at least one
down there with an uncooperative ACL.    ACL's don't come into play.

The only way the ACL's might possibly come into play is if there was an ACL
combination that allowed movement, but didn't allow garbage collecting
subsequently..   I believe there is and won't go to the trouble to check.
How and whether a server garbage collects isn't something we cover in the
spec though.  We've tried, but it was just a rat hole that defied
definition.  It is an interesting problem and it will be interesting to see
how creative servers will be addressing this issue.

Anyway, ACL's don't appear to pose a problem implementing the protocol.



>>
Problem #2 - The required mechanism could actually form a denial of service
attack. Imagine a server gives a space allocation to all of their users. A
user then shows up and knows that the server is running low on space.
Therefore the user decides to fill up their allocation with junk, delete
it, fill it up again, delete it, etc. Each time the server will have to
move all the user's junk to some temp space in order to simulate the atomic
delete. If the server can't delete the temp files fast enough then the
server's disk space will be overrun. One could attempt to counter this
attack by specifying that one can only DELETE something if one has enough
space left in one's space allocation for the MOVE. Of course this means
that if one has filled up one's allocation and wants to delete some files
to get more space the delete will fail because there is no room to do the
move. Of course, if there was room to do the move then one wouldn't have
wanted to delete the files since one would still have space. Catch-22.
>>
This is a bookkeeping issue.  Remember, the DELETE is not an allocation
issue.  It's removing the resource out of one or more places in the
namespace and that's the only verifiable semantic that we can talk about.
We've tried.  Whether the resource continues to exist after it loses its
last binding is up to the server.  If the server has a need, it is free to
delay returning from the DELETE until it has deallocated any resources it
feels it needs to deallocate.  Or it can delay a subsequent request from
that user.   It has these options.

I'll add, that for the time being, equating binding removal with the
freeing of resources should not be encouraged.   The person removing the
resource doesn't know if they have the last binding.   They don't know if
the server is allowed to deallocate a given unreachable resource.   They
may not be aware if the server keeps quotas.   Or if the resources that
became unreachable are part of it's quota.  Or if a request by them could
ever result in an automatic deallocation of a resource owned by someone
else.  A client doesn't even know that a server automatically garbage
collects.   Even if a client knows how one server works,  making any
assumptions here is risking interoperability.

>>
Problem #3 - File system servers are now getting smart enough to add
eventing support to their file systems. The idea is that you can register
to be told when a file is deleted or moved. However the delete and move
events are different. Forcing WebDAV file system servers to simulate a
DELETE as a move would cause the wrong event to get triggered. This means
that one can never be sure if that MOVE event was received because the user
intended to MOVE a file or because it was part of a DELETE operation. This
is especially important when one has a store that is accessible through
multiple means, say WebDAV and FTP. The events are registered directly on
the file system, not in the WebDAV or FTP implementation. So there is no
way for the WebDAV implementation to say "I know I'm doing a MOVE but you
really should just trigger the delete event."
>>
At the WebDAV level, it is a namespace operation.  Not an allocation issue.
If it has to send a MOVE event, then that's what it needs to send.  If the
server then decides to deallocate the resource then it should send the
appropriate message at that time.   It can even do so right away if it
doesn't affect the semantics of the request.  What I mean by this last
statement is that the server is free to do the delete if it knows all the
requests will succeed and the object is going to get GC in an instant
anyway.  That's just an optimization though.

I can imagine a situation where for any resource that becomes unreachable
will appear in the trash can of the owner of that resource.  If they have
an advisory lock on it, they will be informed of the movement to the trash
can.   This will even work if someone else made it unreachable.  And if the
owner throws out this portion of his trash, he might increase his available
space.  This is similar to how some popular desktops work now.   And I
don't want to suggest that this is the only way to do this.


>>
There is then the third and final issue, WebDAV begins with a "D" for a
reason. It's goal is to be distributed. Requiring atomic DELETEs would
essentially hinder all but the most expensive of systems from being able to
implement distributed namespaces across multiple physical servers. The
reason being that the atomic requirement means that these systems will have
to establish transactioning systems between themselves in order to issue
DELETEs if they share namespace.
>>
It's only one binding.  The goal isn't to be atomic, that's just a
fortunate side effect.  A system would fulfill the request in the same
fashion that it would normally do that in the absense of WebDAV.  If that
system is also distributed, then it already has to deal with the
distributed part of that issue.  If the server wants to make it distributed
on top of a non-distributed repository, then it has to handle all this
itself.   Lacking evidence to the contrary, I'd expect  deleting a single
binding would be easier to implement than deleting many of them.
Especially in a distributed environment.

>>
As such I move that the atomic DELETE language be struck from the BIND spec
on the grounds that it destroys interoperability, requires behavior that
would preclude file system based systems from supporting WebDAV and
significantly increases the cost of implementing WebDAV in a distributed
manner.
>>
I believe I've addressed all of these above.

It is very clear that DELETE should not be iterative or accept partial
results in a server that supports multiple bindings.  Legacy clients may
invoke DELETE without knowledge of the potential dangers.  Therefore, a
simple DELETE should delete a single binding.  --- There is no compelling
reason (so far) not to support single binding delete and it simplifies the
protocol and makes behavior consistant across all servers.  Single binding
delete should be the long term target behavior for WebDAV.

Jason.




From w3c-dist-auth-request@w3.org  Tue Jan 18 17:38:30 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06821
	for <webdav-archive@odin.ietf.org>; Tue, 18 Jan 2000 17:38:30 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id RAA16568;
	Tue, 18 Jan 2000 17:27:19 -0500 (EST)
Resent-Date: Tue, 18 Jan 2000 17:27:19 -0500 (EST)
Resent-Message-Id: <200001182227.RAA16568@www19.w3.org>
From: ccjason@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: Yaron Goland <yarong@Exchange.Microsoft.com>
cc: w3c-dist-auth@w3.org
Message-ID: <8525686A.007B4DE2.00@D51MTA03.pok.ibm.com>
Date: Tue, 18 Jan 2000 17:26:11 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: RE: WebDAV Bindings - Issue Yaron.ApplePieToo
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3880
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


  I suspect my problem with the language in the section derives from the
  differentiation made between static and dynamic resources. In my
experience
  one can not really make the distinction because even if a "resource" is
just
  a file in a file system, there is always a server on top of it that may
or
  may not alter its presentation. If the language in section 9 were to be
  re-written with the assumption that ALL resources are dynamic then I
suspect
  we would find the resulting language mutually acceptable.

I agree that there is a perspective that there are no truly static
resources in the world,
but if we get hung up on that, we're verging on a meta-physical discussion
that will
distract from the point of this section.  And if we tried to write
something that works
for all dynamic resources, there truly wouldn't be anything meaningful said
in that
section.   That section is very readable right now and does a good job of
conveying a fuzzy concept/behavior:

There are a range of resources.  From the ideal static resource to the most
dynamic resource
you could imagine.  One will probably never encounter a resource at either
extreme.  Where
a given resource lies between these two extremes is in the eyes of the
beholder... but the
platonic ideal of a static resource acts in this fashion...

That being said, feel free to write up a new version of that section, but
please don't get overly
distracted trying to convey the fact the the nominal "static resource" is
only an ideal.
I do feel if one's focus is too much on that, they will write something
less effective
than the current text.   As I said, the current text seems to do a good job
conveying
a fuzzy topic.





From w3c-dist-auth-request@w3.org  Tue Jan 18 21:07:25 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08565
	for <webdav-archive@odin.ietf.org>; Tue, 18 Jan 2000 21:07:25 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA24065;
	Tue, 18 Jan 2000 20:55:15 -0500 (EST)
Resent-Date: Tue, 18 Jan 2000 20:55:15 -0500 (EST)
Resent-Message-Id: <200001190155.UAA24065@www19.w3.org>
From: ccjason@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: Yaron Goland <yarong@Exchange.Microsoft.com>
cc: w3c-dist-auth@w3.org
Message-ID: <8525686B.000A7A6C.00@D51MTA03.pok.ibm.com>
Date: Tue, 18 Jan 2000 20:39:46 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id UAA24045
Subject: Re: WebDAV Bindings - Issue Yaron.507
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3881
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 8bit


>>
In section 5.5 the 507 error code is written as "507 (Cross-Server Binding
Forbidden): The server is unable to create the requested binding because it
would bind a segment in a collection on one server to a resource on a
different server."

        What does a server have to do with anything? If you try to bind two
resources in different volumes on a FrontPage server the server will have
to fail the BIND even though the resources are on the same server. In
general bringing in the server is almost always a bad idea since resources
can be spread out all over the place and the reasons for various failures
may or may not have anything to do with how those resources are laid out on
the servers. As such I move that the language for the 507 error code be
altered to read that the resource was unable to create a binding to a
destination and to leave the matter at that. All mentions of the word
server should be stricken.
>>

Hmmm.  I don't have a strong preference on whether we should create a new
status code for lack of support for remote connections.  At some point we
might find we need one.   Anyway.... the status code that you're suggesting
doesn't seem to suggest anything except that the server can't do it.
Can't we just use 500 for that?   And if so, shouldn't we mention 500 it in
the spec?  Or is 500 too obvious to mention?









From w3c-dist-auth-request@w3.org  Wed Jan 19 09:12:19 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29074
	for <webdav-archive@odin.ietf.org>; Wed, 19 Jan 2000 09:12:19 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id JAA07707;
	Wed, 19 Jan 2000 09:00:45 -0500 (EST)
Resent-Date: Wed, 19 Jan 2000 09:00:45 -0500 (EST)
Resent-Message-Id: <200001191400.JAA07707@www19.w3.org>
From: "Rickard Falk" <rickard.falk@excosoft.se>
To: <w3c-dist-auth@w3.org>
Date: Wed, 19 Jan 2000 15:00:30 +0100
Message-ID: <NDBBLFJCCKNFKHAFJDCDOENGCBAA.rickard.falk@excosoft.se>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: Should I use displayname?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3882
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

When I'm trying to perform a directory browsing, that I'm going to present
to a user. Should I then present the Displayname info or should I pars the
href to get the name of the resource, from the Propfind request?
If I should use the Displayname info, can I rely on that it only contains
the name of the resource and not the complete path? ( this seems to be the
case for IIS, Xythos, Zope. But not for CyberTeams server )

/Rickard



From w3c-dist-auth-request@w3.org  Wed Jan 19 10:51:25 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01024
	for <webdav-archive@odin.ietf.org>; Wed, 19 Jan 2000 10:51:20 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id KAA11220;
	Wed, 19 Jan 2000 10:40:17 -0500 (EST)
Resent-Date: Wed, 19 Jan 2000 10:40:17 -0500 (EST)
Resent-Message-Id: <200001191540.KAA11220@www19.w3.org>
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD2456C@crte147.wc.eso.mc.xerox.com>
From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'ccjason@us.ibm.com'" <ccjason@us.ibm.com>,
        Yaron Goland
	 <yarong@Exchange.Microsoft.com>
Cc: w3c-dist-auth@w3.org
Date: Wed, 19 Jan 2000 10:39:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.ApplePieToo
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3883
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Here's some text that doesn't mention static / dynamic.  It doesn't make the
simple, idealized statement that we wanted for static resources, but maybe
it says enough to be useful:

"This section describes the interaction of bindings with those HTTP methods
not yet explicitly discussed.  The semantics of the methods GET, HEAD, PUT,
POST and OPTIONS are specified in [HTTP].  The semantics of PROPFIND,
PROPPATCH, and MKCOL are specified in [WebDAV].

"For these methods, no new complexities are introduced by allowing explicit
creation of multiple bindings to the same resource.  However, the
introduction of the BIND method will make it more common for multiple URIs
to map to the same resource.  As a result, the introduction of the BIND
method may point up complexities that were already possible, but occurred
only rarely in the past.  

"In particular, when there are multiple URI mappings to the same resource,
it is possible for the resource's behavior in response to GET, HEAD,
PROPFIND, etc., to be sensitive to the URI that was used to make the
request.  For example, the Request-URI may appear in the response entity
body for GET on a particular resource, in which case the response entity
body produced by that resource will differ depending upon which URI was used
to make the request.

"The only way for a client to determine whether two URIs map to the same
resource is by retrieving and comparing the DAV:resourceid property defined
in the following section."

Or we could keep the current text, but add some remarks about the static /
dynamic distinction, along the lines that Jason suggests:

"This section describes the interaction of bindings with those HTTP methods
not yet explicitly discussed.  The semantics of the methods GET, HEAD, PUT,
POST and OPTIONS are specified in [HTTP].  The semantics of PROPFIND,
PROPPATCH, and MKCOL are specified in [WebDAV].

"For these methods, no new complexities are introduced by allowing explicit
creation of multiple bindings to the same resource.  However, the
introduction of the BIND method will make it more common for multiple URIs
to map to the same resource.  When these methods are applied to the same
resource using different Request-URIs, the rules for their behavior depend
upon whether the resource is static or dynamic.

"A static resource is one that always produces the same response to the same
method with identiical parameters.

"A dynamic resource is one that may produce different responses for
different submissions of the same method with identical parameters.

"In reality, a single resource may respond statically to some requests, but
dynamically to others.  However, for a pure static resource, these methods
obey the folowing rule:

"o  A method submitted through one URI mapping, on success, MUST produce the
same results as the same method, with the same headers and entity body,
submitted through any other URI mapping to the same resource.

"When applied to dynamic resources, it is not possible to state any such
rule.  For any method, a dynamic resource may be sensitive to the URI
mapping used to access it.  The resource may produce different results
depending upon which URI mapping was used to submit the request."

--Judy

> -----Original Message-----
> From: ccjason@us.ibm.com [mailto:ccjason@us.ibm.com]
> Sent: Tuesday, January 18, 2000 5:26 PM
> To: Yaron Goland
> Cc: w3c-dist-auth@w3.org
> Subject: RE: WebDAV Bindings - Issue Yaron.ApplePieToo
> 
> 
> 
>   I suspect my problem with the language in the section 
> derives from the
>   differentiation made between static and dynamic resources. In my
> experience
>   one can not really make the distinction because even if a 
> "resource" is
> just
>   a file in a file system, there is always a server on top of 
> it that may
> or
>   may not alter its presentation. If the language in section 
> 9 were to be
>   re-written with the assumption that ALL resources are dynamic then I
> suspect
>   we would find the resulting language mutually acceptable.
> 
> I agree that there is a perspective that there are no truly static
> resources in the world,
> but if we get hung up on that, we're verging on a 
> meta-physical discussion
> that will
> distract from the point of this section.  And if we tried to write
> something that works
> for all dynamic resources, there truly wouldn't be anything 
> meaningful said
> in that
> section.   That section is very readable right now and does a 
> good job of
> conveying a fuzzy concept/behavior:
> 
> There are a range of resources.  From the ideal static 
> resource to the most
> dynamic resource
> you could imagine.  One will probably never encounter a 
> resource at either
> extreme.  Where
> a given resource lies between these two extremes is in the eyes of the
> beholder... but the
> platonic ideal of a static resource acts in this fashion...
> 
> That being said, feel free to write up a new version of that 
> section, but
> please don't get overly
> distracted trying to convey the fact the the nominal "static 
> resource" is
> only an ideal.
> I do feel if one's focus is too much on that, they will write 
> something
> less effective
> than the current text.   As I said, the current text seems to 
> do a good job
> conveying
> a fuzzy topic.
> 
> 
> 



From w3c-dist-auth-request@w3.org  Wed Jan 19 10:59:51 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01080
	for <webdav-archive@odin.ietf.org>; Wed, 19 Jan 2000 10:59:49 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id KAA11880;
	Wed, 19 Jan 2000 10:48:50 -0500 (EST)
Resent-Date: Wed, 19 Jan 2000 10:48:50 -0500 (EST)
Resent-Message-Id: <200001191548.KAA11880@www19.w3.org>
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD2456D@crte147.wc.eso.mc.xerox.com>
From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'ccjason@us.ibm.com'" <ccjason@us.ibm.com>,
        Yaron Goland
	 <yarong@Exchange.Microsoft.com>
Cc: w3c-dist-auth@w3.org
Date: Wed, 19 Jan 2000 10:48:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id KAA11855
Subject: RE: WebDAV Bindings - Issue Yaron.507
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3884
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 8bit

I don't have a strong commitment to 507 either, but for what it's worth the
rationale was that any creation of a cross-server binding requires
out-of-band collaboration between the servers.  So it seems very likely that
a lot of servers will fail requests to create a binding to a resource on
another server, so it seems useful to have an error code for this case.

--Judy

> -----Original Message-----
> From: ccjason@us.ibm.com [mailto:ccjason@us.ibm.com]
> Sent: Tuesday, January 18, 2000 8:40 PM
> To: Yaron Goland
> Cc: w3c-dist-auth@w3.org
> Subject: Re: WebDAV Bindings - Issue Yaron.507
> 
> 
> 
> >>
> In section 5.5 the 507 error code is written as "507 
> (Cross-Server Binding
> Forbidden): The server is unable to create the requested 
> binding because it
> would bind a segment in a collection on one server to a resource on a
> different server."
> 
>         What does a server have to do with anything? If you 
> try to bind two
> resources in different volumes on a FrontPage server the 
> server will have
> to fail the BIND even though the resources are on the same server. In
> general bringing in the server is almost always a bad idea 
> since resources
> can be spread out all over the place and the reasons for 
> various failures
> may or may not have anything to do with how those resources 
> are laid out on
> the servers. As such I move that the language for the 507 
> error code be
> altered to read that the resource was unable to create a binding to a
> destination and to leave the matter at that. All mentions of the word
> server should be stricken.
> >>
> 
> Hmmm.  I don't have a strong preference on whether we should 
> create a new
> status code for lack of support for remote connections.  At 
> some point we
> might find we need one.   Anyway.... the status code that 
> you're suggesting
> doesn't seem to suggest anything except that the server can't do it.
> Can't we just use 500 for that?   And if so, shouldn't we 
> mention 500 it in
> the spec?  Or is 500 too obvious to mention?
> 
> 
> 
> 
> 
> 
> 



From w3c-dist-auth-request@w3.org  Wed Jan 19 11:28:49 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01489
	for <webdav-archive@odin.ietf.org>; Wed, 19 Jan 2000 11:28:48 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA12868;
	Wed, 19 Jan 2000 11:17:40 -0500 (EST)
Resent-Date: Wed, 19 Jan 2000 11:17:40 -0500 (EST)
Resent-Message-Id: <200001191617.LAA12868@www19.w3.org>
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD2456E@crte147.wc.eso.mc.xerox.com>
From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'Yaron Goland'" <yarong@Exchange.Microsoft.com>, w3c-dist-auth@w3.org
Date: Wed, 19 Jan 2000 11:17:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.403
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3885
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

The previous revision of the spec had a separate error code for this case,
and I have no objection to putting it back in.  I think it would be a 5xx
rather than a 4xx though.  There's no error in the request, it's just that
the particular server has a policy forbidding creation of loops.
 
--Judy

-----Original Message-----
From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
Sent: Sunday, January 16, 2000 8:48 PM
To: w3c-dist-auth@w3.org
Subject: WebDAV Bindings - Issue Yaron.403



Section 5.2 of the Bind spec instructs the reader that if a server wishes to
reject a BIND request because it would cause a loop then the server should
return a 403 (Forbidden). However 403 is overloaded as it is. For example, a
403 could mean that the method is banned at the moment for some reason even
though it is normally supported. This means that someone trying to write an
API to issue a BIND never really knows what a 403 means and so doesn't know
if they should tell the user that the server is currently just not going to
let the user perform this action or if the problem is that the action would
result in a loop. Therefore the use of 403 introduces a vagueness into the
response.

        Therefore I move that a new 4xx error code be introduced to cover
the case when a server refuses a BIND because it would cause a loop.

                Yaron 

P.S. I think that the introduction of all these new error codes is a
mistake. A new error code should only be, in my opinion, introduced when it
provides a very high level error description that could be reasonably used
by members of the HTTP infrastructure, meaning firewalls and proxies.
Otherwise only the x00 errors should be used for everything and either new
headers or a body should be introduced to give detailed error information.
But I'm way too busy to try and push for this change so for the moment let's
just throw another error code on the barbie until people go insane with
them. It will be interesting to see how bad things have to become before we
can get this fixed.



From w3c-dist-auth-request@w3.org  Wed Jan 19 12:16:11 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02242
	for <webdav-archive@odin.ietf.org>; Wed, 19 Jan 2000 12:16:10 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA14754;
	Wed, 19 Jan 2000 12:05:14 -0500 (EST)
Resent-Date: Wed, 19 Jan 2000 12:05:14 -0500 (EST)
Resent-Message-Id: <200001191705.MAA14754@www19.w3.org>
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD2456F@crte147.wc.eso.mc.xerox.com>
From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'Yaron Goland'" <yarong@Exchange.Microsoft.com>, w3c-dist-auth@w3.org
Date: Wed, 19 Jan 2000 12:05:00 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.MrIntegrity
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3886
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

A binding is a relation between a segment S in a collection C and a resource
R, represented C:(S->R).  We are saying that when a server agrees to create
a binding, it MUST guarantee that the binding will continue to exist until
one of the following happens:
 
DELETE with a Request-URI whose final segment is S and the rest of the URI
identifies collection C
MOVE with a Request-URI whose final segment is S and the rest of the URI
identifies collection C
BIND with a Destination whose final segment is S and the rest of the URI
identifies collection C, and Overwrite is T
DELETE the last binding to collection C
 
It is not acceptable for a binding to be destroyed as a side effect of any
other operation.
 
That's it for currently defined methods, I think.  But I also think that we
do have to rely on a more conceptual definition, however inexact, to convey
the implications for other methods that might be defined in the future.
 
So here's a shot at the conceptual definition:
 
If a server allows binding C:(S->R) to be created, it MUST guarantee that
the resource R will continue to be accessible through the URI mappings
induced by that binding until it receives an explicit request to destroy the
binding.  Such a request would have to ask explicitly that some element of
the relation C:(S->R) be removed, or that the relationship itself be
removed.  It would have to explicitly request that the last binding to C be
removed, that the last binding to R be removed, or that the binding C:(S->R)
be removed from C.
 
--Judy
 
 -----Original Message-----
From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
Sent: Sunday, January 16, 2000 8:49 PM
To: w3c-dist-auth@w3.org
Subject: WebDAV Bindings - Issue Yaron.MrIntegrity



The last sentence of the last paragraph of section 4 reads "Implementations
MUST ensure the integrity of bindings." Similar language is used in the
second paragraph of section 5.1. However the term "integrity" was never well
defined inside of the specification. As such it is impossible to comply with
this requirement in an interoperable way. I would strongly caution against
attempting to specify the definition for integrity, English is much too
inexact a language for such an attempt to be successful.

        As such, I move that both sentences be removed and be replaced with
a series of statements that define, in exact language, the requirements that
are to be represented by the term "integrity", each sentence properly
qualified with a MUST.



From w3c-dist-auth-request@w3.org  Wed Jan 19 12:27:45 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02351
	for <webdav-archive@odin.ietf.org>; Wed, 19 Jan 2000 12:27:44 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA15673;
	Wed, 19 Jan 2000 12:16:58 -0500 (EST)
Resent-Date: Wed, 19 Jan 2000 12:16:58 -0500 (EST)
Resent-Message-Id: <200001191716.MAA15673@www19.w3.org>
From: ccjason@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: "Slein, Judith A" <JSlein@crt.xerox.com>
cc: w3c-dist-auth@w3.org
Message-ID: <8525686B.005EE2B1.00@D51MTA03.pok.ibm.com>
Date: Wed, 19 Jan 2000 12:15:37 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: RE: WebDAV Bindings - Issue Yaron.507
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3887
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


>>
I don't have a strong commitment to 507 either, but for what it's worth the
rationale was that any creation of a cross-server binding requires
out-of-band collaboration between the servers.  So it seems very likely
that
a lot of servers will fail requests to create a binding to a resource on
another server, so it seems useful to have an error code for this case.
>>
In addition, it is something that the clients understand and can take
action
on.  They almost certainly know when they are requesting a cross server
binding
and if they see a 507 then they probably will realize that bindings aren't
supported between the two servers specified in this request... and
therefore
the clients will stop trying.

OTOH, clients probably don't know where the
boundaries between file systems are within the URI namespace so they will
have
difficulty knowing which bindings are allowed and which aren't if a machine
refuses to create bindings across file systems.  In other words, they can't
take much action in the situation that Yaron mentioned so for the time
being,
there's probably not much point in using anything other than 500 in the
situation he mentioned





From w3c-dist-auth-request@w3.org  Wed Jan 19 12:54:47 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02760
	for <webdav-archive@odin.ietf.org>; Wed, 19 Jan 2000 12:54:45 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA17158;
	Wed, 19 Jan 2000 12:41:54 -0500 (EST)
Resent-Date: Wed, 19 Jan 2000 12:41:54 -0500 (EST)
Resent-Message-Id: <200001191741.MAA17158@www19.w3.org>
Message-ID: <B9B6874277EED211B1890008C707AF53010C3276@indyexch3.indy.tce.com>
From: Fisher Mark <fisherm@tce.com>
To: "'ccjason@us.ibm.com'" <ccjason@us.ibm.com>,
        Yaron Goland
	 <yarong@Exchange.Microsoft.com>
Cc: w3c-dist-auth@w3.org
Date: Wed, 19 Jan 2000 12:40:16 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.AtomicDelete
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3888
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

> This is a bookkeeping issue.  Remember, the DELETE is not an 
> allocation
> issue.  It's removing the resource out of one or more places in the
> namespace and that's the only verifiable semantic that we can 
> talk about.
> We've tried.  Whether the resource continues to exist after 
> it loses its
> last binding is up to the server.

That's the key point here.  On a direct-mapped webserver (no alias support
in the webserver) that uses a singly-linked filesystem like VMS or
Win32API-NTFS as a WebDAV backing store, it may make sense for the DELETE to
actually remove the underlying file.  If you are using a direct-mapped
webserver on a multiply-linked filesystem like Unix or POSIXsubsystem-NTFS,
then a DELETE might remove one link to the underlying file but leave any
other links lying around.  I could go on and on enumerating the various
possibilities, but to me the DELETE only removes the name from the namespace
-- it is entirely server-dependent as to what if anything happens to the
underlying data for that name.  From the client's viewpoint, that name and
its data doesn't exist anymore.
===============================================
Mark Leighton Fisher            fisherm@tce.com
Thomson Consumer Electronics    Indianapolis IN
"Browser Torture Specialist, First Class" 



From w3c-dist-auth-request@w3.org  Wed Jan 19 14:21:33 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03938
	for <webdav-archive@odin.ietf.org>; Wed, 19 Jan 2000 14:21:32 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA20456;
	Wed, 19 Jan 2000 14:10:10 -0500 (EST)
Resent-Date: Wed, 19 Jan 2000 14:10:10 -0500 (EST)
Resent-Message-Id: <200001191910.OAA20456@www19.w3.org>
From: ccjason@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: "Rickard Falk" <rickard.falk@excosoft.se>
cc: w3c-dist-auth@w3.org
Message-ID: <8525686B.0063603F.00@D51MTA03.pok.ibm.com>
Date: Wed, 19 Jan 2000 13:04:41 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: Should I use displayname?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3889
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


>>
When I'm trying to perform a directory browsing, that I'm going to present
to a user. Should I then present the Displayname info or should I pars the
href to get the name of the resource, from the Propfind request?
If I should use the Displayname info, can I rely on that it only contains
the name of the resource and not the complete path? ( this seems to be the
case for IIS, Xythos, Zope. But not for CyberTeams server )
>>
Noone has answered, so I will take a stab.

I don't think you can count on it containing anything and even that it
exists.  If it does exist, it does seem like the thing you'd want to
display.

Note: I don't think it's even technically required to correspond to
the URI at all.

Note: in the presence of multiple bindings, if the server initializes it
to the URI and treats it as a dead property, that URI might be different
from the URI from which it was accessed.  This unexpected behavior is even
possible (but less likely) if the value is only initialized to the last
segment of the URI.

That's only the technical answer.  If you were asking for a consensus
answer, you can add DAV4J to the list.  It currently treats it as a dead
property that gets initialized to the full URI.  It also allows the client
to change the displayname to anything they wish.




From w3c-dist-auth-request@w3.org  Wed Jan 19 16:08:22 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05322
	for <webdav-archive@odin.ietf.org>; Wed, 19 Jan 2000 16:08:22 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA23903;
	Wed, 19 Jan 2000 15:57:13 -0500 (EST)
Resent-Date: Wed, 19 Jan 2000 15:57:13 -0500 (EST)
Resent-Message-Id: <200001192057.PAA23903@www19.w3.org>
From: ccjason@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: Fisher Mark <fisherm@tce.com>
cc: w3c-dist-auth@w3.org
Message-ID: <8525686B.00730974.00@D51MTA03.pok.ibm.com>
Date: Wed, 19 Jan 2000 15:55:45 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: RE: WebDAV Bindings - Issue Yaron.AtomicDelete
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3890
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list



>>
That's the key point here.  On a direct-mapped webserver (no alias support
in the webserver) that uses a singly-linked filesystem like VMS or
Win32API-NTFS as a WebDAV backing store, it may make sense for the DELETE
to
actually remove the underlying file.
>>

Yes.  The files can be deallocated as long as the other requirements are
fulfilled.
And yes, it might be the right thing to do for a given server.  But WebDAV
is
currently agnostic on that topic.  A server it free to do that as long as
they
stick to the requirements that the proposal outlines.  So what are those
requirements that need to be fulfilled?

If the server supports multiple bindings, it definitely it must not remove
any links/resources that
are also accessable via another binding.   If they aren't accessable via
any other binding, then whether
they get removed or not is not something a client can currently detect so
the server has a bit more flexibility.
The only other constraint then is that the server not delete from bottom
up, run into a problem half way and
leave the job half done.  If you can meet this requirement, you can feel
free to deallocate all those files.

As for a server that doesn't support multiple bindings, we don't have a
strict requirement except the desire
for consistant and predictable behavior across all servers.  I doubt any of
us want to actually have
two classes of servers out there that have *very* different behaviors for
the same operation.  As I think I've
tried to point out, even the singly-linked repositories that we've
discussed to date can meet these
requirements.  It is my hope that we all can settle on this one DELETE
semantic for all servers.

As for us all settling on one semantic.  The webdav model is not an exact
match of any existing repository
that we know of right now.  Some lack depth locks.  Some don't have URI
protection.  Some only have
cooperative locks.  Some don't have multiple bindings.  Some don't support
loops in their bindings.  Some
don't have strong bindings to collections.  Some have features that can't
easily be exposed.  We all
will have our own difficulties implementing any useful spec over each of
our existing systems.  Sure we could
dumb down that protocol, but we'd be left with an FTP look-alike.   Sure we
could let the spec fragment, but that
would limit the value of our work.  We've chosen to come up with something
that's both functional and
interoperable.   That means that everyone will have to bend to deal with
impedance mismatches between the webdav model and the model that their
repositories use.  But if we are all
willing to do our share of bending, we as a community will really be
delivering something of value to the
internet community.

Jason.




From w3c-dist-auth-request@w3.org  Wed Jan 19 18:14:22 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06420
	for <webdav-archive@odin.ietf.org>; Wed, 19 Jan 2000 18:14:22 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA28442;
	Wed, 19 Jan 2000 18:03:06 -0500 (EST)
Resent-Date: Wed, 19 Jan 2000 18:03:06 -0500 (EST)
Resent-Message-Id: <200001192303.SAA28442@www19.w3.org>
Date: Wed, 19 Jan 2000 15:07:03 -0800 (PST)
From: Greg Stein <gstein@lyra.org>
To: Rickard Falk <rickard.falk@excosoft.se>
cc: w3c-dist-auth@w3.org
In-Reply-To: <8525686B.0063603F.00@D51MTA03.pok.ibm.com>
Message-ID: <Pine.LNX.4.10.10001191503470.13911-100000@nebula.lyra.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: Should I use displayname?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3891
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

On Wed, 19 Jan 2000 ccjason@us.ibm.com wrote:
>...
> I don't think you can count on it containing anything and even that it
> exists.  If it does exist, it does seem like the thing you'd want to
> display.
> 
> Note: I don't think it's even technically required to correspond to
> the URI at all.
> 
> Note: in the presence of multiple bindings, if the server initializes it
> to the URI and treats it as a dead property, that URI might be different
> from the URI from which it was accessed.  This unexpected behavior is even
> possible (but less likely) if the value is only initialized to the last
> segment of the URI.
> 
> That's only the technical answer.  If you were asking for a consensus
> answer, you can add DAV4J to the list.  It currently treats it as a dead
> property that gets initialized to the full URI.  It also allows the client
> to change the displayname to anything they wish.

As another point of reference:

mod_dav treats it as a dead property and does *not* initialize the value
to anything. In other words, it (typically) does not exist on a resource.
If it does, then it only contains whatever somebody happened to shove into
it -- that could be a JPEG image for all mod_dav cares.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From w3c-dist-auth-request@w3.org  Wed Jan 19 22:25:31 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08726
	for <webdav-archive@odin.ietf.org>; Wed, 19 Jan 2000 22:25:31 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id WAA03171;
	Wed, 19 Jan 2000 22:14:31 -0500 (EST)
Resent-Date: Wed, 19 Jan 2000 22:14:31 -0500 (EST)
Resent-Message-Id: <200001200314.WAA03171@www19.w3.org>
Date: Wed, 19 Jan 2000 19:18:57 -0800 (PST)
From: Greg Stein <gstein@lyra.org>
To: w3c-dist-auth@w3.org
In-Reply-To: <7DE119D3D0E15543874F7561EECBDBED02619E25@BEG.platinum.corp.microsoft.com>
Message-ID: <Pine.LNX.4.10.10001191917540.13911-100000@nebula.lyra.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: WebDAV Bindings - Issue Yaron.507
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3892
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

On Sun, 16 Jan 2000, Yaron Goland wrote:
> In section 5.5 the 507 error code is written as "507 (Cross-Server Binding
> Forbidden): The server is unable to create the requested binding because it
> would bind a segment in a collection on one server to a resource on a
> different server." 
> 	What does a server have to do with anything? If you try to bind two
> resources in different volumes on a FrontPage server the server will have to
> fail the BIND even though the resources are on the same server. In general
> bringing in the server is almost always a bad idea since resources can be
> spread out all over the place and the reasons for various failures may or
> may not have anything to do with how those resources are laid out on the
> servers. As such I move that the language for the 507 error code be altered
> to read that the resource was unable to create a binding to a destination
> and to leave the matter at that. All mentions of the word server should be
> stricken.

I agree with Yaron here. mod_dav allows the server to operate against
different backends. It will not be possible to create bindings between
namespaces that map to different backends. (much less MOVE or COPY between
them)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From w3c-dist-auth-request@w3.org  Thu Jan 20 14:07:25 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12311
	for <webdav-archive@odin.ietf.org>; Thu, 20 Jan 2000 14:07:24 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA26604;
	Thu, 20 Jan 2000 13:56:13 -0500 (EST)
Resent-Date: Thu, 20 Jan 2000 13:56:13 -0500 (EST)
Resent-Message-Id: <200001201856.NAA26604@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: WebDAV WG <w3c-dist-auth@w3.org>
Date: Thu, 20 Jan 2000 10:52:09 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJKEGJCMAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: WebDAV State of Adoption Report
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3893
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit


WebDAV

State of Adoption Report

January 20, 2000

It has been a little less than a year since the WebDAV Distributed Authoring
Protocol, RFC 2518, was issued by the IETF.  I'm very pleased to report that
in that time, there has been very strong adoption of the WebDAV protocol.
Due to the hard work of the members of this working group, and the people
who have written and deployed WebDAV applications, there are now thousands
of people every day who get useful work done using the WebDAV protocol.
Over the next few years, we'll see this number increase into the millions,
as WebDAV technology diffuses broadly into the platforms, programs, and
devices we use on a daily basis, and as people better learn when and how to
use WebDAV.  Furthermore, as efforts like Advanced Collections, DASL, and
Delta-V expand the capabilities of WebDAV, they open up new applications and
audiences, leading to yet more users of the protocol.  Though WebDAV
adoption has already been strong, in many respects we are just at the
beginning of a long, 20+ year long arc for this protocol.

The purpose of this report is to highlight where WebDAV adoption stands
today by listing clients and servers that support WebDAV.  Though WebDAV
devotees will already know much of this information as individual items,
most people are surprised when they see it all put together in one place --
there is more here than people expect.  This report lists 10 client
applications, 2 publically available client API libraries, 17 WebDAV servers
(12 class-2, 5 class-1), and 2 WebDAV-enabled Web storage sites.  These
applications run on a range of platforms, with client support for Windows,
Unix, and MacOS, and server support for Windows and Unix. WebDAV benefits
from strong commercial and open source development, showing that the
protocol has a broad spectrum of support beyond any one company or
institution.  Finally, the WebDAV-enabled storage sites are gaining users
rapidly, with one site, My Docs Online, currently adding 500 new WebDAV
users a week.


CLIENTS

  Office 2000 (Word, Excel, PowerPoint)
    http://www.microsoft.com/office/
    Provides remote collaborative authoring of documents,
    spreadsheets, and presentations via Web Folders.
    [Windows]

  Internet Explorer 5
    http://www.microsoft.com/windows/ie/ie5/default.asp
    Web Folders interface allows interaction with a remote Web
    site appear to behave as if it were a local file folder.
    Provides drag-and-drop upload and download to a Web site.
    [Windows] ** Free download **

  sitecopy
    http://www.lyra.org/sitecopy/
    Allows a remote Web site to be edited in a local directory,
    then synchronized and uploaded, providing a CVS-like model
    of interaction.
    [Linux, FreeBSD, OS/2, Win32, IRIX, Solaris, SunOS, Digital Unix,
probably others too]
    ** Free Download, Open Source **

  Goliath
    http://www.webdav.org/goliath/
    Provides a Mac Finder-like interface that allows interaction
    with a remote Web site to behave as if it were a local file
    folder.  Provides drag-and-drop upload and download to a
    Web site.
    [MacOS 8.5 or higher]  ** Free download, open source **

  cadaver
    http://www.webdav.org/cadaver/
    A command-line tool for interacting with a remote Web site.
    Analogous to the Unix "ftp" command.
    [Linux, SunOS]  ** Free download, open source **

  DAV Explorer
    http://www.ics.uci.edu/~webdav/
    Provides a Windows Explorer like interface for a remote WebDAV
    server. Supports resource locking.  Allows the protocol stream
    to be logged to a file.  Useful for debugging servers.
    [Java-based, tested on SunOS, Windows]
    ** Free download, open source **

  Documentor
    http://www.excosoft.se/camp/index.html
    Excosoft's Documentor product allows remote XML authoring via
    WebDAV.
    [Windows 95/98/NT, AIX, Solaris, HP-UX] ** Free eval download **

  WebDev for PHP
    http://www.dmcsoft.com/webdev/
    A client application that allows remote management of PHP-based
    Web sites via the WebDAV protocol.
    [Windows] ** Free eval download **


CLIENT API LIBRARIES

  DAV4J
    http://www.alphaworks.ibm.com/tech/DAV4J
    A Java-based client API for WebDAV, comes with IBM's DAV4J server.
    [Java-based, Windows]  ** Free download **

  DAVLib for MacOS
    http://www.webdav.org/goliath/davlib.html
    A C++ library for developing WebDAV client applications for MacOS.
    [MacOS] ** Free download, open source **


SERVERS

  Apache mod_dav
    http://www.webdav.org/mod_dav/
    A module for the Apache Web server providing full class-2 WebDAV
    support. Has a storage layer interface that can be mapped to
    multiple repository types.
    [Linux, Win32, other Unix variants]
    ** Free download, open source **

  Netware 5.1
    http://www.novell.com/catalog/bg/bge14101.html
    Novell's Netware 5.1 provides full class-2 WebDAV support.

  Net Publisher
    http://www.novell.com/catalog/bg/bge30003.html
    Novell's Net Publisher provides full class-2 WebDAV support
    integrated with Novel Directory Service (NDS).  Adds WebDAV
    support to IIS 4, Netscape ES 3.0 or higher.
    [Windows98/NT]

  DAV4J
    http://www.alphaworks.ibm.com/tech/DAV4J
    IBM's DAV4J server, available on the AlphaWorks site, provides
    a full Java-based class-2 WebDAV server.  Provides interfaces
    for easily integrating multiple repository types.
    [Windows]  ** Free download **

  Internet Information Services 5 (IIS 5)

http://www.microsoft.com/windows2000/library/howitworks/iis/iis5techoverview
.asp
    Microsoft's IIS 5 server provides a class-2 WebDAV server
    that is tightly integrated with the Windows 2000 filesystem and
    access control permissions.
    [Windows 2000]

  Exchange 2000
    http://www.microsoft.com/exchange/prodinfo/2000/InfoSheet.htm
    Microsoft's Exchange 2000, currently in Beta 3, provides WebDAV
    access to its Web Store repository.
    [Windows NT/2000]

  Xythos Storage Server
    http://www.xythos.com/
    A full class-2 WebDAV server using an Oracle database as its
    repository.  Provides quota support. Xythos is also the first
    server to provide compliant DASL support.
    ** Free use on www.sharemation.com site **

  WebSite Director
    http://www.cyberteams.com/webdav/
    CyberTeam's WebSite Director project is a class-2 WebDAV
    server integrated with workflow technology.
    [WindowsNT, BSDI, FreeBSD, HP-UX, Linux, SGI, Solaris, SunOS]
    ** Free account available **

  DataChannel Server 4.0
    http://www.datachannel.com/
    http://www.datachannel.com/products/Ds_DCS40_preview_final.pdf
    DataChannel Server 4.0 provides class-2 WebDAV access into their
    repository.

  Zope
    http://webdav.zope.org:2518/
    Zope is a development environment for creating Web sites,
    and provides a class-1 WebDAV server.
    [Most Unix, WindowsNT]
    ** Test accounts available **

  WebRFM
    http://webrfm.netpedia.net/
    WebRFM is a CGI-Perl program that implements a class-1 WebDAV
    server, along with some legacy HTTP methods supported by
    AOLserver, and Netscape Enterprise Server.
    [Unix variants]
    ** Free download, open source **

  Intraspect Knowledge Server
    http://www.intraspect.com/
    Knowledge Server provides a full class-2 WebDAV server interface.
    [WinNT 4]

  Glyphica PortalWare
    http://www.glyphica.com/Press/WebDAVRelease.html
    Glyphica's PortalWare product line contains class-2 WebDAV support.

  Python davserver / GROUP.lounge
    http://www.comlounge.net/webdav/intro.html
    http://www.grouplounge.net/
    Provides a class-1 WebDAV server written in Python, along with
    Python classes designed for reuse.  This server is used inside
    the GROUP.lounge document collaboration environment.
    ** Freely available, open source **

  PyDAV
    http://sandbox.xerox.com/webdav/
    The first Python WebDAV server, developed at Xerox PARC.
    Currently unavailable due to legal issues.

  DaveSmith
    http://www.cyclic.com/cgi-bin/cvsweb/kingdon/davesmith/davesmith.pl
    A testbed class-1 DAV server written in Perl, designed to be as easy
    as possible to understand and install, requiring no external modules,
    such as XML parsers, HTTP modules, etc.
    ** Freely available, source is public domain **

  FrontPage Server Extensions clone -- with WebDAV support
    http://www.nimh.org/fpse.html
    A WebDAV server written in Perl, with some support for the FrontPage
    server extensions.
    ** Freely available **


WEBDAV-ENABLED STORAGE SITES

  A surprise for WebDAV was the emergence of the Web storage site as a
  strong adoptor of WebDAV technology. These sites typically offer
  20 Meg of storage for free, and the ability to share files with other
  users of the site.  Access to files is via a Web interface, or via
  WebDAV.  The ease of access to remote Web sites provided by Web Folders
  is motivating adoption of WebDAV by many storage sites.  This, in turn,
  is introducing WebDAV to a large, new audience.

  Sharemation
    http://www.sharemation.com/
    The first WebDAV-enabled storage site, offering
    20 Meg of storage, non-DAV versioning, DASL support.
    Uses the Xythos Storage Server.

  My Docs Online!
    http://www.mydocsonline.com/
    Also offering 20 Meg of storage. Currently with over
    3,000 WebDAV users after just six weeks of offering WebDAV
    capability. Apparently there would be more WebDAV users,
    except there are recurring reports of difficulty accessing
    WebDAV capability through legacy, non-HTTP/1.1 compliant
    proxies.  MyDocsOnline uses a modified version of
    Apache mod_dav.


- Jim Whitehead <ejw@ics.uci.edu>
Chair, IETF WebDAV Working Group



From w3c-dist-auth-request@w3.org  Thu Jan 20 14:28:47 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12801
	for <webdav-archive@odin.ietf.org>; Thu, 20 Jan 2000 14:28:46 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA28419;
	Thu, 20 Jan 2000 14:17:52 -0500 (EST)
Resent-Date: Thu, 20 Jan 2000 14:17:52 -0500 (EST)
Resent-Message-Id: <200001201917.OAA28419@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: Rickard Falk <rickard.falk@excosoft.se>
Cc: w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at gremlin-relay.ics.uci.edu
Date: Thu, 20 Jan 2000 11:13:46 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJAEGLCMAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <Pine.LNX.4.10.10001191503470.13911-100000@nebula.lyra.org>
Subject: RE: Should I use displayname?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3894
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit


> > That's only the technical answer.  If you were asking for a consensus
> > answer, you can add DAV4J to the list.  It currently treats it as a dead
> > property that gets initialized to the full URI.  It also allows the
client
> > to change the displayname to anything they wish.
>
> As another point of reference:
>
> mod_dav treats it as a dead property and does *not* initialize the value
> to anything. In other words, it (typically) does not exist on a resource.
> If it does, then it only contains whatever somebody happened to shove into
> it -- that could be a JPEG image for all mod_dav cares.

Well, the intent of the displayname property was to provide a mechanism by
which a user could assign a more meaningful name to a resource other than
just the URL.  In particular I was thinking about non-latin character sets
(like Kanji), which are currently poorly handled by existing URLs.

However, this thread is certainly showing that there is an interoperability
problem here. There are two choices:

1) Have the server make it a dead property, initialized to be empty.
Clients would display the last path segment from the href URL
preferentially, but would display the displayname property if set.

2) Have the sever make it a dead property, initialized to the last path
segment of the href URL.  The client would always use the displayname value.

Since client behavior is currently closer to case (1), this might be the
best plan for moving forward.

- Jim



From w3c-dist-auth-request@w3.org  Thu Jan 20 18:46:57 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16952
	for <webdav-archive@odin.ietf.org>; Thu, 20 Jan 2000 18:46:57 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA11331;
	Thu, 20 Jan 2000 18:36:11 -0500 (EST)
Resent-Date: Thu, 20 Jan 2000 18:36:11 -0500 (EST)
Resent-Message-Id: <200001202336.SAA11331@www19.w3.org>
Date: Thu, 20 Jan 2000 15:31:11 -0800
Message-ID: <8809-Thu20Jan2000153111-0800-bill@carpenter.ORG>
X-Mailer: 20.4 "Emerald" XEmacs  Lucid (via feedmail 9-beta-9 I) wjc loop;
	VM 6.71 under 20.4 "Emerald" XEmacs  Lucid
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: bill@carpenter.ORG (WJCarpenter)
To: w3c-dist-auth@w3.org
Subject: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3895
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

Examples in RFC-2518, section 8.10.8 et seq, don't show a LOCK-TOKEN:
response header.  This contradicts other places in RFC-2518 which say
that the header is required in the response.

It would suit me if the requirement were changed and the examples left 
as is.
-- 
bill@carpenter.ORG   (WJCarpenter)           PGP
bill@bubblegum.net                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3



From w3c-dist-auth-request@w3.org  Thu Jan 20 18:50:11 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17002
	for <webdav-archive@odin.ietf.org>; Thu, 20 Jan 2000 18:50:10 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA11584;
	Thu, 20 Jan 2000 18:39:29 -0500 (EST)
Resent-Date: Thu, 20 Jan 2000 18:39:29 -0500 (EST)
Resent-Message-Id: <200001202339.SAA11584@www19.w3.org>
To: "Slein, Judith A" <JSlein@crt.xerox.com>
cc: w3c-dist-auth@w3.org
In-reply-to: Your message of "Tue, 18 Jan 2000 11:41:58 EST."
             <8E3CFBC709A8D21191A400805F15E0DBD2456A@crte147.wc.eso.mc.xerox.com> 
Date: Thu, 20 Jan 2000 15:39:04 -0800
From: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
Message-ID:  <200001201539.aa15398@gremlin-relay.ics.uci.edu>
Subject: Re: WebDAV Bindings - Issue Yaron.BindSyntax 
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3896
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

>It was actually initially written so that it asked for the creation of a
>binding at the Request-URI to the resource identified by the Destination
>header.  The rationale for this was that it seemed more intuitive to have
>the syntax of the request reflect the natural-language request: Create a
>binding from this segment to this resource.  (Anyhow, that's how the spec
>always expresses the request in English.)  And it seems as if the
>Request-URI should identify the resource for which authorization would be
>required to fulfill the request.  It's the collection where the binding
>lives that gets modified, and so update permission would be needed on that
>collection, and so that collection should be identified by the Request-URI.

Yep, that's what it should be.  Not only does the request-URI indicate
the point of modification, it also determines the mechanism within the
server responsible for handling that namespace -- something which absolutely
must be done *before* interpreting the method (except for TRACE).

>We changed this to be consistent with the usage in COPY and MOVE, thinking
>that it would be too confusing otherwise.  And servers would have to
>interpret the Overwrite header differently for BIND than for COPY / MOVE if
>we used the Request-URI and the Destination header differently than COPY /
>MOVE.

Oh, shoot me.  For some lame reason I missed that when WebDAV went up
for review, since the semantics in HTTP have always been that the
request-URI represents the target of the modification, for the same
reason that most assembler languages use the first operand as the
destination.

I'd prefer it be done the natural way rather than being consistent with
COPY and MOVE.

....Roy



From w3c-dist-auth-request@w3.org  Thu Jan 20 19:45:44 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17459
	for <webdav-archive@odin.ietf.org>; Thu, 20 Jan 2000 19:45:44 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id TAA15194;
	Thu, 20 Jan 2000 19:34:08 -0500 (EST)
Resent-Date: Thu, 20 Jan 2000 19:34:08 -0500 (EST)
Resent-Message-Id: <200001210034.TAA15194@www19.w3.org>
To: ccjason@us.ibm.com
cc: w3c-dist-auth@w3.org
In-reply-to: Your message of "Tue, 18 Jan 2000 14:05:19 EST."
             <8525686A.0068EAF0.00@D51MTA03.pok.ibm.com> 
Date: Thu, 20 Jan 2000 16:33:50 -0800
From: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
Message-ID:  <200001201633.aa19985@gremlin-relay.ics.uci.edu>
Subject: Re: WebDAV Bindings - Issue Yaron.Insulting2616, definition of resource
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3897
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

>You are trying to emphasize the definition of a resource as being in
>the eyes of the author.

Yes, and not just trying -- that is the definition of a resource.
The definition derives from the central requirement of the Web:
independent authoring of interconnected hypertext across
multiple trust domains.  Forcing the interface definitions to match
the interface requirements makes some things *seem* vague, but that
is only because the interface being manipulated is only an interface
and not an implementation.

>And that you want the server somehow be able to know and track the author's
>concept of "the resource"... and distinguish it from the current
>implementation of the resource.

That's not quite what I meant.  What I was saying is that IF the spec
is going to make a distinction between bindings and resources, THEN
the protocol must provide a mechanism for the author to communicate
that distinction to the server.  IF, instead, the interface simply
assumes that all bindings are separate resources (as does RFC 2616),
then there is no need for that communication mechanism.

Don't get me wrong: there are some advantages to having a protocol
mechanism for identifying true aliases of a resource outside of DAV
(e.g., elimination of replicas in caches), but in the past those
advantages haven't been worth the effort.

> And because bindings remove the tight one-to-one association
>of the conceptual resource from its implementation, you feel the advent of
>bindings is a good place to have the server start maintaining that
>separation and support both concepts fully.

No, that's where lossage occurs in this discussion.  A resource is not
the storage object.  A resource is not the mechanism that the server uses
to handle the storage object.  A resource is a conceptual mapping --
the server receives the identifier (which identifies the mapping) and
applies it to its current mapping implementation (usually a combination
of collection-specific deep tree traversal and/or hash tables)
to find the currently responsible handler implementation and the
handler implementation then selects the appropriate action+response
based on the request content.  None of this implementation is part of
the Web interface.

For example, consider what happens when a site grows in user base and
decides to replace its old IIS server with a brand spanking new Apache
server running on a Sun ULTRA.  The disks are replaced.  The operating
system is replaced.  The HTTP server is replaced.  Perhaps even the
method of generating responses for all of the content is replaced.
What doesn't change is the Web interface: if designed correctly, the
namespace on the new server can mirror that of the old, meaning that
from the client's perspective, which only knows about resources and
not about how they are implemented, nothing has changed aside from the
improved robustness of the site.  (;-)

So, while it is okay for the bindings spec to say that bindings are
somehow different from resources, it is absolutely critical that it
not equate resources to some part of the server implementation.  Call
those other things handlers if you like, but understand the difference
when interpreting what the existing HTTP requirements mean, because
those HTTP requirements are on resources and resource identifiers,
not on handlers.

....Roy

--
Meet me at ApacheCon 2000 <http://www.apachecon.com/>, March 8-10.



From w3c-dist-auth-request@w3.org  Thu Jan 20 19:49:41 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17506
	for <webdav-archive@odin.ietf.org>; Thu, 20 Jan 2000 19:49:41 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id TAA15394;
	Thu, 20 Jan 2000 19:38:55 -0500 (EST)
Resent-Date: Thu, 20 Jan 2000 19:38:55 -0500 (EST)
Resent-Message-Id: <200001210038.TAA15394@www19.w3.org>
To: "Slein, Judith A" <JSlein@crt.xerox.com>
cc: w3c-dist-auth@w3.org
In-reply-to: Your message of "Wed, 19 Jan 2000 12:05:00 EST."
             <8E3CFBC709A8D21191A400805F15E0DBD2456F@crte147.wc.eso.mc.xerox.com> 
Date: Thu, 20 Jan 2000 16:38:44 -0800
From: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
Message-ID:  <200001201638.aa20424@gremlin-relay.ics.uci.edu>
Subject: Re: WebDAV Bindings - Issue Yaron.MrIntegrity 
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3898
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

>A binding is a relation between a segment S in a collection C and a resource
>R, represented C:(S->R).  We are saying that when a server agrees to create
>a binding, it MUST guarantee that the binding will continue to exist until
>one of the following happens:
> 
>DELETE with a Request-URI whose final segment is S and the rest of the URI
>identifies collection C
>MOVE with a Request-URI whose final segment is S and the rest of the URI
>identifies collection C
>BIND with a Destination whose final segment is S and the rest of the URI
>identifies collection C, and Overwrite is T
>DELETE the last binding to collection C
> 
>It is not acceptable for a binding to be destroyed as a side effect of any
>other operation.

I don't understand why this is a requirement of bindings.  It certainly
isn't a requirement of normal resources.  Why should the requirements on
bound names be stronger than the names they bind to?

....Roy



From w3c-dist-auth-request@w3.org  Fri Jan 21 01:23:05 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23858
	for <webdav-archive@odin.ietf.org>; Fri, 21 Jan 2000 01:23:05 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id BAA25252;
	Fri, 21 Jan 2000 01:11:23 -0500 (EST)
Resent-Date: Fri, 21 Jan 2000 01:11:23 -0500 (EST)
Resent-Message-Id: <200001210611.BAA25252@www19.w3.org>
From: fielding@ebuilt.com
To: w3c-dist-auth@w3.org
X-Mailer: Lotus Notes Release 5.0.1b September 30, 1999
Message-ID: <OFD84EAC65.2680719E-ON8825686D.000A8B5A@ebuilt.net>
Date: Thu, 20 Jan 2000 22:09:08 -0800
X-MIMETrack: Serialize by Router on riddler/Ebuilt(Release 5.0.2a |November 23, 1999) at 01/20/2000 10:09:20 PM,
	Serialize complete at 01/20/2000 10:09:20 PM
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: draft-ietf-webdav-binding-protocol-02
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3899
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Here are my detailed comments on the binding protocol specification.
Some of these have already been mentioned by Yaron, but I don't have
time to separate them into separate messages.  Sorry.

General
=======

I am a bit surprised by the size of the specification. After all, the
manpage for the Unix ln command is only 4 pages.  I think that this shows
there were far too many extremely intelligent people working on the spec.

I am going to highlight portions of the spec which are not relevant to
the Web interface, and thus shouldn't be part of the protocol. In doing
so, I am not trying to slam the authors or even the fact that many of
these reflect important implementation issues -- they simply aren't
relevant to the Web, for reasons that I will attempt to explain.

Formatting
==========

I know that the draft guidelines say that the author should paginate
the document.  The guidelines are wrong.  Pagination is only applicable
to final RFCs, and only get in the way of draft reviews. In particular,
the RFC editor will properly paginate the document according to the rules
of nroff processing macros, so completely messing up all the figures
and examples by automated addition of header/footers in the *wrong*
places is just annoying.

Details
=======

> Abstract

The first and third paragraphs of the Abstract are irrelevant to this
memo -- such things belong in the introduction (if at all).  A simple
rewrite is:

 This specification extends the Hypertext Transfer Protocol (HTTP/1.1),
 as previously extended by the WebDAV Distributed Authoring Protocol,
 to enable clients to create new identifiers for existing resources.
 It defines the semantics for a new request method, BIND, that creates
 a new name binding within the namespace of a target DAV collection.


> Servers are required to insure the integrity of any bindings 
> that they allow to be created.

This is an implementation concern that has no relevance to the client.
Resources disappear for many reasons, and it isn't possible for a
binding to be more persistent than a resource.

> 1 Notational Conventions

This section should follow the Introduction, not precede it.

> 2 Introduction
> 
> This is one of a pair of specifications that extend the WebDAV 
> Distributed Authoring Protocol to enable clients to create new access 
> paths to existing resources.  This capability is useful for several 
> reasons:

The above paragraph can be deleted without losing any useful info.

> URIs of WebDAV-compliant resources are hierarchical and correspond to a 
> hierarchy of collections in resource space.  The WebDAV Distributed 
> Authoring Protocol makes it possible to organize these resources into 
> hierarchies, placing them into groupings, known as collections, which 
> are more easily browsed and manipulated than a single flat collection. 
> However, hierarchies require categorization decisions that locate 
> resources at a single location in the hierarchy, a drawback when a 
> resource has multiple valid categories. For example, in a hierarchy of 
> vehicle descriptions containing collections for cars and boats, a 
> description of a combination car/boat vehicle could belong in either 
> collection. Ideally, the description should be accessible from both. 
> Allowing clients to create new URIs that access the existing resource 
> lets them put that resource into multiple collections.
> 
> Hierarchies also make resource sharing more difficult, since resources 
> that have utility across many collections are still forced into a single 

> collection. For example, the mathematics department at one university 
> might create a collection of information on fractals that contains 
> bindings to some local resources, but also provides access to some 
> resources at other universities.  For many reasons, it may be 
> undesirable to make physical copies of the shared resources on the local 

> server: to conserve disk space, to respect copyright constraints, or to 
> make any changes in the shared resources visible automatically. Being 
> able to create new access paths to existing resources in other 
> collections or even on other servers is useful for this sort of case.

resources != storage objects.  What is the motivation for creating aliases
within one namespace to identifiers in some other namespace?  That is what
needs to be described in the above paragraph -- storage is irrelevant.

> The BIND method defined here provides a mechanism for allowing clients 
> to create alternative access paths to existing WebDAV resources. HTTP 
> and WebDAV methods are able to work because there are mappings between 
> URIs and resources.  A method is addressed to a URI, and the server 
> follows the mapping from that URI to a resource, applying the method to 
> that resource.  Multiple URIs may be mapped to the same resource, but 
> until now there has been no way for clients to create additional URIs 
> mapped to existing resources. 
> 
> BIND lets clients associate a new URI with an existing WebDAV resource, 
> and this URI can then be used to submit requests to the resource.  Since 

> URIs of WebDAV resources are hierarchical, and correspond to a hierarchy 

> of collections in resource space, the BIND method also has the effect of 

> adding the resource to a collection.  As new URIs are associated with 
> the resource, it appears in additional collections.

These are not WebDAV resources -- they are Web resources.  The aliased
resource doesn't even need to be in the http namespace.

> The companion specification, RFC xxxx, defines redirect reference 
> resources, a different mechanism for creating alternative access paths 
> to existing resources.  A redirect reference is a resource in one 
> collection whose purpose is to forward requests to another resource (its 

> target), usually in a different collection.  In this way, it provides 
> access to the target resource from another collection.  It redirects 
> most requests to the target resource using the HTTP 302 (Moved 
> Temporarily) status code, thereby providing a form of mediated access to 

> the target resource.

Forwarding requests is what proxies do.  This paragraph should simply say

  Another mechanism for creating alternative access paths to existing
  resources, using redirect references, will be defined in a separate
  specification.

and the three comparison paragraphs deleted.  Cross-specifying protocols
is evil.

> 3 Terminology
> 
> The terminology used here follows and extends that in the WebDAV 
> Distributed Authoring Protocol specification [WebDAV]. Definitions of 
> the terms resource, Uniform Resource Identifier (URI), and Uniform 
> Resource Locator (URL) are provided in [URI].
> 
> URI Mapping
>      A relation between an absolute URI and a resource.  For an 
>      absolute URI U and the resource it identifies R, the URI mapping 
>      can be thought of as (U => R).  Since a resource can represent 
>      items that are not network retrievable, as well as those that are, 
>      it is possible for a resource to have zero, one, or many URI 
>      mappings. Mapping a resource to an "http" scheme URL makes it 
>      possible to submit HTTP protocol requests to the resource using 
>      the URL.

Actually, it is more like ({U,t} -R-> {V1, V2, ...}), where t is the
current time, R is the resource, -R-> is a mapping function that has
been implemented according to the semantics of resource R), and the range
is a set of values representing that resource at time t.

I covered some of the problems with the way the binding spec tries to
redefine resources in other e-mail.  However, the real deciding issue
in my mind is that none of this is useful to the client in defining
the protocol.  It would be better to simply say:

   For the purpose of this protocol, each unique URI is considered to
   be identifying a unique resource, even when the URI corresponds to
   a binding created by BIND.  The only distinguishing characteristics
   between the two that may be discovered by the client are ...

> Path Segment
>      Informally, the characters found between slashes ("/") in a URI.
                                                              xxxxxxxxx
in the path component of a hierarchical URI.

>      Formally, as defined in section 3.3 of [URI].

> Binding

Ugh.  Sorry, but all this does is define a bunch of things which are of
no concern to the client.  The abstraction is broken.

A binding is a name within a collection namespace.  This includes "normal"
resources, redirect references, immediately subsidiary collection names,
etc.  We know this because we want a DELETE on a binding to have the 
effect
of deleting any of these names -- even if the server is required to 
respond
with an error under some conditions, since the semantics remain the same.
The only thing BIND does is define a new way to create a binding,
similar to PUT and POST.  Once the binding is created, there is no way
for the client to differentiate it from the original PUT resource.  Thus,
the protocol doesn't care either.


> Collection
>      A resource that contains, as part of its state, a set of bindings 
>      that identify member resources.

Hey, that's what I just wrote -- I should have used a larger read-ahead.
So, if a collection is a set of bindings, why is it so hard to define
bindings?  They are just names.

>      In [WebDAV], a collection is defined as containing a list of 
>      internal member URIs, where an internal member URI is the URI of 
>      the collection, plus a single path segment.  This definition 

sucks.  [Well, it would make for a shorter spec, but okay I guess you
can't just replace it like that.  Yaron's suggestion to move this
stuff to an appendix is a good one.]

> 4 Overview of Bindings
> 
> Bindings are part of the state of a collection. In general, there is a 
> one-to-many correspondence between a collection's bindings and its 
> internal member URIs, as illustrated in Figure 2 above.  The URI segment 

> associated with a resource by one of a collection's bindings is also the 

> final segment of one or more of the collection's internal member URIs. 
> The final segment of each internal member URI identifies one of the 
> bindings that is part of the collection's state.

Egads.  Bindings are the names within a collection.

> Bindings are not unique to advanced collections, although the BIND 
> method for explicitly creating bindings is introduced here.  Existing 
> methods that create resources, such as PUT, MOVE, COPY, and MKCOL, 
> implicitly create bindings.  There is no difference between implicitly 
> created bindings and bindings created with BIND.

Yes!
 
> The identity of a binding C:(S -> R) is determined by the URI segment 
> (in its collection) and the resource that the binding associates.  If 
> the resource goes out of existence (as a result of some out-of-band 
> operation), the binding also goes out of existence.  If the URI segment 
> comes to be associated with a different resource, the original binding 
> ceases to exist and another binding is created.

No!  It is fundamentally impossible to implement the above.  In order
to be a protocol requirement, we must specify it in terms of the 
interface.
In other words, what must be done on a PUT/POST/DELETE upon a binding,
where "binding" includes any resource in the namespace.  Once you do
that, you will discover that no one will want to implement this.

> It would be very undesirable if one binding could be destroyed as a side 

> effect of operating on the resource through a different binding.  It is 
> not acceptable for moving a resource through one binding to disrupt 
> another binding, turning that binding into a dangling path segment.  Nor 

> is it acceptable for a server, after removing one binding, to reclaim 
> the system resources associated with its resource while other bindings 
> to the resource remain.  Implementations MUST ensure the integrity of 
> bindings.

I don't need any of these requirements.  If I don't need them, then they
must be specifying something more than a binding, because I've already
implemented every semantic in this spec aside from the BIND method itself.
I am damn sure that I am not going to post-hoc implement alias integrity
within Apache just because this protocol says that a DELETE must result
in removal of all bindings to the binding being deleted.  Late binding,
where the existence or nonexistence of a resource is determined at the
time requested, is far easier to implement and corresponds to what
a user expects to happen -- no magic.

I'm just going to skip the rest of the spec that mentions integrity.

> 5 BIND Method
> 
> 5.1 Overview of BIND
> 
> The BIND method creates a new binding between the resource identified by 

> the Request-URI and the final segment of the Destination header (minus 
> any trailing slash).  This binding is added to the collection identified 

> by the Destination header minus its trailing slash (if present) and 
> final segment.  The Destination header is defined in Section 9.3 of 
> [WebDAV].

As discussed in other mail, this is backwards because the Request-URI
needs to identify the collection that will be changed so that the right
authentication is picked up prior to other processing.  It can be
implemented in the reverse, but doing so is much less efficient for
a general-purpose HTTP server.

>...
> After successful processing of a BIND request, it MUST be possible for 
> clients to use the URI in the Destination header to submit requests to 
> the resource identified by the Request-URI.

That says nothing.  Not even what was intended.  A client can submit
anything it wants at any time.

> By default, if the Destination header identifies an existing binding, 
> the new binding replaces the existing binding. This default binding 
> replacement behavior can be overridden using the Overwrite header 
> defined in Section 9.6 of [WebDAV]. 

Yuck.  I don't like this either -- force the client to do a DELETE.

> 5.2 Bindings to Collections
> 
> Bindings to collections can result in loops.  If a server wants to 
> prevent a loop from being created, it MAY fail the BIND request with a 
> 403 (Forbidden) status code.  If a server allows a loop to be created, 
> it MUST detect the loop when processing "Depth: infinity" requests that 
> encounter the loop.  It is sometimes possible to complete an operation 
> in spite of the presence of a loop.  However, the 506 (Loop Detected) 
> status code is defined in Section 12.1 for use in contexts where an 
> operation is terminated because a loop was encountered. 

I'd prefer a new 4xx code instead of 403.  If we are going to all the
trouble of officially extending HTTP, we might as well take advantage
of the benefits.

> Creating a new binding to a collection makes each resource associated 
> with a binding in that collection accessible via a new URI, and thus 
> creates new URI mappings to those resources but no new bindings.

except for the binding created.  I think we'd all live longer if this
and the following paragraphs trying to explain it were just left to the
reader to figure out for themselves -- the description is far more
difficult to understand than just saying "you can create multiple
bindings to a collection resource".  Besides, the Note below does a
far more effective job of saying the same thing.

> 5.3 URI Mappings Created by a BIND
> 
> Suppose a BIND request causes a binding from "Binding-Name" to resource 
> R to be added to a collection, C.  Then if C-MAP is the set of URI's 
> that were mapped to C before the BIND request, then for each URI "C-URI" 

> in C-MAP, the URI "C-URI/Binding-Name" is mapped to resource R following 

> the BIND request.

Wow, that's an even more obscure way of saying that a BIND adds a name
to a collection such that the new name indirectly identifies R.

> Note that if R is a collection, additional URI mappings are created to 
> the descendents of R.  Also note that if a binding is made in collection 

> C to C itself (or to a parent of C), an infinite number of mappings is 
> introduced.

>...

> 5.5 BIND Status Codes
> 
> 201 (Created): The binding was successfully created.
> 
> 400 (Bad Request): The client set an invalid value for the Destination 
> header or Request-URI.
> 
> 403 (Forbidden): This server has a policy that forbids creation of 
> bindings that would result in loops.

403 means that the request is forbidden for reasons that the server
does not want to explain to the client.  You can't redefine 403 to be
this specific because its purpose is not to be specific.

> 412 (Precondition Failed): The Overwrite header is "F", and a binding 
> already exists for the Destination header.
> 
> 507 (Cross-Server Binding Forbidden): The server is unable to create the 

> requested binding because it would bind a segment in a collection on one 

> server to a resource on a different server.

I don't see why that is any different than the code formerly known as 403.

> 6 DELETE and Bindings
> 
> The DELETE method was originally defined in [HTTP]. This section 
> redefines the behavior of DELETE in terms of bindings, an abstraction 
> not available when writing [HTTP]. [HTTP] states that "the DELETE method 

> requests that the origin server delete the resource identified by the 
> Request-URI."  Because [HTTP] did not distinguish between bindings and 
> resources, the intent of its definition of DELETE is unclear.  The 
> definition presented here is a clarification of the definition in 
> [HTTP].

Much easier to just say that DELETE in HTTP/1.1 now refers to deletion
of any binding, including those created by bind, and then add
 
> The DELETE method requests that the server remove the binding between 
> the resource identified by the Request-URI and the binding name, the 
> last path segment of the Request-URI. The binding MUST be removed from 
> its parent collection, identified by the Request-URI minus its trailing 
> slash (if present) and final segment. 
> 
> Once a resource is unreachable by any URI mapping, the server MAY 
> reclaim system resources associated with that resource. If DELETE 
> removes a binding to a resource, but there remain URI mappings to that 
> resource, the server MUST NOT reclaim system resources associated with 
> the resource.

> Although [WebDAV] allows a DELETE to be a non-atomic operation, the 
> DELETE operation defined here is atomic.  In particular, a DELETE on a 
> hierarchy of resources is simply the removal of a binding to the 
> collection identified by the Request-URI, and so is a single (and 
> therefore atomic) operation. 

Single operations do not imply atomicity.  Atomic implies that nothing
else can happen during the processing of the request, which is false
for any but the most trivial operations.  DELETE is never trivial.

> Section 8.6.1 of [WebDAV] states that during DELETE processing, a server 

> "MUST remove any URI for the resource identified by the Request-URI from 

> collections which contain it as a member."  Servers that support 
> bindings MUST NOT follow this requirement.

Huh?  For the sake of this discussion, just ignore WebDAV.  Define what
the new requirement is and note in the appendix how (and why) it differs
from RFC 2518.  On other words, the above requirement creates an infinite
loop binding between two protocol specs, rather than updating one.

> 9 Bindings and Other Methods

I agree with Yaron that static versus dynamic in this section is 
irrelevant.

> 10 Determining Whether Two Bindings Are to the Same Resource
> 
> It is useful to have some way of determining whether two bindings are to 

> the same resource.  Two different resources might have identical 
> contents and identical values for the properties defined in [WebDAV]. 
> Although the DAV:bindings property defined in Section 13.1 provides this 

> information, it is an optional property.
> 
> The REQUIRED DAV:resourceid property defined in Section 13.2 is a 
> resource identifier, which MUST be unique across all resources for all 
> time.  If the values of DAV:resourceid returned by PROPFIND requests 
> through two bindings are identical, the client can be assured that the 
> two bindings are to the same resource.

Whoa, where did this requirement come from?  The URI is a resource ID.
If somebody wants to create a general metadata field for some sort of
sacred-name, then go wild, but this is not needed for bindings.

A question like this should be answered by a method applied to the
collection, not to the individual bindings.

> 10.1 resourceid URI Scheme
> 
> The value of DAV:resourceid is a URI and may use any URI scheme that 
> guarantees the uniqueness of the value across all resources for all 
> time.  The resourceid URI scheme defined here is an example of an 
> acceptable URI scheme.
> 
> The resourceid URI scheme requires the use of the Universal Unique 
> Identifier (UUID) mechanism, as described in [ISO-11578].  UUID 
> generators may choose between two methods of creating the identifiers. 
> They can either generate a new UUID for every identifier they create or 
> they can create a single UUID and then add extension characters.  If the 

> second method is selected, then the program generating the extensions 
> MUST guarantee that the same extension will never be used twice with the 

> associated UUID.
> 
> resourceid-URI = "resourceid:" UUID [Extension] ; The UUID production is 

> the string representation of a UUID, as defined in [ISO-11578].  Note 
> that white space (LWS) is not allowed between elements of this 
> production.
> 
> Extension = path ; path is defined in Section 3.3 of [URI].

No.  No.  No.

There shall be no repeat of the stupid "opaquelocktoken" URI scheme
just because this is another DAV-related spec.  A URI scheme defines
a namespace, not a purpose for a namespace.  If you want to use UUIDs,
the implementer can CHOOSE to use the "uuid" scheme.  Or they can
choose to use the "mid" scheme, the "urn" scheme, or any other scheme
that fits the need at hand.  Defining a new URI scheme for each new way
that a URI can be used is CONTRARY TO THE DESIGN GOALS OF URI.

>...

> 16.3 Bindings, and Denial of Service
> 
> Denial of service attacks were already possible by posting URLs that 
> were intended for limited use at heavily used Web sites.  The 
> introduction of BIND creates a new avenue for similar denial of service 
> attacks.  If cross-server bindings are supported, clients can now create 

> bindings at heavily used sites to target locations that were not 
> designed for heavy usage.

That isn't denial of service.  There is no need for this subsection.
 
I think that's it.  I'm sorry that I didn't get a chance to review
this earlier, but I've been pretty busy the past two years.

...........................................................
Roy T. Fielding                         fielding@ebuilt.com
eBuilt, Inc.                            tel:+1.949.609.0000
2652 McGaw Ave.                         fax:+1.949.609.0001
Irvine, CA 92614-5840   USA           http://www.eBuilt.com
...........................................................



From w3c-dist-auth-request@w3.org  Fri Jan 21 10:47:09 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12101
	for <webdav-archive@odin.ietf.org>; Fri, 21 Jan 2000 10:47:08 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id KAA07712;
	Fri, 21 Jan 2000 10:36:13 -0500 (EST)
Resent-Date: Fri, 21 Jan 2000 10:36:13 -0500 (EST)
Resent-Message-Id: <200001211536.KAA07712@www19.w3.org>
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24575@crte147.wc.eso.mc.xerox.com>
From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'Roy T. Fielding'" <fielding@kiwi.ICS.UCI.EDU>,
        "Slein, Judith A"
	 <JSlein@crt.xerox.com>
Cc: w3c-dist-auth@w3.org
Date: Fri, 21 Jan 2000 10:35:31 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.MrIntegrity 
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3900
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@kiwi.ICS.UCI.EDU]
> Sent: Thursday, January 20, 2000 7:39 PM
> To: Slein, Judith A
> Cc: w3c-dist-auth@w3.org
> Subject: Re: WebDAV Bindings - Issue Yaron.MrIntegrity 
> 
> 
> >A binding is a relation between a segment S in a collection 
> C and a resource
> >R, represented C:(S->R).  We are saying that when a server 
> agrees to create
> >a binding, it MUST guarantee that the binding will continue 
> to exist until
> >one of the following happens:
> > 
> >DELETE with a Request-URI whose final segment is S and the 
> rest of the URI
> >identifies collection C
> >MOVE with a Request-URI whose final segment is S and the 
> rest of the URI
> >identifies collection C
> >BIND with a Destination whose final segment is S and the 
> rest of the URI
> >identifies collection C, and Overwrite is T
> >DELETE the last binding to collection C
> > 
> >It is not acceptable for a binding to be destroyed as a side 
> effect of any
> >other operation.
> 
> I don't understand why this is a requirement of bindings.  It 
> certainly
> isn't a requirement of normal resources.  Why should the 
> requirements on
> bound names be stronger than the names they bind to?
> 
> ....Roy
> 

There are applications that depend upon the integrity of bindings.  In
particular, the versioning protocol being developed by the Delta-V working
group depends upon it.  In versioning, there are many orthogonal ways of
grouping information: by activity, by version tree, by configuration, etc.
Clients depend upon the integrity of this information.

As others have suggested recently, we may want to define weak bindings
eventually, but we've started in this specification with strong bindings.

--Judy



From w3c-dist-auth-request@w3.org  Fri Jan 21 10:59:42 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12331
	for <webdav-archive@odin.ietf.org>; Fri, 21 Jan 2000 10:59:42 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id KAA08327;
	Fri, 21 Jan 2000 10:48:38 -0500 (EST)
Resent-Date: Fri, 21 Jan 2000 10:48:38 -0500 (EST)
Resent-Message-Id: <200001211548.KAA08327@www19.w3.org>
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24576@crte147.wc.eso.mc.xerox.com>
From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'Yaron Goland'" <yarong@Exchange.Microsoft.com>, w3c-dist-auth@w3.org
Date: Fri, 21 Jan 2000 10:48:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.PublishBind
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3901
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

I think it's important for the binding spec and the redirect reference spec
to cross-reference each other, because they really are in the same space,
and implementers need to understand how bindings differ from redirect
references, when it's appropriate to use each of these in order to decide
which spec to implement or whether they need both.
 
There is precedent for a family of specs referencing each other in the MIME
specs 2045 - 2049.
 
If it does look as if one of these specs is running into trouble and might
jeopardize the approval of the other, I would certainly want to remove the
cross-references and comparisons rather than jeopardize both specs.
 

- -Judy

 

 -----Original Message-----
From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
Sent: Sunday, January 16, 2000 8:50 PM
To: w3c-dist-auth@w3.org
Subject: WebDAV Bindings - Issue Yaron.PublishBind



The spec refers to the redirect resource draft, even attempting to refer to
its RFC number. This means that the bind spec can not be published as an RFC
until the redirect resource draft is approved. While it is nice to point out
that the redirect resource draft exists I can find no compelling reason to
mention it when doing so restricts the schedule for the Bind draft's
standardization. Therefore I move that all references to the redirect
resource draft be stricken from the Bind spec, specifically the removal of
the last paragraph of the abstract, the 2nd, 4th and 5th to last paragraphs
of the Introduction and the reference [RR].



From w3c-dist-auth-request@w3.org  Fri Jan 21 12:09:45 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13910
	for <webdav-archive@odin.ietf.org>; Fri, 21 Jan 2000 12:09:45 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA11994;
	Fri, 21 Jan 2000 11:56:50 -0500 (EST)
Resent-Date: Fri, 21 Jan 2000 11:56:50 -0500 (EST)
Resent-Message-Id: <200001211656.LAA11994@www19.w3.org>
Date: Fri, 21 Jan 2000 11:56:36 -0500
Message-Id: <10001211656.AA26520@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <OFD84EAC65.2680719E-ON8825686D.000A8B5A@ebuilt.net>
	(fielding@ebuilt.com)
Subject: Re: draft-ietf-webdav-binding-protocol-02
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3902
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


First, many thanks to Roy for taking time to review the spec.  I
agreed with many/most of his comments, so to keep this response short,
I'll delete the parts of Roy's review that I agree with or have no
comment on.  The result is that it will appear that I disagree with
everything Roy says, but that emphatically is not the case!

   From: fielding@ebuilt.com

   I am a bit surprised by the size of the specification. After all, the
   manpage for the Unix ln command is only 4 pages.

There was a wide range in views on "how much to say" among the authors.
At the end, we decided to err on the side of too much, and ask the working
group to let us know what could be cut.  You can assume that any comment
of the form "get rid of this" echoes the sentiments of at least one of
the authors.  So to all reviewers, please take Roy's lead and let us know
what to cut!

   > Servers are required to insure the integrity of any bindings 
   > that they allow to be created.

   This is an implementation concern that has no relevance to the client.
   Resources disappear for many reasons, and it isn't possible for a
   binding to be more persistent than a resource.

True, but this statement is intended to constrain a server implementation
to retain a resource while there is a binding to it.  In other words,
an implementation is faulty if it allows a method to have a resource
disappear while there is still a binding to it.  This is in contrast
to references (e.g. redirect references) that have no such guarantee.

   resources != storage objects.  What is the motivation for creating aliases
   within one namespace to identifiers in some other namespace?  That is what
   needs to be described in the above paragraph -- storage is irrelevant.

Although I agree that storage is not the primary value to a client of
creating multiple bindings, it is one of the reasons why a BIND can be
more desireable to a client than a COPY; namely, because they are
aware that a BIND allows for certain storage optimizations that would
not be feasible for a COPY.

   However, the real deciding issue
   in my mind is that none of this is useful to the client in defining
   the protocol.  It would be better to simply say:

      For the purpose of this protocol, each unique URI is considered to
      be identifying a unique resource, even when the URI corresponds to
      a binding created by BIND.  The only distinguishing characteristics
      between the two that may be discovered by the client are ...

This is a model we considered (and JimW even did some impressive ASCII
art to illustrate it), but we found that saying that "every URI
identifies a unique resource" makes the term "resource" irrelevant.
The point of the binding spec was to allow two different URI's to
identify the same "something".  If we say that every URI identifies a
unique resource, then we need another term, say "object", and now all
of our semantics are in terms of URI's and objects, i.e. "A bind
causes two URI's to be mapped to the same object".  So instead, we
took the approach of Yaron's WebDAV model, and say that there are two
spaces, URI-space and resource-space.  URI's are strings whose syntax
is well-defined.  A resource can respond to an HTTP method, and can
be identified by a URI.  Without the binding protocol, there is no way
for a client to cause two URI's to identify the same resource, so for
all practical purposes, each URI identified a unique resource.  With
the binding protocol, a client now has a way to cause two different
URI's to identify the same resource.  In addition, there is a defined
property, DAV:resourceid, that allows a client to determine whether or
not two URI's are bound to the same resource.

We found that this was much more comprehensible to readers, than to
maintain that every URI identified a unique resource, but that a URI/resource
can be "mapped" to an "object", and two URI/resources can be mapped to the
same object.

On the other hand, perhaps we missed something valuable that was gained
by saying "every URI identifies a unique resource".  Could you explain
what this is?

   > Path Segment
   >      Informally, the characters found between slashes ("/") in a URI.
								 xxxxxxxxx
   in the path component of a hierarchical URI.

   >      Formally, as defined in section 3.3 of [URI].

   > Binding

   Ugh.  Sorry, but all this does is define a bunch of things which are of
   no concern to the client.  The abstraction is broken.

A client uses collections and bindings to define and control the
mapping of URI's to resources.  In particular, it can only do so (by
the binding protocol) at the "segment" granularity, i.e. when you bind
the resource R1 into collection C1 with the name "x", and the URL
/stuff/coll identifies C1, then you have made /stuff/coll/x identify
R1.  In particular, the discussions of segments and URL syntax is
important to prevent the incorrect conclusion in this example you have caused
/suff/collx to identify R1.

   A binding is a name within a collection namespace.

It is important for a binding to be a name with legal segment syntax,
so that it produces a legal URL when it is concatenated to the URL
that identifies the collection (separated by a "/").

It is also important that a binding be both a name and the resource
that the name identifies, so that when a method replaces a binding
with another binding that has the same name but identifies a different
resource, this is considered a change to the state of the
collection (as reflected in a different entity tag, lock checking,
etc.)

   The only thing BIND does is
   define a new way to create a binding, similar to PUT and POST.  Once
   the binding is created, there is no way for the client to
   differentiate it from the original PUT resource.  Thus, the protocol
   doesn't care either.

There is an important difference in that a BIND creates another name
for a resource, meaning that changes to the state of the resource through
the first name will be visible at the new name.  Unless you know the
resource type of a resource, that doesn't mean much, but when you do
know the resource type (e.g. that it is a collection resource), then
saying changes through one URL are visible at another URL are of great
significance to a client.

For example, if you have two URL's that identify the same collection, and you
add or delete a binding to that collection from one URL, you will see
that addition or deletion at the other URL.

   > The identity of a binding C:(S -> R) is determined by the URI segment 
   > (in its collection) and the resource that the binding associates.  If 
   > the resource goes out of existence (as a result of some out-of-band 
   > operation), the binding also goes out of existence.  If the URI segment 
   > comes to be associated with a different resource, the original binding 
   > ceases to exist and another binding is created.

   No!  It is fundamentally impossible to implement the above.

I don't understand in what sense it is fundamentally impossible to
implement the above.  What part of this appears problematic?

   In order
   to be a protocol requirement, we must specify it in terms of the 
   interface.

Perhaps something like: A binding cannot return a 404" and
"any out of band operation that changes the resource associated
with a binding in a collection results in a state change of the
collection (as reflected in an entity tag)" ?

   In other words, what must be done on a PUT/POST/DELETE upon a binding,
   where "binding" includes any resource in the namespace.  Once you do
   that, you will discover that no one will want to implement this.

It sounds like you read this as meaning something very different than
was intended.  Could you describe a bit what you thought this was saying,
so we can make sure that we fix it?

   > It would be very undesirable if one binding could be destroyed as a side 

   > effect of operating on the resource through a different binding.  It is 
   > not acceptable for moving a resource through one binding to disrupt 
   > another binding, turning that binding into a dangling path segment.  Nor 

   > is it acceptable for a server, after removing one binding, to reclaim 
   > the system resources associated with its resource while other bindings 
   > to the resource remain.  Implementations MUST ensure the integrity of 
   > bindings.

   I don't need any of these requirements.  If I don't need them, then they
   must be specifying something more than a binding, because I've already
   implemented every semantic in this spec aside from the BIND method itself.

This is the strong integrity requirement.  If you don't need these
requirements, then you don't need bindings (you probably want "references").

   I am damn sure that I am not going to post-hoc implement alias integrity
   within Apache just because this protocol says that a DELETE must result
   in removal of all bindings to the binding being deleted.

Actually, we specifically contradict 2518, and say that a DELETE must
not result in the removal of all bindings to the resource being
deleted (note that we have bindings to resources, not bindings to
bindings).  Some servers will chose not to implement bindings, but
there is (we believe) a large community of clients and servers that
want/need the integrity constraints provided by the binding protocol.
For servers that chose not to implement BIND, then there is no
problem because there will not be multiple bindings to the same
resource (as defined in this protocol).

   Late binding,
   where the existence or nonexistence of a resource is determined at the
   time requested, is far easier to implement and corresponds to what
   a user expects to happen -- no magic.

Yes, and a simple limited form of that is provided by the redirect
reference protocol.  A more extensive form of that would be provided
by a "direct referenece" (i.e. a reference followed by the server),
but that is not what the BIND protocol is about.  Yaron and others have
indicated interest in developing a direct reference protocol, but that
is very different from a binding (i.e. integrity preserving) protocol.

There is a terminology question, i.e. should these non-integrity-preserving
things be called "weak bindings" or "direct references" (I'm a staunch
advocate of the latter), but this protocol is definitely not about
them, whatever we end up calling them.

   > 5.1 Overview of BIND
   > 
   > The BIND method creates a new binding between the resource identified by 

   > the Request-URI and the final segment of the Destination header (minus 
   > any trailing slash).  This binding is added to the collection identified 

   > by the Destination header minus its trailing slash (if present) and 
   > final segment.  The Destination header is defined in Section 9.3 of 
   > [WebDAV].

   As discussed in other mail, this is backwards because the Request-URI
   needs to identify the collection that will be changed so that the right
   authentication is picked up prior to other processing.  It can be
   implemented in the reverse, but doing so is much less efficient for
   a general-purpose HTTP server.

A BIND request affects two resources: the source resource (it gets a
new binding to it) and the target collection (it gets a new binding in
it).  Whether this is implemented as an operation on the source
resource, the target collection, or both, is completely up to the
implementation.  You may need authentication on either or both
resources, and whether it is more efficient depends on the
implementation, so I believe that consistency with similar protocol
methods (COPY, MOVE) should take precedence over optimizing towards a
particular implementation.

If this really is an efficiency killer for an implementation, then I'm
certainly open to change, but I'd like to see that argument in more
detail.  This topic is much less important to me than the underlying
semantics, but seeing how many people get confused over the direction
of "ln" over the years (i.e. using it like "cp"), I'd hate to submit
WebDAV clients to the same confusion without good reason.

In particular, I'd like to see why any such argument doesn't apply
equally well to MOVE, which in practice does not seem to suffer from
having the target in the Destination header.

   >...
   > After successful processing of a BIND request, it MUST be possible for 
   > clients to use the URI in the Destination header to submit requests to 
   > the resource identified by the Request-URI.

   That says nothing.  Not even what was intended.  A client can submit
   anything it wants at any time.

The key here is "to the resource identified by the Request-URI".  A client
can submit anything it wants the Destination URI, but if it's a COPY,
it won't go to the resource identified by the Request-URI, but rather
to some new resource.

   > By default, if the Destination header identifies an existing binding, 
   > the new binding replaces the existing binding. This default binding 
   > replacement behavior can be overridden using the Overwrite header 
   > defined in Section 9.6 of [WebDAV]. 

   Yuck.  I don't like this either -- force the client to do a DELETE.

If a client didn't want the old binding to be deleted unless the new
binding could be created, it's convenient to be able to specify both
operations in a single request.

   > Creating a new binding to a collection makes each resource associated 
   > with a binding in that collection accessible via a new URI, and thus 
   > creates new URI mappings to those resources but no new bindings.

   except for the binding created.  I think we'd all live longer if this
   and the following paragraphs trying to explain it were just left to the
   reader to figure out for themselves -- the description is far more
   difficult to understand than just saying "you can create multiple
   bindings to a collection resource".  Besides, the Note below does a
   far more effective job of saying the same thing.

I'm happy to improve the wording, but this distinction was the key
one that distinguished this approach from another that Yaron proposed
(i.e. the forest of mappings approach).  In this approach, when you
add a new binding, you can cause more than one (in fact, with cyclic
bindings, an infinite number) of new URL-resource mappings to be
created.  Knowing exactly what URL mappings will be introduced by a
BIND request is essential for a client to understand how to use multiple
bindings to collections.

   > 5.3 URI Mappings Created by a BIND
   > 
   > Suppose a BIND request causes a binding from "Binding-Name" to resource 
   > R to be added to a collection, C.  Then if C-MAP is the set of URI's 
   > that were mapped to C before the BIND request, then for each URI "C-URI" 

   > in C-MAP, the URI "C-URI/Binding-Name" is mapped to resource R following 

   > the BIND request.

   Wow, that's an even more obscure way of saying that a BIND adds a name
   to a collection such that the new name indirectly identifies R.

This is emphasizing the above point, namely that adding a binding to a
collection creates a set of mappings, one for each URI mapping to that
collection.  We have found that most readers did not infer that from
statements like "a BIND adds a name to a collection".  So we need better
wording (if both Roy and Yaron find it confusing, I think we can safely
predict that others will as well :-).

   > 10 Determining Whether Two Bindings Are to the Same Resource
   > 
   > It is useful to have some way of determining whether two bindings are to 

   > the same resource.  Two different resources might have identical 
   > contents and identical values for the properties defined in [WebDAV]. 
   > Although the DAV:bindings property defined in Section 13.1 provides this 

   > information, it is an optional property.
   > 
   > The REQUIRED DAV:resourceid property defined in Section 13.2 is a 
   > resource identifier, which MUST be unique across all resources for all 
   > time.  If the values of DAV:resourceid returned by PROPFIND requests 
   > through two bindings are identical, the client can be assured that the 
   > two bindings are to the same resource.

   Whoa, where did this requirement come from?  The URI is a resource ID.
   If somebody wants to create a general metadata field for some sort of
   sacred-name, then go wild, but this is not needed for bindings.

The DAV:resourceid property is the only property that a client can
use in general to determine of two different URL's identify the same
resource.

   A question like this should be answered by a method applied to the
   collection, not to the individual bindings.

Could you explain this?

   I think that's it.  I'm sorry that I didn't get a chance to review
   this earlier, but I've been pretty busy the past two years.

I hear you on that "busy" thing (:-).  If you have time for a
couple more iterations, that would be great!

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Fri Jan 21 13:04:56 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14845
	for <webdav-archive@odin.ietf.org>; Fri, 21 Jan 2000 13:04:53 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA15305;
	Fri, 21 Jan 2000 12:53:58 -0500 (EST)
Resent-Date: Fri, 21 Jan 2000 12:53:58 -0500 (EST)
Resent-Message-Id: <200001211753.MAA15305@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: ccjason@us.ibm.com, Rickard Falk <rickard.falk@excosoft.se>
MMDF-Warning:  Parse error in original version of preceding line at gremlin-relay.ics.uci.edu
Cc: w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at gremlin-relay.ics.uci.edu
Date: Fri, 21 Jan 2000 09:49:46 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJAEICCMAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <8525686B.0063603F.00@D51MTA03.pok.ibm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: RE: Should I use displayname?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3903
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

Jason writes:
> Note: in the presence of multiple bindings, if the server initializes it
> to the URI and treats it as a dead property, that URI might be different
> from the URI from which it was accessed.

Hmm, since properties are part of the state of the resource, in the presence
of bindings it is more than possible for there to be multiple URI names for
the same "display name".  This removes the value of the displayname
property.  Some solutions:

1) move displayname to the collection, and have the collection maintain
displayname/binding pairs (this solution seems icky to me)

2) deprecate displayname, and only use URIs for display to the user, and
concentrate on i18n support for URIs.

- Jim



From w3c-dist-auth-request@w3.org  Fri Jan 21 13:11:07 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14907
	for <webdav-archive@odin.ietf.org>; Fri, 21 Jan 2000 13:11:05 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA15766;
	Fri, 21 Jan 2000 13:00:19 -0500 (EST)
Resent-Date: Fri, 21 Jan 2000 13:00:19 -0500 (EST)
Resent-Message-Id: <200001211800.NAA15766@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>,
        "Slein, Judith A" <JSlein@crt.xerox.com>
Cc: w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at gremlin-relay.ics.uci.edu
Date: Fri, 21 Jan 2000 09:56:11 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJIEICCMAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to:  <200001201638.aa20424@gremlin-relay.ics.uci.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: RE: WebDAV Bindings - Issue Yaron.MrIntegrity 
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3904
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding
Another way of stating the rationale for the integrity requirement is this:
we wanted to create a requirement that would prevent bindings that "dangle".
It must not be possible for a client to interact with a binding that doesn't
have a destination resource.

- Jim

> Sent: Thursday, January 20, 2000 4:39 PM
> To: Slein, Judith A
> Cc: w3c-dist-auth@w3.org
> Subject: Re: WebDAV Bindings - Issue Yaron.MrIntegrity
>
>
> >A binding is a relation between a segment S in a collection C
> and a resource
> >R, represented C:(S->R).  We are saying that when a server
> agrees to create
> >a binding, it MUST guarantee that the binding will continue to
> exist until
> >one of the following happens:
> >
> >DELETE with a Request-URI whose final segment is S and the rest
> of the URI
> >identifies collection C
> >MOVE with a Request-URI whose final segment is S and the rest of the URI
> >identifies collection C
> >BIND with a Destination whose final segment is S and the rest of the URI
> >identifies collection C, and Overwrite is T
> >DELETE the last binding to collection C
> >
> >It is not acceptable for a binding to be destroyed as a side
> effect of any
> >other operation.
>
> I don't understand why this is a requirement of bindings.  It certainly
> isn't a requirement of normal resources.  Why should the requirements on
> bound names be stronger than the names they bind to?
>
> ....Roy
>



From w3c-dist-auth-request@w3.org  Fri Jan 21 13:17:34 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14942
	for <webdav-archive@odin.ietf.org>; Fri, 21 Jan 2000 13:17:30 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA16230;
	Fri, 21 Jan 2000 13:03:19 -0500 (EST)
Resent-Date: Fri, 21 Jan 2000 13:03:19 -0500 (EST)
Resent-Message-Id: <200001211803.NAA16230@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: WJCarpenter <bill@carpenter.ORG>, w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at gremlin-relay.ics.uci.edu
Date: Fri, 21 Jan 2000 09:59:14 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJOEICCMAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <8809-Thu20Jan2000153111-0800-bill@carpenter.ORG>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: RE: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3905
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

Thanks for pointing this out -- this issue was originally caught by Keith
Wannamaker on the dav-dev list, and is currently captured in the RFC 2518
issues list:

http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html

- Jim

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of WJCarpenter
> Sent: Thursday, January 20, 2000 3:31 PM
> To: w3c-dist-auth@w3.org
> Subject: RFC-2518 LOCK-TOKEN: header
>
>
> Examples in RFC-2518, section 8.10.8 et seq, don't show a LOCK-TOKEN:
> response header.  This contradicts other places in RFC-2518 which say
> that the header is required in the response.
>
> It would suit me if the requirement were changed and the examples left
> as is.
> --
> bill@carpenter.ORG   (WJCarpenter)           PGP
> bill@bubblegum.net                    0x91865119
> 38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3
>



From w3c-dist-auth-request@w3.org  Fri Jan 21 14:02:32 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15746
	for <webdav-archive@odin.ietf.org>; Fri, 21 Jan 2000 14:02:32 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA18808;
	Fri, 21 Jan 2000 13:58:11 -0500 (EST)
Resent-Date: Fri, 21 Jan 2000 13:58:11 -0500 (EST)
Resent-Message-Id: <200001211858.NAA18808@www19.w3.org>
Date: Fri, 21 Jan 2000 13:57:52 -0500
Message-Id: <10001211857.AA26628@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <NDBBIKLAGLCOPGKGADOJAEICCMAA.ejw@ics.uci.edu> (message from Jim
	Whitehead on Fri, 21 Jan 2000 09:49:46 -0800)
Subject: Re: Should I use displayname?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3906
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


I vote for choice 2, since choice 1 is so egregiously bad.

Cheers,
Geoff

   From: Jim Whitehead <ejw@ics.uci.edu>
   Date: Fri, 21 Jan 2000 09:49:46 -0800
   Content-Length: 708

   Jason writes:
   > Note: in the presence of multiple bindings, if the server initializes it
   > to the URI and treats it as a dead property, that URI might be different
   > from the URI from which it was accessed.

   Hmm, since properties are part of the state of the resource, in the presence
   of bindings it is more than possible for there to be multiple URI names for
   the same "display name".  This removes the value of the displayname
   property.  Some solutions:

   1) move displayname to the collection, and have the collection maintain
   displayname/binding pairs (this solution seems icky to me)

   2) deprecate displayname, and only use URIs for display to the user, and
   concentrate on i18n support for URIs.

   - Jim




From w3c-dist-auth-request@w3.org  Fri Jan 21 14:40:31 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16158
	for <webdav-archive@odin.ietf.org>; Fri, 21 Jan 2000 14:40:29 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA19997;
	Fri, 21 Jan 2000 14:35:42 -0500 (EST)
Resent-Date: Fri, 21 Jan 2000 14:35:42 -0500 (EST)
Resent-Message-Id: <200001211935.OAA19997@www19.w3.org>
From: fielding@ebuilt.com
To: Jim Whitehead <ejw@ics.uci.edu>
Cc: w3c-dist-auth@w3.org
X-Mailer: Lotus Notes Release 5.0.1b September 30, 1999
Message-ID: <OFB1446DC5.E5FA7DA3-ON8825686D.0065D702@ebuilt.net>
Date: Fri, 21 Jan 2000 11:33:37 -0800
X-MIMETrack: Serialize by Router on riddler/Ebuilt(Release 5.0.2a |November 23, 1999) at 01/21/2000 11:33:44 AM,
	Serialize complete at 01/21/2000 11:33:44 AM
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: WebDAV Bindings - Issue Yaron.MrIntegrity
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3907
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

>Another way of stating the rationale for the integrity requirement is 
this:
>we wanted to create a requirement that would prevent bindings that 
"dangle".
>It must not be possible for a client to interact with a binding that 
doesn't
>have a destination resource.

There are two points you seem to be missing.  First, the origin
server doesn't know the resource.  The server knows what the URI is and
how to map that URI to a program and/or storage object(s), but the
resource is not the storage object.  There are resources that map to no
storage object.  In fact, there are resources that exist even before
their origin server has been realized in hardware and connected to the
Internet.  There are also storage objects that make up only a small
component of many other resources.  Bindings are not about storage 
objects.
They are about names within a namespace.  If you can create a binding
to another resource, then you can create a binding to no storage object,
which means any requirement that bindings be mappable to storage objects
is completely bogus.

The second point is that I, as an experienced Web developer, have
no interest in the strong integrity requirement.  It is, in fact,
contrary to the already implemented forms of bindings that can be
found in every general-purpose Web server post-1993.  It isn't
necessary for the abstract notion of adding an internal redirect
to a resource within the namespace of a collection, which is what
BIND is supposed to solve.  It is harder to implement than late
binding (in fact, the way it is worded in the spec is simply
impossible to implement, but that can be fixed by talking about
what the server knows and not about resources).  It isn't necessary
for interoperability.   It doesn't change the fact of life that some
bindings will be left dangling even with the requirement in the
protocol, since a normal resource can dangle, which means the protocol
still needs to express those semantics to the client (even if that
means the response is just 404, though I'm sure we can do better).

It is not a desirable feature in the majority of Web implementations,
since Web authors are familiar with the concept of setting up links
to a resource *before* the resource exists and don't want all their
links to disappear and need to be re-bound just because one URI
(which is the only way to identify a resource) goes away.  There is
no conceptual difference between a binding within a collection and
an <img src="binding"> within HTML.

It is okay if the server *wants* to implement strong integrity.
It is okay for some resources to have strong integrity by their
very nature.  All of the HTTP methods that make changes to the origin
are defined such that side-effects on other resources are expected.
It is therefore unnecessary to require it of all resources, even
with the presence of versioning and document management systems on
the backend.

Optional features are meant to be options, not protocol requirements.

...........................................................
Roy T. Fielding                         fielding@ebuilt.com
eBuilt, Inc.                            tel:+1.949.609.0000
2652 McGaw Ave.                         fax:+1.949.609.0001
Irvine, CA 92614-5840   USA           http://www.eBuilt.com
...........................................................



From w3c-dist-auth-request@w3.org  Fri Jan 21 14:51:29 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16308
	for <webdav-archive@odin.ietf.org>; Fri, 21 Jan 2000 14:51:26 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA20494;
	Fri, 21 Jan 2000 14:47:12 -0500 (EST)
Resent-Date: Fri, 21 Jan 2000 14:47:12 -0500 (EST)
Resent-Message-Id: <200001211947.OAA20494@www19.w3.org>
To: "Slein, Judith A" <JSlein@crt.xerox.com>
cc: w3c-dist-auth@w3.org
In-reply-to: Your message of "Fri, 21 Jan 2000 10:35:31 EST."
             <8E3CFBC709A8D21191A400805F15E0DBD24575@crte147.wc.eso.mc.xerox.com> 
Date: Fri, 21 Jan 2000 11:46:55 -0800
From: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
Message-ID:  <200001211146.aa21684@gremlin-relay.ics.uci.edu>
Subject: Re: WebDAV Bindings - Issue Yaron.MrIntegrity 
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3908
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

>There are applications that depend upon the integrity of bindings.  In
>particular, the versioning protocol being developed by the Delta-V working
>group depends upon it.  In versioning, there are many orthogonal ways of
>grouping information: by activity, by version tree, by configuration, etc.
>Clients depend upon the integrity of this information.

They depend on the integrity of versioned resources.  That is a
requirement on the resource, not on the protocol.  There is nothing
stopping delta-v from requiring that the bindings created for the
purpose of versioning be strongly bound and verifiable.

....Roy



From w3c-dist-auth-request@w3.org  Fri Jan 21 15:27:52 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16864
	for <webdav-archive@odin.ietf.org>; Fri, 21 Jan 2000 15:27:51 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA21460;
	Fri, 21 Jan 2000 15:23:42 -0500 (EST)
Resent-Date: Fri, 21 Jan 2000 15:23:42 -0500 (EST)
Resent-Message-Id: <200001212023.PAA21460@www19.w3.org>
Date: Fri, 21 Jan 2000 12:18:47 -0800
Message-ID: <3732-Fri21Jan2000121847-0800-bill@carpenter.ORG>
X-Mailer: 20.4 "Emerald" XEmacs  Lucid (via feedmail 9-beta-9 I) wjc loop;
	VM 6.71 under 20.4 "Emerald" XEmacs  Lucid
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: bill@carpenter.ORG (WJCarpenter)
To: w3c-dist-auth@w3.org
Subject: timeout types
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3909
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

RFC-2518, example in section 8.10.8, and description of
DAV:lockdiscovery in section 13.8 mention a "timeout type" for a
LOCK.  As far as I can tell, the example doesn't show any kind of
"timeout type" (particularly the one it says it shows), and I don't
see a description of "timeout type" elsewhere in RFC-2518.

Perhaps the "timeout type" is a holdover from an earlier draft and
just needs an editorial cleansing?
-- 
bill@carpenter.ORG   (WJCarpenter)           PGP
bill@bubblegum.net                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3



From w3c-dist-auth-request@w3.org  Fri Jan 21 16:47:48 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17762
	for <webdav-archive@odin.ietf.org>; Fri, 21 Jan 2000 16:47:47 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id QAA23464;
	Fri, 21 Jan 2000 16:43:37 -0500 (EST)
Resent-Date: Fri, 21 Jan 2000 16:43:37 -0500 (EST)
Resent-Message-Id: <200001212143.QAA23464@www19.w3.org>
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24577@crte147.wc.eso.mc.xerox.com>
From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'Yaron Goland'" <yarong@Exchange.Microsoft.com>, w3c-dist-auth@w3.org
Date: Fri, 21 Jan 2000 16:43:21 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.5.3Huh?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3910
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

What we were trying to accomplish in 5.3 and 5.4 was to state concisely and
reasonably formally exactly what new URI mappings are induced when a new
binding is created.
 
Recalling that a binding is a relation between a segment S in a collection C
and a resource R, the story is basically this.  Take every URI that maps to
collection C.  Concatenate S to that URI as its final segment.  Each URI you
create in this way is a URI that now maps to R in virtue of the new binding.
 
That's it unless R is itself a collection, in which case for every
descendent of R there is a new URI mapping for each of the new URI mappings
to R itself.
 
It seems to me that the current language in the spec is pretty clear (it's
certainly a vast improvement over what was in earlier drafts).  I doubt if I
can do any better, but let me take another stab at it and people can say
whether they think it helps:
 
5.3 URI Mappings Created by a BIND
 
This section describes the set of new URI mappings that result from the
creation of a new binding to a resource.
 
As defined in Section 3 above, a binding is a relation between a path
segment S in a collection C and a resource R.  We represent this binding as
C:(S->R).  The creation of this binding induces new URI mappings to R as
follows:
 
For each URI "C-URI" that was mapped to collection C before the BIND
request, the URI "C-URI/S" maps to resource R after the BIND request has
been processed.
 
For example, suppose that before the BIND request, the following URIs map to
collection C:
 
http://www.fuzz.com/A/1 <http://www.fuzz.com/A/1> 
http://fuzz.com/A/one <http://fuzz.com/A/one> 
 
Then a binding from segment "foo" to R is added to collection C.  The
creation of this binding causes the following URIs to be mapped to resource
R:
 
http://www.fuzz.clm/A/1/foo <http://www.fuzz.clm/A/1/foo> 
http://fuzz.com/A/one/foo <http://fuzz.com/A/one/foo> 
 
In addition, if R is itself a collection, then additional URI mappings to
the descendents of R result from the creation of the new binding to R.  For
example, if R already contained the bindings R:("bar"->R1) and
R:("bat"->R2), then the following new URI mappings to R1 and R2 are induced:
 
http://www.fuzz.com/A/1/foo <http://www.fuzz.com/A/1/foo> /bar
http://fuzz.com/A/one/foo <http://fuzz.com/A/one/foo> /bar
http://www.fuzz.com/A/1/foo <http://www.fuzz.com/A/1/foo> /bat
http://fuzz.com/A/one/foo <http://fuzz.com/A/one/foo> /bat
 
Note that if a loop is created by adding to a collection C a binding to C
itself or a parent of C, an infinite number of new URI mappings is created.
For example, if the binding C:("myself"->C) is created in collection C, the
following infinite number of URI mappings to C are induced:
 
http://www.fuzz.com/A/1/myself <http://www.fuzz.com/A/1/myself> 
http://www.fuzz.com/A/1/myself/myself
<http://www.fuzz.com/A/1/myself/myself> 
...
http://fuzz.com/A/one/myself <http://fuzz.com/A/one/myself> 
http://fuzz.com/A/one/myself/myself <http://fuzz.com/A/one/myself/myself> 
...
 
As well as an infinite number of new URI mappings to other members of C,
like
 
http://www.fuzz.com/A/1/myself/foo <http://www.fuzz.com/A/1/myself/foo> 
http://www.fuzz.com/A/1/myself/myself/foo
<http://www.fuzz.com/A/1/myself/myself/foo> 
...

- -Judy

 -----Original Message-----
From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
Sent: Sunday, January 16, 2000 8:52 PM
To: w3c-dist-auth@w3.org
Subject: WebDAV Bindings - Issue Yaron.5.3Huh?



The first paragraph of section 5.3 reads "Suppose a BIND request causes a
binding from "Binding-Name" to resource R to be added to a collection, C.
Then if C-MAP is the set of URI's that were mapped to C before the BIND
request, then for each URI "C-URI" in C-MAP, the URI "C-URI/Binding-Name" is
mapped to resource R following the BIND request." 

        I have a B.S. in CS & EE and got A's in my classes on set theory and
I still can't read this paragraph. I tried over and over again and I just
couldn't figure it out. If you are going to try to write set theory in
English you should at least translate it faithfully using the appropriate
terms such as "for all" and "there is an instance of". Personally I would
recommend just using an ASCII version of set code notation. Whatever you do,
the current paragraph MUST go. It is unfathomable. In fact here is the best
translation I have been able to come up with: Imagine I have a collection
http://icky/bop <http://icky/bop>  which contains http://icky/bop/blah
<http://icky/bop/blah> . Imagine I now want to map http://zizbang/rocky
<http://zizbang/rocky>  to http://icky/bop/rack <http://icky/bop/rack> .
According to this language it would seem I would have to create a bind to
http://icky/bop/blah/rack <http://icky/bop/blah/rack> . I know this makes no
sense but I swear that is what the sentence seemed to mean when I tried to
read it four or five times. As such I move that the paragraph be rewritten.




From w3c-dist-auth-request@w3.org  Fri Jan 21 17:35:22 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18237
	for <webdav-archive@odin.ietf.org>; Fri, 21 Jan 2000 17:35:21 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id RAA25227;
	Fri, 21 Jan 2000 17:31:09 -0500 (EST)
Resent-Date: Fri, 21 Jan 2000 17:31:09 -0500 (EST)
Resent-Message-Id: <200001212231.RAA25227@www19.w3.org>
Date: Fri, 21 Jan 2000 14:35:39 -0800 (PST)
From: Greg Stein <gstein@lyra.org>
To: ccjason@us.ibm.com
cc: Yaron Goland <yarong@Exchange.Microsoft.com>, w3c-dist-auth@w3.org
In-Reply-To: <8525686A.0070E47D.00@D51MTA03.pok.ibm.com>
Message-ID: <Pine.LNX.4.10.10001211415580.13911-100000@nebula.lyra.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: WebDAV Bindings - Issue Yaron.AtomicDelete
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3911
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

On Tue, 18 Jan 2000 ccjason@us.ibm.com wrote:
>...
> >>
>  There are, I freely admit, circumstances in which a client MUST be able to
> ensure that a DELETE is issued atomically. Clients in those cases will have
> to choose to not interoperate with many WebDAV servers in order to gain
> atomic delete.
> >>
> These clients can interoperate with an old iterative server just fine if
> they also include 2518 support.  That's their choice.
> 
> We have asked around and it seems that server authors appreciate and are
> willing to comply with semantic of an "atomic" removal of a single binding.

I don't recall being asked, nor agreeing with atomic operations. If that
binding happens to be a collection, then it will definitely be non-atomic.

[ also assuming this is the "final" removal of the collection ]

>...
> >>
> Let me clarify that DELETE was defined to not be atomic with malice of fore
> thought. The non-atomic delete language was the result of nearly three
> years of negotiations and represented a deep and broad consensus built up
> amongst a huge community. Might I respectfully suggest to the BIND authors
> that they should not be so ready to overthrow years of careful consensus
> building.
> >>
> We've asked around.  Folks appreciate this behavior and are willing to
> support it.

Again: I don't remember being asked. Maybe I missed a post to this list?

Regardless, I am not willing support atomic deletions of collections OR
single, member resources. Note that I mentioned member resources here. I
delete a member resource in two steps: the contents and its properties.
Definitely non-atomic.

And with respect to the Apache web server, I will not even begin to think
of making it atomic (e.g. serialize all requests while a resource is being
deleted).

> >>
> Do not imagine that the lack of screaming on this issue reflects consensus.
> Rather it reflects the fact that most of the WebDAV community is too busy
> implementing RFC 2518 to pay much attention to BIND. The BIND
> functionality, while I believe it will be important to WebDAV, is a bit
> ahead of the majority of implementers so they just aren't reading or
> reviewing it, yet.
> >>
> We have asked around and we didn't accept silence as a response.

I was certainly silent. Either that, or I'm going senile and forget
responding to a question of atomicity. I certainly can't imagine replying
"sure, I can sure an atomic delete".

> >>
> The key reason DELETE was not allowed to be atomic (which certainly would
> have been a nice thing to be able to do) has to do with the way file
> systems work. Most file systems do not support depth operations atomically.
> So, for example, when you delete a directory what actually happens is that
> the program does a depth first walk of the directory tree and deletes all
> the individual files, walking backwards up the tree until finally deleting
> the parent directory.
> >>
> You've pointed out that this is a problem on your file system.  We've found
> no other.   We've tested it and our testing indicates that the MOVE option
> you mention below works.  (We did not test with ACL's though... or multiple
> bindings.)    We've also contacted folks at your organization and they
> didn't see a problem.

This is an undue complication: generate a unique name, rename the resource
to that new name, then process its removal. And again, mod_dav couldn't
even do this because of its separation between properties and contents: I
could move the contents away, but a PROPFIND could still return
properties.

>...
> >>
> There is then the third and final issue, WebDAV begins with a "D" for a
> reason. It's goal is to be distributed. Requiring atomic DELETEs would
> essentially hinder all but the most expensive of systems from being able to
> implement distributed namespaces across multiple physical servers. The
> reason being that the atomic requirement means that these systems will have
> to establish transactioning systems between themselves in order to issue
> DELETEs if they share namespace.
> >>
> It's only one binding.  The goal isn't to be atomic, that's just a
> fortunate side effect.

It is *definitely* not a "side effect." mod_dav certainly does not do a
rename-then-delete. Therefore, I have to take explicit actions to achieve
that behavior. I don't even think that I could *ever* guarantee an atomic
DELETE operation.

>...
> >>
> As such I move that the atomic DELETE language be struck from the BIND spec
> on the grounds that it destroys interoperability, requires behavior that
> would preclude file system based systems from supporting WebDAV and
> significantly increases the cost of implementing WebDAV in a distributed
> manner.
> >>

I agree with Yaron on this one. Strongly.

> I believe I've addressed all of these above.
> 
> It is very clear that DELETE should not be iterative or accept partial
> results in a server that supports multiple bindings.

I think it is very clear that it shouldn't.

Stating your opinion of clarity doesn't make it so, nor does mine. But I
certainly can tell you right now that I won't be one of the "example
implementations" required for an IETF Standard.

> Legacy clients may
> invoke DELETE without knowledge of the potential dangers.  Therefore, a
> simple DELETE should delete a single binding.  --- There is no compelling
> reason (so far) not to support single binding delete and it simplifies the

I believe that I've given you one. With a good chunk of extra work and
serialization within the server, then it might be possible. But I am not
really up for trying to figure it out.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From w3c-dist-auth-request@w3.org  Fri Jan 21 18:52:50 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19083
	for <webdav-archive@odin.ietf.org>; Fri, 21 Jan 2000 18:52:50 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA26124;
	Fri, 21 Jan 2000 18:48:35 -0500 (EST)
Resent-Date: Fri, 21 Jan 2000 18:48:35 -0500 (EST)
Resent-Message-Id: <200001212348.SAA26124@www19.w3.org>
Message-ID: <00e001bf646a$372780f0$79442382@us.oracle.com>
From: "Eric Sedlar" <esedlar@us.oracle.com>
To: "Jim Whitehead" <ejw@ics.uci.edu>, <ccjason@us.ibm.com>,
        "Rickard Falk" <rickard.falk@excosoft.se>
Cc: <w3c-dist-auth@w3.org>
References: <NDBBIKLAGLCOPGKGADOJAEICCMAA.ejw@ics.uci.edu>
Date: Fri, 21 Jan 2000 15:49:53 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: Re: Should I use displayname?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3912
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

I don't understand what the problem is.  The client can use the displayname
to store some user-interpretable name for a resource that is independent of
the binding, so that the user can tell that these two URLs apply to the same
resource (they probably won't look at resourceID).  For example, the client
could parse the <title> out of an HTML document and store it there.  If you
default the display name to the last segment of the URL, then things can get
confusing as you point out.  It's up to the client to do something useful
here.

--Eric

----- Original Message -----
From: Jim Whitehead <ejw@ics.uci.edu>
To: <ccjason@us.ibm.com>; Rickard Falk <rickard.falk@excosoft.se>
Cc: <w3c-dist-auth@w3.org>
Sent: Friday, January 21, 2000 9:49 AM
Subject: RE: Should I use displayname?


> Jason writes:
> > Note: in the presence of multiple bindings, if the server initializes it
> > to the URI and treats it as a dead property, that URI might be different
> > from the URI from which it was accessed.
>
> Hmm, since properties are part of the state of the resource, in the
presence
> of bindings it is more than possible for there to be multiple URI names
for
> the same "display name".  This removes the value of the displayname
> property.  Some solutions:
>
> 1) move displayname to the collection, and have the collection maintain
> displayname/binding pairs (this solution seems icky to me)
>
> 2) deprecate displayname, and only use URIs for display to the user, and
> concentrate on i18n support for URIs.
>
> - Jim
>
>



From w3c-dist-auth-request@w3.org  Sat Jan 22 05:37:15 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07452
	for <webdav-archive@odin.ietf.org>; Sat, 22 Jan 2000 05:37:14 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id FAA07344;
	Sat, 22 Jan 2000 05:32:55 -0500 (EST)
Resent-Date: Sat, 22 Jan 2000 05:32:55 -0500 (EST)
Resent-Message-Id: <200001221032.FAA07344@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED0282B71F@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "Slein, Judith A" <JSlein@crt.xerox.com>,
        "'ccjason@us.ibm.com'"
	 <ccjason@us.ibm.com>
Cc: w3c-dist-auth@w3.org
Date: Sat, 22 Jan 2000 02:32:15 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id FAA07323
Subject: RE: WebDAV Bindings - Issue Yaron.507
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3913
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 8bit

My point is that the binding could fail not due to cross-server anything but
an intra-server something. That is why I brought up the FrontPage example.
If you try to bind between volumes it will fail. Yet given the current
definition FrontPage could not use a 507 in that case. That just seems
broken. That is why I wanted to widen the language so it could cover the
cross-volume scenario.

		Yaron

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Wednesday, January 19, 2000 5:49 PM
> To: 'ccjason@us.ibm.com'; Yaron Goland
> Cc: w3c-dist-auth@w3.org
> Subject: RE: WebDAV Bindings - Issue Yaron.507
> 
> 
> I don't have a strong commitment to 507 either, but for what 
> it's worth the
> rationale was that any creation of a cross-server binding requires
> out-of-band collaboration between the servers.  So it seems 
> very likely that
> a lot of servers will fail requests to create a binding to a 
> resource on
> another server, so it seems useful to have an error code for 
> this case.
> 
> --Judy
> 
> > -----Original Message-----
> > From: ccjason@us.ibm.com [mailto:ccjason@us.ibm.com]
> > Sent: Tuesday, January 18, 2000 8:40 PM
> > To: Yaron Goland
> > Cc: w3c-dist-auth@w3.org
> > Subject: Re: WebDAV Bindings - Issue Yaron.507
> > 
> > 
> > 
> > >>
> > In section 5.5 the 507 error code is written as "507 
> > (Cross-Server Binding
> > Forbidden): The server is unable to create the requested 
> > binding because it
> > would bind a segment in a collection on one server to a 
> resource on a
> > different server."
> > 
> >         What does a server have to do with anything? If you 
> > try to bind two
> > resources in different volumes on a FrontPage server the 
> > server will have
> > to fail the BIND even though the resources are on the same 
> server. In
> > general bringing in the server is almost always a bad idea 
> > since resources
> > can be spread out all over the place and the reasons for 
> > various failures
> > may or may not have anything to do with how those resources 
> > are laid out on
> > the servers. As such I move that the language for the 507 
> > error code be
> > altered to read that the resource was unable to create a 
> binding to a
> > destination and to leave the matter at that. All mentions 
> of the word
> > server should be stricken.
> > >>
> > 
> > Hmmm.  I don't have a strong preference on whether we should 
> > create a new
> > status code for lack of support for remote connections.  At 
> > some point we
> > might find we need one.   Anyway.... the status code that 
> > you're suggesting
> > doesn't seem to suggest anything except that the server can't do it.
> > Can't we just use 500 for that?   And if so, shouldn't we 
> > mention 500 it in
> > the spec?  Or is 500 too obvious to mention?
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 



From w3c-dist-auth-request@w3.org  Sat Jan 22 05:37:18 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07463
	for <webdav-archive@odin.ietf.org>; Sat, 22 Jan 2000 05:37:18 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id FAA07396;
	Sat, 22 Jan 2000 05:33:14 -0500 (EST)
Resent-Date: Sat, 22 Jan 2000 05:33:14 -0500 (EST)
Resent-Message-Id: <200001221033.FAA07396@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED0282B721@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "Slein, Judith A" <JSlein@crt.xerox.com>, w3c-dist-auth@w3.org
Date: Sat, 22 Jan 2000 02:32:35 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.MrIntegrity
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3914
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

I hail from the school of hard requirements and the proposed language is
open to too many possible interpretations to be considered "hard". I think
it would be better to specify the explicit conditions given below and then
provide a non-normative explanation of the desired long term behavior.

		Yaron

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Wednesday, January 19, 2000 7:05 PM
> To: 'Yaron Goland'; w3c-dist-auth@w3.org
> Subject: RE: WebDAV Bindings - Issue Yaron.MrIntegrity
> 
> 
> A binding is a relation between a segment S in a collection C 
> and a resource
> R, represented C:(S->R).  We are saying that when a server 
> agrees to create
> a binding, it MUST guarantee that the binding will continue 
> to exist until
> one of the following happens:
>  
> DELETE with a Request-URI whose final segment is S and the 
> rest of the URI
> identifies collection C
> MOVE with a Request-URI whose final segment is S and the rest 
> of the URI
> identifies collection C
> BIND with a Destination whose final segment is S and the rest 
> of the URI
> identifies collection C, and Overwrite is T
> DELETE the last binding to collection C
>  
> It is not acceptable for a binding to be destroyed as a side 
> effect of any
> other operation.
>  
> That's it for currently defined methods, I think.  But I also 
> think that we
> do have to rely on a more conceptual definition, however 
> inexact, to convey
> the implications for other methods that might be defined in 
> the future.
>  
> So here's a shot at the conceptual definition:
>  
> If a server allows binding C:(S->R) to be created, it MUST 
> guarantee that
> the resource R will continue to be accessible through the URI mappings
> induced by that binding until it receives an explicit request 
> to destroy the
> binding.  Such a request would have to ask explicitly that 
> some element of
> the relation C:(S->R) be removed, or that the relationship itself be
> removed.  It would have to explicitly request that the last 
> binding to C be
> removed, that the last binding to R be removed, or that the 
> binding C:(S->R)
> be removed from C.
>  
> --Judy
>  
>  -----Original Message-----
> From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
> Sent: Sunday, January 16, 2000 8:49 PM
> To: w3c-dist-auth@w3.org
> Subject: WebDAV Bindings - Issue Yaron.MrIntegrity
> 
> 
> 
> The last sentence of the last paragraph of section 4 reads 
> "Implementations
> MUST ensure the integrity of bindings." Similar language is 
> used in the
> second paragraph of section 5.1. However the term "integrity" 
> was never well
> defined inside of the specification. As such it is impossible 
> to comply with
> this requirement in an interoperable way. I would strongly 
> caution against
> attempting to specify the definition for integrity, English 
> is much too
> inexact a language for such an attempt to be successful.
> 
>         As such, I move that both sentences be removed and be 
> replaced with
> a series of statements that define, in exact language, the 
> requirements that
> are to be represented by the term "integrity", each sentence properly
> qualified with a MUST.
> 



From w3c-dist-auth-request@w3.org  Sat Jan 22 05:37:23 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07475
	for <webdav-archive@odin.ietf.org>; Sat, 22 Jan 2000 05:37:22 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id FAA07420;
	Sat, 22 Jan 2000 05:33:19 -0500 (EST)
Resent-Date: Sat, 22 Jan 2000 05:33:19 -0500 (EST)
Resent-Message-Id: <200001221033.FAA07420@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED0282B722@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "Slein, Judith A" <JSlein@crt.xerox.com>, w3c-dist-auth@w3.org
Date: Sat, 22 Jan 2000 02:32:37 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.403
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3915
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Disclaimer: I still hate the idea of introducing new error codes. I think
these should all be 400/500 error codes with a header or a body. I only
state this for the record.

I think adding a new 5xx code makes the most sense.

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Wednesday, January 19, 2000 6:17 PM
> To: 'Yaron Goland'; w3c-dist-auth@w3.org
> Subject: RE: WebDAV Bindings - Issue Yaron.403
> 
> 
> The previous revision of the spec had a separate error code 
> for this case,
> and I have no objection to putting it back in.  I think it 
> would be a 5xx
> rather than a 4xx though.  There's no error in the request, 
> it's just that
> the particular server has a policy forbidding creation of loops.
>  
> --Judy
> 
> -----Original Message-----
> From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
> Sent: Sunday, January 16, 2000 8:48 PM
> To: w3c-dist-auth@w3.org
> Subject: WebDAV Bindings - Issue Yaron.403
> 
> 
> 
> Section 5.2 of the Bind spec instructs the reader that if a 
> server wishes to
> reject a BIND request because it would cause a loop then the 
> server should
> return a 403 (Forbidden). However 403 is overloaded as it is. 
> For example, a
> 403 could mean that the method is banned at the moment for 
> some reason even
> though it is normally supported. This means that someone 
> trying to write an
> API to issue a BIND never really knows what a 403 means and 
> so doesn't know
> if they should tell the user that the server is currently 
> just not going to
> let the user perform this action or if the problem is that 
> the action would
> result in a loop. Therefore the use of 403 introduces a 
> vagueness into the
> response.
> 
>         Therefore I move that a new 4xx error code be 
> introduced to cover
> the case when a server refuses a BIND because it would cause a loop.
> 
>                 Yaron 
> 
> P.S. I think that the introduction of all these new error codes is a
> mistake. A new error code should only be, in my opinion, 
> introduced when it
> provides a very high level error description that could be 
> reasonably used
> by members of the HTTP infrastructure, meaning firewalls and proxies.
> Otherwise only the x00 errors should be used for everything 
> and either new
> headers or a body should be introduced to give detailed error 
> information.
> But I'm way too busy to try and push for this change so for 
> the moment let's
> just throw another error code on the barbie until people go 
> insane with
> them. It will be interesting to see how bad things have to 
> become before we
> can get this fixed.
> 



From w3c-dist-auth-request@w3.org  Sat Jan 22 12:11:58 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09586
	for <webdav-archive@odin.ietf.org>; Sat, 22 Jan 2000 12:11:57 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA11019;
	Sat, 22 Jan 2000 12:07:45 -0500 (EST)
Resent-Date: Sat, 22 Jan 2000 12:07:45 -0500 (EST)
Resent-Message-Id: <200001221707.MAA11019@www19.w3.org>
Message-Id: <4.2.2.20000122120506.00d99b60@mail.cyberteams.com>
X-Sender: severy@mail.cyberteams.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Sat, 22 Jan 2000 12:05:12 -0500
To: w3c-dist-auth@w3.org
From: Randall Severy <severy@cyberteams.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: RE: Should I use displayname?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3917
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

At 11:13 AM 1/20/00 -0800, Jim Whitehead wrote:
>Well, the intent of the displayname property was to provide a mechanism by
>which a user could assign a more meaningful name to a resource other than
>just the URL.  In particular I was thinking about non-latin character sets
>(like Kanji), which are currently poorly handled by existing URLs.

Jim,

       It's also a big issue when you're dealing with resources from 
something other than a simple filesystem.  It's very risky to assume that 
the URL always refers to a filename that is meaningful to the user.  For 
example, our WebSite Director DAV interface supports DAV access to our 
workflow processing.  The URL for an update request in a workflow stage 
would be something like "/WSD/Editing/requestB18894", which of course would 
be virtually meaningless to users.  The displayname property however, will 
be set to something like "ADD /mydir/myfile.html" or "MOVE 
/mydir/myfile.html TO /otherdir/myfile.html", which *will* be meaningful to 
users.  Because of the fact that Web Folders ignores the displayname 
property, we're having to do some seriously ugly URL mangling to make our 
DAV interface even modestly useable.

>However, this thread is certainly showing that there is an interoperability
>problem here. There are two choices:
>
>1) Have the server make it a dead property, initialized to be empty.
>Clients would display the last path segment from the href URL
>preferentially, but would display the displayname property if set.

I think it should be an option for servers to initialize the property to 
something meaningful to users, as in the example given above.  Also, 
clients should display the displayname property if set and only display the 
last part of the URL if there is no displayname property, again based on 
the example given above.

>2) Have the sever make it a dead property, initialized to the last path
>segment of the href URL.  The client would always use the displayname value.

This assumes that the last path segment of the href URL has any meaning to 
the user, which is often not the case when dealing with document 
repositories and other non-filesystem servers.

Cheers.......    Randall


Randall Severy    severy@cyberteams.com    http://www.cyberteams.com/severy
CyberTeams, Inc.    info@cyberteams.com    http://www.cyberteams.com
Mt. Airy, MD
(301) 829-6144          "Building effective teams in cyberspace"
1-888-832-5575



From w3c-dist-auth-request@w3.org  Sat Jan 22 12:12:00 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09597
	for <webdav-archive@odin.ietf.org>; Sat, 22 Jan 2000 12:12:00 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA11000;
	Sat, 22 Jan 2000 12:07:38 -0500 (EST)
Resent-Date: Sat, 22 Jan 2000 12:07:38 -0500 (EST)
Resent-Message-Id: <200001221707.MAA11000@www19.w3.org>
Message-Id: <4.2.2.20000122120453.02184630@mail.cyberteams.com>
X-Sender: severy@mail.cyberteams.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Sat, 22 Jan 2000 12:05:01 -0500
To: w3c-dist-auth@w3.org
From: Randall Severy <severy@cyberteams.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: Should I use displayname?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3916
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

At 03:00 PM 1/19/00 +0100, Rickard Falk wrote:
>When I'm trying to perform a directory browsing, that I'm going to present
>to a user. Should I then present the Displayname info or should I pars the
>href to get the name of the resource, from the Propfind request?
>If I should use the Displayname info, can I rely on that it only contains
>the name of the resource and not the complete path? ( this seems to be the
>case for IIS, Xythos, Zope. But not for CyberTeams server )

Rickard,

       The CyberTeams server will soon provide the displayname property, 
which will represent whatever is recommended for displaying to the 
user.  We haven't been returning it before since most of our earlier 
testing has been against Web Folders, which calmly ignores any values in 
displayname.  I would not rely on the href containing a meaningful resource 
name, especially when you are looking at something other than a file system.

Cheers.......    Randall


Randall Severy    severy@cyberteams.com    http://www.cyberteams.com/severy
CyberTeams, Inc.    info@cyberteams.com    http://www.cyberteams.com
Mt. Airy, MD
(301) 829-6144          "Building effective teams in cyberspace"
1-888-832-5575



From w3c-dist-auth-request@w3.org  Sat Jan 22 12:12:02 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09608
	for <webdav-archive@odin.ietf.org>; Sat, 22 Jan 2000 12:12:01 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA11050;
	Sat, 22 Jan 2000 12:07:56 -0500 (EST)
Resent-Date: Sat, 22 Jan 2000 12:07:56 -0500 (EST)
Resent-Message-Id: <200001221707.MAA11050@www19.w3.org>
Message-Id: <4.2.2.20000122120516.00d96e20@mail.cyberteams.com>
X-Sender: severy@mail.cyberteams.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Sat, 22 Jan 2000 12:05:20 -0500
To: w3c-dist-auth@w3.org
From: Randall Severy <severy@cyberteams.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: RE: Should I use displayname?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3918
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

At 09:49 AM 1/21/00 -0800, Jim Whitehead wrote:
>2) deprecate displayname, and only use URIs for display to the user, and
>concentrate on i18n support for URIs.

Jim,

      As I just mentioned in an earlier response, this assumes that the 
URIs represent something meaningful to the user.  If WebDAV is going to be 
used for anything other than simple file systems, I think this would be a 
seriously limiting solution.

Cheers.......    Randall


Randall Severy    severy@cyberteams.com    http://www.cyberteams.com/severy
CyberTeams, Inc.    info@cyberteams.com    http://www.cyberteams.com
Mt. Airy, MD
(301) 829-6144          "Building effective teams in cyberspace"
1-888-832-5575



From w3c-dist-auth-request@w3.org  Sat Jan 22 12:43:31 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09787
	for <webdav-archive@odin.ietf.org>; Sat, 22 Jan 2000 12:43:31 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA11835;
	Sat, 22 Jan 2000 12:38:53 -0500 (EST)
Resent-Date: Sat, 22 Jan 2000 12:38:53 -0500 (EST)
Resent-Message-Id: <200001221738.MAA11835@www19.w3.org>
From: ccjason@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: bill@carpenter.ORG (WJCarpenter)
cc: w3c-dist-auth@w3.org
Message-ID: <8525686E.0060E7D3.00@D51MTA03.pok.ibm.com>
Date: Sat, 22 Jan 2000 10:12:06 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: timeout types
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3919
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


>>
RFC-2518, example in section 8.10.8, and description of
DAV:lockdiscovery in section 13.8 mention a "timeout type" for a
LOCK.  As far as I can tell, the example doesn't show any kind of
"timeout type" (particularly the one it says it shows), and I don't
see a description of "timeout type" elsewhere in RFC-2518.

Perhaps the "timeout type" is a holdover from an earlier draft and
just needs an editorial cleansing?
>>
Presumably.  Yaron probably knows.  I've put it on the locking issues
list.  If he doesn't speak up I'll look into it later.




From w3c-dist-auth-request@w3.org  Sat Jan 22 14:59:01 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10626
	for <webdav-archive@odin.ietf.org>; Sat, 22 Jan 2000 14:59:00 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA13524;
	Sat, 22 Jan 2000 14:54:22 -0500 (EST)
Resent-Date: Sat, 22 Jan 2000 14:54:22 -0500 (EST)
Resent-Message-Id: <200001221954.OAA13524@www19.w3.org>
Date: Sat, 22 Jan 2000 14:54:13 -0500
Message-Id: <10001221954.AA27146@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <4.2.2.20000122120506.00d99b60@mail.cyberteams.com> (message from
	Randall Severy on Sat, 22 Jan 2000 12:05:12 -0500)
Subject: Re: Should I use displayname?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3920
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


   From: Randall Severy <severy@cyberteams.com>

	  It's also a big issue when you're dealing with resources from 
   something other than a simple filesystem.  It's very risky to assume that 
   the URL always refers to a filename that is meaningful to the user.

I don't think anyone is assuming that the URL always refers to a
filename.  The real question is under what circumstances the URL
cannot be made meaningful to the user.  In a common authoring
scenario, the author selects a collection, and then does a PUT, COPY,
MOVE, MKCOL, MKRESOURCE, or whatever, to create a new member of that
collection.  It doesn't matter whether the resource is implemented as
a file, a database record, or whatever.

   For 
   example, our WebSite Director DAV interface supports DAV access to our 
   workflow processing.  The URL for an update request in a workflow stage 
   would be something like "/WSD/Editing/requestB18894", which of course would 
   be virtually meaningless to users.

What WebDAV protocol do you use to create a new update request?
There currently is no "create a resource and assign it whatever name
you want" request.  The versioning protocol has introduced a couple
of methods like that to create specific versioning metadata resources,
but normally resources contain the URL assigned to them by the user.

   The displayname property however, will 
   be set to something like "ADD /mydir/myfile.html" or "MOVE 
   /mydir/myfile.html TO /otherdir/myfile.html", which *will* be meaningful to 
   users.  Because of the fact that Web Folders ignores the displayname 
   property, we're having to do some seriously ugly URL mangling to make our 
   DAV interface even modestly useable.

By ugly URL mangling, do you mean making the last segment of the URL
be the displayname?  Why is this a problem (other than the
internationalization issues that Jim mentioned, and perhaps concern
about the length of the URL)?

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Sat Jan 22 15:47:54 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11163
	for <webdav-archive@odin.ietf.org>; Sat, 22 Jan 2000 15:47:54 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA14136;
	Sat, 22 Jan 2000 15:43:44 -0500 (EST)
Resent-Date: Sat, 22 Jan 2000 15:43:44 -0500 (EST)
Resent-Message-Id: <200001222043.PAA14136@www19.w3.org>
Message-Id: <4.2.2.20000122152034.01f8aba0@mail.cyberteams.com>
X-Sender: severy@mail.cyberteams.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Sat, 22 Jan 2000 15:40:53 -0500
To: w3c-dist-auth@w3.org
From: Randall Severy <severy@cyberteams.com>
In-Reply-To: <10001221954.AA27146@tantalum>
References: <4.2.2.20000122120506.00d99b60@mail.cyberteams.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: Should I use displayname?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3921
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

At 02:54 PM 1/22/00 -0500, Geoffrey Clemm wrote:
>I don't think anyone is assuming that the URL always refers to a
>filename.  The real question is under what circumstances the URL
>cannot be made meaningful to the user.  In a common authoring
>scenario, the author selects a collection, and then does a PUT, COPY,
>MOVE, MKCOL, MKRESOURCE, or whatever, to create a new member of that
>collection.  It doesn't matter whether the resource is implemented as
>a file, a database record, or whatever.

Geoff,

      My mistake.  As you picked up on, the key word I was referring to was 
"meaningful", not "filename".  What I should have asked is "isn't it risky 
to assume that the URL always represents something meaningful to the 
user?".  I would argue that the answer is Yes, in that the DAV server 
should be able to choose to use URLs that mean something to the internal 
representation of the objects but that are complete gibberish to the 
users.  Forcing the server to generate URLs that are meaningful to the user 
puts a severe limitation on server design, IMHO.

>What WebDAV protocol do you use to create a new update request?
>There currently is no "create a resource and assign it whatever name
>you want" request.  The versioning protocol has introduced a couple
>of methods like that to create specific versioning metadata resources,
>but normally resources contain the URL assigned to them by the user.

      WebSite Director is a workflow/approval-based authoring system.  When 
you send PUT, MOVE, COPY, or DELETE methods to WebSite Director, the change 
is not immediately made to the filesystem, which would defeat the purpose 
of an approval system.  Instead, WebSite Director automatically creates an 
update request in the workflow system that matches the original DAV 
request.  Following the necessary approvals of that update request, the 
actual update to the web site takes place.  It is functionally equivalent 
to an FTP "incoming" directory, where a system administrator has to take 
some action to make an uploaded document visible and available to users by 
moving it out of the "incoming" directory.

       Consequently, WebSite Director assigns each new update request an 
internal identifier, which is used in the URL to refer to that pending 
update request (there's no point in using the original URL provided by the 
user since the update hasn't been published yet).  That URL is in the form 
mentioned previously, "/WSD/Editing/requestB18894", for example.

>By ugly URL mangling, do you mean making the last segment of the URL
>be the displayname?  Why is this a problem (other than the
>internationalization issues that Jim mentioned, and perhaps concern
>about the length of the URL)?

      To be able to use Web Folders effectively with our workflow 
processing (since Web Folders doesn't do anything with the displayname 
property), we are adding functionality to mangle the URLs of update 
requests so that the above mentioned request would instead have a URL of:

/WSD/Editing/MOVE |mydir|myfile.html TO |otherdir|myfile.html

       To be able to handle DAV methods against the above object, WebSite 
Director has to convert that mangled URL back into the internal identifier 
to figure out what to do.  Just the simple fact that you can't include "/" 
characters in the "filename" component of a URL makes the above mangling 
very ugly.  We settled on the vertical bar ("|") character as the closest 
approximation that we can get away with, but it's still very ugly.  If, on 
the other hand, Web Folders (or any other DAV client) were to check for a 
displayname property, containing "MOVE /mydir/myfile.html TO 
/otherdir/myfile.html", for example, and display that to the user if it was 
found, it would work very smoothly for the client, the server, and the user.

Cheers......   Randall


Randall Severy    severy@cyberteams.com    http://www.cyberteams.com/severy
CyberTeams, Inc.    info@cyberteams.com    http://www.cyberteams.com
Mt. Airy, MD
(301) 829-6144          "Building effective teams in cyberspace"
1-888-832-5575



From w3c-dist-auth-request@w3.org  Sun Jan 23 02:18:31 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28534
	for <webdav-archive@odin.ietf.org>; Sun, 23 Jan 2000 02:18:30 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id CAA19166;
	Sun, 23 Jan 2000 02:13:52 -0500 (EST)
Resent-Date: Sun, 23 Jan 2000 02:13:52 -0500 (EST)
Resent-Message-Id: <200001230713.CAA19166@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED0282B73B@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: w3c-dist-auth@w3.org
Date: Sat, 22 Jan 2000 23:13:11 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF6571.6709CD8E"
Subject: ACL Status
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3922
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6571.6709CD8E
Content-Type: text/plain;
	charset="iso-8859-1"

I promised that I would release a new ACL spec before the end of January.
Unfortunately, as I mentioned in another e-mail on this list, a family
emergency has come up that has required me to fly off to Israel at the last
moment. This has completely screwed up my schedule. The immediate result is
that the ACL spec will be delayed by a week or two. I sincerely apologize
for the delay but it was unavoidable. Sometimes life happens without first
checking our schedule.

			Yaron

------_=_NextPart_001_01BF6571.6709CD8E
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>ACL Status</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">I promised that I would release a new =
ACL spec before the end of January. Unfortunately, as I mentioned in =
another e-mail on this list, a family emergency has come up that has =
required me to fly off to Israel at the last moment. This has =
completely screwed up my schedule. The immediate result is that the ACL =
spec will be delayed by a week or two. I sincerely apologize for the =
delay but it was unavoidable. Sometimes life happens without first =
checking our schedule.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Yaron</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF6571.6709CD8E--



From w3c-dist-auth-request@w3.org  Sun Jan 23 02:18:31 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28531
	for <webdav-archive@odin.ietf.org>; Sun, 23 Jan 2000 02:18:30 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id CAA19240;
	Sun, 23 Jan 2000 02:14:09 -0500 (EST)
Resent-Date: Sun, 23 Jan 2000 02:14:09 -0500 (EST)
Resent-Message-Id: <200001230714.CAA19240@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED0282B73E@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "Slein, Judith A" <JSlein@crt.xerox.com>, w3c-dist-auth@w3.org
Date: Sat, 22 Jan 2000 23:13:17 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.PublishBind
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3924
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Just for the record, I don't really care what we do here. I have no
conceptual problem with cross referencing the specs. I just think that
cross-referencing them when the Bind spec is in last call and the redirect
reference spec isn't means that the Bind spec will be held up by the
redirect reference spec. But I'm happy to do whatever the authors want. 

I consider my objection fully addressed.

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Friday, January 21, 2000 5:48 PM
> To: 'Yaron Goland'; w3c-dist-auth@w3.org
> Subject: RE: WebDAV Bindings - Issue Yaron.PublishBind
> 
> 
> I think it's important for the binding spec and the redirect 
> reference spec
> to cross-reference each other, because they really are in the 
> same space,
> and implementers need to understand how bindings differ from redirect
> references, when it's appropriate to use each of these in 
> order to decide
> which spec to implement or whether they need both.
>  
> There is precedent for a family of specs referencing each 
> other in the MIME
> specs 2045 - 2049.
>  
> If it does look as if one of these specs is running into 
> trouble and might
> jeopardize the approval of the other, I would certainly want 
> to remove the
> cross-references and comparisons rather than jeopardize both specs.
>  
> 
> - -Judy
> 
>  
> 
>  -----Original Message-----
> From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
> Sent: Sunday, January 16, 2000 8:50 PM
> To: w3c-dist-auth@w3.org
> Subject: WebDAV Bindings - Issue Yaron.PublishBind
> 
> 
> 
> The spec refers to the redirect resource draft, even 
> attempting to refer to
> its RFC number. This means that the bind spec can not be 
> published as an RFC
> until the redirect resource draft is approved. While it is 
> nice to point out
> that the redirect resource draft exists I can find no 
> compelling reason to
> mention it when doing so restricts the schedule for the Bind draft's
> standardization. Therefore I move that all references to the redirect
> resource draft be stricken from the Bind spec, specifically 
> the removal of
> the last paragraph of the abstract, the 2nd, 4th and 5th to 
> last paragraphs
> of the Introduction and the reference [RR].
> 



From w3c-dist-auth-request@w3.org  Sun Jan 23 02:23:40 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28532
	for <webdav-archive@odin.ietf.org>; Sun, 23 Jan 2000 02:18:30 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id CAA19199;
	Sun, 23 Jan 2000 02:14:02 -0500 (EST)
Resent-Date: Sun, 23 Jan 2000 02:14:02 -0500 (EST)
Resent-Message-Id: <200001230714.CAA19199@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED0282B73A@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "Slein, Judith A" <JSlein@crt.xerox.com>, w3c-dist-auth@w3.org
Date: Sat, 22 Jan 2000 23:13:10 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.5.3Huh?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3923
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Sigh... the language still makes my head hurt. However I think we have
reached put up or shut up time. Either I have to come up with better
language or I have to go away.

Please note, for those new to the IETF, that there is no general "Put Up or
Shut Up" requirement for last calls. It is completely legitimate for someone
to come to a last call and say "This language sucks" and to stop the draft
until the group agrees on better language. There is absolutely no basis for
asking that person to put in better language. After all they are not an
author and therefore are not normally qualified to write up new language.
However they are a customer and if they can't understand the language then
it means the authors have work left to do.

That having been said my relationship with the authors of the Bind spec is
not one of innocent bystander (more like accident victim ;) and I owe them
collectively so many favors that it isn't even funny. Currently they are
suffering from "been working on this @*!$*@# spec for too @*!$*@# long"
disease and so have trouble fixing language that appears perfectly rational
to them but looks like near gibberish to the rest of humanity. As such I
have something of a duty to help out by taking a fresh perspective and
hopefully using that perspective to produce clearer language.

But here is where I have to ask for forgiveness. There was a family
emergency that has caused me to fly off to Israel at the last second. In
fact, I am currently typing this letter from Israel. As such I don't have
time right now to re-write the language. Doubly unfortunately I have a super
critical presentation to give to my boss's boss's boss's boss's boss on the
1st. So as soon as I get back to the states my life must be dedicated to
that presentation. This means that I won't have time to produce alternate
language until the week of the 1st. I normally wouldn't ask for so long but
the family emergency has really screwed everything up.

I sincerely apologize for the delay.

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Friday, January 21, 2000 11:43 PM
> To: 'Yaron Goland'; w3c-dist-auth@w3.org
> Subject: RE: WebDAV Bindings - Issue Yaron.5.3Huh?
> 
> 
> What we were trying to accomplish in 5.3 and 5.4 was to state 
> concisely and
> reasonably formally exactly what new URI mappings are induced 
> when a new
> binding is created.
>  
> Recalling that a binding is a relation between a segment S in 
> a collection C
> and a resource R, the story is basically this.  Take every 
> URI that maps to
> collection C.  Concatenate S to that URI as its final 
> segment.  Each URI you
> create in this way is a URI that now maps to R in virtue of 
> the new binding.
>  
> That's it unless R is itself a collection, in which case for every
> descendent of R there is a new URI mapping for each of the 
> new URI mappings
> to R itself.
>  
> It seems to me that the current language in the spec is 
> pretty clear (it's
> certainly a vast improvement over what was in earlier 
> drafts).  I doubt if I
> can do any better, but let me take another stab at it and 
> people can say
> whether they think it helps:
>  
> 5.3 URI Mappings Created by a BIND
>  
> This section describes the set of new URI mappings that 
> result from the
> creation of a new binding to a resource.
>  
> As defined in Section 3 above, a binding is a relation between a path
> segment S in a collection C and a resource R.  We represent 
> this binding as
> C:(S->R).  The creation of this binding induces new URI 
> mappings to R as
> follows:
>  
> For each URI "C-URI" that was mapped to collection C before the BIND
> request, the URI "C-URI/S" maps to resource R after the BIND 
> request has
> been processed.
>  
> For example, suppose that before the BIND request, the 
> following URIs map to
> collection C:
>  
> http://www.fuzz.com/A/1 <http://www.fuzz.com/A/1> 
> http://fuzz.com/A/one <http://fuzz.com/A/one> 
>  
> Then a binding from segment "foo" to R is added to collection C.  The
> creation of this binding causes the following URIs to be 
> mapped to resource
> R:
>  
> http://www.fuzz.clm/A/1/foo <http://www.fuzz.clm/A/1/foo> 
> http://fuzz.com/A/one/foo <http://fuzz.com/A/one/foo> 
>  
> In addition, if R is itself a collection, then additional URI 
> mappings to
> the descendents of R result from the creation of the new 
> binding to R.  For
> example, if R already contained the bindings R:("bar"->R1) and
> R:("bat"->R2), then the following new URI mappings to R1 and 
> R2 are induced:
>  
> http://www.fuzz.com/A/1/foo <http://www.fuzz.com/A/1/foo> /bar
> http://fuzz.com/A/one/foo <http://fuzz.com/A/one/foo> /bar
> http://www.fuzz.com/A/1/foo <http://www.fuzz.com/A/1/foo> /bat
> http://fuzz.com/A/one/foo <http://fuzz.com/A/one/foo> /bat
>  
> Note that if a loop is created by adding to a collection C a 
> binding to C
> itself or a parent of C, an infinite number of new URI 
> mappings is created.
> For example, if the binding C:("myself"->C) is created in 
> collection C, the
> following infinite number of URI mappings to C are induced:
>  
> http://www.fuzz.com/A/1/myself <http://www.fuzz.com/A/1/myself> 
> http://www.fuzz.com/A/1/myself/myself
> <http://www.fuzz.com/A/1/myself/myself> 
> ...
> http://fuzz.com/A/one/myself <http://fuzz.com/A/one/myself> 
> http://fuzz.com/A/one/myself/myself 
> <http://fuzz.com/A/one/myself/myself> 
> ...
>  
> As well as an infinite number of new URI mappings to other 
> members of C,
> like
>  
> http://www.fuzz.com/A/1/myself/foo 
> <http://www.fuzz.com/A/1/myself/foo> 
> http://www.fuzz.com/A/1/myself/myself/foo
> <http://www.fuzz.com/A/1/myself/myself/foo> 
> ...
> 
> - -Judy
> 
>  -----Original Message-----
> From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
> Sent: Sunday, January 16, 2000 8:52 PM
> To: w3c-dist-auth@w3.org
> Subject: WebDAV Bindings - Issue Yaron.5.3Huh?
> 
> 
> 
> The first paragraph of section 5.3 reads "Suppose a BIND 
> request causes a
> binding from "Binding-Name" to resource R to be added to a 
> collection, C.
> Then if C-MAP is the set of URI's that were mapped to C 
> before the BIND
> request, then for each URI "C-URI" in C-MAP, the URI 
> "C-URI/Binding-Name" is
> mapped to resource R following the BIND request." 
> 
>         I have a B.S. in CS & EE and got A's in my classes on 
> set theory and
> I still can't read this paragraph. I tried over and over 
> again and I just
> couldn't figure it out. If you are going to try to write set theory in
> English you should at least translate it faithfully using the 
> appropriate
> terms such as "for all" and "there is an instance of". 
> Personally I would
> recommend just using an ASCII version of set code notation. 
> Whatever you do,
> the current paragraph MUST go. It is unfathomable. In fact 
> here is the best
> translation I have been able to come up with: Imagine I have 
> a collection
> http://icky/bop <http://icky/bop>  which contains http://icky/bop/blah
> <http://icky/bop/blah> . Imagine I now want to map 
http://zizbang/rocky
<http://zizbang/rocky>  to http://icky/bop/rack <http://icky/bop/rack> .
According to this language it would seem I would have to create a bind to
http://icky/bop/blah/rack <http://icky/bop/blah/rack> . I know this makes no
sense but I swear that is what the sentence seemed to mean when I tried to
read it four or five times. As such I move that the paragraph be rewritten.



From w3c-dist-auth-request@w3.org  Mon Jan 24 12:38:11 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15799
	for <webdav-archive@odin.ietf.org>; Mon, 24 Jan 2000 12:38:11 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA05946;
	Mon, 24 Jan 2000 12:33:38 -0500 (EST)
Resent-Date: Mon, 24 Jan 2000 12:33:38 -0500 (EST)
Resent-Message-Id: <200001241733.MAA05946@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: WebDAV WG <w3c-dist-auth@w3.org>
Date: Mon, 24 Jan 2000 09:29:31 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJEEKLCMAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: FW: Comments please!
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3925
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

Accidentally caught by the spam filter.  I've put in a request to have
Rickard's email address added to the accept2 list for the mailing list, but
since he doesn't appear to be subscribed, please cc him directly on any
responses.

- Jim

-----Original Message-----
From: falk@excosoft.se [mailto:falk@excosoft.se]
Sent: Sunday, January 23, 2000 12:01 AM
To: w3c-dist-auth@w3.org
Subject: [Moderator Action] Comments please!


I have a WebDav / Http url problem. The problem I have, as a client
developer,
is to know when to do a propfind directory browsing and when to just do a
get.
An example:
The user types that he wants to open 'http://www.foo.com/foo'. If /foo is a
directory there is a problem. If I do a get on that url, the server could
hand
me /foo/index.htm ( or some other default file ), or it could generate a
html
file displaying the directory listing. But if I do a propfind, I could
generate
a directory listing from the answer.
But how can I know which the users wants?
Today I solve this by using a wildcard at the end of the url.
Ex:
'http://www.foo.com/*' -> Do a propfind on 'http://www.foo.com/'. If not
okay,
try a Get on 'http://www.foo.com/*'.
This gives the user a way of 'open as webfolder', without having to checking
a
checkbox. So now you can have links in xml files, that gives you a WebDav
directory listing. Or even email it.

Anyone have some comments, or is there another way of solving this problem?

/Rickard




From w3c-dist-auth-request@w3.org  Mon Jan 24 13:03:30 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16705
	for <webdav-archive@odin.ietf.org>; Mon, 24 Jan 2000 13:03:28 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA06771;
	Mon, 24 Jan 2000 12:57:59 -0500 (EST)
Resent-Date: Mon, 24 Jan 2000 12:57:59 -0500 (EST)
Resent-Message-Id: <200001241757.MAA06771@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: falk@excosoft.se, w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at gremlin-relay.ics.uci.edu
Date: Mon, 24 Jan 2000 09:53:46 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJGEKMCMAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <200001230755.IAA02786@mailgate.excosoft.se>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: RE: Comments please!
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3926
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit


> I have a WebDav / Http url problem. The problem I have, as a
> client developer, is to know when to do a propfind directory
> browsing and when to just do a get.
> An example:
> The user types that he wants to open 'http://www.foo.com/foo'. If
> /foo is a directory there is a problem. If I do a get on that url,
> the server could hand me /foo/index.htm ( or some other default
> file ), or it could generate a html file displaying the directory
> listing. But if I do a propfind, I could generate a directory
> listing from the answer.
>
> But how can I know which the users wants?

One solution is this:

If you don't know whether it is a collection, or an ordinary resource,
always perform a PROPFIND of Depth 1 on the resource.  If the resource is a
collection, you'll receive the directory listing.  If the resource is an
ordinary resource, you should just get back the properties on the resource
itself, which will be a fairly small response.  Then, if it is just an
ordinary resource, you can proceed with the GET.

Note that this would only need to be done when the program doesn't know what
kind of resource it is dealing with.  Once the program starts receiving
PROPFIND responses, it can cache that information, and check its cache
before performing the request.  While the program shouldn't depend on the
cached information being correct (it could be stale), you can certainly make
some optimizations based on the expected type of the resource (for example,
going straight to a GET request if you expect the resource is an ordinary
resource).

> Today I solve this by using a wildcard at the end of the url.
> Ex:
> 'http://www.foo.com/*' -> Do a propfind on 'http://www.foo.com/'.
> If not okay, try a Get on 'http://www.foo.com/*'.
> This gives the user a way of 'open as webfolder', without having
> to checking a checkbox. So now you can have links in xml files,
> that gives you a WebDav directory listing. Or even email it.

My concern with the "*" approach is that most non-programmer types don't
realize there are special wildcard semantics associated with "*".

- Jim



From w3c-dist-auth-request@w3.org  Mon Jan 24 14:05:47 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19422
	for <webdav-archive@odin.ietf.org>; Mon, 24 Jan 2000 14:05:46 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA09338;
	Mon, 24 Jan 2000 14:01:11 -0500 (EST)
Resent-Date: Mon, 24 Jan 2000 14:01:11 -0500 (EST)
Resent-Message-Id: <200001241901.OAA09338@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: WJCarpenter <bill@carpenter.ORG>, w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at gremlin-relay.ics.uci.edu
Date: Mon, 24 Jan 2000 10:57:00 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJEEKOCMAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <3732-Fri21Jan2000121847-0800-bill@carpenter.ORG>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: RE: timeout types
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3927
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit


Bill Carpenter writes:
> RFC-2518, example in section 8.10.8, and description of
> DAV:lockdiscovery in section 13.8 mention a "timeout type" for a
> LOCK.  As far as I can tell, the example doesn't show any kind of
> "timeout type" (particularly the one it says it shows), and I don't
> see a description of "timeout type" elsewhere in RFC-2518.
>
> Perhaps the "timeout type" is a holdover from an earlier draft and
> just needs an editorial cleansing?

Well, "timeout type" is used slightly inconsistently within the spec.  In
section 9.8, which defines the Timeout request header, there is a TimeType
BNF production which describes the syntax of the # of seconds the lock will
last, in addition to having an "Other" production, which is intended to
allow extensibility.  So this is one meaning for "timeout type" -- the
TimeType within the Timeout request header.  It is this sense of "timeout
type" that is used in section 13.8.

During the creation of the spec., we had discussions about whether to
support different kinds of lock refresh policies, and potentially having the
ability to say whether the timeout was absolute, or could be refreshed by
actions on the resource.  In the end, the spec. states that locks should be
refreshed by actions on the resource by the lock owner, but this hasn't been
widely implemented (to the best of my knowledge), since it adds a fair
performance penalty to all operations.  There is currently an item on the
DAV issues list "LOCK_REFRESH_BY_METHODS" that suggests the current
SHOULD-level requirement for refreshing the lock timer based on actions by
the lock owner should be removed.  However, it is this notion of locks being
refreshed by user activity that results in the mention of "activity-based
timeout policy" in 8.10.8.

- Jim



From w3c-dist-auth-request@w3.org  Mon Jan 24 14:28:02 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20538
	for <webdav-archive@odin.ietf.org>; Mon, 24 Jan 2000 14:28:01 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA10293;
	Mon, 24 Jan 2000 14:23:46 -0500 (EST)
Resent-Date: Mon, 24 Jan 2000 14:23:46 -0500 (EST)
Resent-Message-Id: <200001241923.OAA10293@www19.w3.org>
Message-ID: <039f01bf669f$d28d1dc0$0201a8c0@everest.com>
From: "Kaelin Colclasure" <kaelin@everest.com>
To: "Jim Whitehead" <ejw@ics.uci.edu>, "WJCarpenter" <bill@carpenter.ORG>,
        <w3c-dist-auth@w3.org>
References: <NDBBIKLAGLCOPGKGADOJEEKOCMAA.ejw@ics.uci.edu>
Date: Mon, 24 Jan 2000 11:18:40 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: Jini Distributed Leasing Specification (was Re: timeout types)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3928
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

----- Original Message -----
From: Jim Whitehead <ejw@ics.uci.edu>
To: WJCarpenter <bill@carpenter.org>; <w3c-dist-auth@w3.org>
Sent: Monday, January 24, 2000 10:57 AM
Subject: RE: timeout types


>
> Bill Carpenter writes:
> > RFC-2518, example in section 8.10.8, and description of
> > DAV:lockdiscovery in section 13.8 mention a "timeout type" for a
> > LOCK.  As far as I can tell, the example doesn't show any kind of
> > "timeout type" (particularly the one it says it shows), and I don't
> > see a description of "timeout type" elsewhere in RFC-2518.
> >
> > Perhaps the "timeout type" is a holdover from an earlier draft and
> > just needs an editorial cleansing?
>
> Well, "timeout type" is used slightly inconsistently within the spec.  In
> section 9.8, which defines the Timeout request header, there is a TimeType
> BNF production which describes the syntax of the # of seconds the lock
will
> last, in addition to having an "Other" production, which is intended to
> allow extensibility.  So this is one meaning for "timeout type" -- the
> TimeType within the Timeout request header.  It is this sense of "timeout
> type" that is used in section 13.8.

Are you familiar with the "Lease" technique which I first encountered in
Sun's specifications for Jini?

<http://www.sun.com/jini/specs/lease101.html>

Leases represent a very intuitive (IMO) approach to addressing issues of
resource reservation / locking in distributed architectures. While this
particular specification is of course for a Java implementation of the
concept, there's no reason the idea couldn't be incorporated into a
protocol like WebDAV.

> During the creation of the spec., we had discussions about whether to
> support different kinds of lock refresh policies, and potentially having
the
> ability to say whether the timeout was absolute, or could be refreshed by
> actions on the resource.  In the end, the spec. states that locks should
be
> refreshed by actions on the resource by the lock owner, but this hasn't
been
> widely implemented (to the best of my knowledge), since it adds a fair
> performance penalty to all operations.  There is currently an item on the
> DAV issues list "LOCK_REFRESH_BY_METHODS" that suggests the current
> SHOULD-level requirement for refreshing the lock timer based on actions by
> the lock owner should be removed.  However, it is this notion of locks
being
> refreshed by user activity that results in the mention of "activity-based
> timeout policy" in 8.10.8.

For all the reasons you cite, and *particularly* because the loosely
specified semantics of "implicit" refreshes breed interoperability
problems, a lease-like mechanism may be worth investigating.

-- Kaelin




From w3c-dist-auth-request@w3.org  Mon Jan 24 14:56:34 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22001
	for <webdav-archive@odin.ietf.org>; Mon, 24 Jan 2000 14:56:31 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA12215;
	Mon, 24 Jan 2000 14:52:02 -0500 (EST)
Resent-Date: Mon, 24 Jan 2000 14:52:02 -0500 (EST)
Resent-Message-Id: <200001241952.OAA12215@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: Kaelin Colclasure <kaelin@everest.com>, w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at gremlin-relay.ics.uci.edu
Date: Mon, 24 Jan 2000 11:47:53 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJMEKPCMAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <039f01bf669f$d28d1dc0$0201a8c0@everest.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: RE: Jini Distributed Leasing Specification (was Re: timeout types)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3929
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit


> Are you familiar with the "Lease" technique which I first encountered in
> Sun's specifications for Jini?
>
> <http://www.sun.com/jini/specs/lease101.html>
>
> Leases represent a very intuitive (IMO) approach to addressing issues of
> resource reservation / locking in distributed architectures. While this
> particular specification is of course for a Java implementation of the
> concept, there's no reason the idea couldn't be incorporated into a
> protocol like WebDAV.
>

Well, I was not familiar with Jini leases, so I took a quick look through
the spec. you referenced.  As near as I can tell, there are many
similarities between the semantics for Jini leases and WebDAV locks.  Jini
leases allow an object to request a lease that lasts forever, or for a
specific time period, similar to WebDAV locks which can be requested for a
specific time period in seconds, or with the value "Infinite".  Jini leases
can be refreshed, as can WebDAV locks, by re-requesting the lock. Jini
leases can be canceled before the time period ends, as can WebDAV locks,
using the UNLOCK method.

Was there some specific Jini lease semantic that you particularly think
WebDAV would benefit from?

- Jim



From w3c-dist-auth-request@w3.org  Mon Jan 24 15:11:01 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22759
	for <webdav-archive@odin.ietf.org>; Mon, 24 Jan 2000 15:10:59 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA12965;
	Mon, 24 Jan 2000 15:06:01 -0500 (EST)
Resent-Date: Mon, 24 Jan 2000 15:06:01 -0500 (EST)
Resent-Message-Id: <200001242006.PAA12965@www19.w3.org>
Message-ID: <03d201bf66a5$c0de3bd0$0201a8c0@everest.com>
From: "Kaelin Colclasure" <kaelin@everest.com>
To: "Jim Whitehead" <ejw@ics.uci.edu>, <w3c-dist-auth@w3.org>
References: <NDBBIKLAGLCOPGKGADOJMEKPCMAA.ejw@ics.uci.edu>
Date: Mon, 24 Jan 2000 12:01:08 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: Re: Jini Distributed Leasing Specification (was Re: timeout types)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3930
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

----- Original Message -----
From: Jim Whitehead <ejw@ics.uci.edu>
To: Kaelin Colclasure <kaelin@everest.com>; <w3c-dist-auth@w3.org>
Sent: Monday, January 24, 2000 11:47 AM
Subject: RE: Jini Distributed Leasing Specification (was Re: timeout types)


> Well, I was not familiar with Jini leases, so I took a quick look through
> the spec. you referenced.  As near as I can tell, there are many
> similarities between the semantics for Jini leases and WebDAV locks.  Jini
> leases allow an object to request a lease that lasts forever, or for a
> specific time period, similar to WebDAV locks which can be requested for a
> specific time period in seconds, or with the value "Infinite".  Jini
leases
> can be refreshed, as can WebDAV locks, by re-requesting the lock. Jini
> leases can be canceled before the time period ends, as can WebDAV locks,
> using the UNLOCK method.
>
> Was there some specific Jini lease semantic that you particularly think
> WebDAV would benefit from?

Yes.

 a) You can request an "infinite" lease, but you must be prepared for the
    server to return to you instead a finite lease. You must then renew that
    lease before it expires if you want it to persist without interruption.
 b) The renewal of the lease is an explicit action on the part of the
client,
    and is required to occur within a specific time interval. There is no
    implicit anything.

This is, IMHO, significantly less complicated to implement robustly and
correctly than implicit renewal. And of course, truly infinite locks are
highly suspect in a distributed environment. It could be argued that
leases shouldn't permit them at all -- but it suffices to interpret
"infinite" to mean "the longest period a server chooses to tolerate
possibly holding a resource for a client that's never coming back."

-- Kaelin

--
Become a Venture Technologist... <http://www.everest.com/careers/>




From w3c-dist-auth-request@w3.org  Tue Jan 25 02:17:48 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19142
	for <webdav-archive@odin.ietf.org>; Tue, 25 Jan 2000 02:17:48 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id CAA00735;
	Tue, 25 Jan 2000 02:08:52 -0500 (EST)
Resent-Date: Tue, 25 Jan 2000 02:08:52 -0500 (EST)
Resent-Message-Id: <200001250708.CAA00735@www19.w3.org>
From: "Rickard Falk" <rickard.falk@excosoft.se>
To: <w3c-dist-auth@w3.org>
Date: Tue, 25 Jan 2000 08:08:38 +0100
Message-ID: <NDBBLFJCCKNFKHAFJDCDEEPJCBAA.rickard.falk@excosoft.se>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <NDBBIKLAGLCOPGKGADOJGEKMCMAA.ejw@ics.uci.edu>
Subject: RE: Comments please!
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3931
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit


>
> One solution is this:
>
> If you don't know whether it is a collection, or an ordinary resource,
> always perform a PROPFIND of Depth 1 on the resource.  If the
> resource is a
> collection, you'll receive the directory listing.  If the resource is an
> ordinary resource, you should just get back the properties on the resource
> itself, which will be a fairly small response.  Then, if it is just an
> ordinary resource, you can proceed with the GET.
>
> Note that this would only need to be done when the program
> doesn't know what
> kind of resource it is dealing with.  Once the program starts receiving
> PROPFIND responses, it can cache that information, and check its cache
> before performing the request.  While the program shouldn't depend on the
> cached information being correct (it could be stale), you can
> certainly make
> some optimisations based on the expected type of the resource
> (for example,
> going straight to a GET request if you expect the resource is an ordinary
> resource).

Hmm. But this doesn't solve my problem. Let's say that my website is called
'http://www.foo.com'. If I do a
get on this url, I'll get 'http://www.foo.com/index.htm' by default. But
'http://www.foo.com' is also a directory at the to level. So if a user types
'http://www.foo.com' I don't know if I should perform a Get or a Propfind,
both are valid. The user types the same thing for directory browsing in
'http://www.foo.com' and for getting the default page.

>
> > Today I solve this by using a wildcard at the end of the url.
> > Ex:
> > 'http://www.foo.com/*' -> Do a propfind on 'http://www.foo.com/'.
> > If not okay, try a Get on 'http://www.foo.com/*'.
> > This gives the user a way of 'open as webfolder', without having
> > to checking a checkbox. So now you can have links in xml files,
> > that gives you a WebDav directory listing. Or even email it.
>
> My concern with the "*" approach is that most non-programmer types don't
> realize there are special wildcard semantics associated with "*".
>
> - Jim
>

I agree.
This is why I posted this question. And probably why the 'web folders' have
to go through 'file/open' with a checkbox that say's it should be opened as
a folder.

/Rickard



From w3c-dist-auth-request@w3.org  Tue Jan 25 06:31:14 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21505
	for <webdav-archive@odin.ietf.org>; Tue, 25 Jan 2000 06:31:09 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id GAA06849;
	Tue, 25 Jan 2000 06:20:46 -0500 (EST)
Resent-Date: Tue, 25 Jan 2000 06:20:46 -0500 (EST)
Resent-Message-Id: <200001251120.GAA06849@www19.w3.org>
Date: Tue, 25 Jan 2000 11:19:58 +0000
From: Joe Orton <joe@orton.demon.co.uk>
To: w3c-dist-auth@w3.org
Message-ID: <20000125111958.A25078@york.ac.uk>
Mail-Followup-To: w3c-dist-auth@w3.org
References: <NDBBIKLAGLCOPGKGADOJGEKMCMAA.ejw@ics.uci.edu> <NDBBLFJCCKNFKHAFJDCDEEPJCBAA.rickard.falk@excosoft.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <NDBBLFJCCKNFKHAFJDCDEEPJCBAA.rickard.falk@excosoft.se>; from rickard.falk@excosoft.se on Tue, Jan 25, 2000 at 08:08:38AM +0100
Subject: Re: Comments please!
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3932
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

> Hmm. But this doesn't solve my problem. Let's say that my website is called
> 'http://www.foo.com'. If I do a
> get on this url, I'll get 'http://www.foo.com/index.htm' by default. But
> 'http://www.foo.com' is also a directory at the to level. So if a user types
> 'http://www.foo.com' I don't know if I should perform a Get or a Propfind,
> both are valid. The user types the same thing for directory browsing in
> 'http://www.foo.com' and for getting the default page.

I think this mostly a UI problem. From the user's point of view, have two "views" 
on a collection resource; it's GET response, and the listing of collection members
from a PROPFIND response. These correspond to the traditional "web browser" mode of
operation, and the traditional "file browser/explorer" mode of operation.

Like you say, in Web Folders you have the "Open as Web folder" checkbox on open
dialog, which selects which of these views should be used for the given URI. 
Another way to do this (maybe Web Folders does this too, I've not been that side of
the fence for a while?), is to have some way of switching between modes from within
the browser; a toolbar button, or a drop-down box, or whatever.

So then, the user can browse about their web site, happily viewing their pages,
then maybe they want to move some files about, so they hit the "view collection
contents" button, and they can do that, then switch back again when they've
finished. That would be a nice interface, IMO.

joe




From w3c-dist-auth-request@w3.org  Tue Jan 25 12:35:45 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04489
	for <webdav-archive@odin.ietf.org>; Tue, 25 Jan 2000 12:35:42 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA16408;
	Tue, 25 Jan 2000 12:28:47 -0500 (EST)
Resent-Date: Tue, 25 Jan 2000 12:28:47 -0500 (EST)
Resent-Message-Id: <200001251728.MAA16408@www19.w3.org>
From: jamsden@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <85256871.005FFDFB.00@d54mta03.raleigh.ibm.com>
Date: Tue, 25 Jan 2000 12:25:28 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3933
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list



Bill,
If the lock token isn't returned in the header, there's no way for you to
get the lock token of the lock you just created. That's because the active
lock element of the lock discovery property does not contain the
authentication id of the principal owning the lock. The lock  tokens are in
the lock discovery, but you can't figure out which ones you own.

I continue to believe this is an open issue that requires clients to
persist their lock  tokens outside the WebDAV repository. Lock tokens are a
pain enough for the rare case where they are actually useful. Not having
the principal owning the lock in the lock discovery makes them even worse.
I proposed a fix to this over a year ago, but was  told at that time that
it was too late and would have too much effect on the spec which was about
to become an accepted draft. But now we are looking at some pretty
significant changes to locking semantics. Can we please get this simple
issue resolved. WebDAV clients will appreciate it.





bill@carpenter.ORG (WJCarpenter)@w3.org on 01/20/2000 06:31:11 PM

Sent by:  w3c-dist-auth-request@w3.org


To:   w3c-dist-auth@w3.org
cc:

Subject:  RFC-2518 LOCK-TOKEN: header


Examples in RFC-2518, section 8.10.8 et seq, don't show a LOCK-TOKEN:
response header.  This contradicts other places in RFC-2518 which say
that the header is required in the response.

It would suit me if the requirement were changed and the examples left
as is.
--
bill@carpenter.ORG   (WJCarpenter)           PGP
bill@bubblegum.net                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3






From w3c-dist-auth-request@w3.org  Tue Jan 25 13:15:25 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05521
	for <webdav-archive@odin.ietf.org>; Tue, 25 Jan 2000 13:15:24 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA17478;
	Tue, 25 Jan 2000 13:10:39 -0500 (EST)
Resent-Date: Tue, 25 Jan 2000 13:10:39 -0500 (EST)
Resent-Message-Id: <200001251810.NAA17478@www19.w3.org>
Date: Tue, 25 Jan 2000 13:10:24 -0500
Message-Id: <10001251810.AA28231@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <85256871.005FFDFB.00@d54mta03.raleigh.ibm.com>
	(jamsden@us.ibm.com)
Subject: Re: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3934
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

   From: jamsden@us.ibm.com

   If the lock token isn't returned in the header, there's no way for you to
   get the lock token of the lock you just created.

Section 6.3 of RFC-2518 states that you can get the lock token
through the lock discovery property:

"A lock token is a type of state token, represented as a URI, which
identifies a particular lock.  A lock token ... can also be found
through lock discovery on a resource."

   That's because the active
   lock element of the lock discovery property does not contain the
   authentication id of the principal owning the lock.

I can find no authentication id defined or required by RFC-2518.

In fact, RFC-2518  explicitly states that an authentication id is not
part of the WebDAV protocol:

"Locks MUST be enforced based upon whatever authentication mechanism
is used by the server, not based on the secrecy of the token values."

and:

"User agent authentication has previously occurred via a mechanism
outside the scope of the HTTP protocol, in an underlying transport
layer."

   The lock tokens are in
   the lock discovery, but you can't figure out which ones you own.

This information is provided by the DAV:owner element in the
lockdiscovery property.

   I continue to believe this is an open issue that requires clients to
   persist their lock  tokens outside the WebDAV repository. Lock tokens are a
   pain enough for the rare case where they are actually useful.

How else do you handle the situation where the same principal has
several clients acting against the same resource?  I believe this will
be a common scenario.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Tue Jan 25 13:20:52 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05609
	for <webdav-archive@odin.ietf.org>; Tue, 25 Jan 2000 13:20:47 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA17840;
	Tue, 25 Jan 2000 13:16:04 -0500 (EST)
Resent-Date: Tue, 25 Jan 2000 13:16:04 -0500 (EST)
Resent-Message-Id: <200001251816.NAA17840@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: WebDAV WG <w3c-dist-auth@w3.org>
Date: Tue, 25 Jan 2000 10:11:53 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJKEMJCMAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: FW: Bindings Protocol
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3935
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

Accidentally caught by the spam filter.

- Jim

-----Original Message-----
From: James J. Hunt [mailto:jjh@ira.uka.de]
Sent: Tuesday, January 25, 2000 1:30 AM
To: w3c-dist-auth@w3.org
Subject: [Moderator Action] Bindings Protocol



Dear WebDAV Contributors,

After having had read the recent postings on the proposed bindings protocol
specification, we would like to add our position on some issues that still
seem unresolved.  Some of this reiterates points that have already been
made, but it is necessary to restate these point to provide a consistent
view.  Some other points are new.

MEMBER URIs

The definition of WebDAV's internal member URIs seems to be one of the
key problems for the bindings protocol: creating a new binding to a
collection results in providing access to its members through
alternate request URIs and hence formally creates new internal member
URIs (as defined in WebDAV) for that collection, hence undesirably
changing its state.

Unfortunately, this is not a server-only issue: clients become aware
of internal member URIs, for example when applying a PROPFIND, i.e.
during client/server communication, which is the central scope of the
protocol.

The question is how can we make the requirement for internal member URIs
consistent with multiple paths to the same resource.  There seems to be no
requirement that the internal member URIs be stored in full in each
collection.  They are just need to be constructible for sending back to a
client.  If each collection and resource contains a list of all collections
that reference the given collection or resource, all internal member URIs
could be constructed.

When enumerating through a collection, each member of the collection would
be seen then just once, and the URI that was used to address the collection
could be used as the base for generating the URIs of the members.  The
situation is a little more complicated for deep iterations, e.g. PROPFIND
on a collection with depth infinity.  Here, if a resource is accessible
through more than one path from the root collection, the simple
implementation would return an entry or result for each path.  Note however
that path from outside this subtree need (and should) not be in the
enumeration.  (A recursive ls in UNIX does exactly this with hard links.)
We
would argue that this is acceptable.  The unique resource identifier can be
used to detect duplicates.

It is probably better to redefine the definition of internal members, but
that is outside our scope.  It would be better to make the above
implementation requirement instead of assuming some other definition.
Trying to compensate more than the above implementation suggests is
undesirable.

SOFT vs HARD

Another central topic is the discussion on soft/weak and hard/strong
links/bindings.  While an exact definition of these terms may slightly vary,
there seems to be agreement about the fact that the redirection reference
resources specification [RR], will cover the specification of some kind of
weak bindings, while DeltaV (particularly with revisioned collections) will
need strong bindings.  Thus hard link should be addressed in the binding
specification.

The binding specification claims that it is not acceptable
for moving a resource through one binding to disrupt another binding.
This seems sensible for use in future specifications like DeltaV that
will build upon the bindings specification.  In practice, this means,
that bindings probably will behave similar to, for example, hard links
in a file system. This should not be too hard to implement.

Moreover, future protocols like DeltaV seem to require that clients may
trace bindings on the server in both directions, from each binding source
(or path segment, as called in the specification) to its single destination
resource, and from each destination resource to its (possibly multiple)
binding sources.  Currently, the bindings specification allows to determine
whether two bindings are to the same resource (section 10).  In order to be

able to find all URI to a particular resource or collection, it is
necessary to implement the optional DAV property DAV:bindings.  This is not
only much more efficient than traversing the URI space of a server and
comparing bindings, but when links for other servers are allowed it may be
the only way to find all visible links (some links may not be visible to a
particular user because of access restrictions).

As for that, one could propose the bindings protocol to extend WebDAV
such that upon explicit request by the client (e.g. through an
additional header) the server returns not only a single member URI in
a single href element on PROPFIND requests, depending on the specific
request URI, but a set of member URIs that contains an arbitrary
single URI out of the set of all URIs for each binding resource that
immediately maps to the request URI.

RESOURCE INTEGRITY

There seems to be still some disagreement about the integrity of binding.
Our position is that binding should maintain integrity, but side effects
should be avoided whenever possible (Roy's no magic criteria).  This
dictates
that DELETE should only remove the given binding, not the resource or
collection itself.  That should (must) be deleted when no more references
exist.

One argument against this is that one can not positively remove a resource
from the server.  Permission restrictions aside, this is possible through
another mechanism, namely DAV:bindings.  By locking a resource and then
iterating through the results of DAV:bindings, the user should be able
to completely remove any resource from a server (again permission
restrictions aside).

Strong bindings *across* servers may, as mentioned in the current
version of the bindings specification, cause severe problems.
As host-to-host communication is the central issue for web protocols,
the bindings specification should thoroughly specify the behavior
between the corresponding servers rather than just mentioning some
problems.

LOCKS

According to [WebDAV], section 7.1, the bindings specification should
specify
how the BIND method interacts with a write lock.

ATOMICITY

Atomicity of DELETE would be very hard to implement, if at all possible,
e.g. on the basis of non-journaling file systems.  However, the idea behind
atomicity as used in the specification seems to be that a client can perform
a series of actions as a unity without being disturbed by other clients.
DeltaV, for example, wants to implement a CHECKIN operation with a workspace
or activity as request URL (but that is currently still on the TODO list).
This will probably require some kind of transaction model rather than an
atomicity model.  A transaction model that prevents other clients from
intermingling a series of operations should be sufficient. And this is
exactly what WebDAV locks are designed for.  For example, when deleting a
hierarchy of resources, a client may beforehand try to lock each resource
that contributes to the hierarchy and start deletion only if all locks could
be set.  Or a client may assert a write lock on a null resources on the
destination of a MOVE operation.  In other words, the binding specification
should not require atomicity of operations; instead, a transaction model
should be introduced, based on operation on DAV locks.  But transactions are
not in the scope of the bindings protocol; they belong either directly to
DeltaV or should be specified in a separate transactions protocol
specification.

Sincerely,

Juergen Reuter
James J. Hunt



From w3c-dist-auth-request@w3.org  Tue Jan 25 13:35:36 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05860
	for <webdav-archive@odin.ietf.org>; Tue, 25 Jan 2000 13:35:33 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA18506;
	Tue, 25 Jan 2000 13:30:29 -0500 (EST)
Resent-Date: Tue, 25 Jan 2000 13:30:29 -0500 (EST)
Resent-Message-Id: <200001251830.NAA18506@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: WebDAV WG <w3c-dist-auth@w3.org>
Date: Tue, 25 Jan 2000 10:26:19 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJMEMKCMAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: End: WG Last Call: Bindings Protocol
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3936
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

The working group last call period on the WebDAV Bindings Protocol
Specification, <draft-ietf-webdav-binding-protocol-02>, is now complete.

Based on the comments received during the last call period, another revision
of this specification needs to be made addressing the comments.  Once this
revision is ready, there will be another, shorter, 2-week working group last
call period on this revised specification, at the end of which I expect to
be able to forward the draft along to the IESG for approval as a Proposed
Standard.

- Jim Whitehead
Chair, IETF WebDAV WG



From w3c-dist-auth-request@w3.org  Tue Jan 25 14:14:34 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06486
	for <webdav-archive@odin.ietf.org>; Tue, 25 Jan 2000 14:14:33 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA20552;
	Tue, 25 Jan 2000 14:09:56 -0500 (EST)
Resent-Date: Tue, 25 Jan 2000 14:09:56 -0500 (EST)
Resent-Message-Id: <200001251909.OAA20552@www19.w3.org>
Date: Tue, 25 Jan 2000 11:04:33 -0800
Message-ID: <1702-Tue25Jan2000110433-0800-bill@carpenter.ORG>
X-Mailer: 20.4 "Emerald" XEmacs  Lucid (via feedmail 9-beta-9 I) wjc loop;
	VM 6.71 under 20.4 "Emerald" XEmacs  Lucid
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: bill@carpenter.ORG (WJCarpenter)
To: w3c-dist-auth@w3.org
In-Reply-To: <10001251810.AA28231@tantalum>
References: <85256871.005FFDFB.00@d54mta03.raleigh.ibm.com>
	<10001251810.AA28231@tantalum>
Subject: Re: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3937
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

gmc> Section 6.3 of RFC-2518 states that you can get the lock token
gmc> through the lock discovery property:

Yeah, that's what I was thinking (especially as the lock discovery
property is the prescribed payload returned after a successful LOCK
request).  But Jim Amsden is right that that's not sufficient.

ja> That's because the active lock element of the lock discovery
ja> property does not contain the authentication id of the principal
ja> owning the lock.

gmc> I can find no authentication id defined or required by RFC-2518.

Yeah, you're right, too, and that's the problem.  The DAV:owner
property is just so much commentary by the LOCK requester.  It
explicitly has no bearing on the out-of-band authentication.  In
short, it can be a complete lie or completely irrelevant.  I think the
idea of DAV:owner was for human consumption, in case you want to track
down the LOCK owner and beat him/her with a stick until s/he releases
the LOCK.  It is by design not at all helpful to the server in
deciding whether the principal attempting a change is the LOCK holder
or not.

For exclusive LOCKs, you can assume from the lock discovery part of a
successful response that you got the applicable token mentioned.  For
shared LOCKs, you need the LOCK-TOKEN: header or some additional goop
in lock discovery conveying "authenticated" ownership.  For the
problem you mention, of multiple clients being run by the same
principal, there is no sanctioned, unambiguous way to do lock
discovery.

I agree that that is an issue needing a solution.
-- 
bill@carpenter.ORG   (WJCarpenter)           PGP
bill@bubblegum.net                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3



From w3c-dist-auth-request@w3.org  Tue Jan 25 14:34:48 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06644
	for <webdav-archive@odin.ietf.org>; Tue, 25 Jan 2000 14:34:48 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA21748;
	Tue, 25 Jan 2000 14:30:27 -0500 (EST)
Resent-Date: Tue, 25 Jan 2000 14:30:27 -0500 (EST)
Resent-Message-Id: <200001251930.OAA21748@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: WebDAV WG <w3c-dist-auth@w3.org>
Date: Tue, 25 Jan 2000 11:26:16 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJOEMNCMAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: Moving right along...
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3938
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

As I mentioned in the initial message describing the working group last call
for comments on the Binding Protocol, that last call is the first of three
last calls covering all three of the Advanced Collections specifications.
The next one of these last calls periods, concerning the redirect references
protocol, will begin today, and go for the next four weeks.  I'll be
describing this in my next message. In turn, the last call on the Redirect
References protocol will be followed by a last call on the Ordered
Collections protocol, finishing up the three Advanced Collections
specifications.

Afterwards, I'm hoping the revised bindings protocol will be done, and we'll
then be able to start right in on the second last call on it, prior to
sending it along to the IESG.

Laid out with dates, this looks like:

1/25 - 2/22 :: Last call on Redirect References
2/23 - 3/22 :: Last call on Ordered Collections
3/23 - 4/6  :: Second, last call on Bindings Specification (assuming
submission of revised Bindings Protocol by 3/23)

Second last calls on the Redirect References, and Ordered Collections
specifications, if needed, will take place in order, starting on April 7th.

I'd like to thank everyone who submitted comments on the Bindings
Specification -- the comments were of very high quality, and will allow this
specification to be improved a great deal.  But, don't stop now!  We're just
at the beginning of this season of last calls, and I encourage you (and
others who didn't send in comments too) to review the specifications, submit
comments, and participate in working through the issues that are surfaced.

- Jim




From w3c-dist-auth-request@w3.org  Tue Jan 25 14:43:52 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06762
	for <webdav-archive@odin.ietf.org>; Tue, 25 Jan 2000 14:43:47 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA22067;
	Tue, 25 Jan 2000 14:38:56 -0500 (EST)
Resent-Date: Tue, 25 Jan 2000 14:38:56 -0500 (EST)
Resent-Message-Id: <200001251938.OAA22067@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: WebDAV WG <w3c-dist-auth@w3.org>
Date: Tue, 25 Jan 2000 11:34:48 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJEEMOCMAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: WG Last Call: Redirect Reference Resources
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3939
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit


*** WORKING GROUP LAST CALL FOR COMMENTS ***

WEBDAV REDIRECT REFERENCE RESOURCES SPECIFICATION

<draft-ietf-webdav-redirectref-protocol-02>
http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-redirect
ref-protocol-02.txt

This is the final call for comments from the working group on the WebDAV
Redirect Reference Resources protocol specification,
draft-ietf-webdav-binding-protocol-02. This last call period begins
immediately, and ends February 22, 2000, at midnight, US Pacific time.  This
allows 4 weeks for review of this specification.

At the end of the last call period, a new draft will be issued that resolves
comments raised during the last call period.  Depending on the scope of
changes, there will follow either an immediate call for rough consensus
(very few changes), or a second last call period (significant changes). Once
the document represents the rough consensus of the working group, I will
submit this document to the Internet Engineering Steering Group (IESG) for
their approval. IESG review involves a (minimum) two week public last call
for comments review period. This IESG-initiated last call period is in
addition to the working group last call period.

This document is intended to be a "Proposed Standard".  Quoting from RFC
2026, "The Internet Standards Process -- Revision 3":

   The entry-level maturity for the standards track is "Proposed
   Standard".  A specific action by the IESG is required to move a
   specification onto the standards track at the "Proposed Standard"
   level.

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable, and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

Many details on the procedures used to develop an IETF standard can be found
in RFC 2026, available at:

ftp://ftp.ietf.org/rfc/rfc2026.txt

If there are any procedural questions or concerns, please do not hesitate to
contact me, or raise an issue on the list.

Notes:

1) This specification is one of three that have been developed in tandem,
the other two being the WebDAV Bindings Protocol,
<draft-ietf-webdav-binding-protocol-02>, which just finished a working group
last call for comments period on January 24, and the Ordered Collections
Protocol, draft-ietf-webdav-ordering-protocol-02.  The Ordered Collections
Protocol will begin a working group last call for comments period
immediately following the end of this last call period, on February 23,
2000.  If you wish, you may submit comments on the Ordered Collections
protocol and the Redirect References protocol together during the present
last call period.

2) If you've been waiting for a "stable" version of the specification before
performing a review, wait no longer.  This is it.  Assuming the
specification receives only positive feedback, or mostly minor comments, it
will be submitted to the IESG for approval with no further WG last call
periods.  You should treat this as your last opportunity to provide feedback
on the specification.  Review the specification NOW.


- Jim Whitehead
Chair, IETF WEBDAV Working Group



From w3c-dist-auth-request@w3.org  Tue Jan 25 16:29:37 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07951
	for <webdav-archive@odin.ietf.org>; Tue, 25 Jan 2000 16:29:36 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id QAA25254;
	Tue, 25 Jan 2000 16:25:05 -0500 (EST)
Resent-Date: Tue, 25 Jan 2000 16:25:05 -0500 (EST)
Resent-Message-Id: <200001252125.QAA25254@www19.w3.org>
Date: Tue, 25 Jan 2000 16:24:54 -0500
Message-Id: <10001252124.AA28406@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <1702-Tue25Jan2000110433-0800-bill@carpenter.ORG>
Subject: Re: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3940
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

   From: bill@carpenter.ORG (WJCarpenter)

   gmc> Section 6.3 of RFC-2518 states that you can get the lock token
   gmc> through the lock discovery property:

   Yeah, that's what I was thinking (especially as the lock discovery
   property is the prescribed payload returned after a successful LOCK
   request).  But Jim Amsden is right that that's not sufficient.
   ...  The DAV:owner
   property is just so much commentary by the LOCK requester.  It
   explicitly has no bearing on the out-of-band authentication.  In
   short, it can be a complete lie or completely irrelevant.  I think the
   idea of DAV:owner was for human consumption, in case you want to track
   down the LOCK owner and beat him/her with a stick until s/he releases
   the LOCK.  It is by design not at all helpful to the server in
   deciding whether the principal attempting a change is the LOCK holder
   or not.

There seem to be two issues here.  The first is whether a server
should authenticate that the principal specifying the lock token in an
IF header is the same principal that created the lock token in a lock
request.  This is not required by WebDAV, since it is pretty pointless
to carefully guard a lock token when as soon as you UNLOCK the
resource, anyone can come in and trash the resource.  Lock tokens are
for avoiding merges, not for security.

So if you want interoperable security, you should become active in the
WebDAV ACL's effort.  If you try to get it from WebDAV locking and
lock tokens, you will be doomed to disappointment.  But that's not
because WebDAV locking is broken (it in fact does a great job
of avoiding merges), but rather that it doesn't do what it wasn't
designed to do.

The second issue is whether a client other than the lock requesting
client should be able to use the lock token to get access to a
resource.  Doing so would violate the whole design of the lock token
scheme, which is to have a protocol for reliably deciding whether a
*particular* client has the authority granted by the lock token.  The
protocol only works if only the client that made the LOCK request uses
the generated lock token.  The fact that the lock token was issued to
a particular principal is irrelevant.

So a client should always get its own lock token, not appropriate
an existing one.  If a resource is already exclusively locked,
it first will need to UNLOCK the resource.  This then guarantees
that if the other client (that issued the LOCK request) is still
around, it will notice the "cancellation" by the failure of its next
update request.

   For exclusive LOCKs, you can assume from the lock discovery part of a
   successful response that you got the applicable token mentioned.  For
   shared LOCKs, you need the LOCK-TOKEN: header or some additional goop
   in lock discovery conveying "authenticated" ownership.

There is even less point in authenticating shared lock ownership
(which I guess makes it a negative number, since I argue above
that there is no point in authenticating exclusive lock ownership :-).
If you are a principal that has the right to take out a shared
lock, you can just get one - you don't need to use some existing shared lock.

   For the
   problem you mention, of multiple clients being run by the same
   principal, there is no sanctioned, unambiguous way to do lock
   discovery.

There is a sanctioned unambiguous way to do lock discovery ... there
just is (by design) no sanctioned way to do lock appropriation (:-).

Cheers,
Geoff

P.S. I may be all wrong about this, since my livelihood is versioning,
not locking, but I don't think so (:-).



From w3c-dist-auth-request@w3.org  Tue Jan 25 18:11:30 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09502
	for <webdav-archive@odin.ietf.org>; Tue, 25 Jan 2000 18:11:28 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA29169;
	Tue, 25 Jan 2000 18:04:35 -0500 (EST)
Resent-Date: Tue, 25 Jan 2000 18:04:35 -0500 (EST)
Resent-Message-Id: <200001252304.SAA29169@www19.w3.org>
Date: Tue, 25 Jan 2000 14:58:57 -0800
Message-ID: <2271-Tue25Jan2000145857-0800-bill@carpenter.ORG>
X-Mailer: 20.4 "Emerald" XEmacs  Lucid (via feedmail 9-beta-9 I) wjc loop;
	VM 6.71 under 20.4 "Emerald" XEmacs  Lucid
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: bill@carpenter.ORG (WJCarpenter)
To: w3c-dist-auth@w3.org
In-Reply-To: <10001252124.AA28406@tantalum>
References: <1702-Tue25Jan2000110433-0800-bill@carpenter.ORG>
	<10001252124.AA28406@tantalum>
Subject: Re: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3941
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

gmc> The second issue is whether a client other than the lock
gmc> requesting client should be able to use the lock token to get
gmc> access to a resource.  Doing so would violate the whole design of
gmc> the lock token scheme, which is to have a protocol for reliably
gmc> deciding whether a *particular* client has the authority granted
gmc> by the lock token.  The protocol only works if only the client
gmc> that made the LOCK request uses the generated lock token.  The
gmc> fact that the lock token was issued to a particular principal is
gmc> irrelevant.

This doesn't address other reasons for doing unambiguous lock
discovery.  It leaves aside such rainy day scenarios as "oops, my
application just crashed (et seq :-))" and "I guess I'll go home for
the night and work on this".

gmc> So a client should always get its own lock token, not appropriate
gmc> an existing one.  If a resource is already exclusively locked, it
gmc> first will need to UNLOCK the resource.  This then guarantees
gmc> that if the other client (that issued the LOCK request) is still
gmc> around, it will notice the "cancellation" by the failure of its
gmc> next update request.

This technique also opens a (probably very small) window wherein
someone else could grab the lock.  (Such events are not always a
matter of competition.  You could be under the impression that your
co-author was going to release the LOCK when s/he was done and it was
your turn.)
-- 
bill@carpenter.ORG   (WJCarpenter)           PGP
bill@bubblegum.net                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3



From w3c-dist-auth-request@w3.org  Tue Jan 25 18:42:57 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10177
	for <webdav-archive@odin.ietf.org>; Tue, 25 Jan 2000 18:42:57 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA00085;
	Tue, 25 Jan 2000 18:38:36 -0500 (EST)
Resent-Date: Tue, 25 Jan 2000 18:38:36 -0500 (EST)
Resent-Message-Id: <200001252338.SAA00085@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: WJCarpenter <bill@carpenter.ORG>, w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at gremlin-relay.ics.uci.edu
Date: Tue, 25 Jan 2000 15:34:20 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJGENICMAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <2271-Tue25Jan2000145857-0800-bill@carpenter.ORG>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: RE: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3942
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit


Bill Carpenter writes:
> This doesn't address other reasons for doing unambiguous lock
> discovery.  It leaves aside such rainy day scenarios as "oops, my
> application just crashed (et seq :-))" and "I guess I'll go home for
> the night and work on this".

When dealing with exclusive locks, the lack of owner information is more an
inconvenience than a   problem in the situations you mention. A client can
retrieve the lock token by performing lock discovery, and then assume it
belongs to that client.  The server will let the client know if this isn't
the case.  To prevent a user from doing too much work before they discover
the lock token doesn't belong to them, the application should pop up a
dialog letting the user know what happened, and then try to write a dummy
property using PROPPATCH (or some other simple, easy-to-undo write
operation), and see if the method succeeds.

> gmc> So a client should always get its own lock token, not appropriate
> gmc> an existing one.  If a resource is already exclusively locked, it
> gmc> first will need to UNLOCK the resource.  This then guarantees
> gmc> that if the other client (that issued the LOCK request) is still
> gmc> around, it will notice the "cancellation" by the failure of its
> gmc> next update request.
>
> This technique also opens a (probably very small) window wherein
> someone else could grab the lock.  (Such events are not always a
> matter of competition.  You could be under the impression that your
> co-author was going to release the LOCK when s/he was done and it was
> your turn.)

So, I'm not as opposed to grabbing an existing lock token as Geoff is.  If a
client does seize a lock token, the application should inform the user of
this.

- Jim



From w3c-dist-auth-request@w3.org  Tue Jan 25 19:05:55 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10463
	for <webdav-archive@odin.ietf.org>; Tue, 25 Jan 2000 19:05:53 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA00551;
	Tue, 25 Jan 2000 18:59:03 -0500 (EST)
Resent-Date: Tue, 25 Jan 2000 18:59:03 -0500 (EST)
Resent-Message-Id: <200001252359.SAA00551@www19.w3.org>
Date: Tue, 25 Jan 2000 18:58:54 -0500
Message-Id: <10001252358.AA28537@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <2271-Tue25Jan2000145857-0800-bill@carpenter.ORG>
Subject: Re: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3943
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


   From: bill@carpenter.ORG (WJCarpenter)

   gmc> The second issue is whether a client other than the lock
   gmc> requesting client should be able to use the lock token to get
   gmc> access to a resource.  Doing so would violate the whole design of
   gmc> the lock token scheme, which is to have a protocol for reliably
   gmc> deciding whether a *particular* client has the authority granted
   gmc> by the lock token.  The protocol only works if only the client
   gmc> that made the LOCK request uses the generated lock token.  The
   gmc> fact that the lock token was issued to a particular principal is
   gmc> irrelevant.

   This doesn't address other reasons for doing unambiguous lock
   discovery.  It leaves aside such rainy day scenarios as "oops, my
   application just crashed (et seq :-))" and "I guess I'll go home for
   the night and work on this".

If you are using shared locks, neither of these scenarios are
a problem: you just take out another shared lock and let the
orphan locks time out or be eventually cancelled by routine
lock administration.

If you are using exclusive locks, then your second client must first
UNLOCK (i.e. delete the lock from the first client).  If the first
client is still alive after all, this might leave it with changes that
must be "merged", but your client can (and should) make it clear to
you that you are taking that risk when you UNLOCK a resource you
didn't LOCK.

In either case, if you want to make sure that you are taking back
your own lock, and not somebody else's, then the DAV:owner element
should contain exactly the information the client needs to give
to the user in order for the user to decide whether to "cancel"
the lock.  Note that this can *never* be an automatic operation
based on "unambiguous" principal identification.  Just because the
second client has the same principal as the first provides no
guarantee that the first client is no longer alive and active.

   gmc> So a client should always get its own lock token, not appropriate
   gmc> an existing one.  If a resource is already exclusively locked, it
   gmc> first will need to UNLOCK the resource.  This then guarantees
   gmc> that if the other client (that issued the LOCK request) is still
   gmc> around, it will notice the "cancellation" by the failure of its
   gmc> next update request.

   This technique also opens a (probably very small) window wherein
   someone else could grab the lock.(Such events are not always a
   matter of competition.  

There are a variety of situations where you want to specify
relationships between a resource and a principal (or set of
principals), such as: "this principal is the only one that can lock
this resource".  But holding and maintaining a lock token is pointless
for this ...  this are relationships between a resource and a principal,
and passing around a (publically available) lock token is of no
relevance.

So I agree we want to be able to associate with a resource
the access rights for specific principals, but the lock tokens
are irrelevant for this association.

   You could be under the impression that your
   co-author was going to release the LOCK when s/he was done and it was
   your turn.)

I'm not sure what point this scenario illustrates, but I predict my
answer will be to look at the DAV:owner element of the lock (:-).

Cheers,
Geoff




From w3c-dist-auth-request@w3.org  Tue Jan 25 19:32:04 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11054
	for <webdav-archive@odin.ietf.org>; Tue, 25 Jan 2000 19:32:03 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id TAA01581;
	Tue, 25 Jan 2000 19:27:46 -0500 (EST)
Resent-Date: Tue, 25 Jan 2000 19:27:46 -0500 (EST)
Resent-Message-Id: <200001260027.TAA01581@www19.w3.org>
Date: Tue, 25 Jan 2000 19:27:36 -0500
Message-Id: <10001260027.AA28554@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <NDBBIKLAGLCOPGKGADOJGENICMAA.ejw@ics.uci.edu> (message from Jim
	Whitehead on Tue, 25 Jan 2000 15:34:20 -0800)
Subject: Re: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3944
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Ah, good, we've flushed out an author (:-).

   From: Jim Whitehead <ejw@ics.uci.edu>

   Bill Carpenter writes:
   > This doesn't address other reasons for doing unambiguous lock
   > discovery.  It leaves aside such rainy day scenarios as "oops, my
   > application just crashed (et seq :-))" and "I guess I'll go home for
   > the night and work on this".

   When dealing with exclusive locks, the lack of owner information is more an
   inconvenience than a   problem in the situations you mention. A client can
   retrieve the lock token by performing lock discovery, and then assume it
   belongs to that client.   The server will let the client know if this isn't
   the case.  To prevent a user from doing too much work before they discover
   the lock token doesn't belong to them, the application should pop up a
   dialog letting the user know what happened, and then try to write a dummy
   property using PROPPATCH (or some other simple, easy-to-undo write
   operation), and see if the method succeeds.

The whole point of having a lock token is so that you can handle the
case where multiple clients are active for a single principal.  If you
are going to encourage a clients to use a lock token it did not obtain
with a LOCK, the lock token is totally pointless, and should be
removed from the protocol.

   > gmc> So a client should always get its own lock token, not appropriate
   > gmc> an existing one.  If a resource is already exclusively locked, it
   > gmc> first will need to UNLOCK the resource.  This then guarantees
   > gmc> that if the other client (that issued the LOCK request) is still
   > gmc> around, it will notice the "cancellation" by the failure of its
   > gmc> next update request.
   >
   > This technique also opens a (probably very small) window wherein
   > someone else could grab the lock.  (Such events are not always a
   > matter of competition.  You could be under the impression that your
   > co-author was going to release the LOCK when s/he was done and it was
   > your turn.)

   So, I'm not as opposed to grabbing an existing lock token as Geoff is.  If a
   client does seize a lock token, the application should inform the user of
   this.

And would this message be something like "as your client, I decided
overwrite protection is not needed, so I'm just going to use some
other client's lock token"? (:-)

On the other hand, you can UNLOCK the resource and get your own lock,
ensuring that any still alive clients will know that this happened when
they next try to do an update.  The only benefit of the former approach
is that it removes a miniscule window for some other client to come in
and get a lock (where that client has just as much a right to author that
resource as you do).  Seems like you are throwing away the only value
of token based locking in return for a very unlikely and even arguably
"unfair" benefit.

I still may be missing something, but I still don't think so (:-).

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Wed Jan 26 17:34:57 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12760
	for <webdav-archive@odin.ietf.org>; Wed, 26 Jan 2000 17:34:51 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id RAA07654;
	Wed, 26 Jan 2000 17:23:16 -0500 (EST)
Resent-Date: Wed, 26 Jan 2000 17:23:16 -0500 (EST)
Resent-Message-Id: <200001262223.RAA07654@www19.w3.org>
Date: Wed, 26 Jan 2000 14:26:08 -0800
From: David Engberg <dave.engberg@driveway.com>
To: w3c-dist-auth@w3.org
Message-ID: <4003963124.948896768@engberg-nt.pacbell.net>
X-Mailer: Mulberry (Win32) [2.0.0b7, s/n U-300925]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: WebDAV proxy problems
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3945
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

I have heard many reports that some proxy servers prevent WebDAV to public 
servers (driveway.com, sharemation, etc.), at least using Microsoft's 
WebFolders.

Does anyone have any more information on this?  (Fixes, lists of 'bad' 
proxy servers, etc?)





From w3c-dist-auth-request@w3.org  Wed Jan 26 18:05:10 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13041
	for <webdav-archive@odin.ietf.org>; Wed, 26 Jan 2000 18:05:08 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA08819;
	Wed, 26 Jan 2000 18:00:45 -0500 (EST)
Resent-Date: Wed, 26 Jan 2000 18:00:45 -0500 (EST)
Resent-Message-Id: <200001262300.SAA08819@www19.w3.org>
From: jamsden@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <85256872.007D6E9A.00@d54mta03.raleigh.ibm.com>
Date: Wed, 26 Jan 2000 17:49:04 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: locking GULP 2
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3946
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list



Geoff,
Just a couple of comments, I'm trying to catch up from a lot of travel.
- a lock must be an 8 tuple and include the principal (authentication id)
who owns the lock.
- under "A resource can be locked by multiple locks concurrently", the
first sentence should read A resource..., not a lock...
- under "One or more resources may be locked with a lock request", last
paragraph: unfortunately the owner element of a lock is not the principal
owning the lock but rather some arbitrary string describing the owner of
the lock like a phone number or email address, etc. That's why we need
another field for the principal. Otherwise client applications must persist
their lock tokens somewhere else as there's no way to retrieve them from
the server for a given user.
- say you have a lock on a resource which translates to a lock on its
segment binding in its parent collection (the one used to request the
lock), and the resource itself. Now you move the resource to some other
collection. This removes the lock from the binding in the collection, but
not the lock on the resource itself? If so, could one expect that a new
lock would be added to destination binding so that the overall state of the
system is the same? The user started out with a protected resource and URL.
After the move, one would expect the same level of protection?




"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>@w3.org on 01/14/2000
01:11:54 AM

Sent by:  w3c-dist-auth-request@w3.org


To:   w3c-dist-auth@w3.org
cc:

Subject:  GULP, version 2


Here is a second version of the GULP.  I've updated the descriptive
text based on the feedback from Jason, Jim, and Eric (not that I've
successfully addressed their issues, but it was based on it :-).
Jason: I'm now using "target" instead of "name" ... let me know if
you think that works better.

The only semantic change has been the deletion of Depth:N behavior,
for N other than 0 and infinity (this brings it more in line with 2518).

I need some more examples, and I still need to address the use cases
raised by Eric and Jason ...  I believe they are handled properly by
the proposal, but I probably should get some sleep first before
working them through (:-).

Cheers,
Geoff


**************************

GULP: Part I

- A URL is a string that can identify a resource.

- A collection is a resource that contains a set of named members.

- A lock is 7-tuple, consisting of a target, token, type, scope,
depth, timeout, and owner.

- Locking a resource means to add a lock to the state of that
resource.

- Unlocking a resource means to remove a lock from the state of that
resource.

- A lock will cause certain requests to fail with a 423 (Locked)
status code, where that request would have succeeded if the lock had
not been present.

- A resource can be locked by multiple locks concurrently.

- One or more resources can be locked with a LOCK request.

- Locking a collection can lock one or more members of that
collection.

- Adding a resource to a locked collectin can lock that resource.

- One or more resources can be unlocked with an UNLOCK request.

- Unlocking a collection can unlock one or more members of that
collection.

- Removing a resource from a locked collection can unlock that resource.

- The depth of a lock can be a 0 or infinity.  If a collection has a
depth infinity lock, all members of that collection are also locked.

- If a member is added to a depth:infinity locked collection, that
member is locked by that depth:infinity lock.

- A lock protects which resource is identified by that lock.

- If a resource has an exclusive lock, that resource cannot be locked
with another lock with the same type and target but a different token.

- If a resource has a write lock with target ".", the body and
properties of that resource are protected from unauthorized
modification.


**************************

GULP: Part II


- A URL is a string that can identify a resource.

A server initially defines what resource (if any) is identified by a
URL.  Most URL's do not identify a resource, but a client can cause
a URL to identify a resource, and later change which resource is
identified by that URL.

Examples of methods that can cause a URL to identify a resource (or
change the resource identified by a URL) are PUT, MKRESOURCE, MKCOL,
BIND, MOVE, and COPY.  Examples of methods that can cause a URL to no
longer identify a resource are DELETE and MOVE.


- A lock is 7-tuple, consisting of a target, token, type, scope, depth,
timeout, and owner.

The "target" is an extension to locks as defined in rfc2518.  This new
field is defined to distinguish the implicit locks on the state of a
collection implied by the locking semantics of rfc2518, from the
explicit locks that are defined by rfc2518.  The explicit locks in
rfc2518 correspond to locks with target "." in this proposal.

Since all locks with the same token will share the same type, scope,
depth, timeout, and owner, a lock will be represented in this proposal
as a string of the form "[target, token]".

For example, ["x/.", "K"] defines a lock with target "x/." and token "K".


- A collection is a resource that contains a set of named members.

A collection contains a set of bindings, where a binding is a mapping
from a URL segment to a resource.  If a URL identifies a collection,
that URL extended by the URL segment will identify the bound resource.

For example, If "/path" identifies a collection C, and C contains a
binding that binds the segment "x" to resource R, then the URL
"/path/x" identifies resource R.


- Locking a resource means to add a lock to the state of that
resource.

The lock is added to the DAV:lockdiscovery property of the resource.


- Unlocking a resource means to remove a lock from the state of that
resource.

The lock is deleted from the DAV:lockdiscovery property of the
resource.


- A lock will cause certain requests to fail with a 423 (Locked)
status code, where that request would have succeeded if the lock had
not been present.

Whether a particular request will fail can depends on the
target, token, type, scope, and owner of the lock.


- A resource can be locked by multiple locks concurrently.

A lock can be locked by multiple locks with different values or
multiple identical locks.  Some lock combinations will be disallowed
based on information such as the the scope of the lock.


- One or more resources can be locked with a LOCK request.

When a LOCK request succeeds, a lock is added to the resource
identified by shortest sequence of initial segments of the request URL
that identifies a WebDAV resource.

The lock target is the relative URL formed by using standard URL
transformations to remove all segments of the request-URL named "." or
"..", then removing the prefix that identifies the locked resource,
and then appending a segment named ".".

For example, if "LOCK /seg1/seg2/seg3/.../segN" succeeds, and if
/seg1 does not identify a WebDAV resource but /seg1/seg2 does,
then a lock with target "seg3/.../segN/." is added to the resource
identified by "/seg1/seg2".

The type and scope, and owner of the lock is specified in the LOCK
request body.  The depth and timeout of the lock is specified in the
LOCK request headers.  The token of the lock is a unique string
allocated for that LOCK request by the server.

The principal that issued the LOCK request is called the "owner" of
the lock.


- Locking a collection can lock one or more members of that collection.

If a collection C has a binding from "segX" to resource R, and a
request adds a ["segX/pathZ", "K"] lock to C, then the request adds a
["pathZ", "K"] lock to R.


- Adding a resource to a locked collectin can lock that resource.

If a collection C has a ["segX/pathZ", "K"] lock, and a request adds a
binding in C from "segX" to resource R, then the request adds a
["pathZ", "K"] lock to R. If the attempt to add this lock to R fails,
the request MUST fail.


- One or more resources can be unlocked with an UNLOCK request.

When a request of the form "UNLOCK /pathX; Lock-Token K" succeeds,
then all locks with token "K" are removed.


- Unlocking a collection can unlock one or more members of that
collection.

If a collection C has a binding from "segX" to resource R, and a
request removes a ["segX/pathZ", "K"] lock from C, then the request
removes a ["pathZ", "K"] lock from R.


- Removing a resource from a locked collection can unlock that resource.

If a collection has a ["segX/pathZ", "K"] lock, and a request removes
a binding in C from "segX" to resource R, then a ["pathZ", "K"] lock
is removed from R.


- The depth of a lock can be a 0 or infinity.  If a collection has a
depth infinity lock, all members of that collection are also locked.

If a collection C has a binding to resource R, and a request adds a
Depth:infinity [".", "K"] lock to C, and this is the first [".", "K"]
lock on C, then the request adds a [".", "K"] lock to R.  Conversely,
if a collection C has a binding to resource R, and a request removes
the last Depth:infinity [".", "K"] lock from C, then the request
removes a [".", "K"] lock from R.

Note that multiple Depth:infinity locks with target "." and with the
same token can be placed on the same resource due to multiple bindings
to that resource in a Depth:infinity locked collection.  Only the
first such lock on a particular collection adds locks to the members
of that collection to avoid generating an infinite number of locks for
cyclic bindings.


- If a member is added to a depth:infinity locked collection, that
member is locked by that depth:infinity lock.

If a collection C has a Depth:infinity [".", "K"] lock, and a request
adds a binding in C to resource R, then the request adds a [".","K"]
lock to R. If the attempt to add this lock to R fails, the request
MUST fail.  Conversely, if a collection has a Depth:infinity [".",
"K"] lock, and a request removes a binding in C to resource R, then a
[".", "K"] lock removed from R.


- A lock protects which resource is identified by that lock.

More precisely, if a collection has a ["X/....", "K"] lock, a request
cannot delete the member named X from that collection unless the
principal of the request owns all locks with target "X/..." and the
tokens of all those locks are specified in an IF header.


- If a resource has an exclusive lock, that resource cannot be locked
with another locks with the same type and target but a different
token.

If a request attempts to add a type T ["pathZ", "K"] lock to resource
R, and R already has an exclusive lock with target "pathZ" and type T
but with a different token, the request MUST fail. Similarly, if a
request attempts to add an exclusive type T ["pathZ", "K"] lock to
resource R, and R already has a lock with target "pathZ" and type T
but with a different token, the request MUST fail.


- If a resource has a write lock with target ".", the body and
properties of that resource are protected from unauthorized
modification.

If a resource has a write lock with target ".", a request cannot
modify the body or dead properties of that resource unless the
principal of the request owns a write lock with target "." on that
resource and the token of that write lock is specified in an IF
header.


**************************






From w3c-dist-auth-request@w3.org  Wed Jan 26 18:05:43 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13052
	for <webdav-archive@odin.ietf.org>; Wed, 26 Jan 2000 18:05:32 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA08887;
	Wed, 26 Jan 2000 18:01:14 -0500 (EST)
Resent-Date: Wed, 26 Jan 2000 18:01:14 -0500 (EST)
Resent-Message-Id: <200001262301.SAA08887@www19.w3.org>
From: jamsden@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <85256872.007D6AC7.00@d54mta03.raleigh.ibm.com>
Date: Wed, 26 Jan 2000 12:42:33 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3947
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list



But Geoff, the semantics you describe below would make locks useless (maybe
your intent?!). If only the lock token was used to protect from overwrite
conflicts, then any user could just do a PROPFIND, get the lock token from
the DAV:lockdiscovery element, and then have at the resource! The spec
indicates that the user agent owning the lock, the one taking out the lock
in the LOCK request, must be specified along with the lock token. It does
not however say exactly what the user agent is. That's because ACLs weren't
done yet, and the working group didn't want to define principal. So they
just punted and left if up to the server implementation with
server-specific ACL mechanisms until the ACL spec was done. This is why the
principal element wasn't included in the DAV:activelock element. However, I
think we've made enough progress in defining ACLs and principals that we
can now safely include this information in DAV:activelock in which case all
problems are resolved.





"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>@w3.org on 01/25/2000
04:24:54 PM

Sent by:  w3c-dist-auth-request@w3.org


To:   w3c-dist-auth@w3.org
cc:

Subject:  Re: RFC-2518 LOCK-TOKEN: header


   From: bill@carpenter.ORG (WJCarpenter)

   gmc> Section 6.3 of RFC-2518 states that you can get the lock token
   gmc> through the lock discovery property:

   Yeah, that's what I was thinking (especially as the lock discovery
   property is the prescribed payload returned after a successful LOCK
   request).  But Jim Amsden is right that that's not sufficient.
   ...  The DAV:owner
   property is just so much commentary by the LOCK requester.  It
   explicitly has no bearing on the out-of-band authentication.  In
   short, it can be a complete lie or completely irrelevant.  I think the
   idea of DAV:owner was for human consumption, in case you want to track
   down the LOCK owner and beat him/her with a stick until s/he releases
   the LOCK.  It is by design not at all helpful to the server in
   deciding whether the principal attempting a change is the LOCK holder
   or not.

There seem to be two issues here.  The first is whether a server
should authenticate that the principal specifying the lock token in an
IF header is the same principal that created the lock token in a lock
request.  This is not required by WebDAV, since it is pretty pointless
to carefully guard a lock token when as soon as you UNLOCK the
resource, anyone can come in and trash the resource.  Lock tokens are
for avoiding merges, not for security.

So if you want interoperable security, you should become active in the
WebDAV ACL's effort.  If you try to get it from WebDAV locking and
lock tokens, you will be doomed to disappointment.  But that's not
because WebDAV locking is broken (it in fact does a great job
of avoiding merges), but rather that it doesn't do what it wasn't
designed to do.

The second issue is whether a client other than the lock requesting
client should be able to use the lock token to get access to a
resource.  Doing so would violate the whole design of the lock token
scheme, which is to have a protocol for reliably deciding whether a
*particular* client has the authority granted by the lock token.  The
protocol only works if only the client that made the LOCK request uses
the generated lock token.  The fact that the lock token was issued to
a particular principal is irrelevant.

So a client should always get its own lock token, not appropriate
an existing one.  If a resource is already exclusively locked,
it first will need to UNLOCK the resource.  This then guarantees
that if the other client (that issued the LOCK request) is still
around, it will notice the "cancellation" by the failure of its next
update request.

   For exclusive LOCKs, you can assume from the lock discovery part of a
   successful response that you got the applicable token mentioned.  For
   shared LOCKs, you need the LOCK-TOKEN: header or some additional goop
   in lock discovery conveying "authenticated" ownership.

There is even less point in authenticating shared lock ownership
(which I guess makes it a negative number, since I argue above
that there is no point in authenticating exclusive lock ownership :-).
If you are a principal that has the right to take out a shared
lock, you can just get one - you don't need to use some existing shared
lock.

   For the
   problem you mention, of multiple clients being run by the same
   principal, there is no sanctioned, unambiguous way to do lock
   discovery.

There is a sanctioned unambiguous way to do lock discovery ... there
just is (by design) no sanctioned way to do lock appropriation (:-).

Cheers,
Geoff

P.S. I may be all wrong about this, since my livelihood is versioning,
not locking, but I don't think so (:-).






From w3c-dist-auth-request@w3.org  Wed Jan 26 18:05:47 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13054
	for <webdav-archive@odin.ietf.org>; Wed, 26 Jan 2000 18:05:41 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA08929;
	Wed, 26 Jan 2000 18:01:22 -0500 (EST)
Resent-Date: Wed, 26 Jan 2000 18:01:22 -0500 (EST)
Resent-Message-Id: <200001262301.SAA08929@www19.w3.org>
From: jamsden@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <85256872.007D67D9.00@d54mta03.raleigh.ibm.com>
Date: Wed, 26 Jan 2000 12:33:34 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3948
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list



Geoff,
Some corrections and comments below in <jra> tags, but in summary, the
owner element is not sufficient to identify the owner of a lock, and is not
used by the server in any way. It is purely a mechanism for clients to
provide some more meaningful indication of the owner of a lock.

The authentication mechanisms are not specified by HTTP (although WebDAV
does specify Digest and Basic for secured connections), but the
authentication header is used by WebDAV to identify the user agent making
the request, and it is this header that is used to determine if the
requestor is the owner of the lock. The lock discovery element does not
contain this information.




"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>@w3.org on 01/25/2000
01:10:24 PM

Sent by:  w3c-dist-auth-request@w3.org


To:   w3c-dist-auth@w3.org
cc:

Subject:  Re: RFC-2518 LOCK-TOKEN: header


   From: jamsden@us.ibm.com

   If the lock token isn't returned in the header, there's no way for you
to
   get the lock token of the lock you just created.

Section 6.3 of RFC-2518 states that you can get the lock token
through the lock discovery property:

"A lock token is a type of state token, represented as a URI, which
identifies a particular lock.  A lock token ... can also be found
through lock discovery on a resource."
<jra>
Yes, but you can't figure out which ones are yours.
</jra>

   That's because the active
   lock element of the lock discovery property does not contain the
   authentication id of the principal owning the lock.

I can find no authentication id defined or required by RFC-2518.

In fact, RFC-2518  explicitly states that an authentication id is not
part of the WebDAV protocol:

"Locks MUST be enforced based upon whatever authentication mechanism
is used by the server, not based on the secrecy of the token values."

and:

"User agent authentication has previously occurred via a mechanism
outside the scope of the HTTP protocol, in an underlying transport
layer."
<jra>
Its this user agent, identified by the authentication header, that is used
to actually enforce locks. As far as the server is concerned, the lock
token just goes on for the ride. It has to be specified, and the user agent
has to own the lock, but otherwise the lock token isn't used.
</jra>

   The lock tokens are in
   the lock discovery, but you can't figure out which ones you own.

This information is provided by the DAV:owner element in the
lockdiscovery property.
<jra>
This is not the owner information used by the server to identify the owner
of the lock. Rather it is client information used to provide a more
meaningful indication of the owner of the lock for contact information. Use
of this element for identifing lock ownership would create an
interoperability problem because the actual contents are not specified in
the WebDAV spec.
</jra>

   I continue to believe this is an open issue that requires clients to
   persist their lock  tokens outside the WebDAV repository. Lock tokens
are a
   pain enough for the rare case where they are actually useful.

How else do you handle the situation where the same principal has
several clients acting against the same resource?  I believe this will
be a common scenario.
<jra>
Yes, and lock tokens will be marginally useful for this situation. The only
thing that can be done is a client can know if it got the lock from a LOCK
request, or by some other means (IPC, reading from a file, from the
DAV:lockdiscovery element, etc.). A client obtaining the lock from some
other means can only assume that there might be other clients operating
concurrently under the same principal, and can offer a warning before
overwriting the resource.
</jra>

Cheers,
Geoff






From w3c-dist-auth-request@w3.org  Wed Jan 26 18:24:06 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13179
	for <webdav-archive@odin.ietf.org>; Wed, 26 Jan 2000 18:24:04 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA09425;
	Wed, 26 Jan 2000 18:19:58 -0500 (EST)
Resent-Date: Wed, 26 Jan 2000 18:19:58 -0500 (EST)
Resent-Message-Id: <200001262319.SAA09425@www19.w3.org>
Message-ID: <0C5DFAE09D2A644D97C4830DFA90F02202D5EA@df-rocket.platinum.corp.microsoft.com>
From: "Lisa Lippert (Dusseault)" <lisal@Exchange.Microsoft.com>
To: "'David Engberg'" <dave.engberg@driveway.com>, w3c-dist-auth@w3.org
Date: Wed, 26 Jan 2000 14:53:20 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: RE: WebDAV proxy problems
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3949
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

I actually started collecting some information on this.  Since I don't have
testing resources for it, it's only hearsay, but here goes:

Known Proxies that support DAV

 - MS Proxy 2.0: Support for DAV is built-in to MS Proxy 2.0.
 - Squid: There is a patch for the Squid proxy server that adds support for
WebDAV (http://www.squid-cache.org/Versions/v2/2.2/bugs/).

Known Proxies that do not support DAV

 - Gauntlet
 - Inktomi's Traffic-Server
 - Netscape proxy server 
 - Network Application's NetCache.  Some ISPs have made changes to their
configuration of NetCache to bypass known DAV servers - e.g. the Hotmail
servers.  However, this fix won't support all DAV servers, just a fixed list
of known servers.

Note that the workaround for known servers on NetCache may well work on
other servers as well, with the same drawbacks.

Lisa

-----Original Message-----
From: David Engberg [mailto:dave.engberg@driveway.com]
Sent: Wednesday, January 26, 2000 2:26 PM
To: w3c-dist-auth@w3.org
Subject: WebDAV proxy problems


I have heard many reports that some proxy servers prevent WebDAV to public 
servers (driveway.com, sharemation, etc.), at least using Microsoft's 
WebFolders.

Does anyone have any more information on this?  (Fixes, lists of 'bad' 
proxy servers, etc?)



From w3c-dist-auth-request@w3.org  Wed Jan 26 22:40:09 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17407
	for <webdav-archive@odin.ietf.org>; Wed, 26 Jan 2000 22:40:01 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id WAA16965;
	Wed, 26 Jan 2000 22:35:39 -0500 (EST)
Resent-Date: Wed, 26 Jan 2000 22:35:39 -0500 (EST)
Resent-Message-Id: <200001270335.WAA16965@www19.w3.org>
Date: Wed, 26 Jan 2000 22:35:29 -0500
Message-Id: <10001270335.AA29093@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <85256872.007D6E9A.00@d54mta03.raleigh.ibm.com>
	(jamsden@us.ibm.com)
Subject: Re: locking GULP 2
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3950
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

   From: jamsden@us.ibm.com

   Just a couple of comments, I'm trying to catch up from a lot of travel.
   - a lock must be an 8 tuple and include the principal (authentication id)
   who owns the lock.

Where do you find this definition in rfc2518?  The activitelock element
is defined as a 3 to 6 tuple:

   <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
   locktoken?) >

I have found no occurrence of the term "authentication id" in rfc2518.

   - under "A resource can be locked by multiple locks concurrently", the
   first sentence should read A resource..., not a lock...

Yup (this is fixed in GULP-3).

   - under "One or more resources may be locked with a lock request", last
   paragraph: unfortunately the owner element of a lock is not the principal
   owning the lock but rather some arbitrary string describing the owner of
   the lock like a phone number or email address, etc. That's why we need
   another field for the principal. Otherwise client applications must persist
   their lock tokens somewhere else as there's no way to retrieve them from
   the server for a given user.

If you are authenticating against the principal issuing a request,
there is no point in maintaining or requiring a lock token.  If you
are using a lock token to avoid merging between cooperating clients,
then you don't need to authenticate against a principal.  In either
case, there is no point in authenticating the use of a lock token.

And even if there would be a point, it is not specified in rfc2518,
so this would be protocol extension, not protocol compliance.

   - say you have a lock on a resource which translates to a lock on its
   segment binding in its parent collection (the one used to request the
   lock), and the resource itself.

Actually, it produces a lock on all the WebDAV collections named by
segments of the request-URL of the LOCK.

   Now you move the resource to some other
   collection. This removes the lock from the binding in the collection, but
   not the lock on the resource itself?

When you issue a move, the locks are recomputed.  In particular,
(in GULP-3) the rule is:

R5: If a collection C has a lock with token "K" and a request adds
or removes a member from C, all locks with token "K" are removed except for
those that would result from re-executing the LOCK command that
created the token "K" locks.   If any of these locks cannot be added,
the request MUST fail.

   If so, could one expect that a new
   lock would be added to destination binding so that the overall state of the
   system is the same?

In GULP, the lock is logically on the request-URL of the LOCK
request, not on any particular resource.  This logical lock is
reflected in the state of the appropriate resources, so following
a MOVE, the original LOCK request continues to be in effect on the
specified URL.

   The user started out with a protected resource and URL.
   After the move, one would expect the same level of protection?

In GULP, the user started out with a protected URL, and that is the
URL that remains protected following the MOVE.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Wed Jan 26 23:46:30 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18182
	for <webdav-archive@odin.ietf.org>; Wed, 26 Jan 2000 23:43:59 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id XAA20973;
	Wed, 26 Jan 2000 23:39:46 -0500 (EST)
Resent-Date: Wed, 26 Jan 2000 23:39:46 -0500 (EST)
Resent-Message-Id: <200001270439.XAA20973@www19.w3.org>
Date: Wed, 26 Jan 2000 23:39:26 -0500
Message-Id: <10001270439.AA29116@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <85256872.007D6AC7.00@d54mta03.raleigh.ibm.com>
	(jamsden@us.ibm.com)
Subject: Re: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3951
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


   From: jamsden@us.ibm.com

   But Geoff, the semantics you describe below would make locks useless (maybe
   your intent?!).

I believe locks are very useful for avoiding merge conflicts between
cooperating clients.  By "cooperating clients", I mean clients that
whenever they want to update a resource:

 - get an exclusive lock on the resource (LOCK)
 - get the body/properties of the resource (GET, PROPFIND)
 - update the body/properties of the resource (PUT, PROPPATCH)
 - unlock the resource (UNLOCK)

If a locking unaware client tries to update the resource, the locking
protocol prevents the update while the resource is locked, but has no
way of preventing the locking unaware client from getting the state of
the resource before or during the lock, and then unknowingly
overwriting updates from a locking client because it issues its update
after the locking client performed an UNLOCK.

This point is made in section 6.7 of rfc2518.

Now if rfc2518 stopped there, we'd be fine.  But unfortunately, it
doesn't, but tries to present locks as also providing authenticated
access control (e.g. "the right to update a resource").  The reason
this is unfortunate is that "merge avoidance between cooperating
clients" and "authenticated access control" require radically
different support and semantics.

In particular, for merge avoidance, a lock token is required, and
which principal is issuing the request is irrelevant.  On the other
hand, for authenticated access control, the principal is required, and
a "lock-token" is irrelevant.  Thus all the confusion in the working
group about when/where a principal is required and when/where a lock
token is required.

Furthermore, for merge avoidance, you want to protect the URL, because
the URL is what the client is holding as the "key" to identify the
resource being authored.  On the other hand, for authenticated access
control, it is the *resource* that is being controlled, not the URL.
Thus all the confusion in the working group about whether a resource
is being protected or whether a URL is being protected.

So whatever was intended by WebDAV locks, the protocol that is
specified in rfc2518 does a fine job of preventing merge conflicts
for cooperating clients, and is totally inadequate for providing
authenticated access control.  So I propose that anyone that cares
about authenticated access control become active in the WebDAV ACL
specification effort, and just use WebDAV locks for what they can
do, namely prevent merge conflicts for cooperating clients.

   If only the lock token was used to protect from overwrite
   conflicts, then any user could just do a PROPFIND, get the lock token from
   the DAV:lockdiscovery element, and then have at the resource!

Exactly.  Which is precisely what that user can do as soon as you UNLOCK
the resource.  If you intend on keeping the resource permanently
"writable only by a certain principal" (i.e. never issuing an UNLOCK),
then requiring a lock token is pointless, since it is the principal
that matters, and the lock token is irrelevant.  Furthermore, it is
the resource you want to control, and that control should survive
a MOVE, unlike a LOCK.

   The spec
   indicates that the user agent owning the lock, the one taking out the lock
   in the LOCK request, must be specified along with the lock token.

I see no protocol header or XML element in rfc2518 for this purpose.
As you've pointed out, the DAV:owner element does not provide this,
and as you have also pointed out, saying that something should be the
case without providing protocol elements for doing so is useless.

   It does
   not however say exactly what the user agent is. That's because ACLs weren't
   done yet, and the working group didn't want to define principal. So they
   just punted and left if up to the server implementation with
   server-specific ACL mechanisms until the ACL spec was done. This is why the
   principal element wasn't included in the DAV:activelock element. However, I
   think we've made enough progress in defining ACLs and principals that we
   can now safely include this information in DAV:activelock in which case all
   problems are resolved.

I've been basing my statements on what is in rfc2518, not on some
ACL functionality that might (and hopefully will!) appear in some
successor to rfc2518.

But I believe the ACL functionality should be orthogonal to the
locking functionality, and in particular, the ACL's should have no
notion of an "ACL token that must be included in an IF header", nor
should an ACL on a resource imply any "protection" of any URL to that
resource.  When this is done, I expect to see a DAV:acl-discovery
element defined, and with appropriate DAV:principal sub-elements.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Thu Jan 27 00:01:47 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18355
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 00:01:47 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id XAA22400;
	Wed, 26 Jan 2000 23:57:38 -0500 (EST)
Resent-Date: Wed, 26 Jan 2000 23:57:38 -0500 (EST)
Resent-Message-Id: <200001270457.XAA22400@www19.w3.org>
Date: Wed, 26 Jan 2000 23:57:22 -0500
Message-Id: <10001270457.AA29129@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <85256872.007D67D9.00@d54mta03.raleigh.ibm.com>
	(jamsden@us.ibm.com)
Subject: Re: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3952
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


   From: jamsden@us.ibm.com

   Some corrections and comments below in <jra> tags, but in summary, the
   owner element is not sufficient to identify the owner of a lock,

It is sufficient if it is just information that a client wants to
present to the user to help her decide whether she wants to cancel
(UNLOCK) an existing lock.

   and is not used by the server in any way.

I agree.

   It is purely a mechanism for clients to
   provide some more meaningful indication of the owner of a lock.

I agree.

   The authentication mechanisms are not specified by HTTP (although WebDAV
   does specify Digest and Basic for secured connections), but the
   authentication header is used by WebDAV to identify the user agent making
   the request, and it is this header that is used to determine if the
   requestor is the owner of the lock.

I have found no reference to an "authentication header" in rfc2518,
neither in terms of defining it, nor in terms of using it.

I have made this point in several postings ... and will continue
to do so until acknowledged or refuted (:-).

   The lock discovery element does not contain this information.

Which should come as no surprise, since the authentication header
is not defined (:-).

   "A lock token is a type of state token, represented as a URI, which
   identifies a particular lock.  A lock token ... can also be found
   through lock discovery on a resource."

   <jra>
   Yes, but you can't figure out which ones are yours.
   </jra>

For the purposes of the user deciding whether to cancel an
existing lock, the DAV:owner information should be sufficient.

   "User agent authentication has previously occurred via a mechanism
   outside the scope of the HTTP protocol, in an underlying transport
   layer."

   <jra>
   Its this user agent, identified by the authentication header, that is used
   to actually enforce locks. As far as the server is concerned, the lock
   token just goes on for the ride. It has to be specified, and the user agent
   has to own the lock, but otherwise the lock token isn't used.
   </jra>

Yes, for authenticated access control, a lock token is pointless -
one indication that the WebDAV locks are not the appropriate protocol
mechanism to support authenticated access control.

      The lock tokens are in
      the lock discovery, but you can't figure out which ones you own.

   This information is provided by the DAV:owner element in the
   lockdiscovery property.

   <jra>
   This is not the owner information used by the server to identify the owner
   of the lock. Rather it is client information used to provide a more
   meaningful indication of the owner of the lock for contact information. Use
   of this element for identifing lock ownership would create an
   interoperability problem because the actual contents are not specified in
   the WebDAV spec.
   </jra>

As long as this information is just presented to the user, there is
no need for detailing the actual contents.

      I continue to believe this is an open issue that requires clients to
      persist their lock  tokens outside the WebDAV repository. Lock tokens
   are a
      pain enough for the rare case where they are actually useful.

   How else do you handle the situation where the same principal has
   several clients acting against the same resource?  I believe this will
   be a common scenario.

   <jra>
   Yes, and lock tokens will be marginally useful for this situation. The only
   thing that can be done is a client can know if it got the lock from a LOCK
   request, or by some other means (IPC, reading from a file, from the
   DAV:lockdiscovery element, etc.). A client obtaining the lock from some
   other means can only assume that there might be other clients operating
   concurrently under the same principal, and can offer a warning before
   overwriting the resource.
   </jra>

A lock-token is not used by a client because it discovers it on a
resource ... it is only used if that client obtained that lock-token
through a LOCK request.  This guarantees that you will not have a
merge conflict amoung cooperating clients, which makes it very useful.
A client that wants to "steal" a lock, does so by unlocking the resource
and then requesting its own lock with a new LOCK request.

You could require that only the principal issuing a LOCK can "steal"
the lock, but this should be a client-controlled ACL issue, *not*
something hard-wired into the protocol.

Cheers,
Geoff





From w3c-dist-auth-request@w3.org  Thu Jan 27 04:38:26 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01930
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 04:38:26 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id EAA28308;
	Thu, 27 Jan 2000 04:34:04 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 04:34:04 -0500 (EST)
Resent-Message-Id: <200001270934.EAA28308@www19.w3.org>
Date: Thu, 27 Jan 2000 01:33:53 -0800 (PST)
From: Greg Stein <gstein@lyra.org>
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
cc: w3c-dist-auth@w3.org
In-Reply-To: <10001270457.AA29129@tantalum>
Message-ID: <Pine.LNX.4.10.10001270128440.8827-100000@nebula.lyra.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3953
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

On Wed, 26 Jan 2000, Geoffrey M. Clemm wrote:
>...
>    The authentication mechanisms are not specified by HTTP (although WebDAV
>    does specify Digest and Basic for secured connections), but the
>    authentication header is used by WebDAV to identify the user agent making
>    the request, and it is this header that is used to determine if the
>    requestor is the owner of the lock.
> 
> I have found no reference to an "authentication header" in rfc2518,
> neither in terms of defining it, nor in terms of using it.
> 
> I have made this point in several postings ... and will continue
> to do so until acknowledged or refuted (:-).

Section 6.3, last paragraph. It mentions that the use of the lock token
must also be enforced through the server's authentication mechanism.

That mechanism may or may not be a header, but the RFC is quite clear (in
my mind) that simply holding a token is not enough. You must have the
token and you must have the same authentication as that used when the lock
was created. Given these two pieces of state, you are allowed to operate
on the target resource.

> For the purposes of the user deciding whether to cancel an
> existing lock, the DAV:owner information should be sufficient.

Many clients may not set that field. I don't think that you can
necessarily depend upon it. But: I tend to agree that there is nothing
better, and that field *is* intended for human consumption (and,
therefore, for asking whether a lock should be cancelled).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From w3c-dist-auth-request@w3.org  Thu Jan 27 08:20:32 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04725
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 08:20:30 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id IAA02262;
	Thu, 27 Jan 2000 08:15:54 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 08:15:54 -0500 (EST)
Resent-Message-Id: <200001271315.IAA02262@www19.w3.org>
Date: Thu, 27 Jan 2000 13:10:22 +0000
From: Joe Orton <joe@orton.demon.co.uk>
To: "Lisa Lippert (Dusseault)" <lisal@Exchange.Microsoft.com>
Cc: "'David Engberg'" <dave.engberg@driveway.com>, w3c-dist-auth@w3.org
Message-ID: <20000127131022.A28607@york.ac.uk>
Mail-Followup-To: "Lisa Lippert (Dusseault)" <lisal@Exchange.Microsoft.com>,
	'David Engberg' <dave.engberg@driveway.com>, w3c-dist-auth@w3.org
References: <0C5DFAE09D2A644D97C4830DFA90F02202D5EA@df-rocket.platinum.corp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <0C5DFAE09D2A644D97C4830DFA90F02202D5EA@df-rocket.platinum.corp.microsoft.com>; from lisal@Exchange.Microsoft.com on Wed, Jan 26, 2000 at 02:53:20PM -0800
Subject: Re: WebDAV proxy problems
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3954
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

> I actually started collecting some information on this.  Since I don't have
> testing resources for it, it's only hearsay, but here goes:
> 
> Known Proxies that support DAV
> 
>  - MS Proxy 2.0: Support for DAV is built-in to MS Proxy 2.0.
>  - Squid: There is a patch for the Squid proxy server that adds support for
> WebDAV (http://www.squid-cache.org/Versions/v2/2.2/bugs/).

Apache mod_proxy works fine too. IIRC Squid 2.3 will pass through the
methods defined in 2518, but will still block methods it doesn't
understand. 

joe



From w3c-dist-auth-request@w3.org  Thu Jan 27 08:43:32 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05294
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 08:43:31 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id IAA02832;
	Thu, 27 Jan 2000 08:38:32 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 08:38:32 -0500 (EST)
Resent-Message-Id: <200001271338.IAA02832@www19.w3.org>
Date: Thu, 27 Jan 2000 08:38:23 -0500
Message-Id: <10001271338.AA29281@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <Pine.LNX.4.10.10001270128440.8827-100000@nebula.lyra.org>
	(message from Greg Stein on Thu, 27 Jan 2000 01:33:53 -0800 (PST))
Subject: Re: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3955
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

   From: Greg Stein <gstein@lyra.org>

   > I have found no reference to an "authentication header" in rfc2518,
   > neither in terms of defining it, nor in terms of using it.

   Section 6.3, last paragraph. It mentions that the use of the lock token
   must also be enforced through the server's authentication mechanism.

Yes, authentication is mentioned in various places in the protocol,
but there is no mention of an "authentication header" (neither a
definition of its value nor how it is to be used).

   That mechanism may or may not be a header, but the RFC is quite clear (in
   my mind) that simply holding a token is not enough. You must have the
   token and you must have the same authentication as that used when the lock
   was created.

I agree that this is made stated in the protocol, but this is of
limited value to a client since no interoperable mechanism for doing
so is specified.  In addition, no authentication is required if no
authentication was performed when the lock was created, so a client
cannot count on any authentication taking place.

There are different to address this current problem in the protocol.
One would be to beef up the authentication associated with locks.  I
believe this is the wrong approach, since I believe that token-based
namespace-protecting "locks" are only appropriate as a merge avoidance
mechanism, while long-term access control should be neither
token-based, nor should it involve any URL protection.

Another approach is to provide a principal-based access control mechanism,
to complement the locking mechanism.  Whether or not locks require some
level of authentication for use would be controlled by the client, based
on ACL's of the locked resource.  That is an approach I would support.

   > For the purposes of the user deciding whether to cancel an
   > existing lock, the DAV:owner information should be sufficient.

   Many clients may not set that field. I don't think that you can
   necessarily depend upon it. But: I tend to agree that there is nothing
   better, and that field *is* intended for human consumption (and,
   therefore, for asking whether a lock should be cancelled).

Yes, if a client decides to store no information there, then that is
the clients choice.  But I believe the DAV:owner field is a good
interoperable mechanism for addressing the problem of how to let a
client present information to its user about the principal that
requested the lock.

Cheers,
Geoff




From w3c-dist-auth-request@w3.org  Thu Jan 27 11:05:26 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08470
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 11:05:26 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA06730;
	Thu, 27 Jan 2000 11:01:05 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 11:01:05 -0500 (EST)
Resent-Message-Id: <200001271601.LAA06730@www19.w3.org>
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD2457D@crte147.wc.eso.mc.xerox.com>
From: "Slein, Judith A" <JSlein@crt.xerox.com>
To: "'Greg Stein'" <gstein@lyra.org>, ccjason@us.ibm.com
Cc: w3c-dist-auth@w3.org
Date: Thu, 27 Jan 2000 11:00:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.AtomicDelete
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3956
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

I think maybe we haven't made it clear what we are trying to accomplish by
saying that DELETE must be atomic.  And maybe expressing it that way is
confusing.  Here are the results we want (I think):

1. DELETE removes a single binding.  It does not remove all the bindings to
a resource, only the one identified by the Request-URI.  If it happens to be
the last binding, then what happens about garbage collection of either
content or properties is outside the scope of the spec.  DELETE is just
about removing the binding.

2. In the case where the binding is to a collection, DELETE still means only
remove the binding to that collection.  It is not acceptable to walk the
tree deleting bindings to descendents of that collection.  This would have
disastrous consequences in an environment with multiple bindings to
resources.  To resurrect an example of Jason's:

User UA uses URL /a/C/ to access collection coll1.  User UB uses URL /b/C/
to access the same collection.  Now suppose UA issues a DELETE on /a/C/.
What you want is for UB to be able to continue to use /b/C/ to access the
collection (and all its descendents).  So you can't go deleting the bindings
in coll1 to all its children.  All you want to do is remove the binding
a:(C->coll1) from collection /a/.

Does either of these restrictions cause problems for mod_dav?

--Judy

> -----Original Message-----
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Friday, January 21, 2000 5:36 PM
> To: ccjason@us.ibm.com
> Cc: Yaron Goland; w3c-dist-auth@w3.org
> Subject: Re: WebDAV Bindings - Issue Yaron.AtomicDelete
> 
> 
> On Tue, 18 Jan 2000 ccjason@us.ibm.com wrote:
> >...
> > >>
> >  There are, I freely admit, circumstances in which a client 
> MUST be able to
> > ensure that a DELETE is issued atomically. Clients in those 
> cases will have
> > to choose to not interoperate with many WebDAV servers in 
> order to gain
> > atomic delete.
> > >>
> > These clients can interoperate with an old iterative server 
> just fine if
> > they also include 2518 support.  That's their choice.
> > 
> > We have asked around and it seems that server authors 
> appreciate and are
> > willing to comply with semantic of an "atomic" removal of a 
> single binding.
> 
> I don't recall being asked, nor agreeing with atomic 
> operations. If that
> binding happens to be a collection, then it will definitely 
> be non-atomic.
> 
> [ also assuming this is the "final" removal of the collection ]
> 
> >...
> > >>
> > Let me clarify that DELETE was defined to not be atomic 
> with malice of fore
> > thought. The non-atomic delete language was the result of 
> nearly three
> > years of negotiations and represented a deep and broad 
> consensus built up
> > amongst a huge community. Might I respectfully suggest to 
> the BIND authors
> > that they should not be so ready to overthrow years of 
> careful consensus
> > building.
> > >>
> > We've asked around.  Folks appreciate this behavior and are 
> willing to
> > support it.
> 
> Again: I don't remember being asked. Maybe I missed a post to 
> this list?
> 
> Regardless, I am not willing support atomic deletions of 
> collections OR
> single, member resources. Note that I mentioned member 
> resources here. I
> delete a member resource in two steps: the contents and its 
> properties.
> Definitely non-atomic.
> 
> And with respect to the Apache web server, I will not even 
> begin to think
> of making it atomic (e.g. serialize all requests while a 
> resource is being
> deleted).
> 
> > >>
> > Do not imagine that the lack of screaming on this issue 
> reflects consensus.
> > Rather it reflects the fact that most of the WebDAV 
> community is too busy
> > implementing RFC 2518 to pay much attention to BIND. The BIND
> > functionality, while I believe it will be important to 
> WebDAV, is a bit
> > ahead of the majority of implementers so they just aren't reading or
> > reviewing it, yet.
> > >>
> > We have asked around and we didn't accept silence as a response.
> 
> I was certainly silent. Either that, or I'm going senile and forget
> responding to a question of atomicity. I certainly can't 
> imagine replying
> "sure, I can sure an atomic delete".
> 
> > >>
> > The key reason DELETE was not allowed to be atomic (which 
> certainly would
> > have been a nice thing to be able to do) has to do with the way file
> > systems work. Most file systems do not support depth 
> operations atomically.
> > So, for example, when you delete a directory what actually 
> happens is that
> > the program does a depth first walk of the directory tree 
> and deletes all
> > the individual files, walking backwards up the tree until 
> finally deleting
> > the parent directory.
> > >>
> > You've pointed out that this is a problem on your file 
> system.  We've found
> > no other.   We've tested it and our testing indicates that 
> the MOVE option
> > you mention below works.  (We did not test with ACL's 
> though... or multiple
> > bindings.)    We've also contacted folks at your 
> organization and they
> > didn't see a problem.
> 
> This is an undue complication: generate a unique name, rename 
> the resource
> to that new name, then process its removal. And again, 
> mod_dav couldn't
> even do this because of its separation between properties and 
> contents: I
> could move the contents away, but a PROPFIND could still return
> properties.
> 
> >...
> > >>
> > There is then the third and final issue, WebDAV begins with 
> a "D" for a
> > reason. It's goal is to be distributed. Requiring atomic 
> DELETEs would
> > essentially hinder all but the most expensive of systems 
> from being able to
> > implement distributed namespaces across multiple physical 
> servers. The
> > reason being that the atomic requirement means that these 
> systems will have
> > to establish transactioning systems between themselves in 
> order to issue
> > DELETEs if they share namespace.
> > >>
> > It's only one binding.  The goal isn't to be atomic, that's just a
> > fortunate side effect.
> 
> It is *definitely* not a "side effect." mod_dav certainly 
> does not do a
> rename-then-delete. Therefore, I have to take explicit 
> actions to achieve
> that behavior. I don't even think that I could *ever* 
> guarantee an atomic
> DELETE operation.
> 
> >...
> > >>
> > As such I move that the atomic DELETE language be struck 
> from the BIND spec
> > on the grounds that it destroys interoperability, requires 
> behavior that
> > would preclude file system based systems from supporting WebDAV and
> > significantly increases the cost of implementing WebDAV in 
> a distributed
> > manner.
> > >>
> 
> I agree with Yaron on this one. Strongly.
> 
> > I believe I've addressed all of these above.
> > 
> > It is very clear that DELETE should not be iterative or 
> accept partial
> > results in a server that supports multiple bindings.
> 
> I think it is very clear that it shouldn't.
> 
> Stating your opinion of clarity doesn't make it so, nor does 
> mine. But I
> certainly can tell you right now that I won't be one of the "example
> implementations" required for an IETF Standard.
> 
> > Legacy clients may
> > invoke DELETE without knowledge of the potential dangers.  
> Therefore, a
> > simple DELETE should delete a single binding.  --- There is 
> no compelling
> > reason (so far) not to support single binding delete and it 
> simplifies the
> 
> I believe that I've given you one. With a good chunk of extra work and
> serialization within the server, then it might be possible. 
> But I am not
> really up for trying to figure it out.
> 
> Cheers,
> -g
> 
> -- 
> Greg Stein, http://www.lyra.org/
> 



From w3c-dist-auth-request@w3.org  Thu Jan 27 11:19:21 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08915
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 11:19:21 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA07469;
	Thu, 27 Jan 2000 11:14:44 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 11:14:44 -0500 (EST)
Resent-Message-Id: <200001271614.LAA07469@www19.w3.org>
From: jamsden@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <85256873.00593282.00@d54mta03.raleigh.ibm.com>
Date: Thu, 27 Jan 2000 09:49:15 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3957
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list



<geoff>
In particular, for merge avoidance, a lock token is required, and
which principal is issuing the request is irrelevant.  On the other
hand, for authenticated access control, the principal is required, and
a "lock-token" is irrelevant.  Thus all the confusion in the working
group about when/where a principal is required and when/where a lock
token is required.

Furthermore, for merge avoidance, you want to protect the URL, because
the URL is what the client is holding as the "key" to identify the
resource being authored.  On the other hand, for authenticated access
control, it is the *resource* that is being controlled, not the URL.
Thus all the confusion in the working group about whether a resource
is being protected or whether a URL is being protected.

So whatever was intended by WebDAV locks, the protocol that is
specified in rfc2518 does a fine job of preventing merge conflicts
for cooperating clients, and is totally inadequate for providing
authenticated access control.  So I propose that anyone that cares
about authenticated access control become active in the WebDAV ACL
specification effort, and just use WebDAV locks for what they can
do, namely prevent merge conflicts for cooperating clients.
</geoff>
<jra>
OK. Now I see what you're getting at. I didn't understand you were
proposing something that isn't in RFC2518 - lock tokens to prevent merge
conflicts for COOPERATING clints. (I know you said it a number of times, I
just kept interperting it from the point of view of the existing spec.)
This is an interesting approach, and one that could be more acceptable if
we had ACLs. But what does it hurt to require the lock token/authorization
pair? Especially in the case of shared locks? Wouldn't this allow the
server to "help" the clients cooperate? Isn't this the more traditional
notion of locking?
</jra>




From w3c-dist-auth-request@w3.org  Thu Jan 27 13:01:30 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10970
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 13:01:30 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA13061;
	Thu, 27 Jan 2000 12:56:55 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 12:56:55 -0500 (EST)
Resent-Message-Id: <200001271756.MAA13061@www19.w3.org>
Date: Thu, 27 Jan 2000 12:56:35 -0500
Message-Id: <10001271756.AA29444@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: gstein@lyra.org, yarong@microsoft.com, w3c-dist-auth@w3.org
In-Reply-To: 
	<8E3CFBC709A8D21191A400805F15E0DBD2457D@crte147.wc.eso.mc.xerox.com>
	(JSlein@crt.xerox.com)
Subject: Re: WebDAV Bindings - Issue Yaron.AtomicDelete
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3958
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


I agree with Judy's description of what we want to achieve by saying
DELETE is atomic.  Another way of phrasing it is that avoids the word
"atomic" is to say:

"A DELETE modifies the state of the collection resource containing the
specified binding (namely, by deleting that binding), but MUST NOT
modify the state of any other collection resource as a side effect."

In an implementation where only a single binding to a collection
is supported, then deleting a binding to a collection will result in all
the members of that collection being inaccessible, so having the server
traverse down and mangle all the subcollections is permissible (after all,
the client specifically said it isn't interested in any of them any more).

But in a system where having multiple bindings to collections is
supported (e.g. database and versioning systems), mangling member
collections as a side effect of a delete is unacceptable, since this
mangles resources whose current state may still be significant to the client.

One possible compromise would be to place this restriction only on servers
that support multiple bindings.  In particular, the phrasing could be:

The request "DELETE /pathX/resourceY" MUST remove the binding named
"resourceY" from the collection identified by "/pathX".  If a resource
supports the BIND operation, then the request "DELETE /pathX/resourceY"
MUST NOT remove a collection's binding to that resource unless
"/pathX" identifies that collection and "/pathX/resourceY" identifies
that resource.

Greg, Yaron, as supporters of the "mangle" form of DELETE (:-),
would you find this acceptable?

Cheers,
Geoff

   From: "Slein, Judith A" <JSlein@crt.xerox.com>

   I think maybe we haven't made it clear what we are trying to accomplish by
   saying that DELETE must be atomic.  And maybe expressing it that way is
   confusing.  Here are the results we want (I think):

   1. DELETE removes a single binding.  It does not remove all the bindings to
   a resource, only the one identified by the Request-URI.  If it happens to be
   the last binding, then what happens about garbage collection of either
   content or properties is outside the scope of the spec.  DELETE is just
   about removing the binding.

   2. In the case where the binding is to a collection, DELETE still means only
   remove the binding to that collection.  It is not acceptable to walk the
   tree deleting bindings to descendents of that collection.  This would have
   disastrous consequences in an environment with multiple bindings to
   resources.  To resurrect an example of Jason's:

   User UA uses URL /a/C/ to access collection coll1.  User UB uses URL /b/C/
   to access the same collection.  Now suppose UA issues a DELETE on /a/C/.
   What you want is for UB to be able to continue to use /b/C/ to access the
   collection (and all its descendents).  So you can't go deleting the bindings
   in coll1 to all its children.  All you want to do is remove the binding
   a:(C->coll1) from collection /a/.

   Does either of these restrictions cause problems for mod_dav?



From w3c-dist-auth-request@w3.org  Thu Jan 27 13:36:48 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11619
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 13:36:48 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA14372;
	Thu, 27 Jan 2000 13:32:07 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 13:32:07 -0500 (EST)
Resent-Message-Id: <200001271832.NAA14372@www19.w3.org>
Message-ID: <0C5DFAE09D2A644D97C4830DFA90F02202D602@df-rocket.platinum.corp.microsoft.com>
From: "Lisa Lippert (Dusseault)" <lisal@Exchange.Microsoft.com>
To: "'Joe Orton'" <joe@orton.demon.co.uk>
Cc: "'David Engberg'" <dave.engberg@driveway.com>, w3c-dist-auth@w3.org
Date: Thu, 27 Jan 2000 10:21:50 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: RE: WebDAV proxy problems
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3959
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Would this information be suitable on a page for the webdav.org site?  Might
even put some pressure on proxy developers to support RFC 2518, and to allow
their administrators to name additional methods that should be allowed over
HTTP (e.g. so that new advanced collections or DASL commands can be added).

Lisa

-----Original Message-----
From: Joe Orton [mailto:joe@orton.demon.co.uk]
Sent: Thursday, January 27, 2000 5:10 AM
To: Lisa Lippert (Dusseault)
Cc: 'David Engberg'; w3c-dist-auth@w3.org
Subject: Re: WebDAV proxy problems


> I actually started collecting some information on this.  Since I don't
have
> testing resources for it, it's only hearsay, but here goes:
> 
> Known Proxies that support DAV
> 
>  - MS Proxy 2.0: Support for DAV is built-in to MS Proxy 2.0.
>  - Squid: There is a patch for the Squid proxy server that adds support
for
> WebDAV (http://www.squid-cache.org/Versions/v2/2.2/bugs/).

Apache mod_proxy works fine too. IIRC Squid 2.3 will pass through the
methods defined in 2518, but will still block methods it doesn't
understand. 

joe



From w3c-dist-auth-request@w3.org  Thu Jan 27 13:39:32 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11673
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 13:39:30 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA14421;
	Thu, 27 Jan 2000 13:35:13 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 13:35:13 -0500 (EST)
Resent-Message-Id: <200001271835.NAA14421@www19.w3.org>
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
cc: w3c-dist-auth@w3.org
In-reply-to: Your message of "Thu, 27 Jan 2000 12:56:35 EST."
             <10001271756.AA29444@tantalum> 
Date: Thu, 27 Jan 2000 10:35:02 -0800
From: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
Message-ID:  <200001271035.aa07327@gremlin-relay.ics.uci.edu>
Subject: Re: WebDAV Bindings - Issue Yaron.AtomicDelete 
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3960
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

In message <10001271756.AA29444@tantalum>, "Geoffrey M. Clemm" writes:
>I agree with Judy's description of what we want to achieve by saying
>DELETE is atomic.  Another way of phrasing it is that avoids the word
>"atomic" is to say:
>
>"A DELETE modifies the state of the collection resource containing the
>specified binding (namely, by deleting that binding), but MUST NOT
>modify the state of any other collection resource as a side effect."

No, that is a requirement on the implementation, not the protocol.
Why don't you just use the two paragraphs that Judy listed?

>>1. DELETE removes a single binding.  It does not remove all the bindings to
>>a resource, only the one identified by the Request-URI.  If it happens to be
>>the last binding, then what happens about garbage collection of either
>>content or properties is outside the scope of the spec.  DELETE is just
>>about removing the binding.
>
>>2. In the case where the binding is to a collection, DELETE still means only
>>remove the binding to that collection.  It is not acceptable to walk the
>>tree deleting bindings to descendents of that collection.  This would have
>>disastrous consequences in an environment with multiple bindings to
>>resources.  To resurrect an example of Jason's:

This has nothing to do with "atomicity".   It does, however, raise a
problem in that removing the last binding to a non-empty collection might
be unacceptable to the server.  This second case should allow the server
to report an informative error if it requires that the collection be
empty first (this would depend on the nature of the colection resource,
not on some aspect of the protocol).

....Roy



From w3c-dist-auth-request@w3.org  Thu Jan 27 14:19:41 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12428
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 14:19:41 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA15522;
	Thu, 27 Jan 2000 14:14:59 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 14:14:59 -0500 (EST)
Resent-Message-Id: <200001271914.OAA15522@www19.w3.org>
Date: Thu, 27 Jan 2000 14:14:50 -0500
Message-Id: <10001271914.AA29510@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <200001271035.aa07327@gremlin-relay.ics.uci.edu>
	(fielding@kiwi.ICS.UCI.EDU)
Subject: Re: WebDAV Bindings - Issue Yaron.AtomicDelete
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3961
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


   From: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>

   In message <10001271756.AA29444@tantalum>, "Geoffrey M. Clemm" writes:
   >I agree with Judy's description of what we want to achieve by saying
   >DELETE is atomic.  Another way of phrasing it is that avoids the word
   >"atomic" is to say:
   >
   >"A DELETE modifies the state of the collection resource containing the
   >specified binding (namely, by deleting that binding), but MUST NOT
   >modify the state of any other collection resource as a side effect."

   No, that is a requirement on the implementation, not the protocol.
   Why don't you just use the two paragraphs that Judy listed?

I like Judy's two paragraphs, so that's fine with me.

Just for interests sake, since my rewording was intended to be just
state the key point from Judy's two paragraphs, what was wrong with
it?  Doesn't a protocol always defines requirements on the
implementation?  (I'm not disagreeing with you, I just didn't
understand your point.)

   >>1. DELETE removes a single binding.  It does not remove all the bindings to
   >>a resource, only the one identified by the Request-URI.  If it happens to be
   >>the last binding, then what happens about garbage collection of either
   >>content or properties is outside the scope of the spec.  DELETE is just
   >>about removing the binding.
   >
   >>2. In the case where the binding is to a collection, DELETE still means only
   >>remove the binding to that collection.  It is not acceptable to walk the
   >>tree deleting bindings to descendents of that collection.  This would have
   >>disastrous consequences in an environment with multiple bindings to
   >>resources.  To resurrect an example of Jason's:

   This has nothing to do with "atomicity".

I agree.  The term "atomicity" should not be used in this context.

   It does, however, raise a
   problem in that removing the last binding to a non-empty collection might
   be unacceptable to the server.  This second case should allow the server
   to report an informative error if it requires that the collection be
   empty first (this would depend on the nature of the colection resource,
   not on some aspect of the protocol).

Good point.  An appropriate error status should be defined.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Thu Jan 27 14:50:42 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13310
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 14:50:41 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA16036;
	Thu, 27 Jan 2000 14:39:40 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 14:39:40 -0500 (EST)
Resent-Message-Id: <200001271939.OAA16036@www19.w3.org>
Date: Wed, 26 Jan 2000 22:09:27 +0000
From: Joe Orton <joe@orton.demon.co.uk>
To: w3c-dist-auth@w3.org
Message-ID: <20000126220927.C374@ankh.dunno.local>
Mail-Followup-To: w3c-dist-auth@w3.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
Subject: MKRESOURCE without specifying DAV:resourcetype
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3963
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Section 5 of redirectref-02 says "MKRESOURCE can be used to create a
resource of any type other than standard data containers and collections."
(and this is repeated at the beginning of 5.1)

5.1 then goes on to say: "If the DAV:propertyupdate does not specify a
DAV:resourcetype, the resource will be a standard data container."... so,
can MKRESOURCE create "standard data containers", or can't it?

What is meant by a "standard data container" in this context? Maybe it is
the intent that MKRESOURCE without specifying the resourcetype is
equivalent to a PUT of a zero-length entity-body followed by a PROPPATCH?

joe







From w3c-dist-auth-request@w3.org  Thu Jan 27 14:50:47 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13321
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 14:50:47 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA16086;
	Thu, 27 Jan 2000 14:39:49 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 14:39:49 -0500 (EST)
Resent-Message-Id: <200001271939.OAA16086@www19.w3.org>
Date: Thu, 27 Jan 2000 19:33:55 +0000
From: Joe Orton <joe@orton.demon.co.uk>
To: support@driveway.com
Cc: w3c-dist-auth@w3.org
Message-ID: <20000127193355.B1461@ankh.dunno.local>
Mail-Followup-To: support@driveway.com, w3c-dist-auth@w3.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
Subject: driveway.com / cadaver interop
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3964
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

In the response to a PROPFIND with the following body:

<?xml version="1.0"?>
<propfind xmlns="DAV:">
  <prop><getcontentlength/><getlastmodified/><resourcetype/></prop>
</propfind>

the driveway.com server will include the DAV:supportedlock element for
non-collection resources, which seems wrong, although I can't find
anywhere in 2518 which actually says so. There should be some kind of
requirement that servers only return the *requested* properties for this
type of PROPFIND requests, shouldn't there? A MUST requirement would be
nice.

joe



From w3c-dist-auth-request@w3.org  Thu Jan 27 14:50:53 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13343
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 14:50:51 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA16006;
	Thu, 27 Jan 2000 14:39:35 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 14:39:35 -0500 (EST)
Resent-Message-Id: <200001271939.OAA16006@www19.w3.org>
Date: Wed, 26 Jan 2000 22:08:18 +0000
From: Joe Orton <joe@orton.demon.co.uk>
To: w3c-dist-auth@w3.org
Message-ID: <20000126220818.B374@ankh.dunno.local>
Mail-Followup-To: w3c-dist-auth@w3.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
Subject: Bodies of redirect reference resources
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3962
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

I am trying to understand the redirectref-02 spec, and feel I've missed
something fundamental. It starts with:

   "A redirect reference resource is a resource in one collection whose
   purpose is to forward requests to another resource"

This makes sense to me; we have a special type of resource, which, when we
try and do things to it, it will respond with "No, go away and do it to
this other resource instead". Enough said.

Then it says this:

   "A redirect reference is a resource, and so can have properties and a
   body of its own."

Okay, a resource can have properties defined on it; this is WebDAV. But,
"a body of its own". What does that mean? Have resources become confused
with HTTP messages?

On to section 6:

   "A redirect reference resource MAY have a body, though
   none is defined for it in this specification.  The PUT method can be
   used, with Apply-To-Redirect-Ref, to create or replace the body of a
   redirect reference resource.".

So, if we have a redirect reference resource at URI X, when we try and
access it as any normal resource, it tells us to go to URI Y instead. But,
we can also, using a PUT with the Apply-To-RR header, submit an
entity-body, have it stored at this URI, then fetch it again later with a
GET and the same header. So, there are actually *two* separate resources
identified by URI X; the special RR resource, and the extra one we
submitted with the PUT. Except that these two resources share the same
URI, and the same DAV properties. Is this really the intent of the
authors? Is there a need to store an extra resource along with every RR
resource?

Now sec 6.2, with an example of a PUT to a RR resource with the
Apply-to-RR header: 

   "The result in this case is that the reference
   resource is replaced by a non-reference resource having the content
   submitted with the request." 

This seems to imply that in a PUT to an RR resource, the RR resource is
removed, and another one replaces it, losing the "302" stuff, and
contradicting the above semantics? Maybe this was supposed to say "the
body of the reference resource is ..."?

To me, a PUT or a GET to a RR resource, *with* the Apply-to-RR header,
should fail, since this is a special resource, with special semantics, in
the same way that a collection resource is. A 4xx response will do fine in
this case.

Regards,

joe



From w3c-dist-auth-request@w3.org  Thu Jan 27 14:50:54 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13354
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 14:50:54 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA16114;
	Thu, 27 Jan 2000 14:39:57 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 14:39:57 -0500 (EST)
Resent-Message-Id: <200001271939.OAA16114@www19.w3.org>
Date: Wed, 26 Jan 2000 22:16:51 +0000
From: Joe Orton <joe@orton.demon.co.uk>
To: w3c-dist-auth@w3.org
Message-ID: <20000126221651.D374@ankh.dunno.local>
Mail-Followup-To: w3c-dist-auth@w3.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
Subject: Minor nits for redirectref-02
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3965
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

1) In the MKRESOURCE response status codes, 423 Locked and 507
Insufficient storage are included; this seems unnecessary. 2518 specifies
what these mean. You can't include the full set of valid status codes in
responses to MKRESOURCE, else you'd have to include all the normal HTTP
codes too, so why not just stick to new or changed codes?

2) MKRESOURCE responses "SHOULD NOT be cached" implies there are odd cases
when it's okay to cache them, is this right?

joe



From w3c-dist-auth-request@w3.org  Thu Jan 27 14:55:33 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13556
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 14:55:32 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA16576;
	Thu, 27 Jan 2000 14:51:00 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 14:51:00 -0500 (EST)
Resent-Message-Id: <200001271951.OAA16576@www19.w3.org>
Date: Thu, 27 Jan 2000 11:45:51 -0800
Message-ID: <8709-Thu27Jan2000114551-0800-bill@carpenter.ORG>
X-Mailer: 20.4 "Emerald" XEmacs  Lucid (via feedmail 9-beta-9 I) wjc loop;
	VM 6.71 under 20.4 "Emerald" XEmacs  Lucid
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: bill@carpenter.ORG (WJCarpenter)
To: w3c-dist-auth@w3.org
Subject: is DELETE "best effort"?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3966
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

RFC-2518 doesn't come right out and say so, but I think it implies
that a DELETE on a collection is on a "best effort" basis, where you
can deduce what got DELETEd versus what didn't (and why) from a
possible multistatus response.

Suppose I request a DELETE of /zoo/, where /zoo/ contains /zoo/mammals
and /zoo/birds.  Suppose there is a problem with the DELETE of
/zoo/mammals (it's locked by my corporate rival, Snidely Whiplash).
Should the server, having discovered this, go ahead and attempt a
DELETE of /zoo/birds?

Section 8.6.2 says that if you can't DELETE a resource, you shouldn't
DELETE its ancestors (for the sake of namespace consistency).  It is
silent on what you should do about the resource's siblings, though
(the example in 8.6.2 isn't bushy enough to show it).  There is a hint
that some of the DELETEs may be allowed to succeed while others fail
in that 204 response codes are to be omitted from the multistatus
because they are the default success code.

Is DELETE intended to be "best effort"?
-- 
bill@carpenter.ORG   (WJCarpenter)           PGP
bill@bubblegum.net                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3



From w3c-dist-auth-request@w3.org  Thu Jan 27 15:07:32 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13762
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 15:07:29 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA17496;
	Thu, 27 Jan 2000 15:02:55 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 15:02:55 -0500 (EST)
Resent-Message-Id: <200001272002.PAA17496@www19.w3.org>
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
cc: w3c-dist-auth@w3.org
In-reply-to: Your message of "Thu, 27 Jan 2000 14:14:50 EST."
             <10001271914.AA29510@tantalum> 
Date: Thu, 27 Jan 2000 12:02:44 -0800
From: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
Message-ID:  <200001271202.aa15135@gremlin-relay.ics.uci.edu>
Subject: Re: WebDAV Bindings - Issue Yaron.AtomicDelete 
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3967
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

In message <10001271914.AA29510@tantalum>, "Geoffrey M. Clemm" writes:
>   >"A DELETE modifies the state of the collection resource containing the
>   >specified binding (namely, by deleting that binding), but MUST NOT
>   >modify the state of any other collection resource as a side effect."
>
>   No, that is a requirement on the implementation, not the protocol.
>   Why don't you just use the two paragraphs that Judy listed?
>
>I like Judy's two paragraphs, so that's fine with me.
>
>Just for interests sake, since my rewording was intended to be just
>state the key point from Judy's two paragraphs, what was wrong with
>it?  Doesn't a protocol always defines requirements on the
>implementation?  (I'm not disagreeing with you, I just didn't
>understand your point.)

A protocol requires that the externally visible behavior of the
component match that expected by the protocol.  The way you phrased
it was specifying the state within the collection component rather
than what was visible to other components.  Consider, for example,
that a hierarchical database implementation of collections might
have dual-linked relations between sister collections, and thus
deletion of one collection would have to effect another collection.

The point being that we don't have to require anything beyond what
the protocol means -- specifying anything beyond that is just overkill
and tends to limit implementations unnecessarily.

....Roy



From w3c-dist-auth-request@w3.org  Thu Jan 27 15:45:59 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14468
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 15:45:56 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA18676;
	Thu, 27 Jan 2000 15:41:17 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 15:41:17 -0500 (EST)
Resent-Message-Id: <200001272041.PAA18676@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED0282B9A6@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: w3c-dist-auth@w3.org
Cc: Daniel Lovinger <danlo@Exchange.Microsoft.com>,
        Brian Andrew
	 <brianan@Exchange.Microsoft.com>
Date: Thu, 27 Jan 2000 12:23:10 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF6906.B95B36CA"
Subject: WebDAV Bindings - Issue Yaron.AtomicDelete
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3968
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6906.B95B36CA
Content-Type: text/plain;
	charset="iso-8859-1"

The following is a summary of my conversations with Daniel Lovinger,
technical lead for FAT in Windows NT and Brian Andrew, technical lead for
NTFS. Any technical mistakes below are due to my own failure to properly
understand what Dan and Brian told me.

I explained to Brian and Dan that I needed to implement WebDAV over existing
NTFS and FAT file systems and that it was critical that our WebDAV
implementation allow for multiple simultaneous protocol access through
NFS/Win32/SMB/FTP/WebDAV/etc. I asked them, given this requirement, if it
would be possible to simulate an atomic delete by just moving the tree we
wanted to delete and then begin the file-by-file delete.

Both Brian and Dan agreed that the move operation is atomic and that this
would allow one to make the entire sub-tree disappear from a particular
point in the namespace in a single atomic act. However both Brian and Dan
pointed out that the problems really begin once you have moved the tree. The
both pointed out that if I insist on allowing multiple access to the files
in question through WebDAV as well as FTP/SMB/NFS/Win32/etc. then it would
be impossible to perform an atomic delete.

The crux of the problem is that NFS, amongst others, does not necessarily
refer to files using their path location. They often refer to files using
File IDs which are completely independent of location. This means that the
attempt to move the files from one part of the namespace to another in order
to hide them won't work with NFS. NFS and similar systems will continue to
be able to operate on the files, regardless of where they are moved to.

This means that even if the move on the sub-directory succeeds it is
possible for a NFS client to come in and open (without the filesharedelete
flag) or change the ACL on a file and hence prevent us from deleting the
file. Even if we attempt to change the ACL on a file to prevent others from
accessing the file another user with a File ID and a higher access can
always override us. 

Note the assumption that we are running the WebDAV thread using the
authentication of the requesting user. This is standard practice in NT as we
have found that running threads at the administrative level is a security
and performance threat. However, even if we were willing to run the WebDAV
thread at administrative level in a shared file system it is possible for
other administrators to override the local administrator thus causing the
previous problems.

The result is that the atomic move provided by the file system doesn't buy
us much because it doesn't "hide" the files from everyone. This means that
there is no way for us to be sure, once we begin actually deleting files,
that we will successfully be able to delete all of this files. This then
means that we can end up with a half deleted tree. A tree we can not
subsequently move back after the failures because to do so would violate the
atomic guarantee of an all-or-nothing delete.

So the bottom line is that we can't implement an atomic delete and allow for
multiple simultaneous file system access through multiple protocols. Since
our users absolutely demand multiple simultaneous file system access through
multiple protocols we can not implement atomic delete.

			Yaron


------_=_NextPart_001_01BF6906.B95B36CA
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>WebDAV Bindings - Issue Yaron.AtomicDelete</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Courier New">The following is a summary of my =
conversations with Daniel Lovinger, technical lead for FAT in Windows =
NT and Brian Andrew, technical lead for NTFS. Any technical mistakes =
below are due to my own failure to properly understand what Dan and =
Brian told me.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">I explained to Brian and Dan =
that I needed to implement WebDAV over existing NTFS and FAT file =
systems and that it was critical that our WebDAV implementation allow =
for multiple simultaneous protocol access through =
NFS/Win32/SMB/FTP/WebDAV/etc. I asked them, given this requirement, if =
it would be possible to simulate an atomic delete by just moving the =
tree we wanted to delete and then begin the file-by-file =
delete.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Both Brian and Dan agreed that =
the move operation is atomic and that this would allow one to make the =
entire sub-tree disappear from a particular point in the namespace in a =
single atomic act. However both Brian and Dan pointed out that the =
problems really begin once you have moved the tree. The both pointed =
out that if I insist on allowing multiple access to the files in =
question through WebDAV as well as FTP/SMB/NFS/Win32/etc. then it would =
be impossible to perform an atomic delete.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">The crux of the problem is that =
NFS, amongst others, does not necessarily refer to files using their =
path location. They often refer to files using File IDs which are =
completely independent of location. This means that the attempt to move =
the files from one part of the namespace to another in order to hide =
them won't work with NFS. NFS and similar systems will continue to be =
able to operate on the files, regardless of where they are moved =
to.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">This means that even if the move =
on the sub-directory succeeds it is possible for a NFS client to come =
in and open (without the filesharedelete flag) or change the ACL on a =
file and hence prevent us from deleting the file. Even if we attempt to =
change the ACL on a file to prevent others from accessing the file =
another user with a File ID and a higher access can always override us. =
</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Note the assumption that we are =
running the WebDAV thread using the authentication of the requesting =
user. This is standard practice in NT as we have found that running =
threads at the administrative level is a security and performance =
threat. However, even if we were willing to run the WebDAV thread at =
administrative level in a shared file system it is possible for other =
administrators to override the local administrator thus causing the =
previous problems.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">The result is that the atomic =
move provided by the file system doesn't buy us much because it doesn't =
&quot;hide&quot; the files from everyone. This means that there is no =
way for us to be sure, once we begin actually deleting files, that we =
will successfully be able to delete all of this files. This then means =
that we can end up with a half deleted tree. A tree we can not =
subsequently move back after the failures because to do so would =
violate the atomic guarantee of an all-or-nothing delete.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">So the bottom line is that we =
can't implement an atomic delete and allow for multiple simultaneous =
file system access through multiple protocols. Since our users =
absolutely demand multiple simultaneous file system access through =
multiple protocols we can not implement atomic delete.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">Yaron</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF6906.B95B36CA--



From w3c-dist-auth-request@w3.org  Thu Jan 27 16:18:52 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14994
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 16:18:48 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id QAA20122;
	Thu, 27 Jan 2000 16:10:46 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 16:10:46 -0500 (EST)
Resent-Message-Id: <200001272110.QAA20122@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A0E5@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'bill@carpenter.ORG'" <bill@carpenter.ORG>, w3c-dist-auth@w3.org
Date: Thu, 27 Jan 2000 13:09:42 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: RE: is DELETE "best effort"?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3969
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Yes.

> -----Original Message-----
> From: bill@carpenter.ORG [mailto:bill@carpenter.ORG]
> Sent: Thursday, January 27, 2000 11:46 AM
> To: w3c-dist-auth@w3.org
> Subject: is DELETE "best effort"?
> 
> 
> RFC-2518 doesn't come right out and say so, but I think it implies
> that a DELETE on a collection is on a "best effort" basis, where you
> can deduce what got DELETEd versus what didn't (and why) from a
> possible multistatus response.
> 
> Suppose I request a DELETE of /zoo/, where /zoo/ contains /zoo/mammals
> and /zoo/birds.  Suppose there is a problem with the DELETE of
> /zoo/mammals (it's locked by my corporate rival, Snidely Whiplash).
> Should the server, having discovered this, go ahead and attempt a
> DELETE of /zoo/birds?
> 
> Section 8.6.2 says that if you can't DELETE a resource, you shouldn't
> DELETE its ancestors (for the sake of namespace consistency).  It is
> silent on what you should do about the resource's siblings, though
> (the example in 8.6.2 isn't bushy enough to show it).  There is a hint
> that some of the DELETEs may be allowed to succeed while others fail
> in that 204 response codes are to be omitted from the multistatus
> because they are the default success code.
> 
> Is DELETE intended to be "best effort"?
> -- 
> bill@carpenter.ORG   (WJCarpenter)           PGP
> bill@bubblegum.net                    0x91865119
> 38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3
> 



From w3c-dist-auth-request@w3.org  Thu Jan 27 16:23:11 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15058
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 16:23:08 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id QAA20364;
	Thu, 27 Jan 2000 16:15:36 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 16:15:36 -0500 (EST)
Resent-Message-Id: <200001272115.QAA20364@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A0E6@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'Joe Orton'" <joe@orton.demon.co.uk>, support@driveway.com
Cc: w3c-dist-auth@w3.org
Date: Thu, 27 Jan 2000 13:13:55 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: RE: driveway.com / cadaver interop
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3970
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

A server is always free to return extra properties since clients are always
able to tell if a response contains the properties they are interested in. A
client that fails in this scenario would be properly viewed as broken as,
even if the standard prohibited returning extra properties, a real world
client MUST be flexible enough to handle a broken server that did the wrong
thing in this case.

That having been said, I wouldn't support specifying that a server MUST NOT
return extra properties as I don't think this requirement would enhance
interoperability and it would prevent some potentially useful scenarios.

I realize that a server returning extra properties could be considered a
D.O.S. attack but since the server is the "service" and since the client can
kill the TCP connection, I find this argument to be a bit strained.

> -----Original Message-----
> From: Joe Orton [mailto:joe@orton.demon.co.uk]
> Sent: Thursday, January 27, 2000 11:34 AM
> To: support@driveway.com
> Cc: w3c-dist-auth@w3.org
> Subject: driveway.com / cadaver interop
> 
> 
> In the response to a PROPFIND with the following body:
> 
> <?xml version="1.0"?>
> <propfind xmlns="DAV:">
>   <prop><getcontentlength/><getlastmodified/><resourcetype/></prop>
> </propfind>
> 
> the driveway.com server will include the DAV:supportedlock element for
> non-collection resources, which seems wrong, although I can't find
> anywhere in 2518 which actually says so. There should be some kind of
> requirement that servers only return the *requested* 
> properties for this
> type of PROPFIND requests, shouldn't there? A MUST 
> requirement would be
> nice.
> 
> joe
> 



From w3c-dist-auth-request@w3.org  Thu Jan 27 16:53:44 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15519
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 16:53:43 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id QAA21147;
	Thu, 27 Jan 2000 16:45:37 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 16:45:37 -0500 (EST)
Resent-Message-Id: <200001272145.QAA21147@www19.w3.org>
Date: Thu, 27 Jan 2000 16:45:28 -0500
Message-Id: <10001272145.AA29615@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <20000126220818.B374@ankh.dunno.local> (message from Joe Orton on
	Wed, 26 Jan 2000 22:08:18 +0000)
Subject: Re: Bodies of redirect reference resources
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3971
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


   From: Joe Orton <joe@orton.demon.co.uk>

   I am trying to understand the redirectref-02 spec, and feel I've missed
   something fundamental. It starts with:

      "A redirect reference resource is a resource in one collection whose
      purpose is to forward requests to another resource"

Note: That "in one collection" phrase should be deleted.  It is irrelevant
to the functionality of redirect references.

   This makes sense to me; we have a special type of resource, which, when we
   try and do things to it, it will respond with "No, go away and do it to
   this other resource instead". Enough said.

   Then it says this:

      "A redirect reference is a resource, and so can have properties and a
      body of its own."

   Okay, a resource can have properties defined on it; this is WebDAV. But,
   "a body of its own". What does that mean? Have resources become confused
   with HTTP messages?

The term "resource body" is often used as a shorthand for "what appears in
a GET response body when applied to that resource".  That's what is intended
here.  Is there a better term to use?

   On to section 6:

      "A redirect reference resource MAY have a body, though
      none is defined for it in this specification.  The PUT method can be
      used, with Apply-To-Redirect-Ref, to create or replace the body of a
      redirect reference resource.".

   So, if we have a redirect reference resource at URI X, when we try and
   access it as any normal resource, it tells us to go to URI Y instead. But,
   we can also, using a PUT with the Apply-To-RR header, submit an
   entity-body, have it stored at this URI, then fetch it again later with a
   GET and the same header. So, there are actually *two* separate resources
   identified by URI X; the special RR resource, and the extra one we
   submitted with the PUT.

Yes, there are two separate resources, the one at URI X and the one at URI Y.

   Except that these two resources share the same
   URI, and the same DAV properties.

No, the two separate resources have two separate URI's (X and Y)
and two separate sets of properties.  The resource at X
tells you to go look at the resource at Y, but X and Y are two separate
URI's (unless X happens to be Y, which is possible, but not very useful :-).

   Is this really the intent of the
   authors? Is there a need to store an extra resource along with every RR
   resource?

The extra resource is minimally needed to store the information about
what other resource to redirect to.  It is useful to give the redirect
reference additional properties as well, independent of whatever 
properties are at the (current) target of the reference.

   Now sec 6.2, with an example of a PUT to a RR resource with the
   Apply-to-RR header: 

      "The result in this case is that the reference
      resource is replaced by a non-reference resource having the content
      submitted with the request." 

   This seems to imply that in a PUT to an RR resource, the RR resource is
   removed, and another one replaces it, losing the "302" stuff,
   and contradicting the above semantics?

Yup, that's a contradiction, all right!

We could do any of:
- get rid of the "an RR resource can have a body" statement
- get rid of this statement and change the example to say the PUT MUST fail.
- keep the statement, and change the example to say the PUT updates the body
  of the RR resource.

I could live with any of these choices.

   To me, a PUT or a GET to a RR resource, *with* the Apply-to-RR header,
   should fail, since this is a special resource, with special semantics, in
   the same way that a collection resource is. A 4xx response will do fine in
   this case.

That's one vote for choice #3.  Anyone else?

Cheers,
Geoff




From w3c-dist-auth-request@w3.org  Thu Jan 27 17:01:18 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15678
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 17:01:18 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id QAA21586;
	Thu, 27 Jan 2000 16:53:38 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 16:53:38 -0500 (EST)
Resent-Message-Id: <200001272153.QAA21586@www19.w3.org>
Date: Thu, 27 Jan 2000 16:53:28 -0500
Message-Id: <10001272153.AA29629@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <20000126220927.C374@ankh.dunno.local> (message from Joe Orton on
	Wed, 26 Jan 2000 22:09:27 +0000)
Subject: Re: MKRESOURCE without specifying DAV:resourcetype
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3972
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


   From: Joe Orton <joe@orton.demon.co.uk>

   Section 5 of redirectref-02 says "MKRESOURCE can be used to create a
   resource of any type other than standard data containers and collections."
   (and this is repeated at the beginning of 5.1)

Good catch!  You should be able to create any type of resource
with MKRESOURCE.  I'm not sure why this restrictin was added in
the 02 draft of the protocol, but it should be removed.

   5.1 then goes on to say: "If the DAV:propertyupdate does not specify a
   DAV:resourcetype, the resource will be a standard data container."... so,
   can MKRESOURCE create "standard data containers", or can't it?

   What is meant by a "standard data container" in this context? Maybe it is
   the intent that MKRESOURCE without specifying the resourcetype is
   equivalent to a PUT of a zero-length entity-body followed by a PROPPATCH?

Yes.

Cheers,
Geoff








From w3c-dist-auth-request@w3.org  Thu Jan 27 17:09:44 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15765
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 17:09:43 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id RAA22869;
	Thu, 27 Jan 2000 17:02:08 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 17:02:08 -0500 (EST)
Resent-Message-Id: <200001272202.RAA22869@www19.w3.org>
Date: Thu, 27 Jan 2000 17:01:58 -0500
Message-Id: <10001272201.AA29637@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: 
	<7DE119D3D0E15543874F7561EECBDBED0261A0E5@BEG.platinum.corp.microsoft.com>
	(message from Yaron Goland on Thu, 27 Jan 2000 13:09:42 -0800)
Subject: Re: is DELETE "best effort"?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3973
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


This topic is currently being hotly debated in the thread:
"WebDAV Bindings - Issue Yaron.AtomicDelete"

Although 2518 currently implies "yes", the authors of the BIND protocol
extension have proposed that the answer be changed to "no".  Stay tuned (:-).

Minimally, we shall insist that a server be *allowed* to
leave all member collections unmodified if it cannot delete
the collection specified in the DELETE request.

Cheers,
Geoff

   From: Yaron Goland <yarong@Exchange.Microsoft.com>

   Yes.

   > -----Original Message-----
   > From: bill@carpenter.ORG [mailto:bill@carpenter.ORG]
   > Sent: Thursday, January 27, 2000 11:46 AM
   > To: w3c-dist-auth@w3.org
   > Subject: is DELETE "best effort"?
   > 
   > 
   > RFC-2518 doesn't come right out and say so, but I think it implies
   > that a DELETE on a collection is on a "best effort" basis, where you
   > can deduce what got DELETEd versus what didn't (and why) from a
   > possible multistatus response.
   > 
   > Suppose I request a DELETE of /zoo/, where /zoo/ contains /zoo/mammals
   > and /zoo/birds.  Suppose there is a problem with the DELETE of
   > /zoo/mammals (it's locked by my corporate rival, Snidely Whiplash).
   > Should the server, having discovered this, go ahead and attempt a
   > DELETE of /zoo/birds?
   > 
   > Section 8.6.2 says that if you can't DELETE a resource, you shouldn't
   > DELETE its ancestors (for the sake of namespace consistency).  It is
   > silent on what you should do about the resource's siblings, though
   > (the example in 8.6.2 isn't bushy enough to show it).  There is a hint
   > that some of the DELETEs may be allowed to succeed while others fail
   > in that 204 response codes are to be omitted from the multistatus
   > because they are the default success code.
   > 
   > Is DELETE intended to be "best effort"?
   > -- 
   > bill@carpenter.ORG   (WJCarpenter)           PGP
   > bill@bubblegum.net                    0x91865119
   > 38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3
   > 




From w3c-dist-auth-request@w3.org  Thu Jan 27 17:57:32 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16465
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 17:57:32 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id RAA24957;
	Thu, 27 Jan 2000 17:53:10 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 17:53:10 -0500 (EST)
Resent-Message-Id: <200001272253.RAA24957@www19.w3.org>
Date: Thu, 27 Jan 2000 14:52:57 -0800 (PST)
From: Greg Stein <gstein@lyra.org>
To: "Lisa Lippert (Dusseault)" <lisal@Exchange.Microsoft.com>
cc: w3c-dist-auth@w3.org
In-Reply-To: <0C5DFAE09D2A644D97C4830DFA90F02202D602@df-rocket.platinum.corp.microsoft.com>
Message-ID: <Pine.LNX.4.10.10001271450480.9267-100000@nebula.lyra.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: RE: WebDAV proxy problems
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3974
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Yes, it definitely has a place there. Somebody named Aengus was looking
into this back into December, and was going to provide all the information
(and a web page). Never got the info, though.

I'll set up a page today or tomorrow and put the information that we have
on it.

Cheers,
-g

On Thu, 27 Jan 2000, Lisa Lippert (Dusseault) wrote:

> Would this information be suitable on a page for the webdav.org site?  Might
> even put some pressure on proxy developers to support RFC 2518, and to allow
> their administrators to name additional methods that should be allowed over
> HTTP (e.g. so that new advanced collections or DASL commands can be added).
> 
> Lisa
> 
> -----Original Message-----
> From: Joe Orton [mailto:joe@orton.demon.co.uk]
> Sent: Thursday, January 27, 2000 5:10 AM
> To: Lisa Lippert (Dusseault)
> Cc: 'David Engberg'; w3c-dist-auth@w3.org
> Subject: Re: WebDAV proxy problems
> 
> 
> > I actually started collecting some information on this.  Since I don't
> have
> > testing resources for it, it's only hearsay, but here goes:
> > 
> > Known Proxies that support DAV
> > 
> >  - MS Proxy 2.0: Support for DAV is built-in to MS Proxy 2.0.
> >  - Squid: There is a patch for the Squid proxy server that adds support
> for
> > WebDAV (http://www.squid-cache.org/Versions/v2/2.2/bugs/).
> 
> Apache mod_proxy works fine too. IIRC Squid 2.3 will pass through the
> methods defined in 2518, but will still block methods it doesn't
> understand. 
> 
> joe
> 

-- 
Greg Stein, http://www.lyra.org/




From w3c-dist-auth-request@w3.org  Thu Jan 27 18:04:27 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16573
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 18:04:26 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id RAA25150;
	Thu, 27 Jan 2000 17:58:54 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 17:58:54 -0500 (EST)
Resent-Message-Id: <200001272258.RAA25150@www19.w3.org>
From: ccjason@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: jamsden@us.ibm.com
cc: w3c-dist-auth@w3.org
Message-ID: <85256873.007E2C35.00@D51MTA03.pok.ibm.com>
Date: Thu, 27 Jan 2000 17:57:03 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3975
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


<jra>
OK. Now I see what you're getting at. I didn't understand you were
proposing something that isn't in RFC2518 - lock tokens to prevent merge
conflicts for COOPERATING clints. (I know you said it a number of times, I
just kept interperting it from the point of view of the existing spec.)
This is an interesting approach, and one that could be more acceptable if
we had ACLs. But what does it hurt to require the lock token/authorization
pair? Especially in the case of shared locks? Wouldn't this allow the
server to "help" the clients cooperate? Isn't this the more traditional
notion of locking?
</jra>
<jlc>
I agree with Jim's hint here.  The authentication is a good idea... as is
having the server enforce it.

As for merge conflicts, also having a revision ID/Lastmod and resource ID
and a header
line to verify these is a good idea.  But also having the server enforce
tokens and authentication as mentioned above seems like a good idea if
there
exist clients that aren't so careful about avoiding conflicts.

As stated a few months ago, I think server administrators/authors should
consider
their own security and issues when deciding if resources on their site
reveal
the lock-discovery property.  If some clients are stealing tokens and this
is
resulting in trouble, the servers should not reveal lock tokens via
lock-discovery. 2518 allows them to determine their own policy.

As for the need to peak at ld to find a lock token if one (client) has
misplaced their's...
the server administrator needs to weigh this possibility against the
possibility
of token stealing.  That being said, the client can't count on that
property even
existing.  Or that it's absense means there are no locks on a given
resource.

BTW, was there some issue in this thread that needs to go on the issues
list?
</jlc>







From w3c-dist-auth-request@w3.org  Thu Jan 27 18:05:54 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16587
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 18:05:53 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA25278;
	Thu, 27 Jan 2000 18:00:35 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 18:00:35 -0500 (EST)
Resent-Message-Id: <200001272300.SAA25278@www19.w3.org>
From: jamsden@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <85256873.007D839E.00@d54mta03.raleigh.ibm.com>
Date: Thu, 27 Jan 2000 17:48:49 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: is DELETE "best effort"?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3976
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list



That was my interpretation.





bill@carpenter.ORG (WJCarpenter)@w3.org on 01/27/2000 02:45:51 PM

Sent by:  w3c-dist-auth-request@w3.org


To:   w3c-dist-auth@w3.org
cc:

Subject:  is DELETE "best effort"?


RFC-2518 doesn't come right out and say so, but I think it implies
that a DELETE on a collection is on a "best effort" basis, where you
can deduce what got DELETEd versus what didn't (and why) from a
possible multistatus response.

Suppose I request a DELETE of /zoo/, where /zoo/ contains /zoo/mammals
and /zoo/birds.  Suppose there is a problem with the DELETE of
/zoo/mammals (it's locked by my corporate rival, Snidely Whiplash).
Should the server, having discovered this, go ahead and attempt a
DELETE of /zoo/birds?

Section 8.6.2 says that if you can't DELETE a resource, you shouldn't
DELETE its ancestors (for the sake of namespace consistency).  It is
silent on what you should do about the resource's siblings, though
(the example in 8.6.2 isn't bushy enough to show it).  There is a hint
that some of the DELETEs may be allowed to succeed while others fail
in that 204 response codes are to be omitted from the multistatus
because they are the default success code.

Is DELETE intended to be "best effort"?
--
bill@carpenter.ORG   (WJCarpenter)           PGP
bill@bubblegum.net                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3






From w3c-dist-auth-request@w3.org  Thu Jan 27 18:09:41 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16613
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 18:09:41 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA25609;
	Thu, 27 Jan 2000 18:05:27 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 18:05:27 -0500 (EST)
Resent-Message-Id: <200001272305.SAA25609@www19.w3.org>
From: jamsden@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <85256873.007ECE69.00@d54mta03.raleigh.ibm.com>
Date: Thu, 27 Jan 2000 18:04:55 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3977
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list



Jason,
If authentication+lock token is required, users can't "steal" other user's
lock tokens. This seems like a reasonable approach.





From: Jason Crawford on 01/27/2000 05:57 PM

To:   Jim Amsden/Raleigh/IBM@IBMUS
cc:   w3c-dist-auth@w3.org

Subject:  Re: RFC-2518 LOCK-TOKEN: header  (Document link: Jim Amsden)


<jra>
OK. Now I see what you're getting at. I didn't understand you were
proposing something that isn't in RFC2518 - lock tokens to prevent merge
conflicts for COOPERATING clints. (I know you said it a number of times, I
just kept interperting it from the point of view of the existing spec.)
This is an interesting approach, and one that could be more acceptable if
we had ACLs. But what does it hurt to require the lock token/authorization
pair? Especially in the case of shared locks? Wouldn't this allow the
server to "help" the clients cooperate? Isn't this the more traditional
notion of locking?
</jra>
<jlc>
I agree with Jim's hint here.  The authentication is a good idea... as is
having the server enforce it.

As for merge conflicts, also having a revision ID/Lastmod and resource ID
and a header
line to verify these is a good idea.  But also having the server enforce
tokens and authentication as mentioned above seems like a good idea if
there
exist clients that aren't so careful about avoiding conflicts.

As stated a few months ago, I think server administrators/authors should
consider
their own security and issues when deciding if resources on their site
reveal
the lock-discovery property.  If some clients are stealing tokens and this
is
resulting in trouble, the servers should not reveal lock tokens via
lock-discovery. 2518 allows them to determine their own policy.

As for the need to peak at ld to find a lock token if one (client) has
misplaced their's...
the server administrator needs to weigh this possibility against the
possibility
of token stealing.  That being said, the client can't count on that
property even
existing.  Or that it's absense means there are no locks on a given
resource.

BTW, was there some issue in this thread that needs to go on the issues
list?
</jlc>












From w3c-dist-auth-request@w3.org  Thu Jan 27 18:22:39 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16688
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 18:22:37 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA26417;
	Thu, 27 Jan 2000 18:18:00 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 18:18:00 -0500 (EST)
Resent-Message-Id: <200001272318.SAA26417@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: w3c-dist-auth@w3.org
MMDF-Warning:  Parse error in original version of preceding line at gremlin-relay.ics.uci.edu
Date: Thu, 27 Jan 2000 15:13:43 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJCEAFCNAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <10001271338.AA29281@tantalum>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: RE: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3978
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit


Geoff Clemm writes:
> Yes, authentication is mentioned in various places in the
> protocol, but there is no mention of an "authentication
> header" (neither a definition of its value nor how it is
> to be used).

The "Authorization" header is defined in RFC 2617, "HTTP Authentication:
Basic and Digest Access Authentication"
<http://www.ics.uci.edu/pub/ietf/http/rfc2617.txt>.  This is the Draft
Standard version of the Basic authentication information from RFC 2068, and
the Digest authentication information from RFC 2069.  Both of these
documents (RFC 2068 and RFC 2069) are normatively referenced from RFC 2518
(see especially section 17.1).  Furthermore, the locking examples in section
8.10.8, 8.10.9, and 8.10.10 use the Authorization header in the request
message to highlight the fact that authentication credentials must be
supplied.

There is no reference to a header named "authentication" in RFC 2518.

Greg Stein writes:
> That mechanism may or may not be a header, but the RFC
> is quite clear (in my mind) that simply holding a token
> is not enough. You must have the token and you must have
> the same authentication as that used when the lock was
> created. Given these two pieces of state, you are allowed
> to operate on the target resource.

This is correct.

Geoff Clemm writes:
> I agree that this is made stated in the protocol, but
> this is of limited value to a client since no interoperable
> mechanism for doing so is specified.

Section 17.1 states that, at minimum, Digest authentication must be
supported by all WebDAV applications, thus ensuring there exists at least
one interoperable mechanism for authentication.

Geoff Clemm writes:
> In addition, no authentication is required if no
> authentication was performed when the lock was
> created, so a client cannot count on any authentication
> taking place.

Well, at present RFC 2518 is silent on whether a server is allowed to create
a lock if no authentication credentials were presented during the lock
request.  There are good arguments either way: requiring them would make
locking more consistent, but allowing "anonymous" locking would enable
WebDAV clients to interact anonymously with a service, which could be a plus
for publically writeable pages.

But, if the server grants a lock to a specific authenticated principal, the
fact that it might also allow anonymous locking on that resource is
irrelevant.  Other principals will not be able to modify the resource while
the lock is being held by authenticated principal.  Any other behavior is an
error.

- Jim



From w3c-dist-auth-request@w3.org  Thu Jan 27 19:10:58 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17030
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 19:10:58 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id TAA27614;
	Thu, 27 Jan 2000 19:06:46 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 19:06:46 -0500 (EST)
Resent-Message-Id: <200001280006.TAA27614@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: WebDAV WG <w3c-dist-auth@w3.org>
Date: Thu, 27 Jan 2000 16:02:29 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJKEAICNAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <7DE119D3D0E15543874F7561EECBDBED0282B9A6@BEG.platinum.corp.microsoft.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: RE: WebDAV Bindings - Issue Yaron.AtomicDelete
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3979
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

Yaron,

An excellent, meaty, post.

It leaves me wondering, however, whether the inability to perform atomic
deletes is incompatible with the new bind delete language suggested by Judy
in her post (which doesn't use the word "atomic" at all):

http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0182.html

Or, put another way, how would Microsoft's likely implementation of bindings
interact with DELETE, and does that run into the atomic deletion semantics
you mention?

- Jim

Yaron Goland writes:
> The following is a summary of my conversations with
> Daniel Lovinger, technical lead for FAT in Windows NT
> and Brian Andrew, technical lead for NTFS. Any technical
> mistakes below are due to my own failure to properly
> understand what Dan and Brian told me.
>
> ... snip ...




From w3c-dist-auth-request@w3.org  Thu Jan 27 20:30:23 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17521
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 20:30:23 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA00346;
	Thu, 27 Jan 2000 20:26:11 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 20:26:11 -0500 (EST)
Resent-Message-Id: <200001280126.UAA00346@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A0F3@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'Geoffrey M. Clemm'" <geoffrey.clemm@rational.com>, w3c-dist-auth@w3.org
Date: Thu, 27 Jan 2000 17:19:14 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: RE: is DELETE "best effort"?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3980
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Bill the answer for RFC 2518 is an unequivocal YES.

What is being argued is if we should change that YES to a no. This will
require issuing a new version of RFC 2518.

Until such a new version is issued the answer is YES.

BTW, Geoff, RFC 2518 already supports having the server refuse to change any
of the members if it can't delete the root.

			Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com]
> Sent: Thu, January 27, 2000 2:02 PM
> To: w3c-dist-auth@w3.org
> Subject: Re: is DELETE "best effort"?
> 
> 
> 
> This topic is currently being hotly debated in the thread:
> "WebDAV Bindings - Issue Yaron.AtomicDelete"
> 
> Although 2518 currently implies "yes", the authors of the 
> BIND protocol
> extension have proposed that the answer be changed to "no".  
> Stay tuned (:-).
> 
> Minimally, we shall insist that a server be *allowed* to
> leave all member collections unmodified if it cannot delete
> the collection specified in the DELETE request.
> 
> Cheers,
> Geoff
> 
>    From: Yaron Goland <yarong@Exchange.Microsoft.com>
> 
>    Yes.
> 
>    > -----Original Message-----
>    > From: bill@carpenter.ORG [mailto:bill@carpenter.ORG]
>    > Sent: Thursday, January 27, 2000 11:46 AM
>    > To: w3c-dist-auth@w3.org
>    > Subject: is DELETE "best effort"?
>    > 
>    > 
>    > RFC-2518 doesn't come right out and say so, but I think 
> it implies
>    > that a DELETE on a collection is on a "best effort" 
> basis, where you
>    > can deduce what got DELETEd versus what didn't (and why) from a
>    > possible multistatus response.
>    > 
>    > Suppose I request a DELETE of /zoo/, where /zoo/ 
> contains /zoo/mammals
>    > and /zoo/birds.  Suppose there is a problem with the DELETE of
>    > /zoo/mammals (it's locked by my corporate rival, Snidely 
> Whiplash).
>    > Should the server, having discovered this, go ahead and attempt a
>    > DELETE of /zoo/birds?
>    > 
>    > Section 8.6.2 says that if you can't DELETE a resource, 
> you shouldn't
>    > DELETE its ancestors (for the sake of namespace 
> consistency).  It is
>    > silent on what you should do about the resource's 
> siblings, though
>    > (the example in 8.6.2 isn't bushy enough to show it).  
> There is a hint
>    > that some of the DELETEs may be allowed to succeed while 
> others fail
>    > in that 204 response codes are to be omitted from the multistatus
>    > because they are the default success code.
>    > 
>    > Is DELETE intended to be "best effort"?
>    > -- 
>    > bill@carpenter.ORG   (WJCarpenter)           PGP
>    > bill@bubblegum.net                    0x91865119
>    > 38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3
>    > 
> 



From w3c-dist-auth-request@w3.org  Thu Jan 27 21:02:16 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17766
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 21:02:16 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA00681;
	Thu, 27 Jan 2000 20:57:56 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 20:57:56 -0500 (EST)
Resent-Message-Id: <200001280157.UAA00681@www19.w3.org>
Date: Thu, 27 Jan 2000 17:57:55 -0800 (PST)
From: Greg Stein <gstein@lyra.org>
To: Yaron Goland <yarong@Exchange.Microsoft.com>
cc: w3c-dist-auth@w3.org
In-Reply-To: <7DE119D3D0E15543874F7561EECBDBED0282B9A6@BEG.platinum.corp.microsoft.com>
Message-ID: <Pine.LNX.4.10.10001271754380.9267-100000@nebula.lyra.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: WebDAV Bindings - Issue Yaron.AtomicDelete
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3981
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

On Thu, 27 Jan 2000, Yaron Goland wrote:
>...
> So the bottom line is that we can't implement an atomic delete and allow for
> multiple simultaneous file system access through multiple protocols. Since
> our users absolutely demand multiple simultaneous file system access through
> multiple protocols we can not implement atomic delete.

Although I do not agree with atomic delete, I do need to point out
something here (to be fair). You have introduced an extra requirement --
simultaneous access through different protocols. From a WebDAV standpoint,
NTFS and FAT can implement an atomic delete. If you partially delete a
tree, there is nothing requiring you to move it back: from the client's
standpoint, you *have* deleted the resources.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From w3c-dist-auth-request@w3.org  Thu Jan 27 21:31:52 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17986
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 21:31:52 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id VAA01775;
	Thu, 27 Jan 2000 21:27:39 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 21:27:39 -0500 (EST)
Resent-Message-Id: <200001280227.VAA01775@www19.w3.org>
Date: Thu, 27 Jan 2000 18:27:35 -0800 (PST)
From: Greg Stein <gstein@lyra.org>
To: "Slein, Judith A" <JSlein@crt.xerox.com>
cc: w3c-dist-auth@w3.org
In-Reply-To: <8E3CFBC709A8D21191A400805F15E0DBD2457D@crte147.wc.eso.mc.xerox.com>
Message-ID: <Pine.LNX.4.10.10001271804210.9267-100000@nebula.lyra.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: RE: WebDAV Bindings - Issue Yaron.AtomicDelete
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3982
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

On Thu, 27 Jan 2000, Slein, Judith A wrote:
> I think maybe we haven't made it clear what we are trying to accomplish by
> saying that DELETE must be atomic.  And maybe expressing it that way is
> confusing.  Here are the results we want (I think):

In the sense that "atomic delete" meant "integrity is retained during the
delete", then mod_dav has a problem.

It appears that you are removing the word "atomic" and replacing it with
more specific language on what "delete" means. This seems fine...

> 1. DELETE removes a single binding.  It does not remove all the bindings to
> a resource, only the one identified by the Request-URI.  If it happens to be
> the last binding, then what happens about garbage collection of either
> content or properties is outside the scope of the spec.  DELETE is just
> about removing the binding.

Not a problem *if* the server does not support bindings. As long as it is
understood there can be a race condition during the processing of the
DELETE operation.

> 2. In the case where the binding is to a collection, DELETE still means only
> remove the binding to that collection.

Again, not a problem.

> It is not acceptable to walk the
> tree deleting bindings to descendents of that collection.  This would have
> disastrous consequences in an environment with multiple bindings to
> resources.

And this is the problem for both of the cases above. When bindings are
present, we've got problems. In a standard Unix file system, I can
implement bindings in one of three ways:

1) symbolic (soft) links
2) hard links
3) binding database plus custom URL translation

Note that hard links cannot operate across a "devices" and cannot be used
on directories (collections). These two restrictions pretty well obviate
(2), so we are left with (1) and (3). 

With symbolic links, there is no way to know if another resource is
referring to my "real" resource. If somebody deletes a resource and it is
just a symlink -- no problem. If the resource is an actual file or
directory, then how do I know if another resource is using it? For
scenario (1), I would have to retain a database of backpointers. If a
backpointer exists, then what do I do with the "real" resource? I must
then decide to move/rename the thing (or something).

(3) is simply a pain in the butt. It is essentially implementing a symlink
in the web server. It essentially records the backpointers mentioned in
the previous paragraph, but still doesn't solve the "what happens when the
'real' resource is deleted?"

A final option is to make *all* resources symlinks and put the actual
content somewhere else. This would require a database of reference-counts,
however. Maybe mixing with (3) to do the symlinking and refcounts might
work.

>...
> Does either of these restrictions cause problems for mod_dav?

Only in the presence of bindings. There would be a LOT of work to
correctly handle bindings and deletes.

To make it more easily implementable, I would need one of two items:

1) binding between collections is not allowed (this would allow hard
   links; I could live with the device restriction)

2) it is allowable to leave dangling references (a symlink to a "real"
   resource that has been deleted)


Neither of these are very appealing. As it stands, it appears that the
binding specification *requires* a database that maps URLs to resources
(outside of a standard web server's URL translation system).

If a database was required, then I simply wouldn't implement bindings all
that soon. But it *would* be possible.

[ I'm not suggesting that we punt/restrict features such as binding simply
  because particular filesystems cannot support the feature in question;
  I'm just saying that it will take longer to code... ]

The impossible part is guaranteeing that no race conditions exist during
the processing of the DELETE.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From w3c-dist-auth-request@w3.org  Thu Jan 27 22:30:04 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19202
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 22:30:04 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id WAA02387;
	Thu, 27 Jan 2000 22:17:53 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 22:17:53 -0500 (EST)
Resent-Message-Id: <200001280317.WAA02387@www19.w3.org>
Date: Thu, 27 Jan 2000 22:17:42 -0500
Message-Id: <10001280317.AA29825@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: 
	<7DE119D3D0E15543874F7561EECBDBED0261A0F3@BEG.platinum.corp.microsoft.com>
	(message from Yaron Goland on Thu, 27 Jan 2000 17:19:14 -0800)
Subject: Re: is DELETE "best effort"?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3983
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


   From: Yaron Goland <yarong@Exchange.Microsoft.com>

   Bill the answer for RFC 2518 is an unequivocal YES.

What concerns me is that the sequence:

"Is DELETE best effort?  YES."

will result in people believing that DELETE *must* be best effort,
i.e. a server is required to delete everything it can, even if it actually
knows (or could easily find out) that it cannot delete everything.

   What is being argued is if we should change that YES to a no. This will
   require issuing a new version of RFC 2518.
   Until such a new version is issued the answer is YES.

   BTW, Geoff, RFC 2518 already supports having the server refuse to change any
   of the members if it can't delete the root.

I agree that this behavior is not forbidden by rfc2518, but I also 
believe some implementors will misinterpret in one direction (i.e. DELETE 
must be all or nothing) or in the other direction (i.e. DELETE must
be best effort), so whatever answer we arrive at, we should make sure
it is clearly stated in the next rev of rfc2518.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Thu Jan 27 22:39:09 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20181
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 22:39:08 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id WAA02656;
	Thu, 27 Jan 2000 22:34:57 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 22:34:57 -0500 (EST)
Resent-Message-Id: <200001280334.WAA02656@www19.w3.org>
Date: Thu, 27 Jan 2000 19:34:57 -0800 (PST)
From: Greg Stein <gstein@lyra.org>
To: w3c-dist-auth@w3.org
In-Reply-To: <20000126221651.D374@ankh.dunno.local>
Message-ID: <Pine.LNX.4.10.10001271933060.9267-100000@nebula.lyra.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: Minor nits for redirectref-02
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3984
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

On Wed, 26 Jan 2000, Joe Orton wrote:
> 1) In the MKRESOURCE response status codes, 423 Locked and 507
> Insufficient storage are included; this seems unnecessary. 2518 specifies
> what these mean. You can't include the full set of valid status codes in
> responses to MKRESOURCE, else you'd have to include all the normal HTTP
> codes too, so why not just stick to new or changed codes?

I kind of like having "typical response" listed in there. It makes it a
bit easier to review expected responses given a certain set of conditions.

No biggy if they stay or go, but figured that I'd throw in an opinion :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From w3c-dist-auth-request@w3.org  Thu Jan 27 23:28:38 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20469
	for <webdav-archive@odin.ietf.org>; Thu, 27 Jan 2000 23:28:38 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id XAA03562;
	Thu, 27 Jan 2000 23:20:52 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 23:20:52 -0500 (EST)
Resent-Message-Id: <200001280420.XAA03562@www19.w3.org>
Date: Thu, 27 Jan 2000 23:20:42 -0500
Message-Id: <10001280420.AA29849@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <NDBBIKLAGLCOPGKGADOJCEAFCNAA.ejw@ics.uci.edu> (message from Jim
	Whitehead on Thu, 27 Jan 2000 15:13:43 -0800)
Subject: Re: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3985
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


   From: Jim Whitehead <ejw@ics.uci.edu>

   ... the locking examples in section
   8.10.8, 8.10.9, and 8.10.10 use the Authorization header in the request
   message to highlight the fact that authentication credentials must be
   supplied.

Hmmm.  Specification by example ... leaving the reader to inductively
derive the protocol from the examples.  (Note: this is intended
to be friendly, amusing sarcasm, not bitter, vicious sarcasm :-).

OK, I'll play along.  Then since the Authorization header is only used
in the LOCK and UNLOCK examples, but never used in any of the
(several) examples that specify the lock-token in an If header, a
naive reader would conclude that authentication via the Authorization
header is *not* required for use of the lock token, but rather only
when creating (LOCK) and deleting (UNLOCK) a lock.

   There is no reference to a header named "authentication" in RFC 2518.

Thankyou.  I will now stop beating that particular dead horse (:-).

   Geoff Clemm writes:
   > In addition, no authentication is required if no
   > authentication was performed when the lock was
   > created, so a client cannot count on any authentication
   > taking place.

   Well, at present RFC 2518 is silent on whether a server is allowed to create
   a lock if no authentication credentials were presented during the lock
   request.

In the past (e.g. the "atomic deletion" discussion), the principle of
"it is allowed unless it is explicitly forbidden" has been the general rule.
Applied here, silence would imply that it is acceptable to create a lock
with no authentication credentials.

   There are good arguments either way: requiring them would make
   locking more consistent,

"consistent" with ... ?

   but allowing "anonymous" locking would enable
   WebDAV clients to interact anonymously with a service, which could be a plus
   for publically writeable pages.

Yes.  And to emphasize, I am 100% in favor of authentication and ACL's,
I just believe the ACL's should be on *resources* and not associated
with lock tokens.  If a given principal is authorized to do something,
it's client shouldn't have to pointlessly gather up lock tokens for use
in an If header, since this provides no additional security.

   But, if the server grants a lock to a specific authenticated principal, the
   fact that it might also allow anonymous locking on that resource is
   irrelevant.  Other principals will not be able to modify the resource while
   the lock is being held by authenticated principal.  Any other behavior is an
   error.

As is made clear in rfc2518, restricting use of a lock-token to the
principal that requested the lock does not provide overwrite protection,
since a principal can have *multiple* clients acting on his behalf.
The only reason for having lock-tokens is to provide overwrite protection,
and overwrite protection requires that a lock-token be only used by
the *client* (not the principal) that created the lock-token.
So the fact that your client is acting on behalf of a certain principal
is irrelevant to the proper use of lock-tokens.  What matters is that
a client only uses lock-tokens that it has issued.

Alternatively, if clients aren't going to restrict themselves to using
the lock tokens that they created via LOCK, but will grab any
lock-token that was created by their principal, then there is no
reason to have the complexity of lock-tokens in the protocol.

Note: Overwrite protection is the only reason I've ever heard for a
lock-token.  Perhaps there is some other reason I haven't heard yet?

Now there is a completely different question of how you deal with
malicious or non-cooperating clients.  My answer would be with ACL's,
since you need to keep the resource open for editing by trusted
principals while closed to non-trusted principals.  Lock-tokens are
totally irrelevant here.

So to summarize my position:
- Locking with lock tokens is a good thing, and provides merge avoidance
for cooperating clients.
- ACL's on resources is a good thing, and provides protection against
malicious or unauthorized clients.
- using locks to "fake" acl's on resources produces confusion, since
a client doesn't know whether a lock is there to prevent merge avoidance
(i.e. it shouldn't steal it), or is there to fake an ACL (it is
welcome to steal it if you are the principal that requested the lock).

I'm not sure how much farther we can converge via email ... perhaps a
conference call would be in order (in all our copious spare time :-).

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Fri Jan 28 00:00:43 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21053
	for <webdav-archive@odin.ietf.org>; Fri, 28 Jan 2000 00:00:43 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id XAA04088;
	Thu, 27 Jan 2000 23:56:13 -0500 (EST)
Resent-Date: Thu, 27 Jan 2000 23:56:13 -0500 (EST)
Resent-Message-Id: <200001280456.XAA04088@www19.w3.org>
Date: Thu, 27 Jan 2000 23:56:05 -0500
Message-Id: <10001280456.AA29872@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: 
	<7DE119D3D0E15543874F7561EECBDBED02619E1C@BEG.platinum.corp.microsoft.com>
	(message from Yaron Goland on Sun, 16 Jan 2000 17:43:14 -0800)
Subject: Re: WebDAV Bindings - Issue Yaron.AtomicMove
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3986
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


   From: Yaron Goland <yarong@Exchange.Microsoft.com>

   The last paragraph of section 8 reads: "Although [WebDAV] allows a MOVE on a
   collection to be a non-atomic operation, the MOVE operation defined here
   MUST be atomic.  Even when the Request-URI identifies a collection, the MOVE
   operation involves only removing one binding to that collection and adding
   another.  There are no operations on bindings to any of its children, so the
   case of MOVE on a collection is the same as the case of MOVE on a
   non-collection resource.  Both are atomic."

   As there is no way to tell the difference between a URI that was mapped
   through a BIND method and a URI that was mapped through a MKCOL the effect
   of this paragraph is to re-write RFC 2518 to make MOVE atomic.

Agreed.

   The issue
   here is largely a repeat of the issues addressed in Yaron.AtomicDelete.

Not really.  As you point out in the AtomicDelete thread, unlike
DELETE, MOVE is atomic in the NT (and all Unix) file systems,
as long as you stay in the same file volume/partition/whatever.
So the real question is whether the server should automatically
turn a MOVE into a COPY/DELETE (which is harder to make atomic),
or should it fail the MOVE and let the client decide whether it
wants to simulate the MOVE with a COPY/DELETE.

An argument for saying that the client should decide (and not
have the server automatically do it), is that a COPY/DELETE is
often significantly different from a "real" MOVE wrt bindings
(e.g. hard links), ACL's, cost of the operation, and other issues.

A client may of course present the:
  MOVE else { COPY; DELETE }
sequence as a single logical operation to its user, but that should
be a client decision, not hard-wired into the protocol.

Cheers,
Geoff




From w3c-dist-auth-request@w3.org  Fri Jan 28 09:30:31 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12050
	for <webdav-archive@odin.ietf.org>; Fri, 28 Jan 2000 09:30:28 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id JAA15823;
	Fri, 28 Jan 2000 09:25:47 -0500 (EST)
Resent-Date: Fri, 28 Jan 2000 09:25:47 -0500 (EST)
Resent-Message-Id: <200001281425.JAA15823@www19.w3.org>
Date: Fri, 28 Jan 2000 09:25:36 -0500
Message-Id: <10001281425.AA00013@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <200001271202.aa15135@gremlin-relay.ics.uci.edu>
	(fielding@kiwi.ICS.UCI.EDU)
Subject: Re: WebDAV Bindings - Issue Yaron.AtomicDelete
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3987
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


Thanks for the explanation.  By "state" I just meant "the set of
bindings", but I see how a non-clairvoyant reader would not know
this.  Just to confirm that I understood your point, would this
rewording be acceptable:

"A successful DELETE removes the specified binding from the specified
 collection, but (whether it succeeds or fails) MUST NOT remove any
 other other bindings from the specified collection or any other collection."

Cheers,
Geoff

   From: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>

   In message <10001271914.AA29510@tantalum>, "Geoffrey M. Clemm" writes:
   >   >"A DELETE modifies the state of the collection resource containing the
   >   >specified binding (namely, by deleting that binding), but MUST NOT
   >   >modify the state of any other collection resource as a side effect."
   >
   >   No, that is a requirement on the implementation, not the protocol.
   >   Why don't you just use the two paragraphs that Judy listed?
   >
   >I like Judy's two paragraphs, so that's fine with me.
   >
   >Just for interests sake, since my rewording was intended to be just
   >state the key point from Judy's two paragraphs, what was wrong with
   >it?  Doesn't a protocol always defines requirements on the
   >implementation?  (I'm not disagreeing with you, I just didn't
   >understand your point.)

   A protocol requires that the externally visible behavior of the
   component match that expected by the protocol.  The way you phrased
   it was specifying the state within the collection component rather
   than what was visible to other components.  Consider, for example,
   that a hierarchical database implementation of collections might
   have dual-linked relations between sister collections, and thus
   deletion of one collection would have to effect another collection.

   The point being that we don't have to require anything beyond what
   the protocol means -- specifying anything beyond that is just overkill
   and tends to limit implementations unnecessarily.

   ....Roy



From w3c-dist-auth-request@w3.org  Fri Jan 28 09:37:34 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12444
	for <webdav-archive@odin.ietf.org>; Fri, 28 Jan 2000 09:37:33 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id JAA16248;
	Fri, 28 Jan 2000 09:33:14 -0500 (EST)
Resent-Date: Fri, 28 Jan 2000 09:33:14 -0500 (EST)
Resent-Message-Id: <200001281433.JAA16248@www19.w3.org>
Date: Fri, 28 Jan 2000 06:33:14 -0800 (PST)
From: Greg Stein <gstein@lyra.org>
To: w3c-dist-auth@w3.org
In-Reply-To: <0C5DFAE09D2A644D97C4830DFA90F02202D602@df-rocket.platinum.corp.microsoft.com>
Message-ID: <Pine.LNX.4.10.10001280631540.14382-100000@nebula.lyra.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: proxy interop page (was: WebDAV proxy problems)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3988
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

I've put together a page for this:

  http://www.webdav.org/other/proxy.html

And an item in the Recent News on the site home page.

Thank you everybody for the info. Please send me updates as you discover
them.

Cheers,
-g


On Thu, 27 Jan 2000, Lisa Lippert (Dusseault) wrote:
> Would this information be suitable on a page for the webdav.org site?  Might
> even put some pressure on proxy developers to support RFC 2518, and to allow
> their administrators to name additional methods that should be allowed over
> HTTP (e.g. so that new advanced collections or DASL commands can be added).
> 
> Lisa
> 
> -----Original Message-----
> From: Joe Orton [mailto:joe@orton.demon.co.uk]
> Sent: Thursday, January 27, 2000 5:10 AM
> To: Lisa Lippert (Dusseault)
> Cc: 'David Engberg'; w3c-dist-auth@w3.org
> Subject: Re: WebDAV proxy problems
> 
> 
> > I actually started collecting some information on this.  Since I don't
> have
> > testing resources for it, it's only hearsay, but here goes:
> > 
> > Known Proxies that support DAV
> > 
> >  - MS Proxy 2.0: Support for DAV is built-in to MS Proxy 2.0.
> >  - Squid: There is a patch for the Squid proxy server that adds support
> for
> > WebDAV (http://www.squid-cache.org/Versions/v2/2.2/bugs/).
> 
> Apache mod_proxy works fine too. IIRC Squid 2.3 will pass through the
> methods defined in 2518, but will still block methods it doesn't
> understand. 
> 
> joe
> 

-- 
Greg Stein, http://www.lyra.org/



From w3c-dist-auth-request@w3.org  Fri Jan 28 10:14:26 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14506
	for <webdav-archive@odin.ietf.org>; Fri, 28 Jan 2000 10:14:26 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id KAA17503;
	Fri, 28 Jan 2000 10:10:13 -0500 (EST)
Resent-Date: Fri, 28 Jan 2000 10:10:13 -0500 (EST)
Resent-Message-Id: <200001281510.KAA17503@www19.w3.org>
Date: Fri, 28 Jan 2000 10:09:59 -0500
Message-Id: <10001281509.AA00047@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: yarong@Exchange.Microsoft.com
Cc: w3c-dist-auth@w3.org, danlo@Exchange.Microsoft.com,
        brianan@Exchange.Microsoft.com
In-Reply-To: 
	<7DE119D3D0E15543874F7561EECBDBED0282B9A6@BEG.platinum.corp.microsoft.com>
	(message from Yaron Goland on Thu, 27 Jan 2000 12:23:10 -0800)
Subject: Re: WebDAV Bindings - Issue Yaron.AtomicDelete
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3989
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


Like Jim, I'd like to thank Yaron allocating out some non-existent
free time for pursuing this issue!  A few comments:

   From: Yaron Goland <yarong@Exchange.Microsoft.com>

   I explained to Brian and Dan that I needed to implement WebDAV over existing
   NTFS and FAT file systems and that it was critical that our WebDAV
   implementation allow for multiple simultaneous protocol access through
   NFS/Win32/SMB/FTP/WebDAV/etc.

I agree.  Note that this of course does not mean that a WebDAV
DELETE is anything like the operations called "delete" in any of
these other protocols.

Furthermore, I believe it is reasonable for a particular
protocol to provide access to only a subset of the repository.
In particular, it is reasonable to say that you can't point
WebDAV at the root of a file system, but only one level down.
This leaves a place to put "hidden" administrative or implementation
data (such as collections that have been DELETE'd but not yet
garbage collected).

   I asked them, given this requirement, if it
   would be possible to simulate an atomic delete by just moving the tree we
   wanted to delete and then begin the file-by-file delete.

   Both Brian and Dan agreed that the move operation is atomic and that this
   would allow one to make the entire sub-tree disappear from a particular
   point in the namespace in a single atomic act.

And as long as the place it was moved to was invisible to WebDAV access,
the "atomic" definition of DELETE is satisfied.

   However both Brian and Dan
   pointed out that the problems really begin once you have moved the tree. The
   both pointed out that if I insist on allowing multiple access to the files
   in question through WebDAV as well as FTP/SMB/NFS/Win32/etc. then it would
   be impossible to perform an atomic delete.
   The crux of the problem is that NFS, amongst others, does not necessarily
   refer to files using their path location. They often refer to files using
   File IDs which are completely independent of location. This means that the
   attempt to move the files from one part of the namespace to another in order
   to hide them won't work with NFS. NFS and similar systems will continue to
   be able to operate on the files, regardless of where they are moved to.

As long as these files are not visible to WebDAV clients, it doesn't matter
if other protocol operations continue to work on them.

   This means that even if the move on the sub-directory succeeds it is
   possible for a NFS client to come in and open (without the filesharedelete
   flag) or change the ACL on a file and hence prevent us from deleting the
   file.

That's OK, since the file is in the "invisible" location on the file
volume, it doesn't matter to WebDAV that some other protocol still has
access to those bits.  The file may also still exist in some backup
archive form on that host, and we don't care about that either.

   Even if we attempt to change the ACL on a file to prevent others from
   accessing the file another user with a File ID and a higher access can
   always override us. 

That's OK, as long as to a WebDAV client, it looked like the atomic delete
happened.

   The result is that the atomic move provided by the file system doesn't buy
   us much because it doesn't "hide" the files from everyone.

As indicated above, we can't guarantee that a DELETE will hide the files
from everyone.  In the case of multiple bindings, we are explicitly saying
that a DELETE doesn't even hide the file from WebDAV clients (i.e. they
can still see that file from any of the remaining bindings).

   This means that
   there is no way for us to be sure, once we begin actually deleting files,
   that we will successfully be able to delete all of this files.

If DELETE means that you no longer see the specified resource at the
specified URL, then we can successfully delete all the resources.  If
DELETE means that the bits are permanently erased from all possible
forms of access, then it is impossible to implement (in the presence
of backups, etc.).

   This then
   means that we can end up with a half deleted tree. A tree we can not
   subsequently move back after the failures because to do so would violate the
   atomic guarantee of an all-or-nothing delete.

By the "not visible at this URL" definition, a MOVE successfully performs
the delete.  Garbage collecting the space after the DELETE is not something
the protocol should (or could) define.

   So the bottom line is that we can't implement an atomic delete and allow for
   multiple simultaneous file system access through multiple protocols. Since
   our users absolutely demand multiple simultaneous file system access through
   multiple protocols we can not implement atomic delete.

I think the key questions here is:

Does delete mean "this resource is no longer visible at this URL" (as
proposed in the bindings protocol), or "the bits in this resource are
permanently removed from all possible access".

If we pick the former definition (which is the only one that is
compatible with the needs of multiple bindings and versioning), I
believe it is clear that atomic delete is feasible.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Fri Jan 28 14:48:11 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25162
	for <webdav-archive@odin.ietf.org>; Fri, 28 Jan 2000 14:47:59 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA05106;
	Fri, 28 Jan 2000 14:43:27 -0500 (EST)
Resent-Date: Fri, 28 Jan 2000 14:43:27 -0500 (EST)
Resent-Message-Id: <200001281943.OAA05106@www19.w3.org>
From: Jim Whitehead <ejw@ics.uci.edu>
To: WebDAV WG <w3c-dist-auth@w3.org>
Date: Fri, 28 Jan 2000 11:39:02 -0800
Message-ID: <NDBBIKLAGLCOPGKGADOJCEBMCNAA.ejw@ics.uci.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <10001280420.AA29849@tantalum>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: RE: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3990
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

Geoff Clemm writes:
>    ... the locking examples in section
>    8.10.8, 8.10.9, and 8.10.10 use the Authorization header in the request
>    message to highlight the fact that authentication credentials must be
>    supplied.
>
> Hmmm.  Specification by example ... leaving the reader to inductively
> derive the protocol from the examples.  (Note: this is intended
> to be friendly, amusing sarcasm, not bitter, vicious sarcasm :-).

Actually, the ambiguity here is intentional.  If you look at RFC 2068, the
one aspect that looks the most dated after just a few years is the Basic
authentication information.  Since Basic is not secure, and while Digest is
better, but still not perfect, we felt that hardwiring the WebDAV
specification to any particular authentication mechanism would be a poor
design.  In particular, we did not want to mandate use of the Authorization
header (we mandate *support* for Digest, but not *use* of Digest), since it
seemed quite reasonable that some connection-layer security mechanism might
be developed that would handle authentication.  If this happened, it would
cause people to ignore a requirement in the WebDAV spec. to use some other
authentication mechanism.

Furthermore, looking into the future we saw technologies like smart cards,
fingerprint readers, retinals scans, etc., all of which could change how
authentication was performed in the protocol.  It really seemed like a
losing proposition to tightly specify the kind of authentication that was
used.  That's why the requirement to have both authentication information,
and the lock token submitted, was phrased that way it is at the bottom of
section 7.6.  I'll grant you that, looking at this section with a critical
eye, the wording could be improved, but I'll defend not explicitly stating
we should use the Authorization header all the time.

> OK, I'll play along.  Then since the Authorization header is only used
> in the LOCK and UNLOCK examples, but never used in any of the
> (several) examples that specify the lock-token in an If header, a
> naive reader would conclude that authentication via the Authorization
> header is *not* required for use of the lock token, but rather only
> when creating (LOCK) and deleting (UNLOCK) a lock.

Thanks for playing! :-)  Actually, by my count there are only four examples
in the specification where the If header is use in a full HTTP request:

Section 7.6.1: This example clearly states that authentication was performed
in the transport layer (via some SSL-like technology that performs
authentication)

Section 8.9.6: Also states the authentication was performed in the transport
layer.

Section 8.10.9: This example uses the Authorization header.

Section 9.4.2.1: In this case, no mention is made of authentication,
primarily because it is being used to describe the use of the If header
itself.  But, since this is a COPY operation, and the lock token is being
submitted for the source resource, there actually is no need to provide
authentication information, since the state of the source isn't modified on
a copy.

> Yes.  And to emphasize, I am 100% in favor of authentication and ACL's,
> I just believe the ACL's should be on *resources* and not associated
> with lock tokens.

I agree that access control should be an orthogonal issue to locking.

> If a given principal is authorized to do something,
> it's client shouldn't have to pointlessly gather up lock tokens for use
> in an If header, since this provides no additional security.

Just to make sure we're violently agreeing, lock tokens shouldn't be used
for access control, but should be used for merge avoidance.  Furthermore,
submission of authentication information (different from access permissions)
with a lock token is important, since it allows the server to ensure that
only the principal that took out a lock is permitted to modify a locked
resource.

> What matters is that
> a client only uses lock-tokens that it has issued.

OR, if it uses lock tokens issued to other clients operated by the same
principal, it does so with full knowledge that it could be causing an
overwrite conflict. This presumably involves informing the user of this
behavior (although the user probably already knows they're about to
overwrite their own work).  One driving scenario for this was to make sure
that someone could work on a document at work, then go home, decide they
want to work on that same document from home, and be able to.  Sure their
application will tell them they're about to overwrite their work, but this
is OK. It's what they want to do.

> Alternatively, if clients aren't going to restrict themselves to using
> the lock tokens that they created via LOCK, but will grab any
> lock-token that was created by their principal, then there is no
> reason to have the complexity of lock-tokens in the protocol.

You need lock tokens to identify the lock.  If a lock disappears underneath
a client, and then another client (operated by the same principal) takes out
a lock on the resource, then without lock tokens, the first client wouldn't
know that it would cause an overwrite if it wrote to the locked resource.
Using lock tokens, the client will be informed that the lock token isn't
valid, even though the resource is locked, and by the same principal.

> Note: Overwrite protection is the only reason I've ever heard for a
> lock-token.  Perhaps there is some other reason I haven't heard yet?

There are no other reasons I can think of.

> Now there is a completely different question of how you deal with
> malicious or non-cooperating clients.  My answer would be with ACL's,
> since you need to keep the resource open for editing by trusted
> principals while closed to non-trusted principals.  Lock-tokens are
> totally irrelevant here.

This scheme would work, but has several drawbacks.

You either:
(a) Allow everyone in the write set to have access to the resource, and they
negotiate out-of-band to prevent overwrite conflicts.  But, since DAV allows
people to be widely geographically dispersed, perhaps over several time
zones, I don't think its reasonable to assume that people in the write set
will always have perfect information about what their collaborators are
doing.  As soon as the information is incomplete, it leads either to
overwrites, or the need to merge.

(b) Dynamically alter the write set.  So, if, before I start work, Jane,
Fred, and I have access to a resource, I'll change the ACL list so that only
I have access to the resource, and I'll persistently store that Jane and
Fred used to have write access.  I'll do my work, and then once I'm done,
I'll re-add Jane and Fred back.  But, what happens if my client crashes, and
loses this information? Or, what happens if I leave work in the middle of an
edit session, get ill overnight, and then don't come into work for two days?
Or, even worse, what happens if the ACls are set by some kind of
administrative policy, and I don't even have permission to change the ACL
list?  These drawbacks, combined with the fact that it conflates the issues
of overwrite avoidance with access permissions (two separate issues), are
why I don't like this approach.


> So to summarize my position:
> - Locking with lock tokens is a good thing, and provides merge avoidance
> for cooperating clients.

Agreed.

> - ACL's on resources is a good thing, and provides protection against
> malicious or unauthorized clients.

Agreed.

> - using locks to "fake" acl's on resources produces confusion, since
> a client doesn't know whether a lock is there to prevent merge avoidance
> (i.e. it shouldn't steal it), or is there to fake an ACL (it is
> welcome to steal it if you are the principal that requested the lock).

Agreed (I think - devil's in the details :-).

- Jim



From w3c-dist-auth-request@w3.org  Fri Jan 28 16:21:02 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27428
	for <webdav-archive@odin.ietf.org>; Fri, 28 Jan 2000 16:21:02 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id QAA08665;
	Fri, 28 Jan 2000 16:16:44 -0500 (EST)
Resent-Date: Fri, 28 Jan 2000 16:16:44 -0500 (EST)
Resent-Message-Id: <200001282116.QAA08665@www19.w3.org>
From: ccjason@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: Yaron Goland <yarong@Exchange.Microsoft.com>
cc: w3c-dist-auth@w3.org, Daniel Lovinger <danlo@Exchange.Microsoft.com>,
        Brian Andrew <brianan@Exchange.Microsoft.com>
Message-ID: <85256874.0074BD85.00@D51MTA03.pok.ibm.com>
Date: Fri, 28 Jan 2000 16:14:01 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: WebDAV Bindings - Issue Yaron.AtomicDelete
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3991
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


>>
The crux of the problem is that NFS, amongst others, does not necessarily
refer to files using their path location. They often refer to files using
File IDs which are completely independent of location. This means that the
attempt to move the files from one part of the namespace to another in
order to hide them won't work with NFS. NFS and similar systems will
continue to be able to operate on the files, regardless of where they are
moved to.

This means that even if the move on the sub-directory succeeds it is
possible for a NFS client to come in and open (without the filesharedelete
flag) or change the ACL on a file and hence prevent us from deleting the
file. Even if we attempt to change the ACL on a file to prevent others from
accessing the file another user with a File ID and a higher access can
always override us.
>>
Super.  That's how NFS and a few of the file systems over which it often
gets implemented are supposed to work.    Once those files are opened, they
can be deleted from the name space and still accessed via their file
handle.   It's good to hear that that little subtlty would continue to
work.





From w3c-dist-auth-request@w3.org  Fri Jan 28 17:01:08 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28006
	for <webdav-archive@odin.ietf.org>; Fri, 28 Jan 2000 17:01:05 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id QAA09781;
	Fri, 28 Jan 2000 16:56:55 -0500 (EST)
Resent-Date: Fri, 28 Jan 2000 16:56:55 -0500 (EST)
Resent-Message-Id: <200001282156.QAA09781@www19.w3.org>
Date: Fri, 28 Jan 2000 13:56:54 -0800 (PST)
From: Greg Stein <gstein@lyra.org>
To: w3c-dist-auth@w3.org
Message-ID: <Pine.LNX.4.10.10001281356010.14382-100000@nebula.lyra.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: RE: WebDAV Bindings - Issue Yaron.AtomicDelete (fwd)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3992
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

I think Jason intended this for the list...

---------- Forwarded message ----------
Date: Fri, 28 Jan 2000 14:51:43 -0500
From: ccjason@us.ibm.com
To: Greg Stein <gstein@lyra.org>
Subject: RE: WebDAV Bindings - Issue Yaron.AtomicDelete



  Not a problem *if* the server does not support bindings. As long as it is
  understood there can be a race condition during the processing of the
  DELETE operation.

Obviously we wouldn't *want* a race condition, but it might have to be
acceptable.  BTW, do you already face a smaller race condition for single
resources? ...Yup, in your previous note I think you already said it was
also an issue.



>  Does either of these restrictions cause problems for mod_dav?

 Only in the presence of bindings. There would be a LOT of work to
 correctly handle bindings and deletes.

Yup.  Your list of options and analysis is good.  You'd probably also deny
loops just to keep the implementation easy.

You of course wouldn't be required to support
bindings, but market forces might demand it.  If so, you might have
a bunch of work to do and have to implement them with compromises.

>>
To make it more easily implementable, I would need one of two items:

1) binding between collections is not allowed (this would allow hard
   links; I could live with the device restriction)

2) it is allowable to leave dangling references (a symlink to a "real"
   resource that has been deleted)
>>
Of course I wouldn't *want* either of these.  I think (1) would be
acceptable.  Market forces might demand otherwise though.  Either
way, if this restriction becomes common, we probably should come
up with an error code for it.  (Yes, I can hear Yaron jumping up and down
right now, three timezones away.   "No New Status Codes!!!" :-))

I personally don't like the second option.  I'm not totally clear why yet.
It is contrary to our "integrity" belief for one thing.

>>
Neither of these are very appealing. As it stands, it appears that the
binding specification *requires* a database that maps URLs to resources
(outside of a standard web server's URL translation system).
>>
Yes, for Apache over *nix, to *fully* implement bindings, with file
structure most closely matching the URI structure, the use of a URI
"database"
or binding "database" or refcount "database" seems likely.


  If a database was required, then I simply wouldn't implement bindings all
  that soon. But it *would* be possible.

:-)


  [ I'm not suggesting that we punt/restrict features such as binding
simply
  because particular filesystems cannot support the feature in question;
  I'm just saying that it will take longer to code... ]

:-)

  The impossible part is guaranteeing that no race conditions exist during
  the processing of the DELETE.

I think a compromise there can be worked out and market forces can decide
the
issue.  I doubt folks will even notice this.






From w3c-dist-auth-request@w3.org  Sat Jan 29 11:10:20 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21075
	for <webdav-archive@odin.ietf.org>; Sat, 29 Jan 2000 11:10:20 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA26493;
	Sat, 29 Jan 2000 11:05:50 -0500 (EST)
Resent-Date: Sat, 29 Jan 2000 11:05:50 -0500 (EST)
Resent-Message-Id: <200001291605.LAA26493@www19.w3.org>
Date: Sat, 29 Jan 2000 15:19:09 +0000
From: Joe Orton <joe@orton.demon.co.uk>
To: w3c-dist-auth@w3.org
Cc: David Engberg <dave.engberg@driveway.com>
Message-ID: <20000129151909.H330@ankh.dunno.local>
Mail-Followup-To: w3c-dist-auth@w3.org,
	David Engberg <dave.engberg@driveway.com>
References: <7DE119D3D0E15543874F7561EECBDBED0261A0E6@BEG.platinum.corp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <7DE119D3D0E15543874F7561EECBDBED0261A0E6@BEG.platinum.corp.microsoft.com>; from yarong@Exchange.Microsoft.com on Thu, Jan 27, 2000 at 01:13:55PM -0800
Subject: Re: driveway.com / cadaver interop
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3994
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Does the WG still want to be seeing these reports?

Further testing against www.driveway.com: 

MKCOL fails with 500 internal server error, e.g.:

MKCOL /user.jorton/bar/ HTTP/1.1
User-Agent: cadaver/0.10.0
Connection: Keep-Alive
Host: www.driveway.com
Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxx

COPY returns 204, but doesn't actually copy anything: e.g.

COPY /user.jorton/foo.htm HTTP/1.1
User-Agent: cadaver/0.10.0
Connection: Keep-Alive
Host: www.driveway.com
Destination: http://www.driveway.com/user.jorton/bar.htm
Overwrite: F
Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxx

A GET or PROPFIND against a collection which doesn't exist returns 422,
should be 404.

Regards,

joe



From w3c-dist-auth-request@w3.org  Sat Jan 29 11:23:47 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21074
	for <webdav-archive@odin.ietf.org>; Sat, 29 Jan 2000 11:10:20 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA26461;
	Sat, 29 Jan 2000 11:05:41 -0500 (EST)
Resent-Date: Sat, 29 Jan 2000 11:05:41 -0500 (EST)
Resent-Message-Id: <200001291605.LAA26461@www19.w3.org>
Date: Sat, 29 Jan 2000 16:01:31 +0000
From: Joe Orton <joe@orton.demon.co.uk>
To: Yaron Goland <yarong@Exchange.Microsoft.com>
Cc: w3c-dist-auth@w3.org
Message-ID: <20000129160131.I330@ankh.dunno.local>
Mail-Followup-To: Yaron Goland <yarong@Exchange.Microsoft.com>,
	w3c-dist-auth@w3.org
References: <7DE119D3D0E15543874F7561EECBDBED0261A0E6@BEG.platinum.corp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <7DE119D3D0E15543874F7561EECBDBED0261A0E6@BEG.platinum.corp.microsoft.com>; from yarong@Exchange.Microsoft.com on Thu, Jan 27, 2000 at 01:13:55PM -0800
Subject: Re: driveway.com / cadaver interop
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3993
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

> That having been said, I wouldn't support specifying that a server MUST NOT
> return extra properties as I don't think this requirement would enhance
> interoperability and it would prevent some potentially useful scenarios.

The fact that the spec is silent on this point has caused this interop
problem; it needs to say something, whether it is MUST NOT or SHOULD NOT
or just a comment.

joe



From w3c-dist-auth-request@w3.org  Sat Jan 29 17:07:22 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23654
	for <webdav-archive@odin.ietf.org>; Sat, 29 Jan 2000 17:07:21 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id QAA00684;
	Sat, 29 Jan 2000 16:56:39 -0500 (EST)
Resent-Date: Sat, 29 Jan 2000 16:56:39 -0500 (EST)
Resent-Message-Id: <200001292156.QAA00684@www19.w3.org>
From: ccjason@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: Joe Orton <joe@orton.demon.co.uk>
cc: w3c-dist-auth@w3.org, David Engberg <dave.engberg@driveway.com>
Message-ID: <85256875.00788267.00@D51MTA03.pok.ibm.com>
Date: Sat, 29 Jan 2000 16:54:42 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: driveway.com / cadaver interop
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3995
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


> Does the WG still want to be seeing these reports?

Although I gloss over them for now, I like to have these compatibility and
bug reports handy in the archives for reference later.  So IMO, keep on
sending them.




From w3c-dist-auth-request@w3.org  Sat Jan 29 17:18:40 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23729
	for <webdav-archive@odin.ietf.org>; Sat, 29 Jan 2000 17:18:40 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id RAA00937;
	Sat, 29 Jan 2000 17:08:02 -0500 (EST)
Resent-Date: Sat, 29 Jan 2000 17:08:02 -0500 (EST)
Resent-Message-Id: <200001292208.RAA00937@www19.w3.org>
Date: Sat, 29 Jan 2000 21:48:16 +0000
From: Joe Orton <joe@orton.demon.co.uk>
To: w3c-dist-auth@w3.org
Message-ID: <20000129214816.A2773@ankh.dunno.local>
Mail-Followup-To: w3c-dist-auth@w3.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
Subject: Relative URIs in DAV:reftarget
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3996
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Section 9 of redirectref-02 talks about resolving relative URI's in
DAV:reftarget.

It talks about resolving them in the context of a MKRESOURCE request, and
gives an example of this, but I'm not sure why. This implies to me that
when a client submits a MKRESOURCE with a relative URI, the server will
resolve that URI immediately and store it in DAV:reftarget as an absolute
URI?

Of course, if you MOVE the reference resource, this is an important issue:
does the reftarget still point to the same place as before (if it was
resolved at the time of MKRESOURCE), or is it now used relative to the new
URI of the RR?

IMO the latter behaviour is strongly desired: if you have a deep
collection heirarchy with some relative cross-referencing amongst the
leaves of the tree, you want them to still work if you rename a top-level
collection. Unix symlinks are like this if you want some precedence. (I'm
not sure, but I don't think you can store relative targets in Windows
"shortcuts"?)

I think the most important point about relative URIs in DAV:reftarget is
that they must be resolved by the server when it returns the Location
header in a 302 response, since this must be absolute. Other than that,
the value of this property should be pretty opaque to the server, just
like any other dead property?

joe



From w3c-dist-auth-request@w3.org  Sat Jan 29 17:19:31 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23746
	for <webdav-archive@odin.ietf.org>; Sat, 29 Jan 2000 17:19:31 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id RAA00977;
	Sat, 29 Jan 2000 17:08:37 -0500 (EST)
Resent-Date: Sat, 29 Jan 2000 17:08:37 -0500 (EST)
Resent-Message-Id: <200001292208.RAA00977@www19.w3.org>
Date: Sat, 29 Jan 2000 22:06:13 +0000
From: Joe Orton <joe@orton.demon.co.uk>
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
Cc: w3c-dist-auth@w3.org
Message-ID: <20000129220613.B2773@ankh.dunno.local>
Mail-Followup-To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>,
	w3c-dist-auth@w3.org
References: <20000126220818.B374@ankh.dunno.local> <10001272145.AA29615@tantalum>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <10001272145.AA29615@tantalum>; from geoffrey.clemm@rational.com on Thu, Jan 27, 2000 at 04:45:28PM -0500
Subject: Re: Bodies of redirect reference resources
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3997
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

> The term "resource body" is often used as a shorthand for "what appears in
> a GET response body when applied to that resource".  That's what is intended
> here.  Is there a better term to use?

I don't think this term is needed at all ;) But, since you asked, 2616's
"entity-body" seems synonymous with that "what appears... " phrase.

>    So, if we have a redirect reference resource at URI X, when we try and
>    access it as any normal resource, it tells us to go to URI Y instead. But,
>    we can also, using a PUT with the Apply-To-RR header, submit an
>    entity-body, have it stored at this URI, then fetch it again later with a
>    GET and the same header. So, there are actually *two* separate resources
>    identified by URI X; the special RR resource, and the extra one we
>    submitted with the PUT.
> 
> Yes, there are two separate resources, the one at URI X and the one at URI Y.

To me, the "reference resource" should be a resource in its own right: a
conceptual thingy which say "No, go to URI Y instead", when you apply HTTP
methods to it. If you are trying to store an entity-body at URI X along
with this RR, then that is two separate resources, one which has the "No,
go to URI Y instead" semantics, and one which has the standard "I can
store an entity-body with PUT and give it back with GET" semantics.

Unix symlinks have precedent again here: you can't store a file in a
symlink. Windows shortcuts are the same, I expect.

>    Except that these two resources share the same
>    URI, and the same DAV properties.
> 
> No, the two separate resources have two separate URI's (X and Y)
> and two separate sets of properties.  The resource at X
> tells you to go look at the resource at Y, but X and Y are two separate
> URI's (unless X happens to be Y, which is possible, but not very useful :-).
> 
>    Is this really the intent of the
>    authors? Is there a need to store an extra resource along with every RR
>    resource?
> 
> The extra resource is minimally needed to store the information about
> what other resource to redirect to. 

What "information about the other resource" do you want to store? Why
can't you store it in the properties of the RR? To me the only vital
information you want to store in the RR is the target of the reference,
which you have as the DAV:reftarget property.

> It is useful to give the redirect
> reference additional properties as well, independent of whatever 
> properties are at the (current) target of the reference.

Agreed.

> We could do any of:
> - get rid of the "an RR resource can have a body" statement
> - get rid of this statement and change the example to say the PUT MUST fail.
> - keep the statement, and change the example to say the PUT updates the body
>   of the RR resource.
> 
> I could live with any of these choices.
[snip]
> 
> That's one vote for choice #3.  Anyone else?

Either you misunderstood, or miscounted :) I vote #2: get rid of any
mention of "resource body", and have PUT + GET fail with 4xx if the
Apply-To-RR header is included.

Regards,

joe



From w3c-dist-auth-request@w3.org  Sun Jan 30 23:56:33 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16522
	for <webdav-archive@odin.ietf.org>; Sun, 30 Jan 2000 23:56:32 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id XAA19871;
	Sun, 30 Jan 2000 23:45:27 -0500 (EST)
Resent-Date: Sun, 30 Jan 2000 23:45:27 -0500 (EST)
Resent-Message-Id: <200001310445.XAA19871@www19.w3.org>
Date: Sun, 30 Jan 2000 23:45:03 -0500
Message-Id: <10001310445.AA00914@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <20000129220613.B2773@ankh.dunno.local> (message from Joe Orton
	on Sat, 29 Jan 2000 22:06:13 +0000)
Subject: Re: Bodies of redirect reference resources
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3998
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

   From: Joe Orton <joe@orton.demon.co.uk>

   To me, the "reference resource" should be a resource in its own right: a
   conceptual thingy which say "No, go to URI Y instead", when you apply HTTP
   methods to it.

I agree.

   If you are trying to store an entity-body at URI X along
   with this RR, then that is two separate resources, one which has the "No,
   go to URI Y instead" semantics, and one which has the standard "I can
   store an entity-body with PUT and give it back with GET" semantics.

The presence of properties makes this a bit more ambiguous.  If you try
to get the properties of X, it will say "no, go to URI Y instead".  But
the RR X does have properties of its own, that you can obtain with the
Apply-To-RR header.  By analogy, it would be reasonable for X to have
an entity-body that you can obtain with the Apply-To-RR header. 
This doesn't convince me that RR resources should have entity-bodies,
but it is argument that it is reasonable to do so.

   Unix symlinks have precedent again here: you can't store a file in a
   symlink. Windows shortcuts are the same, I expect.

Yes.  I think this is a good argument against giving them a body ...
people will find this confusing, and experience in other domains indicate
that an entity body is not needed or appropriate for references.

   >    Is there a need to store an extra resource along with every RR
   >    resource?
   > 
   > The extra resource is minimally needed to store the information about
   > what other resource to redirect to. 

   What "information about the other resource" do you want to store? Why
   can't you store it in the properties of the RR? To me the only vital
   information you want to store in the RR is the target of the reference,
   which you have as the DAV:reftarget property.

I misunderstood you the first time.  By "extra resource", I meant the
RR resource itself.  You were talking about an extra resource *in addition*
to the RR resource.  I agree that there is no need for an extra resource
beyond the RR resource.  But the RR resource could have an entity body,
in addition to its properties.

   > We could do any of:
   > - get rid of the "an RR resource can have a body" statement
   > - get rid of this statement and change the example to say
   >   the PUT MUST fail.
   > - keep the statement, and change the example to say the PUT
   >   updates the body  of the RR resource.

   > That's one vote for choice #3.  Anyone else?

   Either you misunderstood, or miscounted :)

Neither ... mistyped (:-).

   I vote #2: get rid of any mention of "resource body",
   and have PUT + GET fail with 4xx if the Apply-To-RR header is included.

So we've got a vote for *2*.  Anyone else?

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Mon Jan 31 02:46:27 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29599
	for <webdav-archive@odin.ietf.org>; Mon, 31 Jan 2000 02:46:27 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id CAA24286;
	Mon, 31 Jan 2000 02:34:59 -0500 (EST)
Resent-Date: Mon, 31 Jan 2000 02:34:59 -0500 (EST)
Resent-Message-Id: <200001310734.CAA24286@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A0FA@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'Joe Orton'" <joe@orton.demon.co.uk>
Cc: w3c-dist-auth@w3.org
Date: Sun, 30 Jan 2000 23:34:24 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: RE: driveway.com / cadaver interop
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3999
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Actually the spec is extremely clear on what to do with unexpected/unknown
elements - ignore them.


> -----Original Message-----
> From: Joe Orton [mailto:joe@orton.demon.co.uk]
> Sent: Sat, January 29, 2000 8:02 AM
> To: Yaron Goland
> Cc: w3c-dist-auth@w3.org
> Subject: Re: driveway.com / cadaver interop
> 
> 
> > That having been said, I wouldn't support specifying that a 
> server MUST NOT
> > return extra properties as I don't think this requirement 
> would enhance
> > interoperability and it would prevent some potentially 
> useful scenarios.
> 
> The fact that the spec is silent on this point has caused this interop
> problem; it needs to say something, whether it is MUST NOT or 
> SHOULD NOT
> or just a comment.
> 
> joe
> 



From w3c-dist-auth-request@w3.org  Mon Jan 31 02:51:08 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29622
	for <webdav-archive@odin.ietf.org>; Mon, 31 Jan 2000 02:51:08 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id CAA24392;
	Mon, 31 Jan 2000 02:40:22 -0500 (EST)
Resent-Date: Mon, 31 Jan 2000 02:40:22 -0500 (EST)
Resent-Message-Id: <200001310740.CAA24392@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E39@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'Slein, Judith A'" <JSlein@crt.xerox.com>,
        "'Greg Stein'"
	 <gstein@lyra.org>, ccjason@us.ibm.com
Cc: w3c-dist-auth@w3.org, Brian Andrew <brianan@Exchange.Microsoft.com>
Date: Sun, 30 Jan 2000 23:39:48 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV Bindings - Issue Yaron.AtomicDelete
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4000
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

Firstly, although I still need to see the final language the proposal Judy
makes is fine with me. Obviously in the case of file system based
implementations if you try a delete on a collection with members without a
depth infinity header then you will get an error. However, assuming that the
atomic language will be replaced with Judy's language without any mention of
the word "atomic" then I am ready to consider this issue closed baring
review of the final spec.

Secondly, below I explain how linking works in NTFS. This is mostly FYI but
several people have asked me about this issue so I decided to find out the
answer. The following info comes from our NTFS guru Brian Andrew. Again, any
technical mistakes are my fault.

NTFS supports hard links to files ONLY. NTFS actually implements hard links
as bindings (their term) and all bindings are equal. So, for example, if I
create the file c:/foo/bar and then create a link c:/icky to c:/foo/bar then
I can delete c:/foo/bar and the file will still be around and pointed to by
c:/icky. So, in so far as I can tell, our hard link behavior for files works
exactly the way the BIND spec wants it to work.

NTFS supports symbolic links to directories ONLY. A symbolic link is an
actual file whose contents are the file location of a  directory. The file
system at a really deep level understands that the file is a symbolic link
so all the normal file commands will work properly, including commands from
older programs that don't know anything about a symbolic link. However if I
create a directory c:/di/rectory and create a symbolic link (called a
Junction in NTFS language) to c:/some/other and then delete c:/di/rectory
then c:/some/other will still exist but will return an error when
de-referenced. However one can still refer to c:/some/other even though
c:/di/rectory no longer exists. Also, there is no way to find out from
c:/di/rectory that the junction c:/some/other exists.

I asked Brian why we choose not to implement hard links to directories. He
said that detecting loops was extremely expensive, especially during
CHECKDISK operations. He said that while Junctions could be used to create
loops because everything was late bound and there were no consistency
guarantees it wasn't felt that they needed to actually find junction loops.
He also said that they were never able to get consensus on what to do when a
loop was found, although this issue was secondary to the expensive of
finding the loops in the first place. As such hard links to directories will
not be added in the foreseeable future.

My assumption therefore is that out NTFS DAV implementation will either not
implement the BIND spec or will only implement BIND for non-collection
resources. We will give some 5xx error for requests for a BIND to a
collection. I am extremely concerned about the effect of the 5xx strategy on
interoperability. However the expensive of dealing with loops is so high
that we can't just "suck it up" and make NTFS handle hard links to
directories. So this means that we either leave out BIND all together or use
the 5xx strategy. Both leave a bad taste in my mouth.

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Thu, January 27, 2000 8:01 AM
> To: 'Greg Stein'; ccjason@us.ibm.com
> Cc: w3c-dist-auth@w3.org
> Subject: RE: WebDAV Bindings - Issue Yaron.AtomicDelete
> 
> 
> I think maybe we haven't made it clear what we are trying to 
> accomplish by
> saying that DELETE must be atomic.  And maybe expressing it 
> that way is
> confusing.  Here are the results we want (I think):
> 
> 1. DELETE removes a single binding.  It does not remove all 
> the bindings to
> a resource, only the one identified by the Request-URI.  If 
> it happens to be
> the last binding, then what happens about garbage collection of either
> content or properties is outside the scope of the spec.  
> DELETE is just
> about removing the binding.
> 
> 2. In the case where the binding is to a collection, DELETE 
> still means only
> remove the binding to that collection.  It is not acceptable 
> to walk the
> tree deleting bindings to descendents of that collection.  
> This would have
> disastrous consequences in an environment with multiple bindings to
> resources.  To resurrect an example of Jason's:
> 
> User UA uses URL /a/C/ to access collection coll1.  User UB 
> uses URL /b/C/
> to access the same collection.  Now suppose UA issues a 
> DELETE on /a/C/.
> What you want is for UB to be able to continue to use /b/C/ 
> to access the
> collection (and all its descendents).  So you can't go 
> deleting the bindings
> in coll1 to all its children.  All you want to do is remove 
> the binding
> a:(C->coll1) from collection /a/.
> 
> Does either of these restrictions cause problems for mod_dav?
> 
> --Judy
> 
> > -----Original Message-----
> > From: Greg Stein [mailto:gstein@lyra.org]
> > Sent: Friday, January 21, 2000 5:36 PM
> > To: ccjason@us.ibm.com
> > Cc: Yaron Goland; w3c-dist-auth@w3.org
> > Subject: Re: WebDAV Bindings - Issue Yaron.AtomicDelete
> > 
> > 
> > On Tue, 18 Jan 2000 ccjason@us.ibm.com wrote:
> > >...
> > > >>
> > >  There are, I freely admit, circumstances in which a client 
> > MUST be able to
> > > ensure that a DELETE is issued atomically. Clients in those 
> > cases will have
> > > to choose to not interoperate with many WebDAV servers in 
> > order to gain
> > > atomic delete.
> > > >>
> > > These clients can interoperate with an old iterative server 
> > just fine if
> > > they also include 2518 support.  That's their choice.
> > > 
> > > We have asked around and it seems that server authors 
> > appreciate and are
> > > willing to comply with semantic of an "atomic" removal of a 
> > single binding.
> > 
> > I don't recall being asked, nor agreeing with atomic 
> > operations. If that
> > binding happens to be a collection, then it will definitely 
> > be non-atomic.
> > 
> > [ also assuming this is the "final" removal of the collection ]
> > 
> > >...
> > > >>
> > > Let me clarify that DELETE was defined to not be atomic 
> > with malice of fore
> > > thought. The non-atomic delete language was the result of 
> > nearly three
> > > years of negotiations and represented a deep and broad 
> > consensus built up
> > > amongst a huge community. Might I respectfully suggest to 
> > the BIND authors
> > > that they should not be so ready to overthrow years of 
> > careful consensus
> > > building.
> > > >>
> > > We've asked around.  Folks appreciate this behavior and are 
> > willing to
> > > support it.
> > 
> > Again: I don't remember being asked. Maybe I missed a post to 
> > this list?
> > 
> > Regardless, I am not willing support atomic deletions of 
> > collections OR
> > single, member resources. Note that I mentioned member 
> > resources here. I
> > delete a member resource in two steps: the contents and its 
> > properties.
> > Definitely non-atomic.
> > 
> > And with respect to the Apache web server, I will not even 
> > begin to think
> > of making it atomic (e.g. serialize all requests while a 
> > resource is being
> > deleted).
> > 
> > > >>
> > > Do not imagine that the lack of screaming on this issue 
> > reflects consensus.
> > > Rather it reflects the fact that most of the WebDAV 
> > community is too busy
> > > implementing RFC 2518 to pay much attention to BIND. The BIND
> > > functionality, while I believe it will be important to 
> > WebDAV, is a bit
> > > ahead of the majority of implementers so they just aren't 
> reading or
> > > reviewing it, yet.
> > > >>
> > > We have asked around and we didn't accept silence as a response.
> > 
> > I was certainly silent. Either that, or I'm going senile and forget
> > responding to a question of atomicity. I certainly can't 
> > imagine replying
> > "sure, I can sure an atomic delete".
> > 
> > > >>
> > > The key reason DELETE was not allowed to be atomic (which 
> > certainly would
> > > have been a nice thing to be able to do) has to do with 
> the way file
> > > systems work. Most file systems do not support depth 
> > operations atomically.
> > > So, for example, when you delete a directory what actually 
> > happens is that
> > > the program does a depth first walk of the directory tree 
> > and deletes all
> > > the individual files, walking backwards up the tree until 
> > finally deleting
> > > the parent directory.
> > > >>
> > > You've pointed out that this is a problem on your file 
> > system.  We've found
> > > no other.   We've tested it and our testing indicates that 
> > the MOVE option
> > > you mention below works.  (We did not test with ACL's 
> > though... or multiple
> > > bindings.)    We've also contacted folks at your 
> > organization and they
> > > didn't see a problem.
> > 
> > This is an undue complication: generate a unique name, rename 
> > the resource
> > to that new name, then process its removal. And again, 
> > mod_dav couldn't
> > even do this because of its separation between properties and 
> > contents: I
> > could move the contents away, but a PROPFIND could still return
> > properties.
> > 
> > >...
> > > >>
> > > There is then the third and final issue, WebDAV begins with 
> > a "D" for a
> > > reason. It's goal is to be distributed. Requiring atomic 
> > DELETEs would
> > > essentially hinder all but the most expensive of systems 
> > from being able to
> > > implement distributed namespaces across multiple physical 
> > servers. The
> > > reason being that the atomic requirement means that these 
> > systems will have
> > > to establish transactioning systems between themselves in 
> > order to issue
> > > DELETEs if they share namespace.
> > > >>
> > > It's only one binding.  The goal isn't to be atomic, that's just a
> > > fortunate side effect.
> > 
> > It is *definitely* not a "side effect." mod_dav certainly 
> > does not do a
> > rename-then-delete. Therefore, I have to take explicit 
> > actions to achieve
> > that behavior. I don't even think that I could *ever* 
> > guarantee an atomic
> > DELETE operation.
> > 
> > >...
> > > >>
> > > As such I move that the atomic DELETE language be struck 
> > from the BIND spec
> > > on the grounds that it destroys interoperability, requires 
> > behavior that
> > > would preclude file system based systems from supporting 
> WebDAV and
> > > significantly increases the cost of implementing WebDAV in 
> > a distributed
> > > manner.
> > > >>
> > 
> > I agree with Yaron on this one. Strongly.
> > 
> > > I believe I've addressed all of these above.
> > > 
> > > It is very clear that DELETE should not be iterative or 
> > accept partial
> > > results in a server that supports multiple bindings.
> > 
> > I think it is very clear that it shouldn't.
> > 
> > Stating your opinion of clarity doesn't make it so, nor does 
> > mine. But I
> > certainly can tell you right now that I won't be one of the "example
> > implementations" required for an IETF Standard.
> > 
> > > Legacy clients may
> > > invoke DELETE without knowledge of the potential dangers.  
> > Therefore, a
> > > simple DELETE should delete a single binding.  --- There is 
> > no compelling
> > > reason (so far) not to support single binding delete and it 
> > simplifies the
> > 
> > I believe that I've given you one. With a good chunk of 
> extra work and
> > serialization within the server, then it might be possible. 
> > But I am not
> > really up for trying to figure it out.
> > 
> > Cheers,
> > -g
> > 
> > -- 
> > Greg Stein, http://www.lyra.org/
> > 
> 



From w3c-dist-auth-request@w3.org  Mon Jan 31 04:35:58 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00332
	for <webdav-archive@odin.ietf.org>; Mon, 31 Jan 2000 04:35:57 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id EAA26431;
	Mon, 31 Jan 2000 04:31:43 -0500 (EST)
Resent-Date: Mon, 31 Jan 2000 04:31:43 -0500 (EST)
Resent-Message-Id: <200001310931.EAA26431@www19.w3.org>
Message-ID: <007801bf6bcd$cd9a1c40$9a114498@us.oracle.com>
From: "Eric Sedlar" <esedlar@us.oracle.com>
To: "Yaron Goland" <yarong@Exchange.Microsoft.com>,
        "'Slein, Judith A'" <JSlein@crt.xerox.com>,
        "'Greg Stein'" <gstein@lyra.org>, <ccjason@us.ibm.com>
Cc: <w3c-dist-auth@w3.org>, "Brian Andrew" <brianan@Exchange.Microsoft.com>
References: <7DE119D3D0E15543874F7561EECBDBED02619E39@BEG.platinum.corp.microsoft.com>
Date: Mon, 31 Jan 2000 01:30:24 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Subject: Re: WebDAV Bindings - Issue Yaron.AtomicDelete
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4001
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
Content-Transfer-Encoding: 7bit

The loop detection problem is only necessary if you allow links to affect
the persistence of the linked-to item.  The other property of hard links
(not dangling, and moving with the destination) is probably more important
to users than persistence.  Hence the "weak binding".  Removing dangling
weak bindings is much easier than loop detection.

--Eric

----- Original Message -----
From: "Yaron Goland" <yarong@Exchange.Microsoft.com>
To: "'Slein, Judith A'" <JSlein@crt.xerox.com>; "'Greg Stein'"
<gstein@lyra.org>; <ccjason@us.ibm.com>
Cc: <w3c-dist-auth@w3.org>; "Brian Andrew" <brianan@Exchange.Microsoft.com>
Sent: Sunday, January 30, 2000 11:39 PM
Subject: RE: WebDAV Bindings - Issue Yaron.AtomicDelete


> Firstly, although I still need to see the final language the proposal Judy
> makes is fine with me. Obviously in the case of file system based
> implementations if you try a delete on a collection with members without a
> depth infinity header then you will get an error. However, assuming that
the
> atomic language will be replaced with Judy's language without any mention
of
> the word "atomic" then I am ready to consider this issue closed baring
> review of the final spec.
>
> Secondly, below I explain how linking works in NTFS. This is mostly FYI
but
> several people have asked me about this issue so I decided to find out the
> answer. The following info comes from our NTFS guru Brian Andrew. Again,
any
> technical mistakes are my fault.
>
> NTFS supports hard links to files ONLY. NTFS actually implements hard
links
> as bindings (their term) and all bindings are equal. So, for example, if I
> create the file c:/foo/bar and then create a link c:/icky to c:/foo/bar
then
> I can delete c:/foo/bar and the file will still be around and pointed to
by
> c:/icky. So, in so far as I can tell, our hard link behavior for files
works
> exactly the way the BIND spec wants it to work.
>
> NTFS supports symbolic links to directories ONLY. A symbolic link is an
> actual file whose contents are the file location of a  directory. The file
> system at a really deep level understands that the file is a symbolic link
> so all the normal file commands will work properly, including commands
from
> older programs that don't know anything about a symbolic link. However if
I
> create a directory c:/di/rectory and create a symbolic link (called a
> Junction in NTFS language) to c:/some/other and then delete c:/di/rectory
> then c:/some/other will still exist but will return an error when
> de-referenced. However one can still refer to c:/some/other even though
> c:/di/rectory no longer exists. Also, there is no way to find out from
> c:/di/rectory that the junction c:/some/other exists.
>
> I asked Brian why we choose not to implement hard links to directories. He
> said that detecting loops was extremely expensive, especially during
> CHECKDISK operations. He said that while Junctions could be used to create
> loops because everything was late bound and there were no consistency
> guarantees it wasn't felt that they needed to actually find junction
loops.
> He also said that they were never able to get consensus on what to do when
a
> loop was found, although this issue was secondary to the expensive of
> finding the loops in the first place. As such hard links to directories
will
> not be added in the foreseeable future.
>
> My assumption therefore is that out NTFS DAV implementation will either
not
> implement the BIND spec or will only implement BIND for non-collection
> resources. We will give some 5xx error for requests for a BIND to a
> collection. I am extremely concerned about the effect of the 5xx strategy
on
> interoperability. However the expensive of dealing with loops is so high
> that we can't just "suck it up" and make NTFS handle hard links to
> directories. So this means that we either leave out BIND all together or
use
> the 5xx strategy. Both leave a bad taste in my mouth.
>
> > -----Original Message-----
> > From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> > Sent: Thu, January 27, 2000 8:01 AM
> > To: 'Greg Stein'; ccjason@us.ibm.com
> > Cc: w3c-dist-auth@w3.org
> > Subject: RE: WebDAV Bindings - Issue Yaron.AtomicDelete
> >
> >
> > I think maybe we haven't made it clear what we are trying to
> > accomplish by
> > saying that DELETE must be atomic.  And maybe expressing it
> > that way is
> > confusing.  Here are the results we want (I think):
> >
> > 1. DELETE removes a single binding.  It does not remove all
> > the bindings to
> > a resource, only the one identified by the Request-URI.  If
> > it happens to be
> > the last binding, then what happens about garbage collection of either
> > content or properties is outside the scope of the spec.
> > DELETE is just
> > about removing the binding.
> >
> > 2. In the case where the binding is to a collection, DELETE
> > still means only
> > remove the binding to that collection.  It is not acceptable
> > to walk the
> > tree deleting bindings to descendents of that collection.
> > This would have
> > disastrous consequences in an environment with multiple bindings to
> > resources.  To resurrect an example of Jason's:
> >
> > User UA uses URL /a/C/ to access collection coll1.  User UB
> > uses URL /b/C/
> > to access the same collection.  Now suppose UA issues a
> > DELETE on /a/C/.
> > What you want is for UB to be able to continue to use /b/C/
> > to access the
> > collection (and all its descendents).  So you can't go
> > deleting the bindings
> > in coll1 to all its children.  All you want to do is remove
> > the binding
> > a:(C->coll1) from collection /a/.
> >
> > Does either of these restrictions cause problems for mod_dav?
> >
> > --Judy
> >
> > > -----Original Message-----
> > > From: Greg Stein [mailto:gstein@lyra.org]
> > > Sent: Friday, January 21, 2000 5:36 PM
> > > To: ccjason@us.ibm.com
> > > Cc: Yaron Goland; w3c-dist-auth@w3.org
> > > Subject: Re: WebDAV Bindings - Issue Yaron.AtomicDelete
> > >
> > >
> > > On Tue, 18 Jan 2000 ccjason@us.ibm.com wrote:
> > > >...
> > > > >>
> > > >  There are, I freely admit, circumstances in which a client
> > > MUST be able to
> > > > ensure that a DELETE is issued atomically. Clients in those
> > > cases will have
> > > > to choose to not interoperate with many WebDAV servers in
> > > order to gain
> > > > atomic delete.
> > > > >>
> > > > These clients can interoperate with an old iterative server
> > > just fine if
> > > > they also include 2518 support.  That's their choice.
> > > >
> > > > We have asked around and it seems that server authors
> > > appreciate and are
> > > > willing to comply with semantic of an "atomic" removal of a
> > > single binding.
> > >
> > > I don't recall being asked, nor agreeing with atomic
> > > operations. If that
> > > binding happens to be a collection, then it will definitely
> > > be non-atomic.
> > >
> > > [ also assuming this is the "final" removal of the collection ]
> > >
> > > >...
> > > > >>
> > > > Let me clarify that DELETE was defined to not be atomic
> > > with malice of fore
> > > > thought. The non-atomic delete language was the result of
> > > nearly three
> > > > years of negotiations and represented a deep and broad
> > > consensus built up
> > > > amongst a huge community. Might I respectfully suggest to
> > > the BIND authors
> > > > that they should not be so ready to overthrow years of
> > > careful consensus
> > > > building.
> > > > >>
> > > > We've asked around.  Folks appreciate this behavior and are
> > > willing to
> > > > support it.
> > >
> > > Again: I don't remember being asked. Maybe I missed a post to
> > > this list?
> > >
> > > Regardless, I am not willing support atomic deletions of
> > > collections OR
> > > single, member resources. Note that I mentioned member
> > > resources here. I
> > > delete a member resource in two steps: the contents and its
> > > properties.
> > > Definitely non-atomic.
> > >
> > > And with respect to the Apache web server, I will not even
> > > begin to think
> > > of making it atomic (e.g. serialize all requests while a
> > > resource is being
> > > deleted).
> > >
> > > > >>
> > > > Do not imagine that the lack of screaming on this issue
> > > reflects consensus.
> > > > Rather it reflects the fact that most of the WebDAV
> > > community is too busy
> > > > implementing RFC 2518 to pay much attention to BIND. The BIND
> > > > functionality, while I believe it will be important to
> > > WebDAV, is a bit
> > > > ahead of the majority of implementers so they just aren't
> > reading or
> > > > reviewing it, yet.
> > > > >>
> > > > We have asked around and we didn't accept silence as a response.
> > >
> > > I was certainly silent. Either that, or I'm going senile and forget
> > > responding to a question of atomicity. I certainly can't
> > > imagine replying
> > > "sure, I can sure an atomic delete".
> > >
> > > > >>
> > > > The key reason DELETE was not allowed to be atomic (which
> > > certainly would
> > > > have been a nice thing to be able to do) has to do with
> > the way file
> > > > systems work. Most file systems do not support depth
> > > operations atomically.
> > > > So, for example, when you delete a directory what actually
> > > happens is that
> > > > the program does a depth first walk of the directory tree
> > > and deletes all
> > > > the individual files, walking backwards up the tree until
> > > finally deleting
> > > > the parent directory.
> > > > >>
> > > > You've pointed out that this is a problem on your file
> > > system.  We've found
> > > > no other.   We've tested it and our testing indicates that
> > > the MOVE option
> > > > you mention below works.  (We did not test with ACL's
> > > though... or multiple
> > > > bindings.)    We've also contacted folks at your
> > > organization and they
> > > > didn't see a problem.
> > >
> > > This is an undue complication: generate a unique name, rename
> > > the resource
> > > to that new name, then process its removal. And again,
> > > mod_dav couldn't
> > > even do this because of its separation between properties and
> > > contents: I
> > > could move the contents away, but a PROPFIND could still return
> > > properties.
> > >
> > > >...
> > > > >>
> > > > There is then the third and final issue, WebDAV begins with
> > > a "D" for a
> > > > reason. It's goal is to be distributed. Requiring atomic
> > > DELETEs would
> > > > essentially hinder all but the most expensive of systems
> > > from being able to
> > > > implement distributed namespaces across multiple physical
> > > servers. The
> > > > reason being that the atomic requirement means that these
> > > systems will have
> > > > to establish transactioning systems between themselves in
> > > order to issue
> > > > DELETEs if they share namespace.
> > > > >>
> > > > It's only one binding.  The goal isn't to be atomic, that's just a
> > > > fortunate side effect.
> > >
> > > It is *definitely* not a "side effect." mod_dav certainly
> > > does not do a
> > > rename-then-delete. Therefore, I have to take explicit
> > > actions to achieve
> > > that behavior. I don't even think that I could *ever*
> > > guarantee an atomic
> > > DELETE operation.
> > >
> > > >...
> > > > >>
> > > > As such I move that the atomic DELETE language be struck
> > > from the BIND spec
> > > > on the grounds that it destroys interoperability, requires
> > > behavior that
> > > > would preclude file system based systems from supporting
> > WebDAV and
> > > > significantly increases the cost of implementing WebDAV in
> > > a distributed
> > > > manner.
> > > > >>
> > >
> > > I agree with Yaron on this one. Strongly.
> > >
> > > > I believe I've addressed all of these above.
> > > >
> > > > It is very clear that DELETE should not be iterative or
> > > accept partial
> > > > results in a server that supports multiple bindings.
> > >
> > > I think it is very clear that it shouldn't.
> > >
> > > Stating your opinion of clarity doesn't make it so, nor does
> > > mine. But I
> > > certainly can tell you right now that I won't be one of the "example
> > > implementations" required for an IETF Standard.
> > >
> > > > Legacy clients may
> > > > invoke DELETE without knowledge of the potential dangers.
> > > Therefore, a
> > > > simple DELETE should delete a single binding.  --- There is
> > > no compelling
> > > > reason (so far) not to support single binding delete and it
> > > simplifies the
> > >
> > > I believe that I've given you one. With a good chunk of
> > extra work and
> > > serialization within the server, then it might be possible.
> > > But I am not
> > > really up for trying to figure it out.
> > >
> > > Cheers,
> > > -g
> > >
> > > --
> > > Greg Stein, http://www.lyra.org/
> > >
> >
>
>



From w3c-dist-auth-request@w3.org  Mon Jan 31 06:35:11 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00960
	for <webdav-archive@odin.ietf.org>; Mon, 31 Jan 2000 06:35:10 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id GAA28792;
	Mon, 31 Jan 2000 06:30:47 -0500 (EST)
Resent-Date: Mon, 31 Jan 2000 06:30:47 -0500 (EST)
Resent-Message-Id: <200001311130.GAA28792@www19.w3.org>
From: jamsden@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <85256877.003BD702.00@d54mta03.raleigh.ibm.com>
Date: Sat, 29 Jan 2000 18:14:07 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: RE: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4002
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list



The current locking semantics allow multiple clients operating under the
same principal the flexibility of using the same lock tokens. This assumes
a single principal is more aware of their concurrent clients than say a
distributed work group. It does not however allow any other principal to
reuse the lock tokens. So although I agree with Geoff that locking and
access control are orthogonal issues, requiring principal+lock token is
useful, and not at odds with access control. Locks are an access control
mechanism no matter how one looks at them. They temporarily remove write
access to anyone not owning the lock. This seems quite reasonable and
doesn't necessarily have anything to do with ACLs. I guess I fail to see
the confusion.

Recall that the source of this issue is that the DAV:activelock element
does not contain the principal owning the lock. So there is no way for a
user to obtain the lock tokens they own through the DAV:lockdiscovery
property . I think this needs to be fixed. Otherwise, the semantics of
locking, with respect to  what is submitted for access, seem fine.




From w3c-dist-auth-request@w3.org  Mon Jan 31 08:06:17 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02291
	for <webdav-archive@odin.ietf.org>; Mon, 31 Jan 2000 08:06:17 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id IAA00832;
	Mon, 31 Jan 2000 08:01:54 -0500 (EST)
Resent-Date: Mon, 31 Jan 2000 08:01:54 -0500 (EST)
Resent-Message-Id: <200001311301.IAA00832@www19.w3.org>
From: jamsden@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <85256877.00477E42.00@d54mta03.raleigh.ibm.com>
Date: Mon, 31 Jan 2000 07:59:17 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4003
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list



<geoff>
As is made clear in rfc2518, restricting use of a lock-token to the
principal that requested the lock does not provide overwrite protection,
since a principal can have *multiple* clients acting on his behalf.
The only reason for having lock-tokens is to provide overwrite protection,
and overwrite protection requires that a lock-token be only used by
the *client* (not the principal) that created the lock-token.
So the fact that your client is acting on behalf of a certain principal
is irrelevant to the proper use of lock-tokens.  What matters is that
a client only uses lock-tokens that it has issued.

Alternatively, if clients aren't going to restrict themselves to using
the lock tokens that they created via LOCK, but will grab any
lock-token that was created by their principal, then there is no
reason to have the complexity of lock-tokens in the protocol.
</geoff>
<jra>
We're getting there. The reason for associating the lock token with a
principal is to give that principal the flexibility of running concurrent
clients that may update the same resource. Since not all these clients
actually locked the resource but got the lock token some other way, they
are aware that there might be other clients that have the same lock token
and can warn the principal before using the lock token to update a locked
resource. To enforce Geoff's semantics, that is to make locks more than
just advisory, the lock token would have to be associated with the
particular client application, and HTTP does not support such an identity.
So although I agree that complete overwrite protection would require all
clients to get their own lock token, I don't think this is an acceptable
solution because:

1. locks are only advisory, any client, including clients of another
principal can simply ignore them and overwrite the resource.

2. enforcing such locks would require specific client identification which
is not possible using HTTP.

3. Multiple clients run by the same principal would have to get there own
possibly exclusive write locks which would limit data availability by a
single principal who likely knows what they are doing at the moment, and if
it is safe to proceed with an update. For example, the principal may be
running many concurrent clients, but only one of them is active at a time.
The others are all waiting for input.

So I think associating the lock token with a principal is a reasonable and
useful compromise. It doesn't give absolute and complete overwrite
protection for multiple current clients run by the same principal, but it
does guarantee overwrite protection between principals.

Note that GULP R8 is consistent with associating principals with lock
tokens:

R8: If a resource has a write lock with target ".", a request cannot
modify the body or dead properties of that resource unless the
principal of the request owns a write lock with target "." on that
resource and the token of that write lock is specified in an IF
header.




From w3c-dist-auth-request@w3.org  Mon Jan 31 10:45:55 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07729
	for <webdav-archive@odin.ietf.org>; Mon, 31 Jan 2000 10:45:55 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id KAA07060;
	Mon, 31 Jan 2000 10:38:54 -0500 (EST)
Resent-Date: Mon, 31 Jan 2000 10:38:54 -0500 (EST)
Resent-Message-Id: <200001311538.KAA07060@www19.w3.org>
Date: Mon, 31 Jan 2000 10:37:24 -0500
Message-Id: <10001311537.AA01179@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <85256877.00477E42.00@d54mta03.raleigh.ibm.com>
	(jamsden@us.ibm.com)
Subject: Re: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4004
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


   From: jamsden@us.ibm.com

   <geoff>
   ... if clients aren't going to restrict themselves to using
   the lock tokens that they created via LOCK, but will grab any
   lock-token that was created by their principal, then there is no
   reason to have the complexity of lock-tokens in the protocol.
   </geoff>

   <jra>
   We're getting there. The reason for associating the lock token with a
   principal is to give that principal the flexibility of running concurrent
   clients that may update the same resource.

A principal can run concurrent clients that may update the same resource,
whether or not a lock token is associated with a principal.

   Since not all these clients
   actually locked the resource but got the lock token some other way, they
   are aware that there might be other clients that have the same lock token
   and can warn the principal before using the lock token to update a locked
   resource.

So every time such a client does a PUT/PROPPATCH to a "locked" resource,
it pops up a warning message saying "this might overwrite updates pending
in other clients working on your behalf, but I have no idea whether it
does or not because we use each others' lock tokens".  This is not a
behavior for which I would deliberately design a protocol.

Alternatively, the clients could be written to first UNLOCK a resource that
was locked by some other client, and then that other client (whether it
belonged to you or some other principal) would know this has occurred as
soon as it tries to make its next update, and could then notify that other
client's user that a merge conflict has occurred because someone
UNLOCK'ed your lock.

   ...
   3. Multiple clients run by the same principal would have to get there own
   possibly exclusive write locks which would limit data availability by a
   single principal who likely knows what they are doing at the moment, and if
   it is safe to proceed with an update. For example, the principal may be
   running many concurrent clients, but only one of them is active at a time.
   The others are all waiting for input.

As a side note, "shared locks" are just, well, to be blunt, silly.
RFC2518 says you can take out a shared lock if you are a "principal
with appropriate access".  But if you are a principal with appropriate
access, you should just UNLOCK the resource and take out your own
exclusive lock on it.  This gives you all the benefits of "shared
locks", without losing the overwrite protection of exclusive locks.
Perhaps "silly" is a bit harsh ... or perhaps it is not harsh enough (:-).

Now as for the limiting data availability, how does the need to first
UNLOCK a locked-by-another client resource limit data availability?
Your client confirms (by asking you) that you really want to "steal" the
resource from another client (using the DAV:owner field to give a more
informative message), then UNLOCKs the resource, and then LOCKs
the resource to get its own locktoken.

I believe that you are try to get ACL behavior out of locktokens ...
I'd prefer to use ACL's to get ACL behavior (:-).  An ACL lets
you control which principals have write access to a resource (to prevent
damage from "hostile" principals), while locktokens lets cooperating
clients avoid merge conflicts.  An ACL is resource based and associated
with principals; a locktoken is URL-based and associated with clients.

   So I think associating the lock token with a principal is a reasonable and
   useful compromise. It doesn't give absolute and complete overwrite
   protection for multiple current clients run by the same principal, but it
   does guarantee overwrite protection between principals.

Associating a lock token with a principal is both too strong (it prevents
another principal with the same or higher access rights from authoring
that resource) and is too weak (it doesn't help avoid merge conflicts
between clients acting on behalf of the same client).

If this approach were consistent with our future direction (associating
ACL's with resources), I'd be more willing to accept it, but it isn't.
Requiring that only a principal that issued a LOCK can cancel that LOCK
will conflict with any attempts to allow a wider "trust" group for
that operation.

   Note that GULP R8 is consistent with associating principals with lock
   tokens.

Yes, that has been fixed (:-).  All mention of a "principal" has been
removed from R8.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Mon Jan 31 11:08:25 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08419
	for <webdav-archive@odin.ietf.org>; Mon, 31 Jan 2000 11:08:25 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA08105;
	Mon, 31 Jan 2000 11:04:04 -0500 (EST)
Resent-Date: Mon, 31 Jan 2000 11:04:04 -0500 (EST)
Resent-Message-Id: <200001311604.LAA08105@www19.w3.org>
Date: Mon, 31 Jan 2000 11:03:32 -0500
Message-Id: <10001311603.AA01202@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <007801bf6bcd$cd9a1c40$9a114498@us.oracle.com>
	(esedlar@us.oracle.com)
Subject: Re: WebDAV Bindings - Issue Yaron.AtomicDelete
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4005
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list


   From: "Eric Sedlar" <esedlar@us.oracle.com>

   The loop detection problem is only necessary if you allow links to affect
   the persistence of the linked-to item.

You still need loop detection, because there always will be some type
of link that determines persistence, even if there are others that do not.

   The other property of hard links
   (not dangling, and moving with the destination) is probably more important
   to users than persistence.

Not to this user (:-). I put it into my collection because I wanted to
be able to reliably retrieve it from there in the future.  If I can't
be guaranteed of that behavior, I must have that BIND request fail,
and I'll probably just make a copy of the resource there instead.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Mon Jan 31 13:35:32 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12111
	for <webdav-archive@odin.ietf.org>; Mon, 31 Jan 2000 13:35:30 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA17035;
	Mon, 31 Jan 2000 13:30:54 -0500 (EST)
Resent-Date: Mon, 31 Jan 2000 13:30:54 -0500 (EST)
Resent-Message-Id: <200001311830.NAA17035@www19.w3.org>
From: jamsden@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: w3c-dist-auth@w3.org
Message-ID: <85256877.0065A3AF.00@d54mta03.raleigh.ibm.com>
Date: Mon, 31 Jan 2000 13:30:22 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: RFC-2518 LOCK-TOKEN: header
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4006
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list



I agree with everything Geoff says, but I still think lock-tokens alone
aren't enough. Geoff says lock-tokens should be associated with clients.
But the only way this can be done is if clients don't reuse some other
client's lock token, or arbitrarily unlock them and get their own lock
token. If all clients were well-behaved and only:
    - used lock tokens the obtained from LOCK to update resources
    - except on rare and well coordincate instances, only unlock resources
they locked
    - never used shared locks
then this would work. Do we want locks to be purly advisory like this? I
would be willing to consider it. I've just been working on the assumption
that we wanted the server to do more.

But I still think there is a problem. In Geoff's scheme, lock-tokens are
now associated (essentially and by convention) with the client that took
out the lock. But there's no way in HTTP for the client to identify itself,
and therefore no way for the server to remember what client took out the
lock. That's why the server can't ensure only the client that got the lock
can update the resource, not just any client that might have the lock
token. So again, there's no way for the client to determine what lock
tokens it took out (i.e., owns) through a DAV:lockdiscovery. We're back to
having clients have to persist their lock tokens someplace else. I was
hoping to avoid this by at least using a DAV:principal in the
DAV:activelock to find the locks a particular principal owns.






"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>@w3.org on 01/31/2000
10:37:24 AM

Sent by:  w3c-dist-auth-request@w3.org


To:   w3c-dist-auth@w3.org
cc:

Subject:  Re: RFC-2518 LOCK-TOKEN: header



   From: jamsden@us.ibm.com

   <geoff>
   ... if clients aren't going to restrict themselves to using
   the lock tokens that they created via LOCK, but will grab any
   lock-token that was created by their principal, then there is no
   reason to have the complexity of lock-tokens in the protocol.
   </geoff>

   <jra>
   We're getting there. The reason for associating the lock token with a
   principal is to give that principal the flexibility of running
concurrent
   clients that may update the same resource.

A principal can run concurrent clients that may update the same resource,
whether or not a lock token is associated with a principal.

   Since not all these clients
   actually locked the resource but got the lock token some other way, they
   are aware that there might be other clients that have the same lock
token
   and can warn the principal before using the lock token to update a
locked
   resource.

So every time such a client does a PUT/PROPPATCH to a "locked" resource,
it pops up a warning message saying "this might overwrite updates pending
in other clients working on your behalf, but I have no idea whether it
does or not because we use each others' lock tokens".  This is not a
behavior for which I would deliberately design a protocol.

Alternatively, the clients could be written to first UNLOCK a resource that
was locked by some other client, and then that other client (whether it
belonged to you or some other principal) would know this has occurred as
soon as it tries to make its next update, and could then notify that other
client's user that a merge conflict has occurred because someone
UNLOCK'ed your lock.

   ...
   3. Multiple clients run by the same principal would have to get there
own
   possibly exclusive write locks which would limit data availability by a
   single principal who likely knows what they are doing at the moment, and
if
   it is safe to proceed with an update. For example, the principal may be
   running many concurrent clients, but only one of them is active at a
time.
   The others are all waiting for input.

As a side note, "shared locks" are just, well, to be blunt, silly.
RFC2518 says you can take out a shared lock if you are a "principal
with appropriate access".  But if you are a principal with appropriate
access, you should just UNLOCK the resource and take out your own
exclusive lock on it.  This gives you all the benefits of "shared
locks", without losing the overwrite protection of exclusive locks.
Perhaps "silly" is a bit harsh ... or perhaps it is not harsh enough (:-).

Now as for the limiting data availability, how does the need to first
UNLOCK a locked-by-another client resource limit data availability?
Your client confirms (by asking you) that you really want to "steal" the
resource from another client (using the DAV:owner field to give a more
informative message), then UNLOCKs the resource, and then LOCKs
the resource to get its own locktoken.

I believe that you are try to get ACL behavior out of locktokens ...
I'd prefer to use ACL's to get ACL behavior (:-).  An ACL lets
you control which principals have write access to a resource (to prevent
damage from "hostile" principals), while locktokens lets cooperating
clients avoid merge conflicts.  An ACL is resource based and associated
with principals; a locktoken is URL-based and associated with clients.

   So I think associating the lock token with a principal is a reasonable
and
   useful compromise. It doesn't give absolute and complete overwrite
   protection for multiple current clients run by the same principal, but
it
   does guarantee overwrite protection between principals.

Associating a lock token with a principal is both too strong (it prevents
another principal with the same or higher access rights from authoring
that resource) and is too weak (it doesn't help avoid merge conflicts
between clients acting on behalf of the same client).

If this approach were consistent with our future direction (associating
ACL's with resources), I'd be more willing to accept it, but it isn't.
Requiring that only a principal that issued a LOCK can cancel that LOCK
will conflict with any attempts to allow a wider "trust" group for
that operation.

   Note that GULP R8 is consistent with associating principals with lock
   tokens.

Yes, that has been fixed (:-).  All mention of a "principal" has been
removed from R8.

Cheers,
Geoff






From w3c-dist-auth-request@w3.org  Mon Jan 31 19:56:26 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19146
	for <webdav-archive@odin.ietf.org>; Mon, 31 Jan 2000 19:56:25 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id TAA03103;
	Mon, 31 Jan 2000 19:51:38 -0500 (EST)
Resent-Date: Mon, 31 Jan 2000 19:51:38 -0500 (EST)
Resent-Message-Id: <200002010051.TAA03103@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E3B@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'Geoffrey M. Clemm'" <geoffrey.clemm@rational.com>, w3c-dist-auth@w3.org
Date: Mon, 31 Jan 2000 16:50:27 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: RE: is DELETE "best effort"?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4007
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

I agree that there is an issue here that requires further clarification.

The key here is user expectation. When a user issues a DELETE they need to
know if the result is either going to be a best effort delete or an atomic
delete. They need to know this before they issue the command, without this
knowledge then they can never be sure what the result of the command is.

For example, imagine a program that can walk a tree of source code, change
all the ACLs so as not to give the current user write permission to those
files and then start to compile the source code into various bits and pieces
of code, inside the local collections, before linking them together. When
the final result is done the program will then issue a depth infinity DELETE
in order to clean up. Because the ACLs have been changed the program is
counting on the fact that the only thing that will be deleted will be the
code files. However in a world where best effort isn't guaranteed the
program's assumption can fail. The server may refuse the DELETE because it
can't successfully delete all the files atomically (due to the ACLs) 

This means, in practice, programs must ALWAYS assume the absence of best
effort. This means that WebDAV will be inefficient since clients will be
required to issue individual deletes for all possible files. 

The previous situation is the worst of both worlds. Clients that need
best-effort can't depend on getting it so they must do file by file deletes.
Additionally clients that really want atomic behavior can't depend on
getting it so they will also have to do file by file deletes, although they
could try a depth delete first and then follow up with file by file if there
was an error. The race conditions and performance problems introduced by
file by file deletes (even with pipelining) are unacceptable.

Therefore I believe that the best effort issue identifies an
interoperability problem with WebDAV. We need to either guarantee best
effort or guarantee atomicity. But the current situation in which it could
be either is just a mess.

For reasons that seem to have already gained consensus we can not mandate
atomic delete. Therefore we are left with mandating best effort. Those
clients who wish to guarantee atomic delete behavior will need to use the
MAN mechanism with the DELETE method.

Therefore I propose that when we rev WebDAV we put in language mandating
best effort deletes.

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com]
> Sent: Thu, January 27, 2000 7:18 PM
> To: w3c-dist-auth@w3.org
> Subject: Re: is DELETE "best effort"?
> 
> 
> 
>    From: Yaron Goland <yarong@Exchange.Microsoft.com>
> 
>    Bill the answer for RFC 2518 is an unequivocal YES.
> 
> What concerns me is that the sequence:
> 
> "Is DELETE best effort?  YES."
> 
> will result in people believing that DELETE *must* be best effort,
> i.e. a server is required to delete everything it can, even 
> if it actually
> knows (or could easily find out) that it cannot delete everything.
> 
>    What is being argued is if we should change that YES to a 
> no. This will
>    require issuing a new version of RFC 2518.
>    Until such a new version is issued the answer is YES.
> 
>    BTW, Geoff, RFC 2518 already supports having the server 
> refuse to change any
>    of the members if it can't delete the root.
> 
> I agree that this behavior is not forbidden by rfc2518, but I also 
> believe some implementors will misinterpret in one direction 
> (i.e. DELETE 
> must be all or nothing) or in the other direction (i.e. DELETE must
> be best effort), so whatever answer we arrive at, we should make sure
> it is clearly stated in the next rev of rfc2518.
> 
> Cheers,
> Geoff
> 



From w3c-dist-auth-request@w3.org  Mon Jan 31 20:23:56 2000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19663
	for <webdav-archive@odin.ietf.org>; Mon, 31 Jan 2000 20:23:51 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA04384;
	Mon, 31 Jan 2000 20:19:36 -0500 (EST)
Resent-Date: Mon, 31 Jan 2000 20:19:36 -0500 (EST)
Resent-Message-Id: <200002010119.UAA04384@www19.w3.org>
Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A10A@BEG.platinum.corp.microsoft.com>
From: Yaron Goland <yarong@Exchange.Microsoft.com>
To: "'Kaelin Colclasure'" <kaelin@everest.com>,
        Jim Whitehead
	 <ejw@ics.uci.edu>, w3c-dist-auth@w3.org
Date: Mon, 31 Jan 2000 17:18:54 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Jini Distributed Leasing Specification (was Re: timeout types 	)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/4008
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list

I must be missing something. Both points made below (that you can ask for
what you want and get back what the server decides to give and that renewal
is an explicit act) are already provided in WebDAV.

> -----Original Message-----
> From: Kaelin Colclasure [mailto:kaelin@everest.com]
> Sent: Mon, January 24, 2000 12:01 PM
> To: Jim Whitehead; w3c-dist-auth@w3.org
> Subject: Re: Jini Distributed Leasing Specification (was Re: timeout
> types)
> 
> 
> ----- Original Message -----
> From: Jim Whitehead <ejw@ics.uci.edu>
> To: Kaelin Colclasure <kaelin@everest.com>; <w3c-dist-auth@w3.org>
> Sent: Monday, January 24, 2000 11:47 AM
> Subject: RE: Jini Distributed Leasing Specification (was Re: 
> timeout types)
> 
> 
> > Well, I was not familiar with Jini leases, so I took a 
> quick look through
> > the spec. you referenced.  As near as I can tell, there are many
> > similarities between the semantics for Jini leases and 
> WebDAV locks.  Jini
> > leases allow an object to request a lease that lasts 
> forever, or for a
> > specific time period, similar to WebDAV locks which can be 
> requested for a
> > specific time period in seconds, or with the value "Infinite".  Jini
> leases
> > can be refreshed, as can WebDAV locks, by re-requesting the 
> lock. Jini
> > leases can be canceled before the time period ends, as can 
> WebDAV locks,
> > using the UNLOCK method.
> >
> > Was there some specific Jini lease semantic that you 
> particularly think
> > WebDAV would benefit from?
> 
> Yes.
> 
>  a) You can request an "infinite" lease, but you must be 
> prepared for the
>     server to return to you instead a finite lease. You must 
> then renew that
>     lease before it expires if you want it to persist without 
> interruption.
>  b) The renewal of the lease is an explicit action on the part of the
> client,
>     and is required to occur within a specific time interval. 
> There is no
>     implicit anything.
> 
> This is, IMHO, significantly less complicated to implement 
> robustly and
> correctly than implicit renewal. And of course, truly 
> infinite locks are
> highly suspect in a distributed environment. It could be argued that
> leases shouldn't permit them at all -- but it suffices to interpret
> "infinite" to mean "the longest period a server chooses to tolerate
> possibly holding a resource for a client that's never coming back."
> 
> -- Kaelin
> 
> --
> Become a Venture Technologist... <http://www.everest.com/careers/>
>