From w3c-dist-auth-request@w3.org  Sun Apr  4 15:20:48 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08750
	for <webdav-archive@lists.ietf.org>; Sun, 4 Apr 2004 15:20:47 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id C812AA1B8D; Sun,  4 Apr 2004 15:20:47 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id E61F8A1B8D
	for <w3c-dist-auth@listhub.w3.org>; Sun,  4 Apr 2004 15:20:45 -0400 (EDT)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAD9b-0000WN-N1
	for w3c-dist-auth@w3.org; Sun, 04 Apr 2004 15:19:35 -0400
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i34JJNEK004642 sender julian.reschke@gmx.de for w3c-dist-auth@w3.org; Sun, 4 Apr 2004 12:19:23 -0700
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by bandage.seagull.net (8.12.10) with SMTP id i34JJL6r004615 sender julian.reschke@gmx.de for <nnw3c-dist-auth___at___w3.org@smallcue.com>; Sun, 4 Apr 2004 12:19:21 -0700
Received: (qmail 17942 invoked by uid 65534); 4 Apr 2004 19:19:08 -0000
Received: from p3EE2475B.dip.t-dialin.net (EHLO gmx.de) (62.226.71.91) by mail.gmx.net (mp027) with SMTP; 04 Apr 2004 21:19:08 +0200
Message-ID: <40705F88.1010001@gmx.de>
Date: Sun, 04 Apr 2004 21:18:32 +0200
From: Julian Reschke <julian.reschke@gmx.de>
MIME-Version: 1.0
To: Jason Crawford <ccjason@us.ibm.com>
Cc: nnw3c-dist-auth___at___w3.org@smallcue.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Subject: Re: Please submit last call on draft-ietf-webdav-bind-05.txt
X-Archived-At: http://www.w3.org/mid/40705F88.1010001@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8410
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040404192047.C812AA1B8D@frink.w3.org>
Resent-Date: Sun,  4 Apr 2004 15:20:47 -0400 (EDT)


Jason Crawford wrote:

> We've addressed all issues brought up, right?  Count me as +1.

We did. Basically the issues raised here fell into three categories...:

1) Specific problems in the spec (those have been resolved in draft 05 
that we'd like to last-call).

2) General problems with the reference model introduced by the spec: the 
BIND spec specifies a very specific model; and this is the model it was 
supposed to specify. There are other possible models that behave slighty 
differently. One of them is the redirect reference model (separate 
spec), another is the "direct reference model" (that was mentioned in 
earlier versions of the REDIRECT spec, but as far as I can tell, nobody 
was interested to work on). There hasn't been any new discussion on this 
topic since Geoff's and my answers, so I'll assume it's resolved.

3) Issues with the organization and writing style of the spec. BIND 
adopts the same editorial style as RFC3253; and as there has been only 
one WG member finding problems with that, it seems that there's no 
change necessary. If more people feel differently about that, please 
speak up.

That being said, the draft really should be last-called -- it has been 
in this close-to-be-last-called state for quite some time now.

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Sun Apr  4 15:38:51 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09185
	for <webdav-archive@lists.ietf.org>; Sun, 4 Apr 2004 15:38:50 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 9E1E7A08AD; Sun,  4 Apr 2004 15:38:51 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id CD03CA08AD
	for <w3c-dist-auth@listhub.w3.org>; Sun,  4 Apr 2004 15:38:50 -0400 (EDT)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BADSD-0004lS-Sv
	for w3c-dist-auth@w3.org; Sun, 04 Apr 2004 15:38:49 -0400
Received: from ams-msg-core-1.cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 04 Apr 2004 11:48:49 +0000
X-BrightmailFiltered: true
Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202])
	by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i34Jbfsk000232;
	Sun, 4 Apr 2004 21:37:41 +0200 (MET DST)
Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Sun, 4 Apr 2004 21:38:14 +0200
Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(6.0.3790.0);
	 Sun, 4 Apr 2004 21:38:13 +0200
In-Reply-To: <40705F88.1010001@gmx.de>
References: <40705F88.1010001@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <9C1DEAC7-866F-11D8-AB6C-000A95B2B926@cisco.com>
Content-Transfer-Encoding: 7bit
Cc: w3c-dist-auth@w3.org, Jason Crawford <ccjason@us.ibm.com>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
Date: Sun, 4 Apr 2004 21:38:12 +0200
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-OriginalArrivalTime: 04 Apr 2004 19:38:13.0839 (UTC) FILETIME=[5E9645F0:01C41A7C]
Subject: Re: Please submit last call on draft-ietf-webdav-bind-05.txt
X-Archived-At: http://www.w3.org/mid/9C1DEAC7-866F-11D8-AB6C-000A95B2B926@cisco.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8411
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040404193851.9E1E7A08AD@frink.w3.org>
Resent-Date: Sun,  4 Apr 2004 15:38:51 -0400 (EDT)
Content-Transfer-Encoding: 7bit


On Apr 4, 2004, at 21:18, Julian Reschke wrote:

> 3) Issues with the organization and writing style of the spec. BIND 
> adopts the same editorial style as RFC3253; and as there has been only 
> one WG member finding problems with that, it seems that there's no 
> change necessary. If more people feel differently about that, please 
> speak up.

Let me phrase this differently:

Will two parties which only read the text in the spec be able to write 
code independent of each other which interoperate?

Is your view the answer to that question is 'Yes'?

     Patrik



From w3c-dist-auth-request@w3.org  Sun Apr  4 16:13:12 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09993
	for <webdav-archive@lists.ietf.org>; Sun, 4 Apr 2004 16:13:12 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E517BA0545; Sun,  4 Apr 2004 16:13:11 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 8DF45A087F
	for <w3c-dist-auth@listhub.w3.org>; Sun,  4 Apr 2004 16:13:08 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BADzQ-0002Lm-Aw
	for w3c-dist-auth@w3.org; Sun, 04 Apr 2004 16:13:08 -0400
Received: (qmail 16828 invoked by uid 65534); 4 Apr 2004 20:12:34 -0000
Received: from p3EE2475B.dip.t-dialin.net (EHLO gmx.de) (62.226.71.91)
  by mail.gmx.net (mp021) with SMTP; 04 Apr 2004 22:12:34 +0200
X-Authenticated: #1915285
Message-ID: <40706C0F.2060401@gmx.de>
Date: Sun, 04 Apr 2004 22:11:59 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
Cc: w3c-dist-auth@w3.org, Jason Crawford <ccjason@us.ibm.com>
References: <40705F88.1010001@gmx.de> <9C1DEAC7-866F-11D8-AB6C-000A95B2B926@cisco.com>
In-Reply-To: <9C1DEAC7-866F-11D8-AB6C-000A95B2B926@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: Please submit last call on draft-ietf-webdav-bind-05.txt
X-Archived-At: http://www.w3.org/mid/40706C0F.2060401@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8412
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040404201311.E517BA0545@frink.w3.org>
Resent-Date: Sun,  4 Apr 2004 16:13:11 -0400 (EDT)
Content-Transfer-Encoding: 8bit


Patrik Fältström wrote:

> Let me phrase this differently:
> 
> Will two parties which only read the text in the spec be able to write 
> code independent of each other which interoperate?
> 
> Is your view the answer to that question is 'Yes'?

I think the answer is "yes", if the reader indeed boths reads and 
understands the normative references as well.

Note that being more verbose has drawbacks, such as (1) reduced 
maintainability (if the same thing is described in different places) and 
(2) simply the size of the spec (I do remember the complaints about the 
length of the ACL spec; and BIND really really should be a simple spec).

Also note that "interoperate" doesn't mean the same thing to everybody. 
In a perfect world, every implementation will behave exactly the same 
(generally only the case for systems that have a single-source 
implementation such as Perl).

The BIND spec however simply can't invent new rules that are 
incompatible with it's base specs (HTTP, WebDAV...). So if things are 
already implementation-dependent for plain HTTP/WebDAV servers, things 
won't be different with BIND. That doesn't mean that software isn't 
interoperable; it just means that the spec in some cases simply has to 
allow different behaviours.

Remember that BIND doesn't introduce a new concept or model, the concepz 
of multiple URIs mapped to the same resource is already present in HTTP, 
WebDAV and DeltaV (RFC3233); all the spec adds is...:

- discoverability (is this the same resource as...? what bindings does 
this resource have...)

- explitic authorability (make a new binding exactly here...)

- specific new namespace operations where the HTTP/WebDAV-inherited 
methods (DELETE, MOVE) not always do the "right" thing for a BIND-aware 
system; and where the BIND spec couldn't change existing definitions 
(such as is a server allowed to do a "best-effort" MOVE?).

So there are scenarios where server implementations *will* vary, but 
this is because HTTP and WebDAV servers *do* vary, not because the 
authors couldn't do better.

For example: we've been asked to normatively specify the behaviour of 
HTTP ETags when bindings change. We simply can't, as there's an inherent 
conflict between the use case ETags were designed for (disambiguating 
represensations for the same URI), and the later addition of namespace 
operations in WebDAV. A server that doesn't have globally or at least 
server-wide unique ETags simply will have to do a fixup of ETags after 
namespace operations to prevent ETag collisions. There's nothing the 
BIND spec can do about that (however, the base spec RFC2518bis *should* 
recommend practices for selecting ETags that avoid this kind of 
post-namespace-op fixup).

Regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Apr  5 04:09:12 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16256
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 04:09:12 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 4B451A0E92; Mon,  5 Apr 2004 04:09:13 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id E8155A0E90
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 04:09:03 -0400 (EDT)
Received: from [217.5.201.10] (helo=greenbytes.de)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAPAD-0007PY-13
	for w3c-dist-auth@w3.org; Mon, 05 Apr 2004 04:09:01 -0400
Received: from [192.168.1.26] ([192.168.1.26])
	(authenticated user se@greenbytes.de)
	by greenbytes.de (greenbytes.de)
	(Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000006737.msg
	for <w3c-dist-auth@w3.org>; Mon, 05 Apr 2004 10:08:57 +0200
In-Reply-To: <9C1DEAC7-866F-11D8-AB6C-000A95B2B926@cisco.com>
References: <40705F88.1010001@gmx.de> <9C1DEAC7-866F-11D8-AB6C-000A95B2B926@cisco.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <7B360E86-86D8-11D8-86C0-00039384827E@greenbytes.de>
Content-Transfer-Encoding: quoted-printable
Cc: w3c-dist-auth@w3.org
From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Mon, 5 Apr 2004 10:08:54 +0200
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
X-Mailer: Apple Mail (2.613)
X-Authenticated-Sender: se@greenbytes.de
X-Spam-Processed: greenbytes.de, Mon, 05 Apr 2004 10:08:57 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 192.168.1.26
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3.org
Subject: Re: Please submit last call on draft-ietf-webdav-bind-05.txt
X-Archived-At: http://www.w3.org/mid/7B360E86-86D8-11D8-86C0-00039384827E@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8413
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405080913.4B451A0E92@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 04:09:13 -0400 (EDT)
Content-Transfer-Encoding: quoted-printable



Am 04.04.2004 um 21:38 schrieb Patrik F=E4ltstr=F6m:
>
> On Apr 4, 2004, at 21:18, Julian Reschke wrote:
>
>> 3) Issues with the organization and writing style of the spec. BIND=20=

>> adopts the same editorial style as RFC3253; and as there has been=20
>> only one WG member finding problems with that, it seems that there's=20=

>> no change necessary. If more people feel differently about that,=20
>> please speak up.
>
> Let me phrase this differently:
>
> Will two parties which only read the text in the spec be able to write=20=

> code independent of each other which interoperate?

The bind spec is in an excellent shape to make interoperability between=20=

two parties
more than likely. And if people want to shoot themselves into the foot,=20=

there's nothing
a spec can do to prevent that.

//Stefan





From w3c-dist-auth-request@w3.org  Mon Apr  5 07:26:06 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23726
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 07:26:05 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 6BC4BA1B01; Mon,  5 Apr 2004 07:26:06 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id E2473A1B01
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 07:26:04 -0400 (EDT)
Received: from e1.ny.us.ibm.com ([32.97.182.101])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BASEu-0007Pg-TY
	for w3c-dist-auth@w3.org; Mon, 05 Apr 2004 07:26:04 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i35BPYeI437424
	for <w3c-dist-auth@w3.org>; Mon, 5 Apr 2004 07:25:34 -0400
Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i35BPW6I138344
	for <w3c-dist-auth@w3.org>; Mon, 5 Apr 2004 07:25:33 -0400
In-Reply-To: <9C1DEAC7-866F-11D8-AB6C-000A95B2B926@cisco.com>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF850855B6.3598E1C6-ON85256E6D.003E1936-85256E6D.003EB194@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Mon, 5 Apr 2004 07:25:30 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF282 | March 30, 2004) at
 04/05/2004 07:25:32,
	Serialize complete at 04/05/2004 07:25:32
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: Please submit last call on draft-ietf-webdav-bind-05.txt
X-Archived-At: http://www.w3.org/mid/OF850855B6.3598E1C6-ON85256E6D.003E1936-85256E6D.003EB194@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8414
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405112606.6BC4BA1B01@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 07:26:06 -0400 (EDT)


In my view, yes, two parties which only read the text in the
spec (and the normative document it extends, i.e. RFC2518),
will be able to write code independent of each other that
interoperates.

Since only one expert group member has had concerns in that
regard, I think it is appropriate to last call the document,
to determine whether a significant number of other readers
share that concern.

Cheers,
Geoff

Patrik wrote on 04/04/2004 03:38:12 PM:
> 
> On Apr 4, 2004, at 21:18, Julian Reschke wrote:
> 
> > 3) Issues with the organization and writing style of the spec. BIND 
> > adopts the same editorial style as RFC3253; and as there has been only 

> > one WG member finding problems with that, it seems that there's no 
> > change necessary. If more people feel differently about that, please 
> > speak up.
> 
> Let me phrase this differently:
> 
> Will two parties which only read the text in the spec be able to write 
> code independent of each other which interoperate?
> 
> Is your view the answer to that question is 'Yes'?
> 
>      Patrik
> 



From w3c-dist-auth-request@w3.org  Mon Apr  5 12:30:16 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13531
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 12:30:16 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 14DE8A2BE5; Mon,  5 Apr 2004 12:30:19 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 3BAA4A2BE5
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 12:30:18 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BAWzJ-0001TA-Qa
	for w3c-dist-auth@w3.org; Mon, 05 Apr 2004 12:30:17 -0400
Received: (qmail 9587 invoked by uid 65534); 5 Apr 2004 16:29:45 -0000
Received: from p50824538.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.69.56)
  by mail.gmx.net (mp014) with SMTP; 05 Apr 2004 18:29:45 +0200
X-Authenticated: #1915285
Message-ID: <40718973.6060702@gmx.de>
Date: Mon, 05 Apr 2004 18:29:39 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Slide Users Mailing List <slide-user@jakarta.apache.org>
Cc: w3c-dist-auth@w3.org
References: <000001c1926e$36512530$b3130b3d@uma>
In-Reply-To: <000001c1926e$36512530$b3130b3d@uma>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: What is left after LOCK/UNLOCK on null resource?
X-Archived-At: http://www.w3.org/mid/40718973.6060702@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8415
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405163019.14DE8A2BE5@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 12:30:19 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Uma Gajendragadkar wrote:

> Guys,
>  
>  
> Can anyone help me here? How does one get the lockToken's value in a
> client? Th elockdiscovery seems to return
> opaquelocktoken:dummytoken rather than the actual token :-(
>  
> There has been huge discussin here but no answer???
>  
> Any replies will be appreciated..
>  
> Uma

Servers are free not to return the lock token upon lockdiscovery, 
however returning a "dummy" token (instead of nothing) is definitively a 
severe bug (in particular if it breaks the syntax for the locktoken URI 
scheme).

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Apr  5 14:25:55 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23017
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 14:25:55 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A5F6AA0545; Mon,  5 Apr 2004 14:25:55 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 6DFF7A0668
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 14:25:54 -0400 (EDT)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAYnC-0002PE-Cf
	for w3c-dist-auth@w3c.org; Mon, 05 Apr 2004 14:25:54 -0400
Received: from ams-msg-core-1.cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 05 Apr 2004 10:36:14 +0000
X-BrightmailFiltered: true
Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202])
	by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i35IILOg010244;
	Mon, 5 Apr 2004 20:24:48 +0200 (MET DST)
Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 5 Apr 2004 20:23:09 +0200
Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(6.0.3790.0);
	 Mon, 5 Apr 2004 20:23:08 +0200
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <492C3DBC-872E-11D8-AB6C-000A95B2B926@cisco.com>
Content-Transfer-Encoding: 7bit
Cc: Ted Hardie <hardie@qualcomm.com>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
Date: Mon, 5 Apr 2004 20:23:07 +0200
To: Webdav WG <w3c-dist-auth@w3c.org>
X-Mailer: Apple Mail (2.613)
X-OriginalArrivalTime: 05 Apr 2004 18:23:08.0444 (UTC) FILETIME=[0B934DC0:01C41B3B]
Subject: Work of a co-chair - bind spec
X-Archived-At: http://www.w3.org/mid/492C3DBC-872E-11D8-AB6C-000A95B2B926@cisco.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8416
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405182555.A5F6AA0545@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 14:25:55 -0400 (EDT)
Content-Transfer-Encoding: 7bit


As there are discussions between my co-chair and other wg participants 
around the bind draft, I am now on request from Lisa explicitly stating 
she is in this discussion only a wg participant like the rest of you. 
Regarding this draft, I will act as the only chair of this wg.

More notes about the spec will follow.

     Patrik



From w3c-dist-auth-request@w3.org  Mon Apr  5 14:56:12 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24077
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 14:56:12 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id AD03AA1DE8; Mon,  5 Apr 2004 14:56:13 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id C12E5A1DE8
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 14:56:12 -0400 (EDT)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAZGW-0001qq-Jt
	for w3c-dist-auth@w3c.org; Mon, 05 Apr 2004 14:56:12 -0400
Received: from ams-msg-core-1.cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 05 Apr 2004 11:06:32 +0000
X-BrightmailFiltered: true
Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92])
	by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i35It6OM020178
	for <w3c-dist-auth@w3c.org>; Mon, 5 Apr 2004 20:55:06 +0200 (MET DST)
Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 5 Apr 2004 20:53:40 +0200
Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(6.0.3790.0);
	 Mon, 5 Apr 2004 20:55:39 +0200
Mime-Version: 1.0 (Apple Message framework v613)
Content-Transfer-Encoding: 7bit
Message-Id: <D3828D62-8732-11D8-AB6C-000A95B2B926@cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: Webdav WG <w3c-dist-auth@w3c.org>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
Date: Mon, 5 Apr 2004 20:55:37 +0200
X-Mailer: Apple Mail (2.613)
X-OriginalArrivalTime: 05 Apr 2004 18:55:39.0845 (UTC) FILETIME=[96B37750:01C41B3F]
Subject: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/D3828D62-8732-11D8-AB6C-000A95B2B926@cisco.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8417
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405185613.AD03AA1DE8@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 14:56:13 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Julian wrote:

> Lisa Dusseault wrote:
>
>> I've re-reviewed the bind draft. Many of these issues have come up
>> before but I feel they haven't been resolved in the draft.
>>
>> General
>> -----------
>>
>> The spec must stand alone, not be dependent on changes to RFC2518 in
>> 'bis'. Otherwise, bind can't be approved until RFC2518bis is approved.
>> That means no dependencies for things like 'lockroot'.
>
> There isn't any.

Lisa, was your reference to 'lockroot' a pointer to one such reference 
which exists, or something which is added to 2518bis which you point 
out is not allowed to be used in the bind draft?

>> In general, the spec needs more info to specify how existing things
>> work. All the following questions must be answered in the spec, NOT 
>> just
>> in email. The spec must be explicit, because different people reading 
>> a
>> model description always end up with different ideas how the model 
>> works
>> in practice.
>
> Here I disagree.

Remember I asked a question explicitly about interoperability between 
things developed by just reading the spec...then look at the list 
below. I don't see the statement "yes, there will be interoperability" 
matches those statements.

Can you explain?

> First of all, there are several ways to resolve questions raised:
>
> 1) If there is a simple answer based on existing specs and the current
> draft, just answer it here on the mailing list.
>
> 2) If the issue is likely to be re-raised (because the answer is not
> obvious), record it (and the answer) on the issues list.
>
> 3) If the issue is indeed valid, add it to the issues list and attempt
> to resolve it.
>
> In general, there are areas where the spec *can't* specify how existing
> things work, because they depend on specific implementations. I
> absolutely agree that those situations should be avoided, but sometime
> there's nothing we can do about that.
>
> I'll post answers to the specific issues in a separate mail.

     paf



From w3c-dist-auth-request@w3.org  Mon Apr  5 15:05:06 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25824
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 15:05:05 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 9DFEEA20D0; Mon,  5 Apr 2004 15:05:06 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id AB3B3A20D0
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 15:05:05 -0400 (EDT)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAZP7-0003YF-IK
	for w3c-dist-auth@w3.org; Mon, 05 Apr 2004 15:05:05 -0400
Received: from ams-msg-core-1.cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 05 Apr 2004 11:15:25 +0000
X-BrightmailFiltered: true
Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202])
	by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i35J3xOM021936
	for <w3c-dist-auth@w3.org>; Mon, 5 Apr 2004 21:03:59 +0200 (MET DST)
Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 5 Apr 2004 21:04:33 +0200
Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(6.0.3790.0);
	 Mon, 5 Apr 2004 21:04:33 +0200
Mime-Version: 1.0 (Apple Message framework v613)
Content-Transfer-Encoding: 7bit
Message-Id: <120DA31A-8734-11D8-AB6C-000A95B2B926@cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: w3c-dist-auth@w3.org
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
Date: Mon, 5 Apr 2004 21:04:31 +0200
X-Mailer: Apple Mail (2.613)
X-OriginalArrivalTime: 05 Apr 2004 19:04:33.0179 (UTC) FILETIME=[D497C6B0:01C41B40]
Subject: What is actually locked?
X-Archived-At: http://www.w3.org/mid/120DA31A-8734-11D8-AB6C-000A95B2B926@cisco.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8418
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405190506.9DFEEA20D0@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 15:05:06 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Julian wrote:

> Lisa Dusseault wrote:
>
>> A - Issues relating to 2518 features
>> 1. Can you UNLOCK a URI that binds to a locked resource, when that URI
>> wasn't directly locked? If not, what's the error?
>
> I can't see any language in RFC2518 and/or BIND saying that you can't,
> so you can. UNLOCK removes the lock identified by the lock token header
> from the resource identified by the request URI, so the actual URI 
> being
> used for UNLOCK is irrelevant.
>
>> 2. Can you LOCK a URI that binds to a locked resource, when that URI
>> wasn't directly locked? If not, what's the error?
>
> You can, as long both locks are compatible (that is, none of them is
> exclusive). So the situation here is exactly as if you use the same
> request URI.

To me the above show some communication issues. It continues:

>> 3. In If header evaluation, does a URI "match" a lock token, when that
>> URI wasn't directly locked but the underlying resource was locked with
>> that token?
>
> The If header matching description
> (<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.9.4.4>)
> talks about resources, not URIs, thus it's not relevant which URI you
> provide as long as it identifies the right resource.
>
>> 4. What exactly does lockdiscovery show on a locked binding? On a 
>> locked
>> resource accessed through an unlocked binding? Does 'lockdiscovery' 
>> look
>> exactly the same on every binding to a locked resource?
>
> Yes. The lock belongs to the state of the resource, so PROPFIND returns
> the same operation no matter which binding you use.
>
>> 5. What does creationdate refer to, I assume it's the creationdate of
>> the underlying resource (not the creation date of the binding)? If the
>
> Yes.
>
>> underlying resource, is there any way to tell when a binding was
>
> No.
>
>> created? and vice versa?

It seems Julian is talking about locking always being on the resource, 
regardless of what binding was used. This imply it is completely 
irrelevant what binding has happend, what URI is used etc to reach the 
resource. If the resource is locked it is.

Now, Lisa, you seem to either not agree with this view, or that the 
document doesn't specify this clearly enough.

Can you (Lisa) clarify?

    paf



From w3c-dist-auth-request@w3.org  Mon Apr  5 15:37:46 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29415
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 15:37:45 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E6314A063A; Mon,  5 Apr 2004 15:37:45 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id E7695A0AD4
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 15:37:41 -0400 (EDT)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAZuC-0000nu-BD
	for w3c-dist-auth@w3c.org; Mon, 05 Apr 2004 15:37:12 -0400
Received: from ams-msg-core-1.cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 05 Apr 2004 13:47:32 +0200
X-BrightmailFiltered: true
Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202])
	by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i35JZWOS029246;
	Mon, 5 Apr 2004 21:36:06 +0200 (MET DST)
Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 5 Apr 2004 21:36:28 +0200
Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(6.0.3790.0);
	 Mon, 5 Apr 2004 21:36:28 +0200
In-Reply-To: <4071B109.7050602@gmx.de>
References: <D3828D62-8732-11D8-AB6C-000A95B2B926@cisco.com> <4071B109.7050602@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <87B52E83-8738-11D8-AB6C-000A95B2B926@cisco.com>
Content-Transfer-Encoding: 7bit
Cc: Webdav WG <w3c-dist-auth@w3c.org>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
Date: Mon, 5 Apr 2004 21:36:27 +0200
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-OriginalArrivalTime: 05 Apr 2004 19:36:28.0283 (UTC) FILETIME=[4A1574B0:01C41B45]
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/87B52E83-8738-11D8-AB6C-000A95B2B926@cisco.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8419
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405193745.E6314A063A@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 15:37:45 -0400 (EDT)
Content-Transfer-Encoding: 7bit



On Apr 5, 2004, at 21:18, Julian Reschke wrote:

> And of course it's possible (or actually likely) that we missed 
> something. That's why we're asking for feedback; and the most 
> efficient way to get feedback is by last-calling the document in the 
> working group (the fact that we're having this discussion sort of 
> proves it, right?). So as long as we're getting *new* questions, it's 
> fine to delay the last-call; however once the mail threads stop (which 
> they did last week), we should move on.

Absolutely, you are correct.

BUT, I don't see any reason to last call the document before *I* at 
least understand the issues and misunderstandings and what ever between 
you and Lisa regarding locking and binding. See separate mail.

Else I will as chair just get the same arguments again.

But, message is received.

    paf



From w3c-dist-auth-request@w3.org  Mon Apr  5 15:38:19 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29463
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 15:38:19 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 38901A2F95; Mon,  5 Apr 2004 15:38:20 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 01109A1458
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 15:37:51 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BAZoM-0008DU-Cq
	for w3c-dist-auth@w3.org; Mon, 05 Apr 2004 15:31:10 -0400
Received: (qmail 809 invoked by uid 65534); 5 Apr 2004 19:30:38 -0000
Received: from pD950C245.dip.t-dialin.net (EHLO gmx.de) (217.80.194.69)
  by mail.gmx.net (mp006) with SMTP; 05 Apr 2004 21:30:38 +0200
X-Authenticated: #1915285
Message-ID: <4071B3DA.3080406@gmx.de>
Date: Mon, 05 Apr 2004 21:30:34 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
Cc: w3c-dist-auth@w3.org
References: <120DA31A-8734-11D8-AB6C-000A95B2B926@cisco.com>
In-Reply-To: <120DA31A-8734-11D8-AB6C-000A95B2B926@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: What is actually locked?
X-Archived-At: http://www.w3.org/mid/4071B3DA.3080406@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8420
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405193820.38901A2F95@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 15:38:20 -0400 (EDT)
Content-Transfer-Encoding: 8bit


Patrik Fältström wrote:

 > ...
> It seems Julian is talking about locking always being on the resource, 
> regardless of what binding was used. This imply it is completely 
> irrelevant what binding has happend, what URI is used etc to reach the 
> resource. If the resource is locked it is.
> ...

Correct. IMHO this follows clearly from RFC2518 (specifically the 
introduction of locking (section 6) and write locks (section 7))...:

"The ability to lock a resource provides a mechanism for serializing 
access to that resource. Using a lock, an authoring client can provide a 
reasonable guarantee that another principal will not modify a resource 
while it is being edited. In this way, a client can prevent the "lost 
update" problem."

"A write lock MUST prevent a principal without the lock from 
successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, 
DELETE, or MKCOL on the locked resource. All other current methods, GET 
in particular, function independently of the lock."

BTW: at some point in the previous discussions it was claimed that 
RFC2518 uses the terms "URI" and "resource" interchangeably, and thus 
there was no explicit distinction. I disagree with that point of view. 
If there are places where RFC2518 is sloppy in this regard, we should 
identify those and try to fix them in RFC2518bis.

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Apr  5 15:39:36 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29529
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 15:39:35 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A21B3A0EC6; Mon,  5 Apr 2004 15:39:37 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 72CEDA2FAE
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 15:38:21 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BAZd3-0006B7-Tb
	for w3c-dist-auth@w3c.org; Mon, 05 Apr 2004 15:19:30 -0400
Received: (qmail 28549 invoked by uid 65534); 5 Apr 2004 19:18:54 -0000
Received: from pD950C245.dip.t-dialin.net (EHLO gmx.de) (217.80.194.69)
  by mail.gmx.net (mp014) with SMTP; 05 Apr 2004 21:18:54 +0200
X-Authenticated: #1915285
Message-ID: <4071B109.7050602@gmx.de>
Date: Mon, 05 Apr 2004 21:18:33 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
References: <D3828D62-8732-11D8-AB6C-000A95B2B926@cisco.com>
In-Reply-To: <D3828D62-8732-11D8-AB6C-000A95B2B926@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/4071B109.7050602@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8421
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405193937.A21B3A0EC6@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 15:39:37 -0400 (EDT)
Content-Transfer-Encoding: 8bit


Patrik Fältström wrote:

>> Lisa Dusseault wrote:
>>
>>> I've re-reviewed the bind draft. Many of these issues have come up
>>> before but I feel they haven't been resolved in the draft.
>>>
>>> General
>>> -----------
>>>
>>> The spec must stand alone, not be dependent on changes to RFC2518 in
>>> 'bis'. Otherwise, bind can't be approved until RFC2518bis is approved.
>>> That means no dependencies for things like 'lockroot'.
>>
>>
>> There isn't any.
> 
> 
> Lisa, was your reference to 'lockroot' a pointer to one such reference 
> which exists, or something which is added to 2518bis which you point out 
> is not allowed to be used in the bind draft?

Lisa was probably referring to a previous discussion where we agreed 
that clients will *benefit* from the new DAV:lockroot element, because 
it allows them to programatically discover which URL is protected by a 
lock. However, this is a nice-to-have feature, and clients certainly 
don't require it (after all, they should know the URL because they 
usually issued the LOCK request themselves). So the consensus (imho) was 
that it's presence in RFC2518bis simply is "good enough".

If people feel that DAV:lockroot only being defined by RFC2518bis 
actually is a problem, we can add it to BIND. However, I'd like to avoid 
it because it creates an area of overlap that doesn't seem to be necessary.

>>> In general, the spec needs more info to specify how existing things
>>> work. All the following questions must be answered in the spec, NOT just
>>> in email. The spec must be explicit, because different people reading a
>>> model description always end up with different ideas how the model works
>>> in practice.
>>
>>
>> Here I disagree.
> 
> 
> Remember I asked a question explicitly about interoperability between 
> things developed by just reading the spec...then look at the list below. 
> I don't see the statement "yes, there will be interoperability" matches 
> those statements.
> 
> Can you explain?
> 
>> First of all, there are several ways to resolve questions raised:
>>
>> 1) If there is a simple answer based on existing specs and the current
>> draft, just answer it here on the mailing list.
>>
>> 2) If the issue is likely to be re-raised (because the answer is not
>> obvious), record it (and the answer) on the issues list.
>>
>> 3) If the issue is indeed valid, add it to the issues list and attempt
>> to resolve it.
>>
>> In general, there are areas where the spec *can't* specify how existing
>> things work, because they depend on specific implementations. I
>> absolutely agree that those situations should be avoided, but sometime
>> there's nothing we can do about that.
>>
>> I'll post answers to the specific issues in a separate mail.

Patrik, I'm not sure what you're asking for. There'll always be the 
possibility that people misunderstand a spec, don't read a normative 
reference, or just miss something.

So the question about expected interoperability leads nowhere unless 
it's a *specific* spec question - of course the authors expect that the 
spec is sufficient for interoperable implementations, otherwise we 
wouldn't ask for last-call.

And of course it's possible (or actually likely) that we missed 
something. That's why we're asking for feedback; and the most efficient 
way to get feedback is by last-calling the document in the working group 
(the fact that we're having this discussion sort of proves it, right?). 
So as long as we're getting *new* questions, it's fine to delay the 
last-call; however once the mail threads stop (which they did last 
week), we should move on.

Best regards,

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Apr  5 15:39:58 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29582
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 15:39:57 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B5E60A1458; Mon,  5 Apr 2004 15:39:59 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id A2748A0AA6
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 15:39:58 -0400 (EDT)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAZws-0001ua-Dk
	for w3c-dist-auth@w3.org; Mon, 05 Apr 2004 15:39:58 -0400
Received: from ams-msg-core-1.cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 05 Apr 2004 13:50:14 +0200
X-BrightmailFiltered: true
Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92])
	by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i35JcVOM029918;
	Mon, 5 Apr 2004 21:38:42 +0200 (MET DST)
Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 5 Apr 2004 21:37:05 +0200
Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(6.0.3790.0);
	 Mon, 5 Apr 2004 21:39:04 +0200
In-Reply-To: <4071B3DA.3080406@gmx.de>
References: <120DA31A-8734-11D8-AB6C-000A95B2B926@cisco.com> <4071B3DA.3080406@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <E0FC5017-8738-11D8-AB6C-000A95B2B926@cisco.com>
Content-Transfer-Encoding: 7bit
Cc: w3c-dist-auth@w3.org
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
Date: Mon, 5 Apr 2004 21:38:56 +0200
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-OriginalArrivalTime: 05 Apr 2004 19:39:05.0069 (UTC) FILETIME=[A78919D0:01C41B45]
Subject: Re: What is actually locked?
X-Archived-At: http://www.w3.org/mid/E0FC5017-8738-11D8-AB6C-000A95B2B926@cisco.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8422
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405193959.B5E60A1458@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 15:39:59 -0400 (EDT)
Content-Transfer-Encoding: 7bit



On Apr 5, 2004, at 21:30, Julian Reschke wrote:

> BTW: at some point in the previous discussions it was claimed that 
> RFC2518 uses the terms "URI" and "resource" interchangeably, and thus 
> there was no explicit distinction. I disagree with that point of view. 
> If there are places where RFC2518 is sloppy in this regard, we should 
> identify those and try to fix them in RFC2518bis.

If anyone remember, please let the list know.

    paf



From w3c-dist-auth-request@w3.org  Mon Apr  5 15:53:51 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01033
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 15:53:51 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B612CA2E9C; Mon,  5 Apr 2004 15:53:52 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id B601EA2E9C
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 15:53:51 -0400 (EDT)
Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAaAJ-0005VV-HX
	for w3c-dist-auth@w3.org; Mon, 05 Apr 2004 15:53:51 -0400
Received: from [192.168.101.178] ([65.106.67.2]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 5 Apr 2004 12:53:19 -0700
In-Reply-To: <120DA31A-8734-11D8-AB6C-000A95B2B926@cisco.com>
References: <120DA31A-8734-11D8-AB6C-000A95B2B926@cisco.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <DDCF004C-873A-11D8-970E-000A95B2BB72@xythos.com>
Content-Transfer-Encoding: quoted-printable
Cc: w3c-dist-auth@w3.org
From: Lisa Dusseault <lisa@xythos.com>
Date: Mon, 5 Apr 2004 12:53:10 -0700
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
X-Mailer: Apple Mail (2.613)
X-OriginalArrivalTime: 05 Apr 2004 19:53:19.0670 (UTC) FILETIME=[A4EADD60:01C41B47]
Subject: Re: What is actually locked?
X-Archived-At: http://www.w3.org/mid/DDCF004C-873A-11D8-970E-000A95B2BB72@xythos.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8423
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405195352.B612CA2E9C@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 15:53:52 -0400 (EDT)
Content-Transfer-Encoding: quoted-printable


Patrik asked: "Now, Lisa, you seem to either not agree with this view,=20=

or that the document doesn't specify this clearly enough. Can you=20
(Lisa) clarify?"

Yes, I've had various discussions where it seemed that if one binding=20
to a
resource was locked then other bindings also had to appear locked, and
I've had other discussions where it seemed the other way.  Reading the
specification might lead a person to one conclusion, but it might lead=20=

them
to the other conclusion.  By now I've read the spec many times, but I=20
recently
reread it carefully and tried to do so with an open mind, and I found=20
that it
is unclear -- it is difficult to integrate statements from different=20
sections of
the draft to come to a conclusion.  It's not merely that this is more=20
work for
the reader of the spec, but it is also prone to parsing and integration=20=

errors.

Some of the details resulting from the lock model are even more=20
definitely
unclear.  For example, can a client use UNLOCK on a binding that isn't=20=

the
one that was locked?  If not, what's the error?  The spec must say=20
whether
a server MUST support UNLOCK on all bindings to a locked resource.

It's my belief that interoperability will suffer from the readability=20
problems
in this specification.

Lisa

On Apr 5, 2004, at 12:04 PM, Patrik F=E4ltstr=F6m wrote:

>
> Julian wrote:
>
>> Lisa Dusseault wrote:
>>
>>> A - Issues relating to 2518 features
>>> 1. Can you UNLOCK a URI that binds to a locked resource, when that=20=

>>> URI
>>> wasn't directly locked? If not, what's the error?
>>
>> I can't see any language in RFC2518 and/or BIND saying that you =
can't,
>> so you can. UNLOCK removes the lock identified by the lock token=20
>> header
>> from the resource identified by the request URI, so the actual URI=20
>> being
>> used for UNLOCK is irrelevant.
>>
>>> 2. Can you LOCK a URI that binds to a locked resource, when that URI
>>> wasn't directly locked? If not, what's the error?
>>
>> You can, as long both locks are compatible (that is, none of them is
>> exclusive). So the situation here is exactly as if you use the same
>> request URI.
>
> To me the above show some communication issues. It continues:
>
>>> 3. In If header evaluation, does a URI "match" a lock token, when=20
>>> that
>>> URI wasn't directly locked but the underlying resource was locked=20
>>> with
>>> that token?
>>
>> The If header matching description
>> (<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.9.4.4>)
>> talks about resources, not URIs, thus it's not relevant which URI you
>> provide as long as it identifies the right resource.
>>
>>> 4. What exactly does lockdiscovery show on a locked binding? On a=20
>>> locked
>>> resource accessed through an unlocked binding? Does 'lockdiscovery'=20=

>>> look
>>> exactly the same on every binding to a locked resource?
>>
>> Yes. The lock belongs to the state of the resource, so PROPFIND=20
>> returns
>> the same operation no matter which binding you use.
>>
>>> 5. What does creationdate refer to, I assume it's the creationdate =
of
>>> the underlying resource (not the creation date of the binding)? If=20=

>>> the
>>
>> Yes.
>>
>>> underlying resource, is there any way to tell when a binding was
>>
>> No.
>>
>>> created? and vice versa?
>
> It seems Julian is talking about locking always being on the resource,=20=

> regardless of what binding was used. This imply it is completely=20
> irrelevant what binding has happend, what URI is used etc to reach the=20=

> resource. If the resource is locked it is.
>
> Now, Lisa, you seem to either not agree with this view, or that the=20
> document doesn't specify this clearly enough.
>
> Can you (Lisa) clarify?
>
>    paf
>



From w3c-dist-auth-request@w3.org  Mon Apr  5 15:59:05 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02508
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 15:59:05 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id C1D0AA2F7B; Mon,  5 Apr 2004 15:59:06 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id C0F6DA2F7B
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 15:59:05 -0400 (EDT)
Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAaFN-0006ju-HI
	for w3c-dist-auth@w3c.org; Mon, 05 Apr 2004 15:59:05 -0400
Received: from [192.168.101.178] ([65.106.67.2]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 5 Apr 2004 12:58:33 -0700
In-Reply-To: <D3828D62-8732-11D8-AB6C-000A95B2B926@cisco.com>
References: <D3828D62-8732-11D8-AB6C-000A95B2B926@cisco.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <97D2D91C-873B-11D8-970E-000A95B2BB72@xythos.com>
Content-Transfer-Encoding: quoted-printable
Cc: Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@xythos.com>
Date: Mon, 5 Apr 2004 12:58:22 -0700
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
X-Mailer: Apple Mail (2.613)
X-OriginalArrivalTime: 05 Apr 2004 19:58:34.0138 (UTC) FILETIME=[605ADFA0:01C41B48]
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/97D2D91C-873B-11D8-970E-000A95B2BB72@xythos.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8424
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405195906.C1D0AA2F7B@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 15:59:06 -0400 (EDT)
Content-Transfer-Encoding: quoted-printable



On Apr 5, 2004, at 11:55 AM, Patrik F=E4ltstr=F6m wrote:

>
> Julian wrote:
>
>> Lisa Dusseault wrote:
>>
>>> I've re-reviewed the bind draft. Many of these issues have come up
>>> before but I feel they haven't been resolved in the draft.
>>>
>>> General
>>> -----------
>>>
>>> The spec must stand alone, not be dependent on changes to RFC2518 in
>>> 'bis'. Otherwise, bind can't be approved until RFC2518bis is=20
>>> approved.
>>> That means no dependencies for things like 'lockroot'.
>>
>> There isn't any.
>
> Lisa, was your reference to 'lockroot' a pointer to one such reference=20=

> which exists, or something which is added to 2518bis which you point=20=

> out is not allowed to be used in the bind draft?

In this discussion, I asked whether a user can UNLOCK a binding that=20
wasn't
the binding where the LOCK was issued (these are both bindings to the=20
same
resource).  One of the email answers was that the client software could=20=

always
use the "lockroot" element in the lock information to discover which=20
URI was
locked and thus they could find out which one to unlock.

I find that answer unacceptable for two reasons.  First, 'lockroot'=20
isn't standardized -- it's
only a proposed extension to WebDAV/RFC2518, and not all servers=20
implementing
bindings must implement this proposed extension.   Second, it doesn't=20
answer the
question of how server implementations of bindings MUST behave.

Lisa=



From w3c-dist-auth-request@w3.org  Mon Apr  5 16:12:45 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04447
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 16:12:45 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 28061A1EB5; Mon,  5 Apr 2004 16:12:46 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id D0720A1D0E
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 16:12:42 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BAaSC-0002E5-BY
	for w3c-dist-auth@w3c.org; Mon, 05 Apr 2004 16:12:20 -0400
Received: (qmail 671 invoked by uid 65534); 5 Apr 2004 20:11:47 -0000
Received: from pD950C245.dip.t-dialin.net (EHLO gmx.de) (217.80.194.69)
  by mail.gmx.net (mp010) with SMTP; 05 Apr 2004 22:11:47 +0200
X-Authenticated: #1915285
Message-ID: <4071BD6F.3080303@gmx.de>
Date: Mon, 05 Apr 2004 22:11:27 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@xythos.com>
Cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        Webdav WG <w3c-dist-auth@w3c.org>
References: <D3828D62-8732-11D8-AB6C-000A95B2B926@cisco.com> <97D2D91C-873B-11D8-970E-000A95B2BB72@xythos.com>
In-Reply-To: <97D2D91C-873B-11D8-970E-000A95B2BB72@xythos.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/4071BD6F.3080303@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8425
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405201246.28061A1EB5@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 16:12:46 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> In this discussion, I asked whether a user can UNLOCK a binding that wasn't
> the binding where the LOCK was issued (these are both bindings to the same
> resource).  One of the email answers was that the client software could 
> always
> use the "lockroot" element in the lock information to discover which URI 
> was
> locked and thus they could find out which one to unlock.
> 
> I find that answer unacceptable for two reasons.  First, 'lockroot' 
> isn't standardized -- it's
> only a proposed extension to WebDAV/RFC2518, and not all servers 
> implementing
> bindings must implement this proposed extension.   Second, it doesn't 
> answer the
> question of how server implementations of bindings MUST behave.

1) First of all, clients are not supposed to remove locks they haven't 
created. If the lock was created by themselves, they *know* the original 
request URI. If they didn't, this is definitively an edge case.

2) That being said, the *resource* is locked; and thus it doesn't matter 
what request URI is used to submit the UNLOCK request to. This is 
consistent with the general statement that additional bindings only 
create additional access paths, but that the methods interact with the 
*resources*. In general, the access path does not matter. See 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-05.html#rfc.section.1.p.4>:

"The BIND method defined here provides a mechanism for allowing clients 
to create alternative access paths to existing WebDAV resources. HTTP 
[RFC2616] and WebDAV [RFC2518]  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."

So in general, the access path does not matter. That's the whole point 
of the binding spec.

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Apr  5 16:16:38 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04487
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 16:16:38 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 0E419A1801; Mon,  5 Apr 2004 16:16:40 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 17E8AA1801
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 16:16:37 -0400 (EDT)
Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAaWH-0002sj-3q
	for w3c-dist-auth@w3c.org; Mon, 05 Apr 2004 16:16:33 -0400
Received: from [192.168.101.178] ([65.106.67.2]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 5 Apr 2004 13:15:59 -0700
In-Reply-To: <4071BD6F.3080303@gmx.de>
References: <D3828D62-8732-11D8-AB6C-000A95B2B926@cisco.com> <97D2D91C-873B-11D8-970E-000A95B2BB72@xythos.com> <4071BD6F.3080303@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <04CD947F-873E-11D8-970E-000A95B2BB72@xythos.com>
Content-Transfer-Encoding: 7bit
Cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@xythos.com>
Date: Mon, 5 Apr 2004 13:15:44 -0700
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-OriginalArrivalTime: 05 Apr 2004 20:15:59.0797 (UTC) FILETIME=[CF9DC650:01C41B4A]
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/04CD947F-873E-11D8-970E-000A95B2BB72@xythos.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8426
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405201640.0E419A1801@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 16:16:40 -0400 (EDT)
Content-Transfer-Encoding: 7bit



On Apr 5, 2004, at 1:11 PM, Julian Reschke wrote:

>
> Lisa Dusseault wrote:
>
>> In this discussion, I asked whether a user can UNLOCK a binding that  
>> wasn't
>> the binding where the LOCK was issued (these are both bindings to the  
>> same
>> resource).  One of the email answers was that the client software  
>> could always
>> use the "lockroot" element in the lock information to discover which  
>> URI was
>> locked and thus they could find out which one to unlock.
>> I find that answer unacceptable for two reasons.  First, 'lockroot'  
>> isn't standardized -- it's
>> only a proposed extension to WebDAV/RFC2518, and not all servers  
>> implementing
>> bindings must implement this proposed extension.   Second, it doesn't  
>> answer the
>> question of how server implementations of bindings MUST behave.
>
> 1) First of all, clients are not supposed to remove locks they haven't  
> created. If the lock was created by themselves, they *know* the  
> original request URI. If they didn't, this is definitively an edge  
> case.
>
> 2) That being said, the *resource* is locked; and thus it doesn't  
> matter what request URI is used to submit the UNLOCK request to. This  
> is consistent with the general statement that additional bindings only  
> create additional access paths, but that the methods interact with the  
> *resources*. In general, the access path does not matter. See  
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind 
> -05.html#rfc.section.1.p.4>:
>
> "The BIND method defined here provides a mechanism for allowing  
> clients to create alternative access paths to existing WebDAV  
> resources. HTTP [RFC2616] and WebDAV [RFC2518]  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."
>
> So in general, the access path does not matter. That's the whole point  
> of the binding spec.

Except for the cases where it does matter, like BIND/UNBIND, MOVE and  
DELETE.  The spec is not clear enough about which methods apply to the  
binding and which apply to the resource, and when.  The spec doesn't  
say whether LOCK behaves more like PUT, or more like BIND.

>
> Regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Mon Apr  5 16:23:02 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04601
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 16:23:02 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id EF3E3A211C; Mon,  5 Apr 2004 16:23:03 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 33B45A211C
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 16:22:53 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BAabA-0003bN-Gw
	for w3c-dist-auth@w3.org; Mon, 05 Apr 2004 16:21:36 -0400
Received: (qmail 15257 invoked by uid 65534); 5 Apr 2004 20:21:04 -0000
Received: from pD950C245.dip.t-dialin.net (EHLO gmx.de) (217.80.194.69)
  by mail.gmx.net (mp018) with SMTP; 05 Apr 2004 22:21:04 +0200
X-Authenticated: #1915285
Message-ID: <4071BF9C.7040509@gmx.de>
Date: Mon, 05 Apr 2004 22:20:44 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@xythos.com>
Cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        w3c-dist-auth@w3.org
References: <120DA31A-8734-11D8-AB6C-000A95B2B926@cisco.com> <DDCF004C-873A-11D8-970E-000A95B2BB72@xythos.com>
In-Reply-To: <DDCF004C-873A-11D8-970E-000A95B2BB72@xythos.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: What is actually locked?
X-Archived-At: http://www.w3.org/mid/4071BF9C.7040509@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8427
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405202303.EF3E3A211C@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 16:23:03 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> Patrik asked: "Now, Lisa, you seem to either not agree with this view, 
> or that the document doesn't specify this clearly enough. Can you (Lisa) 
> clarify?"
> 
> Yes, I've had various discussions where it seemed that if one binding to a
> resource was locked then other bindings also had to appear locked, and
> I've had other discussions where it seemed the other way.  Reading the
> specification might lead a person to one conclusion, but it might lead them
> to the other conclusion.  By now I've read the spec many times, but I 
> recently
> reread it carefully and tried to do so with an open mind, and I found 
> that it
> is unclear -- it is difficult to integrate statements from different 
> sections of
> the draft to come to a conclusion.  It's not merely that this is more 
> work for
> the reader of the spec, but it is also prone to parsing and integration 
> errors.

Well, in fact the BIND spec says almost nothing about locks; so I'm not 
sure where you see the ambiguity. BIND doesn't in any way change the 
locking model defined in RFC2518; and that locking model is about 
*resources* being locked. So yes, if a resource is locked through one of 
it's bindings, the lock will be visible (and active) for all other 
bindings as well -- again, that's a basic property of the model; 
additional bindings give you additional access paths to a single 
resource, but you're always manipulating / discovering the resource itself.

If you can point to a section in the BIND spec that suggests otherwise, 
*please* do so.

> Some of the details resulting from the lock model are even more definitely
> unclear.  For example, can a client use UNLOCK on a binding that isn't the
> one that was locked?  If not, what's the error?  The spec must say whether
> a server MUST support UNLOCK on all bindings to a locked resource.

The spec says in it's introduction that additional bindings just add 
additional access paths to the same resource, and that HTTP methods 
access the resource itself. Thus the access path doesn't matter, and 
UNLOCK must work on each of the bindings to the resource.

> It's my belief that interoperability will suffer from the readability 
> problems
> in this specification.

I think the introduction section is very clear about all of this:

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

What else do we need to say here?

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Apr  5 16:51:25 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06942
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 16:51:25 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 124F4A3085; Mon,  5 Apr 2004 16:51:27 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 81240A3085
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 16:51:24 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BAb40-0001ek-7I
	for w3c-dist-auth@w3c.org; Mon, 05 Apr 2004 16:51:24 -0400
Received: (qmail 25833 invoked by uid 65534); 5 Apr 2004 20:50:46 -0000
Received: from pD950C245.dip.t-dialin.net (EHLO gmx.de) (217.80.194.69)
  by mail.gmx.net (mp021) with SMTP; 05 Apr 2004 22:50:46 +0200
X-Authenticated: #1915285
Message-ID: <4071C68E.7010506@gmx.de>
Date: Mon, 05 Apr 2004 22:50:22 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@xythos.com>
Cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        Webdav WG <w3c-dist-auth@w3c.org>
References: <D3828D62-8732-11D8-AB6C-000A95B2B926@cisco.com> <97D2D91C-873B-11D8-970E-000A95B2BB72@xythos.com> <4071BD6F.3080303@gmx.de> <04CD947F-873E-11D8-970E-000A95B2BB72@xythos.com>
In-Reply-To: <04CD947F-873E-11D8-970E-000A95B2BB72@xythos.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/4071C68E.7010506@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8428
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405205127.124F4A3085@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 16:51:27 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

>> So in general, the access path does not matter. That's the whole 
>> point  of the binding spec.
> 
> 
> Except for the cases where it does matter, like BIND/UNBIND, MOVE and  
> DELETE.  The spec is not clear enough about which methods apply to the  
> binding and which apply to the resource, and when.  The spec doesn't  
> say whether LOCK behaves more like PUT, or more like BIND.

I agree that sometimes it may *look* like it does. That follows from the 
specific property that locks do not only apply to the resource, but that 
they *also* protect the request URL to which the lock has been applied. 
So a namespace operation (such as removing a binding) may require a 
lock-token when that binding was protected by the lock, and otherwise 
not. In reprospective, this may have been the wrong design decision; but 
this was done in 1998, not today.

Consider the bindings "p/a1" and "p/a2" to resource A. LOCK was applied 
to the request URI "p/a1", resulting in the resource A being locked by a 
lock that protects the URL "p/a1".

Applying DELETE to "p/a1" requests that the binding "a1" is removed from 
it's parent collection "p". Applying DELETE to "p/a2" requests that the 
binding "a2" is removed from it's parent collection "p". As only the URL 
"p/a1" is protected by the lock, the first request will fail, while the 
second will succeed (if the client doesn't specify the lock token in the 
"If" request header).

What may be confusing here is that in fact the resource "A" isn't 
modified *at all*. Rather than that, it's the state of the collection 
resource identified by "p" that is being manipulated in both cases. For 
UNBIND, the BIND spec gets this right by applying the method to the 
parent collection, and having the actual member URI (to be removed) 
passed in as a parameter in the request body.

I absolutely agree that RFC2518 doesn't explain this very well (*). But 
this is true independantly of the BIND spec, and thus should be fixed in 
RFC2518bis. Alternatively we can also (as discussed in January) extract 
WebDAV locking into a separate independant spec (I'm willing to help 
working on that), but it really has little to do with BIND.

Regards, Julian

(*) For instance, I just tried to figure out where RFC2518 says that I 
can't rename "p" when "p/a1" is being locked without passing the lock 
token for A. Nevertheless, this is true, and everybody seems to agree on it.

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Apr  5 17:02:12 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09225
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 17:02:11 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E64CFA30C0; Mon,  5 Apr 2004 17:02:11 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id EE674A30BE
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 17:01:59 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BAbEF-0004MR-K8
	for w3c-dist-auth@w3c.org; Mon, 05 Apr 2004 17:01:59 -0400
Received: (qmail 32344 invoked by uid 65534); 5 Apr 2004 21:01:25 -0000
Received: from pD950C245.dip.t-dialin.net (EHLO gmx.de) (217.80.194.69)
  by mail.gmx.net (mp003) with SMTP; 05 Apr 2004 23:01:25 +0200
X-Authenticated: #1915285
Message-ID: <4071C8FD.7010800@gmx.de>
Date: Mon, 05 Apr 2004 23:00:45 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Lisa Dusseault <lisa@xythos.com>,
        =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6?= =?ISO-8859-1?Q?m?= <paf@cisco.com>,
        Webdav WG <w3c-dist-auth@w3c.org>
References: <D3828D62-8732-11D8-AB6C-000A95B2B926@cisco.com> <97D2D91C-873B-11D8-970E-000A95B2BB72@xythos.com> <4071BD6F.3080303@gmx.de> <04CD947F-873E-11D8-970E-000A95B2BB72@xythos.com> <4071C68E.7010506@gmx.de>
In-Reply-To: <4071C68E.7010506@gmx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/4071C8FD.7010800@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8429
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405210211.E64CFA30C0@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 17:02:11 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Julian Reschke wrote:

> (*) For instance, I just tried to figure out where RFC2518 says that I 
> can't rename "p" when "p/a1" is being locked without passing the lock 
> token for A. Nevertheless, this is true, and everybody seems to agree on 
> it.

Speaking of which, this seems to follow from RFC2518, section 8.9.2:

"A MOVE with "Depth: infinity" instructs that the collection identified 
by the Request-URI be moved to the URI specified in the Destination 
header, and all resources identified by its internal member URIs are to 
be moved to locations relative to it, recursively through all levels of 
the collection hierarchy."

...so it is defined, but RFC2518's introduction of the locking feature 
really could be more explicit about that...

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Apr  5 17:10:58 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10077
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 17:10:58 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 4DB53A0B55; Mon,  5 Apr 2004 17:10:59 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id CFDADA0B55
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 17:10:56 -0400 (EDT)
Received: from [217.5.201.10] (helo=greenbytes.de)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAbMu-0006G1-G7
	for w3c-dist-auth@w3c.org; Mon, 05 Apr 2004 17:10:56 -0400
Received: from [192.168.0.3] ([192.168.1.23])
	(authenticated user se@greenbytes.de)
	by greenbytes.de (greenbytes.de)
	(Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000006939.msg
	for <w3c-dist-auth@w3c.org>; Mon, 05 Apr 2004 23:10:20 +0200
In-Reply-To: <04CD947F-873E-11D8-970E-000A95B2BB72@xythos.com>
References: <D3828D62-8732-11D8-AB6C-000A95B2B926@cisco.com> <97D2D91C-873B-11D8-970E-000A95B2BB72@xythos.com> <4071BD6F.3080303@gmx.de> <04CD947F-873E-11D8-970E-000A95B2BB72@xythos.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <A146CD53-8745-11D8-86C0-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
Cc: Julian Reschke <julian.reschke@gmx.de>,
        =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        Webdav WG <w3c-dist-auth@w3c.org>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Mon, 5 Apr 2004 23:10:13 +0200
To: Lisa Dusseault <lisa@xythos.com>
X-Mailer: Apple Mail (2.613)
X-Authenticated-Sender: se@greenbytes.de
X-Spam-Processed: greenbytes.de, Mon, 05 Apr 2004 23:10:20 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/A146CD53-8745-11D8-86C0-00039384827E@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8430
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405211059.4DB53A0B55@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 17:10:59 -0400 (EDT)
Content-Transfer-Encoding: 7bit



Am 05.04.2004 um 22:15 schrieb Lisa Dusseault:
> [...]
> Except for the cases where it does matter, like BIND/UNBIND, MOVE and 
> DELETE.  The spec is not clear enough about which methods apply to the 
> binding and which apply to the resource, and when.  The spec doesn't 
> say whether LOCK behaves more like PUT, or more like BIND.

Well, the bind spec does not talk about LOCK. It defines how BIND, 
REBIND and UNBIND
work in the presence of locked resources.

RFC 2518 explicitly adresses the case where multiple URLs to a single 
resource do exist
(see 2518 Chapter 5.1). *RFC 2518* does not explain how LOCK and other 
methods
work in the presence of multiple URLs to the same resource.

The bind spec currently defines the behaviour of namespace operations 
in the presence
of bindings. Something which should have been done in RFC 2518, but 
nobody is
perfect. The bind spec is a good place to do so.

What is not a good idea is to throw the complete, current understanding 
of LOCK
into the bind spec. This is not a failure of the spec, but was 
deliberatly chosen as
the path of wisdom to follow.

LOCK and locked resources in RFC 2518 are, as we know today, 
incompletely specified
in RFC 2518 and have let to interoperability issues. Therefore all 
knowledge was agreed
upon in the GULP and it was also agreed that GULP should find its way 
into RFC 2518bis,
because that's where it should be.

So, it is inaccurate and definitely not helping anyone with any 
implementation issue to
request cleanup of LOCKs from the authors of the bind spec. I 
personally am waiting
for 2 years now that RFC 2518bis makes progress comparable to other 
specs of this
group.

//Stefan




From w3c-dist-auth-request@w3.org  Mon Apr  5 17:19:09 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10130
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 17:19:09 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 5456AA0622; Mon,  5 Apr 2004 17:19:11 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id AC1F4A0622
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 17:19:09 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BAbUr-0008Gf-Em
	for w3c-dist-auth@w3c.org; Mon, 05 Apr 2004 17:19:09 -0400
Received: (qmail 24993 invoked by uid 65534); 5 Apr 2004 21:18:35 -0000
Received: from pD950C245.dip.t-dialin.net (EHLO gmx.de) (217.80.194.69)
  by mail.gmx.net (mp014) with SMTP; 05 Apr 2004 23:18:35 +0200
X-Authenticated: #1915285
Message-ID: <4071CCFF.1070102@gmx.de>
Date: Mon, 05 Apr 2004 23:17:51 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Lisa Dusseault <lisa@xythos.com>,
        =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6?= =?ISO-8859-1?Q?m?= <paf@cisco.com>,
        Webdav WG <w3c-dist-auth@w3c.org>
References: <D3828D62-8732-11D8-AB6C-000A95B2B926@cisco.com> <97D2D91C-873B-11D8-970E-000A95B2BB72@xythos.com> <4071BD6F.3080303@gmx.de> <04CD947F-873E-11D8-970E-000A95B2BB72@xythos.com> <4071C68E.7010506@gmx.de>
In-Reply-To: <4071C68E.7010506@gmx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/4071CCFF.1070102@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8431
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405211911.5456AA0622@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 17:19:11 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Julian Reschke wrote:
 > ...
> I absolutely agree that RFC2518 doesn't explain this very well (*). But 
> this is true independantly of the BIND spec, and thus should be fixed in 
> RFC2518bis. Alternatively we can also (as discussed in January) extract 
> WebDAV locking into a separate independant spec (I'm willing to help 
> working on that), but it really has little to do with BIND.
> ...

For the record: see mail thread 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/thread.html#30>.

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Apr  5 17:21:27 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10159
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 17:21:27 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 3B8F6A08CE; Mon,  5 Apr 2004 17:21:29 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 47261A08CE
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 17:21:28 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BAbX5-0000D6-Rq
	for w3c-dist-auth@w3c.org; Mon, 05 Apr 2004 17:21:28 -0400
Received: (qmail 18519 invoked by uid 65534); 5 Apr 2004 21:20:53 -0000
Received: from pD950C245.dip.t-dialin.net (EHLO gmx.de) (217.80.194.69)
  by mail.gmx.net (mp023) with SMTP; 05 Apr 2004 23:20:53 +0200
X-Authenticated: #1915285
Message-ID: <4071CD8F.2060701@gmx.de>
Date: Mon, 05 Apr 2004 23:20:15 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: Lisa Dusseault <lisa@xythos.com>,
        =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6?= =?ISO-8859-1?Q?m?= <paf@cisco.com>,
        Webdav WG <w3c-dist-auth@w3c.org>
References: <D3828D62-8732-11D8-AB6C-000A95B2B926@cisco.com> <97D2D91C-873B-11D8-970E-000A95B2BB72@xythos.com> <4071BD6F.3080303@gmx.de> <04CD947F-873E-11D8-970E-000A95B2BB72@xythos.com> <A146CD53-8745-11D8-86C0-00039384827E@greenbytes.de>
In-Reply-To: <A146CD53-8745-11D8-86C0-00039384827E@greenbytes.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/4071CD8F.2060701@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8432
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405212129.3B8F6A08CE@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 17:21:29 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Stefan Eissing wrote:

> ...
> So, it is inaccurate and definitely not helping anyone with any 
> implementation issue to
> request cleanup of LOCKs from the authors of the bind spec. I personally 
> am waiting
> for 2 years now that RFC 2518bis makes progress comparable to other 
> specs of this
> group.
> ...

Another way to look at this is that WebDAV LOCKING needs clarifications, 
but it needs them independantly of the BIND spec. It would be funny if 
we'd point people to the BIND spec if they have locking questions, yet 
do not plan to implement the BIND spec at all.

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Apr  5 17:24:00 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10227
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 17:24:00 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 4957DA07DE; Mon,  5 Apr 2004 17:24:02 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 6D1AFA07DE
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 17:24:01 -0400 (EDT)
Received: from natsmtp00.rzone.de ([81.169.145.165] helo=natsmtp00.webmailer.de)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAbZZ-0000jE-7I
	for w3c-dist-auth@w3.org; Mon, 05 Apr 2004 17:24:01 -0400
Received: from x.oberon.ethz.ch (p5083C3D0.dip0.t-ipconnect.de [80.131.195.208])
	by post.webmailer.de (8.12.10/8.12.10) with SMTP id i35LNwF6015039;
	Mon, 5 Apr 2004 23:23:59 +0200 (MEST)
Date: Mon, 5 Apr 2004 23:23:58 +0200 (MEST)
Message-Id: <200404052123.i35LNwF6015039@post.webmailer.de>
From: edgar@edgarschwarz.de
X-Mailer: Oberon Mail (ejz) on Aos 20.02.2004
To: w3c-dist-auth@w3.org
Cc: edgar@edgarschwarz.de
Subject: Re (2): What is actually locked?
X-Archived-At: http://www.w3.org/mid/200404052123.i35LNwF6015039@post.webmailer.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8433
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405212402.4957DA07DE@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 17:24:02 -0400 (EDT)


Lisa Dusseault <lisa@xythos.com> wrote:
> Yes, I've had various discussions where it seemed that if one binding 
> to a resource was locked ...
This could be read like a 'binding' can be locked. But it's the resource
I think we agree hopefully.

> Some of the details resulting from the lock model are even more 
> definitely
> unclear.  For example, can a client use UNLOCK on a binding that isn't 
> the
> one that was locked?  If not, what's the error?  The spec must say 
> whether
> a server MUST support UNLOCK on all bindings to a locked resource.
I can't see your problem here.
If a lock is on the resource and we tell that it doesn't matter
which binding we use to access the resource IMHO it's obvious that
this also applies to UNLOCK.
So I don't think the prose you want is necessary.
Or e.g. "UNLOCK like LOCK works on the resource." should be enough.

Cheers, Edgar



From w3c-dist-auth-request@w3.org  Mon Apr  5 17:55:13 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12327
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 17:55:13 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 1D279A1D64; Mon,  5 Apr 2004 17:55:16 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 8230EA1384
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 17:55:13 -0400 (EDT)
Received: from [65.208.153.194] (helo=sna-027.wakasoft.com)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAc3l-0007tj-8m
	for w3c-dist-auth@w3.org; Mon, 05 Apr 2004 17:55:13 -0400
Received: from apache.org (localhost [127.0.0.1])
	by sna-027.wakasoft.com (8.12.9/8.12.9) with ESMTP id i35Lt7CK023836;
	Mon, 5 Apr 2004 14:55:07 -0700 (PDT)
Date: Mon, 5 Apr 2004 14:55:06 -0700
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
Cc: Lisa Dusseault <lisa@xythos.com>,
        =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        w3c-dist-auth@w3.org
To: Julian Reschke <julian.reschke@gmx.de>
From: "Roy T. Fielding" <fielding@apache.org>
In-Reply-To: <4071BF9C.7040509@gmx.de>
Message-Id: <E648FF8E-874B-11D8-8F2D-000393753936@apache.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.553)
Subject: Re: What is actually locked?
X-Archived-At: http://www.w3.org/mid/E648FF8E-874B-11D8-8F2D-000393753936@apache.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8434
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405215516.1D279A1D64@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 17:55:16 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Perhaps more to the point, the issue is irrelevant because it
deals with a server-side implementation instruction rather than
interoperability between client and server.  The client should
be relying on the answers it gets back from the server, not on
an obscure requirement on how to implement locks within the server.

Regardless of how the server implements those locks, it will
respond with success or fail such that the client will be informed
whether or not it needed the lock token.  The client never needs
to know whether the URI corresponds to a binding, so adding
bind-specific requirements merely obfuscates the protocol.

....Roy



From w3c-dist-auth-request@w3.org  Mon Apr  5 18:00:23 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13551
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 18:00:23 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 1ACB8A1B54; Mon,  5 Apr 2004 18:00:25 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 18204A1B54
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 18:00:24 -0400 (EDT)
Received: from numenor.qualcomm.com ([129.46.51.58])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAc8l-00008y-SL
	for w3c-dist-auth@w3c.org; Mon, 05 Apr 2004 18:00:23 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i35LxaV2004110
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 5 Apr 2004 14:59:37 -0700 (PDT)
Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161])
	by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i35LxXUS015424;
	Mon, 5 Apr 2004 14:59:34 -0700 (PDT)
Mime-Version: 1.0
X-Sender: hardie@mage.qualcomm.com
Message-Id: <p06100407bc97865fe1f4@[129.46.227.161]>
In-Reply-To: <4071CD8F.2060701@gmx.de>
References: <D3828D62-8732-11D8-AB6C-000A95B2B926@cisco.com>
 <97D2D91C-873B-11D8-970E-000A95B2BB72@xythos.com>
 <4071BD6F.3080303@gmx.de>
 <04CD947F-873E-11D8-970E-000A95B2BB72@xythos.com>
 <A146CD53-8745-11D8-86C0-00039384827E@greenbytes.de>
 <4071CD8F.2060701@gmx.de>
Date: Mon, 5 Apr 2004 14:59:32 -0700
To: Julian Reschke <julian.reschke@gmx.de>,
        Stefan Eissing <stefan.eissing@greenbytes.de>
From: Ted Hardie <hardie@qualcomm.com>
Cc: Lisa Dusseault <lisa@xythos.com>,
        Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>,
        Webdav WG <w3c-dist-auth@w3c.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/p06100407bc97865fe1f4@%5B129.46.227.161%5D
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8435
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405220025.1ACB8A1B54@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 18:00:25 -0400 (EDT)


At 11:20 PM +0200 04/05/2004, Julian Reschke wrote:
>Stefan Eissing wrote:
>
>>...
>>So, it is inaccurate and definitely not helping anyone with any 
>>implementation issue to
>>request cleanup of LOCKs from the authors of the bind spec. I 
>>personally am waiting
>>for 2 years now that RFC 2518bis makes progress comparable to other 
>>specs of this
>>group.
>>...
>
>Another way to look at this is that WebDAV LOCKING needs 
>clarifications, but it needs them independantly of the BIND spec. It 
>would be funny if we'd point people to the BIND spec if they have 
>locking questions, yet do not plan to implement the BIND spec at all.
>

Speaking personally, my concern here would be that if those 
clarifications were not
present, BIND behavior became non-deterministic.  If 2518bis was done, and
BIND pointed to it to solve that hypothetical problem, all might be 
goodness; if
it will not be done, on the other hand, getting the job done in the spec which
will be completed might be the practical way to go.

Again, my personal two cents,
			regards,
				Ted



From w3c-dist-auth-request@w3.org  Mon Apr  5 18:09:55 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15269
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 18:09:55 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 281F0A1E7E; Mon,  5 Apr 2004 18:09:57 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 0AFA8A1E7E
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 18:09:56 -0400 (EDT)
Received: from [217.5.201.10] (helo=greenbytes.de)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAcHz-0002N1-Kq
	for w3c-dist-auth@w3c.org; Mon, 05 Apr 2004 18:09:55 -0400
Received: from [192.168.0.3] ([192.168.1.23])
	(authenticated user se@greenbytes.de)
	by greenbytes.de (greenbytes.de)
	(Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000006961.msg
	for <w3c-dist-auth@w3c.org>; Tue, 06 Apr 2004 00:09:09 +0200
In-Reply-To: <p06100407bc97865fe1f4@[129.46.227.161]>
References: <D3828D62-8732-11D8-AB6C-000A95B2B926@cisco.com> <97D2D91C-873B-11D8-970E-000A95B2BB72@xythos.com> <4071BD6F.3080303@gmx.de> <04CD947F-873E-11D8-970E-000A95B2BB72@xythos.com> <A146CD53-8745-11D8-86C0-00039384827E@greenbytes.de> <4071CD8F.2060701@gmx.de> <p06100407bc97865fe1f4@[129.46.227.161]>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <D90CA6B6-874D-11D8-86C0-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
Cc: Julian Reschke <julian.reschke@gmx.de>, Lisa Dusseault <lisa@xythos.com>,
        =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        Webdav WG <w3c-dist-auth@w3c.org>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Tue, 6 Apr 2004 00:09:03 +0200
To: Ted Hardie <hardie@qualcomm.com>
X-Mailer: Apple Mail (2.613)
X-Authenticated-Sender: se@greenbytes.de
X-Spam-Processed: greenbytes.de, Tue, 06 Apr 2004 00:09:09 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/D90CA6B6-874D-11D8-86C0-00039384827E@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8436
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405220957.281F0A1E7E@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 18:09:57 -0400 (EDT)
Content-Transfer-Encoding: 7bit



Am 05.04.2004 um 23:59 schrieb Ted Hardie:

> At 11:20 PM +0200 04/05/2004, Julian Reschke wrote:
>> Stefan Eissing wrote:
>>
>>> ...
>>> So, it is inaccurate and definitely not helping anyone with any 
>>> implementation issue to
>>> request cleanup of LOCKs from the authors of the bind spec. I 
>>> personally am waiting
>>> for 2 years now that RFC 2518bis makes progress comparable to other 
>>> specs of this
>>> group.
>>> ...
>>
>> Another way to look at this is that WebDAV LOCKING needs 
>> clarifications, but it needs them independantly of the BIND spec. It 
>> would be funny if we'd point people to the BIND spec if they have 
>> locking questions, yet do not plan to implement the BIND spec at all.
>>
>
> Speaking personally, my concern here would be that if those 
> clarifications were not
> present, BIND behavior became non-deterministic.  If 2518bis was done, 
> and
> BIND pointed to it to solve that hypothetical problem, all might be 
> goodness; if
> it will not be done, on the other hand, getting the job done in the 
> spec which
> will be completed might be the practical way to go.

But, alas, locks need fixing beyond the scope of the bind spec. As one 
example, RFC
2518 is unclear on the interaction between locks and the IF header. 
This is the
biggest area of non-interoperability. Now, the bind spec cannot clarify 
the general
working of the IF header and fixing the IF header needs also to be done 
for
servers which do not want to support the bind feature.

//Stefan




From w3c-dist-auth-request@w3.org  Mon Apr  5 18:14:22 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16308
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 18:14:22 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 3F383A25CA; Mon,  5 Apr 2004 18:14:24 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 74F34A25CA
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 18:14:23 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BAcMJ-0003HN-1q
	for w3c-dist-auth@w3c.org; Mon, 05 Apr 2004 18:14:23 -0400
Received: (qmail 5279 invoked by uid 65534); 5 Apr 2004 22:13:50 -0000
Received: from pD950C245.dip.t-dialin.net (EHLO gmx.de) (217.80.194.69)
  by mail.gmx.net (mp022) with SMTP; 06 Apr 2004 00:13:50 +0200
X-Authenticated: #1915285
Message-ID: <4071DA07.1040501@gmx.de>
Date: Tue, 06 Apr 2004 00:13:27 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ted Hardie <hardie@qualcomm.com>
Cc: Stefan Eissing <stefan.eissing@greenbytes.de>,
        Lisa Dusseault <lisa@xythos.com>,
        =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        Webdav WG <w3c-dist-auth@w3c.org>
References: <D3828D62-8732-11D8-AB6C-000A95B2B926@cisco.com> <97D2D91C-873B-11D8-970E-000A95B2BB72@xythos.com> <4071BD6F.3080303@gmx.de> <04CD947F-873E-11D8-970E-000A95B2BB72@xythos.com> <A146CD53-8745-11D8-86C0-00039384827E@greenbytes.de> <4071CD8F.2060701@gmx.de> <p06100407bc97865fe1f4@[129.46.227.161]>
In-Reply-To: <p06100407bc97865fe1f4@[129.46.227.161]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/4071DA07.1040501@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8437
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040405221424.3F383A25CA@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 18:14:24 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Ted Hardie wrote:

> Speaking personally, my concern here would be that if those 
> clarifications were not
> present, BIND behavior became non-deterministic.  If 2518bis was done, and
> BIND pointed to it to solve that hypothetical problem, all might be 
> goodness; if
> it will not be done, on the other hand, getting the job done in the spec 
> which
> will be completed might be the practical way to go.
> 
> Again, my personal two cents,
>             regards,
>                 Ted

If we rephrase that as "There should be a standards-track document 
clarifying WebDAV looking as soon as possible.", I'll absolutely agree. 
However, I think that document shouldn't be BIND, if only for the simple 
reason that it matters to those who don't plan to implement BIND at all 
as well.

If we can't get RFC2518bis finished soon, I think the approaches (2) and 
(3) presented in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0030.html> 
would make more sense:

--
2) Come up with a separate spec that updates RFC2518 and just summarizes
all that we changed or intend to change regarding locking (like
deprecation of lock-null resources, fixes to LOCK and lock refresh, If
header syntax, and lockdiscovery extensions). That would still be a
"draft standard" as RFC2518, but it would make things easier for
RFC2518bis as well, because all these changes would be written down in a
spec that came out prior to the revision, so wouldn't be "new" anymore.
It would also encourage implementors to actually *implement* these
changes and extensions *before* RFC2518bis comes out.

3) A drastic approach would be to de-couple locking entirely from
RFC2518 ("updating" RFC2518 again). That would look similar to how
RFC3253 is organized (locking would become an optional module, and
everything that needs to be said about locking would reside in that
separate document). Of course that approach would have a significant
impact on RFC2518bis, because optimally, it wouldn't say anything about
locking anymore either.
--

I'm willing to help working on either; we just need working group 
consensus to do this as it would affect the (currently dormant?) 
activities on RFC2518bis.

As an experiment, I've already extracted locking from RFC2518. This 
turned out to be relatively simple *except* for the locking semantics 
built into the "If" header checks (which will require some more 
thinking). BTW: RFC2518 shrinks by about 30% (interested parties just 
email me for a copy).

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Apr  5 22:09:10 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05273
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 22:09:09 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 8B6A0A48D6; Mon,  5 Apr 2004 22:09:06 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 6B297A216B
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 22:08:46 -0400 (EDT)
Received: from grunt24.ihug.com.au ([203.109.249.144])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAfvt-00051Q-0Q
	for w3c-dist-auth@w3c.org; Mon, 05 Apr 2004 22:03:21 -0400
Received: from p254-tnt2.adl.ihug.com.au ([192.168.0.2]) [203.173.252.254] 
	by grunt24.ihug.com.au with esmtp (Exim 3.35 #1 (Debian))
	id 1BAfvn-0001Vg-00; Tue, 06 Apr 2004 12:03:16 +1000
Mime-Version: 1.0 (Apple Message framework v613)
In-Reply-To: <4071DA07.1040501@gmx.de>
References: <D3828D62-8732-11D8-AB6C-000A95B2B926@cisco.com> <97D2D91C-873B-11D8-970E-000A95B2BB72@xythos.com> <4071BD6F.3080303@gmx.de> <04CD947F-873E-11D8-970E-000A95B2BB72@xythos.com> <A146CD53-8745-11D8-86C0-00039384827E@greenbytes.de> <4071CD8F.2060701@gmx.de> <p06100407bc97865fe1f4@[129.46.227.161]> <4071DA07.1040501@gmx.de>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <9B5FC24A-876E-11D8-8DF0-000393CE9EEE@ihug.com.au>
Content-Transfer-Encoding: 7bit
From: Antony Blakey <antony.blakey@ihug.com.au>
Date: Tue, 6 Apr 2004 11:33:33 +0930
To: Webdav WG <w3c-dist-auth@w3c.org>
X-Mailer: Apple Mail (2.613)
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/9B5FC24A-876E-11D8-8DF0-000393CE9EEE@ihug.com.au
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8438
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040406020906.8B6A0A48D6@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 22:09:06 -0400 (EDT)
Content-Transfer-Encoding: 7bit


I'm a (lurking) WebDAV implementer, and I'm waiting for BIND. I think 
it's bizarre to propose publishing BIND when understanding it depends 
on RFC2518bis, that has an indeterminate publish schedule and may never 
happen. IMO the only thing that makes sense is to publish locking 
separately, and only then publish BIND. I've been hoping this would 
happen ever since I saw GULP, so for what it's worth, I request 
Julian's point 3.

As an aside, I think the BIND spec should err on the side of ease of 
comprehension, rather than being axiomatically minimal. I think the 
process of writing such explanatory content is more likely to bring to 
light misunderstandings that illustrate ambiguity or incomplete 
coverage. Developing such non-normative explanatory content is a 
time-honoured and very effective mechanism to avoid that.

Just my $0.02

On 06/04/2004, at 7:43 AM, Julian Reschke wrote:

> 3) A drastic approach would be to de-couple locking entirely from
> RFC2518 ("updating" RFC2518 again). That would look similar to how
> RFC3253 is organized (locking would become an optional module, and
> everything that needs to be said about locking would reside in that
> separate document). Of course that approach would have a significant
> impact on RFC2518bis, because optimally, it wouldn't say anything about
> locking anymore either.

Antony Blakey
-------------
Some defeats are installments to victory.
   --Jacob Riis



From w3c-dist-auth-request@w3.org  Mon Apr  5 22:58:49 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09844
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 22:58:49 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 174A2A140E; Mon,  5 Apr 2004 22:58:52 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 96CCBA140E
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 22:58:50 -0400 (EDT)
Received: from e1.ny.us.ibm.com ([32.97.182.101])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAgna-0007Eq-21
	for w3c-dist-auth@w3c.org; Mon, 05 Apr 2004 22:58:50 -0400
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i362wIFe315814
	for <w3c-dist-auth@w3c.org>; Mon, 5 Apr 2004 22:58:18 -0400
Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i362wdrU102060
	for <w3c-dist-auth@w3c.org>; Mon, 5 Apr 2004 22:58:39 -0400
In-Reply-To: <4071DA07.1040501@gmx.de>
To: Webdav WG <w3c-dist-auth@w3c.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Message-ID: <OF434B86AC.A557239B-ON85256E6E.0005F963-85256E6E.00104001@us.ibm.com>
Date: Mon, 5 Apr 2004 22:58:13 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF282 | March 30, 2004) at
 04/05/2004 22:58:17,
	Serialize complete at 04/05/2004 22:58:17
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/OF434B86AC.A557239B-ON85256E6E.0005F963-85256E6E.00104001@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8439
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040406025852.174A2A140E@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 22:58:52 -0400 (EDT)


I strongly support choice #3 (issuing a locking draft).

If we are considering defining locking behavior in a 
separate draft that isn't about locking (i.e. the bind draft),
then I think doing so in a separate draft makes the most sense.

Especially if Julian has done most of the editorial work
(thanks, Julian!), we should be able to focus on it after
the binding draft is finalized, and get it out soon afterwards
(once it is decoupled from the many unresolved issues in
the rest of 2518bis).

Cheers,
Geoff

Julian wrote on 04/05/2004 06:13:27 PM:

> 
> Ted Hardie wrote:
> 
> > Speaking personally, my concern here would be that if those 
> > clarifications were not
> > present, BIND behavior became non-deterministic.  If 2518bis was done, 
and
> > BIND pointed to it to solve that hypothetical problem, all might be 
> > goodness; if
> > it will not be done, on the other hand, getting the job done in the 
spec 
> > which
> > will be completed might be the practical way to go.
> > 
> > Again, my personal two cents,
> >             regards,
> >                 Ted
> 
> If we rephrase that as "There should be a standards-track document 
> clarifying WebDAV looking as soon as possible.", I'll absolutely agree. 
> However, I think that document shouldn't be BIND, if only for the simple 

> reason that it matters to those who don't plan to implement BIND at all 
> as well.
> 
> If we can't get RFC2518bis finished soon, I think the approaches (2) and 

> (3) presented in 
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0030.html> 

> would make more sense:
> 
> --
> 2) Come up with a separate spec that updates RFC2518 and just summarizes
> all that we changed or intend to change regarding locking (like
> deprecation of lock-null resources, fixes to LOCK and lock refresh, If
> header syntax, and lockdiscovery extensions). That would still be a
> "draft standard" as RFC2518, but it would make things easier for
> RFC2518bis as well, because all these changes would be written down in a
> spec that came out prior to the revision, so wouldn't be "new" anymore.
> It would also encourage implementors to actually *implement* these
> changes and extensions *before* RFC2518bis comes out.
> 
> 3) A drastic approach would be to de-couple locking entirely from
> RFC2518 ("updating" RFC2518 again). That would look similar to how
> RFC3253 is organized (locking would become an optional module, and
> everything that needs to be said about locking would reside in that
> separate document). Of course that approach would have a significant
> impact on RFC2518bis, because optimally, it wouldn't say anything about
> locking anymore either.
> --
> 
> I'm willing to help working on either; we just need working group 
> consensus to do this as it would affect the (currently dormant?) 
> activities on RFC2518bis.
> 
> As an experiment, I've already extracted locking from RFC2518. This 
> turned out to be relatively simple *except* for the locking semantics 
> built into the "If" header checks (which will require some more 
> thinking). BTW: RFC2518 shrinks by about 30% (interested parties just 
> email me for a copy).
> 
> Regards, Julian
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 



From w3c-dist-auth-request@w3.org  Mon Apr  5 22:58:56 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09862
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 22:58:56 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 865FFA1A82; Mon,  5 Apr 2004 22:58:58 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 903C9A1940
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 22:58:57 -0400 (EDT)
Received: from e3.ny.us.ibm.com ([32.97.182.103])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAgnh-0007Fp-FT
	for w3c-dist-auth@w3c.org; Mon, 05 Apr 2004 22:58:57 -0400
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i362wQBd746350
	for <w3c-dist-auth@w3c.org>; Mon, 5 Apr 2004 22:58:26 -0400
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i362whrW113370
	for <w3c-dist-auth@w3c.org>; Mon, 5 Apr 2004 22:58:47 -0400
In-Reply-To: <D3828D62-8732-11D8-AB6C-000A95B2B926@cisco.com>
To: Webdav WG <w3c-dist-auth@w3c.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Message-ID: <OF9DC761A1.5A1AA146-ON85256E6E.000B58D0-85256E6E.00104276@us.ibm.com>
Date: Mon, 5 Apr 2004 22:58:19 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF282 | March 30, 2004) at
 04/05/2004 22:58:25,
	Serialize complete at 04/05/2004 22:58:25
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/OF9DC761A1.5A1AA146-ON85256E6E.000B58D0-85256E6E.00104276@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8440
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040406025858.865FFA1A82@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 22:58:58 -0400 (EDT)


Patrik wrote on 04/05/2004 02:55:37 PM:

> Julian wrote:
> 
> > Lisa Dusseault wrote:
> >
> >> In general, the spec needs more info to specify how existing things
> >> work. All the following questions must be answered in the spec, NOT 
> >> just
> >> in email. The spec must be explicit, because different people reading 

> >> a
> >> model description always end up with different ideas how the model 
> >> works
> >> in practice.
> >
> > Here I disagree.
> 
> Remember I asked a question explicitly about interoperability between 
> things developed by just reading the spec...then look at the list 
> below. I don't see the statement "yes, there will be interoperability" 
> matches those statements.
> 
> Can you explain?

The phrase Julian (and I as well, in a separate message) disagreed with
was "All the following questions must be answered in the spec, NOT 
just in email".

In particular, our response was: some questions are answered in email,
some questions become issues, and some issues end up causing changes to
the spec.  If every question on the mailing list required an explicit
addition to the spec, the spec would become completely inaccessible due
to its bulk.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Mon Apr  5 23:23:28 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11117
	for <webdav-archive@lists.ietf.org>; Mon, 5 Apr 2004 23:23:28 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 496F5A20B9; Mon,  5 Apr 2004 23:23:30 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id D3409A2134
	for <w3c-dist-auth@listhub.w3.org>; Mon,  5 Apr 2004 23:23:22 -0400 (EDT)
Received: from e4.ny.us.ibm.com ([32.97.182.104])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAhBF-0002DX-Rq
	for w3c-dist-auth@w3c.org; Mon, 05 Apr 2004 23:23:17 -0400
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i363Mlmt879020
	for <w3c-dist-auth@w3c.org>; Mon, 5 Apr 2004 23:22:47 -0400
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i363N8rU108012
	for <w3c-dist-auth@w3c.org>; Mon, 5 Apr 2004 23:23:08 -0400
In-Reply-To: <9B5FC24A-876E-11D8-8DF0-000393CE9EEE@ihug.com.au>
To: Webdav WG <w3c-dist-auth@w3c.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF4DBEAE3D.7E19989C-ON85256E6E.0011E91E-85256E6E.00127D47@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Mon, 5 Apr 2004 23:22:41 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF282 | March 30, 2004) at
 04/05/2004 23:22:46,
	Serialize complete at 04/05/2004 23:22:46
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/OF4DBEAE3D.7E19989C-ON85256E6E.0011E91E-85256E6E.00127D47@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8441
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040406032330.496F5A20B9@frink.w3.org>
Resent-Date: Mon,  5 Apr 2004 23:23:30 -0400 (EDT)


Hi Antony,

Thanks for speaking up!  It's folks that aren't part of the
design team whose feedback on this point is most valuable.

I agree that comprehensibility is more important than
axiomatic minimality, but we do try to avoid duplicating
normative information from other specs, to avoid confusion
when those other specs are revised.

Were there specific parts about the BIND spec that you felt
merited/required additional explanation?

Thanks,
Geoff


Antony wrote on 04/05/2004 10:03:33 PM:

> I'm a (lurking) WebDAV implementer, and I'm waiting for BIND. I think 
> it's bizarre to propose publishing BIND when understanding it depends 
> on RFC2518bis, that has an indeterminate publish schedule and may never 
> happen. IMO the only thing that makes sense is to publish locking 
> separately, and only then publish BIND. I've been hoping this would 
> happen ever since I saw GULP, so for what it's worth, I request 
> Julian's point 3.
> 
> As an aside, I think the BIND spec should err on the side of ease of 
> comprehension, rather than being axiomatically minimal. I think the 
> process of writing such explanatory content is more likely to bring to 
> light misunderstandings that illustrate ambiguity or incomplete 
> coverage. Developing such non-normative explanatory content is a 
> time-honoured and very effective mechanism to avoid that.
> 
> Just my $0.02
> 
> On 06/04/2004, at 7:43 AM, Julian Reschke wrote:
> 
> > 3) A drastic approach would be to de-couple locking entirely from
> > RFC2518 ("updating" RFC2518 again). That would look similar to how
> > RFC3253 is organized (locking would become an optional module, and
> > everything that needs to be said about locking would reside in that
> > separate document). Of course that approach would have a significant
> > impact on RFC2518bis, because optimally, it wouldn't say anything 
about
> > locking anymore either.
> 
> Antony Blakey
> -------------
> Some defeats are installments to victory.
>    --Jacob Riis
> 



From w3c-dist-auth-request@w3.org  Tue Apr  6 00:13:20 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14612
	for <webdav-archive@lists.ietf.org>; Tue, 6 Apr 2004 00:13:20 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 182CAA1356; Tue,  6 Apr 2004 00:13:22 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id D4985A1356
	for <w3c-dist-auth@listhub.w3.org>; Tue,  6 Apr 2004 00:13:17 -0400 (EDT)
Received: from grunt23.ihug.com.au ([203.109.249.143])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAhxd-0002rY-B5
	for w3c-dist-auth@w3c.org; Tue, 06 Apr 2004 00:13:17 -0400
Received: from p254-tnt2.adl.ihug.com.au ([192.168.0.2]) [203.173.252.254] 
	by grunt23.ihug.com.au with esmtp (Exim 3.35 #1 (Debian))
	id 1BAhxY-0003C8-00; Tue, 06 Apr 2004 14:13:13 +1000
In-Reply-To: <OF4DBEAE3D.7E19989C-ON85256E6E.0011E91E-85256E6E.00127D47@us.ibm.com>
References: <OF4DBEAE3D.7E19989C-ON85256E6E.0011E91E-85256E6E.00127D47@us.ibm.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <C2DF20A8-8780-11D8-8DF0-000393CE9EEE@ihug.com.au>
Content-Transfer-Encoding: 7bit
Cc: Webdav WG <w3c-dist-auth@w3c.org>
From: Antony Blakey <antony.blakey@ihug.com.au>
Date: Tue, 6 Apr 2004 13:43:30 +0930
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
X-Mailer: Apple Mail (2.613)
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/C2DF20A8-8780-11D8-8DF0-000393CE9EEE@ihug.com.au
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8442
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040406041322.182CAA1356@frink.w3.org>
Resent-Date: Tue,  6 Apr 2004 00:13:22 -0400 (EDT)
Content-Transfer-Encoding: 7bit



On 06/04/2004, at 12:52 PM, Geoffrey M Clemm wrote:

> Thanks for speaking up!  It's folks that aren't part of the
> design team whose feedback on this point is most valuable.

The fact that I have to reconstruct design motivations from the mailing 
list when reading the spec in order to review it is demonstration of 
why more non-normative content should be with the spec. Otherwise 
responses will be driven by "that's more work for my server" or "that 
doesn't match my use case" rather than "I understand the trade-offs 
required by both extant and projected uses", which seems to me to be 
what is truly required. I've given an example of this below.

I don't feel qualified to give detailed feedback because I'm not sure 
*why* certain decisions were made.

> I agree that comprehensibility is more important than
> axiomatic minimality, but we do try to avoid duplicating
> normative information from other specs, to avoid confusion
> when those other specs are revised.

I'm talking about non-normative content. As a matter of process I think 
that writing (for example) a user guide, generates a better spec. In 
this case, the spec would be less likely to reflect the hidden 
assumptions of specific implementers. Writing explanation is like peer 
review of code.

> Were there specific parts about the BIND spec that you felt
> merited/required additional explanation?

To be honest, my comments were motivated by watching the discussion 
between (principally) Lisa and Julian, rather than reading the most 
recent BIND spec, although now I'm motivated to do that!

I know there have been arguments about DELETE not being equivalent to 
UNBIND, and MOVE not being BIND+UNBIND. However, our implementation is 
transactional and non-transactional semantics seem broken to us - 
that's one place where some non-normative content motivating these 
distinctions would help. As another (tangential) example, having a lock 
create a new resource seems, on the surface, broken to us, because 
effects caused by a failed lock creator should be rolled back at the 
server. IMO any spec specifying that behaviour should say why that's 
required. I'm sure there must be some reason for this that 
non-transactional environments require, which is outside our headspace.

As a matter of completeness: it has always seemed to me that binding is 
more fundamental than locking, and that it would be better to have the 
WebDAV spec recast in terms of bindings, with support for more than one 
binding to a resource as an implementation option. Locking would then 
be on top of that, explaining how core semantics are modified in the 
presence of locks. I know this isn't going to happen.

Antony Blakey
-------------
Reflecting on W.H. Auden's contemplation of 'necessary murders' in the 
Spanish Civil War, George Orwell wrote that such amorality was only 
really possible, 'if you are the kind of person who is always somewhere 
else when the trigger is pulled'.
   -- John Birmingham, "Appeasing Jakarta"



From w3c-dist-auth-request@w3.org  Tue Apr  6 03:31:03 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16610
	for <webdav-archive@lists.ietf.org>; Tue, 6 Apr 2004 03:31:03 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 542EAA1E14; Tue,  6 Apr 2004 03:31:03 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id B1A3AA1F70
	for <w3c-dist-auth@listhub.w3.org>; Tue,  6 Apr 2004 03:31:00 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BAl2x-0004i2-7r
	for w3c-dist-auth@w3c.org; Tue, 06 Apr 2004 03:30:59 -0400
Received: (qmail 19788 invoked by uid 65534); 6 Apr 2004 07:30:23 -0000
Received: from pD950C3AE.dip.t-dialin.net (EHLO gmx.de) (217.80.195.174)
  by mail.gmx.net (mp014) with SMTP; 06 Apr 2004 09:30:23 +0200
X-Authenticated: #1915285
Message-ID: <40725C73.8000104@gmx.de>
Date: Tue, 06 Apr 2004 09:29:55 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Antony Blakey <antony.blakey@ihug.com.au>
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>,
        Webdav WG <w3c-dist-auth@w3c.org>
References: <OF4DBEAE3D.7E19989C-ON85256E6E.0011E91E-85256E6E.00127D47@us.ibm.com> <C2DF20A8-8780-11D8-8DF0-000393CE9EEE@ihug.com.au>
In-Reply-To: <C2DF20A8-8780-11D8-8DF0-000393CE9EEE@ihug.com.au>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/40725C73.8000104@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8443
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040406073103.542EAA1E14@frink.w3.org>
Resent-Date: Tue,  6 Apr 2004 03:31:03 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Antony Blakey wrote:

> ...
> To be honest, my comments were motivated by watching the discussion 
> between (principally) Lisa and Julian, rather than reading the most 
> recent BIND spec, although now I'm motivated to do that!

That whould be great...

> I know there have been arguments about DELETE not being equivalent to 
> UNBIND, and MOVE not being BIND+UNBIND. However, our implementation is 

Well, REBIND isn't MOVE as the working group couldn't change the 
semantics for MOVE (that would have breaked existing code). Thus REBIND 
is introduced as atomic version of MOVE:

"The REBIND method removes a binding to a resource from one collection, 
and adds a binding to that resource into another collection. It is 
effectively an atomic form of a MOVE request."

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#METHOD_REBIND>

Clients can now select a best-effort move (MOVE) or a transactional one 
(REBIND), when supported by the server.

The situation for DELETE vs UNBIND is a bit more complicated. Do you 
think the rational should be explained here?

> transactional and non-transactional semantics seem broken to us - that's 
> one place where some non-normative content motivating these distinctions 
> would help. As another (tangential) example, having a lock create a new 

Well, that's an issue with RFC2518, right? MOVE and DELETE aren't atomic 
for the simple reason that there are servers that can't or don't want to 
implement in atomically.

> resource seems, on the surface, broken to us, because effects caused by 
> a failed lock creator should be rolled back at the server. IMO any spec 
> specifying that behaviour should say why that's required. I'm sure there 
> must be some reason for this that non-transactional environments 
> require, which is outside our headspace.

I'm not sure what you're talking about here. LOCK is a bit special in 
that it creates an empty resource when the URL wasn't mapped before, but 
that is needed to implement a safe way to do a safe "save as" operation. 
The LOCK operation itself is transactional. Either it succeeds (and 
creates a locked resource), or it fails (in which case nothing should be 
left). BTW, this is standard RFC2518 and has nothing to do with BIND.

> As a matter of completeness: it has always seemed to me that binding is 
> more fundamental than locking, and that it would be better to have the 
> WebDAV spec recast in terms of bindings, with support for more than one 
> binding to a resource as an implementation option. Locking would then be

I agree with the fact that bindings are more fundamental, as they affect 
the understanding of the relation of URLs, collection membership and 
resources. That being said, RFC2518 already does that in a minimal way; 
it just calls bindings "internal member URIs" and doesn't provide

- "same resource" discovery
- explicitly creating new bindings

But the concept per se is there.

> on top of that, explaining how core semantics are modified in the 
> presence of locks. I know this isn't going to happen.

Well, we've been discussing separating locking from the rest for some 
time now (see the mail thread that started in January: 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/thread.html#30>). 
However, this proposal affects an official working group item 
(RFC2518bis), so we didn't make any progress here yet, missing support 
from the RFC2518bis authors.


Regards, Julian
-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Tue Apr  6 11:08:20 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26217
	for <webdav-archive@lists.ietf.org>; Tue, 6 Apr 2004 11:08:19 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 3B672A0795; Tue,  6 Apr 2004 11:08:21 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 7F1F8A2CAE
	for <w3c-dist-auth@listhub.w3.org>; Tue,  6 Apr 2004 11:08:18 -0400 (EDT)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAsBW-0003cX-82
	for w3c-dist-auth@w3c.org; Tue, 06 Apr 2004 11:08:18 -0400
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i36F8G5m000633 sender ccjason@us.ibm.com for w3c-dist-auth@w3c.org; Tue, 6 Apr 2004 08:08:16 -0700
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by bandage.seagull.net (8.12.10) with ESMTP id i36F8CVh000388 sender ccjason@us.ibm.com; Tue, 6 Apr 2004 08:08:13 -0700
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i36F7xmt822914; Tue, 6 Apr 2004 11:08:01 -0400
Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i36F8K40109894; Tue, 6 Apr 2004 11:08:20 -0400
To: Webdav WG <nnw3c-dist-auth___at___w3c.org@smallcue.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Jason Crawford <ccjason@us.ibm.com>
Message-ID: <OFC5C157DB.2860AFEA-ON85256E6E.0051BDED-85256E6E.00531B35@us.ibm.com>
Date: Tue, 6 Apr 2004 11:07:44 -0400
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF87 | March 11, 2004) at 04/06/2004 11:07:58, Serialize complete at 04/06/2004 11:07:58
Content-Type: multipart/alternative; boundary="=_alternative 00528E5185256E6E_="
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/OFC5C157DB.2860AFEA-ON85256E6E.0051BDED-85256E6E.00531B35@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8444
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040406150821.3B672A0795@frink.w3.org>
Resent-Date: Tue,  6 Apr 2004 11:08:21 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 00528E5185256E6E_=
Content-Type: text/plain; charset="us-ascii"

A new LOCKING document?  I'm not sure.  Admittedly LOCK'ing has been a 
problem for a long time.   Tossing out lock-null resources was a big help. 
  Is locking holding up 2518bis?  Does creating a new document help? Let's 
hear the pros and cons of having a separate document for locking?

J.

--=_alternative 00528E5185256E6E_=
Content-Type: text/html; charset="us-ascii"


<br>
<br><font size=2 face="sans-serif">A new LOCKING document? &nbsp;I'm not sure. &nbsp;Admittedly LOCK'ing has been a problem for a long time. &nbsp; Tossing out lock-null resources was a big help. &nbsp; Is locking holding up 2518bis? &nbsp;Does creating a new document help? &nbsp; Let's hear the pros and cons of having a separate document for locking?</font>
<br>
<br><font size=2 face="sans-serif">J.</font>
<br>
--=_alternative 00528E5185256E6E_=--



From w3c-dist-auth-request@w3.org  Tue Apr  6 11:16:42 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26985
	for <webdav-archive@lists.ietf.org>; Tue, 6 Apr 2004 11:16:42 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 58A86A2B47; Tue,  6 Apr 2004 11:16:43 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id D77C1A2B47
	for <w3c-dist-auth@listhub.w3.org>; Tue,  6 Apr 2004 11:16:39 -0400 (EDT)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAsJb-0005U0-Li
	for w3c-dist-auth@w3c.org; Tue, 06 Apr 2004 11:16:39 -0400
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i36FGcwi006607 sender julian.reschke@gmx.de for w3c-dist-auth@w3c.org; Tue, 6 Apr 2004 08:16:38 -0700
Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by bandage.seagull.net (8.12.10) with SMTP id i36FGbqh006571 sender julian.reschke@gmx.de for <nnw3c-dist-auth___at___w3c.org@smallcue.com>; Tue, 6 Apr 2004 08:16:38 -0700
Received: (qmail 22156 invoked by uid 65534); 6 Apr 2004 15:16:26 -0000
Received: from p50824568.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.69.104) by mail.gmx.net (mp014) with SMTP; 06 Apr 2004 17:16:26 +0200
Message-ID: <4072C9C9.7050807@gmx.de>
Date: Tue, 06 Apr 2004 17:16:25 +0200
From: Julian Reschke <julian.reschke@gmx.de>
MIME-Version: 1.0
To: Jason Crawford <ccjason@us.ibm.com>
Cc: Webdav WG <nnw3c-dist-auth___at___w3c.org@smallcue.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/4072C9C9.7050807@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8445
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040406151643.58A86A2B47@frink.w3.org>
Resent-Date: Tue,  6 Apr 2004 11:16:43 -0400 (EDT)


Jason Crawford wrote:
> 
> 
> A new LOCKING document?  I'm not sure.  Admittedly LOCK'ing has been a 
> problem for a long time.   Tossing out lock-null resources was a big 
> help.   Is locking holding up 2518bis?  Does creating a new document 
> help?   Let's hear the pros and cons of having a separate document for 
> locking?

We talked about that in January 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0030.html>).

Primarily, it reduces the complexity of RFC2518bis, and allows us to 
both clarify and enhance locking without getting problems with 
RFC2518bis advancing in the standards ladder.

And yes, what's holding up 2518bis? The last draft was posted almost six 
months ago, to which I replied with a long list of issues. There was 
almost no feedback.

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Tue Apr  6 13:16:27 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07771
	for <webdav-archive@lists.ietf.org>; Tue, 6 Apr 2004 13:16:27 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id D18C8A1830; Tue,  6 Apr 2004 13:16:27 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id C7A37A1830
	for <w3c-dist-auth@listhub.w3.org>; Tue,  6 Apr 2004 13:16:26 -0400 (EDT)
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAuBW-0000PP-Lp
	for w3c-dist-auth@w3.org; Tue, 06 Apr 2004 13:16:26 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07768;
	Tue, 6 Apr 2004 13:16:24 -0400 (EDT)
Message-Id: <200404061716.NAA07768@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: w3c-dist-auth@w3.org
From: Internet-Drafts@ietf.org
Date: Tue, 06 Apr 2004 13:16:24 -0400
Subject: I-D ACTION:draft-ietf-webdav-redirectref-protocol-08.txt
X-Archived-At: http://www.w3.org/mid/200404061716.NAA07768@ietf.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8446
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040406171627.D18C8A1830@frink.w3.org>
Resent-Date: Tue,  6 Apr 2004 13:16:27 -0400 (EDT)


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF.

	Title		: Web Distributed Authoring and Versioning (WebDAV) 
			  Redirect Reference Resources
	Author(s)	: J. Whitehead, et al.
	Filename	: draft-ietf-webdav-redirectref-protocol-08.txt
	Pages		: 33
	Date		: 2004-4-5
	
This specification defines redirect reference resources.  A redirect
reference resource is a resource whose default response is an HTTP/
1.1 302 (Found) status code, redirecting the client to a different
resource, the target resource.  A redirect reference makes it
possible to access the target resource indirectly, through any URI
mapped to the redirect reference resource.  There are no integrity
guarantees associated with redirect reference resources.
Distribution of this document is unlimited. Please send comments to
the Distributed Authoring and Versioning (WebDAV) working group at
w3c-dist-auth@w3.org [1], which may be joined by sending a message
with subject 'subscribe' to w3c-dist-auth-request@w3.org [2].
Discussions of the WEBDAV working group are archived at URL: http://
lists.w3.org/Archives/Public/w3c-dist-auth/.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-webdav-redirectref-protocol-08.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-webdav-redirectref-protocol-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-webdav-redirectref-protocol-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2004-4-6105457.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-webdav-redirectref-protocol-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-webdav-redirectref-protocol-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2004-4-6105457.I-D@ietf.org>

--OtherAccess--

--NextPart--




From w3c-dist-auth-request@w3.org  Tue Apr  6 13:25:54 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08850
	for <webdav-archive@lists.ietf.org>; Tue, 6 Apr 2004 13:25:54 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 0E984A254D; Tue,  6 Apr 2004 13:25:55 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 4C5D2A254D
	for <w3c-dist-auth@listhub.w3.org>; Tue,  6 Apr 2004 13:25:44 -0400 (EDT)
Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BAuKW-0002AU-2o
	for w3c-dist-auth@w3.org; Tue, 06 Apr 2004 13:25:44 -0400
Received: (qmail 25368 invoked by uid 65534); 6 Apr 2004 17:25:13 -0000
Received: from p50824568.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.69.104)
  by mail.gmx.net (mp006) with SMTP; 06 Apr 2004 19:25:13 +0200
X-Authenticated: #1915285
Message-ID: <4072E7F7.3000009@gmx.de>
Date: Tue, 06 Apr 2004 19:25:11 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <200404061716.NAA07768@ietf.org>
In-Reply-To: <200404061716.NAA07768@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: I-D ACTION:draft-ietf-webdav-redirectref-protocol-08.txt
X-Archived-At: http://www.w3.org/mid/4072E7F7.3000009@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8447
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040406172555.0E984A254D@frink.w3.org>
Resent-Date: Tue,  6 Apr 2004 13:25:55 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi.

This draft reflects the current state and is work-in-progress. Changes 
since draft 07 are...:

    Closed issue "lc-38-not-hierarchical". Cleaned up DTD fragments in
    appendix. Close (reject) issues "lc-55-iana" and "lc-41-no-webdav".
    Add issue "5_mkresource" and start work on MKREDIRECTREF (issue
    closed, but more work on MKREDIRECTREF needs to be done for updates
    and status codes other than 302). Start resolution of "lc-85-301",
    replacing "302" by more generic language. Update issue
    "lc-57-noautoupdate". Close issue "lc-37-integrity" (duplicate of
    "lc-57-autoupdate"). Started work on "lc-85-301". Add L. Dusseault
    and S. Eissing to Acknowledgments section.

Edits continue on 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-latest.html>, 
the issues list is located at 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-issues.html>.

Best regards, Julian



From w3c-dist-auth-request@w3.org  Tue Apr  6 15:14:14 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16852
	for <webdav-archive@lists.ietf.org>; Tue, 6 Apr 2004 15:14:13 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id BA4FCA07CC; Tue,  6 Apr 2004 15:14:14 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id CE64BA0967
	for <w3c-dist-auth@listhub.w3.org>; Tue,  6 Apr 2004 15:14:12 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAw1U-00006D-L7
	for w3c-dist-auth@w3c.org; Tue, 06 Apr 2004 15:14:12 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i36JDphV004231
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 6 Apr 2004 12:13:53 -0700
In-Reply-To: <4072C9C9.7050807@gmx.de>
References: <4072C9C9.7050807@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <87197BB2-87FE-11D8-970E-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: Jason Crawford <ccjason@us.ibm.com>, Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Tue, 6 Apr 2004 12:13:46 -0700
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Status of RFC2518Bis (Was Re: Remaining issues with the bind draft -- process)
X-Archived-At: http://www.w3.org/mid/87197BB2-87FE-11D8-970E-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8448
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040406191414.BA4FCA07CC@frink.w3.org>
Resent-Date: Tue,  6 Apr 2004 15:14:14 -0400 (EDT)
Content-Transfer-Encoding: 7bit



What's been holding up RFC2518bis is lack of clear consensus -- or a  
reliable way of determining it -- on several issues.  When we're ready,  
we can reintroduce discussion on those issues and see if now there is a  
clear consensus or a way to determine one.

The most high-level issue is whether RFC2518bis is intended to be a  
proposed standard or a draft standard.  I believe this issue is implied  
by the proposal to remove locking from RFC2518 -- a change that big,  
even though it's a feature removal, may require recycling at proposed  
standard.

Lisa

On Apr 6, 2004, at 8:16 AM, Julian Reschke wrote:

>
> Jason Crawford wrote:
>> A new LOCKING document?  I'm not sure.  Admittedly LOCK'ing has been  
>> a problem for a long time.   Tossing out lock-null resources was a  
>> big help.   Is locking holding up 2518bis?  Does creating a new  
>> document help?   Let's hear the pros and cons of having a separate  
>> document for locking?
>
> We talked about that in January  
> (<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/ 
> 0030.html>).
>
> Primarily, it reduces the complexity of RFC2518bis, and allows us to  
> both clarify and enhance locking without getting problems with  
> RFC2518bis advancing in the standards ladder.
>
> And yes, what's holding up 2518bis? The last draft was posted almost  
> six months ago, to which I replied with a long list of issues. There  
> was almost no feedback.
>
> Regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Tue Apr  6 15:23:47 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17368
	for <webdav-archive@lists.ietf.org>; Tue, 6 Apr 2004 15:23:47 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B5FCEA2037; Tue,  6 Apr 2004 15:23:48 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 700C4A2037
	for <w3c-dist-auth@listhub.w3.org>; Tue,  6 Apr 2004 15:23:47 -0400 (EDT)
Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BAwAl-0002Lh-5U
	for w3c-dist-auth@w3c.org; Tue, 06 Apr 2004 15:23:47 -0400
Received: (qmail 15707 invoked by uid 65534); 6 Apr 2004 19:23:15 -0000
Received: from pD950C3AE.dip.t-dialin.net (EHLO gmx.de) (217.80.195.174)
  by mail.gmx.net (mp018) with SMTP; 06 Apr 2004 21:23:15 +0200
X-Authenticated: #1915285
Message-ID: <40730393.40605@gmx.de>
Date: Tue, 06 Apr 2004 21:22:59 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Jason Crawford <ccjason@us.ibm.com>, Webdav WG <w3c-dist-auth@w3c.org>
References: <4072C9C9.7050807@gmx.de> <87197BB2-87FE-11D8-970E-000A95B2BB72@osafoundation.org>
In-Reply-To: <87197BB2-87FE-11D8-970E-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Status of RFC2518Bis (Was Re: Remaining issues with the bind  draft -- process)
X-Archived-At: http://www.w3.org/mid/40730393.40605@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8449
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040406192348.B5FCEA2037@frink.w3.org>
Resent-Date: Tue,  6 Apr 2004 15:23:48 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> What's been holding up RFC2518bis is lack of clear consensus -- or a  
> reliable way of determining it -- on several issues.  When we're ready,  
> we can reintroduce discussion on those issues and see if now there is a  
> clear consensus or a way to determine one.
> 
> The most high-level issue is whether RFC2518bis is intended to be a  
> proposed standard or a draft standard.  I believe this issue is implied  
> by the proposal to remove locking from RFC2518 -- a change that big,  
> even though it's a feature removal, may require recycling at proposed  
> standard.

Lisa,

that proposal has been made *because* of the lack of process; not the 
other way around.

Locking has been optional in RFC2518, so there shouldn't be any problem 
whatsoever having a RFC2518bis-minus-locking going to draft. In fact 
it'll be easier because locking is the area that needs most attention.

That being said, what *is* your position regarding separating locking 
into a separate document?

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Tue Apr  6 16:58:50 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26862
	for <webdav-archive@lists.ietf.org>; Tue, 6 Apr 2004 16:58:50 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 9DB66A4E52; Tue,  6 Apr 2004 16:58:52 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 999B2A4E52
	for <w3c-dist-auth@listhub.w3.org>; Tue,  6 Apr 2004 16:58:47 -0400 (EDT)
Received: from natnoddy.rzone.de ([81.169.145.166])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAxeh-0005aX-BT
	for w3c-dist-auth@w3c.org; Tue, 06 Apr 2004 16:58:47 -0400
Received: from x.oberon.ethz.ch (p5083CECE.dip0.t-ipconnect.de [80.131.206.206])
	by post.webmailer.de (8.12.10/8.12.10) with SMTP id i36KwiXe007169;
	Tue, 6 Apr 2004 22:58:45 +0200 (MEST)
Date: Tue, 6 Apr 2004 22:58:44 +0200 (MEST)
Message-Id: <200404062058.i36KwiXe007169@post.webmailer.de>
From: edgar@edgarschwarz.de
X-Mailer: Oberon Mail (ejz) on Aos 20.02.2004
To: w3c-dist-auth@w3c.org
Cc: edgar@edgarschwarz.de
Subject: Re (2): Status of RFC2518Bis
X-Archived-At: http://www.w3.org/mid/200404062058.i36KwiXe007169@post.webmailer.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8450
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040406205852.9DB66A4E52@frink.w3.org>
Resent-Date: Tue,  6 Apr 2004 16:58:52 -0400 (EDT)


Julian Reschke <julian.reschke@gmx.de> schrieb:
> Locking has been optional in RFC2518, so there shouldn't be any problem 
> whatsoever having a RFC2518bis-minus-locking going to draft. In fact 
> it'll be easier because locking is the area that needs most attention.
>
> That being said, what *is* your position regarding separating locking 
> into a separate document?
I wonder at the moment what we win by locking ?
Roughly speaking it's for avoiding collaborative workers to damage other peoples
work.
But it seems defining and implementing locks successfully is very difficult.
OTOH there is DeltaV which also is a means (Albeit more complex, but servers and
clients are coming) to avoid collaborative conflicts.
So who needs locking ? Me definitely not.
I would be happy to implement DeltaV and the underlying RFC2518 stuff without having
to implement locks.
So doing a RFC2518bis-minus-locking would be fine with me.
And whoever wants locks because he doesn't like DeltaV can work on a lock spec.
This also would help BIND, which wouldn't need to say anything about locks
anymore.
Locking has been a pain in the ass for years. So let's get rid of it in RFC2518bis !
This really could help us to make progress because many disagreements will
disappear.
Just my 2 cent without giving it a lot of thought.

Cheers, Edgar






From w3c-dist-auth-request@w3.org  Tue Apr  6 18:58:42 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07619
	for <webdav-archive@lists.ietf.org>; Tue, 6 Apr 2004 18:58:42 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 92991A1693; Tue,  6 Apr 2004 18:58:44 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 39884A1481
	for <w3c-dist-auth@listhub.w3.org>; Tue,  6 Apr 2004 18:58:43 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BAzWl-0002GA-0R
	for w3c-dist-auth@w3c.org; Tue, 06 Apr 2004 18:58:43 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i36MvXhV021116
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 6 Apr 2004 15:57:37 -0700
In-Reply-To: <40730393.40605@gmx.de>
References: <4072C9C9.7050807@gmx.de> <87197BB2-87FE-11D8-970E-000A95B2BB72@osafoundation.org> <40730393.40605@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <C73CCBAA-881D-11D8-970E-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: Jason Crawford <ccjason@us.ibm.com>, Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Tue, 6 Apr 2004 15:57:28 -0700
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: Status of RFC2518Bis (Was Re: Remaining issues with the bind draft -- process)
X-Archived-At: http://www.w3.org/mid/C73CCBAA-881D-11D8-970E-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8451
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040406225844.92991A1693@frink.w3.org>
Resent-Date: Tue,  6 Apr 2004 18:58:44 -0400 (EDT)
Content-Transfer-Encoding: 7bit


I don't think it's a great idea to split out locking, but I don't think 
it's a terrible idea either.  It's not necessary to remove it, so the 
conservative answer would be to leave it.  OTOH if we were to issue a 
"WebDAV 100% required core features" RFC and a "WebDAV locking" RFC at 
the same time, then it's mostly a case of document convenience and 
perceptions.

The situation with locking is not that bad, as Julian pointed out 
particularly because lock-null resources have been removed.  We could 
simplify further if we think there are still complex or 
rarely-implemented parts (if header parsing being the most obvious 
candidate there, or remove shared locks).  But many (most?) clients and 
servers *do* implement locking, and do so successfully.  There's good 
interoperability.  It's useful.  Many clients routinely lock files 
while they're open and being edited.

Given the discussion so far, I fall on the side of keeping RFC 2518 
whole.  It's not an unmanageable size.  It encourages servers to 
implement locking if they can, which helps the clients that find 
locking useful, and is nice for such an important feature of 
distributed authoring.

Lisa

On Apr 6, 2004, at 12:22 PM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>
>> What's been holding up RFC2518bis is lack of clear consensus -- or a  
>> reliable way of determining it -- on several issues.  When we're 
>> ready,  we can reintroduce discussion on those issues and see if now 
>> there is a  clear consensus or a way to determine one.
>> The most high-level issue is whether RFC2518bis is intended to be a  
>> proposed standard or a draft standard.  I believe this issue is 
>> implied  by the proposal to remove locking from RFC2518 -- a change 
>> that big,  even though it's a feature removal, may require recycling 
>> at proposed  standard.
>
> Lisa,
>
> that proposal has been made *because* of the lack of process; not the 
> other way around.
>
> Locking has been optional in RFC2518, so there shouldn't be any 
> problem whatsoever having a RFC2518bis-minus-locking going to draft. 
> In fact it'll be easier because locking is the area that needs most 
> attention.
>
> That being said, what *is* your position regarding separating locking 
> into a separate document?
>
> Regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Tue Apr  6 19:22:59 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09019
	for <webdav-archive@lists.ietf.org>; Tue, 6 Apr 2004 19:22:58 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id BEAB7A0E55; Tue,  6 Apr 2004 19:22:59 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id E5510A0E55
	for <w3c-dist-auth@listhub.w3.org>; Tue,  6 Apr 2004 19:22:57 -0400 (EDT)
Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BAzuD-0006gu-Nr
	for w3c-dist-auth@w3c.org; Tue, 06 Apr 2004 19:22:57 -0400
Received: (qmail 11495 invoked by uid 65534); 6 Apr 2004 23:22:21 -0000
Received: from pD950C3AE.dip.t-dialin.net (EHLO gmx.de) (217.80.195.174)
  by mail.gmx.net (mp012) with SMTP; 07 Apr 2004 01:22:21 +0200
X-Authenticated: #1915285
Message-ID: <40733B90.8070606@gmx.de>
Date: Wed, 07 Apr 2004 01:21:52 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Jason Crawford <ccjason@us.ibm.com>, Webdav WG <w3c-dist-auth@w3c.org>
References: <4072C9C9.7050807@gmx.de> <87197BB2-87FE-11D8-970E-000A95B2BB72@osafoundation.org> <40730393.40605@gmx.de> <C73CCBAA-881D-11D8-970E-000A95B2BB72@osafoundation.org>
In-Reply-To: <C73CCBAA-881D-11D8-970E-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Status of RFC2518Bis (Was Re: Remaining issues with the bind  draft -- process)
X-Archived-At: http://www.w3.org/mid/40733B90.8070606@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8452
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040406232259.BEAB7A0E55@frink.w3.org>
Resent-Date: Tue,  6 Apr 2004 19:22:59 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Well, Lisa,

you can't both say that you don't want to separate lock *and* then say 
that RFC2518bis is so far away that any new WebDAV client spec needs to 
clean up the lock mess on it's own. If you really think that BIND can 
not work in absence of lock clarifications, then you already accept that 
*some* lock-related work needs to be done outside RFC2518bis. And 
obviously, this work needs to be entirely compatible to what RFC2518bis 
is going to say, otherwise it's worthless.

Most of the voices I hear want to keep locking, although in a separate 
spec. Geoff and I have already volunteered to write that spec. The whole 
WG process is based on people doing voluntary work; so if you prefer to 
reject that offer, I'd like to see your plan how to proceed (including 
time estimates).

Some more comments inline...

> I don't think it's a great idea to split out locking, but I don't think 
> it's a terrible idea either.  It's not necessary to remove it, so the 
> conservative answer would be to leave it.  OTOH if we were to issue a 
> "WebDAV 100% required core features" RFC and a "WebDAV locking" RFC at 
> the same time, then it's mostly a case of document convenience and 
> perceptions.

Our proposal is to have a WebDAV locking protocol at "proposed" as soon 
as possible, then to issue a RFC2518bis (without locking) at "draft", 
and soon to follow with a LOCKING draft at "draft" (when we'll have 
actual implementation experience with the changes such as If header 
evaluation and DAV:lockroot). So we want to *speed* up the process, not 
slow it down.

> The situation with locking is not that bad, as Julian pointed out 
> particularly because lock-null resources have been removed.  We could 
> simplify further if we think there are still complex or 
> rarely-implemented parts (if header parsing being the most obvious 
> candidate there, or remove shared locks).  But many (most?) clients and 
> servers *do* implement locking, and do so successfully.  There's good 
> interoperability.  It's useful.  Many clients routinely lock files while 
> they're open and being edited.

That's correct. There are use cases for servers that do not need nor 
support locking, but locking is a useful feature, and it should be left 
in the *family* of WebDAV specs, just not necessarily in the base document.

> Given the discussion so far, I fall on the side of keeping RFC 2518 
> whole.  It's not an unmanageable size.  It encourages servers to 
> implement locking if they can, which helps the clients that find locking 
> useful, and is nice for such an important feature of distributed authoring.

So how about giving as an estimate for

- answers to the issues raised against the latest rfc2518bis (-05) and
- a release of a -06 draft?

Regards,

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Wed Apr  7 04:19:53 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23178
	for <webdav-archive@lists.ietf.org>; Wed, 7 Apr 2004 04:19:53 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 06396A1776; Wed,  7 Apr 2004 04:19:52 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id C6EE7A1776
	for <w3c-dist-auth@listhub.w3.org>; Wed,  7 Apr 2004 04:19:46 -0400 (EDT)
Received: from [217.5.201.10] (helo=greenbytes.de)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BB8HP-0005ib-O3
	for w3c-dist-auth@w3c.org; Wed, 07 Apr 2004 04:19:27 -0400
Received: from [192.168.1.26] ([192.168.1.26])
	(authenticated user se@greenbytes.de)
	by greenbytes.de (greenbytes.de)
	(Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000007397.msg
	for <w3c-dist-auth@w3c.org>; Wed, 07 Apr 2004 10:18:38 +0200
In-Reply-To: <200404062058.i36KwiXe007169@post.webmailer.de>
References: <200404062058.i36KwiXe007169@post.webmailer.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <28C79960-886C-11D8-BCE0-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
Cc: w3c-dist-auth@w3c.org
From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Wed, 7 Apr 2004 10:18:32 +0200
To: edgar@edgarschwarz.de
X-Mailer: Apple Mail (2.613)
X-Authenticated-Sender: se@greenbytes.de
X-Spam-Processed: greenbytes.de, Wed, 07 Apr 2004 10:18:38 +0200
	(not processed: message from valid local sender)
X-MDRemoteIP: 192.168.1.26
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: Re (2): Status of RFC2518Bis
X-Archived-At: http://www.w3.org/mid/28C79960-886C-11D8-BCE0-00039384827E@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8453
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040407081952.06396A1776@frink.w3.org>
Resent-Date: Wed,  7 Apr 2004 04:19:52 -0400 (EDT)
Content-Transfer-Encoding: 7bit



Am 06.04.2004 um 22:58 schrieb edgar@edgarschwarz.de:
> Julian Reschke <julian.reschke@gmx.de> schrieb:
>> Locking has been optional in RFC2518, so there shouldn't be any 
>> problem
>> whatsoever having a RFC2518bis-minus-locking going to draft. In fact
>> it'll be easier because locking is the area that needs most attention.
>>
>> That being said, what *is* your position regarding separating locking
>> into a separate document?
> I wonder at the moment what we win by locking ?

Well, it's certainly a much needed feature for editing in-place. Almost 
all servers
implement it, not the least because MS-Office clients use it.

Although DeltaV has much to offer in this area, there is currently a 
lack of
deltav-aware clients for general editing purposes. So, locking in WebDAV
will keep its usefullness.

As to the difficulty of implementation: the obstacles are there for new
implementors as the specification in RFC 2518 is weak. So most issues
are discovered and fixed during interop(s). There is a general consensus
among implementors how to handle them on the server side. It's
documenting this consensus that's lacking.

> Roughly speaking it's for avoiding collaborative workers to damage 
> other peoples
> work.
> But it seems defining and implementing locks successfully is very 
> difficult.
> OTOH there is DeltaV which also is a means (Albeit more complex, but 
> servers and
> clients are coming) to avoid collaborative conflicts.
> So who needs locking ? Me definitely not.
> I would be happy to implement DeltaV and the underlying RFC2518 stuff 
> without having
> to implement locks.
> So doing a RFC2518bis-minus-locking would be fine with me.
> And whoever wants locks because he doesn't like DeltaV can work on a 
> lock spec.
> This also would help BIND, which wouldn't need to say anything about 
> locks
> anymore.
> Locking has been a pain in the ass for years. So let's get rid of it 
> in RFC2518bis !
> This really could help us to make progress because many disagreements 
> will
> disappear.
> Just my 2 cent without giving it a lot of thought.
>
> Cheers, Edgar
>
>
>
>




From w3c-dist-auth-request@w3.org  Wed Apr  7 13:19:41 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13811
	for <webdav-archive@lists.ietf.org>; Wed, 7 Apr 2004 13:19:40 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 4E8CCA0C8C; Wed,  7 Apr 2004 13:19:41 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id B0C12A0C8C
	for <w3c-dist-auth@listhub.w3.org>; Wed,  7 Apr 2004 13:19:38 -0400 (EDT)
Received: from mail-out3.apple.com ([17.254.13.22])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BBGhK-0002Ib-Pz
	for w3c-dist-auth@w3c.org; Wed, 07 Apr 2004 13:18:46 -0400
Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225])
	by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i37HIFai013107
	for <w3c-dist-auth@w3c.org>; Wed, 7 Apr 2004 10:18:15 -0700 (PDT)
Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.3.6) with ESMTP id <T68d0e26163118064e160c@mailgate1.apple.com> for <w3c-dist-auth@w3c.org>;
 Wed, 7 Apr 2004 10:18:15 -0700
Received: from [17.202.43.76] (luthji.apple.com [17.202.43.76])
	by relay1.apple.com (8.12.11/8.12.11) with ESMTP id i37HIEoH013733
	for <w3c-dist-auth@w3c.org>; Wed, 7 Apr 2004 17:18:14 GMT
Mime-Version: 1.0 (Apple Message framework v613)
In-Reply-To: <200404062058.i36KwiXe007169@post.webmailer.de>
References: <200404062058.i36KwiXe007169@post.webmailer.de>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <8D69321A-88B7-11D8-9A77-000A95DC65E0@apple.com>
Content-Transfer-Encoding: 7bit
From: Jim Luther <luther.j@apple.com>
Date: Wed, 7 Apr 2004 10:18:14 -0700
To: w3c-dist-auth@w3c.org
X-Mailer: Apple Mail (2.613)
Subject: Re: Re (2): Status of RFC2518Bis
X-Archived-At: http://www.w3.org/mid/8D69321A-88B7-11D8-9A77-000A95DC65E0@apple.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8454
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040407171941.4E8CCA0C8C@frink.w3.org>
Resent-Date: Wed,  7 Apr 2004 13:19:41 -0400 (EDT)
Content-Transfer-Encoding: 7bit



On Apr 6, 2004, at 1:58 PM, edgar@edgarschwarz.de wrote:
> Julian Reschke <julian.reschke@gmx.de> schrieb:
>> Locking has been optional in RFC2518, so there shouldn't be any 
>> problem
>> whatsoever having a RFC2518bis-minus-locking going to draft. In fact
>> it'll be easier because locking is the area that needs most attention.
>>
>> That being said, what *is* your position regarding separating locking
>> into a separate document?
> I wonder at the moment what we win by locking ?
> Roughly speaking it's for avoiding collaborative workers to damage 
> other peoples
> work.
> But it seems defining and implementing locks successfully is very 
> difficult.
> OTOH there is DeltaV which also is a means (Albeit more complex, but 
> servers and
> clients are coming) to avoid collaborative conflicts.
> So who needs locking ? Me definitely not.
> I would be happy to implement DeltaV and the underlying RFC2518 stuff 
> without having
> to implement locks.
> So doing a RFC2518bis-minus-locking would be fine with me.
> And whoever wants locks because he doesn't like DeltaV can work on a 
> lock spec.
> This also would help BIND, which wouldn't need to say anything about 
> locks
> anymore.
> Locking has been a pain in the ass for years. So let's get rid of it 
> in RFC2518bis !
> This really could help us to make progress because many disagreements 
> will
> disappear.
> Just my 2 cent without giving it a lot of thought.
>
> Cheers, Edgar

Who needs locking? Apple's Mac OS X WebDAV file system client needs it. 
Whenever a file (a non-collection resource on the WebDAV server) is 
opened with write access, the WebDAV file system obtains a lock. The 
lock is held until the file is closed. If a WebDAV server does not 
support locks (i.e., it is not class 2 compliant), the WebDAV file 
system mounts it read-only.

- Jim



From w3c-dist-auth-request@w3.org  Wed Apr  7 15:12:59 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27613
	for <webdav-archive@lists.ietf.org>; Wed, 7 Apr 2004 15:12:59 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 224A9A0D7E; Wed,  7 Apr 2004 15:13:00 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id EF65AA093C
	for <w3c-dist-auth@listhub.w3.org>; Wed,  7 Apr 2004 15:12:58 -0400 (EDT)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BBITq-0002hX-NH
	for w3c-dist-auth@w3c.org; Wed, 07 Apr 2004 15:12:58 -0400
Received: (qmail 29234 invoked by uid 65534); 7 Apr 2004 19:12:24 -0000
Received: from pD950C392.dip.t-dialin.net (EHLO gmx.de) (217.80.195.146)
  by mail.gmx.net (mp016) with SMTP; 07 Apr 2004 21:12:24 +0200
X-Authenticated: #1915285
Message-ID: <40745282.8050506@gmx.de>
Date: Wed, 07 Apr 2004 21:12:02 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jim Luther <luther.j@apple.com>
Cc: w3c-dist-auth@w3c.org
References: <200404062058.i36KwiXe007169@post.webmailer.de> <8D69321A-88B7-11D8-9A77-000A95DC65E0@apple.com>
In-Reply-To: <8D69321A-88B7-11D8-9A77-000A95DC65E0@apple.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Re (2): Status of RFC2518Bis
X-Archived-At: http://www.w3.org/mid/40745282.8050506@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8455
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040407191300.224A9A0D7E@frink.w3.org>
Resent-Date: Wed,  7 Apr 2004 15:13:00 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Jim Luther wrote:

> Who needs locking? Apple's Mac OS X WebDAV file system client needs it. 
> Whenever a file (a non-collection resource on the WebDAV server) is 
> opened with write access, the WebDAV file system obtains a lock. The 
> lock is held until the file is closed. If a WebDAV server does not 
> support locks (i.e., it is not class 2 compliant), the WebDAV file 
> system mounts it read-only.

Yes. Many applications need locking, and most servers provide it. 
However, it is optional right now, and will have to remain so.

So what's the best way to come up with an updated/upgraded locking spec, 
if we can't wait for RFC2518bis?

Discussion started back here: 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0030.html>. 
More feedback appreciated.


Regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Wed Apr  7 17:57:35 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13943
	for <webdav-archive@lists.ietf.org>; Wed, 7 Apr 2004 17:57:35 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 91899A4FF5; Wed,  7 Apr 2004 17:57:37 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 42065A4FF8
	for <w3c-dist-auth@listhub.w3.org>; Wed,  7 Apr 2004 17:57:33 -0400 (EDT)
Received: from inet-mail4.oracle.com ([148.87.2.204])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BBL36-0007UA-U2
	for w3c-dist-auth@w3c.org; Wed, 07 Apr 2004 17:57:33 -0400
Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14])
	by inet-mail4.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i37Lsmek003115;
	Wed, 7 Apr 2004 14:54:49 -0700 (PDT)
Received: from rgmgw5.us.oracle.com (localhost [127.0.0.1])
	by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id i37LulE22497;
	Wed, 7 Apr 2004 15:56:47 -0600 (MDT)
Received: from esedlarlap1 (dhcp-4op7-4op8-west-130-35-170-27.us.oracle.com [130.35.170.27])
	by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id i37LukE22480;
	Wed, 7 Apr 2004 15:56:46 -0600 (MDT)
Message-ID: <009401c41ceb$26578a20$1baa2382@us.oracle.com>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: "Julian Reschke" <julian.reschke@gmx.de>,
        "Jim Luther" <luther.j@apple.com>
Cc: <w3c-dist-auth@w3c.org>
References: <200404062058.i36KwiXe007169@post.webmailer.de> <8D69321A-88B7-11D8-9A77-000A95DC65E0@apple.com> <40745282.8050506@gmx.de>
Date: Wed, 7 Apr 2004 14:56:15 -0700
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 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Subject: Re: Re (2): Status of RFC2518Bis
X-Archived-At: http://www.w3.org/mid/009401c41ceb$26578a20$1baa2382@us.oracle.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8456
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040407215737.91899A4FF5@frink.w3.org>
Resent-Date: Wed,  7 Apr 2004 17:57:37 -0400 (EDT)
Content-Transfer-Encoding: 7bit


I guess I'd vote for Julian's option #2:

"Come up with a separate spec that updates RFC2518 and just summarizes
all that we changed or intend to change regarding locking (like
deprecation of lock-null resources, fixes to LOCK and lock refresh, If
header syntax, and lockdiscovery extensions). That would still be a
"draft standard" as RFC2518, but it would make things easier for
RFC2518bis as well, because all these changes would be written down in a
spec that came out prior to the revision, so wouldn't be "new" anymore. "

--Eric

----- Original Message ----- 
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Jim Luther" <luther.j@apple.com>
Cc: <w3c-dist-auth@w3c.org>
Sent: Wednesday, April 07, 2004 12:12 PM
Subject: Re: Re (2): Status of RFC2518Bis


>
> Jim Luther wrote:
>
> > Who needs locking? Apple's Mac OS X WebDAV file system client needs it.
> > Whenever a file (a non-collection resource on the WebDAV server) is
> > opened with write access, the WebDAV file system obtains a lock. The
> > lock is held until the file is closed. If a WebDAV server does not
> > support locks (i.e., it is not class 2 compliant), the WebDAV file
> > system mounts it read-only.
>
> Yes. Many applications need locking, and most servers provide it.
> However, it is optional right now, and will have to remain so.
>
> So what's the best way to come up with an updated/upgraded locking spec,
> if we can't wait for RFC2518bis?
>
> Discussion started back here:
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0030.html>.
> More feedback appreciated.
>
>
> Regards, Julian
>
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>



From w3c-dist-auth-request@w3.org  Wed Apr  7 17:57:41 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13961
	for <webdav-archive@lists.ietf.org>; Wed, 7 Apr 2004 17:57:40 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id C5226A4FEB; Wed,  7 Apr 2004 17:57:38 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 50F64A4FEB
	for <w3c-dist-auth@listhub.w3.org>; Wed,  7 Apr 2004 17:57:36 -0400 (EDT)
Received: from inet-mail1.oracle.com ([148.87.2.201])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BBL39-0007Un-W0
	for w3c-dist-auth@w3c.org; Wed, 07 Apr 2004 17:57:36 -0400
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13])
	by inet-mail1.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i37LvkjV008071;
	Wed, 7 Apr 2004 14:57:46 -0700 (PDT)
Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1])
	by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id i37Lusf07118;
	Wed, 7 Apr 2004 15:56:54 -0600 (MDT)
Received: from esedlarlap1 (dhcp-4op7-4op8-west-130-35-170-27.us.oracle.com [130.35.170.27])
	by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id i37Lurf07109;
	Wed, 7 Apr 2004 15:56:53 -0600 (MDT)
Message-ID: <009601c41ceb$2a883b80$1baa2382@us.oracle.com>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: "Julian Reschke" <julian.reschke@gmx.de>,
        "Jim Luther" <luther.j@apple.com>
Cc: <w3c-dist-auth@w3c.org>
References: <200404062058.i36KwiXe007169@post.webmailer.de> <8D69321A-88B7-11D8-9A77-000A95DC65E0@apple.com> <40745282.8050506@gmx.de>
Date: Wed, 7 Apr 2004 14:56:22 -0700
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 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Subject: Re: Re (2): Status of RFC2518Bis
X-Archived-At: http://www.w3.org/mid/009601c41ceb$2a883b80$1baa2382@us.oracle.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8457
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040407215738.C5226A4FEB@frink.w3.org>
Resent-Date: Wed,  7 Apr 2004 17:57:38 -0400 (EDT)
Content-Transfer-Encoding: 7bit


I guess I'd vote for Julian's option #2:

"Come up with a separate spec that updates RFC2518 and just summarizes
all that we changed or intend to change regarding locking (like
deprecation of lock-null resources, fixes to LOCK and lock refresh, If
header syntax, and lockdiscovery extensions). That would still be a
"draft standard" as RFC2518, but it would make things easier for
RFC2518bis as well, because all these changes would be written down in a
spec that came out prior to the revision, so wouldn't be "new" anymore. "

--Eric

----- Original Message ----- 
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Jim Luther" <luther.j@apple.com>
Cc: <w3c-dist-auth@w3c.org>
Sent: Wednesday, April 07, 2004 12:12 PM
Subject: Re: Re (2): Status of RFC2518Bis


>
> Jim Luther wrote:
>
> > Who needs locking? Apple's Mac OS X WebDAV file system client needs it.
> > Whenever a file (a non-collection resource on the WebDAV server) is
> > opened with write access, the WebDAV file system obtains a lock. The
> > lock is held until the file is closed. If a WebDAV server does not
> > support locks (i.e., it is not class 2 compliant), the WebDAV file
> > system mounts it read-only.
>
> Yes. Many applications need locking, and most servers provide it.
> However, it is optional right now, and will have to remain so.
>
> So what's the best way to come up with an updated/upgraded locking spec,
> if we can't wait for RFC2518bis?
>
> Discussion started back here:
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0030.html>.
> More feedback appreciated.
>
>
> Regards, Julian
>
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>



From w3c-dist-auth-request@w3.org  Wed Apr  7 18:00:36 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14056
	for <webdav-archive@lists.ietf.org>; Wed, 7 Apr 2004 18:00:36 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 44BD7A502C; Wed,  7 Apr 2004 18:00:38 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 8EC3CA502C
	for <w3c-dist-auth@listhub.w3.org>; Wed,  7 Apr 2004 18:00:36 -0400 (EDT)
Received: from agminet03.oracle.com ([141.146.126.230])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BBL64-00088J-Dd
	for w3c-dist-auth@w3c.org; Wed, 07 Apr 2004 18:00:36 -0400
Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15])
	by agminet03.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i37LupgW010642;
	Wed, 7 Apr 2004 14:57:32 -0700
Received: from rgmgw6.us.oracle.com (localhost [127.0.0.1])
	by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id i37Luop09152;
	Wed, 7 Apr 2004 15:56:50 -0600 (MDT)
Received: from esedlarlap1 (dhcp-4op7-4op8-west-130-35-170-27.us.oracle.com [130.35.170.27])
	by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with SMTP id i37Lunp09137;
	Wed, 7 Apr 2004 15:56:49 -0600 (MDT)
Message-ID: <009501c41ceb$282b38b0$1baa2382@us.oracle.com>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: "Julian Reschke" <julian.reschke@gmx.de>,
        "Jim Luther" <luther.j@apple.com>
Cc: <w3c-dist-auth@w3c.org>
References: <200404062058.i36KwiXe007169@post.webmailer.de> <8D69321A-88B7-11D8-9A77-000A95DC65E0@apple.com> <40745282.8050506@gmx.de>
Date: Wed, 7 Apr 2004 14:56:18 -0700
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 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Subject: Re: Re (2): Status of RFC2518Bis
X-Archived-At: http://www.w3.org/mid/009501c41ceb$282b38b0$1baa2382@us.oracle.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8458
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040407220038.44BD7A502C@frink.w3.org>
Resent-Date: Wed,  7 Apr 2004 18:00:38 -0400 (EDT)
Content-Transfer-Encoding: 7bit


I guess I'd vote for Julian's option #2:

"Come up with a separate spec that updates RFC2518 and just summarizes
all that we changed or intend to change regarding locking (like
deprecation of lock-null resources, fixes to LOCK and lock refresh, If
header syntax, and lockdiscovery extensions). That would still be a
"draft standard" as RFC2518, but it would make things easier for
RFC2518bis as well, because all these changes would be written down in a
spec that came out prior to the revision, so wouldn't be "new" anymore. "

--Eric

----- Original Message ----- 
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Jim Luther" <luther.j@apple.com>
Cc: <w3c-dist-auth@w3c.org>
Sent: Wednesday, April 07, 2004 12:12 PM
Subject: Re: Re (2): Status of RFC2518Bis


>
> Jim Luther wrote:
>
> > Who needs locking? Apple's Mac OS X WebDAV file system client needs it.
> > Whenever a file (a non-collection resource on the WebDAV server) is
> > opened with write access, the WebDAV file system obtains a lock. The
> > lock is held until the file is closed. If a WebDAV server does not
> > support locks (i.e., it is not class 2 compliant), the WebDAV file
> > system mounts it read-only.
>
> Yes. Many applications need locking, and most servers provide it.
> However, it is optional right now, and will have to remain so.
>
> So what's the best way to come up with an updated/upgraded locking spec,
> if we can't wait for RFC2518bis?
>
> Discussion started back here:
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0030.html>.
> More feedback appreciated.
>
>
> Regards, Julian
>
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>



From w3c-dist-auth-request@w3.org  Fri Apr  9 06:12:49 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20690
	for <webdav-archive@lists.ietf.org>; Fri, 9 Apr 2004 06:12:47 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id EDD2CA11D8; Fri,  9 Apr 2004 05:26:15 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id C9161A1BA5
	for <w3c-dist-auth@listhub.w3.org>; Fri,  9 Apr 2004 05:26:14 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BBsH8-0007aH-H4
	for w3c-dist-auth@w3c.org; Fri, 09 Apr 2004 05:26:14 -0400
Received: (qmail 13540 invoked by uid 65534); 9 Apr 2004 09:25:40 -0000
Received: from pD950C25C.dip.t-dialin.net (EHLO gmx.de) (217.80.194.92)
  by mail.gmx.net (mp001) with SMTP; 09 Apr 2004 11:25:40 +0200
X-Authenticated: #1915285
Message-ID: <40766BFD.7000404@gmx.de>
Date: Fri, 09 Apr 2004 11:25:17 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3c.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: summary of BIND/RFC2518 status
X-Archived-At: http://www.w3.org/mid/40766BFD.7000404@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8459
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040409092615.EDD2CA11D8@frink.w3.org>
Resent-Date: Fri,  9 Apr 2004 05:26:15 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi,

in this mail, I'll try to clarify both the current state of things and 
what Geoff and I are actually proposing.

Let's start with some facts that we hopefully all agree on.


1) Multiple URIs mapping to the same resource are not introduced by the 
BIND spec. They've been a fact of live for HTTP per se, are explicily 
mentioned in RFC2518, and can be created as side effect in some RFC3253 
operations. The BIND spec doesn't introduce bindings as new feature; it 
only clarifies some namespace operations, adds authoring methods for 
*explicitly* creating new bindings; adds discovery mechanisms and error 
marshalling.

2) Locking is a useful, but *optional* feature of RFC2518. Many clients 
require locking to be able to author a resource, for instance MS Office. 
However, there are valid server implementation scenarios where locks 
won't be available, and clients will have to cope with that as well. In 
many cases, strong ETags are more useful than locking. Ideally a server 
provides both.

3) RFC3253, RFC3648 and ACL (RFC to be published soon) work both with 
and without locking. In particular, they don't specify any specific lock 
behaviours; the just rely on the base document RFC2518.

4) The locking definitions in RFC2518 need to be updated; most if not 
all issues are on the RFC2518 issues list 
(<http://www.webdav.org/wg/rfcdev/issues.htm>). This includes extensions 
(DAV:lockroot, If header syntax), clarifications (LOCK operation 
returning Lock-Token header, DAV:owner content...), simplifications (get 
rid of special lock-null resources, simplify lock refresh). It also 
should include an updated general description of write lock behaviour, 
which should be identical to what we wrote down in GULP 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0001.html>).


Given this base, I personally conclude:

A) We should avoid a situation where optional specs need to specifically 
define interaction with other optional features. Rather than that, that 
interaction should follow from the definition in the base spec. If the 
base locking model is clear about where state resides, and what a lock 
protects, the additional semantics for new features (such as versioning, 
or ACL) will follow automatically.

A1) Example: the ACL spec that the IETF just accepted does not state 
that if a resource is locked, you'll need to provide the lock token in 
the request to modify the ACL. It doesn't need to, because the spec 
states that the ACL belongs to the state of the resource. Similar 
considerations apply to versioning and ordering methods.

B) WebDAV's locking definitions needs to be fixed and updated. 
Optimally, this would be done in RFC2518bis; but for reasons that I 
currently don't understand this spec doesn't seem to progress at all.

C) A big part of what changes in RFC2518bis relates to locking. On the 
other hand, locking is the area where we have/had the most 
interoperability problems. If we can't get RFC2518bis finished in the 
near future, it makes sense to extract all this information into a 
separate document (starting at standards level "proposed").

D) This separate document shouldn't be an appendix to BIND, because it's 
relevant to all WebDAV specs, not only BIND. In particular, people not 
interested in BIND may not even be aware of this appendix. For the same 
reason, we should now last-call BIND. This is the best way to find out 
about other possible issues unrelated to the locking question.

E) If we decide to clarify/update outside the RFC2518bis spec, we need 
support for that activity from the WG in general and the RFC2518bis 
authors in particular. A "fork" in the locking spec is a no-no. Whatever 
the new document says *must* be repeated (modulo fixes) in RFC2518bis, 
unless...

F) ...we publish a standalone document that fully specifies WebDAV 
locking and updates RFC2518 (in which case, locking can simply be 
removed from RFC2518bis). This is what Geoff and I are both proposing 
*and* volunteering to do.

G) It was said that this very discussion is the reason for the slow 
progress of RFC2518bis. In fact, this discussion has started *because* 
of the slow progress. Removing the optional locking feature from 
RFC2518bis will make that spec more manageable and will cause it to 
contain much less *changes* from RFC2518, probably making the transition 
to "Draft" much easier.

Ted, Patrik: I'll assume that removing an optional feature from a spec 
when going from "Draft" to "Proposed" is absolutely ok. If I'm wrong 
here, please clarify.



Feedback appreciated,

Julian



-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Sun Apr 11 10:28:09 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25350
	for <webdav-archive@lists.ietf.org>; Sun, 11 Apr 2004 10:28:07 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 91702A1EC7; Sun, 11 Apr 2004 09:41:40 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 2D3D9A1EC7
	for <w3c-dist-auth@listhub.w3.org>; Sun, 11 Apr 2004 09:41:38 -0400 (EDT)
Received: from a17-250-248-87.apple.com ([17.250.248.87] helo=smtpout.mac.com)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BCfDN-000473-Sq
	for w3c-dist-auth@w3c.org; Sun, 11 Apr 2004 09:41:37 -0400
Received: from mac.com (smtpin07-en2 [10.13.10.152])
	by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i3BDfa1N008823
	for <w3c-dist-auth@w3c.org>; Sun, 11 Apr 2004 06:41:36 -0700 (PDT)
Received: from [192.168.1.101] (h81.242.40.162.ip.alltel.net [162.40.242.81])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 3.0) with ESMTP id i3BDfWIS010550
	for <w3c-dist-auth@w3c.org>; Sun, 11 Apr 2004 06:41:35 -0700 (PDT)
Mime-Version: 1.0
X-Sender: frank.lowney@mail.mac.com
Message-Id: <p06100501bc9eeb197a59@[192.168.1.101]>
In-Reply-To: <200404062058.i36KwiXe007169@post.webmailer.de>
References: <200404062058.i36KwiXe007169@post.webmailer.de>
Date: Sun, 11 Apr 2004 09:41:31 -0400
To: w3c-dist-auth@w3c.org
From: Frank Lowney <frank.lowney@mac.com>
Content-Type: text/plain; charset="us-ascii"
Subject: End User Info on WebDAV
X-Archived-At: http://www.w3.org/mid/p06100501bc9eeb197a59@%5B192.168.1.101%5D
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8460
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040411134140.91702A1EC7@frink.w3.org>
Resent-Date: Sun, 11 Apr 2004 09:41:40 -0400 (EDT)


Is anyone maintaining a list of WebDAV options and 'how-to' recipes from the end user perspective?  The closest thing that I can find is:

http://www.webdav.org/projects/

...where may of the links (e.g. Dreamweaver, Photoshop, Acrobat, etc.) now go to pages where WebDAV is not mentioned at all.

What I want to be able to point my audiences toward is a page that lists all or many of the things that they can do with WebDAV using applications that are likely available to them.  The items on this list should then link to pages that illustrate how one would use WebDAV with that specific application to create and maintain content.  Descriptions of how WebDAV can fit into and facilitate a work flow would also be useful.

The underlying concept is that if I want to attract content developers to the use of WebDAV, I need to be able to convince them that an investment in learning about WebDAV is likely to pay off in many areas and in many ways.

Or should I approach this as if all or most of the content creators in my audience are using either MacOS X or WinXP such that they will use these apps as if working on local files?  That is, create and save a shortcut or alias file in a convenient place. But do the current iterations of these apps really accommodate that perspective?  
-- 
=====================================================================
Dr. Frank Lowney  frank.lowney@gcsu.edu
    Director, Electronic Instructional Services, a unit of the
    Office of Information and Instructional Technology, 
    Professional Pages: http://www.gcsu.edu/oiit/eis/
    Personal Pages: http://www.faculty.de.gcsu.edu/~flowney
Voice: (478) 445-5260
=====================================================================
We don't make instruction effective, we make effective instruction more accessible.

Please note that my new e-mail address is: frank.lowney@gcsu.edu



From w3c-dist-auth-request@w3.org  Mon Apr 12 19:44:23 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25607
	for <webdav-archive@lists.ietf.org>; Mon, 12 Apr 2004 19:44:20 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 6D32AA1FFC; Mon, 12 Apr 2004 19:44:17 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id DA110A1FFC
	for <w3c-dist-auth@listhub.w3.org>; Mon, 12 Apr 2004 19:44:15 -0400 (EDT)
Received: from agminet04.oracle.com ([141.146.126.231])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BDB64-0006vB-62
	for w3c-dist-auth@w3c.org; Mon, 12 Apr 2004 19:44:12 -0400
Received: from agminet04.oracle.com (localhost [127.0.0.1])
	by agminet04.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i3CNhdPD001637
	for <w3c-dist-auth@w3c.org>; Mon, 12 Apr 2004 16:43:39 -0700
Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.191.12])
	by agminet04.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i3CNhcPD001629
	for <w3c-dist-auth@w3c.org>; Mon, 12 Apr 2004 16:43:38 -0700
Received: from rgmgw3.us.oracle.com (localhost [127.0.0.1])
	by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i3CNhc67028821
	for <w3c-dist-auth@w3c.org>; Mon, 12 Apr 2004 17:43:38 -0600
Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197])
	by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id i3CNhc1h028817
	for <w3c-dist-auth@w3c.org>; Mon, 12 Apr 2004 17:43:38 -0600
Message-ID: <066b01c420e7$db593f90$c5b42382@us.oracle.com>
From: "Stanley Guan" <stanley.guan@oracle.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
References: <4072C9C9.7050807@gmx.de> <87197BB2-87FE-11D8-970E-000A95B2BB72@osafoundation.org> <40730393.40605@gmx.de>
Date: Mon, 12 Apr 2004 16:42:45 -0700
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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: set a property with an empty content
X-Archived-At: http://www.w3.org/mid/066b01c420e7$db593f90$c5b42382@us.oracle.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8461
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040412234417.6D32AA1FFC@frink.w3.org>
Resent-Date: Mon, 12 Apr 2004 19:44:17 -0400 (EDT)
Content-Transfer-Encoding: 7bit


If a property is set with an empty content as shown below,
is it allowed?  If yes, is it equivalent to "remove"?

Thx,

-Stanley


<?xml version="1.0" encoding="UTF-8"?> 
<D:propertyupdate xmlns:D="DAV:"> 
    <D:set> 
        <D:prop xml:lang="en">
            <D:PropertyA/> 
        </D:prop> 
    </D:set> 
</D:propertyupdate> 




From w3c-dist-auth-request@w3.org  Mon Apr 12 21:49:08 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00927
	for <webdav-archive@lists.ietf.org>; Mon, 12 Apr 2004 21:49:05 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id EA357A2A6E; Mon, 12 Apr 2004 21:49:03 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id E8F2FA2A73
	for <w3c-dist-auth@listhub.w3.org>; Mon, 12 Apr 2004 21:48:57 -0400 (EDT)
Received: from grunt22.ihug.com.au ([203.109.249.142])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BDD2n-0004xU-J8
	for w3c-dist-auth@w3c.org; Mon, 12 Apr 2004 21:48:57 -0400
Received: from p52-max3.adl.ihug.com.au ([192.168.0.2]) [203.173.185.52] 
	by grunt22.ihug.com.au with esmtp (Exim 3.35 #1 (Debian))
	id 1BDD2d-0007Jf-00; Tue, 13 Apr 2004 11:48:49 +1000
In-Reply-To: <066b01c420e7$db593f90$c5b42382@us.oracle.com>
References: <4072C9C9.7050807@gmx.de> <87197BB2-87FE-11D8-970E-000A95B2BB72@osafoundation.org> <40730393.40605@gmx.de> <066b01c420e7$db593f90$c5b42382@us.oracle.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <B52123F2-8CEC-11D8-9CBF-000393CE9EEE@ihug.com.au>
Content-Transfer-Encoding: 7bit
Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
From: Antony Blakey <antony.blakey@ihug.com.au>
Date: Tue, 13 Apr 2004 11:18:48 +0930
To: "Stanley Guan" <stanley.guan@oracle.com>
X-Mailer: Apple Mail (2.613)
Subject: Re: set a property with an empty content
X-Archived-At: http://www.w3.org/mid/B52123F2-8CEC-11D8-9CBF-000393CE9EEE@ihug.com.au
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8462
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040413014903.EA357A2A6E@frink.w3.org>
Resent-Date: Mon, 12 Apr 2004 21:49:03 -0400 (EDT)
Content-Transfer-Encoding: 7bit



On 13/04/2004, at 9:12 AM, Stanley Guan wrote:

> If a property is set with an empty content as shown below,
> is it allowed?

Yes. Although if that's your property, best not to use the DAV: 
namespace.

> If yes, is it equivalent to "remove"?

No. The property will be returned as you have set it i.e. an empty XML 
element, which is different from the property not existing.

Antony Blakey
-------------
He who would make his own liberty secure, must guard even his enemy 
from repression.
   -- Thomas Paine



From w3c-dist-auth-request@w3.org  Tue Apr 13 03:48:30 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26730
	for <webdav-archive@lists.ietf.org>; Tue, 13 Apr 2004 03:48:28 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A56DBA1B10; Tue, 13 Apr 2004 03:48:25 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 1F4A9A1BD2
	for <w3c-dist-auth@listhub.w3.org>; Tue, 13 Apr 2004 03:48:24 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BDIeI-0008Sc-U5
	for w3c-dist-auth@w3c.org; Tue, 13 Apr 2004 03:48:03 -0400
Received: (qmail 15770 invoked by uid 65534); 13 Apr 2004 07:47:30 -0000
Received: from pD950C27C.dip.t-dialin.net (EHLO gmx.de) (217.80.194.124)
  by mail.gmx.net (mp007) with SMTP; 13 Apr 2004 09:47:30 +0200
X-Authenticated: #1915285
Message-ID: <407B9B0E.7080305@gmx.de>
Date: Tue, 13 Apr 2004 09:47:26 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Antony Blakey <antony.blakey@ihug.com.au>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
References: <4072C9C9.7050807@gmx.de> <87197BB2-87FE-11D8-970E-000A95B2BB72@osafoundation.org> <40730393.40605@gmx.de> <066b01c420e7$db593f90$c5b42382@us.oracle.com> <B52123F2-8CEC-11D8-9CBF-000393CE9EEE@ihug.com.au>
In-Reply-To: <B52123F2-8CEC-11D8-9CBF-000393CE9EEE@ihug.com.au>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: set a property with an empty content
X-Archived-At: http://www.w3.org/mid/407B9B0E.7080305@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8463
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040413074825.A56DBA1B10@frink.w3.org>
Resent-Date: Tue, 13 Apr 2004 03:48:25 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Antony Blakey wrote:
> 
> 
> On 13/04/2004, at 9:12 AM, Stanley Guan wrote:
> 
>> If a property is set with an empty content as shown below,
>> is it allowed?
> 
> 
> Yes. Although if that's your property, best not to use the DAV: namespace.
> 
>> If yes, is it equivalent to "remove"?
> 
> 
> No. The property will be returned as you have set it i.e. an empty XML 
> element, which is different from the property not existing.

Antony is right on both counts.

Furthermore it would be nice not to start new threads by replying to 
mails from toher threads, this messes up the threaded display both in 
email clients and the web archive...

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Tue Apr 13 07:32:34 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06351
	for <webdav-archive@lists.ietf.org>; Tue, 13 Apr 2004 07:32:31 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A6009A0614; Tue, 13 Apr 2004 07:32:27 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 24B19A0614
	for <w3c-dist-auth@listhub.w3.org>; Tue, 13 Apr 2004 07:32:25 -0400 (EDT)
Received: from e5.ny.us.ibm.com ([32.97.182.105])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BDM9D-0003DH-IX
	for w3c-dist-auth@w3.org; Tue, 13 Apr 2004 07:32:11 -0400
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3DBVb67231862
	for <w3c-dist-auth@w3.org>; Tue, 13 Apr 2004 07:31:37 -0400
Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3DBW0Nm112668
	for <w3c-dist-auth@w3.org>; Tue, 13 Apr 2004 07:32:01 -0400
In-Reply-To: <D82C355E-8D25-11D8-8095-00039384827E@greenbytes.de>
To: " webdav" <w3c-dist-auth@w3.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF26D9C6AC.33EF3473-ON85256E75.003F00F3-85256E75.003F50C7@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Tue, 13 Apr 2004 07:31:33 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF291 | April 6, 2004) at
 04/13/2004 07:31:36,
	Serialize complete at 04/13/2004 07:31:36
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: [ACL] DAV:unauthenticated usage
X-Archived-At: http://www.w3.org/mid/OF26D9C6AC.33EF3473-ON85256E75.003F00F3-85256E75.003F50C7@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8464
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040413113227.A6009A0614@frink.w3.org>
Resent-Date: Tue, 13 Apr 2004 07:32:27 -0400 (EDT)


Our experience is that
Getting consensus on each new addition of this kind is very difficult,
because everyone does this kind of thing very differently.
So I'd want to save these kind of enhancements until
after we have more practical experience with the features we
were able to get consensus on.

Cheers,
Geoff

Stefan wrote on 04/13/2004 04:37:48 AM:

> 
> Am 09.04.2004 um 22:57 schrieb Eric Sedlar:
> 
> > Well, not to be a pain in the butt, but actually now that our 
> > implementation
> > teams have been looking seriously at the spec, we have a couple 
> > additional
> > issues:
> >
> > * shared ACLs:  the current spec specifies that the <acl> property 
> > from the
> > resources listed in <inherited-acl-set> is to be used.  The problem 
> > with
> > this is when you want a different acl to be propagated to the 
> > inheritees
> > than you want on the parent resource.  This could be solved by 
> > defining an
> > <acl-data> property, which had the same structure as <acl>, but 
doesn't
> > define access control for the parent resource.  Another issue in this
> > scenario is that <inherited-acl-set> needs to be PROPPATCH'able.  A 
> > number
> > of our WebDAV servers at Oracle only support ACLs by reference from 
the
> > resource rather than one copied to each resource, so this is a 
problem.
> 
> There is nothing in the spec which says that DAV:inherited-acl-set 
> cannot be
> PROPPATCHed.
> 
> As to special inheritance with <acl-data>: The spec does not define how
> acl inheritance is done by the server (e.g. if acls default to parent 
> resource
> or something else). Your server could implement inheritance by some
> <oracle:acl-data> and still be compliant with the spec.
> 
> 
> > * usability:  One of the major use cases for WebDAV ACL is an 
> > interoperable
> > client setting access permissions on objects on any compliant servers 
> > (e.g.
> > via a GUI).  One complaint I've received is that creating ACLs is too
> > complicated.  This is why Windows provides for a small set of 
> > pre-defined
> > useful ACLs, and I think most servers will want to do the same.
> > Potentially, the set of pre-defined ACLs could vary per resource.  It 
> > would
> > be useful to have an additional live property with a URL of a 
> > collection of
> > resources (or else to list the set of URLs in that property) with
> > pre-configured ACLs (e.g. "Public Read/Owner Write", "Private",
> > "Classified", "Oracle Database Development Group Shared Docs", etc.). 
> > These
> > ACLs could then be copied by value into the ACL of that resource, or
> > referenced by using inherited-acl-set for truly shared access control
> > policies.
> 
> As I understood your description this seems to be outside the scope of
> the current spec. Offering default ACL-building blocks for the UI is 
> good
> for user experience, but I would not put it into the basic ACL spec.
> 
> I can think of tons of things which we could invent and improve on 
> regarding
> ACL management and UI experience, but let's leave the spec at its 
> current
> scope and collect implementation experience before defining more
> standardized elements and behaviour.
> 
> //Stefan
> 
> >
> > --Eric
> >
> >> -----Original Message-----
> >> From: acl-bounces@webdav.org [mailto:acl-bounces@webdav.org] On 
> >> Behalf Of
> >> Julian Reschke
> >> Sent: Thursday, April 08, 2004 2:08 PM
> >> To: acl@webdav.org
> >> Subject: Re: [ACL] DAV:unauthenticated usage
> >>
> >> Geoff & Eric,
> >>
> >> thans for answering the questions.
> >>
> >> We still haven't reached the AUTH48 period for the RFC, so if there 
> >> are
> >> REALLY REALLY minor edits we should do on the spec, let me know.
> >>
> >> On the other hand, if there's a major problem we can't fix right now,
> >> let's at least identify it so we can put it on a future RFCxxxx-bis
> >> issues list.
> >>
> >> Regards, Julian
> >>
> >> --
> >> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >> _______________________________________________
> >> acl mailing list
> >> acl@webdav.org
> >> http://mailman.webdav.org/mailman/listinfo/acl
> >
> > _______________________________________________
> > acl mailing list
> > acl@webdav.org
> > http://mailman.webdav.org/mailman/listinfo/acl
> 
> 
> _______________________________________________
> acl mailing list
> acl@webdav.org
> http://mailman.webdav.org/mailman/listinfo/acl



From w3c-dist-auth-request@w3.org  Tue Apr 13 14:53:42 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27285
	for <webdav-archive@lists.ietf.org>; Tue, 13 Apr 2004 14:53:41 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 359C7A1D1B; Tue, 13 Apr 2004 14:53:29 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id CC5AFA2C4D
	for <w3c-dist-auth@listhub.w3.org>; Tue, 13 Apr 2004 14:53:27 -0400 (EDT)
Received: from mtaw6.prodigy.net ([64.164.98.56])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BDT2F-00018L-Iz
	for w3c-dist-auth@w3c.org; Tue, 13 Apr 2004 14:53:27 -0400
Received: from cse.ucsc.edu (adsl-63-194-88-161.dsl.snfc21.pacbell.net [63.194.88.161])
	by mtaw6.prodigy.net (8.12.10/8.12.10) with ESMTP id i3DIq9jG013190
	for <w3c-dist-auth@w3c.org>; Tue, 13 Apr 2004 11:52:13 -0700 (PDT)
Message-ID: <407C371B.20800@cse.ucsc.edu>
Date: Tue, 13 Apr 2004 11:53:15 -0700
From: Elias Sinderson <elias@cse.ucsc.edu>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Webdav WG <w3c-dist-auth@w3c.org>
References: <OF434B86AC.A557239B-ON85256E6E.0005F963-85256E6E.00104001@us.ibm.com>
In-Reply-To: <OF434B86AC.A557239B-ON85256E6E.0005F963-85256E6E.00104001@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Remaining issues with the bind draft -- process
X-Archived-At: http://www.w3.org/mid/407C371B.20800@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8465
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040413185329.359C7A1D1B@frink.w3.org>
Resent-Date: Tue, 13 Apr 2004 14:53:29 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Geoffrey M Clemm wrote:

>I strongly support choice #3 (issuing a locking draft).
>If we are considering defining locking behavior in a 
>separate draft that isn't about locking (i.e. the bind draft),
>then I think doing so in a separate draft makes the most sense.
>  
>
Apologies for jumping into this thread late, I've been traveling on 
business and unable to keep up with the discussion. Anyway, I'd like to 
offer my (non-binding) +1 on issuing GULP as a seperate draft - this 
approach seems to be the most reasonable way to proceed at this juncture.

Elias

>Especially if Julian has done most of the editorial work
>(thanks, Julian!), we should be able to focus on it after
>the binding draft is finalized, and get it out soon afterwards
>(once it is decoupled from the many unresolved issues in
>the rest of 2518bis).
>
>Cheers,
>Geoff
>
>Julian wrote on 04/05/2004 06:13:27 PM:
>
>  
>
>>Ted Hardie wrote:
>>
>>    
>>
>>>Speaking personally, my concern here would be that if those 
>>>clarifications were not
>>>present, BIND behavior became non-deterministic.  If 2518bis was done, 
>>>      
>>>
>and
>  
>
>>>BIND pointed to it to solve that hypothetical problem, all might be 
>>>goodness; if
>>>it will not be done, on the other hand, getting the job done in the 
>>>      
>>>
>spec 
>  
>
>>>which
>>>will be completed might be the practical way to go.
>>>
>>>Again, my personal two cents,
>>>            regards,
>>>                Ted
>>>      
>>>
>>If we rephrase that as "There should be a standards-track document 
>>clarifying WebDAV looking as soon as possible.", I'll absolutely agree. 
>>However, I think that document shouldn't be BIND, if only for the simple 
>>    
>>
>
>  
>
>>reason that it matters to those who don't plan to implement BIND at all 
>>as well.
>>
>>If we can't get RFC2518bis finished soon, I think the approaches (2) and 
>>    
>>
>
>  
>
>>(3) presented in 
>><http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0030.html> 
>>    
>>
>
>  
>
>>would make more sense:
>>
>>--
>>2) Come up with a separate spec that updates RFC2518 and just summarizes
>>all that we changed or intend to change regarding locking (like
>>deprecation of lock-null resources, fixes to LOCK and lock refresh, If
>>header syntax, and lockdiscovery extensions). That would still be a
>>"draft standard" as RFC2518, but it would make things easier for
>>RFC2518bis as well, because all these changes would be written down in a
>>spec that came out prior to the revision, so wouldn't be "new" anymore.
>>It would also encourage implementors to actually *implement* these
>>changes and extensions *before* RFC2518bis comes out.
>>
>>3) A drastic approach would be to de-couple locking entirely from
>>RFC2518 ("updating" RFC2518 again). That would look similar to how
>>RFC3253 is organized (locking would become an optional module, and
>>everything that needs to be said about locking would reside in that
>>separate document). Of course that approach would have a significant
>>impact on RFC2518bis, because optimally, it wouldn't say anything about
>>locking anymore either.
>>--
>>
>>I'm willing to help working on either; we just need working group 
>>consensus to do this as it would affect the (currently dormant?) 
>>activities on RFC2518bis.
>>
>>As an experiment, I've already extracted locking from RFC2518. This 
>>turned out to be relatively simple *except* for the locking semantics 
>>built into the "If" header checks (which will require some more 
>>thinking). BTW: RFC2518 shrinks by about 30% (interested parties just 
>>email me for a copy).
>>
>>Regards, Julian
>>
>>-- 
>><green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>>
>>    
>>



From w3c-dist-auth-request@w3.org  Sun Apr 18 13:21:12 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01553
	for <webdav-archive@lists.ietf.org>; Sun, 18 Apr 2004 13:21:11 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 03D2DA086C; Sun, 18 Apr 2004 13:21:13 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id AAF96A0DB9
	for <w3c-dist-auth@listhub.w3.org>; Sun, 18 Apr 2004 13:21:11 -0400 (EDT)
Received: from cats-mx1.ucsc.edu ([128.114.129.36] helo=ucsc.edu)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BFFyh-0008Py-CT
	for w3c-dist-auth@w3.org; Sun, 18 Apr 2004 13:21:11 -0400
Received: from dhcp-60-141.cse.ucsc.edu (dhcp-60-141.cse.ucsc.edu [128.114.60.141])
	by ucsc.edu (8.10.1/8.10.1) with ESMTP id i3IHJNC03871
	for <w3c-dist-auth@w3.org>; Sun, 18 Apr 2004 10:19:23 -0700 (PDT)
To: "WebDAV" <w3c-dist-auth@w3.org>
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
Reply-To: "Jim Whitehead" <ejw@cse.ucsc.edu>
Organization: UC Santa Cruz
X-Priority: 3 (normal)
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
X-Mailer: Bloomba 1.0.5
Mime-Version: 1.0
Message-Id: <20040418101805.2009699665.ejw@cse.ucsc.edu>
Date: Sun, 18 Apr 2004 10:18:05 -0700
X-UCSC-CATS-MailScanner: Found to be clean
Subject: HELP: only -ONE- client LOCK/UNLOCK's my WebDAV served files, -ALL- others issue GET
X-Archived-At: http://www.w3.org/mid/20040418101805.2009699665.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8466
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040418172113.03D2DA086C@frink.w3.org>
Resent-Date: Sun, 18 Apr 2004 13:21:13 -0400 (EDT)
Content-Transfer-Encoding: quoted-printable


Accidentally caught by the spam filter.

- Jim

> ------------Original Message------------
> From: "AMC newsgroups" <d.debas@amc.uva.nl>
> To: w3c-dist-auth@w3.org
> Date: Thu, Apr-15-2004 7:33 AM
> Subject: [Moderator Action] HELP: only -ONE- client LOCK/UNLOCK's my WebD=
AV served files, -ALL- others issue GET
> =

> =

> =

> =

> Left without any clue and completely stumped, I would appreciate any
> comments to set me off in the right direction.
> =

> I'm setting up a departemental server running Windows 2000 Server,
> configured with IIS 5.0 for serving an intranetsite with WebDAV enabled
> by default.
> The server is a domain member of subdomain CLASS, and also functions as
> a backup Domain Controller for this Active Directory domain.
> =

> Connected to this subdomain are a couple of clients, most of them:
> - configured with Win2K Pro/SP2 -or- SP4, and IE 5.5 SP2,
> - some with WinXP Pro/SP1 and IE 6 SP1,
> =

> All desktops have Office 2000 installed, updated with SR-1a & SP-3.
> =

> Users logon to the CLASS domain, so that their permissions can be set
> domain-wide. After testing, I plan to change IIS authentication to IWA
> (Integrated Windows Authentication) and configure IE 5.5 accordingly for
> transparant authentication.
> =

> ALL clients support adding WebFolders in "My Network Places" on the deskt=
op.
> Doubleclicking the WebFolder opens up a window, showing Office documents.
> Doubleclicking documents fires up Excel, Word, etc. and opens up the
> document Read-Write for update, as long as not already reviewed by someon=
e
> else. This indicates that basic WebDAV functionality is in place.
> =

> The intranetsite uses Anonymous Authentication against the IUSR_computern=
ame
> account. The WebDAV folder serving the Office documents on the IIS 5.0
> server, is actually a virtual folder with Basic Authentication enabled
> for testing purposes. Because this folder has Read/Write/DirectoryBrowsin=
g
> enabled, users can also browse with IE to the documentfolder and fireup
> the Office application by doubleclicking a document of their choice.
> =

> And here the magic happens: ALL clients fireup Excel, Word, etc. with
> the clicked document opened READ-ONLY.
> But heh, all but ONE: one client opens up the document Read-Write, and
> there-
> fore allows saving it directly on the server.
> =

> As I don't have ANY clue to why documents are opened Read-Write on that
> particular machine, I checked versions of any installed software. Operati=
ng
> System, Internet Explorer, MS Office, DLL's, etc. Without a clue.
> =

> Configuration client opening Read-Write
> ---------------------------------------
> OS: Win2K Pro / SP2 ( build 5.00.2195)
> browser: Internet Explorer 5.5 SP2 v.5.50.4807.2300 (patched with Q824145=
,
> Q330994)
> Word 2000: v9.0.2720 (no SR-1a or SP-3 applied)
> Excel 2000: v9.0.2720 (no SR-1a or SP-3 applied)
> msdaipp.dll: v10.145.3812.0
> =

> Configuration clients opening Read-Only
> ---------------------------------------
> OS: Win2K Pro / SP2-or-SP4 ( build 5.00.2195)
> browser: Internet Explorer 5.5 SP2 v.5.50.4807.2300 (patched with Q824145=
,
> Q330994)
> Word 2000: v9.0.6926 SP-3
> Excel 2000: v9.0.6926 SP-3
> msdaipp.dll: v10.145.3812.0
> =

> =

> =

> =

> Contents of WebDAV folder as seen in browser:
> ---------------------------------------------
> =

> 192.168.1.39 - /publicfiles/office/
> =

> [To Parent Directory]
> =

>      Thursday, April 15, 2004  1:30 PM        <dir> archive
>   Thursday, December 05, 2002  6:34 PM       133632 Basic_Math.pps
>      Thursday, April 15, 2004  9:06 AM       142336 Budget_Forecast-bldg.=
xls
>     Wednesday, April 14, 2004  8:02 AM        19968 Current_Repairs.xls
>      Thursday, April 15, 2004  8:36 AM       142336 Dereks_spreadsheet.xl=
s
>       Tuesday, April 13, 2004  7:03 PM       142336
> Dominiques_spreadsheet.xls
>        Tuesday, July 30, 2002 10:52 AM       145408
> Financial_Projection-it.xls
>      Monday, October 07, 2002  6:04 PM       102400 Housing_Database.mdb
>        Friday, April 09, 2004  6:07 PM        45056
> Planning_Installation.xls
>      Wednesday, June 21, 2000  1:09 PM      1303040 SETI_at_home.ppt
>    Monday, September 30, 2002  2:25 PM      1191609 Standard_Definitions.=
rtf
> =

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
> =3D=3D=3D=3D
> =

> =

> =

> =

> Results of HTTP OPTIONS query on the IIS 5.0 server:
> ----------------------------------------------------
> HTTP/1.1 200 OK
> Server: Microsoft-IIS/5.0
> Date: Thu, 15 Apr 2004 11:22:48 GMT
> MS-Author-Via: DAV
> Content-Length: 0
> Accept-Ranges: none
> DASL: <DAV:sql>
> DAV: 1, 2
> Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL,
> PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH
> Allow: OPTIONS, TRACE, GET, HEAD, COPY, PROPFIND, SEARCH, LOCK, UNLOCK
> Cache-Control: private
> =

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
> =3D=3D=3D=3D
> =

> =

> =

> =

> HTTP-header dump of the one client opening documents Read-Write:
> ---------------------------------------------------------------
> =

> 1.  TYPING URL IN BROWSER:
> =

> GET /publicfiles/office/ HTTP/1.0
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/msword,
> application/vnd.ms-excel, application/vnd.ms-powerpoint,
> application/x-shockwave-flash,
> */*
> Accept-Language: en-us
> User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR
> 1.1.4322)
> Host: 192.168.1.39
> Connection: Keep-Alive
> Cookie: FileView=3DReverse=3D0&SortBy=3D0
> HTTP/1.1 401 Access Denied
> Server: Microsoft-IIS/5.0
> Date: Thu, 15 Apr 2004 12:11:39 GMT
> WWW-Authenticate: Negotiate
> WWW-Authenticate: NTLM
> Content-Length: 4431
> Content-Type: text/html
> =

> GET /publicfiles/office/ HTTP/1.0
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/msword, application/vnd.ms-excel, application/vnd.ms-powerpoi=
nt,
> application/x-shockwave-flash, */*
> Accept-Language: en-us
> User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR
> 1.1.4322)
> Host: 192.168.1.39
> Connection: Keep-Alive
> Cookie: FileView=3DReverse=3D0&SortBy=3D0
> Authorization: Negotiate TlRMTVNTUAABAAAAB4IAoAAAAAAAAAAAAAAAAAAAAAA=3D
> HTTP/1.1 401 Access Denied
> Server: Microsoft-IIS/5.0
> Date: Thu, 15 Apr 2004 12:11:39 GMT
> WWW-Authenticate: Negotiate
> TlRMTVNTUAACAAAABgAGADAAAAAFgoGgBfSF7+u2P/MAAAAAAAAAAHwAfAA2AAAAQQBMAEMAA=
gAG
> AEEATABDAAEAFABSAEUARABTAE4AQQBQAFAARQBSAAQAHABhAGwAYwAuAGEAbQBjAC4AdQB2A=
GEA
> LgBuAGwAAwAyAHIAZQBkAHMAbgBhAHAAcABlAHIALgBhAGwAYwAuAGEAbQBjAC4AdQB2AGEAL=
gBu
> AGwAAAAAAA=3D=3D
> Connection: keep-alive
> Content-Length: 4033
> Content-Type: text/html
> =

> GET /publicfiles/office/ HTTP/1.0
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/msword, application/vnd.ms-excel, application/vnd.ms-powerpoi=
nt,
> application/x-shockwave-flash, */*
> Accept-Language: en-us
> User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR
> 1.1.4322)
> Host: 192.168.1.39
> Connection: Keep-Alive
> Authorization: Negotiate
> TlRMTVNTUAADAAAAGAAYAGQAAAAYABgAfAAAAAYABgBAAAAAFAAUAEYAAAAKAAoAWgAAAAAAA=
ACU
> AAAABYKAoGEAbABjAGIAbABkAGcAcwBhAGQAbQBpAG4AQQBNAEMASQBUAC4/dT9soJ67oTe27=
jME
> 8UjOof6ltSsLxgI7Q6rgpnmYwvcQSzwAPlVuOgfVT78/Ww=3D=3D
> Cookie: FileView=3DReverse=3D0&SortBy=3D
> HTTP/1.1 200 Ok
> Server: Microsoft-IIS/5.0
> Date: Thu, 15 Apr 2004 12:11:39 GMT
> Content-Type: text/html
> =

> =

> 2.  DOUBLECLICKING FILE Budget_Forecast-bldgs.xls IN BROWSER:
> =

> GET /publicfiles/office/Budget_Forecast-bldg.xls HTTP/1.0
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/msword, application/vnd.ms-excel, application/vnd.ms-powerpoi=
nt,
> application/x-shockwave-flash, */*
> Referer: http://192.168.1.39/publicfiles/office/
> Accept-Language: en-us
> User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR
> 1.1.4322)
> Host: 192.168.1.39
> Connection: Keep-Alive
> Cookie: FileView=3DReverse=3D0&SortBy=3D0
> HTTP/1.1 401 Access Denied
> Server: Microsoft-IIS/5.0
> Date: Thu, 15 Apr 2004 12:11:48 GMT
> WWW-Authenticate: Negotiate
> WWW-Authenticate: NTLM
> Content-Length: 4431
> Content-Type: text/html
> =

> =

> GET /publicfiles/office/Budget_Forecast-bldg.xls HTTP/1.0
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/msword, application/vnd.ms-excel, application/vnd.ms-powerpoi=
nt,
> application/x-shockwave-flash, */*
> Referer: http://192.168.1.39/publicfiles/office/
> Accept-Language: en-us
> User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR
> 1.1.4322)
> Host: 192.168.1.39
> Connection: Keep-Alive
> Authorization: Negotiate TlRMTVNTUAABAAAAB4IAoAAAAAAAAAAAAAAAAAAAAAA=3D
> Cookie: FileView=3DReverse=3D0&SortBy=3D0
> HTTP/1.1 401 Access Denied
> Server: Microsoft-IIS/5.0
> Date: Thu, 15 Apr 2004 12:11:48 GMT
> WWW-Authenticate: Negotiate
> TlRMTVNTUAACAAAABgAGADAAAAAFgoGgjfwao4eJUMcAAAAAAAAAAHwAfAA2AAAAQQBMAEMAA=
gAG
> AEEATABDAAEAFABSAEUARABTAE4AQQBQAFAARQBSAAQAHABhAGwAYwAuAGEAbQBjAC4AdQB2A=
GEA
> LgBuAGwAAwAyAHIAZQBkAHMAbgBhAHAAcABlAHIALgBhAGwAYwAuAGEAbQBjAC4AdQB2AGEAL=
gBu
> AGwAAAAAAA=3D=3D
> Connection: keep-alive
> Content-Length: 4033
> Content-Type: text/htm
> =

> =

> GET /publicfiles/office/Budget_Forecast-bldg.xls HTTP/1.0
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/msword, application/vnd.ms-excel, application/vnd.ms-powerpoi=
nt,
> application/x-shockwave-flash, */*
> Referer: http://192.168.1.39/publicfiles/office/
> Accept-Language: en-us
> User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR
> 1.1.4322)
> Host: 192.168.1.39
> Connection: Keep-Alive
> Authorization: Negotiate
> TlRMTVNTUAADAAAAGAAYAGQAAAAYABgAfAAAAAYABgBAAAAAFAAUAEYAAAAKAAoAWgAAAAAAA=
ACU
> AAAABYKAoGEAbABjAGIAbABkAGcAcwBhAGQAbQBpAG4AQQBNAEMASQBUAKGXOYgYB57Jtuwkl=
hRo
> 3zlXp7mEYlU/pTPVlSjA/67xb3gj+w9nfB+CpujTRw+nxW=3D=3D
> Cookie: FileView=3DReverse=3D0&SortBy=3DHTTP/1.1 200 OK
> Server: Microsoft-IIS/5.0
> Connection: keep-alive
> Date: Thu, 15 Apr 2004 12:11:48 GMT
> Content-Type: application/vnd.ms-excel
> Accept-Ranges: bytes
> Last-Modified: Thu, 15 Apr 2004 07:06:48 GMT
> ETag: "e6a84738b822c41:a80"
> Content-Length: 142336
> =

> 0
> =

> l
> =

> =

> =

> 0
> =

> =

> =

> =

> Corresponding IIS 5.0 serverlog for these queries of the client opening
> Read-Write:
> -------------------------------------------------------------------------=
---
> ------
> =

> PLEASE NOTE:
> - for readability, I deleted the first two colums: date and time.
> - user-agent
> "Mozilla/4.0+(compatible;+MSIE+5.5;+Windows+NT+5.0;+.NET+CLR+1.1.4322)"
> abbreviated to "MSIE55"
> - user-agent "Microsoft+Data+Access+Internet+Publishing+Provider+DAV"
> abbreviated to "MDAIPPDAV"
> =

> =

> #Software: Microsoft Internet Information Services 5.0
> #Version: 1.0
> #Date: 2004-04-15 12:11:39
> #Fields: c-ip cs-username s-ip s-port cs-method cs-uri-stem cs-uri-query
> sc-status cs(User-Agent)
> -------------------------------------------------------------------------=
---
> ---------------------
> 192.168.1.69 - 192.168.1.39 80 GET /publicfiles/office/ - 401 MSIE55
> 192.168.1.69 class\admin-bldg 192.168.1.39 80 GET /publicfiles/office/ - =
200
> MSIE55
> 192.168.1.69 - 192.168.1.39 80 GET
> /publicfiles/office/Budget_Forecast-bldg.xls - 401 MSIE55
> 192.168.1.69 - 192.168.1.39 80 LOCK
> /publicfiles/office/Budget_Forecast-bldg.xls - 401 MDAIPPDAV
> 192.168.1.69 - 192.168.1.39 80 PROPFIND
> /publicfiles/office/Budget_Forecast-bldg.xls - 401 MDAIPPDAV
> 192.168.1.69 - 192.168.1.39 80 LOCK
> /publicfiles/office/Budget_Forecast-bldg.xls - 401 MDAIPPDAV
> 192.168.1.69 class\admin-bldg 192.168.1.39 80 GET
> /publicfiles/office/Budget_Forecast-bldg.xls - 200 MSIE55
> 192.168.1.69 class\admin-bldg 192.168.1.39 80 LOCK
> /publicfiles/office/Budget_Forecast-bldg.xls - 200 MDAIPPDAV
> 192.168.1.69 class\admin-bldg 192.168.1.39 80 GET
> /publicfiles/office/Budget_Forecast-bldg.xls - 304 MDAIPPDAV
> 192.168.1.69 - 192.168.1.39 80 LOCK
> /publicfiles/office/Budget_Forecast-bldg.xls - 401 MDAIPPDAV
> 192.168.1.69 class\admin-bldg 192.168.1.39 80 LOCK
> /publicfiles/office/Budget_Forecast-bldg.xls - 200 MDAIPPDAV
> 192.168.1.69 - 192.168.1.39 80 UNLOCK
> /publicfiles/office/Budget_Forecast-bldg.xls - 401 MDAIPPDAV
> 192.168.1.69 class\admin-bldg 192.168.1.39 80 UNLOCK
> /publicfiles/office/Budget_Forecast-bldg.xls - 204 MDAIPPDAV
> 192.168.1.228 - 192.168.1.39 80 PROPFIND /publicfiles/office - 401 MDAIPP=
DAV
> 192.168.1.228 class\admin-it 192.168.1.39 80 PROPFIND /publicfiles/office=
 -
> 207 MDAIPPDAV
> 192.168.1.228 class\admin-it 192.168.1.39 80 PROPFIND /publicfiles/office=
 -
> 207 MDAIPPDAV
> =

> =

> =

> =

> =

> =

> =

> HTTP-header dump of another client opening documents Read-Only:
> --------------------------------------------------------------
> =

> 1.  TYPING URL IN BROWSER:
> =

> GET /publicfiles/office/ HTTP/1.0
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/vnd.ms-excel, application/msword, application/x-shockwave-fla=
sh,
> */*
> Accept-Language: en-us
> User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR
> 1.1.4322)
> Host: amcnip1139.amc.uva.nl
> Connection: Keep-Alive
> =

> HTTP/1.1 401 Access Denied
> Server: Microsoft-IIS/5.0
> Date: Thu, 15 Apr 2004 12:31:33 GMT
> WWW-Authenticate: Negotiate
> WWW-Authenticate: NTLM
> Content-Length: 4431
> Content-Type: text/html
> =

> =

> GET /publicfiles/office/ HTTP/1.0
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/vnd.ms-excel, application/msword, application/x-shockwave-fla=
sh,
> */*
> Accept-Language: en-us
> User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR
> 1.1.4322)
> Host: amcnip1139.amc.uva.nl
> Connection: Keep-Alive
> Authorization: Negotiate TlRMTVNTUAABAAAAB4IAoAAAAAAAAAAAAAAAAAAAAAB=3D
> =

> HTTP/1.1 401 Access Denied
> Server: Microsoft-IIS/5.0
> Date: Thu, 15 Apr 2004 12:31:33 GMT
> WWW-Authenticate: Negotiate
> TlRMTVNTUAACAAAABgAGADAAAAAFgoGgdAfwIATYXekAAAAAAAAAAHwAfAA2AAAAQQBMAEMAA=
gAG
> AEEATABDAAEAFABSAEUARABTAE4AQQBQAFAARQBSAAQAHABhAGwAYwAuAGEAbQBjAC4AdQB2A=
GEA
> LgBuAGwAAwAyAHIAZQBkAHMAbgBhAHAAcABlAHIALgBhAGwAYwAuAGEAbQBjAC4AdQB2AGEAL=
gBu
> AGwAAAAAAA=3D=3D
> Connection: keep-alive
> Content-Length: 4033
> Content-Type: text/htm
> =

> =

> GET /publicfiles/office/ HTTP/1.0
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/vnd.ms-excel, application/msword, application/x-shockwave-fla=
sh,
> */*
> Accept-Language: en-us
> User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR
> 1.1.4322)
> Host: amcnip1139.amc.uva.nl
> Connection: Keep-Alive
> Authorization: Negotiate
> TlRMTVNTUAADAAAAGAAYAGgAAAAYABgAgAAAAAYABgBAAAAAGAAYAEYAAAAKAAoAXgAAAAAAA=
ACY
> AAAABYKAoGEAbABjAGkAdABhAGQAbQBpAG4AYgBsAGQAZwBzAFYARQBOAFUAUwBCNBQ7P8FwV=
AHI
> ae81HkQTjKpea7bJ3UZk5tnTrK9m7//lGeFpjohLI6Wf4VbtMuh=3DHTTP/1.1 200 Ok
> Server: Microsoft-IIS/5.0
> Date: Thu, 15 Apr 2004 12:31:33 GMT
> Content-Type: text/html
> =

> =

> 2.  DOUBLECLICKING FILE Finacncial_Projection-it.xls IN BROWSER:
> =

> GET /publicfiles/office/Financial_Projection-it.xls HTTP/1.0
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/vnd.ms-excel, application/msword, application/x-shockwave-fla=
sh,
> */*
> Referer: http://amcnip1139.amc.uva.nl/publicfiles/office/
> Accept-Language: en-us
> User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR
> 1.1.4322)
> Host: amcnip1139.amc.uva.nl
> Connection: Keep-Alive
> =

> HTTP/1.1 401 Access Denied
> Server: Microsoft-IIS/5.0
> Date: Thu, 15 Apr 2004 12:31:45 GMT
> WWW-Authenticate: Negotiate
> WWW-Authenticate: NTLM
> Content-Length: 4431
> Content-Type: text/html
> =

> =

> GET /publicfiles/office/Financial_Projection-it.xls HTTP/1.0
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/vnd.ms-excel, application/msword, application/x-shockwave-fla=
sh,
> */*
> Referer: http://amcnip1139.amc.uva.nl/publicfiles/office/
> Accept-Language: en-us
> User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR
> 1.1.4322)
> Host: amcnip1139.amc.uva.nl
> Connection: Keep-Alive
> Authorization: Negotiate TlRMTVNTUAABAAAAB4IAoAAAAAAAAAAAAAAAAAAAAAB=3D
> =

> HTTP/1.1 401 Access Denied
> Server: Microsoft-IIS/5.0
> Date: Thu, 15 Apr 2004 12:31:45 GMT
> WWW-Authenticate: Negotiate
> TlRMTVNTUAACAAAABgAGADAAAAAFgoGgrvSj7MtlN10AAAAAAAAAAHwAfAA2AAAAQQBMAEMAA=
gAG
> AEEATABDAAEAFABSAEUARABTAE4AQQBQAFAARQBSAAQAHABhAGwAYwAuAGEAbQBjAC4AdQB2A=
GEA
> LgBuAGwAAwAyAHIAZQBkAHMAbgBhAHAAcABlAHIALgBhAGwAYwAuAGEAbQBjAC4AdQB2AGEAL=
gBu
> AGwAAAAAAA=3D=3D
> Connection: keep-alive
> Content-Length: 4033
> Content-Type: text/htm
> =

> =

> GET /publicfiles/office/Financial_Projection-it.xls HTTP/1.0
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/vnd.ms-excel, application/msword, application/x-shockwave-fla=
sh,
> */*
> Referer: http://amcnip1139.amc.uva.nl/publicfiles/office/
> Accept-Language: en-us
> User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR
> 1.1.4322)
> Host: amcnip1139.amc.uva.nl
> Connection: Keep-Alive
> Authorization: Negotiate
> TlRMTVNTUAADAAAAGAAYAGgAAAAYABgAgAAAAAYABgBAAAAAGAAYAEYAAAAKAAoAXgAAAAAAA=
ACY
> AAAABYKAoGEAbABjAGkAdABhAGQAbQBpAG4AYgBsAGQAZwBzAFYARQBOAFUAUwDcp3cRAZtKm=
d0P
> 2DFZljF5u40dLncXzJ90193x+SdpLubZ9i6WX7ed48uGChHRadp=3D
> HTTP/1.1 200 OK
> Server: Microsoft-IIS/5.0
> Connection: keep-alive
> Date: Thu, 15 Apr 2004 12:31:45 GMT
> Content-Type: application/vnd.ms-excel
> Accept-Ranges: bytes
> Last-Modified: Tue, 30 Jul 2002 08:52:24 GMT
> ETag: "0943f6ca637c21:a80"
> Content-Length: 145408
> =

> =

> =

> l
> =

> =

> =

> l
> =

> =

> =

> =

> =

> Corresponding IIS 5.0 serverlog for these queries from client opening in
> Read-Only:
> -------------------------------------------------------------------------=
---
> -------
> =

> PLEASE NOTE:
> - for readability, I deleted the first two colums: date and time.
> - user-agent
> "Mozilla/4.0+(compatible;+MSIE+5.5;+Windows+NT+5.0;+.NET+CLR+1.1.4322)"
> abbreviated to "MSIE55"
> - user-agent "Microsoft+Data+Access+Internet+Publishing+Provider+DAV"
> abbreviated to
> "MDAIPPDAV"
> =

> #Software: Microsoft Internet Information Services 5.0
> #Version: 1.0
> #Date: 2004-04-15 12:31:33
> #Fields: date time c-ip cs-username s-ip s-port cs-method cs-uri-stem
> cs-uri-query
> sc-status cs(User-Agent)
> -------------------------------------------------------------------------=
---
> -------
> 192.168.1.228 - 192.168.1.39 80 GET /publicfiles/office/ - 401 MSIE55
> 192.168.1.228 class\admin-it 192.168.1.39 80 GET /publicfiles/office/ - 2=
00
> MSIE55
> 192.168.1.228 - 192.168.1.39 80 GET
> /publicfiles/office/Financial_Projection-it.xls - 401 MSIE55
> 192.168.1.228 class\admin-it 192.168.1.39 80 GET
> /publicfiles/office/Financial_Projection-it.xls - 200 MSIE55
> =

> =

> =

> REMARK: Where are the LOCK/UNLOCK queries?!
> =

> =

> Derek
> derekdb@gmx.net
> =

> =

> =



From w3c-dist-auth-request@w3.org  Sun Apr 18 14:26:53 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04303
	for <webdav-archive@lists.ietf.org>; Sun, 18 Apr 2004 14:26:53 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 4F147A17B4; Sun, 18 Apr 2004 14:26:53 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id F02E2A17B4
	for <w3c-dist-auth@listhub.w3.org>; Sun, 18 Apr 2004 14:26:51 -0400 (EDT)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BFH0F-0003mx-OI
	for w3c-dist-auth@w3.org; Sun, 18 Apr 2004 14:26:51 -0400
Received: (qmail 1660 invoked by uid 65534); 18 Apr 2004 18:26:19 -0000
Received: from pD950C3B1.dip.t-dialin.net (EHLO gmx.de) (217.80.195.177)
  by mail.gmx.net (mp002) with SMTP; 18 Apr 2004 20:26:19 +0200
X-Authenticated: #1915285
Message-ID: <4082C846.7060509@gmx.de>
Date: Sun, 18 Apr 2004 20:26:14 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: WebDAV <w3c-dist-auth@w3.org>
Cc: derekdb@gmx.net
References: <20040418101805.2009699665.ejw@cse.ucsc.edu>
In-Reply-To: <20040418101805.2009699665.ejw@cse.ucsc.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: HELP: only -ONE- client LOCK/UNLOCK's my WebDAV served files,  -ALL- others issue GET
X-Archived-At: http://www.w3.org/mid/4082C846.7060509@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8467
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040418182653.4F147A17B4@frink.w3.org>
Resent-Date: Sun, 18 Apr 2004 14:26:53 -0400 (EDT)
Content-Transfer-Encoding: 7bit


How's the behaviour for both types of machines when the document is 
opened from a web folder, not the browser?

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Sun Apr 18 15:07:06 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05977
	for <webdav-archive@lists.ietf.org>; Sun, 18 Apr 2004 15:07:06 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 20B77A4B65; Sun, 18 Apr 2004 15:07:06 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 59397A4B65
	for <w3c-dist-auth@listhub.w3.org>; Sun, 18 Apr 2004 15:07:04 -0400 (EDT)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BFHd9-0002dG-P0
	for w3c-dist-auth@w3.org; Sun, 18 Apr 2004 15:07:04 -0400
Received: (qmail 23319 invoked by uid 65534); 18 Apr 2004 19:06:31 -0000
Received: from pD950C3B1.dip.t-dialin.net (EHLO gmx.de) (217.80.195.177)
  by mail.gmx.net (mp025) with SMTP; 18 Apr 2004 21:06:31 +0200
X-Authenticated: #1915285
Message-ID: <4082D1AF.7000409@gmx.de>
Date: Sun, 18 Apr 2004 21:06:23 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Cc: acl@webdav.org, w3c-dist-auth@w3.org
X-Priority: 1 (highest)
References: <OF0D096C15.882BECDE-ON85256E79.004ECEF7-85256E79.004F28F8@us.ibm.com>
In-Reply-To: <OF0D096C15.882BECDE-ON85256E79.004ECEF7-85256E79.004F28F8@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [ACL] Re: Last minute ACL stuff (was DAV:unauthenticated usage)
X-Archived-At: http://www.w3.org/mid/4082D1AF.7000409@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8468
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040418190706.20B77A4B65@frink.w3.org>
Resent-Date: Sun, 18 Apr 2004 15:07:06 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Geoffrey M Clemm wrote:

> I agree that it makes sense to remove the "protected" qualifier.
> Julian: Can you take care of this?
> 
> Cheers,
> Geoff

We're talking about ... 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.html#PROPERTY_inherited-acl-set> 
and Eric's request on the ACL mailing list 
(<http://mailman.webdav.org/pipermail/acl/2004-April/001815.html>).


I agree that servers should be allowed not to protect that property. I'm 
not so sure about the best wording, how about saying...:

To stay consistent with other property descriptions, I'd prefer to 
remove the word "protected" but also to add...:

"Servers MAY implement DAV:inherited-acl-set as protected property."

I'll make that change for now; if people feel we shouldn't make that 
change they need to speak up *now*, as we are currently doing the last 
edits on the *RFC* document which then will be published Really Soon.

Regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Apr 19 07:24:47 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04214
	for <webdav-archive@lists.ietf.org>; Mon, 19 Apr 2004 07:24:47 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 07025A2DEC; Mon, 19 Apr 2004 07:24:47 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 570ABA2DEC
	for <w3c-dist-auth@listhub.w3.org>; Mon, 19 Apr 2004 07:24:45 -0400 (EDT)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BFWsp-0008Lx-I1
	for w3c-dist-auth@w3.org; Mon, 19 Apr 2004 07:24:15 -0400
Received: (qmail 1323 invoked by uid 65534); 19 Apr 2004 11:23:42 -0000
Received: from p50824CEA.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.76.234)
  by mail.gmx.net (mp010) with SMTP; 19 Apr 2004 13:23:42 +0200
X-Authenticated: #1915285
Message-ID: <4083B6B5.40501@gmx.de>
Date: Mon, 19 Apr 2004 13:23:33 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Cc: acl@webdav.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: ACL spec enters RFC-Editors "AUTH48" period
X-Archived-At: http://www.w3.org/mid/4083B6B5.40501@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8469
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040419112447.07025A2DEC@frink.w3.org>
Resent-Date: Mon, 19 Apr 2004 07:24:47 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi,

(cc'ing the specific ACL mailing as well)

The WebDAV ACL spec just entered the AUTH48 state, meaning that we can 
do final edits if and only if they are minor. It also means that right 
now the authors are busy reviewing the text provided by the RFC Editor.

I'm tracking changes to the latest draft at...

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.html>

This includes both corrections made by the RFC Editor, and changes we 
have discussed on the ACL mailing list since December.

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Apr 19 13:08:59 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24113
	for <webdav-archive@lists.ietf.org>; Mon, 19 Apr 2004 13:08:56 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id DE01CA11DA; Mon, 19 Apr 2004 13:08:58 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 69638A11DA
	for <w3c-dist-auth@listhub.w3.org>; Mon, 19 Apr 2004 13:08:57 -0400 (EDT)
Received: from numenor.qualcomm.com ([129.46.51.58])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BFcGG-00080b-Gj
	for w3c-dist-auth@w3.org; Mon, 19 Apr 2004 13:08:48 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i3JH6nV2020279
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 19 Apr 2004 10:06:49 -0700 (PDT)
Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161])
	by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i3JH6kvB006613;
	Mon, 19 Apr 2004 10:06:47 -0700 (PDT)
Mime-Version: 1.0
X-Sender: hardie@mage.qualcomm.com
Message-Id: <p06100501bca9b6f57292@[129.46.227.161]>
In-Reply-To: <4082D1AF.7000409@gmx.de>
References: 
 <OF0D096C15.882BECDE-ON85256E79.004ECEF7-85256E79.004F28F8@us.ibm.com>
 <4082D1AF.7000409@gmx.de>
X-Priority: 1 (Highest)
Date: Mon, 19 Apr 2004 10:06:44 -0700
To: Julian Reschke <julian.reschke@gmx.de>,
        Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
From: Ted Hardie <hardie@qualcomm.com>
Cc: acl@webdav.org, w3c-dist-auth@w3.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: Re: [ACL] Re: Last minute ACL stuff (was DAV:unauthenticated  usage)
X-Archived-At: http://www.w3.org/mid/p06100501bca9b6f57292@%5B129.46.227.161%5D
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8470
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040419170858.DE01CA11DA@frink.w3.org>
Resent-Date: Mon, 19 Apr 2004 13:08:58 -0400 (EDT)


Are you talking about making this change during AUTH 48?

This is not a time at which substantive changes are allowed.

You will note that this draft has been significantly delayed in
publication because of the changes which were included during
the last round, including a need to return the whole document
to the IESG agenda for re-approval and a restart in the
RFC Editor's queue.  Doing this again will raise very serious
questions about the extent to which this working group has
reviewed specs sent to the IESG/RFC Editor.

			Ted Hardie
			co-AD, Applications Area


At 9:06 PM +0200 04/18/2004, Julian Reschke wrote:
>Geoffrey M Clemm wrote:
>
>>I agree that it makes sense to remove the "protected" qualifier.
>>Julian: Can you take care of this?
>>
>>Cheers,
>>Geoff
>
>We're talking about ... 
><http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.html#PROPERTY_inherited-acl-set> 
>and Eric's request on the ACL mailing list 
>(<http://mailman.webdav.org/pipermail/acl/2004-April/001815.html>).
>
>
>I agree that servers should be allowed not to protect that property. 
>I'm not so sure about the best wording, how about saying...:
>
>To stay consistent with other property descriptions, I'd prefer to 
>remove the word "protected" but also to add...:
>
>"Servers MAY implement DAV:inherited-acl-set as protected property."
>
>I'll make that change for now; if people feel we shouldn't make that 
>change they need to speak up *now*, as we are currently doing the 
>last edits on the *RFC* document which then will be published Really 
>Soon.
>
>Regards, Julian
>
>
>--
><green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Apr 19 13:44:23 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26768
	for <webdav-archive@lists.ietf.org>; Mon, 19 Apr 2004 13:44:22 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 5CBEDA261F; Mon, 19 Apr 2004 13:44:23 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id C8116A2B31
	for <w3c-dist-auth@listhub.w3.org>; Mon, 19 Apr 2004 13:43:43 -0400 (EDT)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BFcZl-0002kH-F1
	for w3c-dist-auth@w3.org; Mon, 19 Apr 2004 13:28:57 -0400
Received: (qmail 26359 invoked by uid 65534); 19 Apr 2004 17:28:24 -0000
Received: from p50824CEA.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.76.234)
  by mail.gmx.net (mp023) with SMTP; 19 Apr 2004 19:28:24 +0200
X-Authenticated: #1915285
Message-ID: <40840C35.4070303@gmx.de>
Date: Mon, 19 Apr 2004 19:28:21 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ted Hardie <hardie@qualcomm.com>
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, acl@webdav.org,
        w3c-dist-auth@w3.org
References: <OF0D096C15.882BECDE-ON85256E79.004ECEF7-85256E79.004F28F8@us.ibm.com> <4082D1AF.7000409@gmx.de> <p06100501bca9b6f57292@[129.46.227.161]>
In-Reply-To: <p06100501bca9b6f57292@[129.46.227.161]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [ACL] Re: Last minute ACL stuff (was DAV:unauthenticated  usage)
X-Archived-At: http://www.w3.org/mid/40840C35.4070303@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8471
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040419174423.5CBEDA261F@frink.w3.org>
Resent-Date: Mon, 19 Apr 2004 13:44:23 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Ted Hardie wrote:

> Are you talking about making this change during AUTH 48?
> 
> This is not a time at which substantive changes are allowed.
> 
> You will note that this draft has been significantly delayed in
> publication because of the changes which were included during
> the last round, including a need to return the whole document
> to the IESG agenda for re-approval and a restart in the
> RFC Editor's queue.  Doing this again will raise very serious
> questions about the extent to which this working group has
> reviewed specs sent to the IESG/RFC Editor.

Yes, I indeed was talking about AUTH48, and I'm aware of the implications.

In this case a property that everybody thought was optionally changeable 
indeed wasn't. Removing the requirement that it's indeed non-writeable 
(= protected) doesn't change anything for clients and servers that don't 
want to support authoring; but it makes it legal for those who wish to 
do so. As a matter of fact, people that need the ability to change that 
property will likely support that in their servers no matter what the 
specs says about it, and thus this would end up on a future issue/errata 
list anyway. Therefore I think this is a good change that won't have any 
negative side effects.

On the other hand, I've been announcing that change because it *is* a 
change, and because we need feedback and full consensus on it. If you or 
the RFC-Editor feel this one is problematic, I'll be happy to roll back 
that change (= remove it from the issues list sent back to the RFC Editor).

For the record: I fully support the statement that drafts submitted for 
publication need to be of high quality; and I'm trying to enhance that 
quality by using the best tools available (rfc2629 format instead of 
Word, and complete change and issue tracking on everything we do between 
drafts).

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Apr 19 13:51:45 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27223
	for <webdav-archive@lists.ietf.org>; Mon, 19 Apr 2004 13:51:45 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id DEB9AA28CF; Mon, 19 Apr 2004 13:51:45 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id EF9D9A28CF
	for <w3c-dist-auth@listhub.w3.org>; Mon, 19 Apr 2004 13:51:43 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BFcvi-00010s-DN
	for w3c-dist-auth@w3.org; Mon, 19 Apr 2004 13:51:38 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3.org
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i3JHoUhV022858
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 19 Apr 2004 10:50:31 -0700
In-Reply-To: <40840C35.4070303@gmx.de>
References: <OF0D096C15.882BECDE-ON85256E79.004ECEF7-85256E79.004F28F8@us.ibm.com> <4082D1AF.7000409@gmx.de> <p06100501bca9b6f57292@[129.46.227.161]> <40840C35.4070303@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <1353A202-922A-11D8-A6A2-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: w3c-dist-auth@w3.org, Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>,
        Ted Hardie <hardie@qualcomm.com>, acl@webdav.org
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 19 Apr 2004 10:50:41 -0700
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: [ACL] Re: Last minute ACL stuff (was DAV:unauthenticated  usage)
X-Archived-At: http://www.w3.org/mid/1353A202-922A-11D8-A6A2-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8472
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040419175145.DEB9AA28CF@frink.w3.org>
Resent-Date: Mon, 19 Apr 2004 13:51:45 -0400 (EDT)
Content-Transfer-Encoding: 7bit


I reviewed the changes and I don't consider them substantive.  The 
sentence added that the property can be changed is on the borderline 
between "clarification" and "insubstantive change", as it doesn't 
change either client or server behavior.

There is a concern that this WG doesn't have as many active members as 
it needs to do careful review of new specs, but the ACL specification 
is actually quite mature (having been reviewed by quite a few people 
over a period of years) and has been implemented by more than one 
group, with some interoperability testing.

Lisa

On Apr 19, 2004, at 10:28 AM, Julian Reschke wrote:

> Ted Hardie wrote:
>
>> Are you talking about making this change during AUTH 48?
>> This is not a time at which substantive changes are allowed.
>> You will note that this draft has been significantly delayed in
>> publication because of the changes which were included during
>> the last round, including a need to return the whole document
>> to the IESG agenda for re-approval and a restart in the
>> RFC Editor's queue.  Doing this again will raise very serious
>> questions about the extent to which this working group has
>> reviewed specs sent to the IESG/RFC Editor.
>
> Yes, I indeed was talking about AUTH48, and I'm aware of the 
> implications.
>
> In this case a property that everybody thought was optionally 
> changeable indeed wasn't. Removing the requirement that it's indeed 
> non-writeable (= protected) doesn't change anything for clients and 
> servers that don't want to support authoring; but it makes it legal 
> for those who wish to do so. As a matter of fact, people that need the 
> ability to change that property will likely support that in their 
> servers no matter what the specs says about it, and thus this would 
> end up on a future issue/errata list anyway. Therefore I think this is 
> a good change that won't have any negative side effects.
>
> On the other hand, I've been announcing that change because it *is* a 
> change, and because we need feedback and full consensus on it. If you 
> or the RFC-Editor feel this one is problematic, I'll be happy to roll 
> back that change (= remove it from the issues list sent back to the 
> RFC Editor).
>
> For the record: I fully support the statement that drafts submitted 
> for publication need to be of high quality; and I'm trying to enhance 
> that quality by using the best tools available (rfc2629 format instead 
> of Word, and complete change and issue tracking on everything we do 
> between drafts).
>
> Best regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> _______________________________________________
> acl mailing list
> acl@webdav.org
> http://mailman.webdav.org/mailman/listinfo/acl



From w3c-dist-auth-request@w3.org  Mon Apr 19 13:53:38 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27325
	for <webdav-archive@lists.ietf.org>; Mon, 19 Apr 2004 13:53:37 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 1F2C4A2BC7; Mon, 19 Apr 2004 13:53:37 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 16FA2A2BC7
	for <w3c-dist-auth@listhub.w3.org>; Mon, 19 Apr 2004 13:53:36 -0400 (EDT)
Received: from numenor.qualcomm.com ([129.46.51.58])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BFcxS-0001Ab-Dp
	for w3c-dist-auth@w3.org; Mon, 19 Apr 2004 13:53:26 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i3JHphV2023222
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 19 Apr 2004 10:51:43 -0700 (PDT)
Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161])
	by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i3JHpf3P022091;
	Mon, 19 Apr 2004 10:51:41 -0700 (PDT)
Mime-Version: 1.0
X-Sender: hardie@mage.qualcomm.com
Message-Id: <p06100504bca9bf8c75fb@[129.46.227.161]>
In-Reply-To: <40840C35.4070303@gmx.de>
References: 
 <OF0D096C15.882BECDE-ON85256E79.004ECEF7-85256E79.004F28F8@us.ibm.com>
 <4082D1AF.7000409@gmx.de> <p06100501bca9b6f57292@[129.46.227.161]>
 <40840C35.4070303@gmx.de>
Date: Mon, 19 Apr 2004 10:51:40 -0700
To: Julian Reschke <julian.reschke@gmx.de>
From: Ted Hardie <hardie@qualcomm.com>
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, acl@webdav.org,
        w3c-dist-auth@w3.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: Re: [ACL] Re: Last minute ACL stuff (was DAV:unauthenticated   usage)
X-Archived-At: http://www.w3.org/mid/p06100504bca9bf8c75fb@%5B129.46.227.161%5D
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8473
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040419175337.1F2C4A2BC7@frink.w3.org>
Resent-Date: Mon, 19 Apr 2004 13:53:37 -0400 (EDT)


At 7:28 PM +0200 04/19/2004, Julian Reschke wrote:
>Yes, I indeed was talking about AUTH48, and I'm aware of the implications.
>
>In this case a property that everybody thought was optionally 
>changeable indeed wasn't. Removing the requirement that it's indeed 
>non-writeable (= protected) doesn't change anything for clients and 
>servers that don't want to support authoring; but it makes it legal 
>for those who wish to do so. As a matter of fact, people that need 
>the ability to change that property will likely support that in 
>their servers no matter what the specs says about it, and thus this 
>would end up on a future issue/errata list anyway. Therefore I think 
>this is a good change that won't have any negative side effects.
>
>On the other hand, I've been announcing that change because it *is* 
>a change, and because we need feedback and full consensus on it. If 
>you or the RFC-Editor feel this one is problematic, I'll be happy to 
>roll back that change (= remove it from the issues list sent back to 
>the RFC Editor).

It is not appropriate to make substantive changes to the document at this stage
of processing.  If this is a showstopper issue, you can ask the RFC Editor
to stop processing the document, and get the WG chairs to call for consensus
on the changes.  The draft will then have to go back through at least
IESG processing and possibly IETF last call.

Continuing to tweak the documents after they have completed processing
is hindering this group's ability to get a stable specification.  It is normal
to find things as people implement and deploy, but if you never issue
a final spec the number of people actually working with the documents
will remain low.

		regards,
			Ted Hardie



From w3c-dist-auth-request@w3.org  Mon Apr 19 14:03:56 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28242
	for <webdav-archive@lists.ietf.org>; Mon, 19 Apr 2004 14:03:56 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 5685BA2FFE; Mon, 19 Apr 2004 14:03:56 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id AEF8BA2F28
	for <w3c-dist-auth@listhub.w3.org>; Mon, 19 Apr 2004 14:03:54 -0400 (EDT)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BFd7a-0003vt-5g
	for w3c-dist-auth@w3.org; Mon, 19 Apr 2004 14:03:54 -0400
Received: (qmail 4341 invoked by uid 65534); 19 Apr 2004 18:03:20 -0000
Received: from p50824CEA.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.76.234)
  by mail.gmx.net (mp003) with SMTP; 19 Apr 2004 20:03:20 +0200
X-Authenticated: #1915285
Message-ID: <40841467.1080802@gmx.de>
Date: Mon, 19 Apr 2004 20:03:19 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ted Hardie <hardie@qualcomm.com>
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, acl@webdav.org,
        w3c-dist-auth@w3.org
References: <OF0D096C15.882BECDE-ON85256E79.004ECEF7-85256E79.004F28F8@us.ibm.com> <4082D1AF.7000409@gmx.de> <p06100501bca9b6f57292@[129.46.227.161]> <40840C35.4070303@gmx.de> <p06100504bca9bf8c75fb@[129.46.227.161]>
In-Reply-To: <p06100504bca9bf8c75fb@[129.46.227.161]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [ACL] Re: Last minute ACL stuff (was DAV:unauthenticated  usage)
X-Archived-At: http://www.w3.org/mid/40841467.1080802@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8474
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040419180356.5685BA2FFE@frink.w3.org>
Resent-Date: Mon, 19 Apr 2004 14:03:56 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Ted Hardie wrote:

> It is not appropriate to make substantive changes to the document at 
> this stage
> of processing.  If this is a showstopper issue, you can ask the RFC Editor
> to stop processing the document, and get the WG chairs to call for 
> consensus
> on the changes.  The draft will then have to go back through at least
> IESG processing and possibly IETF last call.

IMHO, it's not a substantive change, and it's also not a showstopper. So 
if there's any doubt, let's not make it.

> Continuing to tweak the documents after they have completed processing
> is hindering this group's ability to get a stable specification.  It is 
> normal
> to find things as people implement and deploy, but if you never issue
> a final spec the number of people actually working with the documents
> will remain low.

Agreed. That's why we want to get the spec published (finally). So if 
there's any doubt about a particular change, let's not do it. Note that 
this is the only change that I'm aware that isn't a case of bug fixing 
or updating references.

Eric, would you agree not to do it (after all, you did ask for it), and 
just add it to a future errata document?


Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Tue Apr 20 17:42:06 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27989
	for <webdav-archive@lists.ietf.org>; Tue, 20 Apr 2004 17:42:06 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 5CEF8A314F; Tue, 20 Apr 2004 17:42:08 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id F3B34A314F
	for <w3c-dist-auth@listhub.w3.org>; Tue, 20 Apr 2004 17:42:06 -0400 (EDT)
Received: from inet-mail1.oracle.com ([148.87.2.201])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BG30I-0003S0-Mj
	for w3c-dist-auth@w3.org; Tue, 20 Apr 2004 17:42:06 -0400
Received: from inet-mail1.oracle.com (localhost [127.0.0.1])
	by inet-mail1.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i3KLgUXi017064
	for <w3c-dist-auth@w3.org>; Tue, 20 Apr 2004 14:42:31 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10])
	by inet-mail1.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i3KLgSpb017037
	for <w3c-dist-auth@w3.org>; Tue, 20 Apr 2004 14:42:28 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1])
	by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i3KLfUs5030522
	for <w3c-dist-auth@w3.org>; Tue, 20 Apr 2004 15:41:30 -0600
Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197])
	by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id i3KLfUft030516
	for <w3c-dist-auth@w3.org>; Tue, 20 Apr 2004 15:41:30 -0600
Message-ID: <00a401c42720$01f1d840$c5b42382@us.oracle.com>
From: "Stanley Guan" <stanley.guan@oracle.com>
To: <w3c-dist-auth@w3.org>
References: <OF0D096C15.882BECDE-ON85256E79.004ECEF7-85256E79.004F28F8@us.ibm.com> <4082D1AF.7000409@gmx.de> <p06100501bca9b6f57292@[129.46.227.161]> <40840C35.4070303@gmx.de>
Date: Tue, 20 Apr 2004 14:39:49 -0700
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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: Last minute ACL stuff
X-Archived-At: http://www.w3.org/mid/00a401c42720$01f1d840$c5b42382@us.oracle.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8475
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040420214208.5CEF8A314F@frink.w3.org>
Resent-Date: Tue, 20 Apr 2004 17:42:08 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Just curious why Element "property" instead of "prop" is 
used in the definition of Element principal:
   5.5.1 ACE Principal
   <!ELEMENT principal (href | all | authenticated | unauthenticated 
          | property | self)>

The content of Element "prop" is defined to be ANY with further
clarafication (RFC 2518):
   "The prop XML element is a generic container for
   properties defined on resources.  All elements inside a prop XML
   element MUST define properties related to the resource.  No other
   elements may be used inside of a prop element."

It seems to me that "prop" can be very well suited for Element
principal's definition.  Besides, Element "prop" is also referenced
in the definitions of REPORT's sub-elements.

Will appreciate your inputs!

-Stanley




From w3c-dist-auth-request@w3.org  Tue Apr 20 22:05:54 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15467
	for <webdav-archive@lists.ietf.org>; Tue, 20 Apr 2004 22:05:54 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id C5E84A172E; Tue, 20 Apr 2004 22:05:54 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 19B55A172E
	for <w3c-dist-auth@listhub.w3.org>; Tue, 20 Apr 2004 22:05:52 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1BG771-0007xc-V2
	for w3c-dist-auth@w3c.org; Tue, 20 Apr 2004 22:05:20 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: <w3c-dist-auth@w3c.org>
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i3L24qhV000519
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <w3c-dist-auth@w3c.org>; Tue, 20 Apr 2004 19:04:58 -0700
Mime-Version: 1.0 (Apple Message framework v613)
To: Webdav WG <w3c-dist-auth@w3c.org>
Message-Id: <4DD90555-9338-11D8-A6A2-000A95B2BB72@osafoundation.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-28--1020794607
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Tue, 20 Apr 2004 19:05:04 -0700
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Fwd: Using OPTIONS for optional feature discovery -- advice 
X-Archived-At: http://www.w3.org/mid/4DD90555-9338-11D8-A6A2-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8476
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040421020554.C5E84A172E@frink.w3.org>
Resent-Date: Tue, 20 Apr 2004 22:05:54 -0400 (EDT)



--Apple-Mail-28--1020794607
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

FYI - thought this draft would be useful reading

Begin forwarded message:

> From: Jeffrey Mogul <Jeff.Mogul@hp.com>
> Date: April 20, 2004 6:37:04 PM PDT
> To: Lisa Dusseault <lisa@osafoundation.org>
> Cc: Jeff.Mogul@hp.com
> Subject: Re: Using OPTIONS for optional feature discovery -- advice
>
> In my opinion, we ended up with OPTIONS being next to useless
> because we couldn't agree (within the HTTP working group or
> even among the authors of RFC2616) on a meaningful feature-discovery
> mechanism.
>
> I still believe that the proposal I co-wrote:
>    http://ftp.ics.uci.edu/pub/ietf/http/draft-ietf-http-options-02.txt
>
> is the most feasible approach, and I'd be happy to see the WebDAV
> group adopt it if you can.  Note that there are a few places where
> this proposal might need to change RFC2616, and this could create
> some challenges (or maybe not; I no longer have the neurons to think
> about this carefully).
>
> -Jeff

--Apple-Mail-28--1020794607
Content-Type: text/enriched;
	charset=US-ASCII
Content-Transfer-Encoding: 7bit

FYI - thought this draft would be useful reading


Begin forwarded message:


<excerpt><bold><color><param>0000,0000,0000</param>From:
</color></bold>Jeffrey Mogul <<Jeff.Mogul@hp.com>

<bold><color><param>0000,0000,0000</param>Date: </color></bold>April
20, 2004 6:37:04 PM PDT

<bold><color><param>0000,0000,0000</param>To: </color></bold>Lisa
Dusseault <<lisa@osafoundation.org>

<bold><color><param>0000,0000,0000</param>Cc:
</color></bold>Jeff.Mogul@hp.com

<bold><color><param>0000,0000,0000</param>Subject: </color>Re: Using
OPTIONS for optional feature discovery -- advice 

</bold>

In my opinion, we ended up with OPTIONS being next to useless

because we couldn't agree (within the HTTP working group or

even among the authors of RFC2616) on a meaningful feature-discovery

mechanism.


I still believe that the proposal I co-wrote:

   http://ftp.ics.uci.edu/pub/ietf/http/draft-ietf-http-options-02.txt


is the most feasible approach, and I'd be happy to see the WebDAV

group adopt it if you can.  Note that there are a few places where

this proposal might need to change RFC2616, and this could create

some challenges (or maybe not; I no longer have the neurons to think

about this carefully).


-Jeff

</excerpt>
--Apple-Mail-28--1020794607--



From w3c-dist-auth-request@w3.org  Sun Apr 25 11:01:19 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02134
	for <webdav-archive@lists.ietf.org>; Sun, 25 Apr 2004 11:01:18 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B961AA1A84; Sun, 25 Apr 2004 11:01:19 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 831E5A1A84
	for <w3c-dist-auth@listhub.w3.org>; Sun, 25 Apr 2004 11:01:18 -0400 (EDT)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1BHl8A-0003oJ-78
	for w3c-dist-auth@w3c.org; Sun, 25 Apr 2004 11:01:18 -0400
Received: (qmail 11078 invoked by uid 65534); 25 Apr 2004 15:00:41 -0000
Received: from pD950C26D.dip.t-dialin.net (EHLO gmx.de) (217.80.194.109)
  by mail.gmx.net (mp009) with SMTP; 25 Apr 2004 17:00:41 +0200
X-Authenticated: #1915285
Message-ID: <408BD288.8010907@gmx.de>
Date: Sun, 25 Apr 2004 17:00:24 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Webdav WG <w3c-dist-auth@w3c.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS
X-Archived-At: http://www.w3.org/mid/408BD288.8010907@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8477
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040425150119.B961AA1A84@frink.w3.org>
Resent-Date: Sun, 25 Apr 2004 11:01:19 -0400 (EDT)
Content-Transfer-Encoding: 8bit


 From <http://www.webdav.org/wg/rfcdev/issues.htm>:

IF_AND_AUTH: "The fact that use of authentication credentials with 
submission of lock tokens is required should be strengthened in the 
document."

and

LOCK_SEMANTICS: "At present, the WebDAV specification is not 
excruciatingly explicit that writing to a locked resource requires the 
combination of the lock token, plus an authentication principal. At one 
point, the spec. discusses an “authorized” principal, but “authorized” 
is never explicitly defined."

I'd like to confirm that indeed authentication and the ability to use a 
given lock token MAY be orthogonal. That is, a server can

- restrict usage of the lock token to exactly the principal that was 
authenticated when the lock was obtained,

- restrict usage to the creator as above and a group of other principals 
that are allowed to "break" the lock (WebDAV ACL DAV:unlock privilege, 
see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.html#PRIVILEGE_unlock>) 
or

- allow anybody who knows the lock token to use it.

I think right now there are servers implementing each of these schemes, 
and there doesn't seem to be any problem with that.

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Wed Apr 28 12:43:34 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27558
	for <webdav-archive@lists.ietf.org>; Wed, 28 Apr 2004 12:43:32 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 543C8A0C92; Wed, 28 Apr 2004 12:43:34 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 49F3CA1C8B
	for <w3c-dist-auth@listhub.w3.org>; Wed, 28 Apr 2004 12:43:32 -0400 (EDT)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BIs9i-0006Ie-5h
	for w3c-dist-auth@w3c.org; Wed, 28 Apr 2004 12:43:30 -0400
Received: (qmail 29399 invoked by uid 65534); 28 Apr 2004 16:42:59 -0000
Received: from p5082405C.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.64.92)
  by mail.gmx.net (mp017) with SMTP; 28 Apr 2004 18:42:59 +0200
X-Authenticated: #1915285
Message-ID: <408FDF12.3040103@gmx.de>
Date: Wed, 28 Apr 2004 18:42:58 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Webdav WG <w3c-dist-auth@w3c.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Mark Nottingham on "Using WebDAV as a Description Format for REST"
X-Archived-At: http://www.w3.org/mid/408FDF12.3040103@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8478
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040428164334.543C8A0C92@frink.w3.org>
Resent-Date: Wed, 28 Apr 2004 12:43:34 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Interesting read:

<http://www.mnot.net/blog/2004/04/27/webdav4rest>

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Wed Apr 28 14:00:59 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03932
	for <webdav-archive@lists.ietf.org>; Wed, 28 Apr 2004 14:00:59 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id F07ACA08A4; Wed, 28 Apr 2004 14:00:58 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 87CF9A1D8C
	for <w3c-dist-auth@listhub.w3.org>; Wed, 28 Apr 2004 14:00:57 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BItMf-0007Nh-Aa
	for w3c-dist-auth@w3c.org; Wed, 28 Apr 2004 14:00:57 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Received: from [192.168.1.100] ([198.144.201.116])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i3SI08hV016269
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 28 Apr 2004 11:00:11 -0700
In-Reply-To: <408BD288.8010907@gmx.de>
References: <408BD288.8010907@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: multipart/alternative; boundary=Apple-Mail-5--358670451
Message-Id: <EE994F5C-993D-11D8-B566-000A95B2BB72@osafoundation.org>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 28 Apr 2004 11:00:28 -0700
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS
X-Archived-At: http://www.w3.org/mid/EE994F5C-993D-11D8-B566-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8479
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040428180058.F07ACA08A4@frink.w3.org>
Resent-Date: Wed, 28 Apr 2004 14:00:58 -0400 (EDT)



--Apple-Mail-5--358670451
Content-Type: text/plain;
	charset=WINDOWS-1252;
	delsp=yes;
	format=flowed
Content-Transfer-Encoding: quoted-printable


IF_AND_AUTH: This issue was raised by Geoff.
LOCK_SEMANTICS:  This was apparently raised by the DeltaV design team.

Julian, your recommended solution goes counter to the solution =20
recommended by the people who raised these issues, as far as I can =20
tell. Both these issues were raised in order to strengthen the =20
requirement that authentication is required to use a lock =20
token,=A0whereas you suggest loosening that requirement altogether.

So, with conflicting suggestions, we need more discussion and for =20
people to indicate which side they fall on.
  1. Authentication is required for lock token usage but the draft is =20=

clear enough already.
  2. Authentication is required for lock token usage but the draft needs =
=20
clearer text (please suggest where, what text).
  3. Authentication MAY be required for lock token usage (see text =20
below).
  4. Other -- please describe your position.

This is a call for consensus -- I'll respond separately with my own =20
opinion.

For reference, here are the most salient sections of the existing -bis =20=

draft:

section 6.3:
"Having a lock token provides no special access rights. Anyone can find =20=

out anyone else's lock token by performing lock discovery. Locks MUST =20=

be enforced based upon whatever authentication mechanism is used by the =20=

server, not based on the secrecy of the token values."

section 7.6 the "authorized" is re-emphasized:
In order to prevent these collisions a lock token MUST be submitted by =20=

an authorized principal for all locked resources that a method may =20
change or the method MUST fail.

Here's some proposed text to consider adding to section 7.6  if we lean =20=

towards option 3 above (note this would also require changing the text =20=

in the above quoted paragraphs):

Servers MAY restrict usage of the lock token to exactly the =20
authenticated principal who created the lock.  Servers MAY also allow =20=

other privileged authenticated principals or even unauthenticated =20
principals to use the lock token.

Lisa

On Apr 25, 2004, at 8:00 AM, Julian Reschke wrote:

>
> =46rom <http://www.webdav.org/wg/rfcdev/issues.htm>:
>
> IF_AND_AUTH: "The fact that use of authentication credentials with =20
> submission of lock tokens is required should be strengthened in the =20=

> document."
>
> and
>
> LOCK_SEMANTICS: "At present, the WebDAV specification is not =20
> excruciatingly explicit that writing to a locked resource requires the =
=20
> combination of the lock token, plus an authentication principal. At =20=

> one point, the spec. discusses an =93authorized=94 principal, but =20
> =93authorized=94 is never explicitly defined."
>
> I'd like to confirm that indeed authentication and the ability to use =20=

> a given lock token MAY be orthogonal. That is, a server can
>
> - restrict usage of the lock token to exactly the principal that was =20=

> authenticated when the lock was obtained,
>
> - restrict usage to the creator as above and a group of other =20
> principals that are allowed to "break" the lock (WebDAV ACL DAV:unlock =
=20
> privilege, see =20
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-=20
> latest.html#PRIVILEGE_unlock>) or
>
> - allow anybody who knows the lock token to use it.
>
> I think right now there are servers implementing each of these =20
> schemes, and there doesn't seem to be any problem with that.
>
> Regards, Julian
>
> --=20
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>

--Apple-Mail-5--358670451
Content-Type: text/enriched;
	charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable



IF_AND_AUTH: This issue was raised by Geoff.

LOCK_SEMANTICS:  This was apparently raised by the DeltaV design team.


Julian, your recommended solution goes counter to the solution
recommended by the people who raised these issues, as far as I can
tell. Both these issues were raised in order to strengthen the
requirement that authentication is required to use a lock
token,=A0whereas you suggest loosening that requirement altogether.


So, with conflicting suggestions, we need more discussion and for
people to indicate which side they fall on.  =20

 1. Authentication is required for lock token usage but the draft is
clear enough already.

 2. Authentication is required for lock token usage but the draft
needs clearer text (please suggest where, what text).

 3. Authentication MAY be required for lock token usage (see text
below).

 4. Other -- please describe your position.


This is a call for consensus -- I'll respond separately with my own
opinion.=20


For reference, here are the most salient sections of the existing -bis
draft:


section 6.3:

"<fixed><fontfamily><param>Courier New</param><smaller>Having a lock
token provides no special access rights. Anyone can find out anyone
else's lock token by performing lock discovery. Locks MUST be enforced
based upon whatever authentication mechanism is used by the server,
not based on the secrecy of the token =
values."</smaller></fontfamily></fixed>


section 7.6 the "authorized" is re-emphasized:

<fixed><fontfamily><param>Courier New</param><smaller>In order to
prevent these collisions a lock token MUST be submitted by an
authorized principal for all locked resources that a method may change
or the method MUST fail.  </smaller></fontfamily></fixed>


Here's some proposed text to consider adding to section 7.6  if we
lean towards option 3 above (note this would also require changing the
text in the above quoted paragraphs):


<fixed><fontfamily><param>Courier New</param>Servers MAY restrict
usage of the lock token to exactly the authenticated principal who
created the lock.  Servers MAY also allow other privileged
authenticated principals or even unauthenticated principals to use the
lock token. </fontfamily></fixed>


Lisa


On Apr 25, 2004, at 8:00 AM, Julian Reschke wrote:


<excerpt>

=46rom <<http://www.webdav.org/wg/rfcdev/issues.htm>:


IF_AND_AUTH: "The fact that use of authentication credentials with
submission of lock tokens is required should be strengthened in the
document."


and


LOCK_SEMANTICS: "At present, the WebDAV specification is not
excruciatingly explicit that writing to a locked resource requires the
combination of the lock token, plus an authentication principal. At
one point, the spec. discusses an =93authorized=94 principal, but
=93authorized=94 is never explicitly defined."


I'd like to confirm that indeed authentication and the ability to use
a given lock token MAY be orthogonal. That is, a server can


- restrict usage of the lock token to exactly the principal that was
authenticated when the lock was obtained,


- restrict usage to the creator as above and a group of other
principals that are allowed to "break" the lock (WebDAV ACL DAV:unlock
privilege, see
=
<<http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.html#PRIVI=
LEGE_unlock>)
or


- allow anybody who knows the lock token to use it.


I think right now there are servers implementing each of these
schemes, and there doesn't seem to be any problem with that.


Regards, Julian


--=20

<<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760


</excerpt>=

--Apple-Mail-5--358670451--



From w3c-dist-auth-request@w3.org  Wed Apr 28 14:08:20 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04555
	for <webdav-archive@lists.ietf.org>; Wed, 28 Apr 2004 14:08:20 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A9EFCA26B6; Wed, 28 Apr 2004 14:08:20 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id B9F65A26B6
	for <w3c-dist-auth@listhub.w3.org>; Wed, 28 Apr 2004 14:08:19 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BItTX-0000Vl-Hi
	for w3c-dist-auth@w3c.org; Wed, 28 Apr 2004 14:08:03 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Received: from [192.168.1.100] ([198.144.201.116])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i3SI7AhV016761
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 28 Apr 2004 11:07:13 -0700
In-Reply-To: <EE994F5C-993D-11D8-B566-000A95B2BB72@osafoundation.org>
References: <408BD288.8010907@gmx.de> <EE994F5C-993D-11D8-B566-000A95B2BB72@osafoundation.org>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: multipart/alternative; boundary=Apple-Mail-6--358248964
Message-Id: <E9D31D0F-993E-11D8-B566-000A95B2BB72@osafoundation.org>
Cc: Julian Reschke <julian.reschke@gmx.de>, Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 28 Apr 2004 11:07:29 -0700
To: Lisa Dusseault <lisa@osafoundation.org>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS
X-Archived-At: http://www.w3.org/mid/E9D31D0F-993E-11D8-B566-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8480
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040428180820.A9EFCA26B6@frink.w3.org>
Resent-Date: Wed, 28 Apr 2004 14:08:20 -0400 (EDT)



--Apple-Mail-6--358248964
Content-Type: text/plain;
	charset=WINDOWS-1252;
	delsp=yes;
	format=flowed
Content-Transfer-Encoding: quoted-printable

So for the record, I lean towards option 1 (no change) because I can't =20=

recall any interoperability problems in this area.  Without any known =20=

interoperability problems, it seems safest to leave the spec unchanged.

Lisa

On Apr 28, 2004, at 11:00 AM, Lisa Dusseault wrote:

>
> IF_AND_AUTH: This issue was raised by Geoff.
> LOCK_SEMANTICS:  This was apparently raised by the DeltaV design team.
>
> Julian, your recommended solution goes counter to the solution =20
> recommended by the people who raised these issues, as far as I can =20
> tell. Both these issues were raised in order to strengthen the =20
> requirement that authentication is required to use a lock =20
> token,=A0whereas you suggest loosening that requirement altogether.
>
> So, with conflicting suggestions, we need more discussion and for =20
> people to indicate which side they fall on.
>  1. Authentication is required for lock token usage but the draft is =20=

> clear enough already.
>  2. Authentication is required for lock token usage but the draft =20
> needs clearer text (please suggest where, what text).
>  3. Authentication MAY be required for lock token usage (see text =20
> below).
>  4. Other -- please describe your position.
>
> This is a call for consensus -- I'll respond separately with my own =20=

> opinion.
>
> For reference, here are the most salient sections of the existing -bis =
=20
> draft:
>
> section 6.3:
> "Having a lock token provides no special access rights. Anyone can =20
> find out anyone else's lock token by performing lock discovery. Locks =20=

> MUST be enforced based upon whatever authentication mechanism is used =20=

> by the server, not based on the secrecy of the token values."
>
> section 7.6 the "authorized" is re-emphasized:
> In order to prevent these collisions a lock token MUST be submitted by =
=20
> an authorized principal for all locked resources that a method may =20
> change or the method MUST fail.
>
> Here's some proposed text to consider adding to section 7.6  if we =20
> lean towards option 3 above (note this would also require changing the =
=20
> text in the above quoted paragraphs):
>
> Servers MAY restrict usage of the lock token to exactly the =20
> authenticated principal who created the lock.  Servers MAY also allow =20=

> other privileged authenticated principals or even unauthenticated =20
> principals to use the lock token.
>
> Lisa
>
> On Apr 25, 2004, at 8:00 AM, Julian Reschke wrote:
>
>>
>> =46rom <http://www.webdav.org/wg/rfcdev/issues.htm>:
>>
>> IF_AND_AUTH: "The fact that use of authentication credentials with =20=

>> submission of lock tokens is required should be strengthened in the =20=

>> document."
>>
>> and
>>
>> LOCK_SEMANTICS: "At present, the WebDAV specification is not =20
>> excruciatingly explicit that writing to a locked resource requires =20=

>> the combination of the lock token, plus an authentication principal. =20=

>> At one point, the spec. discusses an =93authorized=94 principal, but =20=

>> =93authorized=94 is never explicitly defined."
>>
>> I'd like to confirm that indeed authentication and the ability to use =
=20
>> a given lock token MAY be orthogonal. That is, a server can
>>
>> - restrict usage of the lock token to exactly the principal that was =20=

>> authenticated when the lock was obtained,
>>
>> - restrict usage to the creator as above and a group of other =20
>> principals that are allowed to "break" the lock (WebDAV ACL =20
>> DAV:unlock privilege, see =20
>> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-=20
>> latest.html#PRIVILEGE_unlock>) or
>>
>> - allow anybody who knows the lock token to use it.
>>
>> I think right now there are servers implementing each of these =20
>> schemes, and there doesn't seem to be any problem with that.
>>
>> Regards, Julian
>>
>> --=20
>> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>>

--Apple-Mail-6--358248964
Content-Type: text/enriched;
	charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable

So for the record, I lean towards option 1 (no change) because I can't
recall any interoperability problems in this area.  Without any known
interoperability problems, it seems safest to leave the spec unchanged.


Lisa


On Apr 28, 2004, at 11:00 AM, Lisa Dusseault wrote:


<excerpt>

IF_AND_AUTH: This issue was raised by Geoff.

LOCK_SEMANTICS:  This was apparently raised by the DeltaV design team.


Julian, your recommended solution goes counter to the solution
recommended by the people who raised these issues, as far as I can
tell. Both these issues were raised in order to strengthen the
requirement that authentication is required to use a lock
token,=A0whereas you suggest loosening that requirement altogether.


So, with conflicting suggestions, we need more discussion and for
people to indicate which side they fall on.  =20

 1. Authentication is required for lock token usage but the draft is
clear enough already.

 2. Authentication is required for lock token usage but the draft
needs clearer text (please suggest where, what text).

 3. Authentication MAY be required for lock token usage (see text
below).

 4. Other -- please describe your position.


This is a call for consensus -- I'll respond separately with my own
opinion.=20


For reference, here are the most salient sections of the existing -bis
draft:


section 6.3:

"<fixed><fontfamily><param>Courier New</param><smaller><smaller>Having
a lock token provides no special access rights. Anyone can find out
anyone else's lock token by performing lock discovery. Locks MUST be
enforced based upon whatever authentication mechanism is used by the
server, not based on the secrecy of the token =
values."</smaller></smaller></fontfamily></fixed>


section 7.6 the "authorized" is re-emphasized:

<fixed><fontfamily><param>Courier New</param><smaller><smaller>In
order to prevent these collisions a lock token MUST be submitted by an
authorized principal for all locked resources that a method may change
or the method MUST fail.  </smaller></smaller></fontfamily></fixed>


Here's some proposed text to consider adding to section 7.6  if we
lean towards option 3 above (note this would also require changing the
text in the above quoted paragraphs):


<fixed><fontfamily><param>Courier New</param><smaller>Servers MAY
restrict usage of the lock token to exactly the authenticated
principal who created the lock.  Servers MAY also allow other
privileged authenticated principals or even unauthenticated principals
to use the lock token. </smaller></fontfamily></fixed>


Lisa


On Apr 25, 2004, at 8:00 AM, Julian Reschke wrote:


<excerpt>

=46rom <<http://www.webdav.org/wg/rfcdev/issues.htm>:


IF_AND_AUTH: "The fact that use of authentication credentials with
submission of lock tokens is required should be strengthened in the
document."


and


LOCK_SEMANTICS: "At present, the WebDAV specification is not
excruciatingly explicit that writing to a locked resource requires the
combination of the lock token, plus an authentication principal. At
one point, the spec. discusses an =93authorized=94 principal, but
=93authorized=94 is never explicitly defined."


I'd like to confirm that indeed authentication and the ability to use
a given lock token MAY be orthogonal. That is, a server can


- restrict usage of the lock token to exactly the principal that was
authenticated when the lock was obtained,


- restrict usage to the creator as above and a group of other
principals that are allowed to "break" the lock (WebDAV ACL DAV:unlock
privilege, see
=
<<http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.html#PRIVI=
LEGE_unlock>)
or


- allow anybody who knows the lock token to use it.


I think right now there are servers implementing each of these
schemes, and there doesn't seem to be any problem with that.


Regards, Julian


--=20

<<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760


</excerpt></excerpt>=

--Apple-Mail-6--358248964--



From w3c-dist-auth-request@w3.org  Wed Apr 28 14:24:34 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05619
	for <webdav-archive@lists.ietf.org>; Wed, 28 Apr 2004 14:24:34 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 280B8A2AF1; Wed, 28 Apr 2004 14:24:34 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id BB2EAA2AF1
	for <w3c-dist-auth@listhub.w3.org>; Wed, 28 Apr 2004 14:24:32 -0400 (EDT)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BItjU-0003Xs-I0
	for w3c-dist-auth@w3c.org; Wed, 28 Apr 2004 14:24:32 -0400
Received: (qmail 31194 invoked by uid 65534); 28 Apr 2004 18:23:59 -0000
Received: from pD950C259.dip.t-dialin.net (EHLO gmx.de) (217.80.194.89)
  by mail.gmx.net (mp007) with SMTP; 28 Apr 2004 20:23:59 +0200
X-Authenticated: #1915285
Message-ID: <408FF6B8.3050206@gmx.de>
Date: Wed, 28 Apr 2004 20:23:52 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
References: <408BD288.8010907@gmx.de> <EE994F5C-993D-11D8-B566-000A95B2BB72@osafoundation.org>
In-Reply-To: <EE994F5C-993D-11D8-B566-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS
X-Archived-At: http://www.w3.org/mid/408FF6B8.3050206@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8481
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040428182434.280B8A2AF1@frink.w3.org>
Resent-Date: Wed, 28 Apr 2004 14:24:34 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:
> 
> 
> IF_AND_AUTH: This issue was raised by Geoff.
> LOCK_SEMANTICS: This was apparently raised by the DeltaV design team.
> 
> Julian, your recommended solution goes counter to the solution 
> recommended by the people who raised these issues, as far as I can tell. 
> Both these issues were raised in order to strengthen the requirement 
> that authentication is required to use a lock token, whereas you suggest 
> loosening that requirement altogether.

Correct.

> So, with conflicting suggestions, we need more discussion and for people 
> to indicate which side they fall on.
> 1. Authentication is required for lock token usage but the draft is 
> clear enough already.
> 2. Authentication is required for lock token usage but the draft needs 
> clearer text (please suggest where, what text).
> 3. Authentication MAY be required for lock token usage (see text below).
> 4. Other -- please describe your position.
> 
> This is a call for consensus -- I'll respond separately with my own 
> opinion.
> 
> For reference, here are the most salient sections of the existing -bis 
> draft:
> 
> section 6.3:
> "Having a lock token provides no special access rights. Anyone can find 
> out anyone else's lock token by performing lock discovery. Locks MUST be 
> enforced based upon whatever authentication mechanism is used by the 
> server, not based on the secrecy of the token values."

I agree with this statement in that the server has to ensure that the 
principal submitting the lock token indeed has the "right" to do that. 
However I disagree that locks *must* be tied to an authenticated user.

That requirement IMHO simply doesn't make sense. It would mean that a 
WebDAV server can't offer locking on resources with anonymous access. 
Why would we want to *forbid* that?

> section 7.6 the "authorized" is re-emphasized:
> In order to prevent these collisions a lock token MUST be submitted by 
> an authorized principal for all locked resources that a method may 
> change or the method MUST fail.

Emphasis here (read previous paragraph) is not "authenticated" but 
"submitted".

> Here's some proposed text to consider adding to section 7.6 if we lean 
> towards option 3 above (note this would also require changing the text 
> in the above quoted paragraphs):
> 
> Servers MAY restrict usage of the lock token to exactly the 
> authenticated principal who created the lock. Servers MAY also allow 
> other privileged authenticated principals or even unauthenticated 
> principals to use the lock token.

I think this is what is currently being implemented; and there doesn't 
seem to be any reason to forbid unauthenticated usage of locks. If a 
server chooses to do that, why should that be forbidden?

Generally, locking and authentication are separate concepts. Of course 
servers *can* tie lock ownership to particular principals, but there 
doesn't seem to be a compelling reason to require that.

Maybe Geoff (who raised one of the issues) could explain?


Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Wed Apr 28 14:26:20 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05677
	for <webdav-archive@lists.ietf.org>; Wed, 28 Apr 2004 14:26:20 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id AA243A2B57; Wed, 28 Apr 2004 14:26:20 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id A7231A2A93
	for <w3c-dist-auth@listhub.w3.org>; Wed, 28 Apr 2004 14:26:19 -0400 (EDT)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BItlC-0003kQ-T3
	for w3c-dist-auth@w3c.org; Wed, 28 Apr 2004 14:26:19 -0400
Received: (qmail 11582 invoked by uid 65534); 28 Apr 2004 18:25:41 -0000
Received: from pD950C259.dip.t-dialin.net (EHLO gmx.de) (217.80.194.89)
  by mail.gmx.net (mp014) with SMTP; 28 Apr 2004 20:25:41 +0200
X-Authenticated: #1915285
Message-ID: <408FF715.8070702@gmx.de>
Date: Wed, 28 Apr 2004 20:25:25 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
References: <408BD288.8010907@gmx.de> <EE994F5C-993D-11D8-B566-000A95B2BB72@osafoundation.org> <E9D31D0F-993E-11D8-B566-000A95B2BB72@osafoundation.org>
In-Reply-To: <E9D31D0F-993E-11D8-B566-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS
X-Archived-At: http://www.w3.org/mid/408FF715.8070702@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8482
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040428182620.AA243A2B57@frink.w3.org>
Resent-Date: Wed, 28 Apr 2004 14:26:20 -0400 (EDT)
Content-Transfer-Encoding: 8bit


Lisa Dusseault wrote:

> So for the record, I lean towards option 1 (no change) because I can't 
> recall any interoperability problems in this area. Without any known 
> interoperability problems, it seems safest to leave the spec unchanged.

As there are two open items on the issue list regarding this issue, I'd 
say that the current wording ísn't good enough.

Let's clarify either way (making sure that we don't break existing 
implementations).

Best regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Wed Apr 28 16:15:27 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15129
	for <webdav-archive@lists.ietf.org>; Wed, 28 Apr 2004 16:15:24 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id EE3B6A1419; Wed, 28 Apr 2004 16:15:24 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 68FFEA2487
	for <w3c-dist-auth@listhub.w3.org>; Wed, 28 Apr 2004 16:15:23 -0400 (EDT)
Received: from betlik.darwin.nasa.gov ([198.123.160.11] helo=dream.darwin.nasa.gov)
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BIvSl-0008Su-7X
	for w3c-dist-auth@w3c.org; Wed, 28 Apr 2004 16:15:23 -0400
Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27])
	by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id i3SKF6d22581
	for <w3c-dist-auth@w3c.org>; Wed, 28 Apr 2004 13:15:10 -0700 (PDT)
Message-ID: <409010CA.3010708@cse.ucsc.edu>
Date: Wed, 28 Apr 2004 13:15:06 -0700
From: Elias Sinderson <elias@cse.ucsc.edu>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Webdav WG <w3c-dist-auth@w3c.org>
References: <408BD288.8010907@gmx.de> <EE994F5C-993D-11D8-B566-000A95B2BB72@osafoundation.org>
Content-Type: multipart/alternative;
 boundary="------------020907020208040401030105"
Subject: Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS
X-Archived-At: http://www.w3.org/mid/409010CA.3010708@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8483
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040428201524.EE3B6A1419@frink.w3.org>
Resent-Date: Wed, 28 Apr 2004 16:15:24 -0400 (EDT)



--------------020907020208040401030105
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Lisa Dusseault wrote:

> [...] we need more discussion and for people to indicate which side 
> they fall on.
> 1. Authentication is required for lock token usage but the draft is 
> clear enough already.
> 2. Authentication is required for lock token usage but the draft needs 
> clearer text (please suggest where, what text).
> 3. Authentication MAY be required for lock token usage (see text below).
> 4. Other -- please describe your position.

I've always believed that authentication and lock token usage were 
orthogonal. To add to Julians' example of anonymous authoring of 
resources involving lock tokens, I'd add the following use case. Given a 
locked resource, R, and two principals, P1 and P2, with different access 
priviledges such that P1 can PUT to R, but P2 can only do a PROPPATCH to 
R. This scenario may arise in a content management system where resource 
properties are used to indicate the current state of the resource. It 
seems clear to me from this scenario that the issues of authentication 
(whether by user, group or method) and lock token usage are decoupled.

> [...] Here's some proposed text to consider adding to section 7.6 if 
> we lean towards option 3 above (note this would also require changing 
> the text in the above quoted paragraphs):
>
> Servers MAY restrict usage of the lock token to exactly the 
> authenticated principal who created the lock. Servers MAY also allow 
> other privileged authenticated principals or even unauthenticated 
> principals to use the lock token. 

I agree with the above proposed text, however it may lead to some 
interoperability issues. Is there a proposed mechanism to allow clients 
to discover how a server handles the intersection of these design choices?


Cheers,
Elias

--------------020907020208040401030105
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Lisa Dusseault wrote:<br>
<blockquote type="cite"
 cite="midEE994F5C-993D-11D8-B566-000A95B2BB72@osafoundation.org">[...] we
need more discussion and for people to indicate which side they fall on.
   <br>
 1. Authentication is required for lock token usage but the draft is clear
enough already. <br>
 2. Authentication is required for lock token usage but the draft needs clearer
text (please suggest where, what text). <br>
 3. Authentication MAY be required for lock token usage (see text below). 
  <br>
 4. Other -- please describe your position.</blockquote>
I've always believed that authentication and lock token usage were orthogonal.
To add to Julians' example of anonymous authoring of resources involving
lock tokens, I'd add the following use case. Given a locked resource, R,
and two principals, P1 and P2, with different access priviledges such that
P1 can PUT to R, but P2 can only do a PROPPATCH to R. This scenario may arise
in a content management system where resource properties are used to indicate
the current state of the resource. It seems clear to me from this scenario
that the issues of authentication (whether by user, group or method) and
lock token usage are decoupled.<br>
<blockquote type="cite"
 cite="midEE994F5C-993D-11D8-B566-000A95B2BB72@osafoundation.org">[...] Here's
some proposed text to consider adding to section 7.6  if we lean towards
option 3 above (note this would also require changing the text in the above
quoted paragraphs): <br>
  <br>
  <tt><!-- Courier New -->Servers MAY restrict usage of the lock token to
exactly the authenticated principal who created the lock.  Servers MAY also
allow other privileged authenticated principals or even unauthenticated principals
to use the lock token. </tt> </blockquote>
I agree with the above proposed text, however it may lead to some interoperability
issues. Is there a proposed mechanism to allow clients to discover how a
server handles the intersection of these design choices?<br>
<br>
<br>
Cheers,<br>
Elias<br>
</body>
</html>

--------------020907020208040401030105--



From w3c-dist-auth-request@w3.org  Wed Apr 28 16:56:47 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19772
	for <webdav-archive@lists.ietf.org>; Wed, 28 Apr 2004 16:56:47 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 02155A28E5; Wed, 28 Apr 2004 16:56:47 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 3B982A28E5
	for <w3c-dist-auth@listhub.w3.org>; Wed, 28 Apr 2004 16:56:44 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BIw6l-00005k-UJ
	for w3c-dist-auth@w3c.org; Wed, 28 Apr 2004 16:56:44 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Received: from [192.168.1.100] ([198.144.201.116])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i3SKuDhV028111
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 28 Apr 2004 13:56:16 -0700
In-Reply-To: <409010CA.3010708@cse.ucsc.edu>
References: <408BD288.8010907@gmx.de> <EE994F5C-993D-11D8-B566-000A95B2BB72@osafoundation.org> <409010CA.3010708@cse.ucsc.edu>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <8860BE92-9956-11D8-B566-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 28 Apr 2004 13:56:34 -0700
To: Elias Sinderson <elias@cse.ucsc.edu>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS
X-Archived-At: http://www.w3.org/mid/8860BE92-9956-11D8-B566-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8484
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040428205647.02155A28E5@frink.w3.org>
Resent-Date: Wed, 28 Apr 2004 16:56:47 -0400 (EDT)
Content-Transfer-Encoding: 7bit


But how can clients discover if servers allow any authenticated user 
(other than the one that got the lock)?  Without servers advertising 
this toggle, it seems very unlikely that clients will use it as they 
cannot rely on it.  Unless of course the client is talking to a server 
by the same vendor in which case there may be other non-standard 
behaviors that the standard has no business describing.

So yeah, it might be desirable but it's not a slam dunk.

lisa

On Apr 28, 2004, at 1:15 PM, Elias Sinderson wrote:

> Lisa Dusseault wrote:
>
>> [...] we need more discussion and for people to indicate which side 
>> they fall on.
>> 1. Authentication is required for lock token usage but the draft is 
>> clear enough already.
>> 2. Authentication is required for lock token usage but the draft 
>> needs clearer text (please suggest where, what text).
>> 3. Authentication MAY be required for lock token usage (see text 
>> below).
>> 4. Other -- please describe your position.
>
> I've always believed that authentication and lock token usage were 
> orthogonal. To add to Julians' example of anonymous authoring of 
> resources involving lock tokens, I'd add the following use case. Given 
> a locked resource, R, and two principals, P1 and P2, with different 
> access priviledges such that P1 can PUT to R, but P2 can only do a 
> PROPPATCH to R. This scenario may arise in a content management system 
> where resource properties are used to indicate the current state of 
> the resource. It seems clear to me from this scenario that the issues 
> of authentication (whether by user, group or method) and lock token 
> usage are decoupled.
>
>> [...] Here's some proposed text to consider adding to section 7.6 if 
>> we lean towards option 3 above (note this would also require changing 
>> the text in the above quoted paragraphs):
>>
>> Servers MAY restrict usage of the lock token to exactly the 
>> authenticated principal who created the lock. Servers MAY also allow 
>> other privileged authenticated principals or even unauthenticated 
>> principals to use the lock token.
>
> I agree with the above proposed text, however it may lead to some 
> interoperability issues. Is there a proposed mechanism to allow 
> clients to discover how a server handles the intersection of these 
> design choices?
>
>
> Cheers,
> Elias



From w3c-dist-auth-request@w3.org  Wed Apr 28 17:06:41 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20551
	for <webdav-archive@lists.ietf.org>; Wed, 28 Apr 2004 17:06:41 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id D2FC5A0FBB; Wed, 28 Apr 2004 17:06:42 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 96205A063D
	for <w3c-dist-auth@listhub.w3.org>; Wed, 28 Apr 2004 17:06:39 -0400 (EDT)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BIwGN-0001Bv-9b
	for w3c-dist-auth@w3c.org; Wed, 28 Apr 2004 17:06:39 -0400
Received: (qmail 14133 invoked by uid 65534); 28 Apr 2004 21:06:07 -0000
Received: from pD950C259.dip.t-dialin.net (EHLO gmx.de) (217.80.194.89)
  by mail.gmx.net (mp018) with SMTP; 28 Apr 2004 23:06:07 +0200
X-Authenticated: #1915285
Message-ID: <40901CB0.1040208@gmx.de>
Date: Wed, 28 Apr 2004 23:05:52 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Elias Sinderson <elias@cse.ucsc.edu>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
References: <408BD288.8010907@gmx.de> <EE994F5C-993D-11D8-B566-000A95B2BB72@osafoundation.org> <409010CA.3010708@cse.ucsc.edu>
In-Reply-To: <409010CA.3010708@cse.ucsc.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS
X-Archived-At: http://www.w3.org/mid/40901CB0.1040208@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8485
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040428210642.D2FC5A0FBB@frink.w3.org>
Resent-Date: Wed, 28 Apr 2004 17:06:42 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Elias Sinderson wrote:
> ...
> I agree with the above proposed text, however it may lead to some 
> interoperability issues. Is there a proposed mechanism to allow clients 
> to discover how a server handles the intersection of these design choices?

I'm not sure we need that kind of discovery. Keep in mind that we're 
talking of an exceptional edge case where somebody "steals" a lock that 
was created by somebody else. We don't need to make that simple. Trying 
and seeing the outcome should be ok.

Or am I missing a more regular use case?

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Wed Apr 28 17:24:31 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23385
	for <webdav-archive@lists.ietf.org>; Wed, 28 Apr 2004 17:24:31 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A0085A2B18; Wed, 28 Apr 2004 17:24:32 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id EE6C8A2B18
	for <w3c-dist-auth@listhub.w3.org>; Wed, 28 Apr 2004 17:24:30 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BIwXe-0004Kh-Qf
	for w3c-dist-auth@w3c.org; Wed, 28 Apr 2004 17:24:31 -0400
Old-X-Envelope-From: lisa@xythos.com
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Received: from [192.168.1.100] ([198.144.201.116])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i3SLNehV030018
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 28 Apr 2004 14:23:45 -0700
In-Reply-To: <40901CB0.1040208@gmx.de>
References: <408BD288.8010907@gmx.de> <EE994F5C-993D-11D8-B566-000A95B2BB72@osafoundation.org> <409010CA.3010708@cse.ucsc.edu> <40901CB0.1040208@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <5DDCFA2A-995A-11D8-B566-000A95B2BB72@xythos.com>
Content-Transfer-Encoding: 7bit
Cc: Elias Sinderson <elias@cse.ucsc.edu>, Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@xythos.com>
Date: Wed, 28 Apr 2004 14:24:00 -0700
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS
X-Archived-At: http://www.w3.org/mid/5DDCFA2A-995A-11D8-B566-000A95B2BB72@xythos.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8486
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040428212432.A0085A2B18@frink.w3.org>
Resent-Date: Wed, 28 Apr 2004 17:24:32 -0400 (EDT)
Content-Transfer-Encoding: 7bit


So far we've only considered lock "stealing" for the purpose of 
destroying a lock (e.g. if somebody locked a file and went on 
vacation).  If I steal somebody else's lock to use it and change the 
file while still leaving it under the same lock there *will* be 
interoperability problems because there's no way to coordinate.

Going from that limited UNLOCK use case to a more general content 
management use case, where multiple people might use the locked 
resource is a big step and we don't have a lot of experience (that I 
know of).  Recall that shared locks were invented for the latter case, 
not exclusive lock token sharing.

Lisa

On Apr 28, 2004, at 2:05 PM, Julian Reschke wrote:

>
> Elias Sinderson wrote:
>> ...
>> I agree with the above proposed text, however it may lead to some 
>> interoperability issues. Is there a proposed mechanism to allow 
>> clients to discover how a server handles the intersection of these 
>> design choices?
>
> I'm not sure we need that kind of discovery. Keep in mind that we're 
> talking of an exceptional edge case where somebody "steals" a lock 
> that was created by somebody else. We don't need to make that simple. 
> Trying and seeing the outcome should be ok.
>
> Or am I missing a more regular use case?
>
> Regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Wed Apr 28 17:37:45 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24941
	for <webdav-archive@lists.ietf.org>; Wed, 28 Apr 2004 17:37:45 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 1C935A236A; Wed, 28 Apr 2004 17:37:46 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 524F8A2B96
	for <w3c-dist-auth@listhub.w3.org>; Wed, 28 Apr 2004 17:37:45 -0400 (EDT)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BIwkH-00060F-1N
	for w3c-dist-auth@w3c.org; Wed, 28 Apr 2004 17:37:33 -0400
Received: (qmail 21922 invoked by uid 65534); 28 Apr 2004 21:36:57 -0000
Received: from pD950C259.dip.t-dialin.net (EHLO gmx.de) (217.80.194.89)
  by mail.gmx.net (mp003) with SMTP; 28 Apr 2004 23:36:57 +0200
X-Authenticated: #1915285
Message-ID: <409023F0.9000508@gmx.de>
Date: Wed, 28 Apr 2004 23:36:48 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@xythos.com>
Cc: Elias Sinderson <elias@cse.ucsc.edu>, Webdav WG <w3c-dist-auth@w3c.org>
References: <408BD288.8010907@gmx.de> <EE994F5C-993D-11D8-B566-000A95B2BB72@osafoundation.org> <409010CA.3010708@cse.ucsc.edu> <40901CB0.1040208@gmx.de> <5DDCFA2A-995A-11D8-B566-000A95B2BB72@xythos.com>
In-Reply-To: <5DDCFA2A-995A-11D8-B566-000A95B2BB72@xythos.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS
X-Archived-At: http://www.w3.org/mid/409023F0.9000508@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8487
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040428213746.1C935A236A@frink.w3.org>
Resent-Date: Wed, 28 Apr 2004 17:37:46 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> So far we've only considered lock "stealing" for the purpose of 
> destroying a lock (e.g. if somebody locked a file and went on 
> vacation).  If I steal somebody else's lock to use it and change the 
> file while still leaving it under the same lock there *will* be 
> interoperability problems because there's no way to coordinate.
> 
> Going from that limited UNLOCK use case to a more general content 
> management use case, where multiple people might use the locked resource 
> is a big step and we don't have a lot of experience (that I know of).  
> Recall that shared locks were invented for the latter case, not 
> exclusive lock token sharing.

I c. I absolutely agree that using somebody else's lock token to get rid 
of the lock (did the other forget to unlock before leaving for the 
weekend?) is a completely different use case then *using* the lock token 
in methods other than UNLOCK (that is, in the "If" header). *That* is 
something we may want to clarify.

That still leaves the use case of a public resource that supports locks. 
I think this is allowed today, and actually is in use. We should not 
forbid that.

So maybe we should close the two issues mentioned, and add a new one 
specifically for this question?

 From my point of view:

- There are no restrictions on who a server allows to UNLOCK using a 
"stolen" lock token. It MAY restrict it to the "owner" of the lock, to 
the owner and principals holding the DAV:unlock privilege, or not 
restrict it at all. In particular, there's no requirement that for each 
lock token there actually *is* an "authenticated owner" (unless you 
count the ACL specs's "DAV:unauthenticated").

- On the other hand, submitting the lock token in an If header (usages 
!= UNLOCK) SHOULD be restricted to whatever the server thinks the 
"owner" of the lock is.

Does this make sense?

Regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Wed Apr 28 17:44:10 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25310
	for <webdav-archive@lists.ietf.org>; Wed, 28 Apr 2004 17:44:10 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 3C837A19EE; Wed, 28 Apr 2004 17:44:12 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id C7EC4A19EE
	for <w3c-dist-auth@listhub.w3.org>; Wed, 28 Apr 2004 17:44:10 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BIwqg-0007fS-Fc
	for w3c-dist-auth@w3c.org; Wed, 28 Apr 2004 17:44:10 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Received: from [192.168.1.100] ([198.144.201.116])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i3SLh8hV032585
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 28 Apr 2004 14:43:11 -0700
In-Reply-To: <409023F0.9000508@gmx.de>
References: <408BD288.8010907@gmx.de> <EE994F5C-993D-11D8-B566-000A95B2BB72@osafoundation.org> <409010CA.3010708@cse.ucsc.edu> <40901CB0.1040208@gmx.de> <5DDCFA2A-995A-11D8-B566-000A95B2BB72@xythos.com> <409023F0.9000508@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <161AA397-995D-11D8-B566-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: Elias Sinderson <elias@cse.ucsc.edu>, Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 28 Apr 2004 14:43:28 -0700
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS
X-Archived-At: http://www.w3.org/mid/161AA397-995D-11D8-B566-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8488
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040428214412.3C837A19EE@frink.w3.org>
Resent-Date: Wed, 28 Apr 2004 17:44:12 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Yes, I think that makes sense.

On Apr 28, 2004, at 2:36 PM, Julian Reschke wrote:

>
> Lisa Dusseault wrote:
>
>> So far we've only considered lock "stealing" for the purpose of 
>> destroying a lock (e.g. if somebody locked a file and went on 
>> vacation).  If I steal somebody else's lock to use it and change the 
>> file while still leaving it under the same lock there *will* be 
>> interoperability problems because there's no way to coordinate.
>> Going from that limited UNLOCK use case to a more general content 
>> management use case, where multiple people might use the locked 
>> resource is a big step and we don't have a lot of experience (that I 
>> know of).  Recall that shared locks were invented for the latter 
>> case, not exclusive lock token sharing.
>
> I c. I absolutely agree that using somebody else's lock token to get 
> rid of the lock (did the other forget to unlock before leaving for the 
> weekend?) is a completely different use case then *using* the lock 
> token in methods other than UNLOCK (that is, in the "If" header). 
> *That* is something we may want to clarify.
>
> That still leaves the use case of a public resource that supports 
> locks. I think this is allowed today, and actually is in use. We 
> should not forbid that.
>
> So maybe we should close the two issues mentioned, and add a new one 
> specifically for this question?
>
> From my point of view:
>
> - There are no restrictions on who a server allows to UNLOCK using a 
> "stolen" lock token. It MAY restrict it to the "owner" of the lock, to 
> the owner and principals holding the DAV:unlock privilege, or not 
> restrict it at all. In particular, there's no requirement that for 
> each lock token there actually *is* an "authenticated owner" (unless 
> you count the ACL specs's "DAV:unauthenticated").
>
> - On the other hand, submitting the lock token in an If header (usages 
> != UNLOCK) SHOULD be restricted to whatever the server thinks the 
> "owner" of the lock is.
>
> Does this make sense?
>
> Regards, Julian
>
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Wed Apr 28 20:07:16 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06003
	for <webdav-archive@lists.ietf.org>; Wed, 28 Apr 2004 20:07:13 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 8CAA2A0FC1; Wed, 28 Apr 2004 20:07:13 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 5813BA0FFB
	for <w3c-dist-auth@listhub.w3.org>; Wed, 28 Apr 2004 20:06:51 -0400 (EDT)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BIysU-0003fp-8f
	for w3c-dist-auth@w3c.org; Wed, 28 Apr 2004 19:54:10 -0400
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i3SNs6ag000919 sender ccjason@us.ibm.com for w3c-dist-auth@w3c.org; Wed, 28 Apr 2004 16:54:06 -0700
Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by bandage.seagull.net (8.12.10) with ESMTP id i3SNrt7j000595 sender ccjason@us.ibm.com; Wed, 28 Apr 2004 16:53:56 -0700
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3SNrifQ089936; Wed, 28 Apr 2004 19:53:44 -0400
Received: from d01ml604.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3SNsC6h086520; Wed, 28 Apr 2004 19:54:13 -0400
To: Webdav WG <nnw3c-dist-auth___at___w3c.org@smallcue.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Jason Crawford <ccjason@us.ibm.com>
Message-ID: <OF8D84B3C3.20C730AA-ON85256E84.00820E8B-85256E84.00833F85@us.ibm.com>
Date: Wed, 28 Apr 2004 19:53:35 -0400
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF141 | April 6, 2004) at 04/28/2004 19:53:43, Serialize complete at 04/28/2004 19:53:43
Content-Type: multipart/alternative; boundary="=_alternative 0082E3F285256E84_="
Subject: Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS
X-Archived-At: http://www.w3.org/mid/OF8D84B3C3.20C730AA-ON85256E84.00820E8B-85256E84.00833F85@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8489
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040429000713.8CAA2A0FC1@frink.w3.org>
Resent-Date: Wed, 28 Apr 2004 20:07:13 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 0082E3F285256E84_=
Content-Type: text/plain; charset="us-ascii"

> > From my point of view:
> >
> > - There are no restrictions on who a server allows to UNLOCK using a
> > "stolen" lock token. It MAY restrict it to the "owner" of the lock, to
> > the owner and principals holding the DAV:unlock privilege, or not
> > restrict it at all. In particular, there's no requirement that for
> > each lock token there actually *is* an "authenticated owner" (unless
> > you count the ACL specs's "DAV:unauthenticated").
> >
> > - On the other hand, submitting the lock token in an If header (usages
> > != UNLOCK) SHOULD be restricted to whatever the server thinks the
> > "owner" of the lock is.
> >
> > Does this make sense?

I began writing this note intending to suggest that we at least encourage 
some checking of the principal, but after further reflection, I think 
simply mentioning the options as you just did should be sufficient.  It 
should be clear to the reader that there are benefits to making the checks 
without us pushing for that.

J.
--=_alternative 0082E3F285256E84_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">&gt; &gt; From my point of view:<br>
&gt; &gt;<br>
&gt; &gt; - There are no restrictions on who a server allows to UNLOCK using a<br>
&gt; &gt; &quot;stolen&quot; lock token. It MAY restrict it to the &quot;owner&quot; of the lock, to<br>
&gt; &gt; the owner and principals holding the DAV:unlock privilege, or not<br>
&gt; &gt; restrict it at all. In particular, there's no requirement that for<br>
&gt; &gt; each lock token there actually *is* an &quot;authenticated owner&quot; (unless<br>
&gt; &gt; you count the ACL specs's &quot;DAV:unauthenticated&quot;).<br>
&gt; &gt;<br>
&gt; &gt; - On the other hand, submitting the lock token in an If header (usages<br>
&gt; &gt; != UNLOCK) SHOULD be restricted to whatever the server thinks the<br>
&gt; &gt; &quot;owner&quot; of the lock is.<br>
&gt; &gt;<br>
&gt; &gt; Does this make sense?</font>
<br>
<br><font size=2 face="sans-serif">I began writing this note intending to suggest that we at least encourage some checking of the principal, but after further reflection, I think simply mentioning the options as you just did should be sufficient. &nbsp;It should be clear to the reader that there are benefits to making the checks without us pushing for that.</font>
<br>
<br><font size=2 face="sans-serif">J.</font>
--=_alternative 0082E3F285256E84_=--



From w3c-dist-auth-request@w3.org  Fri Apr 30 14:35:09 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21131
	for <webdav-archive@lists.ietf.org>; Fri, 30 Apr 2004 14:35:09 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 823A0A2569; Fri, 30 Apr 2004 14:35:07 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id DA5A4A2569
	for <w3c-dist-auth@listhub.w3.org>; Fri, 30 Apr 2004 14:35:05 -0400 (EDT)
Received: from numenor.qualcomm.com ([129.46.51.58])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BJcqb-00075s-N5
	for w3c-dist-auth@w3c.org; Fri, 30 Apr 2004 14:34:53 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i3UIYIV2022799
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <w3c-dist-auth@w3c.org>; Fri, 30 Apr 2004 11:34:18 -0700 (PDT)
Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161])
	by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i3UIYGrZ022562
	for <w3c-dist-auth@w3c.org>; Fri, 30 Apr 2004 11:34:17 -0700 (PDT)
Mime-Version: 1.0
X-Sender: hardie@mage.qualcomm.com
Message-Id: <p06100502bcb84c541dcf@[129.46.227.161]>
Date: Fri, 30 Apr 2004 11:34:15 -0700
To: w3c-dist-auth@w3c.org
From: Ted Hardie <hardie@qualcomm.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: HTTP sasl draft in last call
X-Archived-At: http://www.w3.org/mid/p06100502bcb84c541dcf@%5B129.46.227.161%5D
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8490
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040430183507.823A0A2569@frink.w3.org>
Resent-Date: Fri, 30 Apr 2004 14:35:07 -0400 (EDT)


http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-11.txt

is currently in last call; working group members may wish to review
it, as it specifies HTTP status codes and SASL mechanisms which may
be relevant to the work of WEBDAV.
			regards,
				Ted Hardie



From w3c-dist-auth-request@w3.org  Fri Apr 30 18:48:02 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11045
	for <webdav-archive@lists.ietf.org>; Fri, 30 Apr 2004 18:48:02 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id BD89DA0CE9; Fri, 30 Apr 2004 18:48:04 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 28469A0CE9
	for <w3c-dist-auth@listhub.w3.org>; Fri, 30 Apr 2004 18:48:03 -0400 (EDT)
Received: from mta06-svc.ntlworld.com ([62.253.162.46])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BJgna-0000kN-Sl
	for w3c-dist-auth@w3c.org; Fri, 30 Apr 2004 18:48:03 -0400
Received: from manyfish.co.uk ([62.253.142.183]) by mta06-svc.ntlworld.com
          (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP
          id <20040430224737.EKEL21150.mta06-svc.ntlworld.com@manyfish.co.uk>;
          Fri, 30 Apr 2004 23:47:37 +0100
Received: from monolith.fishnet (localhost.localdomain [127.0.0.1])
	by manyfish.co.uk (8.12.10/8.12.5) with ESMTP id i3UMlVNv032093;
	Fri, 30 Apr 2004 23:47:31 +0100
Received: (from joe@localhost)
	by monolith.fishnet (8.12.10/8.12.10/Submit) id i3UMlTTU032092;
	Fri, 30 Apr 2004 23:47:29 +0100
Date: Fri, 30 Apr 2004 23:47:29 +0100
From: Joe Orton <joe@manyfish.co.uk>
To: Ted Hardie <hardie@qualcomm.com>
Cc: w3c-dist-auth@w3c.org
Message-ID: <20040430224729.GA31789@manyfish.co.uk>
Mail-Followup-To: Ted Hardie <hardie@qualcomm.com>,
	w3c-dist-auth@w3c.org
References: <p06100502bcb84c541dcf@[129.46.227.161]>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <p06100502bcb84c541dcf@[129.46.227.161]>
User-Agent: Mutt/1.4.1i
Subject: Re: HTTP sasl draft in last call
X-Archived-At: http://www.w3.org/mid/20040430224729.GA31789@manyfish.co.uk
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8491
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040430224804.BD89DA0CE9@frink.w3.org>
Resent-Date: Fri, 30 Apr 2004 18:48:04 -0400 (EDT)


On Fri, Apr 30, 2004 at 11:34:15AM -0700, Ted Hardie wrote:
> http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-11.txt
> 
> is currently in last call; working group members may wish to review
> it, as it specifies HTTP status codes and SASL mechanisms which may
> be relevant to the work of WEBDAV.

The last call is "aarrgggh".... well, how about removing "HTTP/1.1" from
the title so this spec isn't confused with a real HTTP/1.1
authentication scheme?

What are these new 235/236 status codes for?  They seem to be entirely
redundant.  Trying to redefine OPTIONS is still not going to work,
neither is the CONNECT-to-port-80 stuff, etc etc as per previous
reviews.

joe



From w3c-dist-auth-request@w3.org  Fri Apr 30 19:24:03 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12802
	for <webdav-archive@lists.ietf.org>; Fri, 30 Apr 2004 19:24:03 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 7C4E6A09CA; Fri, 30 Apr 2004 19:24:04 -0400 (EDT)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 45E44A0EAF
	for <w3c-dist-auth@listhub.w3.org>; Fri, 30 Apr 2004 19:24:02 -0400 (EDT)
Received: from numenor.qualcomm.com ([129.46.51.58])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BJhMQ-0007QT-4E
	for w3c-dist-auth@w3c.org; Fri, 30 Apr 2004 19:24:02 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i3UNNPV2013382
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 30 Apr 2004 16:23:25 -0700 (PDT)
Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161])
	by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i3UNNLvB019174;
	Fri, 30 Apr 2004 16:23:22 -0700 (PDT)
Mime-Version: 1.0
X-Sender: hardie@mage.qualcomm.com
Message-Id: <p0610050abcb8904591b7@[129.46.227.161]>
In-Reply-To: <20040430224729.GA31789@manyfish.co.uk>
References: <p06100502bcb84c541dcf@[129.46.227.161]>
 <20040430224729.GA31789@manyfish.co.uk>
Date: Fri, 30 Apr 2004 16:23:20 -0700
To: Joe Orton <joe@manyfish.co.uk>
From: Ted Hardie <hardie@qualcomm.com>
Cc: w3c-dist-auth@w3c.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: Re: HTTP sasl draft in last call
X-Archived-At: http://www.w3.org/mid/p0610050abcb8904591b7@%5B129.46.227.161%5D
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8492
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040430232404.7C4E6A09CA@frink.w3.org>
Resent-Date: Fri, 30 Apr 2004 19:24:04 -0400 (EDT)


Hi Joe,
	Can you send your last call comments to the IESG,
so they can be considered with the draft?
			thanks,
				Ted



At 11:47 PM +0100 04/30/2004, Joe Orton wrote:
>On Fri, Apr 30, 2004 at 11:34:15AM -0700, Ted Hardie wrote:
>>  http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-11.txt
>>
>>  is currently in last call; working group members may wish to review
>>  it, as it specifies HTTP status codes and SASL mechanisms which may
>>  be relevant to the work of WEBDAV.
>
>The last call is "aarrgggh".... well, how about removing "HTTP/1.1" from
>the title so this spec isn't confused with a real HTTP/1.1
>authentication scheme?
>
>What are these new 235/236 status codes for?  They seem to be entirely
>redundant.  Trying to redefine OPTIONS is still not going to work,
>neither is the CONNECT-to-port-80 stuff, etc etc as per previous
>reviews.
>
>joe