From w3c-dist-auth-request@w3.org  Sun May  2 06:11: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 GAA08270
	for <webdav-archive@lists.ietf.org>; Sun, 2 May 2004 06:11:52 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 8E6CEA2222; Sun,  2 May 2004 06:11: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 A5BCBA2222
	for <w3c-dist-auth@listhub.w3.org>; Sun,  2 May 2004 06:11:49 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BKDwq-000861-Vj
	for w3c-dist-auth@w3c.org; Sun, 02 May 2004 06:11:49 -0400
Received: (qmail 31125 invoked by uid 65534); 2 May 2004 10:11:14 -0000
Received: from p3EE24736.dip.t-dialin.net (EHLO gmx.de) (62.226.71.54)
  by mail.gmx.net (mp026) with SMTP; 02 May 2004 12:11:14 +0200
X-Authenticated: #1915285
Message-ID: <4094C93C.4050403@gmx.de>
Date: Sun, 02 May 2004 12:11:08 +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
References: <40766BFD.7000404@gmx.de>
In-Reply-To: <40766BFD.7000404@gmx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: summary of BIND/RFC2518 status
X-Archived-At: http://www.w3.org/mid/4094C93C.4050403@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8493
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: <20040502101151.8E6CEA2222@frink.w3.org>
Resent-Date: Sun,  2 May 2004 06:11:51 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi all.

Three weeks ago, I have tried to summarize this dicussion in the 
following mail...:

<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0049.html>

Unfortunately, there hasn't been any feedback at all. I'd like to think 
that this means that everybody agrees, but realistically it probably 
means that people are either getting tired of this discussion (no new 
arguments), or for reasons unclear to me prefer the WG not to make any 
progress at all.

Geoff and I have volunteered to author a standalone WebDAV Locking 
specification, and I haven't seen any other proposal that would both 
resolve the current situation and have people volunteering to implement it.

Unless people can think of new arguments, I'd propose that the WG simply 
votes on the issue. To restate our proposal:

1) We will *not* add locking discussion to BIND (in fact, we may want to 
remove some locking-specific preconditions).

2) We'll extract all parts relevant to Locking from RFC2518, integrate 
GULP and resolve all locking related issues from the RF2518 issues list, 
  and publish this as a separate LOCKING document (starting as Proposed 
standard updating RFC2518).

3) As a consequence, the authors of RFC2518bis should remove the locking 
part of the specification (once both RFC2518bis becomes a Draft standard 
and LOCKING is a Proposed standard, it will be relatively simple to 
advance LOCKING as well).

4) draft-ietf-webdav-bind-05 as published can be wg-last-called after 
possibly referencing the LOCKING spec.


<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html> 
  currently is a simple container of all stuff that would go into the 
LOCKING spec (RFC2518 parts, open issues, GULP). 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-base-latest.html> 
is an experimental edit of RFC2518 demonstrating the effects of removing 
  Locking from the protocol.

Feedback appreciated.

Best regards, Julian


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



From w3c-dist-auth-request@w3.org  Sun May  2 09:17:52 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 JAA13358
	for <webdav-archive@lists.ietf.org>; Sun, 2 May 2004 09:17:50 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 8DA5FA0B0E; Sun,  2 May 2004 09:17: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 E1C28A0C19
	for <w3c-dist-auth@listhub.w3.org>; Sun,  2 May 2004 09:17:43 -0400 (EDT)
Received: from conure.mail.pas.earthlink.net ([207.217.120.54])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BKGql-0002zK-D4
	for w3c-dist-auth@w3c.org; Sun, 02 May 2004 09:17:43 -0400
Received: from user-11fa7jt.dsl.mindspring.com ([66.245.30.125] helo=[192.168.1.10])
	by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 1BKGqh-0002Fh-00
	for w3c-dist-auth@w3c.org; Sun, 02 May 2004 06:17:40 -0700
Mime-Version: 1.0 (Apple Message framework v613)
In-Reply-To: <4094C93C.4050403@gmx.de>
References: <40766BFD.7000404@gmx.de> <4094C93C.4050403@gmx.de>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <EBC75C22-9C3A-11D8-800F-000A95B03262@icx.net>
Content-Transfer-Encoding: 7bit
From: John DeSoi <jd@icx.net>
Date: Sun, 2 May 2004 09:16:28 -0400
To: w3c-dist-auth@w3c.org
X-Mailer: Apple Mail (2.613)
Subject: Re: summary of BIND/RFC2518 status
X-Archived-At: http://www.w3.org/mid/EBC75C22-9C3A-11D8-800F-000A95B03262@icx.net
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8494
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: <20040502131748.8DA5FA0B0E@frink.w3.org>
Resent-Date: Sun,  2 May 2004 09:17:48 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Julian,

Great approach in my opinion. Locking is by far the worst thing about 
implementing WebDAV. I had no plans at all to implement it since my 
WebDAV back end already supporting all of the locking features I 
needed. But I was forced to implement it because some WebDAV clients 
(e.g. MacOS X) won't allow any writes unless locking is implemented.

Thanks for your work on this.

John DeSoi, Ph.D.



On May 2, 2004, at 6:11 AM, Julian Reschke wrote:

> Unless people can think of new arguments, I'd propose that the WG 
> simply votes on the issue. To restate our proposal:
>
> 1) We will *not* add locking discussion to BIND (in fact, we may want 
> to remove some locking-specific preconditions).
>
> 2) We'll extract all parts relevant to Locking from RFC2518, integrate 
> GULP and resolve all locking related issues from the RF2518 issues 
> list,  and publish this as a separate LOCKING document (starting as 
> Proposed standard updating RFC2518).
>
> 3) As a consequence, the authors of RFC2518bis should remove the 
> locking part of the specification (once both RFC2518bis becomes a 
> Draft standard and LOCKING is a Proposed standard, it will be 
> relatively simple to advance LOCKING as well).
>
> 4) draft-ietf-webdav-bind-05 as published can be wg-last-called after 
> possibly referencing the LOCKING spec.



From w3c-dist-auth-request@w3.org  Sun May  2 16:31: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 QAA02090
	for <webdav-archive@lists.ietf.org>; Sun, 2 May 2004 16:31:21 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 55AC8A1CC1; Sun,  2 May 2004 16:31: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 6EEFEA17A3
	for <w3c-dist-auth@listhub.w3.org>; Sun,  2 May 2004 16:31:18 -0400 (EDT)
Received: from natsmtp00.rzone.de ([81.169.145.165])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BKNcM-000732-3B
	for w3c-dist-auth@w3c.org; Sun, 02 May 2004 16:31:18 -0400
Received: from x.oberon.ethz.ch (p5083D867.dip0.t-ipconnect.de [80.131.216.103])
	by post.webmailer.de (8.12.10/8.12.10) with SMTP id i42KV0xu003855;
	Sun, 2 May 2004 22:31:00 +0200 (MEST)
Date: Sun, 2 May 2004 22:31:00 +0200 (MEST)
Message-Id: <200405022031.i42KV0xu003855@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): summary of BIND/RFC2518 status
X-Archived-At: http://www.w3.org/mid/200405022031.i42KV0xu003855@post.webmailer.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8495
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: <20040502203121.55AC8A1CC1@frink.w3.org>
Resent-Date: Sun,  2 May 2004 16:31:21 -0400 (EDT)


Julian Reschke <julian.reschke@gmx.de> wrote:
> Geoff and I have volunteered to author a standalone WebDAV Locking 
> specification
Thanks, please do it.

> Unless people can think of new arguments, I'd propose that the WG simply 
> votes on the issue. To restate our proposal:
> 1) We will *not* add locking discussion to BIND (in fact, we may want to 
> remove some locking-specific preconditions).
> 2) We'll extract all parts relevant to Locking from RFC2518, integrate 
> GULP and resolve all locking related issues from the RF2518 issues list, 
>   and publish this as a separate LOCKING document (starting as Proposed 
> standard updating RFC2518).
> 3) As a consequence, the authors of RFC2518bis should remove the locking 
> part of the specification (once both RFC2518bis becomes a Draft standard 
> and LOCKING is a Proposed standard, it will be relatively simple to 
> advance LOCKING as well).
> 4) draft-ietf-webdav-bind-05 as published can be wg-last-called after 
> possibly referencing the LOCKING spec.
+ 1

Cheers, Edgar



From w3c-dist-auth-request@w3.org  Sun May  2 16:37: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 QAA02345
	for <webdav-archive@lists.ietf.org>; Sun, 2 May 2004 16:37:37 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 78A1FA1FA6; Sun,  2 May 2004 16:37:39 -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 6CFD9A1FB9
	for <w3c-dist-auth@listhub.w3.org>; Sun,  2 May 2004 16:37:36 -0400 (EDT)
Received: from e2.ny.us.ibm.com ([32.97.182.102])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BKNiB-0007Um-B1
	for w3c-dist-auth@w3c.org; Sun, 02 May 2004 16:37:19 -0400
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i42KamiJ464464
	for <w3c-dist-auth@w3c.org>; Sun, 2 May 2004 16:36:48 -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 i42KbIdx064200
	for <w3c-dist-auth@w3c.org>; Sun, 2 May 2004 16:37:19 -0400
In-Reply-To: <408FF6B8.3050206@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: <OFBAEAE447.95E7E3DD-ON85256E88.004A7EAE-85256E88.00713B53@us.ibm.com>
Date: Sun, 2 May 2004 16:36:47 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF291 | April 6, 2004) at
 05/02/2004 16:36:47,
	Serialize complete at 05/02/2004 16:36:47
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS
X-Archived-At: http://www.w3.org/mid/OFBAEAE447.95E7E3DD-ON85256E88.004A7EAE-85256E88.00713B53@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8496
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: <20040502203739.78A1FA1FA6@frink.w3.org>
Resent-Date: Sun,  2 May 2004 16:37:39 -0400 (EDT)


I fully support option 3.  A server should do whatever it can to
ensure that the lock token is being used only by the client that
created the lock, but for a server that allows unauthenticated
clients to take out locks (and I believe that should be allowed),
there's nothing the server can do beyond checking
that the lock token corresponds to that on the locked resource.

Cheers,
Geoff

Julian wrote on 04/28/2004 02:23:52 PM:

> 
> 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  Mon May  3 12:51: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 MAA13122
	for <webdav-archive@lists.ietf.org>; Mon, 3 May 2004 12:51:13 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id F25BDA0D28; Mon,  3 May 2004 12:51: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 30201A0F40
	for <w3c-dist-auth@listhub.w3.org>; Mon,  3 May 2004 12:51:11 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BKgel-0007E2-K2
	for w3c-dist-auth@w3c.org; Mon, 03 May 2004 12:51:03 -0400
Old-X-Envelope-From: lisa@xythos.com
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 i43Go7hV030407
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 3 May 2004 09:50:10 -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: <FC145028-9D21-11D8-AF45-000A95B2BB72@xythos.com>
Content-Transfer-Encoding: 7bit
Cc: Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@xythos.com>
Date: Mon, 3 May 2004 09:50:29 -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/FC145028-9D21-11D8-AF45-000A95B2BB72@xythos.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8497
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: <20040503165115.F25BDA0D28@frink.w3.org>
Resent-Date: Mon,  3 May 2004 12:51:15 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Julian, just so I make sure there's a clear consensus, was the proposed 
text OK?

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

It was my sense that Geoff, Jason and Elias were more or less on board 
with this but I was confused by your latest reply.

Elias suggested explaining how clients discover how a server handles 
these design choices, but this mostly codifies how things already work 
today and we seem to have pretty successful interoperability in this 
area.  As it stands today, if the server requires authentication and 
the client didn't provide it, the server responds with a 403 and 
clients deal with that appropriately.

Did anybody have any alterations to suggest to this text?

Lisa

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  Mon May  3 13:04: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 NAA14005
	for <webdav-archive@lists.ietf.org>; Mon, 3 May 2004 13:04:31 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 51E89A0B4F; Mon,  3 May 2004 13:04:33 -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 430B0A094B
	for <w3c-dist-auth@listhub.w3.org>; Mon,  3 May 2004 13:04:31 -0400 (EDT)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BKgrB-0001DT-CP
	for w3c-dist-auth@w3c.org; Mon, 03 May 2004 13:03:53 -0400
Received: (qmail 16800 invoked by uid 65534); 3 May 2004 17:03:21 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.39]) (217.5.201.10)
  by mail.gmx.net (mp010) with SMTP; 03 May 2004 19:03:21 +0200
X-Authenticated: #1915285
Message-ID: <40967B58.4030209@gmx.de>
Date: Mon, 03 May 2004 19:03:20 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@xythos.com>
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> <40901CB0.1040208@gmx.de> <5DDCFA2A-995A-11D8-B566-000A95B2BB72@xythos.com> <409023F0.9000508@gmx.de> <FC145028-9D21-11D8-AF45-000A95B2BB72@xythos.com>
In-Reply-To: <FC145028-9D21-11D8-AF45-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/40967B58.4030209@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8498
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: <20040503170433.51E89A0B4F@frink.w3.org>
Resent-Date: Mon,  3 May 2004 13:04:33 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> Julian, just so I make sure there's a clear consensus, was the proposed 
> text OK?
> 
>>>
>>> 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.

Actually I'd make that

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

(first MAY -> SHOULD).

> It was my sense that Geoff, Jason and Elias were more or less on board 
> with this but I was confused by your latest reply.

Which one?

> Elias suggested explaining how clients discover how a server handles 
> these design choices, but this mostly codifies how things already work 
> today and we seem to have pretty successful interoperability in this 
> area.  As it stands today, if the server requires authentication and the 
> client didn't provide it, the server responds with a 403 and clients 
> deal with that appropriately.

Agreed.

> Did anybody have any alterations to suggest to this text?

Nothing except the one above.

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Mon May  3 15:24:11 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 PAA23635
	for <webdav-archive@lists.ietf.org>; Mon, 3 May 2004 15:24:11 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 4BC94A08E3; Mon,  3 May 2004 15:24: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 0FCD8A0DA3
	for <w3c-dist-auth@listhub.w3.org>; Mon,  3 May 2004 15:23:21 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BKinq-0000UW-IY
	for w3c-dist-auth@w3c.org; Mon, 03 May 2004 15:08:34 -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 i43IgYhV009496
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 3 May 2004 11:42:34 -0700
In-Reply-To: <p0610050abcb8904591b7@[129.46.227.161]>
References: <p06100502bcb84c541dcf@[129.46.227.161]> <20040430224729.GA31789@manyfish.co.uk> <p0610050abcb8904591b7@[129.46.227.161]>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <B203237C-9D31-11D8-AF45-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: Alexey Melnikov <Alexey.Melnikov@isode.com>,
        Magnus Nystrom <magnus@rsasecurity.com>,
        Joe Orton <joe@manyfish.co.uk>, Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 3 May 2004 11:42:57 -0700
To: Ted Hardie <hardie@qualcomm.com>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: HTTP sasl draft in last call
X-Archived-At: http://www.w3.org/mid/B203237C-9D31-11D8-AF45-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8499
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: <20040503192413.4BC94A08E3@frink.w3.org>
Resent-Date: Mon,  3 May 2004 15:24:13 -0400 (EDT)
Content-Transfer-Encoding: 7bit


I share Joe's concern with definition of 235/236 success codes.  They 
are unnecessary
and introduce a round-trip, and this makes SASL authentication work 
unlike Digest
(and Basic).  I don't see the justification for the change and the 
extra complexity.
Instead, when authentication succeeds, the response to the authorized 
request should
immediately be the regular success response, whether that's 200 OK with 
the body
of the requested resource, or some other success code, with the 
WWW-Authenticate
success header moved from the 235 (236) code response to the real 
success
response.

Joe, why is CONNECT not going to work?  Can you forward your explanation
for that?  Also, why is redefining OPTIONS not going to work (and how 
exactly
are they redefining OPTIONS?)

Ted, I'll forward the 1st para above to the IESG separately as an 
official last call comment.

Lisa

On Apr 30, 2004, at 4:23 PM, Ted Hardie wrote:

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



From w3c-dist-auth-request@w3.org  Mon May  3 15:24:18 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 PAA23654
	for <webdav-archive@lists.ietf.org>; Mon, 3 May 2004 15:24:17 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 66BC6A194A; Mon,  3 May 2004 15:24: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 28F6BA2107
	for <w3c-dist-auth@listhub.w3.org>; Mon,  3 May 2004 15:23:21 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BKinp-0000UW-MJ
	for w3c-dist-auth@w3c.org; Mon, 03 May 2004 15:08:34 -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 i43Ip6hV010317
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 3 May 2004 11:51:07 -0700
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <E399BA96-9D32-11D8-AF45-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 3 May 2004 11:51:29 -0700
To: Alexey Melnikov <Alexey.Melnikov@isode.com>,
        Magnus Nystrom <magnus@rsasecurity.com>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Another issue on SASL draft
X-Archived-At: http://www.w3.org/mid/E399BA96-9D32-11D8-AF45-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8500
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: <20040503192417.66BC6A194A@frink.w3.org>
Resent-Date: Mon,  3 May 2004 15:24:17 -0400 (EDT)
Content-Transfer-Encoding: 7bit



I just noticed something else I don't understand in the SASL draft.  
Can you clarify?

Example 6, in section 4.7.6, shows the client attempting to 
authenticate but without
using the CONNECT request.  So far so good -- the client doesn't want a 
SASL layer,
the client simply wants to authenticate.  The last GET request in the 
example shows
no WWW-Authenticate header, thus no authorization information -- yet 
the server
responds successfully.  Shouldn't every request include the 
WWW-Authenticate
header, until the point where the client decides to "log out"?

This problem wouldn't exist if the 235 error was removed and if SASL 
worked like
Digest/Basic -- the 2nd GET request would clearly contain the 
authentication, and
the response would be 200 OK.

Lisa



From w3c-dist-auth-request@w3.org  Mon May  3 16:05: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 QAA26199
	for <webdav-archive@lists.ietf.org>; Mon, 3 May 2004 16:05:54 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 09703A1F48; Mon,  3 May 2004 16:05: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 489AEA1F48
	for <w3c-dist-auth@listhub.w3.org>; Mon,  3 May 2004 16:05:54 -0400 (EDT)
Received: from cats-mx1.ucsc.edu ([128.114.129.36] helo=ucsc.edu)
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BKjhG-0005HW-AS
	for w3c-dist-auth@w3.org; Mon, 03 May 2004 16:05:50 -0400
Received: from dhcp-63-214.cse.ucsc.edu (dhcp-63-214.cse.ucsc.edu [128.114.63.214])
	by ucsc.edu (8.10.1/8.10.1) with ESMTP id i43K4B704726
	for <w3c-dist-auth@w3.org>; Mon, 3 May 2004 13:04:11 -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: <20040503130255.1842041596.ejw@cse.ucsc.edu>
Date: Mon, 3 May 2004 13:02:55 -0700
X-UCSC-CATS-MailScanner: Found to be clean
Subject: Fw: PROPFIND with just property names not working thro' telnet on port 80
X-Archived-At: http://www.w3.org/mid/20040503130255.1842041596.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8501
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: <20040503200556.09703A1F48@frink.w3.org>
Resent-Date: Mon,  3 May 2004 16:05:56 -0400 (EDT)
Content-Transfer-Encoding: quoted-printable


Accidentally caught by the spam filter.

- Jim

> ------------Original Message------------
> From: Z K <z197in@yahoo.com>
> To: w3c-dist-auth@w3.org
> Date: Mon, Apr-26-2004 1:21 AM
> Subject: [Moderator Action] PROPFIND with just property names not working=
 thro' telnet on port 80
> =

> =

> =

> Hi,
> Any idea why this isn't working? =

> =

> Foll. is the transcript of telnet session on port 80
> =

> telnet localhost 80
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> PROPFIND /temp/ HTTP/1.0
> Depth: 0
> Content-Type: text/xml; charset=3D"utf-8"
> Content-Length: xxxx
>                                                       =

>                          =

>    <?xml version=3D"1.0 encoding=3D"utf-8" ?>
>       <propfind xmlns=3D"DAV:">
>         <propname/>
>       </propfind>
> =

> =

> >>Response:
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <html><head>
> <title>413 Request Entity Too Large</title>
> </head><body>
> <h1>Request Entity Too Large</h1>
> The requested resource<br />/temp/<br />
> does not allow request data with PROPFIND requests, or
> the amount of data provided in
> the request exceeds the capacity limit.
> <hr />
> <address>Apache/2.0.49 (Unix) DAV/2 Server
> =

> Thanks.
> =

> =

> =

> __________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online by April 15th
> http://taxes.yahoo.com/filing.html
> =



From w3c-dist-auth-request@w3.org  Mon May  3 16:06: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 QAA26217
	for <webdav-archive@lists.ietf.org>; Mon, 3 May 2004 16:06:23 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id CE8CEA1B48; Mon,  3 May 2004 16:06: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 F16B4A1B48
	for <w3c-dist-auth@listhub.w3.org>; Mon,  3 May 2004 16:06:22 -0400 (EDT)
Received: from cats-mx1.ucsc.edu ([128.114.129.36] helo=ucsc.edu)
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BKjhb-0005LU-I2
	for w3c-dist-auth@w3.org; Mon, 03 May 2004 16:06:11 -0400
Received: from dhcp-63-214.cse.ucsc.edu (dhcp-63-214.cse.ucsc.edu [128.114.63.214])
	by ucsc.edu (8.10.1/8.10.1) with ESMTP id i43K31704441
	for <w3c-dist-auth@w3.org>; Mon, 3 May 2004 13:03:05 -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: <20040503130144.502981740.ejw@cse.ucsc.edu>
Date: Mon, 3 May 2004 13:01:44 -0700
X-UCSC-CATS-MailScanner: Found to be clean
Subject: Fw: Goliath question
X-Archived-At: http://www.w3.org/mid/20040503130144.502981740.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8502
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: <20040503200624.CE8CEA1B48@frink.w3.org>
Resent-Date: Mon,  3 May 2004 16:06:24 -0400 (EDT)
Content-Transfer-Encoding: quoted-printable


Accidentally caught by the spam filter.

- Jim

> ------------Original Message------------
> From: Darwin_Dali <darwin_dali@mac.com>
> To: <w3c-dist-auth@w3.org>
> Date: Sat, May-1-2004 1:54 PM
> Subject: [Moderator Action] Goliath question
> =

> =

> =

> I seem to be unable to delete a folder in the public folder of my iDisk
> using Goliath 1.0.1. I can upload just fine, but not delete. It prompts m=
e
> with the dialogue whether I'm sure I want to delete it, then I click OK a=
nd
> it appears to do the job (and the folder actually disappears). However, w=
hen
> I refresh the view (or check my homepage on the web), that folder is stil=
l
> there! My system is OS9.2.1. Any suggestions?
> Thanks,
> Mike
> =



From w3c-dist-auth-request@w3.org  Tue May  4 13:31: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 NAA14716
	for <webdav-archive@lists.ietf.org>; Tue, 4 May 2004 13:31:50 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 9F725A09F6; Tue,  4 May 2004 13:31: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 9C07EA1668
	for <w3c-dist-auth@listhub.w3.org>; Tue,  4 May 2004 13:31:46 -0400 (EDT)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BL3kj-0001xw-FL
	for w3c-dist-auth@w3c.org; Tue, 04 May 2004 13:30:45 -0400
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i44HUjFD032253 sender ccjason@us.ibm.com for w3c-dist-auth@w3c.org; Tue, 4 May 2004 10:30:45 -0700
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by bandage.seagull.net (8.12.10) with ESMTP id i44HUhkE032153 sender ccjason@us.ibm.com; Tue, 4 May 2004 10:30:44 -0700
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i44HUTIm696016; Tue, 4 May 2004 13:30:29 -0400
Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i44HUnD6079024; Tue, 4 May 2004 13:30:49 -0400
To: Julian Reschke <nnjulian.reschke___at___gmx.de@smallcue.com>
Cc: 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: <OF09337CE3.0075D66F-ON85256E8A.005F118B-85256E8A.00602570@us.ibm.com>
Date: Tue, 4 May 2004 13:30:23 -0400
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF199 | April 27, 2004) at 05/04/2004 13:30:28, Serialize complete at 05/04/2004 13:30:28
Content-Type: multipart/alternative; boundary="=_alternative 005F384185256E8A_="
Subject: Re: RFC2518 issues IF_AND_AUTH and LOCK_SEMANTICS
X-Archived-At: http://www.w3.org/mid/OF09337CE3.0075D66F-ON85256E8A.005F118B-85256E8A.00602570@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8503
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: <20040504173148.9F725A09F6@frink.w3.org>
Resent-Date: Tue,  4 May 2004 13:31:48 -0400 (EDT)


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

> >>> 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.
> 
> Actually I'd make that
> 
> "Servers SHOULD 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."
> 
> (first MAY -> SHOULD).
 I agree with Julian's sentiments, but either wording works for me.



--=_alternative 005F384185256E8A_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">&gt; &gt;&gt;&gt; Servers MAY restrict usage of the lock token to exactly the<br>
&gt; &gt;&gt;&gt; authenticated principal who created the lock. Servers MAY also allow<br>
&gt; &gt;&gt;&gt; other privileged authenticated principals or even unauthenticated<br>
&gt; &gt;&gt;&gt; principals to use the lock token.<br>
&gt; <br>
&gt; Actually I'd make that<br>
&gt; <br>
&gt; &quot;Servers SHOULD restrict usage of the lock token to exactly the<br>
&gt; authenticated principal who created the lock. Servers MAY also allow<br>
&gt; other privileged authenticated principals or even unauthenticated<br>
&gt; principals to use the lock token.&quot;<br>
&gt; <br>
&gt; (first MAY -&gt; SHOULD).</font>
<br><font size=2 face="sans-serif">&nbsp;I agree with Julian's sentiments, but either wording works for me.</font>
<br>
<br><font size=2 face="sans-serif"><br>
</font>
--=_alternative 005F384185256E8A_=--



From w3c-dist-auth-request@w3.org  Tue May  4 16:12: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 QAA26420
	for <webdav-archive@lists.ietf.org>; Tue, 4 May 2004 16:12:53 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 29AE3A056B; Tue,  4 May 2004 16:12: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 055A2A056B
	for <w3c-dist-auth@listhub.w3.org>; Tue,  4 May 2004 16:12:46 -0400 (EDT)
Received: from agminet03.oracle.com ([141.146.126.230])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BL6FW-00013l-OR
	for w3c-dist-auth@w3.org; Tue, 04 May 2004 16:10:42 -0400
Received: from agminet03.oracle.com (localhost [127.0.0.1])
	by agminet03.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i44K8TfN024303
	for <w3c-dist-auth@w3.org>; Tue, 4 May 2004 13:10:11 -0700
Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.191.11])
	by agminet03.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i44HWoTA024161
	for <w3c-dist-auth@w3.org>; Tue, 4 May 2004 10:34:11 -0700
Received: from rgmgw2.us.oracle.com (localhost [127.0.0.1])
	by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i44HWotO006307
	for <w3c-dist-auth@w3.org>; Tue, 4 May 2004 11:32:50 -0600
Received: from sguanpc (sguan-pc.us.oracle.com [130.35.180.197])
	by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id i44HWnMD006301
	for <w3c-dist-auth@w3.org>; Tue, 4 May 2004 11:32:49 -0600
Message-ID: <062301c431fd$74aa6ef0$c5b42382@us.oracle.com>
From: "Stanley Guan" <stanley.guan@oracle.com>
To: <w3c-dist-auth@w3.org>
Date: Tue, 4 May 2004 10:30:12 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0620_01C431C2.C81E4560"
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: list item separator
X-Archived-At: http://www.w3.org/mid/062301c431fd$74aa6ef0$c5b42382@us.oracle.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8504
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: <20040504201252.29AE3A056B@frink.w3.org>
Resent-Date: Tue,  4 May 2004 16:12:52 -0400 (EDT)


This is a multi-part message in MIME format.

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

As shown in the Example, list items are separated by ",".
Is this implied by the notation "1*"?  Why "," is not=20
explicitly specified in the derivation rules?  Can we use
space character instead of "," as separator?

Thx,

-Stanley


9.5 If Header=20
   =20
   If =3D "If" ":" ( 1*No-tag-list | 1*Tagged-list)=20
   No-tag-list =3D List=20
   Tagged-list =3D Resource 1*List=20
   Resource =3D Coded-URL=20
   List =3D "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"=20
   State-token =3D Coded-URL =20
   Coded-URL =3D "<" absoluteURI ">"=20
   =20
9.5.4   Example - Tagged List If header=20
   =20
     COPY /resource1 HTTP/1.1=20
     Host: www.example.com=20
     Destination: http://www.example.com/resource2=20
     If: <http://www.example.com/resource1> (<locktoken:a-write-lock-
     token> [W/"A weak ETag"]), (["strong ETag"]),=20
     <http://www.bar.bar/random>(["another strong ETag"])=20


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial>As shown in the Example, list items are =
separated by=20
",".</FONT></DIV>
<DIV><FONT face=3DArial>Is this implied by the notation "1*"?&nbsp; Why =
"," is not=20
</FONT></DIV>
<DIV><FONT face=3DArial>explicitly specified in the derivation =
rules?&nbsp; Can we=20
use</FONT></DIV>
<DIV><FONT face=3DArial>space character instead of "," as=20
separator?</FONT></DIV><FONT face=3DArial>
<DIV><BR>Thx,</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>-Stanley</FONT></FONT></DIV>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial>9.5 If Header <BR>&nbsp;&nbsp;&nbsp; =
<BR>&nbsp;&nbsp; If =3D=20
"If" ":" ( 1*No-tag-list | 1*Tagged-list) <BR>&nbsp;&nbsp; No-tag-list =
=3D List=20
<BR>&nbsp;&nbsp; Tagged-list =3D Resource 1*List <BR>&nbsp;&nbsp; =
Resource =3D=20
Coded-URL <BR>&nbsp;&nbsp; List =3D "(" 1*(["Not"](State-token | "[" =
entity-tag=20
"]")) ")" <BR>&nbsp;&nbsp; State-token =3D Coded-URL&nbsp; =
<BR>&nbsp;&nbsp;=20
Coded-URL =3D "&lt;" absoluteURI "&gt;"&nbsp;<BR>&nbsp;&nbsp;&nbsp;=20
<BR>9.5.4&nbsp;&nbsp; Example - Tagged List If header =
<BR>&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp; COPY /resource1 HTTP/1.1=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp; Host: www.example.com =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
Destination: http://www.example.com/resource2 =
<BR>&nbsp;&nbsp;&nbsp;&nbsp; If:=20
&lt;http://www.example.com/resource1&gt;=20
(&lt;locktoken:a-write-lock-<BR>&nbsp;&nbsp;&nbsp;&nbsp; token&gt; [W/"A =
weak=20
ETag"]), (["strong ETag"]), <BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;http://www.bar.bar/random&gt;(["another strong ETag"])=20
<BR></DIV></FONT></BODY></HTML>

------=_NextPart_000_0620_01C431C2.C81E4560--



From w3c-dist-auth-request@w3.org  Tue May  4 17:36: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 RAA00845
	for <webdav-archive@lists.ietf.org>; Tue, 4 May 2004 17:36:36 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 238CCA14CB; Tue,  4 May 2004 17:36:28 -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 C3E01A19E4
	for <w3c-dist-auth@listhub.w3.org>; Tue,  4 May 2004 17:36:24 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BL7aS-00025t-GI
	for w3c-dist-auth@w3c.org; Tue, 04 May 2004 17:36:24 -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 i44LZQhV027313
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 4 May 2004 14:35:27 -0700
In-Reply-To: <Pine.WNT.4.58.0405032235290.2184@mnystrom-lap>
References: <E399BA96-9D32-11D8-AF45-000A95B2BB72@osafoundation.org> <Pine.WNT.4.58.0405032235290.2184@mnystrom-lap>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <036C1BDF-9E13-11D8-8F35-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: Alexey Melnikov <Alexey.Melnikov@isode.com>,
        Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Tue, 4 May 2004 14:35:50 -0700
To: "Nystrom, Magnus" <magnus@rsasecurity.com>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: Another issue on SASL draft
X-Archived-At: http://www.w3.org/mid/036C1BDF-9E13-11D8-8F35-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8505
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: <20040504213628.238CCA14CB@frink.w3.org>
Resent-Date: Tue,  4 May 2004 17:36:28 -0400 (EDT)
Content-Transfer-Encoding: 7bit


I'm not sure this connection-oriented approach will really work for
existing HTTP/WebDAV software.  For example, the Java HTTP servlet API
treats each request as independent.  It's a major architectural change 
to
have authentication credentials (or any state) last for more than one 
request.
The "HTTP way" is to re-establish context information with every 
request.
For example, the ETag the client expects the entity to have is sent 
with every
HTTP request; and WebDAV clients send the lock token they are using
with every request.

There are other options like having the server provide a SASL session-ID
(you can require that this only be used over secured connections) and 
the
SASL session ID is used to identify the SASL authentication context 
without
re-authentication.

Lisa

On May 3, 2004, at 1:44 PM, Nystrom, Magnus wrote:

> Lisa,
>
> Thanks for reviewing our document. Alex is on holidays right now but in
> the interest of time I'll try to answer right away.
>
> The idea is that when sending the last request, the client already 
> knows
> that it has been authenticated and there was no need to send another
> WWW-Authenticate header for the server (and no need to include an
> Authorization header for the client). The fact that the client is
> authenticated is something the server will have to make note of. This 
> is
> different from Basic/Digest where the client pre-emptively may include 
> an
> Authorization header for requests within the original request-URIs
> protection space, but it is a consequence of the open nature of the 
> SASL
> framework - it may not be possible, or it may be very costly, to
> re-authenticate with a particular SASL mechanism, especially
> pre-emptively.
>
> I will answer your question regarding the 235 response in a separate
> email.
>
> -- Magnus
>
> On Mon, 3 May 2004, Lisa Dusseault wrote:
>
>> I just noticed something else I don't understand in the SASL draft.
>> Can you clarify?
>>
>> Example 6, in section 4.7.6, shows the client attempting to 
>> authenticate
>> but without using the CONNECT request.  So far so good -- the client
>> doesn't want a SASL layer, the client simply wants to authenticate.
>> The last GET request in the example shows no WWW-Authenticate header,
>> thus no authorization information -- yet the server responds
>> successfully.  Shouldn't every request include the WWW-Authenticate
>> header, until the point where the client decides to "log out"?
>>
>> This problem wouldn't exist if the 235 error was removed and if SASL
>> worked like Digest/Basic -- the 2nd GET request would clearly contain
>> the authentication, and the response would be 200 OK.



From w3c-dist-auth-request@w3.org  Wed May  5 00:00: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 AAA20093
	for <webdav-archive@lists.ietf.org>; Wed, 5 May 2004 00:00:40 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id CE28CA06EB; Wed,  5 May 2004 00:00: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 BB736A08EF
	for <w3c-dist-auth@listhub.w3.org>; Wed,  5 May 2004 00:00:37 -0400 (EDT)
Received: from dc3.com ([68.98.211.142] helo=mail.dc3.com)
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BLDVr-0004b7-12
	for w3c-dist-auth@w3c.org; Tue, 04 May 2004 23:56:03 -0400
Received: from dc3.com ([68.98.211.147])
	by dc3.com (dc3.com [127.0.0.1])
	(MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000005047.msg
	for <w3c-dist-auth@w3c.org>; Tue, 04 May 2004 20:55:56 -0700
Message-ID: <409865C7.9030308@dc3.com>
Date: Tue, 04 May 2004 20:55:51 -0700
From: Bob Denny <rdenny@dc3.com>
Organization: DC-3 Dreams, SP
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, pdf
MIME-Version: 1.0
To: w3c-dist-auth@w3c.org
References: <200405022031.i42KV0xu003855@post.webmailer.de>
In-Reply-To: <200405022031.i42KV0xu003855@post.webmailer.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Processed: dc3.com, Tue, 04 May 2004 20:55:56 -0700
	(not processed: message from valid local sender)
X-MDRemoteIP: 68.98.211.147
X-Return-Path: rdenny@dc3.com
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: Re (2): summary of BIND/RFC2518 status
X-Archived-At: http://www.w3.org/mid/409865C7.9030308@dc3.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8506
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: <20040505040041.CE28CA06EB@frink.w3.org>
Resent-Date: Wed,  5 May 2004 00:00:41 -0400 (EDT)
Content-Transfer-Encoding: 7bit


> [...]
> 1) We will *not* add locking discussion to BIND (in fact, we may want to 
> remove some locking-specific preconditions).
> [... etc.]

Thank Heaven. As an observer, this was going in a terrible direction.

In fact, it seems that DAV gets increasingly complex all the time, without
apparent convergence. Furthermore, the server-side implementations outside
Apache appear to be withering away. As such it seems less like a W3C
standard and more like a private protocol for special purposes, owned by
the Apache working group and a few client vendors who implemented it.

Is WebDAV really a standard? I think not.

  -- Bob  (DAV observer for 4+ years, and someone who implemented 2+
           years ago, only to be met with deafening silence from
           customers)






From w3c-dist-auth-request@w3.org  Wed May  5 02:34: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 CAA24160
	for <webdav-archive@lists.ietf.org>; Wed, 5 May 2004 02:34:02 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 3333DA1318; Wed,  5 May 2004 02:34: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 009B7A1318
	for <w3c-dist-auth@listhub.w3.org>; Wed,  5 May 2004 02:34:00 -0400 (EDT)
Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BLFyi-0006W3-HB
	for w3c-dist-auth@w3c.org; Wed, 05 May 2004 02:34:00 -0400
Received: (qmail 3744 invoked by uid 65534); 5 May 2004 06:33:28 -0000
Received: from p3EE24811.dip.t-dialin.net (EHLO [192.168.0.3]) (62.226.72.17)
  by mail.gmx.net (mp014) with SMTP; 05 May 2004 08:33:28 +0200
X-Authenticated: #1915285
Message-ID: <40988AB4.4080009@gmx.de>
Date: Wed, 05 May 2004 08:33:24 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bob Denny <rdenny@dc3.com>
Cc: w3c-dist-auth@w3c.org
References: <200405022031.i42KV0xu003855@post.webmailer.de> <409865C7.9030308@dc3.com>
In-Reply-To: <409865C7.9030308@dc3.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Re (2): summary of BIND/RFC2518 status
X-Archived-At: http://www.w3.org/mid/40988AB4.4080009@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8507
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: <20040505063403.3333DA1318@frink.w3.org>
Resent-Date: Wed,  5 May 2004 02:34:03 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Bob Denny wrote:
>>[...]
>>1) We will *not* add locking discussion to BIND (in fact, we may want to 
>>remove some locking-specific preconditions).
>>[... etc.]
> 
> 
> Thank Heaven. As an observer, this was going in a terrible direction.

I take that as agreement that locking should be moved into a separate 
document, instead of having advanced protocols (such as BIND) having to 
extend/fix RFC2518's definition of locks?

> In fact, it seems that DAV gets increasingly complex all the time, without
> apparent convergence. Furthermore, the server-side implementations outside
> Apache appear to be withering away. As such it seems less like a W3C
> standard and more like a private protocol for special purposes, owned by
> the Apache working group and a few client vendors who implemented it.
>
> Is WebDAV really a standard? I think not.

Well, it's a proposed standard, and many many clients and servers are 
using it. It's somehow "beyond hype", but that's not necessarily bad.

>   -- Bob  (DAV observer for 4+ years, and someone who implemented 2+
>            years ago, only to be met with deafening silence from
>            customers)

Our customers definitively use WebDAV intensively, be it for editing 
using Microsoft Office, for mass import/export, or as transport protocol 
for interconnecting separate servers.

Thanks for the feedback,

Julian

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



From w3c-dist-auth-request@w3.org  Thu May  6 15:55:40 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 PAA16071
	for <webdav-archive@lists.ietf.org>; Thu, 6 May 2004 15:55:38 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 51A94A0E51; Thu,  6 May 2004 15:55:39 -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 F0F16A2399
	for <w3c-dist-auth@listhub.w3.org>; Thu,  6 May 2004 15:55:36 -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 1BLoy0-00034N-Kx
	for w3c-dist-auth@w3.org; Thu, 06 May 2004 15:55:36 -0400
Received: (qmail 11645 invoked by uid 65534); 6 May 2004 19:55:05 -0000
Received: from p3EE2470E.dip.t-dialin.net (EHLO [192.168.0.3]) (62.226.71.14)
  by mail.gmx.net (mp001) with SMTP; 06 May 2004 21:55:05 +0200
X-Authenticated: #1915285
Message-ID: <409A9815.50906@gmx.de>
Date: Thu, 06 May 2004 21:55:01 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org, acl@webdav.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: WebDAV Access Control Protocol published as RFC3744
X-Archived-At: http://www.w3.org/mid/409A9815.50906@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8508
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: <20040506195539.51A94A0E51@frink.w3.org>
Resent-Date: Thu,  6 May 2004 15:55:39 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi.

It took long, but now we're done -- the WebDAV ACL protocol has been 
published as Proposed Standard. Get it from:

<http://www.ietf.org/rfc/rfc3744> (authorative text version)

or

<http://greenbytes.de/tech/webdav/rfc3744.html> (HTML)
<http://greenbytes.de/tech/webdav/rfc3744.pdf> (PDF)
<http://greenbytes.de/tech/webdav/rfc3744.xml> (XML)

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Thu May  6 17:11: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 RAA19459
	for <webdav-archive@lists.ietf.org>; Thu, 6 May 2004 17:11:30 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 6DDF5A07AA; Thu,  6 May 2004 17:11: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 97C59A07AA
	for <w3c-dist-auth@listhub.w3.org>; Thu,  6 May 2004 17:10:56 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BLplX-0004Zs-O5
	for w3c-dist-auth@w3.org; Thu, 06 May 2004 16:46:47 -0400
Old-X-Envelope-From: lisa@xythos.com
Old-X-Envelope-To: w3c-dist-auth@w3.org
Received: from [128.143.237.74] ([128.143.237.74])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i46KjehV010454
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Thu, 6 May 2004 13:45:43 -0700
In-Reply-To: <409A9815.50906@gmx.de>
References: <409A9815.50906@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <67047B2B-9F9E-11D8-8F35-000A95B2BB72@xythos.com>
Content-Transfer-Encoding: 7bit
Cc: w3c-dist-auth@w3.org, acl@webdav.org
From: Lisa Dusseault <lisa@xythos.com>
Date: Thu, 6 May 2004 13:46:08 -0700
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: WebDAV Access Control Protocol published as RFC3744
X-Archived-At: http://www.w3.org/mid/67047B2B-9F9E-11D8-8F35-000A95B2BB72@xythos.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8509
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: <20040506211132.6DDF5A07AA@frink.w3.org>
Resent-Date: Thu,  6 May 2004 17:11:32 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Congratulations.  A lot of good work went into this standard, but it's 
worth pointing out and applauding Geoff's careful modelling, Jim's 
clear writing, and Julian's tireless (and seemingly endlessly required) 
followups at the end.

Lisa

On May 6, 2004, at 12:55 PM, Julian Reschke wrote:

>
> Hi.
>
> It took long, but now we're done -- the WebDAV ACL protocol has been 
> published as Proposed Standard. Get it from:
>
> <http://www.ietf.org/rfc/rfc3744> (authorative text version)
>
> or
>
> <http://greenbytes.de/tech/webdav/rfc3744.html> (HTML)
> <http://greenbytes.de/tech/webdav/rfc3744.pdf> (PDF)
> <http://greenbytes.de/tech/webdav/rfc3744.xml> (XML)
>
> Best regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Sat May  8 07:49: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 HAA28716
	for <webdav-archive@lists.ietf.org>; Sat, 8 May 2004 07:49:19 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 8E869A23F5; Sat,  8 May 2004 07:49: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 D57CCA23F5
	for <w3c-dist-auth@listhub.w3.org>; Sat,  8 May 2004 07:49:17 -0400 (EDT)
Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BMQKI-0006OF-Ou
	for w3c-dist-auth@w3.org; Sat, 08 May 2004 07:49:07 -0400
Received: (qmail 22067 invoked by uid 65534); 8 May 2004 11:48:35 -0000
Received: from pD950C24F.dip.t-dialin.net (EHLO [192.168.0.2]) (217.80.194.79)
  by mail.gmx.net (mp001) with SMTP; 08 May 2004 13:48:35 +0200
X-Authenticated: #1915285
Message-ID: <409CC90D.40802@gmx.de>
Date: Sat, 08 May 2004 13:48:29 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Charter update: remove property registry task? 
X-Archived-At: http://www.w3.org/mid/409CC90D.40802@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8510
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: <20040508114919.8E869A23F5@frink.w3.org>
Resent-Date: Sat,  8 May 2004 07:49:19 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi,

We recently ([1]) discussed removing the property registry from the 
charter. Looking at all comments, it seems that there is indeed 
consensus to remove it.

I also mentioned that I can create a "common" index file for 
WebDAV-family specs, which will include a summary of all defined 
properties as well. It's now online at

	<http://greenbytes.de/tech/webdav/common-index.html>

(scroll down to "P / Properties" to get to a list of properties defined 
in current RFCs and IDs; note that this index only includes documents 
available in RFC2629 format that use a consistent way to include things 
in their respective indices).


[1] 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0128.html>)


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



From w3c-dist-auth-request@w3.org  Mon May 10 12:42: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 MAA16188
	for <webdav-archive@lists.ietf.org>; Mon, 10 May 2004 12:42:50 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 4C457A4CDA; Mon, 10 May 2004 12:42: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 5B0E8A4CE9
	for <w3c-dist-auth@listhub.w3.org>; Mon, 10 May 2004 12:42:46 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BNDrR-0007k4-NE
	for w3c-dist-auth@w3c.org; Mon, 10 May 2004 12:42:37 -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 i4AGfVhV025007
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 10 May 2004 09:41:32 -0700
In-Reply-To: <409BA5F8.4040406@isode.com>
References: <p06100502bcb84c541dcf@[129.46.227.161]> <20040430224729.GA31789@manyfish.co.uk> <p0610050abcb8904591b7@[129.46.227.161]> <B203237C-9D31-11D8-AF45-000A95B2BB72@osafoundation.org> <Pine.WNT.4.58.0405032244500.2184@mnystrom-lap> <409BA5F8.4040406@isode.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <F35ED503-A2A0-11D8-8F35-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: "Nystrom, Magnus" <magnus@rsasecurity.com>,
        Ted Hardie <hardie@qualcomm.com>, Joe Orton <joe@manyfish.co.uk>,
        Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 10 May 2004 09:41:56 -0700
To: Alexey Melnikov <Alexey.Melnikov@isode.com>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: HTTP sasl draft in last call
X-Archived-At: http://www.w3.org/mid/F35ED503-A2A0-11D8-8F35-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8511
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: <20040510164252.4C457A4CDA@frink.w3.org>
Resent-Date: Mon, 10 May 2004 12:42:52 -0400 (EDT)
Content-Transfer-Encoding: 7bit



On May 7, 2004, at 8:06 AM, Alexey Melnikov wrote:

> Nystrom, Magnus wrote:
>
>> Lisa,
>>
>> Thanks again for your review.
>>
>> The reason for introduction of 235/236 status codes is that they 
>> allow for
>> a clean introduction of a SASL security layer. With 200 alone, one 
>> must
>> ask when the SASL security layer actually goes into effect. Clearly 
>> not
>> all headers can be included in it, since for example there could be a
>> final WWW-Authenticate header from the server which is needed for the
>> client to calculate session keys etc. OTOH, any body clearly must be
>> protected by them. So, after some discussion, and while realizing 
>> that the
>> 235/236 will require an extra roundtrip, we felt the advantages 
>> outweighed
>> the disadvantages.
>>
>> Of course, I would be grateful for any suggestions on how to solve 
>> this
>> problem without the introduction of new status codes.
>>
> I agree with everything that Magnus said. I am wondering if this 
> explanation should be part of the document itself?

Unfortunately, I think the architecture that "necessitates" adding 
235/236 requires a rethink.  It's very un-HTTP and ill-defined to 
create a security layer in this way.  We could try to have some 
discussions about how to solve this differently - Roy suggested one 
approach, and there are obvious variations.

Lisa



From w3c-dist-auth-request@w3.org  Tue May 11 17:11: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 RAA25805
	for <webdav-archive@lists.ietf.org>; Tue, 11 May 2004 17:11:10 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 344C4A08F3; Tue, 11 May 2004 17:11: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 2C3F3A157B
	for <w3c-dist-auth@listhub.w3.org>; Tue, 11 May 2004 17:11:02 -0400 (EDT)
Received: from cats-mx3.ucsc.edu ([128.114.129.37] helo=ucsc.edu)
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BNeRJ-0001Hv-Pn
	for w3c-dist-auth@w3.org; Tue, 11 May 2004 17:05:26 -0400
Received: from dhcp-63-214.cse.ucsc.edu (dhcp-63-214.cse.ucsc.edu [128.114.63.214])
	by ucsc.edu (8.10.1/8.10.1) with ESMTP id i4BL2rq17687
	for <w3c-dist-auth@w3.org>; Tue, 11 May 2004 14:02:53 -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.6
Mime-Version: 1.0
Message-Id: <20040511140157.981953879.ejw@cse.ucsc.edu>
Date: Tue, 11 May 2004 14:01:57 -0700
X-UCSC-CATS-MailScanner: Found to be clean
Subject: Fw: Slide 2.0 final released
X-Archived-At: http://www.w3.org/mid/20040511140157.981953879.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8512
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: <20040511211112.344C4A08F3@frink.w3.org>
Resent-Date: Tue, 11 May 2004 17:11:12 -0400 (EDT)
Content-Transfer-Encoding: quoted-printable


Accidentally caught by the spam filter.

- Jim

> ------------Original Message------------
> From: Daniel Florey <dflorey@apache.org>
> To: w3c-dist-auth@w3.org
> Date: Thu, May-6-2004 6:42 AM
> Subject: [Moderator Action] Slide 2.0 final released
> =

> =

> =

> Hi folks,
> the final release of Slide 2.0 is available for download!
> The Slide WebDAV-server comes bundled with Tomcat 4.x / 5.x and is very =

> easy to install, because a new transactional file-store is used as =

> default store implementation.
> The 2.0 release also contains the updated webdav-client api and a simple =

> webdav commandline client.
> =

> So if you are interested, give it a try...
> =

> Regards,
> Daniel
> =



From w3c-dist-auth-request@w3.org  Tue May 11 17:11:17 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 RAA25827
	for <webdav-archive@lists.ietf.org>; Tue, 11 May 2004 17:11:17 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id AD61DA0563; Tue, 11 May 2004 17:11:18 -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 E412FA0563
	for <w3c-dist-auth@listhub.w3.org>; Tue, 11 May 2004 17:11:04 -0400 (EDT)
Received: from cats-mx3.ucsc.edu ([128.114.129.37] helo=ucsc.edu)
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BNeQJ-00019s-Eo
	for w3c-dist-auth@w3.org; Tue, 11 May 2004 17:04:23 -0400
Received: from dhcp-63-214.cse.ucsc.edu (dhcp-63-214.cse.ucsc.edu [128.114.63.214])
	by ucsc.edu (8.10.1/8.10.1) with ESMTP id i4BL2Cq17549
	for <w3c-dist-auth@w3.org>; Tue, 11 May 2004 14:02:13 -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.6
Mime-Version: 1.0
Message-Id: <20040511140117.1148846195.ejw@cse.ucsc.edu>
Date: Tue, 11 May 2004 14:01:17 -0700
X-UCSC-CATS-MailScanner: Found to be clean
Subject: Fw: WebDAV Problem with Microsoft Office
X-Archived-At: http://www.w3.org/mid/20040511140117.1148846195.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8513
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: <20040511211118.AD61DA0563@frink.w3.org>
Resent-Date: Tue, 11 May 2004 17:11:18 -0400 (EDT)
Content-Transfer-Encoding: quoted-printable


Accidentally caught by the spam filter.

- Jim

> ------------Original Message------------
> From: "Eddie Bates" <Eddie.Bates@erlbaum.com>
> To: <w3c-dist-auth@w3.org>
> Date: Fri, May-7-2004 11:21 AM
> Subject: [Moderator Action] WebDAV Problem with Microsoft Office
> =

> =

> =

> Hi Greg
> =

> I have a question about WebDAV. We have installed it on about 20 Windows =
98 machines. For the most part there are no problems. However, on a handful=
 of computers, everytime you try to open the "web folders," there is a prom=
pt for "Windows Installer" and then Microsoft Office 2000 Professional," wh=
ich I don't understand because everyone here has Office 2000.
> =

> Have you heard of this? Is there anything you can recommend?
> =

> Thank you so much for your time.
> =

> Sincerely
> =

> Eddie Bates
> =

> =



From w3c-dist-auth-request@w3.org  Wed May 12 13:05:04 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 NAA26779
	for <webdav-archive@lists.ietf.org>; Wed, 12 May 2004 13:05:03 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 0FF02A2A38; Wed, 12 May 2004 13:05:01 -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 273E0A2944
	for <w3c-dist-auth@listhub.w3.org>; Wed, 12 May 2004 13:04:59 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BNxA0-0002Lm-C1
	for w3c-dist-auth@w3.org; Wed, 12 May 2004 13:04:48 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3.org
Received: from [198.144.203.243] (bourne.rtfm.com [198.144.203.243])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i4CH46JL022811
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 12 May 2004 10:04:08 -0700
In-Reply-To: <062301c431fd$74aa6ef0$c5b42382@us.oracle.com>
References: <062301c431fd$74aa6ef0$c5b42382@us.oracle.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <74A626A8-A436-11D8-8F35-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: <w3c-dist-auth@w3.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 12 May 2004 10:04:39 -0700
To: "Stanley Guan" <stanley.guan@oracle.com>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: list item separator
X-Archived-At: http://www.w3.org/mid/74A626A8-A436-11D8-8F35-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8514
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: <20040512170501.0FF02A2A38@frink.w3.org>
Resent-Date: Wed, 12 May 2004 13:05:01 -0400 (EDT)
Content-Transfer-Encoding: 7bit


I'm a little confused.  Which document are you looking at, RFC2518 or 
RFC2518 bis (and if so, which draft?)

RFC2518 doesn't support commas in the If header, which is unfortunate 
because it doesn't allow the sender to split the header up into several 
headers. Normal HTTP composition rules allow the sender to do that, and 
the entire header is reconstructed by adding in commas.

Lisa

On May 4, 2004, at 10:30 AM, Stanley Guan wrote:

> As shown in the Example, list items are separated by ",".
> Is this implied by the notation "1*"?  Why "," is not
> explicitly specified in the derivation rules?  Can we use
> space character instead of "," as separator?
>
> Thx,
>
> -Stanley
>
>
> 9.5 If Header
>
>    If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
>    No-tag-list = List
>    Tagged-list = Resource 1*List
>    Resource = Coded-URL
>    List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
>    State-token = Coded-URL
>    Coded-URL = "<" absoluteURI ">"
>
> 9.5.4   Example - Tagged List If header
>
>      COPY /resource1 HTTP/1.1
>      Host: www.example.com
>      Destination: http://www.example.com/resource2
>      If: <http://www.example.com/resource1> (<locktoken:a-write-lock-
>      token> [W/"A weak ETag"]), (["strong ETag"]),
>      <http://www.bar.bar/random>(["another strong ETag"])
>



From w3c-dist-auth-request@w3.org  Wed May 12 17:23: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 RAA12688
	for <webdav-archive@lists.ietf.org>; Wed, 12 May 2004 17:23:56 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id D040CA0629; Wed, 12 May 2004 17:23: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 A1569A11AE
	for <w3c-dist-auth@listhub.w3.org>; Wed, 12 May 2004 17:23:54 -0400 (EDT)
Received: from inet-mail4.oracle.com ([148.87.2.204])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BO1Ck-0004jY-E1
	for w3c-dist-auth@w3.org; Wed, 12 May 2004 17:23:54 -0400
Received: from inet-mail4.oracle.com (localhost [127.0.0.1])
	by inet-mail4.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i4CLKYKv022209;
	Wed, 12 May 2004 14:20:35 -0700 (PDT)
Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.191.12])
	by inet-mail4.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i4CLKW1d022176;
	Wed, 12 May 2004 14:20:32 -0700 (PDT)
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 i4CLNCD3002681;
	Wed, 12 May 2004 15:23:12 -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 i4CLNCjq002668;
	Wed, 12 May 2004 15:23:12 -0600
Message-ID: <03b001c43866$d8250160$c5b42382@us.oracle.com>
From: "Stanley Guan" <stanley.guan@oracle.com>
To: "Lisa Dusseault" <lisa@osafoundation.org>
Cc: <w3c-dist-auth@w3.org>
References: <062301c431fd$74aa6ef0$c5b42382@us.oracle.com> <74A626A8-A436-11D8-8F35-000A95B2BB72@osafoundation.org>
Date: Wed, 12 May 2004 14:19:43 -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: Re: list item separator
X-Archived-At: http://www.w3.org/mid/03b001c43866$d8250160$c5b42382@us.oracle.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8515
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: <20040512212357.D040CA0629@frink.w3.org>
Resent-Date: Wed, 12 May 2004 17:23:57 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Lisa,

I am looking at RFC2518 bis-05!

My question is why list item separator (",") was 
not explicitly shown in the derivation rules.  Is
it because it is implicitly implied?

BTW, what's the current status RFC2518 bis?

Thx,

-Stanley

----- Original Message ----- 
From: "Lisa Dusseault" <lisa@osafoundation.org>
To: "Stanley Guan" <stanley.guan@oracle.com>
Cc: <w3c-dist-auth@w3.org>
Sent: Wednesday, May 12, 2004 10:04 AM
Subject: Re: list item separator


> 
> I'm a little confused.  Which document are you looking at, RFC2518 or 
> RFC2518 bis (and if so, which draft?)
> 
> RFC2518 doesn't support commas in the If header, which is unfortunate 
> because it doesn't allow the sender to split the header up into several 
> headers. Normal HTTP composition rules allow the sender to do that, and 
> the entire header is reconstructed by adding in commas.
> 
> Lisa
> 
> On May 4, 2004, at 10:30 AM, Stanley Guan wrote:
> 
> > As shown in the Example, list items are separated by ",".
> > Is this implied by the notation "1*"?  Why "," is not
> > explicitly specified in the derivation rules?  Can we use
> > space character instead of "," as separator?
> >
> > Thx,
> >
> > -Stanley
> >
> >
> > 9.5 If Header
> >
> >    If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
> >    No-tag-list = List
> >    Tagged-list = Resource 1*List
> >    Resource = Coded-URL
> >    List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
> >    State-token = Coded-URL
> >    Coded-URL = "<" absoluteURI ">"
> >
> > 9.5.4   Example - Tagged List If header
> >
> >      COPY /resource1 HTTP/1.1
> >      Host: www.example.com
> >      Destination: http://www.example.com/resource2
> >      If: <http://www.example.com/resource1> (<locktoken:a-write-lock-
> >      token> [W/"A weak ETag"]), (["strong ETag"]),
> >      <http://www.bar.bar/random>(["another strong ETag"])
> >
> 
> 



From w3c-dist-auth-request@w3.org  Wed May 12 17:56: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 RAA13875
	for <webdav-archive@lists.ietf.org>; Wed, 12 May 2004 17:56:36 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 361E4A2790; Wed, 12 May 2004 17:56: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 3E1AEA2722
	for <w3c-dist-auth@listhub.w3.org>; Wed, 12 May 2004 17:56:35 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BO1iM-0004Qj-UW
	for w3c-dist-auth@w3.org; Wed, 12 May 2004 17:56:35 -0400
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3.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 i4CLtoJL011482
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 12 May 2004 14:55:52 -0700
In-Reply-To: <03b001c43866$d8250160$c5b42382@us.oracle.com>
References: <062301c431fd$74aa6ef0$c5b42382@us.oracle.com> <74A626A8-A436-11D8-8F35-000A95B2BB72@osafoundation.org> <03b001c43866$d8250160$c5b42382@us.oracle.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <31E9F4B7-A45F-11D8-8F35-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: <w3c-dist-auth@w3.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 12 May 2004 14:56:17 -0700
To: "Stanley Guan" <stanley.guan@oracle.com>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: list item separator
X-Archived-At: http://www.w3.org/mid/31E9F4B7-A45F-11D8-8F35-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8516
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: <20040512215637.361E4A2790@frink.w3.org>
Resent-Date: Wed, 12 May 2004 17:56:37 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Sorry, I get it now.   HTTP headers often allow commas as separators.  
The If header doesn't originally  include commas, and it would be 
useful to allow commas so that the If header can be split across 
multiple lines.

In draft rfc2518bis-03 I tried to alter the If header so that commas 
would be allowable.  I didn't do a complete job of this, apparently -- 
the syntax is wrong.  (Then again, I can't quite see how the original 
RFC2518 syntax definition allows the given examples, either.)

Since HTTP uses the syntax "# ( comma-separated-item )", I guess it 
would be:

If = "If" ":" (1* No-tag-list | 1*Tagged-List)
No-tag-list = List
Tagged-list = Resource 1*List
Resource = Coded-URL
List = #(  "(" List | State-token ")" )
State-token = Coded-URL | "[" entity-tag "]"
Coded-URL = "<" absoluteURI ">"

Does that look correct?  Let me know if it does...

The current state of RFC2518bis is that we got blocked on a couple 
issues for which we couldn't determine consensus at the time.  I do 
have a few changes that could go into a -06 but not a lot.  The issues 
list itself needs updating, and there's not a lot of participation.  
I'm talking to Patrik and Ted and others about what we should focus on 
next now that ACLs is done. I'd welcome your feedback on this planning.

Lisa

On May 12, 2004, at 2:19 PM, Stanley Guan wrote:

> Lisa,
>
> I am looking at RFC2518 bis-05!
>
> My question is why list item separator (",") was
> not explicitly shown in the derivation rules.  Is
> it because it is implicitly implied?
>
> BTW, what's the current status RFC2518 bis?
>
> Thx,
>
> -Stanley
>
> ----- Original Message -----
> From: "Lisa Dusseault" <lisa@osafoundation.org>
> To: "Stanley Guan" <stanley.guan@oracle.com>
> Cc: <w3c-dist-auth@w3.org>
> Sent: Wednesday, May 12, 2004 10:04 AM
> Subject: Re: list item separator
>
>
>>
>> I'm a little confused.  Which document are you looking at, RFC2518 or
>> RFC2518 bis (and if so, which draft?)
>>
>> RFC2518 doesn't support commas in the If header, which is unfortunate
>> because it doesn't allow the sender to split the header up into 
>> several
>> headers. Normal HTTP composition rules allow the sender to do that, 
>> and
>> the entire header is reconstructed by adding in commas.
>>
>> Lisa
>>
>> On May 4, 2004, at 10:30 AM, Stanley Guan wrote:
>>
>>> As shown in the Example, list items are separated by ",".
>>> Is this implied by the notation "1*"?  Why "," is not
>>> explicitly specified in the derivation rules?  Can we use
>>> space character instead of "," as separator?
>>>
>>> Thx,
>>>
>>> -Stanley
>>>
>>>
>>> 9.5 If Header
>>>
>>>    If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
>>>    No-tag-list = List
>>>    Tagged-list = Resource 1*List
>>>    Resource = Coded-URL
>>>    List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
>>>    State-token = Coded-URL
>>>    Coded-URL = "<" absoluteURI ">"
>>>
>>> 9.5.4   Example - Tagged List If header
>>>
>>>      COPY /resource1 HTTP/1.1
>>>      Host: www.example.com
>>>      Destination: http://www.example.com/resource2
>>>      If: <http://www.example.com/resource1> (<locktoken:a-write-lock-
>>>      token> [W/"A weak ETag"]), (["strong ETag"]),
>>>      <http://www.bar.bar/random>(["another strong ETag"])
>>>
>>
>>
>



From w3c-dist-auth-request@w3.org  Wed May 19 15:59: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 PAA09648
	for <webdav-archive@lists.ietf.org>; Wed, 19 May 2004 15:59:36 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 71A48A1A09; Wed, 19 May 2004 15:59: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 B5F21A1A90
	for <w3c-dist-auth@listhub.w3.org>; Wed, 19 May 2004 15:59:35 -0400 (EDT)
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BQXDx-0002mG-8X
	for w3c-dist-auth@w3.org; Wed, 19 May 2004 15:59:33 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09632;
	Wed, 19 May 2004 15:59:29 -0400 (EDT)
Message-Id: <200405191959.PAA09632@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce: ;
Cc: w3c-dist-auth@w3.org, Patrik Faltstrom <paf@cisco.com>,
        Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 19 May 2004 15:59:28 -0400
Subject: WG Action: RECHARTER: WWW Distributed Authoring and Versioning (webdav)
X-Archived-At: http://www.w3.org/mid/200405191959.PAA09632@ietf.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8517
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: <20040519195937.71A48A1A09@frink.w3.org>
Resent-Date: Wed, 19 May 2004 15:59:37 -0400 (EDT)


The charter of the WWW Distributed Authoring and Versioning (webdav) working group 
in the Applications Area of the IETF has been updated. For additional information, 
please contact the Area Directors or the working group Chairs. 

WWW Distributed Authoring and Versioning (webdav)
=================================================

Current Status: Active Working Group

Chair(s):
Patrik Falstrom <paf@cisco.com>
Lisa Dusseault <lisa@xythos.com>

Applications Area Director(s):
Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>

Applications Area Advisor:
Ted Hardie <hardie@qualcomm.com>

Mailing Lists:
General Discussion: w3c-dist-auth@w3.org
To Subscribe: w3c-dist-auth-request@w3.org
In Body: Subject of subscribe
Archive: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/

Description of Working Group:

The goal of this working group is to define extensions to the Hypertext
Transfer Protocol (HTTP) that enable remote collaborative authoring of
Web resources. This is the third charter for
this Working Group, and does not include items
that have already been completed by this Working
Group (base WebDAV Proposed Standard, ordered
collections extension, and access control
extension).

When the WebDAV working group was initially formed, it was reacting to
experience from circa-1995/96 HTML authoring tools that showed they
were unable to meet their user's needs using the facilities of the HTTP
protocol. The observed consequences were either postponed introduction
of distributed authoring capability, or the addition of nonstandard
extensions to the HTTP protocol. These extensions, developed in
isolation, are not interoperable. The WebDAV Distributed Authoring
Protocol, RFC 2518, addressed these concerns by providing facilities for
overwrite prevention (locking), metadata management (properties), and
namespace management (copy, move, collections).

Despite their utility, several important capabilities were not supported
in the initial Distributed Authoring Protocol. It is a goal to create
protocols to support these capabilities:

* Referential Containment (Bindings): The WebDAV Distributed Authoring
 Protocol has unusual containment semantics where multiple containment
 is allowed, but not supported by any protocol operations, yet
 container deletion assumes inclusion containment, deleting the
 container and its members. Most object management systems provide
 full support for referential containment, and have delete semantics that
 only remove the container without affecting contained objects.

* Namespace Redirection (Redirect References): HTTP, via its 301 and
 302 responses, supports namespace redirection where a request on one
 URL is returned to the client with instructions to resubmit the same
 request to another URL.

As with most application layer protocols, implementation and field
experience on the WebDAV Distributed Authoring Protocol has highlighted
many issues that should be addressed as the protocol is advanced from
proposed to draft standard status. Some of these issues will require
additional deliberation within the WebDAV working group.

NOT IN SCOPE:

The following items were initially identified as being out of scope for
the WebDAV working group, and continue to be such:

* Definition of core attribute sets, beyond those attributes necessary
 for the implementation of distributed authoring and versioning
 functionality

* Creation of new authentication schemes

* HTTP server to server communication protocols

* Distributed authoring via protocols other than HTTP and SMTP

* Implementation of functionality by non-origin proxies

Deliverables

The further output of this working group is expected to be these
documents:

1. A Bindings Protocol, providing a specification of operations
 supporting referential containment for WebDAV collections. [Proposed
 Standard]

2. A Redirect References Protocol, providing a specification of
 operations for remote maintenance of namespace redirections, and the
 interaction of these redirections with existing HTTP and WebDAV
 methods. [Proposed Standard]

4. An updated version of WebDAV Distributed Authoring Protocol that
 resolves known issues with the protocol. [Draft Standard]

At present, the Binding Protocol and Redirect Reference protocols have
been through a WG last call but major changes were made and another
WG last call seems advised. The revision of the WebDAV Distributed
Authoring Protocol has been started.

In addition to the IETF Internet-Draft repository
(http://www.ietf.org/ID.html), the most recent versions of these
documents are accessible via links from the WebDAV Home Page,
(http://www.ics.uci.edu/pub/ietf/webdav/), and on WebDAV Resources,
(http://www.webdav.org/).

Goals and Milestones:
(including only goals not yet achieved as of 18/3/2004)

May 04 Revise Binding draft, submit as
internet-draft. Begin working group last call.
Jul 04 Revise Redirect references draft. Begin working group last call.
Sep 04 Revise Binding as necessary, submit to
IESG for approval as Proposed Standard.
Oct 04 Close more open issues in new draft of
revised base protocol (RFC2518bis). Consider WG
last call.
Oct 04 Revise Redirect references as necesssary,
submit to IESG for approval as Proposed Standard.
Dec 04 Submit revised base protocol (RFC2518bis)
to IESG for approval as Draft Standard.




From w3c-dist-auth-request@w3.org  Wed May 19 17:23: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 RAA18378
	for <webdav-archive@lists.ietf.org>; Wed, 19 May 2004 17:23:10 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id D9B15A0794; Wed, 19 May 2004 16:14:26 -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 C2FCFA0794
	for <w3c-dist-auth@listhub.w3.org>; Wed, 19 May 2004 16:14:20 -0400 (EDT)
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BQXQd-0005AG-2Q
	for w3c-dist-auth@w3.org; Wed, 19 May 2004 16:12:39 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10740;
	Wed, 19 May 2004 16:12:31 -0400 (EDT)
Message-Id: <200405192012.QAA10740@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce: ;
Cc: w3c-dist-auth@w3.org, Patrik Falstrom <paf@cisco.com>,
        Lisa Dusseault <lisa@xythos.com>
Date: Wed, 19 May 2004 16:12:30 -0400
Subject: WG Action: RECHARTER: WWW Distributed Authoring and Versioning (webdav)
X-Archived-At: http://www.w3.org/mid/200405192012.QAA10740@ietf.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8518
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: <20040519201426.D9B15A0794@frink.w3.org>
Resent-Date: Wed, 19 May 2004 16:14:26 -0400 (EDT)


The charter of the WWW Distributed Authoring and Versioning (webdav) working group
in the Applications Area of the IETF has been updated. For additional information,
please contact the Area Directors or the working group Chairs. 


WWW Distributed Authoring and Versioning (webdav)
=================================================

Current Status: Active Working Group

Chair(s):
Patrik Falstrom <paf@cisco.com>
Lisa Dusseault <lisa@xythos.com>

Applications Area Director(s):
Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>

Applications Area Advisor:
Ted Hardie <hardie@qualcomm.com>

Mailing Lists:
General Discussion: w3c-dist-auth@w3.org
To Subscribe: w3c-dist-auth-request@w3.org
In Body: Subject of subscribe
Archive: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/

Description of Working Group:

The goal of this working group is to define extensions to the Hypertext
Transfer Protocol (HTTP) that enable remote collaborative authoring of
Web resources. This is the third charter for
this Working Group, and does not include items
that have already been completed by this Working
Group (base WebDAV Proposed Standard, ordered
collections extension, and access control
extension).

When the WebDAV working group was initially formed, it was reacting to
experience from circa-1995/96 HTML authoring tools that showed they
were unable to meet their user's needs using the facilities of the HTTP
protocol. The observed consequences were either postponed introduction
of distributed authoring capability, or the addition of nonstandard
extensions to the HTTP protocol. These extensions, developed in
isolation, are not interoperable. The WebDAV Distributed Authoring
Protocol, RFC 2518, addressed these concerns by providing facilities for
overwrite prevention (locking), metadata management (properties), and
namespace management (copy, move, collections).

Despite their utility, several important capabilities were not supported
in the initial Distributed Authoring Protocol. It is a goal to create
protocols to support these capabilities:

* Referential Containment (Bindings): The WebDAV Distributed Authoring
 Protocol has unusual containment semantics where multiple containment
 is allowed, but not supported by any protocol operations, yet
 container deletion assumes inclusion containment, deleting the
 container and its members. Most object management systems provide
 full support for referential containment, and have delete semantics that
 only remove the container without affecting contained objects.

* Namespace Redirection (Redirect References): HTTP, via its 301 and
 302 responses, supports namespace redirection where a request on one
 URL is returned to the client with instructions to resubmit the same
 request to another URL.

As with most application layer protocols, implementation and field
experience on the WebDAV Distributed Authoring Protocol has highlighted
many issues that should be addressed as the protocol is advanced from
proposed to draft standard status. Some of these issues will require
additional deliberation within the WebDAV working group.

NOT IN SCOPE:

The following items were initially identified as being out of scope for
the WebDAV working group, and continue to be such:

* Definition of core attribute sets, beyond those attributes necessary
 for the implementation of distributed authoring and versioning
 functionality

* Creation of new authentication schemes

* HTTP server to server communication protocols

* Distributed authoring via protocols other than HTTP and SMTP

* Implementation of functionality by non-origin proxies

Deliverables

The further output of this working group is expected to be these
documents:

1. A Bindings Protocol, providing a specification of operations
 supporting referential containment for WebDAV collections. [Proposed
 Standard]

2. A Redirect References Protocol, providing a specification of
 operations for remote maintenance of namespace redirections, and the
 interaction of these redirections with existing HTTP and WebDAV
 methods. [Proposed Standard]

4. An updated version of WebDAV Distributed Authoring Protocol that
 resolves known issues with the protocol. [Draft Standard]

At present, the Binding Protocol and Redirect Reference protocols have
been through a WG last call but major changes were made and another
WG last call seems advised. The revision of the WebDAV Distributed
Authoring Protocol has been started.

In addition to the IETF Internet-Draft repository
(http://www.ietf.org/ID.html), the most recent versions of these
documents are accessible via links from the WebDAV Home Page,
(http://www.ics.uci.edu/pub/ietf/webdav/), and on WebDAV Resources,
(http://www.webdav.org/).

Goals and Milestones:
(including only goals not yet achieved as of 18/3/2004)

May 04 Revise Binding draft, submit as
internet-draft. Begin working group last call.
Jul 04 Revise Redirect references draft. Begin working group last call.
Sep 04 Revise Binding as necessary, submit to
IESG for approval as Proposed Standard.
Oct 04 Close more open issues in new draft of
revised base protocol (RFC2518bis). Consider WG
last call.
Oct 04 Revise Redirect references as necesssary,
submit to IESG for approval as Proposed Standard.
Dec 04 Submit revised base protocol (RFC2518bis)
to IESG for approval as Draft Standard.



From w3c-dist-auth-request@w3.org  Thu May 20 04:36:57 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 EAA05256
	for <webdav-archive@lists.ietf.org>; Thu, 20 May 2004 04:36:56 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id BF979A0932; Thu, 20 May 2004 04:36: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 90145A0E9C
	for <w3c-dist-auth@listhub.w3.org>; Thu, 20 May 2004 04:36:53 -0400 (EDT)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BQj2r-0001io-7x
	for w3c-dist-auth@w3.org; Thu, 20 May 2004 04:36:53 -0400
Received: (qmail 9924 invoked by uid 65534); 20 May 2004 08:36:21 -0000
Received: from p3EE24736.dip.t-dialin.net (EHLO [192.168.0.2]) (62.226.71.54)
  by mail.gmx.net (mp004) with SMTP; 20 May 2004 10:36:21 +0200
X-Authenticated: #1915285
Message-ID: <40AC6E03.1020902@gmx.de>
Date: Thu, 20 May 2004 10:36:19 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Noah Mendelsohn discusses impact of XML 1.1 on existing applications
X-Archived-At: http://www.w3.org/mid/40AC6E03.1020902@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8519
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: <20040520083657.BF979A0932@frink.w3.org>
Resent-Date: Thu, 20 May 2004 04:36:57 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Interesting read:

<http://lists.w3.org/Archives/Public/www-tag/2004May/0041.html>

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Fri May 21 16:46:29 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 QAA01074
	for <webdav-archive@lists.ietf.org>; Fri, 21 May 2004 16:46:27 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E4831A139E; Fri, 21 May 2004 16:46:26 -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 39BCAA16E4
	for <w3c-dist-auth@listhub.w3.org>; Fri, 21 May 2004 16:46:22 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BRGuL-0003iS-U5
	for w3c-dist-auth@w3c.org; Fri, 21 May 2004 16:46:22 -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 i4LKjCJL024025
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 21 May 2004 13:45:13 -0700
In-Reply-To: <40AE60E2.2030700@gmx.de>
References: <0HXX00HJS3QJ24@mailsj-v1.corp.adobe.com> <40ADD6A1.70406@gmx.de> <20040521120551.GA27507@mail.shareable.org> <2AC7237C-AB60-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE60E2.2030700@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <D7772F84-AB67-11D8-8F35-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: HTTP working group <ietf-http-wg@w3.org>,
        Jamie Lokier <jamie@shareable.org>, Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Fri, 21 May 2004 13:45:49 -0700
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: FYI: I-D ACTION:draft-dusseault-http-patch-02.txt
X-Archived-At: http://www.w3.org/mid/D7772F84-AB67-11D8-8F35-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8520
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: <20040521204626.E4831A139E@frink.w3.org>
Resent-Date: Fri, 21 May 2004 16:46:26 -0400 (EDT)
Content-Transfer-Encoding: 7bit


I'd like to see wider input before diverging from what I see as pretty 
standard practice.  Is OPTIONS * dead?  Is it useful?  Both?

I had always seen OPTIONS * to be very useful.  At Xythos, we went to a 
deal of effort to make it work even though the Xythos WFS was a java 
servlet-based technology.  Xythos WFS worked with clients that expected 
to find useful information in OPTIONS *, including the Xythos WFC 
(before that, Teamstream behaved the same way, I think).  The clients 
looked for features advertised in OPTIONS *, so that the client would 
know whether it would be worthwhile querying individual resources for 
further detail on supported features.

Some clients, like Microsoft clients, use OPTIONS '/', which can be 
just as hard or harder for the server to support than OPTIONS *.  And 
if the server doesn't advertise a major feature in OPTIONS * or OPTIONS 
/, then the client doesn't bother looking for the feature on individual 
URLs -- it's probably too prohibitive to do that roundtrip on every 
resource visited.  I think that a server implemented today that didn't 
put features in OPTIONS * or OPTIONS / would find that some clients 
failed to enable features that would otherwise be enabled.  This may be 
most true for WebDAV features like locking.

I'm now in the position of developing a WebDAV client from the ground 
up, rather than a server, as I've done before.  I assure you that the 
client would rather have some indication (in OPTIONS * or OPTIONS / or 
elsewhere) that a feature might be supported somewhere in the 
repository.  This is so that a GUI can show a button as enabled or 
disabled right away, as the client navigates through a bunch of 
resources.  For example, the "lock" button should be visible on the 
toolbar when the user is navigating a repository that might support 
locking somewhere -- but the "lock" button should be at least greyed 
out, if not absent, when the user is navigating a repository that 
doesn't support locking at all.

Developers hate uncertainty, but users are generally better at dealing 
with it than we think they are.  It's a principle of good user 
interface to show affordances for things that might be possible.  It's 
OK if the affordance doesn't work once in a while -- it's better than 
the user not to be allowed, or not to know, that they can even do the 
function in the first place.  That's why I think it's good for OPTIONS 
* to show that a feature like locking is available somewhere in the 
repository, even if it's not available everywhere.

Perhaps the solution is to fix the tools.  Java Servlets could easily 
have been designed to make OPTIONS * aggregate information from a 
number of servlets.  Reverse proxies could send OPTIONS * requests to 
the different servers and bundle the answers together, if the set is 
finite and known.  Or we could provide some way of responding to 
OPTIONS * with a specific advertised caveat that "this response does 
not have the list of features available in the repository(ies) that can 
be addressed at this server".

In any case, this issue affects PATCH no more than it affects any other 
HTTP extension.

Lisa

On May 21, 2004, at 1:04 PM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>
>> ...
>>> It also cannot be implemented in general over reverse-proxies which
>>> forward requests to different servers depending on the URL.
>>>
>> OPTIONS * is a difficult problem; I don't really have a solution to 
>> it, nor do I know of any consensus on "the right thing" to do about 
>> it.  The requirement is only a SHOULD, since obviously some 
>> implementations can't do this.
>
> I think it's understood that under many cirumstances, "OPTIONS *" will 
> simply not work. Making it a "SHOULD" requirement suggests to clients 
> that they reasonably can expect it to work most of the time; however 
> the *opposite* is true.
>
> Clients can not rely on "OPTIONS *" working as described, and it's 
> also not clear what the value of this feature is. The client can't 
> rely on PATCH being available on every resource, nor can it rely on 
> specific delta formats being supported on all resources.
>
> As such, it should be a "MAY", or even better, the description should 
> be removed altogether.
>
> If you disagree, I'd be interested to hear about a use case where the 
> response from "OPTIONS *" will indeed help the client in any way.
>
> Best regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Fri May 21 17:09: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 RAA03796
	for <webdav-archive@lists.ietf.org>; Fri, 21 May 2004 17:09:46 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 128FAA0940; Fri, 21 May 2004 17:09: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 9C977A06C5
	for <w3c-dist-auth@listhub.w3.org>; Fri, 21 May 2004 17:09:42 -0400 (EDT)
Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BRHGw-0007wp-8M
	for w3c-dist-auth@w3c.org; Fri, 21 May 2004 17:09:42 -0400
Received: (qmail 16022 invoked by uid 65534); 21 May 2004 21:09:06 -0000
Received: from pD9FF05EC.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.5.236)
  by mail.gmx.net (mp015) with SMTP; 21 May 2004 23:09:06 +0200
X-Authenticated: #1915285
Message-ID: <40AE6FEA.2060407@gmx.de>
Date: Fri, 21 May 2004 23:08:58 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: HTTP working group <ietf-http-wg@w3.org>,
        Jamie Lokier <jamie@shareable.org>, Webdav WG <w3c-dist-auth@w3c.org>
References: <0HXX00HJS3QJ24@mailsj-v1.corp.adobe.com> <40ADD6A1.70406@gmx.de> <20040521120551.GA27507@mail.shareable.org> <2AC7237C-AB60-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE60E2.2030700@gmx.de> <D7772F84-AB67-11D8-8F35-000A95B2BB72@osafoundation.org>
In-Reply-To: <D7772F84-AB67-11D8-8F35-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: FYI: I-D ACTION:draft-dusseault-http-patch-02.txt
X-Archived-At: http://www.w3.org/mid/40AE6FEA.2060407@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8521
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: <20040521210947.128FAA0940@frink.w3.org>
Resent-Date: Fri, 21 May 2004 17:09:47 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> I'd like to see wider input before diverging from what I see as pretty 
> standard practice.  Is OPTIONS * dead?  Is it useful?  Both?

It can't be both. As far as I'm concerned it doesn't work (or at least 
it doesn't do what you're asking it for).

> I had always seen OPTIONS * to be very useful.  At Xythos, we went to a 
> deal of effort to make it work even though the Xythos WFS was a java 
> servlet-based technology.  Xythos WFS worked with clients that expected 
> to find useful information in OPTIONS *, including the Xythos WFC 
> (before that, Teamstream behaved the same way, I think).  The clients 
> looked for features advertised in OPTIONS *, so that the client would 
> know whether it would be worthwhile querying individual resources for 
> further detail on supported features.

I've been working on both WebDAV server and client informations for over 
three years now, and I haven't *seen* any client making that request 
(and if some clients *did* make that request, they obviously proceeded 
without that information ok; otherwise I'd definitively had gotten 
customer complaints).

> Some clients, like Microsoft clients, use OPTIONS '/', which can be just 
> as hard or harder for the server to support than OPTIONS *.  And if the 

That's a known bug in older Microsoft clients; it has been fixed for a 
long time.

> server doesn't advertise a major feature in OPTIONS * or OPTIONS /, then 
> the client doesn't bother looking for the feature on individual URLs -- 
> it's probably too prohibitive to do that roundtrip on every resource 
> visited.  I think that a server implemented today that didn't put 
> features in OPTIONS * or OPTIONS / would find that some clients failed 
> to enable features that would otherwise be enabled.  This may be most 
> true for WebDAV features like locking.

I'm not aware of any such client except for the Microsoft Windows XP 
WebDAV Mini-Redirector (which does OPTIONS /), and in that case 
Microsoft has indeed acknowledged that this is a client bug: 
<http://support.microsoft.com/?kbid=831805>.

Besides, can we please distinguish between "*" and "/"? They are *very* 
different? "OPTIONS /" returns communication options for the root URL, 
this is well-defined and will work with any compliant server.

> I'm now in the position of developing a WebDAV client from the ground 
> up, rather than a server, as I've done before.  I assure you that the 
> client would rather have some indication (in OPTIONS * or OPTIONS / or 
> elsewhere) that a feature might be supported somewhere in the 
> repository.  This is so that a GUI can show a button as enabled or 
> disabled right away, as the client navigates through a bunch of 
> resources.  For example, the "lock" button should be visible on the 
> toolbar when the user is navigating a repository that might support 
> locking somewhere -- but the "lock" button should be at least greyed 
> out, if not absent, when the user is navigating a repository that 
> doesn't support locking at all.

Support for locking will vary across resources; this particular piece of 
information can better be obtained by using the "DAV:" header on the 
collection you're looking at 
(<http://greenbytes.de/tech/webdav/rfc2518.html#HEADER_DAV>).

BTW: so what will you do when the server does *not* support "OPTIONS *"?

> Developers hate uncertainty, but users are generally better at dealing 
> with it than we think they are.  It's a principle of good user interface 
> to show affordances for things that might be possible.  It's OK if the 
> affordance doesn't work once in a while -- it's better than the user not 
> to be allowed, or not to know, that they can even do the function in the 
> first place.  That's why I think it's good for OPTIONS * to show that a 
> feature like locking is available somewhere in the repository, even if 
> it's not available everywhere.

So exactly what do you do when the Allow header upon "OPTIONS *" doesn't 
contain LOCK? Enable or disable that button?

> Perhaps the solution is to fix the tools.  Java Servlets could easily 
> have been designed to make OPTIONS * aggregate information from a number 
> of servlets.  Reverse proxies could send OPTIONS * requests to the 
> different servers and bundle the answers together, if the set is finite 
> and known.  Or we could provide some way of responding to OPTIONS * with 
> a specific advertised caveat that "this response does not have the list 
> of features available in the repository(ies) that can be addressed at 
> this server".
> 
> In any case, this issue affects PATCH no more than it affects any other 
> HTTP extension.

That's correct; however other specifications are simply silent about 
that topic, while the current text for PATCH makes the impression that 
this is a feature that's going to work in some reliable fashion. This is 
simply incorrect.

Regards, Julian

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



From w3c-dist-auth-request@w3.org  Sat May 22 02:56: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 CAA16286
	for <webdav-archive@lists.ietf.org>; Sat, 22 May 2004 02:56:04 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 42857A2B6F; Sat, 22 May 2004 02:56: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 419A9A2BA2
	for <w3c-dist-auth@listhub.w3.org>; Sat, 22 May 2004 02:55:59 -0400 (EDT)
Received: from mx1.igatecorp.com ([12.34.23.20])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BRQQG-0004S9-8D
	for w3c-dist-auth@w3c.org; Sat, 22 May 2004 02:55:56 -0400
Received: from delta.igatecorp.com (delta.igatecorp.com [192.168.70.100])
	by mx1.igatecorp.com (8.11.6/8.11.6) with ESMTP id i4M7Gjg52125
	for <w3c-dist-auth@w3c.org>; Sat, 22 May 2004 03:16:45 -0400 (EDT)
Received: from igteblrexc04.igatecorp.com ([192.168.210.113]) by delta.igatecorp.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Sat, 22 May 2004 02:55:25 -0400
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C43FC9.B2803E33"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Sat, 22 May 2004 12:24:58 +0530
Message-ID: <FCE110FFAA26324686F5A3F1954D00DA0A11E7@igteblrexc01.igatecorp.com>
Thread-Topic: unsubscriibe
Thread-Index: AcQ/ybJ6Ck9Zv83YRyG0sV5HdIOssw==
From: "Gangadhar Pai" <Gangadhar.Pai@igate.com>
To: <w3c-dist-auth@w3c.org>
X-OriginalArrivalTime: 22 May 2004 06:55:25.0514 (UTC) FILETIME=[C25E1AA0:01C43FC9]
Subject: unsubscriibe
X-Archived-At: http://www.w3.org/mid/FCE110FFAA26324686F5A3F1954D00DA0A11E7@igteblrexc01.igatecorp.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8522
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: <20040522065602.42857A2B6F@frink.w3.org>
Resent-Date: Sat, 22 May 2004 02:56:02 -0400 (EDT)


This is a multi-part message in MIME format.

------_=_NextPart_001_01C43FC9.B2803E33
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20

Gangadhar Pai=20
|Project Manager| iGATE Global Solutions | Office: +91-80-251104731 xtn  =
148 | Mobile: +91 98441 86314 | Fax: +91-80-25527594 | email: =
gangadhar.pai@igate.com < mailto:gangadhar.pai@igate.com> | Website: < =
http://paionline.tripod.com <http://paionline.tripod.com/> > |

=20

=20

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

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


<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<P><FONT face=3DVerdana color=3D#959595 size=3D1></FONT></P>
<P><B><FONT face=3DVerdana size=3D2>Gangadhar Pai</FONT></B> =
<BR><B><FONT face=3DVe=20
color=3D#000000 size=3D1>|Project Manager| iGATE Global Solutions |=20
Office:</FONT></B><FONT face=3DVe color=3D#000000 size=3D1></FONT><B> =
<FONT face=3DVe=20
color=3D#000000 size=3D1>+91-80-251104731</FONT></B><FONT face=3DVe =
color=3D#000000=20
size=3D1></FONT><B> <FONT face=3DVe color=3D#000000 size=3D1>xtn&nbsp; =
148 |=20
Mobile:</FONT></B><FONT face=3DVe color=3D#000000 size=3D1> =
+91</FONT><B><FONT face=3DVe=20
color=3D#000000 size=3D1> 98441 86314</FONT></B><FONT face=3DVe =
color=3D#000000 size=3D1>=20
|</FONT><B> <FONT face=3DVe color=3D#000000 size=3D1>Fax: =
+91-80-25527594</FONT></B>=20
<FONT face=3DVe color=3D#000000 size=3D1>| email:</FONT><U></U><U><B> =
<FONT face=3DVe=20
color=3D#0000ff size=3D1>gangadhar.pai@igate.com &lt;<A=20
href=3D"mailto:gangadhar.pai@igate.com">mailto:gangadhar.pai@igate.com</A=
>&gt;</FONT></B></U><B></B><FONT=20
face=3DVe color=3D#000000 size=3D1> | Website:</FONT><U> <FONT face=3DVe =
color=3D#0000ff=20
size=3D1>&lt;<A href=3D"http://paionline.tripod.com/"=20
target=3D_blank>http://paionline.tripod.com</A>&gt;</FONT></U><FONT =
face=3DVe=20
color=3D#000000 size=3D1> |</FONT></P>
<P>&nbsp;</P>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C43FC9.B2803E33--



From w3c-dist-auth-request@w3.org  Sun May 23 16:39: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 QAA05328
	for <webdav-archive@lists.ietf.org>; Sun, 23 May 2004 16:39:59 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E1397A18AC; Sun, 23 May 2004 16: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 86662A19DA
	for <w3c-dist-auth@listhub.w3.org>; Sun, 23 May 2004 16:39:57 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BRzlF-0001PK-4G
	for w3c-dist-auth@w3.org; Sun, 23 May 2004 16:39:57 -0400
Received: (qmail 20608 invoked by uid 65534); 23 May 2004 20:39:25 -0000
Received: from pD9FF0D0B.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.13.11)
  by mail.gmx.net (mp006) with SMTP; 23 May 2004 22:39:25 +0200
X-Authenticated: #1915285
Message-ID: <40B10BEE.1090703@gmx.de>
Date: Sun, 23 May 2004 22:39:10 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
Cc: w3c-dist-auth@w3.org, acl@webdav.org
References: <409A9815.50906@gmx.de>
In-Reply-To: <409A9815.50906@gmx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [ACL] WebDAV Access Control Protocol published as RFC3744
X-Archived-At: http://www.w3.org/mid/40B10BEE.1090703@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8523
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: <20040523203959.E1397A18AC@frink.w3.org>
Resent-Date: Sun, 23 May 2004 16:39:59 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi,

now that the ACL spec is published, we *should* create a new place for 
collecting spec issues (and hopefully their resolutions). For instance, 
this would include the last-minute change that in we end we did not do:

	<http://mailman.webdav.org/pipermail/acl/2004-April/001817.html>

For me the simplest way to do this is to create a document 
"draft-reschke-rfc3744bis" (starting with a copy of RFC3744), and add 
issue markers to the spec itself. I can then automatically create an 
issue list document.

If there aren't any objections to that approach, I'll implement that 
sometime next week.

Best regards,

Julian

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



From w3c-dist-auth-request@w3.org  Mon May 24 07:17: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 HAA27650
	for <webdav-archive@lists.ietf.org>; Mon, 24 May 2004 07:17:25 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A26BAA3001; Mon, 24 May 2004 07:17: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 440ABA2D57
	for <w3c-dist-auth@listhub.w3.org>; Mon, 24 May 2004 07:17:22 -0400 (EDT)
Received: from e2.ny.us.ibm.com ([32.97.182.102])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BSDSM-0001hj-7R
	for w3c-dist-auth@w3.org; Mon, 24 May 2004 07:17:22 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i4OBGmTW459088;
	Mon, 24 May 2004 07:16:48 -0400
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4OBHS8d103858;
	Mon, 24 May 2004 07:17:28 -0400
In-Reply-To: <40B10BEE.1090703@gmx.de>
To: acl@webdav.org, w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF982E6D04.8792E7DE-ON85256E9E.003DDB33-85256E9E.003DF892@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Mon, 24 May 2004 07:16:49 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF267 | May 20, 2004) at
 05/24/2004 07:16:42,
	Serialize complete at 05/24/2004 07:16:42
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: [ACL] WebDAV Access Control Protocol published as RFC3744
X-Archived-At: http://www.w3.org/mid/OF982E6D04.8792E7DE-ON85256E9E.003DDB33-85256E9E.003DF892@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8524
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: <20040524111724.A26BAA3001@frink.w3.org>
Resent-Date: Mon, 24 May 2004 07:17:24 -0400 (EDT)


Sounds good to me.
Cheers,
Geoff

Julian wrote on 05/23/2004 04:39:10 PM:
> now that the ACL spec is published, we *should* create a new place for 
> collecting spec issues (and hopefully their resolutions). For instance, 
> this would include the last-minute change that in we end we did not do:
> 
>    <http://mailman.webdav.org/pipermail/acl/2004-April/001817.html>
> 
> For me the simplest way to do this is to create a document 
> "draft-reschke-rfc3744bis" (starting with a copy of RFC3744), and add 
> issue markers to the spec itself. I can then automatically create an 
> issue list document.
> 
> If there aren't any objections to that approach, I'll implement that 
> sometime next week.



From w3c-dist-auth-request@w3.org  Mon May 24 10:51:52 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 KAA11403
	for <webdav-archive@lists.ietf.org>; Mon, 24 May 2004 10:51:52 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 6E7D9A082E; Mon, 24 May 2004 10:51: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 88C13A21B7
	for <w3c-dist-auth@listhub.w3.org>; Mon, 24 May 2004 10:51:49 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BSGnN-0005tw-9u
	for w3c-dist-auth@w3.org; Mon, 24 May 2004 10:51:17 -0400
Received: (qmail 14141 invoked by uid 65534); 24 May 2004 14:50:44 -0000
Received: from p50824FA6.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.79.166)
  by mail.gmx.net (mp003) with SMTP; 24 May 2004 16:50:44 +0200
X-Authenticated: #1915285
Message-ID: <40B20BBD.6070609@gmx.de>
Date: Mon, 24 May 2004 16:50:37 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Issue 079_UNLOCK_BY_NON_LOCK_OWNER
X-Archived-At: http://www.w3.org/mid/40B20BBD.6070609@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8525
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: <20040524145152.6E7D9A082E@frink.w3.org>
Resent-Date: Mon, 24 May 2004 10:51:52 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi,

while I was looking for the resolution for 
"079_UNLOCK_BY_NON_LOCK_OWNER", I came across the following text in bis-05:

> 8.12    UNLOCK Method 
>     
>    The UNLOCK method removes the lock identified by the lock token in 
>    the Lock-Token request header from the Request-URI and all other 
>    resources included in the lock.  The root of the lock MUST be named 
>    by the Request-URI, not any other resource within the scope of the 
>    lock.  Servers SHOULD redirect the UNLOCK request to the lock root.  
>    Failing that, servers MAY fail an UNLOCK request to a resource that 
>    is not directly locked (not the root of the lock) with error code 
>    400 (Bad Request). 


1) It should say "...in the Lock-Token request header from the resource 
identified by the Request-URI and all other resources included in the 
lock." (old text from RFC2518)

2) "The root of the lock MUST be named by the Request-URI, not any other 
resource within the scope of the lock.": What is this supposed to mean? 
That the Request-URI MUST identify the lock root? I think this needs 
clarification.

3) "Servers SHOULD redirect the UNLOCK request to the lock root. Failing 
that, servers MAY fail an UNLOCK request to a resource that is not 
directly locked (not the root of the lock) with error code 400 (Bad 
Request).": Again, I'm not sure what this is supposed to mean. If the 
resource identified by the Request-URI is not the lock root, it seems 
that the previous statement REQUIRES the server to fail the request, not 
to do a "redirect" (what kind of redirect would that be?).

Back to issue "079_UNLOCK_BY_NON_LOCK_OWNER":

"Resolved in part by putting it under ACL control: 
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0002.html 
and the response that follows it."

The referenced mailing list entry indicates that we want text to be 
added to the spec, yet I can't find in in bis-05 (al least not under 
UNLOCK).

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Mon May 24 11:27: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 LAA13825
	for <webdav-archive@lists.ietf.org>; Mon, 24 May 2004 11:27:59 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id EA270A0A84; Mon, 24 May 2004 11:27: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 61C67A06F4
	for <w3c-dist-auth@listhub.w3.org>; Mon, 24 May 2004 11:27:57 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BSHLK-0003qL-HZ
	for w3c-dist-auth@w3.org; Mon, 24 May 2004 11:26:22 -0400
Received: (qmail 5348 invoked by uid 65534); 24 May 2004 15:25:51 -0000
Received: from p50824FA6.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.79.166)
  by mail.gmx.net (mp011) with SMTP; 24 May 2004 17:25:51 +0200
X-Authenticated: #1915285
Message-ID: <40B213FE.8030606@gmx.de>
Date: Mon, 24 May 2004 17:25:50 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Issue 60: LOCK_REFRESH_BODY
X-Archived-At: http://www.w3.org/mid/40B213FE.8030606@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8526
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: <20040524152759.EA270A0A84@frink.w3.org>
Resent-Date: Mon, 24 May 2004 11:27:59 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi,

the issue...:

"Section 7.8 of RFC 2518 indicates that clients may submit a lock 
refresh without a body. However, it implies that clients could submit a 
lock refresh with a body. Server implementations have been disallowing a 
lock refresh with a body. It might make sense to codify this practice, 
and disallow submission of a body on a lock refresh.

Raised by Rickard Falk:
http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JulSep/0039.html"

I'd like to confirm that we agree on

- a LOCK creation request MUST have a request body and MUST NOT have a 
Lock-Token request header

- a LOCK refresh request MUST NOT have a request body and MUST have a 
Lock-Token request header


Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Tue May 25 17:13: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 RAA20561
	for <webdav-archive@lists.ietf.org>; Tue, 25 May 2004 17:13:28 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 2E817A060B; Tue, 25 May 2004 17:13: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 F2C00A066B
	for <w3c-dist-auth@listhub.w3.org>; Tue, 25 May 2004 17:13:26 -0400 (EDT)
Received: from agminet03.oracle.com ([141.146.126.230])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BSjEk-0000jw-UD
	for w3c-dist-auth@w3.org; Tue, 25 May 2004 17:13:27 -0400
Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.191.12])
	by agminet03.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i4PL9KMU012417
	for <w3c-dist-auth@w3.org>; Tue, 25 May 2004 14:10:28 -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 i4PL9KR0021375
	for <w3c-dist-auth@w3.org>; Tue, 25 May 2004 15:09:20 -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 i4PL9Klr021371
	for <w3c-dist-auth@w3.org>; Tue, 25 May 2004 15:09:20 -0600
Message-ID: <0c2f01c4429b$e3ea6550$c5b42382@us.oracle.com>
From: "Stanley Guan" <stanley.guan@oracle.com>
To: <w3c-dist-auth@w3.org>
Date: Tue, 25 May 2004 14:04:38 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0C2C_01C44261.3762F6B0"
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: locks with depth of infinity treated as depth of 1
X-Archived-At: http://www.w3.org/mid/0c2f01c4429b$e3ea6550$c5b42382@us.oracle.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8527
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: <20040525211330.2E817A060B@frink.w3.org>
Resent-Date: Tue, 25 May 2004 17:13:30 -0400 (EDT)


This is a multi-part message in MIME format.

------=_NextPart_000_0C2C_01C44261.3762F6B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

 If a server's implementation decides to treat locks with depth of
infinity as depth of 1, what's the recommended way for a=20
server receiving requests of locks with depth of infinity?

1) reject it and responded with detailed information
2) accept it silently
3) or others?

What's the recommended way for the servers to reveal the above
fact programmatically?

Thx,

-Stanley


------=_NextPart_000_0C2C_01C44261.3762F6B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>&nbsp;If a server's implementation =
decides to treat=20
locks with depth of</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>infinity as depth of 1, what's the =
recommended way=20
for a </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>server receiving requests of locks with =
depth of=20
infinity?</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><FONT=20
color=3D#000000></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><FONT =
color=3D#000000>1) reject it and=20
responded with detailed information</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>2) accept it silently</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>3) or others?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>What's the recommended way for the =
servers to=20
reveal the above</FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2>fact =
programmatically?</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thx,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>-Stanley</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0C2C_01C44261.3762F6B0--



From w3c-dist-auth-request@w3.org  Tue May 25 20:03: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 UAA09014
	for <webdav-archive@lists.ietf.org>; Tue, 25 May 2004 20:03:22 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id CB144A0603; Tue, 25 May 2004 20:03: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 4774DA0BC9
	for <w3c-dist-auth@listhub.w3.org>; Tue, 25 May 2004 20:03:20 -0400 (EDT)
Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BSltA-0008QX-0z
	for w3c-dist-auth@w3.org; Tue, 25 May 2004 20:03:20 -0400
Received: (qmail 31917 invoked by uid 65534); 26 May 2004 00:02:47 -0000
Received: from pD9E51264.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.18.100)
  by mail.gmx.net (mp026) with SMTP; 26 May 2004 02:02:47 +0200
X-Authenticated: #1915285
Message-ID: <40B3DEA4.9000705@gmx.de>
Date: Wed, 26 May 2004 02:02:44 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stanley Guan <stanley.guan@oracle.com>
Cc: w3c-dist-auth@w3.org
References: <0c2f01c4429b$e3ea6550$c5b42382@us.oracle.com>
In-Reply-To: <0c2f01c4429b$e3ea6550$c5b42382@us.oracle.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: locks with depth of infinity treated as depth of 1
X-Archived-At: http://www.w3.org/mid/40B3DEA4.9000705@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8528
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: <20040526000322.CB144A0603@frink.w3.org>
Resent-Date: Tue, 25 May 2004 20:03:22 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Stanley Guan wrote:
>  If a server's implementation decides to treat locks with depth of
> infinity as depth of 1, what's the recommended way for a
> server receiving requests of locks with depth of infinity?

I'd say that's a bug.

> 1) reject it and responded with detailed information

Yes.

> 2) accept it silently

Never.

> 3) or others?
>  
> What's the recommended way for the servers to reveal the above
> fact programmatically?

No idea. What's the benefit of a depth: 1 lock??? Maybe this is just a 
misunderstanding, and what you really want is a depth: 0 lock on a 
collection?

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Thu May 27 05:30: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 FAA10155
	for <webdav-archive@lists.ietf.org>; Thu, 27 May 2004 05:30:10 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 9C915A05D5; Thu, 27 May 2004 05:30: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 F3E7BA1E6D
	for <w3c-dist-auth@listhub.w3.org>; Thu, 27 May 2004 05:30:07 -0400 (EDT)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BTHDD-0005qO-IY
	for w3c-dist-auth@w3.org; Thu, 27 May 2004 05:30:07 -0400
Received: (qmail 2103 invoked by uid 65534); 27 May 2004 09:29:35 -0000
Received: from p50824161.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.65.97)
  by mail.gmx.net (mp006) with SMTP; 27 May 2004 11:29:35 +0200
X-Authenticated: #1915285
Message-ID: <40B5B4FD.4060902@gmx.de>
Date: Thu, 27 May 2004 11:29:33 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: acl@webdav.org, w3c-dist-auth@w3.org
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
References: <OF982E6D04.8792E7DE-ON85256E9E.003DDB33-85256E9E.003DF892@us.ibm.com>
In-Reply-To: <OF982E6D04.8792E7DE-ON85256E9E.003DDB33-85256E9E.003DF892@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [ACL] WebDAV Access Control Protocol published as RFC3744
X-Archived-At: http://www.w3.org/mid/40B5B4FD.4060902@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8529
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: <20040527093011.9C915A05D5@frink.w3.org>
Resent-Date: Thu, 27 May 2004 05:30:11 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Geoffrey M Clemm wrote:

> Sounds good to me.
> Cheers,
> Geoff
> 
> Julian wrote on 05/23/2004 04:39:10 PM:
> 
>>now that the ACL spec is published, we *should* create a new place for 
>>collecting spec issues (and hopefully their resolutions). For instance, 
>>this would include the last-minute change that in we end we did not do:
>>
>>   <http://mailman.webdav.org/pipermail/acl/2004-April/001817.html>
>>
>>For me the simplest way to do this is to create a document 
>>"draft-reschke-rfc3744bis" (starting with a copy of RFC3744), and add 
>>issue markers to the spec itself. I can then automatically create an 
>>issue list document.
>>
>>If there aren't any objections to that approach, I'll implement that 
>>sometime next week.

OK, the issues list is online at 
<http://greenbytes.de/tech/webdav/draft-reschke-rfc3744bis-latest.html> 
(you may want to link from webdav.org/acl to it, Geoff).

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Mon May 31 09:14: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 JAA18607
	for <webdav-archive@lists.ietf.org>; Mon, 31 May 2004 09:14:18 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E351EA16A7; Mon, 31 May 2004 09:14:18 -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 33EF1A16A7
	for <w3c-dist-auth@listhub.w3.org>; Mon, 31 May 2004 09:14:14 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BUmcI-0002ee-15
	for w3c-dist-auth@w3.org; Mon, 31 May 2004 09:14:14 -0400
Received: (qmail 16731 invoked by uid 65534); 31 May 2004 13:13:42 -0000
Received: from pD9FF0FE2.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.15.226)
  by mail.gmx.net (mp017) with SMTP; 31 May 2004 15:13:42 +0200
X-Authenticated: #1915285
Message-ID: <40BB2F7D.3060606@gmx.de>
Date: Mon, 31 May 2004 15:13:33 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: GULP 5.6 vs issue UNLOCK_WHAT_URL (65)
X-Archived-At: http://www.w3.org/mid/40BB2F7D.3060606@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8530
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: <20040531131418.E351EA16A7@frink.w3.org>
Resent-Date: Mon, 31 May 2004 09:14:18 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Hi,

I just noticed that in

<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0001.html>

we write...:

   "An UNLOCK request deletes the lock with the specified lock token.
   The request-URL of the request MUST identify the resource that
   is directly locked by that lock.  After a lock is deleted,
   no resource is locked by that lock."

This was a change to the previous GULP version. However, the discussion 
attached to issue entry UNLOCK_WHAT_URL 
(<http://www.webdav.org/wg/rfcdev/issues.htm>) seems to indicate that we 
agreed upon allowing any URL protected by the lock to be used as request 
URL.

1) We should agree on one of the two; and fix the other document 
accordingly.

2) RFC2518 seems to allow both interpretations:

    "The UNLOCK method removes the lock identified by the lock token
    in the Lock-Token request header from the Request-URI, and all
    other resources included in the lock."

3) Back when I tested this, both Apache/moddav and Xythos were 
implementing this, and so are we (I think). Microsoft IIS doesn't 
support deep locks, so it's not relevant here.

Therefore it seems that we should undo that particular change from GULP 
5.5 for the sake of interoperability with older clients that may rely on 
it (this seems to be harmless).

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Mon May 31 09:21:44 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 JAA18841
	for <webdav-archive@lists.ietf.org>; Mon, 31 May 2004 09:21:44 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 36901A216F; Mon, 31 May 2004 09:21: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 3A609A216F
	for <w3c-dist-auth@listhub.w3.org>; Mon, 31 May 2004 09:21: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.31)
	id 1BUmjW-0004FJ-2U
	for w3c-dist-auth@w3.org; Mon, 31 May 2004 09:21:42 -0400
Received: (qmail 17597 invoked by uid 65534); 31 May 2004 13:21:10 -0000
Received: from pD9FF0FE2.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.15.226)
  by mail.gmx.net (mp009) with SMTP; 31 May 2004 15:21:10 +0200
X-Authenticated: #1915285
Message-ID: <40BB313D.6020107@gmx.de>
Date: Mon, 31 May 2004 15:21:01 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
Cc: w3c-dist-auth@w3.org
References: <40B213FE.8030606@gmx.de>
In-Reply-To: <40B213FE.8030606@gmx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issue 60: LOCK_REFRESH_BODY
X-Archived-At: http://www.w3.org/mid/40BB313D.6020107@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8531
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: <20040531132144.36901A216F@frink.w3.org>
Resent-Date: Mon, 31 May 2004 09:21:44 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Julian Reschke wrote:

> 
> Hi,
> 
> the issue...:
> 
> "Section 7.8 of RFC 2518 indicates that clients may submit a lock 
> refresh without a body. However, it implies that clients could submit a 
> lock refresh with a body. Server implementations have been disallowing a 
> lock refresh with a body. It might make sense to codify this practice, 
> and disallow submission of a body on a lock refresh.
> 
> Raised by Rickard Falk:
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JulSep/0039.html"
> 
> I'd like to confirm that we agree on
> 
> - a LOCK creation request MUST have a request body and MUST NOT have a 
> Lock-Token request header
> 
> - a LOCK refresh request MUST NOT have a request body and MUST have a 
> Lock-Token request header

As nobody spoke up, I'll conclude that this is indeed the case. Jason, 
could you please update the issues list accordingly?

Best regards, Julian


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



From w3c-dist-auth-request@w3.org  Mon May 31 09:52:24 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 JAA20640
	for <webdav-archive@lists.ietf.org>; Mon, 31 May 2004 09:52:24 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 1F7C3A21C5; Mon, 31 May 2004 09:52: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 A8BBBA21C5
	for <w3c-dist-auth@listhub.w3.org>; Mon, 31 May 2004 09:52:20 -0400 (EDT)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.31)
	id 1BUnDA-0000OU-E5
	for w3c-dist-auth@w3.org; Mon, 31 May 2004 09:52:20 -0400
Received: (qmail 28850 invoked by uid 65534); 31 May 2004 13:51:49 -0000
Received: from pD9FF0FE2.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.15.226)
  by mail.gmx.net (mp021) with SMTP; 31 May 2004 15:51:49 +0200
X-Authenticated: #1915285
Message-ID: <40BB386B.4040807@gmx.de>
Date: Mon, 31 May 2004 15:51:39 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <40BB2F7D.3060606@gmx.de>
In-Reply-To: <40BB2F7D.3060606@gmx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: GULP 5.6 vs issue UNLOCK_WHAT_URL (65)
X-Archived-At: http://www.w3.org/mid/40BB386B.4040807@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8532
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: <20040531135225.1F7C3A21C5@frink.w3.org>
Resent-Date: Mon, 31 May 2004 09:52:25 -0400 (EDT)
Content-Transfer-Encoding: 7bit


Julian Reschke wrote:

> I just noticed that in
> 
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0001.html>
> 
> we write...:
> 
>   "An UNLOCK request deletes the lock with the specified lock token.
>   The request-URL of the request MUST identify the resource that
>   is directly locked by that lock.  After a lock is deleted,
>   no resource is locked by that lock."
> 
> This was a change to the previous GULP version. However, the discussion 
> attached to issue entry UNLOCK_WHAT_URL 
> (<http://www.webdav.org/wg/rfcdev/issues.htm>) seems to indicate that we 
> agreed upon allowing any URL protected by the lock to be used as request 
> URL.
> 
> 1) We should agree on one of the two; and fix the other document 
> accordingly.
> 
> 2) RFC2518 seems to allow both interpretations:
> 
>    "The UNLOCK method removes the lock identified by the lock token
>    in the Lock-Token request header from the Request-URI, and all
>    other resources included in the lock."
> 
> 3) Back when I tested this, both Apache/moddav and Xythos were 
> implementing this, and so are we (I think). Microsoft IIS doesn't 
> support deep locks, so it's not relevant here.
> 
> Therefore it seems that we should undo that particular change from GULP 
> 5.5 for the sake of interoperability with older clients that may rely on 
> it (this seems to be harmless).

Adding to the confusion, I just find out that RFC2518bis-05 says it 
needs to be directly locked as well (well, I guess it *tries* to say 
that, see... 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0115.html>).

Can we please make a decision *and* make sure that it's tracked on the 
issues list? An issues list that is not only out of sync but even 
contradicts the latest draft really doesn't help much :-)

Best regards, Julian

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



From w3c-dist-auth-request@w3.org  Mon May 31 12:18: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 MAA28743
	for <webdav-archive@lists.ietf.org>; Mon, 31 May 2004 12:18:01 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A327FA11DD; Mon, 31 May 2004 12:18: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 A1C11A11DD
	for <w3c-dist-auth@listhub.w3.org>; Mon, 31 May 2004 12:18:00 -0400 (EDT)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BUpU8-0007ap-HH
	for w3c-dist-auth@w3.org; Mon, 31 May 2004 12:18:00 -0400
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i4VGHxVu001780 sender ccjason@us.ibm.com for w3c-dist-auth@w3.org; Mon, 31 May 2004 09:17:59 -0700
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by bandage.seagull.net (8.12.10) with ESMTP id i4VGHvxE001731 sender ccjason@us.ibm.com; Mon, 31 May 2004 09:17:58 -0700
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i4VGHl61752452; Mon, 31 May 2004 12:17:47 -0400
Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4VGIZ1s070930; Mon, 31 May 2004 12:18:35 -0400
To: nnw3c-dist-auth___at___w3.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: <OF69E1FEC8.FE014514-ON85256EA5.0057886E-85256EA5.00598006@us.ibm.com>
Date: Mon, 31 May 2004 12:17:36 -0400
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF199 | April 27, 2004) at 05/31/2004 12:17:46, Serialize complete at 05/31/2004 12:17:46
Content-Type: multipart/alternative; boundary="=_alternative 00589CD085256EA5_="
Subject: Re: Issue 60: LOCK_REFRESH_BODY
X-Archived-At: http://www.w3.org/mid/OF69E1FEC8.FE014514-ON85256EA5.0057886E-85256EA5.00598006@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8533
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: <20040531161802.A327FA11DD@frink.w3.org>
Resent-Date: Mon, 31 May 2004 12:18:02 -0400 (EDT)


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

> > the issue...:
> >
> > "Section 7.8 of RFC 2518 indicates that clients may submit a lock
> > refresh without a body. However, it implies that clients could submit 
a
> > lock refresh with a body. Server implementations have been disallowing 
a
> > lock refresh with a body. It might make sense to codify this practice,
> > and disallow submission of a body on a lock refresh.
> >
> > Raised by Rickard Falk:
> > 
http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JulSep/0039.html"
> >
> > I'd like to confirm that we agree on
> >
> > - a LOCK creation request MUST have a request body and MUST NOT have a
> > Lock-Token request header
> >
> > - a LOCK refresh request MUST NOT have a request body and MUST have a
> > Lock-Token request header
> 
> As nobody spoke up, I'll conclude that this is indeed the case. Jason,
> could you please update the issues list accordingly?

Julian seem to support this.  I'll offer a weak vote of support.  Let's 
hear one more voice.

J.

--=_alternative 00589CD085256EA5_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">&gt; &gt; the issue...:<br>
&gt; &gt;<br>
&gt; &gt; &quot;Section 7.8 of RFC 2518 indicates that clients may submit a lock<br>
&gt; &gt; refresh without a body. However, it implies that clients could submit a<br>
&gt; &gt; lock refresh with a body. Server implementations have been disallowing a<br>
&gt; &gt; lock refresh with a body. It might make sense to codify this practice,<br>
&gt; &gt; and disallow submission of a body on a lock refresh.<br>
&gt; &gt;<br>
&gt; &gt; Raised by Rickard Falk:<br>
&gt; &gt; http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JulSep/0039.html&quot;<br>
&gt; &gt;<br>
&gt; &gt; I'd like to confirm that we agree on<br>
&gt; &gt;<br>
&gt; &gt; - a LOCK creation request MUST have a request body and MUST NOT have a<br>
&gt; &gt; Lock-Token request header<br>
&gt; &gt;<br>
&gt; &gt; - a LOCK refresh request MUST NOT have a request body and MUST have a<br>
&gt; &gt; Lock-Token request header<br>
&gt; <br>
&gt; As nobody spoke up, I'll conclude that this is indeed the case. Jason,<br>
&gt; could you please update the issues list accordingly?</font>
<br>
<br><font size=2 face="sans-serif">Julian seem to support this. &nbsp;I'll offer a weak vote of support. &nbsp;Let's hear one more voice.</font>
<br>
<br><font size=2 face="sans-serif">J.</font>
<br>
--=_alternative 00589CD085256EA5_=--



From w3c-dist-auth-request@w3.org  Mon May 31 12:22:43 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 MAA28962
	for <webdav-archive@lists.ietf.org>; Mon, 31 May 2004 12:22:42 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id F3C9FA13D0; Mon, 31 May 2004 12:22: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 0AE17A13D0
	for <w3c-dist-auth@listhub.w3.org>; Mon, 31 May 2004 12:22:40 -0400 (EDT)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BUpYd-0008Mr-VQ
	for w3c-dist-auth@w3c.org; Mon, 31 May 2004 12:22:40 -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 i4VGLGJL007375
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 31 May 2004 09:21:18 -0700
In-Reply-To: <OF69E1FEC8.FE014514-ON85256EA5.0057886E-85256EA5.00598006@us.ibm.com>
References: <OF69E1FEC8.FE014514-ON85256EA5.0057886E-85256EA5.00598006@us.ibm.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: multipart/alternative; boundary=Apple-Mail-14-339133596
Message-Id: <A238FE58-B31E-11D8-ACE9-000A95B2BB72@osafoundation.org>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 31 May 2004 09:21:55 -0700
To: Jason Crawford <ccjason@us.ibm.com>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: Issue 60: LOCK_REFRESH_BODY
X-Archived-At: http://www.w3.org/mid/A238FE58-B31E-11D8-ACE9-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8534
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: <20040531162243.F3C9FA13D0@frink.w3.org>
Resent-Date: Mon, 31 May 2004 12:22:43 -0400 (EDT)



--Apple-Mail-14-339133596
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: quoted-printable



On May 31, 2004, at 9:17 AM, Jason Crawford wrote:

>  > >
>  > > I'd like to confirm that we agree on
>  > >
>  > > - a LOCK creation request MUST have a request body and MUST NOT=20=

> have a
>  > > Lock-Token request header
>  > >
>  > > - a LOCK refresh request MUST NOT have a request body and MUST=20
> have a
>  > > Lock-Token request header
>  >
>  > As nobody spoke up, I'll conclude that this is indeed the case.=20
> Jason,
>  > could you please update the issues list accordingly?
>
> Julian seem to support this. =A0I'll offer a weak vote of support.=20
> =A0Let's hear one more voice.
>
> J.
Agreed.

- Lisa=

--Apple-Mail-14-339133596
Content-Type: text/enriched;
	charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On May 31, 2004, at 9:17 AM, Jason Crawford wrote:


<excerpt><smaller> > ></smaller>

<smaller> > > I'd like to confirm that we agree on</smaller>

<smaller> > ></smaller>

<smaller> > > - a LOCK creation request MUST have a request body and
MUST NOT have a</smaller>

<smaller> > > Lock-Token request header</smaller>

<smaller> > ></smaller>

<smaller> > > - a LOCK refresh request MUST NOT have a request body
and MUST have a</smaller>

<smaller> > > Lock-Token request header</smaller>

<smaller> > </smaller>

<smaller> > As nobody spoke up, I'll conclude that this is indeed the
case. Jason,</smaller>

<smaller> > could you please update the issues list
accordingly?</smaller>=20


<smaller>Julian seem to support this. =A0I'll offer a weak vote of
support. =A0Let's hear one more voice.</smaller>=20


<smaller>J.</smaller>=20

</excerpt>Agreed.


- Lisa=

--Apple-Mail-14-339133596--



From w3c-dist-auth-request@w3.org  Mon May 31 19:18: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 TAA22130
	for <webdav-archive@lists.ietf.org>; Mon, 31 May 2004 19:18:22 -0400 (EDT)
Received: by frink.w3.org (Postfix, from userid 59936)
	id C2BD0A1652; Mon, 31 May 2004 19:18: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 CB76FA1652
	for <w3c-dist-auth@listhub.w3.org>; Mon, 31 May 2004 19:18:21 -0400 (EDT)
Received: from e1.ny.us.ibm.com ([32.97.182.101])
	by dr-nick.w3.org with esmtp (Exim 4.31)
	id 1BUw2v-0007Ex-RV
	for w3c-dist-auth@w3.org; Mon, 31 May 2004 19:18:21 -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 i4VNHp4N448504
	for <w3c-dist-auth@w3.org>; Mon, 31 May 2004 19:17:51 -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 i4VNId1s086668
	for <w3c-dist-auth@w3.org>; Mon, 31 May 2004 19:18:40 -0400
In-Reply-To: <40BB2F7D.3060606@gmx.de>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF919D205C.EBB830FD-ON85256EA5.007FC52E-85256EA5.007FF91D@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Mon, 31 May 2004 19:17:44 -0400
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.51HF285 | May 28, 2004) at
 05/31/2004 19:17:39,
	Serialize complete at 05/31/2004 19:17:39
Content-Type: multipart/alternative; boundary="=_alternative 007FF91A85256EA5_="
Subject: Re: GULP 5.6 vs issue UNLOCK_WHAT_URL (65)
X-Archived-At: http://www.w3.org/mid/OF919D205C.EBB830FD-ON85256EA5.007FC52E-85256EA5.007FF91D@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8535
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: <20040531231823.C2BD0A1652@frink.w3.org>
Resent-Date: Mon, 31 May 2004 19:18:23 -0400 (EDT)


This is a multipart message in MIME format.
--=_alternative 007FF91A85256EA5_=
Content-Type: text/plain; charset="US-ASCII"

Changing back is fine with me.
Cheers,
Geoff

Julian wrote on 05/31/2004 09:13:33 AM:
> 
> Hi,
> 
> I just noticed that in
> 
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0001.html>
> 
> we write...:
> 
>    "An UNLOCK request deletes the lock with the specified lock token.
>    The request-URL of the request MUST identify the resource that
>    is directly locked by that lock.  After a lock is deleted,
>    no resource is locked by that lock."
> 
> This was a change to the previous GULP version. However, the discussion 
> attached to issue entry UNLOCK_WHAT_URL 
> (<http://www.webdav.org/wg/rfcdev/issues.htm>) seems to indicate that we 

> agreed upon allowing any URL protected by the lock to be used as request 

> URL.
> 
> 1) We should agree on one of the two; and fix the other document 
> accordingly.
> 
> 2) RFC2518 seems to allow both interpretations:
> 
>     "The UNLOCK method removes the lock identified by the lock token
>     in the Lock-Token request header from the Request-URI, and all
>     other resources included in the lock."
> 
> 3) Back when I tested this, both Apache/moddav and Xythos were 
> implementing this, and so are we (I think). Microsoft IIS doesn't 
> support deep locks, so it's not relevant here.
> 
> Therefore it seems that we should undo that particular change from GULP 
> 5.5 for the sake of interoperability with older clients that may rely on 

> it (this seems to be harmless).
> 
> Best regards, Julian
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 

--=_alternative 007FF91A85256EA5_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Changing back is fine with me.</tt></font>
<br><font size=2><tt>Cheers,</tt></font>
<br><font size=2><tt>Geoff</tt></font>
<br>
<br><font size=2><tt>Julian wrote on 05/31/2004 09:13:33 AM:</tt></font>
<br><font size=2><tt>&gt; <br>
&gt; Hi,<br>
&gt; <br>
&gt; I just noticed that in<br>
&gt; <br>
&gt; &lt;http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0001.html&gt;<br>
&gt; <br>
&gt; we write...:<br>
&gt; <br>
&gt; &nbsp; &nbsp;&quot;An UNLOCK request deletes the lock with the specified
lock token.<br>
&gt; &nbsp; &nbsp;The request-URL of the request MUST identify the resource
that<br>
&gt; &nbsp; &nbsp;is directly locked by that lock. &nbsp;After a lock is
deleted,<br>
&gt; &nbsp; &nbsp;no resource is locked by that lock.&quot;<br>
&gt; <br>
&gt; This was a change to the previous GULP version. However, the discussion
<br>
&gt; attached to issue entry UNLOCK_WHAT_URL <br>
&gt; (&lt;http://www.webdav.org/wg/rfcdev/issues.htm&gt;) seems to indicate
that we <br>
&gt; agreed upon allowing any URL protected by the lock to be used as request
<br>
&gt; URL.<br>
&gt; <br>
&gt; 1) We should agree on one of the two; and fix the other document <br>
&gt; accordingly.<br>
&gt; <br>
&gt; 2) RFC2518 seems to allow both interpretations:<br>
&gt; <br>
&gt; &nbsp; &nbsp; &quot;The UNLOCK method removes the lock identified
by the lock token<br>
&gt; &nbsp; &nbsp; in the Lock-Token request header from the Request-URI,
and all<br>
&gt; &nbsp; &nbsp; other resources included in the lock.&quot;<br>
&gt; <br>
&gt; 3) Back when I tested this, both Apache/moddav and Xythos were <br>
&gt; implementing this, and so are we (I think). Microsoft IIS doesn't
<br>
&gt; support deep locks, so it's not relevant here.<br>
&gt; <br>
&gt; Therefore it seems that we should undo that particular change from
GULP <br>
&gt; 5.5 for the sake of interoperability with older clients that may rely
on <br>
&gt; it (this seems to be harmless).<br>
&gt; <br>
&gt; Best regards, Julian<br>
&gt; <br>
&gt; -- <br>
&gt; &lt;green/&gt;bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760<br>
&gt; <br>
</tt></font>
--=_alternative 007FF91A85256EA5_=--