From w3c-dist-auth-request@w3.org  Mon Sep  2 06:25:36 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18588
	for <webdav-archive@lists.ietf.org>; Mon, 2 Sep 2002 06:25:36 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g82AOLE01184;
	Mon, 2 Sep 2002 06:24:21 -0400 (EDT)
Resent-Date: Mon, 2 Sep 2002 06:24:21 -0400 (EDT)
Resent-Message-Id: <200209021024.g82AOLE01184@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g82AOJv01160
	for <w3c-dist-auth@frink.w3.org>; Mon, 2 Sep 2002 06:24:19 -0400 (EDT)
Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA13596
	for <w3c-dist-auth@w3.org>; Mon, 2 Sep 2002 06:24:19 -0400
Received: from daehub01.software-ag.de by server8a.software-ag.de; (8.11.6/8.9.3)
	id g82ANJA02859; Mon, 2 Sep 2002 12:23:19 +0200
Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2650.21)
	id <QLZQLVRZ>; Mon, 2 Sep 2002 12:24:17 +0200
Message-ID: <DFF2AC9E3583D511A21F0008C7E62106031F2AC2@daemsg02.software-ag.de>
From: "Pill, Juergen" <Juergen.Pill@softwareag.com>
To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
Date: Mon, 2 Sep 2002 12:24:17 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6532
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>


Hello,

The current WebDAV specifications deal with a transactional support on a
method base only. Either a single WebDAV method is completely and
successfully executed, or the method is not executed at all (e.g. a
PropPatch command will either modify all requested properties or none of
them). A transactional support spanning multiple WebDAV methods is currently
not specified.
Multi user requirements are either handled in separate workspaces (Delta-V)
or via the Lock method.
During our discussion on the JSR 170 (Content Management API) implementation
on top of WebDAV, we believe that we require longer transactions spanning
multiple separate WebDAV methods. (This issue was already partially
discussed in the Batch method thread). Do you also fell the need/requirement
to get a standard on the way, concerning a transactional WebDAV protocol
extension?

A possible use case would be:
An author wants to modify an html page. To successfully do so, he will PUT
the updated html page back, PROPPATCH and UNLOCK it, DELETE all bitmap
files, which are not references any more, and PUT (create) the newly
referenced bitmaps files. If he wants to ensure, that either all his changes
do apply (or none of them) he would surround those method call with an
TA-BEGIN and a TA-COMMIT method call. If the author would be an API (e.g.
JSR 170) exposing the TA functionality to an application, we believe this
feature to be mandatory.

A possible (starting) specification could be:
WebDAV defines 3 additional methods: TA-BEGIN, TA-COMMIT and TA-ABORT. The
TA-BEGIN method will return a TA token (e.g. via an XML response body). This
TA token will be send to the following WebDAV methods, which are part of
this transaction (e.g. via an additional header). The TA-COMMIT or TA-ABORT
method will either commit or abort the transaction and invalidate the TA
token. 
If and when an open TA, which is not used any more, is aborted, could be
controlled similar to the lock method timeout header.
All WebDAV methods, which either do not posses a TA token, or posses an
invalid token are handled as today (the method is executed within its own
TA), this would ensure upward compatibility.
This extension would be optional, if a server supports the TA methods, it
will state this in the OPTIONS request (similar to Delta-V).


Does this make sense?

Best regards
Juergen Pill



From w3c-dist-auth-request@w3.org  Mon Sep  2 07:35:41 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19572
	for <webdav-archive@lists.ietf.org>; Mon, 2 Sep 2002 07:35:41 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g82Ba4I06674;
	Mon, 2 Sep 2002 07:36:04 -0400 (EDT)
Resent-Date: Mon, 2 Sep 2002 07:36:04 -0400 (EDT)
Resent-Message-Id: <200209021136.g82Ba4I06674@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g82Ba2v06654
	for <w3c-dist-auth@frink.w3.org>; Mon, 2 Sep 2002 07:36:02 -0400 (EDT)
Received: from dirf.bris.ac.uk (dirf.bris.ac.uk [137.222.10.72])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA22141
	for <w3c-dist-auth@w3.org>; Mon, 2 Sep 2002 07:36:02 -0400
Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) 
          by dirf.bris.ac.uk with SMTP-PRIV with ESMTP;
          Mon, 2 Sep 2002 12:35:44 +0100
Received: from shi.cs.bris.ac.uk (shi [137.222.102.34]) 
          by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id MAA01948;
          Mon, 2 Sep 2002 12:35:16 +0100 (BST)
Received: from cs.bris.ac.uk by shi.cs.bris.ac.uk (8.9.3) id MAA14019;
          Mon, 2 Sep 2002 12:35:15 +0100 (BST)
Message-ID: <3D734CF3.16D28F8D@cs.bris.ac.uk>
Date: Mon, 02 Sep 2002 12:35:15 +0100
From: "B. Shadgar" <shadgar@cs.bris.ac.uk>
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Pill, Juergen" <Juergen.Pill@softwareag.com>, w3c-dist-auth@w3.org
References: <DFF2AC9E3583D511A21F0008C7E62106031F2AC2@daemsg02.software-ag.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6533
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>
Content-Transfer-Encoding: 7bit


"Pill, Juergen" wrote:

> Hello,
>
> The current WebDAV specifications deal with a transactional support on a
> method base only. Either a single WebDAV method is completely and
> successfully executed, or the method is not executed at all (e.g. a
> PropPatch command will either modify all requested properties or none of
> them). A transactional support spanning multiple WebDAV methods is currently
> not specified.
> Multi user requirements are either handled in separate workspaces (Delta-V)
> or via the Lock method.
> During our discussion on the JSR 170 (Content Management API) implementation
> on top of WebDAV, we believe that we require longer transactions spanning
> multiple separate WebDAV methods. (This issue was already partially
> discussed in the Batch method thread). Do you also fell the need/requirement
> to get a standard on the way, concerning a transactional WebDAV protocol
> extension?
>
> A possible use case would be:
> An author wants to modify an html page. To successfully do so, he will PUT
> the updated html page back, PROPPATCH and UNLOCK it, DELETE all bitmap
> files, which are not references any more, and PUT (create) the newly
> referenced bitmaps files. If he wants to ensure, that either all his changes
> do apply (or none of them) he would surround those method call with an
> TA-BEGIN and a TA-COMMIT method call. If the author would be an API (e.g.
> JSR 170) exposing the TA functionality to an application, we believe this
> feature to be mandatory.
>
> A possible (starting) specification could be:
> WebDAV defines 3 additional methods: TA-BEGIN, TA-COMMIT and TA-ABORT. The
> TA-BEGIN method will return a TA token (e.g. via an XML response body). This
> TA token will be send to the following WebDAV methods, which are part of
> this transaction (e.g. via an additional header). The TA-COMMIT or TA-ABORT
> method will either commit or abort the transaction and invalidate the TA
> token.
> If and when an open TA, which is not used any more, is aborted, could be
> controlled similar to the lock method timeout header.
> All WebDAV methods, which either do not posses a TA token, or posses an
> invalid token are handled as today (the method is executed within its own
> TA), this would ensure upward compatibility.
> This extension would be optional, if a server supports the TA methods, it
> will state this in the OPTIONS request (similar to Delta-V).
>
> Does this make sense?
>
> Best regards
> Juergen Pill

Juergen,

It is what exactly I was thinking about. I've got another scenario of possible
using TA- methods you have proposed. I need those transaction methods since I
am dealing with accessing the database through the web based on the WebDAV
protocol. In other words, I've almost prepared an application which accesses to
the database and considers the database data model as WebDAV resources. With
all methods are provided by WebDAV and other WG + Batch method , I am able to
send almost all SQL queries into the server in form of WebDAV methods. But some
statements like commit, rollback, savepoint can not be implemented by WebDAV
methods, and it is exactly what you suggesting; TA-COMMIT, TA-ABORT and
TA-BEGIN.  This application can be another possible use case of those three
methods + Batch method which is discussed already but hasn't been accepted as a
WebDAV method.

If I want to complete your proposal from my point of view I would say: Since
the WebDAV claims to encompass all kind of web resources representing by URI,
databases resource can be considered as its resource and therefore to support
database operation we would need TA- Methods  as well as Batch Method.

Regards,
Bita







From w3c-dist-auth-request@w3.org  Mon Sep  2 09:18:59 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21798
	for <webdav-archive@lists.ietf.org>; Mon, 2 Sep 2002 09:18:59 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g82DJ9C13294;
	Mon, 2 Sep 2002 09:19:09 -0400 (EDT)
Resent-Date: Mon, 2 Sep 2002 09:19:09 -0400 (EDT)
Resent-Message-Id: <200209021319.g82DJ9C13294@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g82DJ8v13269
	for <w3c-dist-auth@frink.w3.org>; Mon, 2 Sep 2002 09:19:08 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA03960
	for <w3c-dist-auth@w3.org>; Mon, 2 Sep 2002 09:19:07 -0400
Received: (qmail 15959 invoked by uid 0); 2 Sep 2002 13:18:37 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp007-rz3) with SMTP; 2 Sep 2002 13:18:37 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: <w3c-dist-auth@w3.org>
Date: Mon, 2 Sep 2002 15:18:36 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCMEEDFEAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <JIEGINCHMLABHJBIGKBCCELOEOAA.julian.reschke@gmx.de>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Subject: RE: discovering the root of a deep lock
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6534
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>
Content-Transfer-Encoding: 7bit


OK,

seems that we had consensus on this protocol extension (got OKs from: Geoff
Clemm, Dan Brotsky and Jason Crawford, and no negative feedback).

This should close issue #89 (FINDING_THE_ROOT_OF_A_DEPTH_LOCK).

Lisa, is there any chance that we may be able to get this into the RFC2518
revision? I'm happy to provide a URL of a test server implementing this in
time before the interop meeting.

Regards,

Julian

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

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Wednesday, July 10, 2002 9:39 AM
> To: w3c-dist-auth@w3.org
> Subject: discovering the root of a deep lock
>
>
> (see also issue LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY)
>
> Proposed syntax:
>
> 12.1  activelock XML Element
>
> Name:
> activelock
> Namespace:
> DAV:
> Purpose:
> Describes a lock on a resource.
>
>    <!ELEMENT activelock (lockscope, locktype, depth, owner?,
> timeout?, locktoken?, lockroot?) >
>
>
> 12.1.x  lockroot XML Element
>
> Name:
> lockroot
> Namespace:
> DAV:
> Purpose:
> For locks with depth infinity, servers SHOULD report the root of
> the lock using the DAV:lockroot element. This enables clients to
> know the scope of resources affected by a subsequent UNLOCK with
> the given lock token. For lock with depth 0, the DAV:lockroot
> element MUST NOT be present.
>
>    <!ELEMENT lockroot (href) >
>
>
> --
>
> Note: I made it a "SHOULD" in order not to break existing implementations.
>
>
>



From w3c-dist-auth-request@w3.org  Mon Sep  2 14:27:07 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28659
	for <webdav-archive@lists.ietf.org>; Mon, 2 Sep 2002 14:27:07 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g82IRdC16622;
	Mon, 2 Sep 2002 14:27:39 -0400 (EDT)
Resent-Date: Mon, 2 Sep 2002 14:27:39 -0400 (EDT)
Resent-Message-Id: <200209021827.g82IRdC16622@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g82IRbv16602
	for <w3c-dist-auth@frink.w3.org>; Mon, 2 Sep 2002 14:27:37 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA27178
	for <w3c-dist-auth@w3.org>; Mon, 2 Sep 2002 14:27:36 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id LAA12287 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Mon, 2 Sep 2002 11:27:28 -0700
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by sunbelt.seagull.net (8.9.3) with ESMTP id LAA12259 sender obsfucated@us.ibm.com; Mon, 2 Sep 2002 11:27:21 -0700
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g82IQjEG249000; Mon, 2 Sep 2002 14:26:46 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g82IQhaH051556; Mon, 2 Sep 2002 14:26:44 -0400
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: w3c-dist-auth@w3.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF1F792D75.07A12419-ON85256C28.006289BE@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Mon, 2 Sep 2002 14:06:35 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_M14_08012002 Release Candidate|August 01, 2002) at 09/02/2002 14:26:43
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
                                                                                                              
Subject: RE: discovering the root of a deep lock
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6535
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>



On Monday, 09/02/2002 at 03:18 ZE2, "Julian Reschke" <nnjulian.
reschke___at___gmx.de@smallcue.com> wrote:
> OK,
>
> seems that we had consensus on this protocol extension (got OKs from:
Geoff
> Clemm, Dan Brotsky and Jason Crawford, and no negative feedback).
>
> This should close issue #89 (FINDING_THE_ROOT_OF_A_DEPTH_LOCK).
>
> Lisa, is there any chance that we may be able to get this into the
RFC2518
> revision? I'm happy to provide a URL of a test server implementing this
in
> time before the interop meeting.

I've moved the state of that issue to Edit although I think we need to test
some
interop.

Let's get a few of the folks that will be at the interop to implement this.

J.

------------------------------------------
Phone: 914-784-7569



From w3c-dist-auth-request@w3.org  Mon Sep  2 16:59:41 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01307
	for <webdav-archive@lists.ietf.org>; Mon, 2 Sep 2002 16:59:41 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g82Kxkp01470;
	Mon, 2 Sep 2002 16:59:46 -0400 (EDT)
Resent-Date: Mon, 2 Sep 2002 16:59:46 -0400 (EDT)
Resent-Message-Id: <200209022059.g82Kxkp01470@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g82Kxjv01449
	for <w3c-dist-auth@frink.w3.org>; Mon, 2 Sep 2002 16:59:45 -0400 (EDT)
Received: from hq-exgw2.filenet.com (Filenet-gw.filenet.com [198.3.8.1])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA15569
	for <w3c-dist-auth@w3.org>; Mon, 2 Sep 2002 16:59:44 -0400
Received: by hq-exgw2.filenet.com with Internet Mail Service (5.5.2653.19)
	id <R80M38PR>; Mon, 2 Sep 2002 13:59:09 -0700
Message-ID: <C3AF5E329E21D2119C4C00805F6FF58F08FE5E16@hq-expo2.filenet.com>
From: "Babich, Alan" <ABabich@filenet.com>
To: "'B. Shadgar'" <shadgar@cs.bris.ac.uk>,
        "Pill, Juergen"
	 <Juergen.Pill@softwareag.com>, w3c-dist-auth@w3.org
Date: Mon, 2 Sep 2002 13:59:12 -0700 
X-Mailer: Internet Mail Service (5.5.2653.19)
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6536
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>


One thing you do NOT want under any circumstances are 
begin-transaction, end-transaction, and abort-transaction 
methods. That approach simply does not scale beyond a single
user, and is a performance disaster.

You absolutely need to stick to single method calls that can 
Perform Multiple operations on the server in a single 
Transaction. Batching up operations is a valid approach.

Transactions aren't that easy to deal with. That becomes
Even more true when multiple servers are involved. Someday,
WebDAV might get that far.

Transactions aren't new. They're decades old. The effort would
Profit from the decades of thought that has gone before.
For example, see the DMA standard for one approach. (But
remember: DMA specifies an API, not a protocol, and WebDAV is a 
protocol.)

Dr. Alan F. Babich



From w3c-dist-auth-request@w3.org  Tue Sep  3 13:17:06 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05593
	for <webdav-archive@lists.ietf.org>; Tue, 3 Sep 2002 13:17:06 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g83HGHT05029;
	Tue, 3 Sep 2002 13:16:18 -0400 (EDT)
Resent-Date: Tue, 3 Sep 2002 13:16:18 -0400 (EDT)
Resent-Message-Id: <200209031716.g83HGHT05029@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g83HGGv05009
	for <w3c-dist-auth@frink.w3.org>; Tue, 3 Sep 2002 13:16:16 -0400 (EDT)
Received: from cats.ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA30770
	for <w3c-dist-auth@w3.org>; Tue, 3 Sep 2002 13:16:02 -0400
Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177])
	by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g83HFVT14517
	for <w3c-dist-auth@w3.org>; Tue, 3 Sep 2002 10:15:31 -0700 (PDT)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "WebDAV" <w3c-dist-auth@w3.org>
Date: Tue, 3 Sep 2002 10:13:13 -0700
Message-ID: <AMEPKEBLDJJCCDEJHAMIAEPPFFAA.ejw@cse.ucsc.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0087_01C25332.8326E630"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
X-UCSC-CATS-MailScanner: Found to be clean
Subject: RE: Passwords and WebDAV
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6537
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>


This is a multi-part message in MIME format.

------=_NextPart_000_0087_01C25332.8326E630
Content-Type: text/plain;
	charset="windows-1256"
Content-Transfer-Encoding: 7bit

Accidentally caught by the spam filter.

- Jim
-----Original Message-----
From: Haider Sahir Al-Baghdadi [mailto:hs84@uruklink.net]
Sent: Monday, September 02, 2002 5:05 PM
To: w3c-dist-auth@w3.org
Subject: [Moderator Action] RE: Passwords and WebDAV


Hmm, well I can see how this is an important deployment issue. I think the
problem of notifying the user that their password has expired would be
easier than providing a password modification protocol.

It seems to be this problem isn't inherent to authoring -- regular Web
access could run into this problem as well.  For example, if my subscription
to an online magazine, or digital library runs out, I might want to receive
a message as well.  But, authoring certainly does bring in clients that do
not have HTML rendering capability.

I think the best way to address this would be for someone to volunteer to
write up an Internet Draft describing a new status code, and its meaning, to
cover the password expiration, and password refresh cases.  I think it
should scrupulously avoid functionality that would allow a user to reset
their password, unless it involved returning the URL of a Web page that
would allow the password to be reset.

But, this wouldn't affect existing WebDAV clients fast enough to affect your
current situation -- for that, one option is to use email as a notification
service, telling users their passwords have expired.

- Jim


> In my original message I said this may be out of the scope of
> WebDAV, but now I think it is critical to WebDAV. We a currently
> working on this issue with a large customer. With a normal HTTP
> client (one that renders html) it is possible to solve the
> expired password problem. However, with WebDAV clients there
> currently is no way to solve this problem. This is currently THE
> issue that is preventing the adoption of WebDAV for this
> customer. If we want to have people use the WebDAV protocol we
> have to be willing to solve problems like this one.

------=_NextPart_000_0087_01C25332.8326E630
Content-Type: text/html;
	charset="windows-1256"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1256" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3207.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D486541217-03092002>Accidentally caught by the spam=20
filter.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D486541217-03092002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D486541217-03092002>-=20
Jim</SPAN></FONT></DIV>
<DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> Haider Sahir =
Al-Baghdadi=20
[mailto:hs84@uruklink.net]<BR><B>Sent:</B> Monday, September 02, 2002 =
5:05=20
PM<BR><B>To:</B> w3c-dist-auth@w3.org<BR><B>Subject:</B> [Moderator =
Action] RE:=20
Passwords and WebDAV<BR><BR></FONT></DIV>
<DIV align=3Djustify><FONT face=3DArial>Hmm, well I can see how this is =
an important=20
deployment issue. I think the<BR>problem of notifying the user that =
their=20
password has expired would be<BR>easier than providing a password =
modification=20
protocol.<BR><BR>It seems to be this problem isn't inherent to authoring =
--=20
regular Web<BR>access could run into this problem as well.&nbsp; For =
example, if=20
my subscription<BR>to an online magazine, or digital library runs out, I =
might=20
want to receive<BR>a message as well.&nbsp; But, authoring certainly =
does bring=20
in clients that do<BR>not have HTML rendering capability.<BR><BR>I think =
the=20
best way to address this would be for someone to volunteer to<BR>write =
up an=20
Internet Draft describing a new status code, and its meaning, =
to<BR>cover the=20
password expiration, and password refresh cases.&nbsp; I think =
it<BR>should=20
scrupulously avoid functionality that would allow a user to =
reset<BR>their=20
password, unless it involved returning the URL of a Web page =
that<BR>would allow=20
the password to be reset.<BR><BR>But, this wouldn't affect existing =
WebDAV=20
clients fast enough to affect your<BR>current situation -- for that, one =
option=20
is to use email as a notification<BR>service, telling users their =
passwords have=20
expired.<BR><BR>- Jim<BR><BR><BR>&gt; In my original message I said this =
may be=20
out of the scope of<BR>&gt; WebDAV, but now I think it is critical to =
WebDAV. We=20
a currently<BR>&gt; working on this issue with a large customer. With a =
normal=20
HTTP<BR>&gt; client (one that renders html) it is possible to solve =
the<BR>&gt;=20
expired password problem. However, with WebDAV clients there<BR>&gt; =
currently=20
is no way to solve this problem. This is currently THE<BR>&gt; issue =
that is=20
preventing the adoption of WebDAV for this<BR>&gt; customer. If we want =
to have=20
people use the WebDAV protocol we<BR>&gt; have to be willing to solve =
problems=20
like this one.</FONT></DIV></BODY></HTML>

------=_NextPart_000_0087_01C25332.8326E630--



From w3c-dist-auth-request@w3.org  Tue Sep  3 20:12:31 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17973
	for <webdav-archive@lists.ietf.org>; Tue, 3 Sep 2002 20:12:31 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g840CZY25393;
	Tue, 3 Sep 2002 20:12:35 -0400 (EDT)
Resent-Date: Tue, 3 Sep 2002 20:12:35 -0400 (EDT)
Resent-Message-Id: <200209040012.g840CZY25393@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g840CTv25369
	for <w3c-dist-auth@frink.w3.org>; Tue, 3 Sep 2002 20:12:29 -0400 (EDT)
Received: from cats.ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA19416
	for <w3c-dist-auth@w3.org>; Tue, 3 Sep 2002 20:12:29 -0400
Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177])
	by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g8407sg05792;
	Tue, 3 Sep 2002 17:07:54 -0700 (PDT)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: <interop@webdav.org>
Cc: "WebDAV" <w3c-dist-auth@w3.org>
Date: Tue, 3 Sep 2002 17:05:36 -0700
Message-ID: <AMEPKEBLDJJCCDEJHAMIGEALFGAA.ejw@cse.ucsc.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-UCSC-CATS-MailScanner: Found to be clean
Subject: Interop Event FAQ
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6538
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>
Content-Transfer-Encoding: 7bit


Here is a list of questions about next week's upcoming WebDAV
Interoperability Testing Event, being held M-W, 9/9-9/11, in Jack's Lounge,
Baskin Engineering Building, UC Santa Cruz.

* What are the hours of the interoperability testing event?

9AM-6:30PM each day (M-W). Network equipment setup will start at 8AM each
day -- feel free to come early and help set up.

* What are the hours of the interim working group meeting?

Sept 9, 10: 3PM-6PM, Sept. 11: 9AM-12noon.  This will take place
concurrently with the interoperability testing event, so that
interoperability issues can be identified, resolved, and perhaps even tested
on-the-spot.

* How should I pay the $225 fee for the interop event?

Please bring a check to the event, payable to "UC Regents". You will be
given a receipt at the event. The fee is per-organization (not per-person).
Unfortunately, UCSC is not set up to handle credit card payments. Not that
people attending only the interim WG meeting do not need to pay the fee.

* How do I park my car?

Please park in the parking structure located across the street from the
Baskin Engineering building. You should be receiving, by snail mail, a
parking pass and a map to the parking structure and Baskin Engineering
buildings. You'll need a new parking pass each day -- you can pick up the
remaining parking passes at the event. If you accidentally forget your pass,
please park in the structure, then come to the event, pick up a pass, and
then put it on your car.

* Who is coming to the event?

We're expecting about 35 people, from the following companies and projects
(in no particular order):

Adobe (client and server side I believe), Microsoft (Windows CE, Sharepoint,
Exchange), Oracle, Merant, Xythos, Software AG, Alias|Wavefront, kCura,
NetApp. Greg Stein/Apache mod_dav will be present, as will several students
from UCSC, representing the Catacomb server and Cadaver client. An improved
version of Litmus will also be used at the event.

* Is the interoperability event held in a secure location?

Not especially. The room for the event is not lockable, and is a relatively
public area within the Baskin Engineering building. Classes are *not*
currently in session (UCSC is on the quarter system) and hence there are
relatively few people in the building, however. Additionally, there are many
people present during the event itself, and food is being brought directly
to the room of the event. Still, especially if you're bringing a laptop, you
may want to bring a cable for securing the laptop to a desk. On the other
hand, theft is uncommon in Baskin Engineering in general, and there were no
problems at last year's event.

* What kind of network is available for the event?

We'll be setting Jack's Lounge up as a small computer lab, with 10-Base-T
cables attached to network hubs. Once you have connected your computer to
our network, you will be on UCSC's network, which is *not* behind a
firewall.

* Should I install the latest security patches for my OS before I come?

Absolutely. Automated intrusion scripts are constantly scanning our network
for vulnerable machines, and last year it took less than an hour for a
participating machine to be compromised. This is a considerably more
hazardous environment than what is typically encountered behind a firewall.

* Will we have fixed or dynamic IP addresses?

To aid interpretation of network traffic traces, each machine will be
assigned a static IP address. This allows identification of each participant
based solely on their IP.

* Will my cell phone work at the event?

Possibly. Coverage is very spotty on campus -- many phones do not receive
sufficient signal. We will have several land line phones available for
calling out.

* What food is being provided at the event?

There will be coffee and muffins available in the mornings, and lunch will
be served all three days as well. All meals include a vegetarian option.
Soda, water and snacks will also be available in the afternoon. You're on
your own for dinner.

* Will a printer be available?

Yes, a laser printer will be available for making printouts of protocol
traces, source code, etc.

* Will there be any test equipment provided at the event, such as a packet
sniffer?

Sadly, no. We recommend using existing tools, such as:

tcpdump - http://www.tcpdump.org/
Berkeley Packet Filter -
http://www.gsp.com/cgi-bin/man.cgi?section=4&topic=bpf
http://www-nrg.ee.lbl.gov/

For Windows, HTTPTracer looks like it might be useful (haven't used it
myself, costs only $25)
http://www.concentric.net/~Sstmail/index.html

EffeTech's HTTP Sniffer might also be handy as well (haven't used it myself)
http://www.effetech.com/

These tools can take some fiddling before you feel comfortable with their
results, so get some experience with them before coming to the event.


* How will testing pairs be established?

At the start of the event we'll go around the room and have everyone
introduce themselves, and explain which implementations they're testing.
After this, we expect individuals to proactively set up testing pairs --
it's too chaotic to manage this centrally.

We do ask that people attending the event adopt the goal of trying to
interoperate with all of the other clients/servers at the event. We're
trying to achieve broad interoperability, and this implies broad testing.

More questions? Please contact Jim Whitehead <ejw@cs.ucsc.edu>

- Jim





From w3c-dist-auth-request@w3.org  Tue Sep  3 23:26:46 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22200
	for <webdav-archive@lists.ietf.org>; Tue, 3 Sep 2002 23:26:46 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g843R3W09036;
	Tue, 3 Sep 2002 23:27:03 -0400 (EDT)
Resent-Date: Tue, 3 Sep 2002 23:27:03 -0400 (EDT)
Resent-Message-Id: <200209040327.g843R3W09036@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g843R2v09016
	for <w3c-dist-auth@frink.w3.org>; Tue, 3 Sep 2002 23:27:02 -0400 (EDT)
Received: from cts01.webone.com.au (cts01.webone.com.au [210.9.240.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA09781
	for <w3c-dist-auth@w3.org>; Tue, 3 Sep 2002 23:27:00 -0400
Received: from ammd01 (dial-ctb0368.webone.com.au [210.9.243.68])
	by cts01.webone.com.au (8.9.3/8.9.3) with SMTP id NAA29449
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 13:26:57 +1000
From: "Michael Leditschke" <mike@ammd.com.au>
To: <w3c-dist-auth@w3.org>
Date: Wed, 4 Sep 2002 13:26:57 +1000
Message-ID: <LOBBICBLDJIJHPNJFPOLKECICMAA.mike@ammd.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Subject: What is left after LOCK/UNLOCK on null resource?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6539
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>
Content-Transfer-Encoding: 7bit


I'm doing some experimenting with
Tomcat 4.0.4+Slide1.0.16+IE6 on WIN2K box.

I would appreciate some advice as to the 
expected behaviour in the following scenario:

1. A null resource is locked.

Q. Should this resource appear as a member
URI of its parent? 

IE displays the lock-null
resource as a directory, which doesn't seem right.


2. The null resource is unlocked.

Q. Should there be anything left if no other 
command is issued in between?

Looking at the Slide database, there continues to 
be information maintained about the unlocked 
resource. I would have thought everything should have
been cleaned out, i.e. the properties created for the
locked resource should have been deleted.

IE also continues to show the now unlocked resource as
a directory, but it doesn't act as a collection, e.g. 
you can't create members within it. I suspect this is as
a result of the Slide behaviour.


Any clarifications greatly appreciated.

Regards
Michael

--

Michael Leditschke
AMMD Professional Services Pty Ltd
+61 407 671 480

"The question of whether computers can think is 
like the question of whether submarines can swim"
 
                    --Edsger W. Dijkstra,         
                      deceased 6 August 2002         




From w3c-dist-auth-request@w3.org  Wed Sep  4 02:41:01 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18924
	for <webdav-archive@lists.ietf.org>; Wed, 4 Sep 2002 02:41:01 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g846ed621995;
	Wed, 4 Sep 2002 02:40:39 -0400 (EDT)
Resent-Date: Wed, 4 Sep 2002 02:40:39 -0400 (EDT)
Resent-Message-Id: <200209040640.g846ed621995@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g846ebv21975
	for <w3c-dist-auth@frink.w3.org>; Wed, 4 Sep 2002 02:40:37 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA00460
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 02:40:36 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id XAA10051 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Tue, 3 Sep 2002 23:40:35 -0700
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by sunbelt.seagull.net (8.9.3) with ESMTP id XAA10035 sender obsfucated@us.ibm.com; Tue, 3 Sep 2002 23:40:34 -0700
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g846e2EG250244; Wed, 4 Sep 2002 02:40:02 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g846e1wr024742; Wed, 4 Sep 2002 02:40:01 -0400
To: "Michael Leditschke" <mike@ammd.com.au>
Cc: w3c-dist-auth@w3.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF11AA9242.2C8AE0AF-ON85256C2A.00237E48@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Wed, 4 Sep 2002 02:39:28 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_M14_08012002 Release Candidate|August 01, 2002) at 09/04/2002 02:40:01
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
                                                                                                              
Subject: Re: What is left after LOCK/UNLOCK on null resource?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6540
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>




> 1. A null resource is locked.

> Q. Should this resource appear as a member
> URI of its parent?

Yes, it should appear.  All versions of the spec say it should.


> IE displays the lock-null
> resource as a directory, which doesn't seem right.

A directory?  At the protocol level?  Or
just in the gui?


> 2. The null resource is unlocked.
> Q. Should there be anything left if no other
> command is issued in between?

rfc2518 says there should be nothing.  rfc2518bis
(new spec) says there should be a resource.


> IE also continues to show the now unlocked resource as
> a directory, but it doesn't act as a collection, e.g.
> you can't create members within it.
rfc2518 does specify some odd lock-null behavior while it's
still locked, but neither protocol specifies any odd
behavior after unlocked.

> I suspect this is as
> a result of the Slide behaviour.
Check at the protocol level to determine what's happening
there.  The gui might just make it look like a directory
even if the protocol is doing something different.


> Any clarifications greatly appreciated.
Let us know what you discover.

J.



From w3c-dist-auth-request@w3.org  Wed Sep  4 09:02:47 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26391
	for <webdav-archive@lists.ietf.org>; Wed, 4 Sep 2002 09:02:47 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g84D2Q611315;
	Wed, 4 Sep 2002 09:02:26 -0400 (EDT)
Resent-Date: Wed, 4 Sep 2002 09:02:26 -0400 (EDT)
Resent-Message-Id: <200209041302.g84D2Q611315@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g84D2Ov11295
	for <w3c-dist-auth@frink.w3.org>; Wed, 4 Sep 2002 09:02:24 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA31537
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 09:02:23 -0400
Received: (qmail 31609 invoked by uid 0); 4 Sep 2002 13:01:52 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp019-rz3) with SMTP; 4 Sep 2002 13:01:52 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: <w3c-dist-auth@w3.org>
Date: Wed, 4 Sep 2002 15:01:51 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCCEIFFEAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <C3AF5E329E21D2119C4C00805F6FF58F08FE5E16@hq-expo2.filenet.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: Interoperability for DAV:ishidden?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6541
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>
Content-Transfer-Encoding: 7bit


Hi,

one thing that the participants of the interop meeting may want to
consider...

A long time ago ([1]), Microsoft proposed a live property DAV:ishidden which
signals that a resource should be displayed as hidden in a UI.

Support currently exists in:

MS IIS 5.0: reports DAV:ishidden according to the file system flags of the
underlying file system
MS webfolder client: asks for DAV:ishidden, and hides the resource when it
is reported as hidden
SAP Enterprise Portal Server: treats DAV:ishidden as live property with the
semantics defined in [1]

I think this is a really useful feature, and in case we can identify another
client that supports it, we may want to roll it into RFC2518.

Regards, Julian



[1] <http://greenbytes.de/tech/webdav/draft-hopmann-collection-props-00.txt>

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



From w3c-dist-auth-request@w3.org  Wed Sep  4 09:21:12 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27344
	for <webdav-archive@lists.ietf.org>; Wed, 4 Sep 2002 09:21:12 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g84DKfK13687;
	Wed, 4 Sep 2002 09:20:41 -0400 (EDT)
Resent-Date: Wed, 4 Sep 2002 09:20:41 -0400 (EDT)
Resent-Message-Id: <200209041320.g84DKfK13687@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g84DKev13663
	for <w3c-dist-auth@frink.w3.org>; Wed, 4 Sep 2002 09:20:40 -0400 (EDT)
Received: from cts01.webone.com.au (cts01.webone.com.au [210.9.240.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA02973
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 09:20:39 -0400
Received: from ammd01 (dial-ctb0368.webone.com.au [210.9.243.68])
	by cts01.webone.com.au (8.9.3/8.9.3) with SMTP id XAA15511;
	Wed, 4 Sep 2002 23:20:33 +1000
From: "Michael Leditschke" <mike@ammd.com.au>
To: "Jason Crawford" <nn683849@smallcue.com>
Cc: <w3c-dist-auth@w3.org>
Date: Wed, 4 Sep 2002 23:20:32 +1000
Message-ID: <LOBBICBLDJIJHPNJFPOLGECOCMAA.mike@ammd.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <OF11AA9242.2C8AE0AF-ON85256C2A.00237E48@us.ibm.com>
Subject: RE: What is left after LOCK/UNLOCK on null resource?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6542
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>
Content-Transfer-Encoding: 7bit


> > IE displays the lock-null
> > resource as a directory, which doesn't seem right.
> 
> A directory?  At the protocol level?  Or
> just in the gui?

I was looking via the IE Web Folders GUI. Thanks to 
Stefan for pointing out that MS shows any resource with
a non-empty resource type as a collection. The slide
client makes a similar assumption in that the resourcetype
is shown as blank if the resourcetype isn't "collection".

> 
> 
> > 2. The null resource is unlocked.
> > Q. Should there be anything left if no other
> > command is issued in between?
> 
> rfc2518 says there should be nothing.  rfc2518bis
> (new spec) says there should be a resource.

If I use the slide client to lock/unlock in the *same*
client session, nothing is left, the resource gets unlocked
and all is sweet.

> 
> 
> > IE also continues to show the now unlocked resource as
> > a directory, but it doesn't act as a collection, e.g.
> > you can't create members within it.
> rfc2518 does specify some odd lock-null behavior while it's
> still locked, but neither protocol specifies any odd
> behavior after unlocked.

This is where the wheels come off a bit. It would appear
that the slide client can only delete a lock if it created
the lock in the *same* session. If I fire up the client,
create a lock, exit, fire it up again and attempt an unlock,
the operation fails. Nothing appears on the wire. A brief
troll through the code suggests the client won't even try if
it doesn't find the lock in its internal state structure, and
this structure only gets populated as part of a lock operation
- though I'm happy to be corrected.


Can anyone confirm whether this is the expected client behaviour,
or a bug? I would have thought you should be able to unlock a
resource independent of when the lock operation occurred.

Regards
Michael



From w3c-dist-auth-request@w3.org  Wed Sep  4 09:48:02 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29257
	for <webdav-archive@lists.ietf.org>; Wed, 4 Sep 2002 09:48:02 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g84Dl0j17101;
	Wed, 4 Sep 2002 09:47:00 -0400 (EDT)
Resent-Date: Wed, 4 Sep 2002 09:47:00 -0400 (EDT)
Resent-Message-Id: <200209041347.g84Dl0j17101@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g84Dkxv17081
	for <w3c-dist-auth@frink.w3.org>; Wed, 4 Sep 2002 09:46:59 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA09557
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 09:46:58 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 04 Sep 2002 09:37:13 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <P4FX4VKZ>; Wed, 4 Sep 2002 09:46:27 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10808D715@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Wed, 4 Sep 2002 09:46:27 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Interoperability for DAV:ishidden?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6543
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>


Adding DAV:ishidden if there is demonstrable interop support for it is fine
with me.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Wednesday, September 04, 2002 9:02 AM
To: w3c-dist-auth@w3.org
Subject: Interoperability for DAV:ishidden?



Hi,

one thing that the participants of the interop meeting may want to
consider...

A long time ago ([1]), Microsoft proposed a live property DAV:ishidden which
signals that a resource should be displayed as hidden in a UI.

Support currently exists in:

MS IIS 5.0: reports DAV:ishidden according to the file system flags of the
underlying file system
MS webfolder client: asks for DAV:ishidden, and hides the resource when it
is reported as hidden
SAP Enterprise Portal Server: treats DAV:ishidden as live property with the
semantics defined in [1]

I think this is a really useful feature, and in case we can identify another
client that supports it, we may want to roll it into RFC2518.

Regards, Julian



[1] <http://greenbytes.de/tech/webdav/draft-hopmann-collection-props-00.txt>

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



From w3c-dist-auth-request@w3.org  Wed Sep  4 10:03:26 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00235
	for <webdav-archive@lists.ietf.org>; Wed, 4 Sep 2002 10:03:25 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g84DtDb18424;
	Wed, 4 Sep 2002 09:55:13 -0400 (EDT)
Resent-Date: Wed, 4 Sep 2002 09:55:13 -0400 (EDT)
Resent-Message-Id: <200209041355.g84DtDb18424@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g84DtCv18399
	for <w3c-dist-auth@frink.w3.org>; Wed, 4 Sep 2002 09:55:12 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA12620
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 09:55:12 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 04 Sep 2002 09:45:28 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <P4FX4V76>; Wed, 4 Sep 2002 09:54:42 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10808D725@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Wed, 4 Sep 2002 09:54:36 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: What is left after LOCK/UNLOCK on null resource?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6544
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>


It is very reasonable/sensible behavior for a client to
refuse to unlock a resource if it wasn't the process that
took out the lock.  A client should never unlock such
a resource without getting explicit confirmation from the
user to do so, but a client can reasonably refuse to give
the user that choice, because a user is often not in a
position to make the right choice (i.e. forgets or is not
aware that something else being done on their behalf requires
that resource to be locked).

Such a client should of course set a timeout on any lock that
it takes out, so that the server can automatically expire a
lock when the client that took out the lock has dies or otherwise
failed to unlock.

Cheers,
Geoff

-----Original Message-----
From: Michael Leditschke [mailto:mike@ammd.com.au]

... It would appear
that the slide client can only delete a lock if it created
the lock in the *same* session. If I fire up the client,
create a lock, exit, fire it up again and attempt an unlock,
the operation fails. Nothing appears on the wire. A brief
troll through the code suggests the client won't even try if
it doesn't find the lock in its internal state structure, and
this structure only gets populated as part of a lock operation
- though I'm happy to be corrected.


Can anyone confirm whether this is the expected client behaviour,
or a bug? I would have thought you should be able to unlock a
resource independent of when the lock operation occurred.



From w3c-dist-auth-request@w3.org  Wed Sep  4 10:25:28 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01395
	for <webdav-archive@lists.ietf.org>; Wed, 4 Sep 2002 10:25:28 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g84EJkA22206;
	Wed, 4 Sep 2002 10:19:46 -0400 (EDT)
Resent-Date: Wed, 4 Sep 2002 10:19:46 -0400 (EDT)
Resent-Message-Id: <200209041419.g84EJkA22206@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g84EJiv22186
	for <w3c-dist-auth@frink.w3.org>; Wed, 4 Sep 2002 10:19:44 -0400 (EDT)
Received: from smtp-relay-1.adobe.com (smtp-relay-1.adobe.com [192.150.11.1])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA18822
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 10:19:44 -0400
Received: from inner-relay-2.corp.adobe.com (inner-relay-2 [153.32.1.52])
	by smtp-relay-1.adobe.com (8.12.3/8.12.3) with ESMTP id g84ELbBk012088
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 07:21:37 -0700 (PDT)
Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192])
	by inner-relay-2.corp.adobe.com (8.12.3/8.12.3) with ESMTP id g84EGiUU021456
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 07:16:44 -0700 (PDT)
Received: from dan.local.brotsky.com ([130.248.188.138]) by
          mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul
          11 2001 16:32:57) with ESMTP id H1X3RW00.0G5; Wed, 4 Sep 2002
          07:19:08 -0700 
Date: Wed, 4 Sep 2002 07:19:07 -0700
Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v543)
Cc: Dan Brotsky <dbrotsky@adobe.com>, w3c-dist-auth@w3.org
To: "Clemm, Geoff" <gclemm@rational.com>
From: Dan Brotsky <dbrotsky@adobe.com>
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10808D715@SUS-MA1IT01>
Message-Id: <45D92420-C011-11D6-937B-0003931036B4@adobe.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.543)
Subject: Re: Interoperability for DAV:ishidden?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6545
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>
Content-Transfer-Encoding: 7bit


And me.  But only to the extent of specifying its meaning as a  
property, not to the extent of making it MUST behavior for clients.

     dan

On Wednesday, September 4, 2002, at 06:46 AM, Clemm, Geoff wrote:

>
> Adding DAV:ishidden if there is demonstrable interop support for it is  
> fine
> with me.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Wednesday, September 04, 2002 9:02 AM
> To: w3c-dist-auth@w3.org
> Subject: Interoperability for DAV:ishidden?
>
>
>
> Hi,
>
> one thing that the participants of the interop meeting may want to
> consider...
>
> A long time ago ([1]), Microsoft proposed a live property DAV:ishidden  
> which
> signals that a resource should be displayed as hidden in a UI.
>
> Support currently exists in:
>
> MS IIS 5.0: reports DAV:ishidden according to the file system flags of  
> the
> underlying file system
> MS webfolder client: asks for DAV:ishidden, and hides the resource  
> when it
> is reported as hidden
> SAP Enterprise Portal Server: treats DAV:ishidden as live property  
> with the
> semantics defined in [1]
>
> I think this is a really useful feature, and in case we can identify  
> another
> client that supports it, we may want to roll it into RFC2518.
>
> Regards, Julian
>
>
>
> [1]  
> <http://greenbytes.de/tech/webdav/draft-hopmann-collection-props- 
> 00.txt>
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Wed Sep  4 13:22:00 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11588
	for <webdav-archive@lists.ietf.org>; Wed, 4 Sep 2002 13:21:59 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g84HJDL26285;
	Wed, 4 Sep 2002 13:19:13 -0400 (EDT)
Resent-Date: Wed, 4 Sep 2002 13:19:13 -0400 (EDT)
Resent-Message-Id: <200209041719.g84HJDL26285@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g84HJCv26264
	for <w3c-dist-auth@frink.w3.org>; Wed, 4 Sep 2002 13:19:12 -0400 (EDT)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA01952
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 13:19:12 -0400
Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225])
	by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g84HJ2m04886
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 10:19:02 -0700 (PDT)
Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5d20d44c85118164e13c0@mailgate2.apple.com> for <w3c-dist-auth@w3.org>;
 Wed, 4 Sep 2002 10:19:02 -0700
Received: from luthji.apple.com (luthji.apple.com [17.202.43.76])
	by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g84HJ2V21310
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 10:19:02 -0700 (PDT)
Date: Wed, 4 Sep 2002 10:18:42 -0700
Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v543)
From: Jim Luther <luther.j@apple.com>
To: w3c-dist-auth@w3.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <JIEGINCHMLABHJBIGKBCCEIFFEAA.julian.reschke@gmx.de>
Message-Id: <5C84BAA8-C02A-11D6-B386-0003934B6A22@apple.com>
X-Mailer: Apple Mail (2.543)
Subject: Re: Interoperability for DAV:ishidden?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6546
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>
Content-Transfer-Encoding: 7bit


If this were part of the standard, I'd certainly want to support it.  
Mac OS X creates some files which are intended to be hidden (being UNIX  
based, Mac OS X hides files which begin with a "." character) and so a  
standard WebDAV property to indicate that a file is supposed to be  
hidden would be welcome.

- Jim

On Wednesday, September 4, 2002, at 06:01 AM, Julian Reschke wrote:

>
> Hi,
>
> one thing that the participants of the interop meeting may want to
> consider...
>
> A long time ago ([1]), Microsoft proposed a live property DAV:ishidden  
> which
> signals that a resource should be displayed as hidden in a UI.
>
> Support currently exists in:
>
> MS IIS 5.0: reports DAV:ishidden according to the file system flags of  
> the
> underlying file system
> MS webfolder client: asks for DAV:ishidden, and hides the resource  
> when it
> is reported as hidden
> SAP Enterprise Portal Server: treats DAV:ishidden as live property  
> with the
> semantics defined in [1]
>
> I think this is a really useful feature, and in case we can identify  
> another
> client that supports it, we may want to roll it into RFC2518.
>
> Regards, Julian
>
>
>
> [1]  
> <http://greenbytes.de/tech/webdav/draft-hopmann-collection-props- 
> 00.txt>
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Wed Sep  4 13:31:15 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12124
	for <webdav-archive@lists.ietf.org>; Wed, 4 Sep 2002 13:31:15 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g84HUAB27483;
	Wed, 4 Sep 2002 13:30:10 -0400 (EDT)
Resent-Date: Wed, 4 Sep 2002 13:30:10 -0400 (EDT)
Resent-Message-Id: <200209041730.g84HUAB27483@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g84HU5v27462
	for <w3c-dist-auth@frink.w3.org>; Wed, 4 Sep 2002 13:30:05 -0400 (EDT)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA04290
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 13:30:04 -0400
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225])
	by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g84HU3m10172
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 10:30:03 -0700 (PDT)
Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5d20de50d5118064e13b0@mailgate1.apple.com>;
 Wed, 4 Sep 2002 10:29:59 -0700
Received: from luthji.apple.com (luthji.apple.com [17.202.43.76])
	by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g84HU0317395;
	Wed, 4 Sep 2002 10:30:00 -0700 (PDT)
Date: Wed, 4 Sep 2002 10:29:41 -0700
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v543)
From: Jim Luther <luther.j@apple.com>
To: interop@webdav.org, WebDAV <w3c-dist-auth@w3.org>
Content-Transfer-Encoding: 7bit
In-Reply-To: <AMEPKEBLDJJCCDEJHAMIGEALFGAA.ejw@cse.ucsc.edu>
Message-Id: <E4EA7ECC-C02B-11D6-B386-0003934B6A22@apple.com>
X-Mailer: Apple Mail (2.543)
Subject: Re: Interop Event FAQ
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6547
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>
Content-Transfer-Encoding: 7bit


> * Who is coming to the event?
>
> We're expecting about 35 people, from the following companies and 
> projects
> (in no particular order):
>
> Adobe (client and server side I believe), Microsoft (Windows CE, 
> Sharepoint,
> Exchange), Oracle, Merant, Xythos, Software AG, Alias|Wavefront, kCura,
> NetApp. Greg Stein/Apache mod_dav will be present, as will several 
> students
> from UCSC, representing the Catacomb server and Cadaver client. An 
> improved
> version of Litmus will also be used at the event.

Engineers from Apple Computer will be attending (Mac OS X file system 
client, iDisk server, and XServe).

> * Will there be any test equipment provided at the event, such as a 
> packet
> sniffer?

I'm planning to bring an extra PowerBook with Etherpeek installed. In 
addition, my development/test system will have tcpdump and tcpflow 
installed.

Jim Luther
Apple Computer, Inc.



From w3c-dist-auth-request@w3.org  Wed Sep  4 14:38:44 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15050
	for <webdav-archive@lists.ietf.org>; Wed, 4 Sep 2002 14:38:44 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g84Icno06296;
	Wed, 4 Sep 2002 14:38:49 -0400 (EDT)
Resent-Date: Wed, 4 Sep 2002 14:38:49 -0400 (EDT)
Resent-Message-Id: <200209041838.g84Icno06296@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g84Iclv06271
	for <w3c-dist-auth@frink.w3.org>; Wed, 4 Sep 2002 14:38:47 -0400 (EDT)
Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA19834
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 14:38:46 -0400
Received: from inet-mail4.oracle.com (localhost [127.0.0.1])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g84IcG722561
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 11:38:16 -0700 (PDT)
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g84IcFp22549
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 11:38:15 -0700 (PDT)
Received: from rgmum1.us.oracle.com (rgmum1.us.oracle.com [138.1.191.22])
	by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g84IcEO18181
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 12:38:14 -0600 (MDT)
Received: from 152.68.17.155 by rgmum1.us.oracle.com
	with ESMTP id 57834101031164804; Wed, 04 Sep 2002 12:40:04 -0600
Message-ID: <01c601c25440$fd104fe0$9b114498@esedlar>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: "Jim Luther" <luther.j@apple.com>, <w3c-dist-auth@w3.org>
References: <5C84BAA8-C02A-11D6-B386-0003934B6A22@apple.com>
Date: Wed, 4 Sep 2002 11:29:21 -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: Interoperability for DAV:ishidden?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6548
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>
Content-Transfer-Encoding: 7bit


Are any other of the Microsoft proposed extensions of general interest?
They have a property like "has-children" or something as well, I believe,
that they use...

--Eric

----- Original Message -----
From: "Jim Luther" <luther.j@apple.com>
To: <w3c-dist-auth@w3.org>
Sent: Wednesday, September 04, 2002 10:18 AM
Subject: Re: Interoperability for DAV:ishidden?


>
> If this were part of the standard, I'd certainly want to support it.
> Mac OS X creates some files which are intended to be hidden (being UNIX
> based, Mac OS X hides files which begin with a "." character) and so a
> standard WebDAV property to indicate that a file is supposed to be
> hidden would be welcome.
>
> - Jim
>
> On Wednesday, September 4, 2002, at 06:01 AM, Julian Reschke wrote:
>
> >
> > Hi,
> >
> > one thing that the participants of the interop meeting may want to
> > consider...
> >
> > A long time ago ([1]), Microsoft proposed a live property DAV:ishidden
> > which
> > signals that a resource should be displayed as hidden in a UI.
> >
> > Support currently exists in:
> >
> > MS IIS 5.0: reports DAV:ishidden according to the file system flags of
> > the
> > underlying file system
> > MS webfolder client: asks for DAV:ishidden, and hides the resource
> > when it
> > is reported as hidden
> > SAP Enterprise Portal Server: treats DAV:ishidden as live property
> > with the
> > semantics defined in [1]
> >
> > I think this is a really useful feature, and in case we can identify
> > another
> > client that supports it, we may want to roll it into RFC2518.
> >
> > Regards, Julian
> >
> >
> >
> > [1]
> > <http://greenbytes.de/tech/webdav/draft-hopmann-collection-props-
> > 00.txt>
> >
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >
>
>



From w3c-dist-auth-request@w3.org  Wed Sep  4 20:16:36 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25386
	for <webdav-archive@lists.ietf.org>; Wed, 4 Sep 2002 20:16:36 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g850GKQ06451;
	Wed, 4 Sep 2002 20:16:20 -0400 (EDT)
Resent-Date: Wed, 4 Sep 2002 20:16:20 -0400 (EDT)
Resent-Message-Id: <200209050016.g850GKQ06451@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g850GJv06431
	for <w3c-dist-auth@frink.w3.org>; Wed, 4 Sep 2002 20:16:19 -0400 (EDT)
Received: from cts01.webone.com.au (cts01.webone.com.au [210.9.240.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA11694
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 20:16:18 -0400
Received: from ammd01 (dial-ctb0368.webone.com.au [210.9.243.68])
	by cts01.webone.com.au (8.9.3/8.9.3) with SMTP id KAA09117;
	Thu, 5 Sep 2002 10:16:11 +1000
From: "Michael Leditschke" <mike@ammd.com.au>
To: "Clemm, Geoff" <gclemm@rational.com>, <w3c-dist-auth@w3.org>
Date: Thu, 5 Sep 2002 10:16:00 +1000
Message-ID: <LOBBICBLDJIJHPNJFPOLAEDJCMAA.mike@ammd.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10808D725@SUS-MA1IT01>
Importance: Normal
Subject: RE: What is left after LOCK/UNLOCK on null resource?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6549
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>
Content-Transfer-Encoding: 7bit


> It is very reasonable/sensible behavior for a client to
> refuse to unlock a resource if it wasn't the process that
> took out the lock.  A client should never unlock such
> a resource without getting explicit confirmation from the
> user to do so, but a client can reasonably refuse to give
> the user that choice, because a user is often not in a
> position to make the right choice (i.e. forgets or is not
> aware that something else being done on their behalf requires
> that resource to be locked).
> 
> 

I guess it depends on your definition of process. DAV locks are
supposed to be capable of being held for an extended time. I might 
want to lock a resource, edit it for a while locally, then push the
result back and unlock it again. Are you suggesting this all has
to be done by the same OS process? What happens if the power goes
out and my PC reboots? Or perhaps you expect the client to cache
locktokens?

In my case, it is the same client I'm using to lock and unlock and
I'm presenting the same credentials to the server. Its a low
level test program, so I would have thought being able to unlock
a resource of which I am the owner would be reasonable.

Regards
Michael



From w3c-dist-auth-request@w3.org  Wed Sep  4 22:12:39 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27470
	for <webdav-archive@lists.ietf.org>; Wed, 4 Sep 2002 22:12:39 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g852CXo16817;
	Wed, 4 Sep 2002 22:12:33 -0400 (EDT)
Resent-Date: Wed, 4 Sep 2002 22:12:33 -0400 (EDT)
Resent-Message-Id: <200209050212.g852CXo16817@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g852CWv16797
	for <w3c-dist-auth@frink.w3.org>; Wed, 4 Sep 2002 22:12:32 -0400 (EDT)
Received: from inet-mail2.oracle.com (inet-mail2.oracle.com [148.87.2.202])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA27633
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 22:12:32 -0400
Received: from inet-mail2.oracle.com (localhost [127.0.0.1])
	by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g852C0Z29944
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 19:12:00 -0700 (PDT)
Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14])
	by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g852BxZ29891
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 19:11:59 -0700 (PDT)
Received: from rgmum2.us.oracle.com (rgmum2.us.oracle.com [138.1.191.23])
	by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g852Bxn24652
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 20:11:59 -0600 (MDT)
Received: from dhcp-4op7-4op8-east-130-35-171-81.us.oracle.com by rgmum3.us.oracle.com
	with ESMTP id 58117411031191730; Wed, 04 Sep 2002 20:08:50 -0600
Message-ID: <00ce01c25481$03af9c30$51ab2382@us.oracle.com>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: <w3c-dist-auth@w3.org>
References: <5C84BAA8-C02A-11D6-B386-0003934B6A22@apple.com>
Date: Wed, 4 Sep 2002 19:07:40 -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: Interoperability for DAV:ishidden?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6550
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>
Content-Transfer-Encoding: 7bit


One property that keeps coming up (also in the Microsoft proposal) is the
resource-ID property, to uniquely identify a resource (generally a GUID).
I'm constantly getting requests from internal groups for this, and I know a
lot of the JSR-170 people are interested in this for content management
apps.

Of course another related requirement is the ability to fetch resources by
ID.  This could be done either by fully utilizing the DAV: namespace, e.g.
DAV:<resourceID> as the URL or by waiting for DASL.

--Eric




From w3c-dist-auth-request@w3.org  Wed Sep  4 22:28:12 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27734
	for <webdav-archive@lists.ietf.org>; Wed, 4 Sep 2002 22:28:11 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g852SXv18277;
	Wed, 4 Sep 2002 22:28:33 -0400 (EDT)
Resent-Date: Wed, 4 Sep 2002 22:28:33 -0400 (EDT)
Resent-Message-Id: <200209050228.g852SXv18277@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g852SWv18257
	for <w3c-dist-auth@frink.w3.org>; Wed, 4 Sep 2002 22:28:32 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA29578
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 22:28:32 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 04 Sep 2002 22:18:46 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <P4FXWCM1>; Wed, 4 Sep 2002 22:28:01 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10808D8AD@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Wed, 4 Sep 2002 22:28:01 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: What is left after LOCK/UNLOCK on null resource?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6551
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>


   From: Michael Leditschke [mailto:mike@ammd.com.au]

   DAV locks are
   supposed to be capable of being held for an extended time.

Only by the process that took out the lock.

   I might 
   want to lock a resource, edit it for a while locally, then push the
   result back and unlock it again. Are you suggesting this all has
   to be done by the same OS process?

Yes.

   What happens if the power goes out and my PC reboots?

The new process needs to obtain its own (new) lock.  The old
lock is cleaned up by a timeout, or if allowed by the server,
the new process can clean up the old lock with an UNLOCK.
The new process shouldn't "reuse" the old lock, unless you have
some way of guaranteeing that two processes cannot both reuse the
old lock at the same time.

   Or perhaps you expect the client to cache locktokens?

Only if the cache has some way of guaranteeing that only one
process can obtain the cached locktoken.

   In my case, it is the same client I'm using to lock and unlock and
   I'm presenting the same credentials to the server. Its a low
   level test program, so I would have thought being able to unlock
   a resource of which I am the owner would be reasonable.

Unlocking is reasonable (unlike "reusing", which is not), but some
servers do not trust clients to appropriately unlock something they
didn't lock (since the client can't automatically know that it is
appropriate to do so, and even if it asks the user, the user can be
mistaken).  Those servers require clients to depend on timeouts.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Wed Sep  4 22:59:15 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28679
	for <webdav-archive@lists.ietf.org>; Wed, 4 Sep 2002 22:59:15 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g852xb424993;
	Wed, 4 Sep 2002 22:59:37 -0400 (EDT)
Resent-Date: Wed, 4 Sep 2002 22:59:37 -0400 (EDT)
Resent-Message-Id: <200209050259.g852xb424993@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g852xZv24924
	for <w3c-dist-auth@frink.w3.org>; Wed, 4 Sep 2002 22:59:35 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA02216
	for <w3c-dist-auth@w3.org>; Wed, 4 Sep 2002 22:59:35 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 04 Sep 2002 22:49:49 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <P4FXWDDV>; Wed, 4 Sep 2002 22:59:04 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10808D8BC@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Wed, 4 Sep 2002 22:59:03 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Interoperability for DAV:ishidden?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6552
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>


We'll get DAV:resourceid in the binding draft ... which I *have* 
been working on, but got interrupted by the stuff they pay me to do (:-).

Cheers,
Geoff

-----Original Message-----
From: Eric Sedlar [mailto:eric.sedlar@oracle.com]
Sent: Wednesday, September 04, 2002 10:08 PM
To: w3c-dist-auth@w3.org
Subject: Re: Interoperability for DAV:ishidden?



One property that keeps coming up (also in the Microsoft proposal) is the
resource-ID property, to uniquely identify a resource (generally a GUID).
I'm constantly getting requests from internal groups for this, and I know a
lot of the JSR-170 people are interested in this for content management
apps.

Of course another related requirement is the ability to fetch resources by
ID.  This could be done either by fully utilizing the DAV: namespace, e.g.
DAV:<resourceID> as the URL or by waiting for DASL.

--Eric



From w3c-dist-auth-request@w3.org  Thu Sep  5 00:34:50 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00336
	for <webdav-archive@lists.ietf.org>; Thu, 5 Sep 2002 00:34:49 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g854Z1Y09052;
	Thu, 5 Sep 2002 00:35:01 -0400 (EDT)
Resent-Date: Thu, 5 Sep 2002 00:35:01 -0400 (EDT)
Resent-Message-Id: <200209050435.g854Z1Y09052@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g854Yxv09006
	for <w3c-dist-auth@frink.w3.org>; Thu, 5 Sep 2002 00:34:59 -0400 (EDT)
Received: from cts01.webone.com.au (cts01.webone.com.au [210.9.240.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA13305
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 00:34:57 -0400
Received: from ammd01 (dial-ctb0368.webone.com.au [210.9.243.68])
	by cts01.webone.com.au (8.9.3/8.9.3) with SMTP id OAA32105;
	Thu, 5 Sep 2002 14:34:46 +1000
From: "Michael Leditschke" <mike@ammd.com.au>
To: "Clemm, Geoff" <gclemm@rational.com>, <w3c-dist-auth@w3.org>
Date: Thu, 5 Sep 2002 14:34:45 +1000
Message-ID: <LOBBICBLDJIJHPNJFPOLOEDKCMAA.mike@ammd.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10808D8AD@SUS-MA1IT01>
Importance: Normal
Subject: RE: What is left after LOCK/UNLOCK on null resource?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6553
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>
Content-Transfer-Encoding: 7bit


> The new process needs to obtain its own (new) lock.  The old
> lock is cleaned up by a timeout, or if allowed by the server,
> the new process can clean up the old lock with an UNLOCK.
> The new process shouldn't "reuse" the old lock, unless you have
> some way of guaranteeing that two processes cannot both reuse the
> old lock at the same time.

And if the lock were exclusive with an infinite timeout? A lock
on an already locked resource will fail. Isn't lock re-use the
only option apart from Administrator intervention?

Is it fair to say the locking model is more oriented to 
transient locking rather than long term locking?


Regards
Michael




From w3c-dist-auth-request@w3.org  Thu Sep  5 04:17:59 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12661
	for <webdav-archive@lists.ietf.org>; Thu, 5 Sep 2002 04:17:59 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g858HrK00581;
	Thu, 5 Sep 2002 04:17:53 -0400 (EDT)
Resent-Date: Thu, 5 Sep 2002 04:17:53 -0400 (EDT)
Resent-Message-Id: <200209050817.g858HrK00581@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g858Hqv00536
	for <w3c-dist-auth@frink.w3.org>; Thu, 5 Sep 2002 04:17:52 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA10467
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 04:17:51 -0400
Received: (qmail 8076 invoked by uid 0); 5 Sep 2002 08:17:29 -0000
Received: from p3ee2482e.dip.t-dialin.net (HELO lisa) (62.226.72.46)
  by mail.gmx.net (mp008-rz3) with SMTP; 5 Sep 2002 08:17:29 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Eric Sedlar" <eric.sedlar@oracle.com>, <w3c-dist-auth@w3.org>
Date: Thu, 5 Sep 2002 10:17:26 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCMEJPFEAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <00ce01c25481$03af9c30$51ab2382@us.oracle.com>
Subject: RE: Interoperability for DAV:ishidden?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6554
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>
Content-Transfer-Encoding: 7bit


> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> Sent: Thursday, September 05, 2002 4:08 AM
> To: w3c-dist-auth@w3.org
> Subject: Re: Interoperability for DAV:ishidden?
>
>
>
> One property that keeps coming up (also in the Microsoft proposal) is the
> resource-ID property, to uniquely identify a resource (generally a GUID).
> I'm constantly getting requests from internal groups for this,
> and I know a
> lot of the JSR-170 people are interested in this for content management
> apps.

As Geoff pointed out, this will be available as part of the BIND spec. It
could be used on systems even when they don't specifically support the BIND
method.

> Of course another related requirement is the ability to fetch resources by
> ID.  This could be done either by fully utilizing the DAV: namespace, e.g.
> DAV:<resourceID> as the URL or by waiting for DASL.

First of all, the "unique resource ID" just is a URI. Which URI scheme is
used is up to the server. So it's completely free to assign an HTTP URI, and
this obviously could then be used to fetch the ressource. If the resourceId
isn't an HTTP URI, WebDAV doesn't give you any direct mean to retrieve it.

Re: locating a WebDAV ressource by resourceid -- this won't work with the
current DASL spec (at least not with the DAV:basicsearch grammar), as I
expect the property to have DAV:href content -- something in which you can't
search using DASL. Therefore, a REPORT (locate-by-resourceid) may be
appropriate...

Julian

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




From w3c-dist-auth-request@w3.org  Thu Sep  5 07:52:59 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16010
	for <webdav-archive@lists.ietf.org>; Thu, 5 Sep 2002 07:52:59 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g85Bov524265;
	Thu, 5 Sep 2002 07:50:57 -0400 (EDT)
Resent-Date: Thu, 5 Sep 2002 07:50:57 -0400 (EDT)
Resent-Message-Id: <200209051150.g85Bov524265@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g85Bouv24245
	for <w3c-dist-auth@frink.w3.org>; Thu, 5 Sep 2002 07:50:56 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA13690
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 07:50:56 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 05 Sep 2002 07:41:09 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <P4FXXA99>; Thu, 5 Sep 2002 07:50:25 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10808D901@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Thu, 5 Sep 2002 07:50:25 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: What is left after LOCK/UNLOCK on null resource?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6555
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>


   From: Michael Leditschke [mailto:mike@ammd.com.au]

   > The new process needs to obtain its own (new) lock.  The old
   > lock is cleaned up by a timeout, or if allowed by the server,
   > the new process can clean up the old lock with an UNLOCK.
   > The new process shouldn't "reuse" the old lock, unless you have
   > some way of guaranteeing that two processes cannot both reuse the
   > old lock at the same time.

   And if the lock were exclusive with an infinite timeout? A lock
   on an already locked resource will fail. Isn't lock re-use the
   only option apart from Administrator intervention?

We need to carefully distinguish "re-using" the old lock,
from "deleting" (i.e. unlocking) the old lock.  It is reasonable
to have another process unlock a resource, because if the
other process holding that lock token is still alive, and
tries an update with the old lock, the update will fail
(although the old process is now stuck with a merge situation,
which is what the lock was being used to prevent in the
first place ... if it just wanted overwrite protection, it
could have just used Etags).  It is never reasonable to
have a process re-use a lock token allocated by another process
(i.e. use that lock token in a PUT or PROPPATCH).

I believe the "right" answer is that a server should never
allow an infinite timeout on a lock.

   Is it fair to say the locking model is more oriented to 
   transient locking rather than long term locking?

Yes.  For "long term locking", you'd want to use the
checkout/checkin model provided by the DeltaV WebDAV extensions.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Thu Sep  5 07:58:42 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16185
	for <webdav-archive@lists.ietf.org>; Thu, 5 Sep 2002 07:58:42 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g85BvPP25803;
	Thu, 5 Sep 2002 07:57:25 -0400 (EDT)
Resent-Date: Thu, 5 Sep 2002 07:57:25 -0400 (EDT)
Resent-Message-Id: <200209051157.g85BvPP25803@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g85BvPv25782
	for <w3c-dist-auth@frink.w3.org>; Thu, 5 Sep 2002 07:57:25 -0400 (EDT)
Received: from cts01.webone.com.au (cts01.webone.com.au [210.9.240.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA14842
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 07:57:23 -0400
Received: from ammd01 (dial-ctb0368.webone.com.au [210.9.243.68])
	by cts01.webone.com.au (8.9.3/8.9.3) with SMTP id VAA02646;
	Thu, 5 Sep 2002 21:57:18 +1000
From: "Michael Leditschke" <mike@ammd.com.au>
To: "Clemm, Geoff" <gclemm@rational.com>, <w3c-dist-auth@w3.org>
Date: Thu, 5 Sep 2002 21:57:18 +1000
Message-ID: <LOBBICBLDJIJHPNJFPOLEEEECMAA.mike@ammd.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10808D901@SUS-MA1IT01>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: RE: What is left after LOCK/UNLOCK on null resource?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6556
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>
Content-Transfer-Encoding: 7bit


> We need to carefully distinguish "re-using" the old lock,
> from "deleting" (i.e. unlocking) the old lock.  It is reasonable
> to have another process unlock a resource, because if the
> other process holding that lock token is still alive, and
> tries an update with the old lock, the update will fail
> (although the old process is now stuck with a merge situation,
> which is what the lock was being used to prevent in the
> first place ... if it just wanted overwrite protection, it
> could have just used Etags).  It is never reasonable to
> have a process re-use a lock token allocated by another process
> (i.e. use that lock token in a PUT or PROPPATCH).
> 
> I believe the "right" answer is that a server should never
> allow an infinite timeout on a lock.
> 
>    Is it fair to say the locking model is more oriented to 
>    transient locking rather than long term locking?
> 
> Yes.  For "long term locking", you'd want to use the
> checkout/checkin model provided by the DeltaV WebDAV extensions.
> 
> Cheers,
> Geoff
> 
> 

Thanks for the clarification.

Regards
Michael



From w3c-dist-auth-request@w3.org  Thu Sep  5 08:07:22 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16489
	for <webdav-archive@lists.ietf.org>; Thu, 5 Sep 2002 08:07:22 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g85C6Mi27807;
	Thu, 5 Sep 2002 08:06:22 -0400 (EDT)
Resent-Date: Thu, 5 Sep 2002 08:06:22 -0400 (EDT)
Resent-Message-Id: <200209051206.g85C6Mi27807@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g85C6Lv27786
	for <w3c-dist-auth@frink.w3.org>; Thu, 5 Sep 2002 08:06:21 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA19572
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 08:06:21 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 05 Sep 2002 07:56:34 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <P4FXXBTM>; Thu, 5 Sep 2002 08:05:50 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10808D903@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Thu, 5 Sep 2002 08:05:48 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Interoperability for DAV:ishidden?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6557
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>


The DASL spec doesn't have provisions for searching through
a DAV:href reference?  That sounds like an essential piece of functionality
for a DAV searching protocol.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Thursday, September 05, 2002 4:17 AM
To: Eric Sedlar; w3c-dist-auth@w3.org
Subject: RE: Interoperability for DAV:ishidden?



> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> Sent: Thursday, September 05, 2002 4:08 AM
> To: w3c-dist-auth@w3.org
> Subject: Re: Interoperability for DAV:ishidden?
>
>
>
> One property that keeps coming up (also in the Microsoft proposal) is the
> resource-ID property, to uniquely identify a resource (generally a GUID).
> I'm constantly getting requests from internal groups for this,
> and I know a
> lot of the JSR-170 people are interested in this for content management
> apps.

As Geoff pointed out, this will be available as part of the BIND spec. It
could be used on systems even when they don't specifically support the BIND
method.

> Of course another related requirement is the ability to fetch resources by
> ID.  This could be done either by fully utilizing the DAV: namespace, e.g.
> DAV:<resourceID> as the URL or by waiting for DASL.

First of all, the "unique resource ID" just is a URI. Which URI scheme is
used is up to the server. So it's completely free to assign an HTTP URI, and
this obviously could then be used to fetch the ressource. If the resourceId
isn't an HTTP URI, WebDAV doesn't give you any direct mean to retrieve it.

Re: locating a WebDAV ressource by resourceid -- this won't work with the
current DASL spec (at least not with the DAV:basicsearch grammar), as I
expect the property to have DAV:href content -- something in which you can't
search using DASL. Therefore, a REPORT (locate-by-resourceid) may be
appropriate...

Julian

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



From w3c-dist-auth-request@w3.org  Thu Sep  5 08:11:47 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16551
	for <webdav-archive@lists.ietf.org>; Thu, 5 Sep 2002 08:11:47 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g85CC6l28456;
	Thu, 5 Sep 2002 08:12:06 -0400 (EDT)
Resent-Date: Thu, 5 Sep 2002 08:12:06 -0400 (EDT)
Resent-Message-Id: <200209051212.g85CC6l28456@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g85CC4v28432
	for <w3c-dist-auth@frink.w3.org>; Thu, 5 Sep 2002 08:12:04 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA21939
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 08:12:04 -0400
Received: (qmail 7680 invoked by uid 0); 5 Sep 2002 12:12:00 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp009-rz3) with SMTP; 5 Sep 2002 12:12:00 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Clemm, Geoff" <gclemm@rational.com>, <w3c-dist-auth@w3.org>
Date: Thu, 5 Sep 2002 14:11:59 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCCEKHFEAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10808D903@SUS-MA1IT01>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: RE: Interoperability for DAV:ishidden?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6558
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>
Content-Transfer-Encoding: 7bit


Correct. Keep in mind that back when DAV:basicsearch was designed, there was
no href-typed DAV: property.

The issue here is to define a meaningful operator -- for instance, at a
minimum the operator would need to be able to resolve relativeURIs for
comparisons, right?

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Thursday, September 05, 2002 2:06 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: Interoperability for DAV:ishidden?
>
>
>
> The DASL spec doesn't have provisions for searching through
> a DAV:href reference?  That sounds like an essential piece of
> functionality
> for a DAV searching protocol.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Thursday, September 05, 2002 4:17 AM
> To: Eric Sedlar; w3c-dist-auth@w3.org
> Subject: RE: Interoperability for DAV:ishidden?
>
>
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> > Sent: Thursday, September 05, 2002 4:08 AM
> > To: w3c-dist-auth@w3.org
> > Subject: Re: Interoperability for DAV:ishidden?
> >
> >
> >
> > One property that keeps coming up (also in the Microsoft
> proposal) is the
> > resource-ID property, to uniquely identify a resource
> (generally a GUID).
> > I'm constantly getting requests from internal groups for this,
> > and I know a
> > lot of the JSR-170 people are interested in this for content management
> > apps.
>
> As Geoff pointed out, this will be available as part of the BIND spec. It
> could be used on systems even when they don't specifically
> support the BIND
> method.
>
> > Of course another related requirement is the ability to fetch
> resources by
> > ID.  This could be done either by fully utilizing the DAV:
> namespace, e.g.
> > DAV:<resourceID> as the URL or by waiting for DASL.
>
> First of all, the "unique resource ID" just is a URI. Which URI scheme is
> used is up to the server. So it's completely free to assign an
> HTTP URI, and
> this obviously could then be used to fetch the ressource. If the
> resourceId
> isn't an HTTP URI, WebDAV doesn't give you any direct mean to retrieve it.
>
> Re: locating a WebDAV ressource by resourceid -- this won't work with the
> current DASL spec (at least not with the DAV:basicsearch grammar), as I
> expect the property to have DAV:href content -- something in
> which you can't
> search using DASL. Therefore, a REPORT (locate-by-resourceid) may be
> appropriate...
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Thu Sep  5 08:37:18 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17048
	for <webdav-archive@lists.ietf.org>; Thu, 5 Sep 2002 08:37:18 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g85CbCx01907;
	Thu, 5 Sep 2002 08:37:12 -0400 (EDT)
Resent-Date: Thu, 5 Sep 2002 08:37:12 -0400 (EDT)
Resent-Message-Id: <200209051237.g85CbCx01907@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g85Cb9v01887
	for <w3c-dist-auth@frink.w3.org>; Thu, 5 Sep 2002 08:37:09 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA31324
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 08:37:09 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 05 Sep 2002 08:26:18 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <P4FXXDXS>; Thu, 5 Sep 2002 08:35:34 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10808D90C@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Thu, 5 Sep 2002 08:35:29 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Interoperability for DAV:ishidden?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6559
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>


I don't think we have to require that relativeURIs be resolved
for comparisons (since we can't expect a server to determine
when two URLs in general are bound to the same resource) but a
server should be allowed to do so.  The primary need is to be able
to say "find resources whose xxx:foo property refers to a resource
whose yyy:bar property has the value zzz" (i.e. to search through
hrefs the way DAV:expand-property lets you PROPFIND through hrefs.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Thursday, September 05, 2002 8:12 AM
To: Clemm, Geoff; w3c-dist-auth@w3.org
Subject: RE: Interoperability for DAV:ishidden?


Correct. Keep in mind that back when DAV:basicsearch was designed, there was
no href-typed DAV: property.

The issue here is to define a meaningful operator -- for instance, at a
minimum the operator would need to be able to resolve relativeURIs for
comparisons, right?

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Thursday, September 05, 2002 2:06 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: Interoperability for DAV:ishidden?
>
>
>
> The DASL spec doesn't have provisions for searching through
> a DAV:href reference?  That sounds like an essential piece of
> functionality
> for a DAV searching protocol.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Thursday, September 05, 2002 4:17 AM
> To: Eric Sedlar; w3c-dist-auth@w3.org
> Subject: RE: Interoperability for DAV:ishidden?
>
>
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> > Sent: Thursday, September 05, 2002 4:08 AM
> > To: w3c-dist-auth@w3.org
> > Subject: Re: Interoperability for DAV:ishidden?
> >
> >
> >
> > One property that keeps coming up (also in the Microsoft
> proposal) is the
> > resource-ID property, to uniquely identify a resource
> (generally a GUID).
> > I'm constantly getting requests from internal groups for this,
> > and I know a
> > lot of the JSR-170 people are interested in this for content management
> > apps.
>
> As Geoff pointed out, this will be available as part of the BIND spec. It
> could be used on systems even when they don't specifically
> support the BIND
> method.
>
> > Of course another related requirement is the ability to fetch
> resources by
> > ID.  This could be done either by fully utilizing the DAV:
> namespace, e.g.
> > DAV:<resourceID> as the URL or by waiting for DASL.
>
> First of all, the "unique resource ID" just is a URI. Which URI scheme is
> used is up to the server. So it's completely free to assign an
> HTTP URI, and
> this obviously could then be used to fetch the ressource. If the
> resourceId
> isn't an HTTP URI, WebDAV doesn't give you any direct mean to retrieve it.
>
> Re: locating a WebDAV ressource by resourceid -- this won't work with the
> current DASL spec (at least not with the DAV:basicsearch grammar), as I
> expect the property to have DAV:href content -- something in
> which you can't
> search using DASL. Therefore, a REPORT (locate-by-resourceid) may be
> appropriate...
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Thu Sep  5 08:41:45 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17163
	for <webdav-archive@lists.ietf.org>; Thu, 5 Sep 2002 08:41:44 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g85Cfs603130;
	Thu, 5 Sep 2002 08:41:54 -0400 (EDT)
Resent-Date: Thu, 5 Sep 2002 08:41:54 -0400 (EDT)
Resent-Message-Id: <200209051241.g85Cfs603130@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g85Cfpv03092
	for <w3c-dist-auth@frink.w3.org>; Thu, 5 Sep 2002 08:41:51 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA00498
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 08:41:51 -0400
Received: (qmail 27790 invoked by uid 0); 5 Sep 2002 12:41:41 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp013-rz3) with SMTP; 5 Sep 2002 12:41:41 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Clemm, Geoff" <gclemm@rational.com>, <w3c-dist-auth@w3.org>
Date: Thu, 5 Sep 2002 14:41:40 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCKEKIFEAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10808D90C@SUS-MA1IT01>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: RE: Interoperability for DAV:ishidden?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6560
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>
Content-Transfer-Encoding: 7bit


Well,

that's certainly a *new* requirement that hasn't been mentioned on the DASL
list before.

Is it useful? Yes. Does it belong into DAV:basicsearch? I don't think so.

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Thursday, September 05, 2002 2:35 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: Interoperability for DAV:ishidden?
>
>
>
> I don't think we have to require that relativeURIs be resolved
> for comparisons (since we can't expect a server to determine
> when two URLs in general are bound to the same resource) but a
> server should be allowed to do so.  The primary need is to be able
> to say "find resources whose xxx:foo property refers to a resource
> whose yyy:bar property has the value zzz" (i.e. to search through
> hrefs the way DAV:expand-property lets you PROPFIND through hrefs.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Thursday, September 05, 2002 8:12 AM
> To: Clemm, Geoff; w3c-dist-auth@w3.org
> Subject: RE: Interoperability for DAV:ishidden?
>
>
> Correct. Keep in mind that back when DAV:basicsearch was
> designed, there was
> no href-typed DAV: property.
>
> The issue here is to define a meaningful operator -- for instance, at a
> minimum the operator would need to be able to resolve relativeURIs for
> comparisons, right?
>
> Julian
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> > Sent: Thursday, September 05, 2002 2:06 PM
> > To: w3c-dist-auth@w3.org
> > Subject: RE: Interoperability for DAV:ishidden?
> >
> >
> >
> > The DASL spec doesn't have provisions for searching through
> > a DAV:href reference?  That sounds like an essential piece of
> > functionality
> > for a DAV searching protocol.
> >
> > Cheers,
> > Geoff
> >
> > -----Original Message-----
> > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > Sent: Thursday, September 05, 2002 4:17 AM
> > To: Eric Sedlar; w3c-dist-auth@w3.org
> > Subject: RE: Interoperability for DAV:ishidden?
> >
> >
> >
> > > -----Original Message-----
> > > From: w3c-dist-auth-request@w3.org
> > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> > > Sent: Thursday, September 05, 2002 4:08 AM
> > > To: w3c-dist-auth@w3.org
> > > Subject: Re: Interoperability for DAV:ishidden?
> > >
> > >
> > >
> > > One property that keeps coming up (also in the Microsoft
> > proposal) is the
> > > resource-ID property, to uniquely identify a resource
> > (generally a GUID).
> > > I'm constantly getting requests from internal groups for this,
> > > and I know a
> > > lot of the JSR-170 people are interested in this for content
> management
> > > apps.
> >
> > As Geoff pointed out, this will be available as part of the
> BIND spec. It
> > could be used on systems even when they don't specifically
> > support the BIND
> > method.
> >
> > > Of course another related requirement is the ability to fetch
> > resources by
> > > ID.  This could be done either by fully utilizing the DAV:
> > namespace, e.g.
> > > DAV:<resourceID> as the URL or by waiting for DASL.
> >
> > First of all, the "unique resource ID" just is a URI. Which URI
> scheme is
> > used is up to the server. So it's completely free to assign an
> > HTTP URI, and
> > this obviously could then be used to fetch the ressource. If the
> > resourceId
> > isn't an HTTP URI, WebDAV doesn't give you any direct mean to
> retrieve it.
> >
> > Re: locating a WebDAV ressource by resourceid -- this won't
> work with the
> > current DASL spec (at least not with the DAV:basicsearch grammar), as I
> > expect the property to have DAV:href content -- something in
> > which you can't
> > search using DASL. Therefore, a REPORT (locate-by-resourceid) may be
> > appropriate...
> >
> > Julian
> >
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >
>



From w3c-dist-auth-request@w3.org  Thu Sep  5 10:19:21 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20394
	for <webdav-archive@lists.ietf.org>; Thu, 5 Sep 2002 10:19:21 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g85EJMd25386;
	Thu, 5 Sep 2002 10:19:22 -0400 (EDT)
Resent-Date: Thu, 5 Sep 2002 10:19:22 -0400 (EDT)
Resent-Message-Id: <200209051419.g85EJMd25386@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g85EJLv25366
	for <w3c-dist-auth@frink.w3.org>; Thu, 5 Sep 2002 10:19:21 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA29568
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 10:19:20 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 05 Sep 2002 09:40:40 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <P4FXXKTQ>; Thu, 5 Sep 2002 09:49:56 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10808D942@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Thu, 5 Sep 2002 09:49:51 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Interoperability for DAV:ishidden?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6561
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>


Fair enough.  I have no problem deferring it to DAV:advancedsearch.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Thursday, September 05, 2002 8:42 AM
To: Clemm, Geoff; w3c-dist-auth@w3.org
Subject: RE: Interoperability for DAV:ishidden?


Well,

that's certainly a *new* requirement that hasn't been mentioned on the DASL
list before.

Is it useful? Yes. Does it belong into DAV:basicsearch? I don't think so.

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Thursday, September 05, 2002 2:35 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: Interoperability for DAV:ishidden?
>
>
>
> I don't think we have to require that relativeURIs be resolved
> for comparisons (since we can't expect a server to determine
> when two URLs in general are bound to the same resource) but a
> server should be allowed to do so.  The primary need is to be able
> to say "find resources whose xxx:foo property refers to a resource
> whose yyy:bar property has the value zzz" (i.e. to search through
> hrefs the way DAV:expand-property lets you PROPFIND through hrefs.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Thursday, September 05, 2002 8:12 AM
> To: Clemm, Geoff; w3c-dist-auth@w3.org
> Subject: RE: Interoperability for DAV:ishidden?
>
>
> Correct. Keep in mind that back when DAV:basicsearch was
> designed, there was
> no href-typed DAV: property.
>
> The issue here is to define a meaningful operator -- for instance, at a
> minimum the operator would need to be able to resolve relativeURIs for
> comparisons, right?
>
> Julian
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> > Sent: Thursday, September 05, 2002 2:06 PM
> > To: w3c-dist-auth@w3.org
> > Subject: RE: Interoperability for DAV:ishidden?
> >
> >
> >
> > The DASL spec doesn't have provisions for searching through
> > a DAV:href reference?  That sounds like an essential piece of
> > functionality
> > for a DAV searching protocol.
> >
> > Cheers,
> > Geoff
> >
> > -----Original Message-----
> > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > Sent: Thursday, September 05, 2002 4:17 AM
> > To: Eric Sedlar; w3c-dist-auth@w3.org
> > Subject: RE: Interoperability for DAV:ishidden?
> >
> >
> >
> > > -----Original Message-----
> > > From: w3c-dist-auth-request@w3.org
> > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> > > Sent: Thursday, September 05, 2002 4:08 AM
> > > To: w3c-dist-auth@w3.org
> > > Subject: Re: Interoperability for DAV:ishidden?
> > >
> > >
> > >
> > > One property that keeps coming up (also in the Microsoft
> > proposal) is the
> > > resource-ID property, to uniquely identify a resource
> > (generally a GUID).
> > > I'm constantly getting requests from internal groups for this,
> > > and I know a
> > > lot of the JSR-170 people are interested in this for content
> management
> > > apps.
> >
> > As Geoff pointed out, this will be available as part of the
> BIND spec. It
> > could be used on systems even when they don't specifically
> > support the BIND
> > method.
> >
> > > Of course another related requirement is the ability to fetch
> > resources by
> > > ID.  This could be done either by fully utilizing the DAV:
> > namespace, e.g.
> > > DAV:<resourceID> as the URL or by waiting for DASL.
> >
> > First of all, the "unique resource ID" just is a URI. Which URI
> scheme is
> > used is up to the server. So it's completely free to assign an
> > HTTP URI, and
> > this obviously could then be used to fetch the ressource. If the
> > resourceId
> > isn't an HTTP URI, WebDAV doesn't give you any direct mean to
> retrieve it.
> >
> > Re: locating a WebDAV ressource by resourceid -- this won't
> work with the
> > current DASL spec (at least not with the DAV:basicsearch grammar), as I
> > expect the property to have DAV:href content -- something in
> > which you can't
> > search using DASL. Therefore, a REPORT (locate-by-resourceid) may be
> > appropriate...
> >
> > Julian
> >
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >
>



From w3c-dist-auth-request@w3.org  Thu Sep  5 12:22:44 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24365
	for <webdav-archive@lists.ietf.org>; Thu, 5 Sep 2002 12:22:44 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g85GMPM13492;
	Thu, 5 Sep 2002 12:22:25 -0400 (EDT)
Resent-Date: Thu, 5 Sep 2002 12:22:25 -0400 (EDT)
Resent-Message-Id: <200209051622.g85GMPM13492@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g85GMNv13468
	for <w3c-dist-auth@frink.w3.org>; Thu, 5 Sep 2002 12:22:23 -0400 (EDT)
Received: from smtp-relay-1.adobe.com (smtp-relay-1.adobe.com [192.150.11.1])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA28404
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 12:22:23 -0400
Received: from inner-relay-2.corp.adobe.com (inner-relay-2 [153.32.1.52])
	by smtp-relay-1.adobe.com (8.12.3/8.12.3) with ESMTP id g85GOHBk018013
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 09:24:17 -0700 (PDT)
Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192])
	by inner-relay-2.corp.adobe.com (8.12.3/8.12.3) with ESMTP id g85GJOvW023002
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 09:19:24 -0700 (PDT)
Received: from c-159-46.corp.adobe.com ([153.32.159.46]) by
          mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul
          11 2001 16:32:57) with ESMTP id H1Z44B00.6YV; Thu, 5 Sep 2002
          09:21:47 -0700 
Date: Thu, 5 Sep 2002 09:20:15 -0700
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v543)
Cc: w3c-dist-auth@w3.org
To: Michael Leditschke <mike@ammd.com.au>
From: Dan Brotsky <dbrotsky@adobe.com>
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10808D8AD@SUS-MA1IT01>
Message-Id: <5C49FFC0-C0EB-11D6-9962-0003931036B4@adobe.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.543)
Subject: Re: What is left after LOCK/UNLOCK on null resource?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6562
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>
Content-Transfer-Encoding: 7bit


Michael,

Just for the record, I disagree with most all of Geoff's responses here 
(and in the subsequent thread), and I don't think he speaks "for the 
working group" in saying that the DAV spec favors time-limited locking.

In the first place, I think client implementation (at the level, for 
example, of "process") is way outside the scope of the spec.

Second, I believe that the language of the spec (as written) 
intentionally doesn't say much at all about what constitutes an 
"authoring client" (see section 6 on locking).  I think that's 
appropriate both because HTTP 1.1 is profoundly neutral about it and 
because WebDAV hopes to allow a broad range of interoperable 
implementations.

Third, there is a broad class of existing, interoperable 
implementations (the Adobe Systems WebDAV-enabled products) which 
communicate tokens among processes, persist tokens between invocations 
of processes, and use LOCKDISCOVERY values (both tokens and owner 
props) as a means of interoperating on the client side about authoring 
responsibility.  These impementations work against servers which allow 
infinite-duration locks and those which don't.

FWIW, I believe that lock expiration is really tied to a usage model in 
which clients actually use the server as a "remote file system," in the 
sense that they may only have a non-persistent buffer locally and all 
saves are done directly back to the server.  This is the model that 
Microsoft office clients use, for example, and they use lock timeouts 
as a way of preventing lock stranding when clients crash.

The model you outlined---a local working copy is made of a locked 
resource, that local copy is edited over an indefinite period of time, 
that local copy is occasionally "published" to the server, and then the 
server resource is unlocked after all local editing is complete---is 
exactly the model used by Adobe clients.  (I have been meaning for some 
time to write an explanation of why Adobe uses this model; maybe this 
thread will finally get me to do that.  Then again, maybe not. :^)  
But, in any event, it is quite natural in this model for lock tokens to 
be persisted by the editing clients that are using the local copy, 
because in this model all the editing state (including the lock token 
and owner information) is local-disk-specific not process-specific.

Finally, I'm not really sure why Geoff says that delta-V is 
specifically better suited than "plain" DAV for use by clients who use 
long-term locks.  Versioning servers are arguably a better choice than 
non-versioning servers for almost all collaborative authoring 
applications, delta-V is (of course) a DAV extension, and in fact 
delta-V specifically provides for backward compatibility around DAV 
locking for non-delta-V clients who wish to get the benefits of 
versioning.  So I really don't think lock (or checkout) duration has 
much to do with the difference between delta-V and DAV.

     dan

On Wednesday, September 4, 2002, at 07:28 PM, Clemm, Geoff wrote:

>
>    From: Michael Leditschke [mailto:mike@ammd.com.au]
>
>    DAV locks are
>    supposed to be capable of being held for an extended time.
>
> Only by the process that took out the lock.
>
>    I might
>    want to lock a resource, edit it for a while locally, then push the
>    result back and unlock it again. Are you suggesting this all has
>    to be done by the same OS process?
>
> Yes.
>
>    What happens if the power goes out and my PC reboots?
>
> The new process needs to obtain its own (new) lock.  The old
> lock is cleaned up by a timeout, or if allowed by the server,
> the new process can clean up the old lock with an UNLOCK.
> The new process shouldn't "reuse" the old lock, unless you have
> some way of guaranteeing that two processes cannot both reuse the
> old lock at the same time.
>
>    Or perhaps you expect the client to cache locktokens?
>
> Only if the cache has some way of guaranteeing that only one
> process can obtain the cached locktoken.
>
>    In my case, it is the same client I'm using to lock and unlock and
>    I'm presenting the same credentials to the server. Its a low
>    level test program, so I would have thought being able to unlock
>    a resource of which I am the owner would be reasonable.
>
> Unlocking is reasonable (unlike "reusing", which is not), but some
> servers do not trust clients to appropriately unlock something they
> didn't lock (since the client can't automatically know that it is
> appropriate to do so, and even if it asks the user, the user can be
> mistaken).  Those servers require clients to depend on timeouts.
>
> Cheers,
> Geoff
>



From w3c-dist-auth-request@w3.org  Thu Sep  5 13:51:55 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29091
	for <webdav-archive@lists.ietf.org>; Thu, 5 Sep 2002 13:51:54 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g85HpmX27754;
	Thu, 5 Sep 2002 13:51:48 -0400 (EDT)
Resent-Date: Thu, 5 Sep 2002 13:51:48 -0400 (EDT)
Resent-Message-Id: <200209051751.g85HpmX27754@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g85Hpkv27734
	for <w3c-dist-auth@frink.w3.org>; Thu, 5 Sep 2002 13:51:46 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA16090
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 13:51:45 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 05 Sep 2002 13:41:57 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <P4FXYC9K>; Thu, 5 Sep 2002 13:51:14 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1078391FB@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Thu, 5 Sep 2002 13:51:13 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: What is left after LOCK/UNLOCK on null resource?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6563
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>


On at least one point, Dan and I are in complete agreement,
which is that I speak for myself, and not for the working group
as a whole.

But until Dan (or someone) has published a convincing rationale
for having multiple processes reuse the lock token for an exclusive
lock,  I will continue to maintain that an exclusive lock token should
only be used in an update request (PUT/PROPPATCH) by the process
that took out the lock originally.  (Note that I do not at all 
object to another process UNLOCK'ing a lock created by another
process).

If you want to allow multiple processes to effectively "share"
a lock token, the protocol has defined shared locks.

My point about using the DeltaV protocol for "long-lived locking"
(or "shared locking) applications was that using this protocol
would allow a client to effectively interoperate with a wider
variety of servers (both versioning and non-versioning), with the
"version URL" effectively replacing the functionality of the
"shared lock token". 

Cheers,
Geoff 

-----Original Message-----
From: Dan Brotsky [mailto:dbrotsky@adobe.com]
Sent: Thursday, September 05, 2002 12:20 PM
To: Michael Leditschke
Cc: w3c-dist-auth@w3.org
Subject: Re: What is left after LOCK/UNLOCK on null resource?



Michael,

Just for the record, I disagree with most all of Geoff's responses here 
(and in the subsequent thread), and I don't think he speaks "for the 
working group" in saying that the DAV spec favors time-limited locking.

In the first place, I think client implementation (at the level, for 
example, of "process") is way outside the scope of the spec.

Second, I believe that the language of the spec (as written) 
intentionally doesn't say much at all about what constitutes an 
"authoring client" (see section 6 on locking).  I think that's 
appropriate both because HTTP 1.1 is profoundly neutral about it and 
because WebDAV hopes to allow a broad range of interoperable 
implementations.

Third, there is a broad class of existing, interoperable 
implementations (the Adobe Systems WebDAV-enabled products) which 
communicate tokens among processes, persist tokens between invocations 
of processes, and use LOCKDISCOVERY values (both tokens and owner 
props) as a means of interoperating on the client side about authoring 
responsibility.  These impementations work against servers which allow 
infinite-duration locks and those which don't.

FWIW, I believe that lock expiration is really tied to a usage model in 
which clients actually use the server as a "remote file system," in the 
sense that they may only have a non-persistent buffer locally and all 
saves are done directly back to the server.  This is the model that 
Microsoft office clients use, for example, and they use lock timeouts 
as a way of preventing lock stranding when clients crash.

The model you outlined---a local working copy is made of a locked 
resource, that local copy is edited over an indefinite period of time, 
that local copy is occasionally "published" to the server, and then the 
server resource is unlocked after all local editing is complete---is 
exactly the model used by Adobe clients.  (I have been meaning for some 
time to write an explanation of why Adobe uses this model; maybe this 
thread will finally get me to do that.  Then again, maybe not. :^)  
But, in any event, it is quite natural in this model for lock tokens to 
be persisted by the editing clients that are using the local copy, 
because in this model all the editing state (including the lock token 
and owner information) is local-disk-specific not process-specific.

Finally, I'm not really sure why Geoff says that delta-V is 
specifically better suited than "plain" DAV for use by clients who use 
long-term locks.  Versioning servers are arguably a better choice than 
non-versioning servers for almost all collaborative authoring 
applications, delta-V is (of course) a DAV extension, and in fact 
delta-V specifically provides for backward compatibility around DAV 
locking for non-delta-V clients who wish to get the benefits of 
versioning.  So I really don't think lock (or checkout) duration has 
much to do with the difference between delta-V and DAV.

     dan

On Wednesday, September 4, 2002, at 07:28 PM, Clemm, Geoff wrote:

>
>    From: Michael Leditschke [mailto:mike@ammd.com.au]
>
>    DAV locks are
>    supposed to be capable of being held for an extended time.
>
> Only by the process that took out the lock.
>
>    I might
>    want to lock a resource, edit it for a while locally, then push the
>    result back and unlock it again. Are you suggesting this all has
>    to be done by the same OS process?
>
> Yes.
>
>    What happens if the power goes out and my PC reboots?
>
> The new process needs to obtain its own (new) lock.  The old
> lock is cleaned up by a timeout, or if allowed by the server,
> the new process can clean up the old lock with an UNLOCK.
> The new process shouldn't "reuse" the old lock, unless you have
> some way of guaranteeing that two processes cannot both reuse the
> old lock at the same time.
>
>    Or perhaps you expect the client to cache locktokens?
>
> Only if the cache has some way of guaranteeing that only one
> process can obtain the cached locktoken.
>
>    In my case, it is the same client I'm using to lock and unlock and
>    I'm presenting the same credentials to the server. Its a low
>    level test program, so I would have thought being able to unlock
>    a resource of which I am the owner would be reasonable.
>
> Unlocking is reasonable (unlike "reusing", which is not), but some
> servers do not trust clients to appropriately unlock something they
> didn't lock (since the client can't automatically know that it is
> appropriate to do so, and even if it asks the user, the user can be
> mistaken).  Those servers require clients to depend on timeouts.
>
> Cheers,
> Geoff
>



From w3c-dist-auth-request@w3.org  Thu Sep  5 14:03:46 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29849
	for <webdav-archive@lists.ietf.org>; Thu, 5 Sep 2002 14:03:46 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g85I40E29613;
	Thu, 5 Sep 2002 14:04:00 -0400 (EDT)
Resent-Date: Thu, 5 Sep 2002 14:04:00 -0400 (EDT)
Resent-Message-Id: <200209051804.g85I40E29613@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g85I3tv29564
	for <w3c-dist-auth@frink.w3.org>; Thu, 5 Sep 2002 14:03:55 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA18781
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 14:03:55 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 05 Sep 2002 13:54:08 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <P4FXYD62>; Thu, 5 Sep 2002 14:03:25 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1078391FD@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Thu, 5 Sep 2002 14:03:24 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: What is left after LOCK/UNLOCK on null resource?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6564
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>


Just to avoid any misunderstanding, using the DeltaV protocol
will only allow such interoperation if we get clients and servers
to support the protocol.  Probably I should have said
"would theoretically allow" instead of "would effectively allow" (:-),
but that is one reason I encourage folks to use the DeltaV protocol
in their clients and servers if they want to provide shared long-term
locking functionality.

Cheers,
Geoff


-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@Rational.Com]

My point about using the DeltaV protocol for "long-lived locking"
(or "shared locking) applications was that using this protocol
would allow a client to effectively interoperate with a wider
variety of servers (both versioning and non-versioning), with the
"version URL" effectively replacing the functionality of the
"shared lock token". 



From w3c-dist-auth-request@w3.org  Thu Sep  5 14:21:55 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00724
	for <webdav-archive@lists.ietf.org>; Thu, 5 Sep 2002 14:21:54 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g85IM5b01916;
	Thu, 5 Sep 2002 14:22:05 -0400 (EDT)
Resent-Date: Thu, 5 Sep 2002 14:22:05 -0400 (EDT)
Resent-Message-Id: <200209051822.g85IM5b01916@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g85IM3v01896
	for <w3c-dist-auth@frink.w3.org>; Thu, 5 Sep 2002 14:22:03 -0400 (EDT)
Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA23272
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 14:22:01 -0400
Received: from inet-mail3.oracle.com (localhost [127.0.0.1])
	by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g85ILUP18080
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 11:21:30 -0700 (PDT)
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13])
	by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g85ILTR18004
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 11:21:29 -0700 (PDT)
Received: from rgmum1.us.oracle.com (rgmum1.us.oracle.com [138.1.191.22])
	by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g85ILSO01440
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 12:21:28 -0600 (MDT)
Received: from 152.68.17.155 by rgmum2.us.oracle.com
	with ESMTP id 58473571031250087; Thu, 05 Sep 2002 12:21:27 -0600
Message-ID: <003901c25507$cbf4df30$9b114498@esedlar>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: "Julian Reschke" <julian.reschke@gmx.de>, <w3c-dist-auth@w3.org>
References: <JIEGINCHMLABHJBIGKBCMEJPFEAA.julian.reschke@gmx.de>
Date: Thu, 5 Sep 2002 11:12:28 -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: Interoperability for DAV:ishidden?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6565
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>
Content-Transfer-Encoding: 7bit


> > One property that keeps coming up (also in the Microsoft proposal) is
the
> > resource-ID property, to uniquely identify a resource (generally a
GUID).
> > I'm constantly getting requests from internal groups for this,
> > and I know a
> > lot of the JSR-170 people are interested in this for content management
> > apps.
>
> As Geoff pointed out, this will be available as part of the BIND spec. It
> could be used on systems even when they don't specifically support the
BIND
> method.
>
> > Of course another related requirement is the ability to fetch resources
by
> > ID.  This could be done either by fully utilizing the DAV: namespace,
e.g.
> > DAV:<resourceID> as the URL or by waiting for DASL.
>
> First of all, the "unique resource ID" just is a URI. Which URI scheme is
> used is up to the server. So it's completely free to assign an HTTP URI,
and
> this obviously could then be used to fetch the ressource. If the
resourceId
> isn't an HTTP URI, WebDAV doesn't give you any direct mean to retrieve it.
>
> Re: locating a WebDAV ressource by resourceid -- this won't work with the
> current DASL spec (at least not with the DAV:basicsearch grammar), as I
> expect the property to have DAV:href content -- something in which you
can't
> search using DASL. Therefore, a REPORT (locate-by-resourceid) may be
> appropriate...
>

What is needed is an interoperable way, given a resource ID, to operate on a
resource with that ID on the server.  If the mapping between resource-ID and
implementation is server-defined, we can't do that.  Requiring the DAV:
namespace to respond to these requests is probably the easiest thing to do,
since this will work with other methods, like LOCK and so forth.  REPORT
doesn't handle that case.

--Eric



From w3c-dist-auth-request@w3.org  Thu Sep  5 14:35:50 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01531
	for <webdav-archive@lists.ietf.org>; Thu, 5 Sep 2002 14:35:50 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g85IWwd03980;
	Thu, 5 Sep 2002 14:32:58 -0400 (EDT)
Resent-Date: Thu, 5 Sep 2002 14:32:58 -0400 (EDT)
Resent-Message-Id: <200209051832.g85IWwd03980@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g85IWvv03960
	for <w3c-dist-auth@frink.w3.org>; Thu, 5 Sep 2002 14:32:57 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA25880
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 14:32:56 -0400
Received: (qmail 17131 invoked by uid 0); 5 Sep 2002 18:32:25 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp001-rz3) with SMTP; 5 Sep 2002 18:32:25 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Eric Sedlar" <eric.sedlar@oracle.com>,
        "Julian Reschke" <julian.reschke@gmx.de>, <w3c-dist-auth@w3.org>
Date: Thu, 5 Sep 2002 20:32:23 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCCELGFEAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <003901c25507$cbf4df30$9b114498@esedlar>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: RE: Interoperability for DAV:ishidden?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6566
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>
Content-Transfer-Encoding: 7bit


> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> Sent: Thursday, September 05, 2002 8:12 PM
> To: Julian Reschke; w3c-dist-auth@w3.org
> Subject: Re: Interoperability for DAV:ishidden?
>
> ..
>
> What is needed is an interoperable way, given a resource ID, to
> operate on a
> resource with that ID on the server.  If the mapping between
> resource-ID and
> implementation is server-defined, we can't do that.  Requiring the DAV:
> namespace to respond to these requests is probably the easiest
> thing to do,
> since this will work with other methods, like LOCK and so forth.  REPORT
> doesn't handle that case.

Eric,

WebDAV is an HTTP extension. There's simply no way to directly manipulate a
resource identified by a DAV: URI using HTTP/WebDAV. Is this *really* what
you're proposing, or am I missing something?

Julian

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



From w3c-dist-auth-request@w3.org  Thu Sep  5 14:44:36 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02098
	for <webdav-archive@lists.ietf.org>; Thu, 5 Sep 2002 14:44:36 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g85IipE06026;
	Thu, 5 Sep 2002 14:44:51 -0400 (EDT)
Resent-Date: Thu, 5 Sep 2002 14:44:51 -0400 (EDT)
Resent-Message-Id: <200209051844.g85IipE06026@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g85Iiov06006
	for <w3c-dist-auth@frink.w3.org>; Thu, 5 Sep 2002 14:44:50 -0400 (EDT)
Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA28333
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 14:44:49 -0400
Received: from inet-mail3.oracle.com (localhost [127.0.0.1])
	by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g85IiIP12580
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 11:44:19 -0700 (PDT)
Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14])
	by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g85IiIR12570
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 11:44:18 -0700 (PDT)
Received: from rgmum4.us.oracle.com (rgmum4.us.oracle.com [138.1.191.25])
	by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g85IiHr15707
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 12:44:17 -0600 (MDT)
Received: from 152.68.17.155 by rgmum2.us.oracle.com
	with ESMTP id 58491941031251456; Thu, 05 Sep 2002 12:44:16 -0600
Message-ID: <010401c2550a$fc23e540$9b114498@esedlar>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: <w3c-dist-auth@w3.org>
References: <JIEGINCHMLABHJBIGKBCCELGFEAA.julian.reschke@gmx.de>
Date: Thu, 5 Sep 2002 11:35:18 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: Re: Interoperability for DAV:ishidden?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6567
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>
Content-Transfer-Encoding: 7bit


didn't think about that problem...

What I'd like to be able to do is to have a URL-based scheme for accessing
resources by resource ID, without having to run a REPORT or SEARCH method or
something to find a URL for it, especially since that will be yet another
spec.

OK, how about if we make resource IDs <href>s that are guaranteed to be
unique?  We had to do the same thing with principals in the ACL spec to
uniquely identify them.  So, rather than treating resource ID as an opaque
string, we can do something with it.  On a server storing GUIDs for each
resource, you could return:

http://myserver/sys/ids/<GUID>

as the string rather than just

GUID

--Eric

----- Original Message -----
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Eric Sedlar" <eric.sedlar@oracle.com>; "Julian Reschke"
<julian.reschke@gmx.de>; <w3c-dist-auth@w3.org>
Sent: Thursday, September 05, 2002 11:32 AM
Subject: RE: Interoperability for DAV:ishidden?


> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> > Sent: Thursday, September 05, 2002 8:12 PM
> > To: Julian Reschke; w3c-dist-auth@w3.org
> > Subject: Re: Interoperability for DAV:ishidden?
> >
> > ..
> >
> > What is needed is an interoperable way, given a resource ID, to
> > operate on a
> > resource with that ID on the server.  If the mapping between
> > resource-ID and
> > implementation is server-defined, we can't do that.  Requiring the DAV:
> > namespace to respond to these requests is probably the easiest
> > thing to do,
> > since this will work with other methods, like LOCK and so forth.  REPORT
> > doesn't handle that case.
>
> Eric,
>
> WebDAV is an HTTP extension. There's simply no way to directly manipulate
a
> resource identified by a DAV: URI using HTTP/WebDAV. Is this *really* what
> you're proposing, or am I missing something?
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>



From w3c-dist-auth-request@w3.org  Thu Sep  5 14:58:40 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03011
	for <webdav-archive@lists.ietf.org>; Thu, 5 Sep 2002 14:58:40 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g85Iudt09368;
	Thu, 5 Sep 2002 14:56:39 -0400 (EDT)
Resent-Date: Thu, 5 Sep 2002 14:56:39 -0400 (EDT)
Resent-Message-Id: <200209051856.g85Iudt09368@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g85Iubv09344
	for <w3c-dist-auth@frink.w3.org>; Thu, 5 Sep 2002 14:56:37 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA31133
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 14:56:37 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 05 Sep 2002 14:44:18 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <P4FXY2Q8>; Thu, 5 Sep 2002 14:53:34 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1078391FE@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Thu, 5 Sep 2002 14:53:30 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Interoperability for DAV:ishidden?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6568
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>


I still don't see your objection to Julian's original proposal,
i.e. if your server can (or is willing to) allow a client to operate
directly on the resource identified by the DAV:resourceid, then it
just makes the value of DAV:resourceid be in the HTTP: namespace.

There is value in a DAV:resourceid, even if it isn't something a
client can use to directly operate on the resource, so I don't believe
it is reasonable to require that the value of DAV:resourceid be in the HTTP
namespace.

Cheers,
Geoff

-----Original Message-----
From: Eric Sedlar [mailto:eric.sedlar@oracle.com]
Sent: Thursday, September 05, 2002 2:35 PM
To: w3c-dist-auth@w3.org
Subject: Re: Interoperability for DAV:ishidden?



didn't think about that problem...

What I'd like to be able to do is to have a URL-based scheme for accessing
resources by resource ID, without having to run a REPORT or SEARCH method or
something to find a URL for it, especially since that will be yet another
spec.

OK, how about if we make resource IDs <href>s that are guaranteed to be
unique?  We had to do the same thing with principals in the ACL spec to
uniquely identify them.  So, rather than treating resource ID as an opaque
string, we can do something with it.  On a server storing GUIDs for each
resource, you could return:

http://myserver/sys/ids/<GUID>

as the string rather than just

GUID

--Eric

----- Original Message -----
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Eric Sedlar" <eric.sedlar@oracle.com>; "Julian Reschke"
<julian.reschke@gmx.de>; <w3c-dist-auth@w3.org>
Sent: Thursday, September 05, 2002 11:32 AM
Subject: RE: Interoperability for DAV:ishidden?


> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> > Sent: Thursday, September 05, 2002 8:12 PM
> > To: Julian Reschke; w3c-dist-auth@w3.org
> > Subject: Re: Interoperability for DAV:ishidden?
> >
> > ..
> >
> > What is needed is an interoperable way, given a resource ID, to
> > operate on a
> > resource with that ID on the server.  If the mapping between
> > resource-ID and
> > implementation is server-defined, we can't do that.  Requiring the DAV:
> > namespace to respond to these requests is probably the easiest
> > thing to do,
> > since this will work with other methods, like LOCK and so forth.  REPORT
> > doesn't handle that case.
>
> Eric,
>
> WebDAV is an HTTP extension. There's simply no way to directly manipulate
a
> resource identified by a DAV: URI using HTTP/WebDAV. Is this *really* what
> you're proposing, or am I missing something?
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>



From w3c-dist-auth-request@w3.org  Thu Sep  5 19:00:51 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11031
	for <webdav-archive@lists.ietf.org>; Thu, 5 Sep 2002 19:00:50 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g85MuLr23938;
	Thu, 5 Sep 2002 18:56:21 -0400 (EDT)
Resent-Date: Thu, 5 Sep 2002 18:56:21 -0400 (EDT)
Resent-Message-Id: <200209052256.g85MuLr23938@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g85MuJv23917
	for <w3c-dist-auth@frink.w3.org>; Thu, 5 Sep 2002 18:56:19 -0400 (EDT)
Received: from cats.ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA16532
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 18:56:19 -0400
Received: from Tycho (dhcp-60-118.cse.ucsc.edu [128.114.60.118])
	by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g85MtVq26456
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 15:55:31 -0700 (PDT)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: <w3c-dist-auth@w3.org>
Date: Thu, 5 Sep 2002 15:53:11 -0700
Message-ID: <AMEPKEBLDJJCCDEJHAMIOEFHFGAA.ejw@cse.ucsc.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1078391FE@SUS-MA1IT01>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
X-UCSC-CATS-MailScanner: Found to be clean
Subject: RE: Interoperability for DAV:ishidden?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6570
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>
Content-Transfer-Encoding: 7bit


I like the idea of having a URI namespace for unique identifiers for
resources. Since we use the DAV: namespace exclusively for protocol
elements, I tihnk it's a bad idea to reuse the DAV: URI space for this
purpose. But, a "guid:" URI scheme could be very useful to us, and to other
working groups too, I imagine.

Now, a "guid:" URI is just an identifier, and is not explicitly defined to
be a locator, like a URL. However, we could easily say that each DAV server
understands how to resolve a subset of the overall GUID space, and if you
somehow know one of the GUIDs a server can resolve, a GET request on that
"guid:" URI will respond with the correct state, etc.

Just to make sure we're all on the same page, I'm proposing that in addition
to the current situation where there can be multiple URLs mapped to a single
resource:

URL (n)-->(1) resource

We would additionally have a 1 to 1 mapping of guid: URI to resource:

guid: (1)-->(1) resource

- Jim

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Thursday, September 05, 2002 11:54 AM
> To: w3c-dist-auth@w3.org
> Subject: RE: Interoperability for DAV:ishidden?
>
>
>
> I still don't see your objection to Julian's original proposal,
> i.e. if your server can (or is willing to) allow a client to operate
> directly on the resource identified by the DAV:resourceid, then it
> just makes the value of DAV:resourceid be in the HTTP: namespace.
>
> There is value in a DAV:resourceid, even if it isn't something a
> client can use to directly operate on the resource, so I don't believe
> it is reasonable to require that the value of DAV:resourceid be
> in the HTTP
> namespace.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Eric Sedlar [mailto:eric.sedlar@oracle.com]
> Sent: Thursday, September 05, 2002 2:35 PM
> To: w3c-dist-auth@w3.org
> Subject: Re: Interoperability for DAV:ishidden?
>
>
>
> didn't think about that problem...
>
> What I'd like to be able to do is to have a URL-based scheme for accessing
> resources by resource ID, without having to run a REPORT or
> SEARCH method or
> something to find a URL for it, especially since that will be yet another
> spec.
>
> OK, how about if we make resource IDs <href>s that are guaranteed to be
> unique?  We had to do the same thing with principals in the ACL spec to
> uniquely identify them.  So, rather than treating resource ID as an opaque
> string, we can do something with it.  On a server storing GUIDs for each
> resource, you could return:
>
> http://myserver/sys/ids/<GUID>
>
> as the string rather than just
>
> GUID
>
> --Eric
>
> ----- Original Message -----
> From: "Julian Reschke" <julian.reschke@gmx.de>
> To: "Eric Sedlar" <eric.sedlar@oracle.com>; "Julian Reschke"
> <julian.reschke@gmx.de>; <w3c-dist-auth@w3.org>
> Sent: Thursday, September 05, 2002 11:32 AM
> Subject: RE: Interoperability for DAV:ishidden?
>
>
> > > -----Original Message-----
> > > From: w3c-dist-auth-request@w3.org
> > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> > > Sent: Thursday, September 05, 2002 8:12 PM
> > > To: Julian Reschke; w3c-dist-auth@w3.org
> > > Subject: Re: Interoperability for DAV:ishidden?
> > >
> > > ..
> > >
> > > What is needed is an interoperable way, given a resource ID, to
> > > operate on a
> > > resource with that ID on the server.  If the mapping between
> > > resource-ID and
> > > implementation is server-defined, we can't do that.
> Requiring the DAV:
> > > namespace to respond to these requests is probably the easiest
> > > thing to do,
> > > since this will work with other methods, like LOCK and so
> forth.  REPORT
> > > doesn't handle that case.
> >
> > Eric,
> >
> > WebDAV is an HTTP extension. There's simply no way to directly
> manipulate
> a
> > resource identified by a DAV: URI using HTTP/WebDAV. Is this
> *really* what
> > you're proposing, or am I missing something?
> >
> > Julian
> >
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >
> >



From w3c-dist-auth-request@w3.org  Thu Sep  5 19:10:40 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11313
	for <webdav-archive@lists.ietf.org>; Thu, 5 Sep 2002 19:10:40 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g85Mn4c22393;
	Thu, 5 Sep 2002 18:49:04 -0400 (EDT)
Resent-Date: Thu, 5 Sep 2002 18:49:04 -0400 (EDT)
Resent-Message-Id: <200209052249.g85Mn4c22393@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g85Mn2v22373
	for <w3c-dist-auth@frink.w3.org>; Thu, 5 Sep 2002 18:49:02 -0400 (EDT)
Received: from cats.ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA14678
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 18:49:02 -0400
Received: from Tycho (dhcp-60-118.cse.ucsc.edu [128.114.60.118])
	by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g85Mjvq24385
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 15:45:57 -0700 (PDT)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: <w3c-dist-auth@w3.org>
Date: Thu, 5 Sep 2002 15:43:37 -0700
Message-ID: <AMEPKEBLDJJCCDEJHAMIAEFHFGAA.ejw@cse.ucsc.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1078391FB@SUS-MA1IT01>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
X-UCSC-CATS-MailScanner: Found to be clean
Subject: RE: What is left after LOCK/UNLOCK on null resource?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6569
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>
Content-Transfer-Encoding: 7bit


> But until Dan (or someone) has published a convincing rationale
> for having multiple processes reuse the lock token for an exclusive
> lock,  I will continue to maintain that an exclusive lock token should
> only be used in an update request (PUT/PROPPATCH) by the process
> that took out the lock originally.  (Note that I do not at all
> object to another process UNLOCK'ing a lock created by another
> process).

If you're editing a document, and your machine crashes, you would like to
reboot your machine, and then restart your authoring application to continue
editing the same document. This is strictly a different operating system
process than the one that took out the lock, yet this new process should be
able to assume the existing lock.

Alternatives, such as the Office model where locks last for only two
minutes, allow the lock to timeout while the machine is being rebooted, and
hence it's possible for the lock to be grabbed by another person after it
has expired. Social conventions surrounding turn-taking in collaborative
authoring tend to make it so this doesn't actually happen, but the
possibility does exist.

It is also possible to require the new editor instance to explicitly remove
the existing lock, then take out a new one, but to do this requires the same
information you'd need to assume the existing lock, and still provides a
small window of lock-grabbing vulnerability.

> If you want to allow multiple processes to effectively "share"
> a lock token, the protocol has defined shared locks.

Shared locks don't strike me as being appropriate for this case, since you'd
have two shared locks, each owned by the same person (DAV doesn't have a way
to explicitly represent the process taking out a lock).

- Jim



From w3c-dist-auth-request@w3.org  Thu Sep  5 20:47:37 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12787
	for <webdav-archive@lists.ietf.org>; Thu, 5 Sep 2002 20:47:36 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g860de403656;
	Thu, 5 Sep 2002 20:39:40 -0400 (EDT)
Resent-Date: Thu, 5 Sep 2002 20:39:40 -0400 (EDT)
Resent-Message-Id: <200209060039.g860de403656@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g860dcv03636
	for <w3c-dist-auth@frink.w3.org>; Thu, 5 Sep 2002 20:39:38 -0400 (EDT)
Received: from smtp-relay-3.sea.adobe.com (smtp-relay-3.adobe.com [192.150.22.10])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA29305
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 20:39:37 -0400
Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51])
	by smtp-relay-3.sea.adobe.com (8.12.3/8.12.3) with ESMTP id g860c4Mh008368
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 17:38:04 -0700 (PDT)
Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192])
	by inner-relay-3.corp.adobe.com (8.12.3/8.12.3) with ESMTP id g860ZbUv019655
	for <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 17:35:37 -0700 (PDT)
Received: from c-159-46.corp.adobe.com ([130.248.188.151]) by
          mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul
          11 2001 16:32:57) with ESMTP id H1ZR5600.3WV for
          <w3c-dist-auth@w3.org>; Thu, 5 Sep 2002 17:39:06 -0700 
Date: Thu, 5 Sep 2002 16:17:12 -0700
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v543)
From: Dan Brotsky <dbrotsky@adobe.com>
To: w3c-dist-auth@w3.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1078391FB@SUS-MA1IT01>
Message-Id: <9BDEAE4C-C125-11D6-9962-0003931036B4@adobe.com>
X-Mailer: Apple Mail (2.543)
Subject: Re: What is left after LOCK/UNLOCK on null resource?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6571
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>
Content-Transfer-Encoding: 7bit


On Thursday, September 5, 2002, at 10:51 AM, Clemm, Geoff wrote:
> ... until Dan (or someone) has published a convincing rationale
> for having multiple processes reuse the lock token for an exclusive
> lock,  I will continue to maintain that an exclusive lock token should
> only be used in an update request (PUT/PROPPATCH) by the process
> that took out the lock originally.  (Note that I do not at all
> object to another process UNLOCK'ing a lock created by another
> process).
>
> If you want to allow multiple processes to effectively "share"
> a lock token, the protocol has defined shared locks.

Ah!  Thanks for adding this last piece of your position, Geoff, it 
really brought something into focus that had eluded me about your 
argument.  I will attempt (in a message under a different subject line) 
to provide the "convincing rationale" you are asking for :^).

> My point about using the DeltaV protocol for "long-lived locking"
> (or "shared locking) applications was that using this protocol
> would allow a client to effectively interoperate with a wider
> variety of servers (both versioning and non-versioning), with the
> "version URL" effectively replacing the functionality of the
> "shared lock token".

I think we agree on this, too.  I just wouldn't call this "long-lived 
locking."

     dan

>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Dan Brotsky [mailto:dbrotsky@adobe.com]
> Sent: Thursday, September 05, 2002 12:20 PM
> To: Michael Leditschke
> Cc: w3c-dist-auth@w3.org
> Subject: Re: What is left after LOCK/UNLOCK on null resource?
>
>
>
> Michael,
>
> Just for the record, I disagree with most all of Geoff's responses here
> (and in the subsequent thread), and I don't think he speaks "for the
> working group" in saying that the DAV spec favors time-limited locking.
>
> In the first place, I think client implementation (at the level, for
> example, of "process") is way outside the scope of the spec.
>
> Second, I believe that the language of the spec (as written)
> intentionally doesn't say much at all about what constitutes an
> "authoring client" (see section 6 on locking).  I think that's
> appropriate both because HTTP 1.1 is profoundly neutral about it and
> because WebDAV hopes to allow a broad range of interoperable
> implementations.
>
> Third, there is a broad class of existing, interoperable
> implementations (the Adobe Systems WebDAV-enabled products) which
> communicate tokens among processes, persist tokens between invocations
> of processes, and use LOCKDISCOVERY values (both tokens and owner
> props) as a means of interoperating on the client side about authoring
> responsibility.  These impementations work against servers which allow
> infinite-duration locks and those which don't.
>
> FWIW, I believe that lock expiration is really tied to a usage model in
> which clients actually use the server as a "remote file system," in the
> sense that they may only have a non-persistent buffer locally and all
> saves are done directly back to the server.  This is the model that
> Microsoft office clients use, for example, and they use lock timeouts
> as a way of preventing lock stranding when clients crash.
>
> The model you outlined---a local working copy is made of a locked
> resource, that local copy is edited over an indefinite period of time,
> that local copy is occasionally "published" to the server, and then the
> server resource is unlocked after all local editing is complete---is
> exactly the model used by Adobe clients.  (I have been meaning for some
> time to write an explanation of why Adobe uses this model; maybe this
> thread will finally get me to do that.  Then again, maybe not. :^)
> But, in any event, it is quite natural in this model for lock tokens to
> be persisted by the editing clients that are using the local copy,
> because in this model all the editing state (including the lock token
> and owner information) is local-disk-specific not process-specific.
>
> Finally, I'm not really sure why Geoff says that delta-V is
> specifically better suited than "plain" DAV for use by clients who use
> long-term locks.  Versioning servers are arguably a better choice than
> non-versioning servers for almost all collaborative authoring
> applications, delta-V is (of course) a DAV extension, and in fact
> delta-V specifically provides for backward compatibility around DAV
> locking for non-delta-V clients who wish to get the benefits of
> versioning.  So I really don't think lock (or checkout) duration has
> much to do with the difference between delta-V and DAV.
>
>      dan
>
> On Wednesday, September 4, 2002, at 07:28 PM, Clemm, Geoff wrote:
>
>>
>>    From: Michael Leditschke [mailto:mike@ammd.com.au]
>>
>>    DAV locks are
>>    supposed to be capable of being held for an extended time.
>>
>> Only by the process that took out the lock.
>>
>>    I might
>>    want to lock a resource, edit it for a while locally, then push the
>>    result back and unlock it again. Are you suggesting this all has
>>    to be done by the same OS process?
>>
>> Yes.
>>
>>    What happens if the power goes out and my PC reboots?
>>
>> The new process needs to obtain its own (new) lock.  The old
>> lock is cleaned up by a timeout, or if allowed by the server,
>> the new process can clean up the old lock with an UNLOCK.
>> The new process shouldn't "reuse" the old lock, unless you have
>> some way of guaranteeing that two processes cannot both reuse the
>> old lock at the same time.
>>
>>    Or perhaps you expect the client to cache locktokens?
>>
>> Only if the cache has some way of guaranteeing that only one
>> process can obtain the cached locktoken.
>>
>>    In my case, it is the same client I'm using to lock and unlock and
>>    I'm presenting the same credentials to the server. Its a low
>>    level test program, so I would have thought being able to unlock
>>    a resource of which I am the owner would be reasonable.
>>
>> Unlocking is reasonable (unlike "reusing", which is not), but some
>> servers do not trust clients to appropriately unlock something they
>> didn't lock (since the client can't automatically know that it is
>> appropriate to do so, and even if it asks the user, the user can be
>> mistaken).  Those servers require clients to depend on timeouts.
>>
>> Cheers,
>> Geoff
>>
>



From w3c-dist-auth-request@w3.org  Fri Sep  6 04:35:47 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28108
	for <webdav-archive@lists.ietf.org>; Fri, 6 Sep 2002 04:35:47 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g868a6a16399;
	Fri, 6 Sep 2002 04:36:06 -0400 (EDT)
Resent-Date: Fri, 6 Sep 2002 04:36:06 -0400 (EDT)
Resent-Message-Id: <200209060836.g868a6a16399@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g868a4v16375
	for <w3c-dist-auth@frink.w3.org>; Fri, 6 Sep 2002 04:36:05 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA00542
	for <w3c-dist-auth@w3.org>; Fri, 6 Sep 2002 04:36:04 -0400
Received: (qmail 26578 invoked by uid 0); 6 Sep 2002 08:35:33 -0000
Received: from p3ee2480e.dip.t-dialin.net (HELO lisa) (62.226.72.14)
  by mail.gmx.net (mp012-rz3) with SMTP; 6 Sep 2002 08:35:33 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Jim Whitehead" <ejw@cse.ucsc.edu>, <w3c-dist-auth@w3.org>
Date: Fri, 6 Sep 2002 10:35:31 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCCEMGFEAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <AMEPKEBLDJJCCDEJHAMIOEFHFGAA.ejw@cse.ucsc.edu>
Subject: RE: Interoperability for DAV:ishidden?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6572
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>
Content-Transfer-Encoding: 7bit


> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead
> Sent: Friday, September 06, 2002 12:53 AM
> To: w3c-dist-auth@w3.org
> Subject: RE: Interoperability for DAV:ishidden?
>
>
>
> I like the idea of having a URI namespace for unique identifiers for
> resources. Since we use the DAV: namespace exclusively for protocol

Well, that's a property of *all* URIs :-)

> elements, I tihnk it's a bad idea to reuse the DAV: URI space for this
> purpose. But, a "guid:" URI scheme could be very useful to us,
> and to other
> working groups too, I imagine.

Yes.

I think a UUID based URI scheme is what we need, and we should NOT define
this in a WebDAV RFC (like it happened for "opaquelocktoken:"). Instead, a
separate RFC should be authored, finally defining the URN "uuid" namespace.

Note that "urn:uuid:..:" is already in use by published software, yet the
URN namespace has *not* been registered (see http://uri.net).

> Now, a "guid:" URI is just an identifier, and is not explicitly defined to
> be a locator, like a URL. However, we could easily say that each
> DAV server
> understands how to resolve a subset of the overall GUID space, and if you
> somehow know one of the GUIDs a server can resolve, a GET request on that
> "guid:" URI will respond with the correct state, etc.

I don't understand that. How do you apply an HTTP method to a non HTTP-URL?

> Just to make sure we're all on the same page, I'm proposing that
> in addition
> to the current situation where there can be multiple URLs mapped
> to a single
> resource:
>
> URL (n)-->(1) resource
>
> We would additionally have a 1 to 1 mapping of guid: URI to resource:
>
> guid: (1)-->(1) resource

I'm not sure what this is good for. The binding draft requires a unique URI
for each resource that will never change and will never be assigned again.
IMHO,

- servers should be completely free in choosing a URI scheme for that URI,
as long as it has the desired properties

- in particular (like Geoff said), a server can choose to generate URIs with
these properties inside it's own URL namespace, in which case HTTP methods
can be applied to that URI -- but I don't think it makes sense to *require*
this

If we really need a reverse-lookup (from resource id to valid HTTP URL), I'd
make that a REPORT.

Julian

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



From w3c-dist-auth-request@w3.org  Fri Sep  6 16:22:30 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20330
	for <webdav-archive@lists.ietf.org>; Fri, 6 Sep 2002 16:22:30 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g86KLTr28268;
	Fri, 6 Sep 2002 16:21:29 -0400 (EDT)
Resent-Date: Fri, 6 Sep 2002 16:21:29 -0400 (EDT)
Resent-Message-Id: <200209062021.g86KLTr28268@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g86KLSv28248
	for <w3c-dist-auth@frink.w3.org>; Fri, 6 Sep 2002 16:21:28 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA08872
	for <w3c-dist-auth@w3.org>; Fri, 6 Sep 2002 16:21:28 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 06 Sep 2002 16:11:38 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <P4FX522Z>; Fri, 6 Sep 2002 16:20:58 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10783920A@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Fri, 6 Sep 2002 16:20:57 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: What is left after LOCK/UNLOCK on null resource?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6573
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>


   From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]

   > ... an exclusive lock token should
   > only be used in an update request (PUT/PROPPATCH) by the process
   > that took out the lock originally.  (Note that I do not at all
   > object to another process UNLOCK'ing a lock created by another
   > process).

   If you're editing a document, and your machine crashes, you would
   like to reboot your machine, and then restart your authoring
   application to continue editing the same document.

Agreed.

   This is strictly a different operating system process than the one
   that took out the lock, yet this new process should be able to
   assume the existing lock.

That is the premise you need to prove, not a statement you can assume
to be true.  In particular, since you cannot in general know whether
or not the original process is gone or simply inactive (even if the user
believes it has), a client cannot safely "assume" the existing lock.

   Alternatives, such as the Office model where locks last for only two
   minutes, allow the lock to timeout while the machine is being rebooted,
and
   hence it's possible for the lock to be grabbed by another person after it
   has expired.

The result of you "losing" the lock are far less serious than the
results of having two processes use the same lock (which is the risk
you take by "assuming" an existing lock).  If someone else has taken
out a lock (not all that likely in the first place), you immediately
know what has happened, and can negotiate with the other lock holder
if your authoring need is more urgent.  Or you might simply cancel
their lock with an unlock, and take out a new lock of your own if you
need to preempt their lock, and they will know this has happened on
their next attempt to update (their lock token will no longer be
valid).

   Social conventions surrounding turn-taking in collaborative
   authoring tend to make it so this doesn't actually happen, but the
   possibility does exist.

It doesn't make sense to introduce a serious problem (multiple
processes using the same lock token, causing overwrites to occur) to
handle an unlikely event, especially when there are safer ways to deal
with the problem (described above).

   It is also possible to require the new editor instance to
   explicitly remove the existing lock, then take out a new one, but
   to do this requires the same information you'd need to assume the
   existing lock, and still provides a small window of lock-grabbing
   vulnerability.

But it prevents overwrite problem, which is the whole point
of locking.  Why would you want to introduce a serious flaw in
the protocol (i.e. risk of overwrite), in order to avoid a
low-likelihood event that has a safe alternative solution?

   > If you want to allow multiple processes to effectively "share"
   > a lock token, the protocol has defined shared locks.

   Shared locks don't strike me as being appropriate for this case,
   since you'd have two shared locks, each owned by the same person
   (DAV doesn't have a way to explicitly represent the process taking
   out a lock).

I agree that shared locks aren't an appropriate way to get an
exclusive lock, but "assuming" an existing exclusive lock is even
worse, since at least a shared lock makes it clear that you are not
expecting the protocol to protect you against overwrites, while
a client should be able to ignore overwrite issues while they
hold and use an exclusive lock token.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Fri Sep  6 17:57:58 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22953
	for <webdav-archive@lists.ietf.org>; Fri, 6 Sep 2002 17:57:58 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g86Lujl05990;
	Fri, 6 Sep 2002 17:56:45 -0400 (EDT)
Resent-Date: Fri, 6 Sep 2002 17:56:45 -0400 (EDT)
Resent-Message-Id: <200209062156.g86Lujl05990@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g86Luhv05966
	for <w3c-dist-auth@frink.w3.org>; Fri, 6 Sep 2002 17:56:43 -0400 (EDT)
Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA24336
	for <w3c-dist-auth@w3.org>; Fri, 6 Sep 2002 17:56:43 -0400
Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Fri, 06 Sep 2002 17:56:11 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.182]) by atl1simr002.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Fri, 6 Sep 2002 17:56:10 -0400
Received: from xythoslap ([198.144.203.248]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Fri, 6 Sep 2002 17:56:10 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Clemm, Geoff'" <gclemm@rational.com>, <w3c-dist-auth@w3.org>
Date: Fri, 6 Sep 2002 14:56:08 -0700
Message-ID: <000e01c255f0$361a4b00$29c4fea9@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10783920A@SUS-MA1IT01>
Importance: Normal
X-OriginalArrivalTime: 06 Sep 2002 21:56:10.0388 (UTC) FILETIME=[35DB6D40:01C255F0]
Subject: RE: What is left after LOCK/UNLOCK on null resource?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6574
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>
Content-Transfer-Encoding: 7bit


> The result of you "losing" the lock are far less serious than the
> results of having two processes use the same lock (which is the risk
> you take by "assuming" an existing lock).  If someone else has taken
> out a lock (not all that likely in the first place), you immediately
> know what has happened, and can negotiate with the other lock holder
> if your authoring need is more urgent.  Or you might simply cancel
> their lock with an unlock, and take out a new lock of your own if you
> need to preempt their lock, and they will know this has happened on
> their next attempt to update (their lock token will no longer be
> valid).

Geoff's right. If two processes are using the same lock, both must be
aware of this, and they need *another* way of communicating which is
expected to change the resource when.  Otherwise, the "lost update"
problem isn't solved at all, you've found a work-around for the
solution!

Note that whether or not a lock is used by a single process, shared
among cooperating processes, or lost during a reboot or other timeout,
ETags STRONGLY SHOULD be used to check if the resource is unchanged.
Note what the ETag is whenever a GET is used, and cache that
(persistently, so that even if the computer crashes and the lock is
lost, the ETag should still be available).  Then when doing a PUT, use
the If-Match header to make sure that the ETag is still the same. 

So:
 - most of the time you shouldn't be losing locks accidentally;
 - most of the time when you do lose a lock accidentally you can check
the ETag to make sure that you can relock without having to consult the
user;

 - In the rare cases when you do lose a lock and the ETag has changed,
user intervention is required to make sure that content is not being
overwritten;
 - In the rare case when you do lose a lock and the resource has now
been locked by somebody else, it's necessary to tell the user their file
is not available for writing. 

Lisa



From w3c-dist-auth-request@w3.org  Sun Sep  8 23:38:44 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14636
	for <webdav-archive@lists.ietf.org>; Sun, 8 Sep 2002 23:38:43 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g890bnO24157;
	Sun, 8 Sep 2002 20:37:49 -0400 (EDT)
Resent-Date: Sun, 8 Sep 2002 20:37:49 -0400 (EDT)
Resent-Message-Id: <200209090037.g890bnO24157@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g890bdv23687
	for <w3c-dist-auth@frink.w3.org>; Sun, 8 Sep 2002 20:37:39 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA16177
	for <w3c-dist-auth@w3.org>; Sun, 8 Sep 2002 08:27:51 -0400
Received: from lisa [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3.org>; Sun, 08 Sep 2002 14:27:35 +0200
From: "Julian Reschke" <julian.reschke@greenbytes.de>
To: <w3c-dist-auth@w3.org>
Date: Sun, 8 Sep 2002 14:27:27 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCCEOEFEAA.julian.reschke@greenbytes.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-MDRemoteIP: 192.168.1.23
X-Return-Path: julian.reschke@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3.org
Subject: WebDAV WG meeting -- current status of greenbytes activities
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6575
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>
Content-Transfer-Encoding: 7bit


Hi,

again apologies for us not attending the meeting. However, I'd like to
contribute to the upcoming WG meetings by summarizing the status of our
various WebDAV related activities.


1) Internet Draft "Datatypes for WebDAV properties" [1]

Initially, this only covered marshalling of type information for WebDAV
properties. It builds on the datatype part of XML schema (not the structure
part), and is compatible to what other XML vocabularies do (for instance,
SOAP). It's also very similar to the type system in Microsoft IIS, Exhange
and Sharepoint -- the main difference being that it's based on W3C
recommendations.

This part of the draft has been stable since almost a year, and support has
been present in shipping SAP Enterpise Portal servers for several months
now.

Recently, we have started to extend the draft to marshall information that
should make it possible for generic clients to treat a resource's properties
in a more meaningful way. It includes

- flags ("hidden" and "protected") -- this is already in the draft, and
- display names (language dependant).

We attempt to come up with a common proposal with Eric Sedlar (Oracle). At
this point, we're also interested in feedback from authors of generic
clients, such as TeamStream, WebDrive, kCura, Adobe and (yes) Microsoft.


2) Internet Draft "Computing the CHECKIN URI in WebDAV versioning" [2]

This has been stable for several months now and is implemented in shipping
SAP Enterprise Portal servers. From the abstract:

"In many cases, a versioning-aware client might want to display/include the
URI of the version it's editing while it's being edited. For instance, an
editor might include this as meta information, or the author of a document
might want to know the URI of the version before it's checked in. A
well-known example is the W3C way of referring to document versions in
recommendations: it contains references to "the current version", to "this
version" and to the "previous version". Something like this is currently
impossible with WebDAV versioning [RFC3253], as the version URI is
determined at the time of CHECKIN."

We will probably submit it for publication as Informational RFC soon, unless
other WG members file like participating in this activity.


3) Internet Draft "Including additional properties in WebDAV
PROPFIND/allprop requests" [3]

Again, this has been stable for several months now and is implemented in
shipping SAP Enterprise Portal servers. From the abstract:

"Recent specifications extending the Web Distributed Authoring Protocol
(WebDAV) restrict the set of properties returned automatically upon a
PROPFIND/allprop request. This specification defines a method to add
specific properties to the set of properties returned upon
PROPFIND/allprop."

The current draft has been submitted to the RFC editor for publication as
Informational RFC two weeks ago.


4) WebDAV SEARCH [4]

This draft is very slowly progressing and is fully supported in the current
SAP Enterprise Portal version. The main open issues are:

- whether or not the section describing the SEARCH method in general should
be rewritten to specify RFC3253-like error response marshalling (needs
editorial time and commitment from current implementors to change/upgrade
implementations) and

- cleanup of DAV:basicsearch, mainly to properly define valid lexical value
spaces, and how datatypes relate to the various operators (such as: string
collations and so on)


5) WebDAV Ordered Collections Protocol [5]

We feel that this protocol is stable, and we have volunteered in March to
resubmit it after clean up. We still plan to reformat the draft to use
RFC3253-based error marshalling.


6) WebDAV Bindings [6]

We are very interested in this draft and have the necessary code in place to
support the protocol. In fact, our test server implementation (see
"Always-On Interop Server" mailings) supports the DAV:resourceid property.
It probably would be good if there would be a generally accepted URI scheme
in place -- I propose to work with Michael Mealling (Verisign) to get the
features we need (basically the same as in in the RFC2518 "opaquelocktoken"
scheme) into the UUID URN namespace.


7) WebDAV Redirect Reference Resources [7]

We have implemented this draft, and are *very* interested in getting better
client support for it.  At a minimum, clients should be able to correctly
process a server's 302 response (for instance, the basic MS webfolder client
doesn't on PROPFIND, but the newer versions shipping with Sharepoint and
Office XP do).


8) Other Stuff

- We support the plan of adding DAV:ishidden into RFC2518bis -- a conforming
server wouldn't need to do more than persist it as dead property. Conforming
clients would just treat a value of "1" as signal not to display a resource
in it's UI.

- We support extending DAV:activelock to optionally provide the root of a
deep lock, as described in [2]. If there's interest, we may be able to
enable support for it on our public test server before the end of the
interop event.

- I think we need to clarify the relationship between WebDAV and HTTP
variant handling. This should go into a separate document.

- We should consider the relation of the various new WebDAV methods/HTTP
headers to RFC2774 (HTTP Extension Framework). Should we use that framework
in future work?


Julian

[1]
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-datatypes-la
test.html>
[2]
<http://greenbytes.de/tech/webdav/draft-reschke-deltav-compute-checkin-uri-l
atest.html>
[3]
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-allprop-include-lates
t.html>
[4]
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html>
[5]
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-latest
.html>
[6]
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-binding-protocol-02.html
>
[7] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0049.html>
[8] <ftp://ftp.isi.edu/in-notes/rfc2774.txt>

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




From w3c-dist-auth-request@w3.org  Mon Sep  9 10:19:29 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03085
	for <webdav-archive@lists.ietf.org>; Mon, 9 Sep 2002 10:19:28 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g89E6P229165;
	Mon, 9 Sep 2002 10:06:25 -0400 (EDT)
Resent-Date: Mon, 9 Sep 2002 10:06:25 -0400 (EDT)
Resent-Message-Id: <200209091406.g89E6P229165@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g89E6NU29145
	for <w3c-dist-auth@frink.w3.org>; Mon, 9 Sep 2002 10:06:23 -0400 (EDT)
Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA22090
	for <w3c-dist-auth@w3.org>; Mon, 9 Sep 2002 10:06:23 -0400
Received: from daehub01.software-ag.de by server8a.software-ag.de; (8.11.6/8.9.3)
	id g89E6JA19581; Mon, 9 Sep 2002 16:06:19 +0200
Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2650.21)
	id <SSA8J93G>; Mon, 9 Sep 2002 16:06:19 +0200
Message-ID: <DFF2AC9E3583D511A21F0008C7E62106031F2B35@daemsg02.software-ag.de>
From: "Pill, Juergen" <Juergen.Pill@softwareag.com>
To: "'Babich, Alan'" <ABabich@filenet.com>, w3c-dist-auth@w3.org
Date: Mon, 9 Sep 2002 16:06:16 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6576
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>


Hello Alan,

You put it to the point.

From the protocol point of view, there may be only minor needs to have TA
functions. A user issues a request, gets an answer and the server is clean
again. This is a (server wise) very lean approach.

From an API layer, there are many scenarios an application wants to block
some commands within a TA. Unfortunately an API can not simulate TA behavior
without help (TA support) from the server. This was the intention of the
mail. Batch operations would not help an API, if the API wants to perform
different operations depending on the succors response code or body.

Having TA spreading several servers is far more complicated (here a 2 phase
commit protocol would be needed), this was not intended by the current TA
approach. I think this is something, as you pointed out, for  "someday".

The TA approach would be an extension, some servers would support it (they
have to deal with TA state) some would not. If a client does not request
Tas, or a server does not support TA, the behavior and performance would be
identical to today's situation. If a client/API would require and request
TAs, the server has to deal with more (space and logic) overheads.

Best regards,

Juergen


 -----Original Message-----
From: 	Babich, Alan [mailto:ABabich@filenet.com] 
Sent:	Monday, September 02, 2002 22.59 PM
To:	'B. Shadgar'; Pill, Juergen; w3c-dist-auth@w3.org
Subject:	RE: Proposal: WebDAV and transactions

One thing you do NOT want under any circumstances are 
begin-transaction, end-transaction, and abort-transaction 
methods. That approach simply does not scale beyond a single
user, and is a performance disaster.

You absolutely need to stick to single method calls that can 
Perform Multiple operations on the server in a single 
Transaction. Batching up operations is a valid approach.

Transactions aren't that easy to deal with. That becomes
Even more true when multiple servers are involved. Someday,
WebDAV might get that far.

Transactions aren't new. They're decades old. The effort would
Profit from the decades of thought that has gone before.
For example, see the DMA standard for one approach. (But
remember: DMA specifies an API, not a protocol, and WebDAV is a 
protocol.)

Dr. Alan F. Babich



From w3c-dist-auth-request@w3.org  Mon Sep  9 10:24:48 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03380
	for <webdav-archive@lists.ietf.org>; Mon, 9 Sep 2002 10:24:48 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g89EHOe00398;
	Mon, 9 Sep 2002 10:17:24 -0400 (EDT)
Resent-Date: Mon, 9 Sep 2002 10:17:24 -0400 (EDT)
Resent-Message-Id: <200209091417.g89EHOe00398@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g89EHNU00378
	for <w3c-dist-auth@frink.w3.org>; Mon, 9 Sep 2002 10:17:23 -0400 (EDT)
Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA25594
	for <w3c-dist-auth@w3.org>; Mon, 9 Sep 2002 10:17:22 -0400
Received: from daehub01.software-ag.de by server8a.software-ag.de; (8.11.6/8.9.3)
	id g89EHLA20700; Mon, 9 Sep 2002 16:17:21 +0200
Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2650.21)
	id <SSA8J943>; Mon, 9 Sep 2002 16:17:20 +0200
Message-ID: <DFF2AC9E3583D511A21F0008C7E62106031F2B36@daemsg02.software-ag.de>
From: "Pill, Juergen" <Juergen.Pill@softwareag.com>
To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
Date: Mon, 9 Sep 2002 16:17:19 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6577
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>


Hello,

I did not receive a lot of feed-back on the TA "proposal" (and the
statements were both positive and negative).

Would you agree on the statement, the WebDAV group would be currently not
interested in standardizing TA methods?

As we would need this extension for the API implementation, our option would
be to implement a proprietary WebDAV TA extension available on our server
only.

If the interest on this topic would raise again - possibly at a later time -
we would be happy to share our experience with you.

Best regards,

Juergen Pill



 -----Original Message-----
From: 	Pill, Juergen [mailto:Juergen.Pill@softwareag.com] 
Sent:	Monday, September 02, 2002 12.24 PM
To:	'w3c-dist-auth@w3.org'
Subject:	Proposal: WebDAV and transactions


Hello,

The current WebDAV specifications deal with a transactional support on a
method base only. Either a single WebDAV method is completely and
successfully executed, or the method is not executed at all (e.g. a
PropPatch command will either modify all requested properties or none of
them). A transactional support spanning multiple WebDAV methods is currently
not specified.
Multi user requirements are either handled in separate workspaces (Delta-V)
or via the Lock method.
During our discussion on the JSR 170 (Content Management API) implementation
on top of WebDAV, we believe that we require longer transactions spanning
multiple separate WebDAV methods. (This issue was already partially
discussed in the Batch method thread). Do you also fell the need/requirement
to get a standard on the way, concerning a transactional WebDAV protocol
extension?

A possible use case would be:
An author wants to modify an html page. To successfully do so, he will PUT
the updated html page back, PROPPATCH and UNLOCK it, DELETE all bitmap
files, which are not references any more, and PUT (create) the newly
referenced bitmaps files. If he wants to ensure, that either all his changes
do apply (or none of them) he would surround those method call with an
TA-BEGIN and a TA-COMMIT method call. If the author would be an API (e.g.
JSR 170) exposing the TA functionality to an application, we believe this
feature to be mandatory.

A possible (starting) specification could be:
WebDAV defines 3 additional methods: TA-BEGIN, TA-COMMIT and TA-ABORT. The
TA-BEGIN method will return a TA token (e.g. via an XML response body). This
TA token will be send to the following WebDAV methods, which are part of
this transaction (e.g. via an additional header). The TA-COMMIT or TA-ABORT
method will either commit or abort the transaction and invalidate the TA
token. 
If and when an open TA, which is not used any more, is aborted, could be
controlled similar to the lock method timeout header.
All WebDAV methods, which either do not posses a TA token, or posses an
invalid token are handled as today (the method is executed within its own
TA), this would ensure upward compatibility.
This extension would be optional, if a server supports the TA methods, it
will state this in the OPTIONS request (similar to Delta-V).


Does this make sense?

Best regards
Juergen Pill



From w3c-dist-auth-request@w3.org  Mon Sep  9 10:41:28 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04105
	for <webdav-archive@lists.ietf.org>; Mon, 9 Sep 2002 10:41:28 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g89EYEE01580;
	Mon, 9 Sep 2002 10:34:14 -0400 (EDT)
Resent-Date: Mon, 9 Sep 2002 10:34:14 -0400 (EDT)
Resent-Message-Id: <200209091434.g89EYEE01580@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g89EYDU01556
	for <w3c-dist-auth@frink.w3.org>; Mon, 9 Sep 2002 10:34:13 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA31619
	for <w3c-dist-auth@w3.org>; Mon, 9 Sep 2002 10:34:12 -0400
Received: (qmail 6187 invoked by uid 0); 9 Sep 2002 14:33:41 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp002-rz3) with SMTP; 9 Sep 2002 14:33:41 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Pill, Juergen" <Juergen.Pill@softwareag.com>, <w3c-dist-auth@w3.org>
Date: Mon, 9 Sep 2002 16:33:38 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCOEPEFEAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <DFF2AC9E3583D511A21F0008C7E62106031F2B36@daemsg02.software-ag.de>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6578
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>
Content-Transfer-Encoding: 8bit


Jürgen,

I think the main issue isn't that people aren't interested -- it's more that
they (well, I) think that it's an extremely bad idea that doesn't adher to
the HTTP model.

In particular, it would make the meaning of an HTTP method invocation depend
on previous method calls. That makes it hard or impossible for
intermediaries to work with these messages.

Julian

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Pill, Juergen
> Sent: Monday, September 09, 2002 4:17 PM
> To: 'w3c-dist-auth@w3.org'
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> Hello,
>
> I did not receive a lot of feed-back on the TA "proposal" (and the
> statements were both positive and negative).
>
> Would you agree on the statement, the WebDAV group would be currently not
> interested in standardizing TA methods?
>
> As we would need this extension for the API implementation, our
> option would
> be to implement a proprietary WebDAV TA extension available on our server
> only.
>
> If the interest on this topic would raise again - possibly at a
> later time -
> we would be happy to share our experience with you.
>
> Best regards,
>
> Juergen Pill
>
>
>
>  -----Original Message-----
> From: 	Pill, Juergen [mailto:Juergen.Pill@softwareag.com]
> Sent:	Monday, September 02, 2002 12.24 PM
> To:	'w3c-dist-auth@w3.org'
> Subject:	Proposal: WebDAV and transactions
>
>
> Hello,
>
> The current WebDAV specifications deal with a transactional support on a
> method base only. Either a single WebDAV method is completely and
> successfully executed, or the method is not executed at all (e.g. a
> PropPatch command will either modify all requested properties or none of
> them). A transactional support spanning multiple WebDAV methods
> is currently
> not specified.
> Multi user requirements are either handled in separate workspaces
> (Delta-V)
> or via the Lock method.
> During our discussion on the JSR 170 (Content Management API)
> implementation
> on top of WebDAV, we believe that we require longer transactions spanning
> multiple separate WebDAV methods. (This issue was already partially
> discussed in the Batch method thread). Do you also fell the
> need/requirement
> to get a standard on the way, concerning a transactional WebDAV protocol
> extension?
>
> A possible use case would be:
> An author wants to modify an html page. To successfully do so, he will PUT
> the updated html page back, PROPPATCH and UNLOCK it, DELETE all bitmap
> files, which are not references any more, and PUT (create) the newly
> referenced bitmaps files. If he wants to ensure, that either all
> his changes
> do apply (or none of them) he would surround those method call with an
> TA-BEGIN and a TA-COMMIT method call. If the author would be an API (e.g.
> JSR 170) exposing the TA functionality to an application, we believe this
> feature to be mandatory.
>
> A possible (starting) specification could be:
> WebDAV defines 3 additional methods: TA-BEGIN, TA-COMMIT and TA-ABORT. The
> TA-BEGIN method will return a TA token (e.g. via an XML response
> body). This
> TA token will be send to the following WebDAV methods, which are part of
> this transaction (e.g. via an additional header). The TA-COMMIT
> or TA-ABORT
> method will either commit or abort the transaction and invalidate the TA
> token.
> If and when an open TA, which is not used any more, is aborted, could be
> controlled similar to the lock method timeout header.
> All WebDAV methods, which either do not posses a TA token, or posses an
> invalid token are handled as today (the method is executed within its own
> TA), this would ensure upward compatibility.
> This extension would be optional, if a server supports the TA methods, it
> will state this in the OPTIONS request (similar to Delta-V).
>
>
> Does this make sense?
>
> Best regards
> Juergen Pill
>



From w3c-dist-auth-request@w3.org  Mon Sep  9 10:55:39 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04864
	for <webdav-archive@lists.ietf.org>; Mon, 9 Sep 2002 10:55:39 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g89ErjI03962;
	Mon, 9 Sep 2002 10:53:45 -0400 (EDT)
Resent-Date: Mon, 9 Sep 2002 10:53:45 -0400 (EDT)
Resent-Message-Id: <200209091453.g89ErjI03962@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g89EriU03940
	for <w3c-dist-auth@frink.w3.org>; Mon, 9 Sep 2002 10:53:44 -0400 (EDT)
Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA06256
	for <w3c-dist-auth@w3.org>; Mon, 9 Sep 2002 10:53:44 -0400
Received: from daehub01.software-ag.de by server8a.software-ag.de; (8.11.6/8.9.3)
	id g89ErfA24186; Mon, 9 Sep 2002 16:53:41 +0200
Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2650.21)
	id <SSA8J02M>; Mon, 9 Sep 2002 16:53:41 +0200
Message-ID: <DFF2AC9E3583D511A21F0008C7E62106031F2B3A@daemsg02.software-ag.de>
From: "Pill, Juergen" <Juergen.Pill@softwareag.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>,
        "Pill, Juergen"
	 <Juergen.Pill@softwareag.com>, w3c-dist-auth@w3.org
Date: Mon, 9 Sep 2002 16:53:39 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g89EriU03940
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6579
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>
Content-Transfer-Encoding: 8bit


Hello Julian,

I agree, TA adds a new aspect and quality to http (or WebDAV) and a new
useful functionality, IMO. If it would go beyond the scope or philosophy of
Http (or webdav) there is no need to get a standard on the way.

The only issue I could see, is - if many people feel the requirement for
this functionality too - that we get a series of WebDAV TA implementations,
which are not interoperable any more.

Best regards,

Juergen




 -----Original Message-----
From: 	Julian Reschke [mailto:julian.reschke@gmx.de] 
Sent:	Monday, September 09, 2002 16.34 PM
To:	Pill, Juergen; w3c-dist-auth@w3.org
Subject:	RE: Proposal: WebDAV and transactions

Jürgen,

I think the main issue isn't that people aren't interested -- it's more that
they (well, I) think that it's an extremely bad idea that doesn't adher to
the HTTP model.

In particular, it would make the meaning of an HTTP method invocation depend
on previous method calls. That makes it hard or impossible for
intermediaries to work with these messages.

Julian

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Pill, Juergen
> Sent: Monday, September 09, 2002 4:17 PM
> To: 'w3c-dist-auth@w3.org'
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> Hello,
>
> I did not receive a lot of feed-back on the TA "proposal" (and the
> statements were both positive and negative).
>
> Would you agree on the statement, the WebDAV group would be currently not
> interested in standardizing TA methods?
>
> As we would need this extension for the API implementation, our
> option would
> be to implement a proprietary WebDAV TA extension available on our server
> only.
>
> If the interest on this topic would raise again - possibly at a
> later time -
> we would be happy to share our experience with you.
>
> Best regards,
>
> Juergen Pill
>
>
>
>  -----Original Message-----
> From: 	Pill, Juergen [mailto:Juergen.Pill@softwareag.com]
> Sent:	Monday, September 02, 2002 12.24 PM
> To:	'w3c-dist-auth@w3.org'
> Subject:	Proposal: WebDAV and transactions
>
>
> Hello,
>
> The current WebDAV specifications deal with a transactional support on a
> method base only. Either a single WebDAV method is completely and
> successfully executed, or the method is not executed at all (e.g. a
> PropPatch command will either modify all requested properties or none of
> them). A transactional support spanning multiple WebDAV methods
> is currently
> not specified.
> Multi user requirements are either handled in separate workspaces
> (Delta-V)
> or via the Lock method.
> During our discussion on the JSR 170 (Content Management API)
> implementation
> on top of WebDAV, we believe that we require longer transactions spanning
> multiple separate WebDAV methods. (This issue was already partially
> discussed in the Batch method thread). Do you also fell the
> need/requirement
> to get a standard on the way, concerning a transactional WebDAV protocol
> extension?
>
> A possible use case would be:
> An author wants to modify an html page. To successfully do so, he will PUT
> the updated html page back, PROPPATCH and UNLOCK it, DELETE all bitmap
> files, which are not references any more, and PUT (create) the newly
> referenced bitmaps files. If he wants to ensure, that either all
> his changes
> do apply (or none of them) he would surround those method call with an
> TA-BEGIN and a TA-COMMIT method call. If the author would be an API (e.g.
> JSR 170) exposing the TA functionality to an application, we believe this
> feature to be mandatory.
>
> A possible (starting) specification could be:
> WebDAV defines 3 additional methods: TA-BEGIN, TA-COMMIT and TA-ABORT. The
> TA-BEGIN method will return a TA token (e.g. via an XML response
> body). This
> TA token will be send to the following WebDAV methods, which are part of
> this transaction (e.g. via an additional header). The TA-COMMIT
> or TA-ABORT
> method will either commit or abort the transaction and invalidate the TA
> token.
> If and when an open TA, which is not used any more, is aborted, could be
> controlled similar to the lock method timeout header.
> All WebDAV methods, which either do not posses a TA token, or posses an
> invalid token are handled as today (the method is executed within its own
> TA), this would ensure upward compatibility.
> This extension would be optional, if a server supports the TA methods, it
> will state this in the OPTIONS request (similar to Delta-V).
>
>
> Does this make sense?
>
> Best regards
> Juergen Pill
>



From w3c-dist-auth-request@w3.org  Mon Sep  9 11:05:45 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06243
	for <webdav-archive@lists.ietf.org>; Mon, 9 Sep 2002 11:05:45 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g89F61s04816;
	Mon, 9 Sep 2002 11:06:01 -0400 (EDT)
Resent-Date: Mon, 9 Sep 2002 11:06:01 -0400 (EDT)
Resent-Message-Id: <200209091506.g89F61s04816@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g89F60U04796
	for <w3c-dist-auth@frink.w3.org>; Mon, 9 Sep 2002 11:06:00 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA10171
	for <w3c-dist-auth@w3.org>; Mon, 9 Sep 2002 11:05:59 -0400
Received: (qmail 8883 invoked by uid 0); 9 Sep 2002 15:05:25 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp003-rz3) with SMTP; 9 Sep 2002 15:05:25 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Pill, Juergen" <Juergen.Pill@softwareag.com>,
        "'Julian Reschke'" <julian.reschke@gmx.de>, <w3c-dist-auth@w3.org>
Date: Mon, 9 Sep 2002 17:05:24 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCGEPGFEAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <DFF2AC9E3583D511A21F0008C7E62106031F2B3A@daemsg02.software-ag.de>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6580
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>
Content-Transfer-Encoding: 8bit


Jürgen,

I think one should try to achieve the same goal while staying inside the
boundaries of HTTP.

For instance, one could define a specific "transaction resource", and use
POST to append specific method invocations to it. You might also want to
present your use case on the REST-discuss mailing list...

Julian

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Pill, Juergen
> Sent: Monday, September 09, 2002 4:54 PM
> To: 'Julian Reschke'; Pill, Juergen; w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> Hello Julian,
>
> I agree, TA adds a new aspect and quality to http (or WebDAV) and a new
> useful functionality, IMO. If it would go beyond the scope or
> philosophy of
> Http (or webdav) there is no need to get a standard on the way.
>
> The only issue I could see, is - if many people feel the requirement for
> this functionality too - that we get a series of WebDAV TA
> implementations,
> which are not interoperable any more.
>
> Best regards,
>
> Juergen
>
>
>
>
>  -----Original Message-----
> From: 	Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent:	Monday, September 09, 2002 16.34 PM
> To:	Pill, Juergen; w3c-dist-auth@w3.org
> Subject:	RE: Proposal: WebDAV and transactions
>
> Jürgen,
>
> I think the main issue isn't that people aren't interested --
> it's more that
> they (well, I) think that it's an extremely bad idea that doesn't adher to
> the HTTP model.
>
> In particular, it would make the meaning of an HTTP method
> invocation depend
> on previous method calls. That makes it hard or impossible for
> intermediaries to work with these messages.
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Pill, Juergen
> > Sent: Monday, September 09, 2002 4:17 PM
> > To: 'w3c-dist-auth@w3.org'
> > Subject: RE: Proposal: WebDAV and transactions
> >
> >
> >
> > Hello,
> >
> > I did not receive a lot of feed-back on the TA "proposal" (and the
> > statements were both positive and negative).
> >
> > Would you agree on the statement, the WebDAV group would be
> currently not
> > interested in standardizing TA methods?
> >
> > As we would need this extension for the API implementation, our
> > option would
> > be to implement a proprietary WebDAV TA extension available on
> our server
> > only.
> >
> > If the interest on this topic would raise again - possibly at a
> > later time -
> > we would be happy to share our experience with you.
> >
> > Best regards,
> >
> > Juergen Pill
> >
> >
> >
> >  -----Original Message-----
> > From: 	Pill, Juergen [mailto:Juergen.Pill@softwareag.com]
> > Sent:	Monday, September 02, 2002 12.24 PM
> > To:	'w3c-dist-auth@w3.org'
> > Subject:	Proposal: WebDAV and transactions
> >
> >
> > Hello,
> >
> > The current WebDAV specifications deal with a transactional support on a
> > method base only. Either a single WebDAV method is completely and
> > successfully executed, or the method is not executed at all (e.g. a
> > PropPatch command will either modify all requested properties or none of
> > them). A transactional support spanning multiple WebDAV methods
> > is currently
> > not specified.
> > Multi user requirements are either handled in separate workspaces
> > (Delta-V)
> > or via the Lock method.
> > During our discussion on the JSR 170 (Content Management API)
> > implementation
> > on top of WebDAV, we believe that we require longer
> transactions spanning
> > multiple separate WebDAV methods. (This issue was already partially
> > discussed in the Batch method thread). Do you also fell the
> > need/requirement
> > to get a standard on the way, concerning a transactional WebDAV protocol
> > extension?
> >
> > A possible use case would be:
> > An author wants to modify an html page. To successfully do so,
> he will PUT
> > the updated html page back, PROPPATCH and UNLOCK it, DELETE all bitmap
> > files, which are not references any more, and PUT (create) the newly
> > referenced bitmaps files. If he wants to ensure, that either all
> > his changes
> > do apply (or none of them) he would surround those method call with an
> > TA-BEGIN and a TA-COMMIT method call. If the author would be an
> API (e.g.
> > JSR 170) exposing the TA functionality to an application, we
> believe this
> > feature to be mandatory.
> >
> > A possible (starting) specification could be:
> > WebDAV defines 3 additional methods: TA-BEGIN, TA-COMMIT and
> TA-ABORT. The
> > TA-BEGIN method will return a TA token (e.g. via an XML response
> > body). This
> > TA token will be send to the following WebDAV methods, which are part of
> > this transaction (e.g. via an additional header). The TA-COMMIT
> > or TA-ABORT
> > method will either commit or abort the transaction and invalidate the TA
> > token.
> > If and when an open TA, which is not used any more, is aborted, could be
> > controlled similar to the lock method timeout header.
> > All WebDAV methods, which either do not posses a TA token, or posses an
> > invalid token are handled as today (the method is executed
> within its own
> > TA), this would ensure upward compatibility.
> > This extension would be optional, if a server supports the TA
> methods, it
> > will state this in the OPTIONS request (similar to Delta-V).
> >
> >
> > Does this make sense?
> >
> > Best regards
> > Juergen Pill
> >
>



From w3c-dist-auth-request@w3.org  Mon Sep  9 12:57:54 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10053
	for <webdav-archive@lists.ietf.org>; Mon, 9 Sep 2002 12:57:54 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g89GuRI20308;
	Mon, 9 Sep 2002 12:56:27 -0400 (EDT)
Resent-Date: Mon, 9 Sep 2002 12:56:27 -0400 (EDT)
Resent-Message-Id: <200209091656.g89GuRI20308@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g89GuQU20288
	for <w3c-dist-auth@frink.w3.org>; Mon, 9 Sep 2002 12:56:26 -0400 (EDT)
Received: from cpimssmtpu11.email.msn.com (cpimssmtpu11.email.msn.com [207.46.181.86])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA03572
	for <w3c-dist-auth@w3.org>; Mon, 9 Sep 2002 12:56:26 -0400
Received: from compagno ([68.130.3.220]) by cpimssmtpu11.email.msn.com with Microsoft SMTPSVC(5.0.2195.4617);
	 Mon, 9 Sep 2002 09:54:52 -0700
Reply-To: <dennis.hamilton@acm.org>
From: "Dennis E. Hamilton" <dennis.hamilton@acm.org>
To: <w3c-dist-auth@w3.org>
Cc: "Pill, Juergen" <Juergen.Pill@softwareag.com>,
        "Julian Reschke" <julian.reschke@gmx.de>
Date: Mon, 9 Sep 2002 09:53:23 -0700
Message-ID: <NDBBKEGCNONMNKGDINPFOEDKGPAA.dennis.hamilton@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <JIEGINCHMLABHJBIGKBCGEPGFEAA.julian.reschke@gmx.de>
X-OriginalArrivalTime: 09 Sep 2002 16:54:52.0816 (UTC) FILETIME=[9E061900:01C25821]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g89GuQU20288
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6581
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>
Content-Transfer-Encoding: 8bit


I second that.  Also, there is more concern and interest about transactioning (and related topics) in specialized communities that are looking at how to adopt WebDAV in their niche.

The next point-counterpoint that Bernard Chester and I are working on for the electronic edition of AIIM eDocs magazine is going to be about the lack of transactioning support.  I was in Japan in April and this came up as a key issue for people operating with enterprise document-management systems there.  It also comes up in enterprise application integration, where federated transaction management is important.  That's looking pretty far down the road, but transactioning is a clear scalability issue unless one takes the position that WebDAV is simply not going to handle this, and people will need to use different views/islands for enterprise repositories if WebDAV is to be part of the story.

For a little background, here are the articles so far:

"WebDAV Arrives" (May/June 2002 Print issue)
http://www.edocmagazine.com/columns_articles.asp?ID=24696&vault=CNUTS&header=e_all_columns_header.gif

"WebDAV Universal Clients" (September 4, 2002, on-line edition)
http://www.edocmagazine.com/article.asp?ID=24744&header=e_webexclusive_header.gif

You will notice is that my perspective is toward being able to scale from a commodity protocol, so long as there is sufficient space within the specification to allow for that.  I say that WebDAV provides the necessary headroom, since metadata discovery and model discovery can all be done by supplemental and even parochial agreements within the existing framework.  Transactioning is not in that category and it will be a great challenge.

I notice that, on STEPwiki, the question about transactioning has not gone very far.  I don't know if Fielding's thesis addresses it or not.  I think Julian has a point in associating transactions with an object (resource) may be the avenue.  It is not obvious how to keep that within STEP and within HTTP without being just-another-tunneling. I think more discussion and attention are required.  

-- Dennis
 
------------------
Dennis E. Hamilton
AIIM DMware Technical Coordinator
mailto:dennis.hamilton@acm.org
http://www.dmware.org/
http://DMware.info/ Development Site
  ODMA Support: http://ODMA.info/


-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke
Sent: Monday, 09 September 2002 08:05
To: Pill, Juergen; 'Julian Reschke'; w3c-dist-auth@w3.org
Subject: RE: Proposal: WebDAV and transactions


Jürgen,

I think one should try to achieve the same goal while staying inside the
boundaries of HTTP.

For instance, one could define a specific "transaction resource", and use
POST to append specific method invocations to it. You might also want to
present your use case on the REST-discuss mailing list...

Julian

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

[ ... ]





From w3c-dist-auth-request@w3.org  Mon Sep  9 15:39:14 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14750
	for <webdav-archive@lists.ietf.org>; Mon, 9 Sep 2002 15:39:13 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g89Jb5k10584;
	Mon, 9 Sep 2002 15:37:05 -0400 (EDT)
Resent-Date: Mon, 9 Sep 2002 15:37:05 -0400 (EDT)
Resent-Message-Id: <200209091937.g89Jb5k10584@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g89Jb3U10558
	for <w3c-dist-auth@frink.w3.org>; Mon, 9 Sep 2002 15:37:03 -0400 (EDT)
Received: from hq-exgw2.filenet.com (Filenet-gw.filenet.com [198.3.8.1])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA04176
	for <w3c-dist-auth@w3.org>; Mon, 9 Sep 2002 15:37:00 -0400
Received: by hq-exgw2.filenet.com with Internet Mail Service (5.5.2653.19)
	id <R80MS71T>; Mon, 9 Sep 2002 12:36:17 -0700
Message-ID: <C3AF5E329E21D2119C4C00805F6FF58F08FE5E40@hq-expo2.filenet.com>
From: "Babich, Alan" <ABabich@filenet.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>,
        "Pill, Juergen"
	 <Juergen.Pill@softwareag.com>, w3c-dist-auth@w3.org
Date: Mon, 9 Sep 2002 12:36:26 -0700 
X-Mailer: Internet Mail Service (5.5.2653.19)
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6582
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>


The database vendors faced the issue of transactions in a client-server
network when they distributed their databases some ago. The naïve approach
of just remoting each database call was a performance disaster on large
networks. That is why they invented database script programming languages
and stored procedures. Stored procedures are scripts (in a database
programming language) that allow fairly general database transactions to be
programmed. These scripts are stored in the database. Clients invoke the
scripts by passing them parameters. 

Besides performance, one of the advantages of stored procedures is
standardization of the database processing. The system doesn't have to
depend upon every client getting the update processing correct. The stored
procedures can theoretically enforce all the checking and standardization
required. If one limits who can write stored procedures to a small trusted
group, the integrity of the system is protected.

As you pointed out, it is sometimes the case that the processing involved in
WebDAV transactions as you envision them is conditional on the result of
previous processing steps.

If you give people a gun they can shoot themselves in the foot with, then a
certain percentage of the people will shoot themselves in the foot. (I know
someone who literally did that.) If the gun refuses to shoot you in the
foot, that is a better design for the gun. In the spirit of that analogy, I
am proposing that the entire transaction, conditional processing and all,
should be invoked by one method call. That would do a lot to help protect
the performance of the system.

Within the single-method constraint, there are two ways to go: (1) Specify
the entire transaction, conditional processing and all, within the stuff you
send over the network in the method invocation. (2) Invent stored WebDAV
procedures that specify WebDAV transactions (conditional processing and
all), and have the method pass parameters to the stored procedure. You could
think about taking either or both of these approaches.

It is an open question as to whether either of the above two approaches can
be done well without doing violence to HTTP and/or WebDAV.

Alan

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de] 
Sent: Monday, September 09, 2002 7:34 AM
To: Pill, Juergen; w3c-dist-auth@w3.org
Subject: RE: Proposal: WebDAV and transactions


Jürgen,

I think the main issue isn't that people aren't interested -- it's more that
they (well, I) think that it's an extremely bad idea that doesn't adher to
the HTTP model.

In particular, it would make the meaning of an HTTP method invocation depend
on previous method calls. That makes it hard or impossible for
intermediaries to work with these messages.

Julian

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Pill, Juergen
> Sent: Monday, September 09, 2002 4:17 PM
> To: 'w3c-dist-auth@w3.org'
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> Hello,
>
> I did not receive a lot of feed-back on the TA "proposal" (and the
> statements were both positive and negative).
>
> Would you agree on the statement, the WebDAV group would be currently not
> interested in standardizing TA methods?
>
> As we would need this extension for the API implementation, our
> option would
> be to implement a proprietary WebDAV TA extension available on our server
> only.
>
> If the interest on this topic would raise again - possibly at a
> later time -
> we would be happy to share our experience with you.
>
> Best regards,
>
> Juergen Pill
>
>
>
>  -----Original Message-----
> From: 	Pill, Juergen [mailto:Juergen.Pill@softwareag.com]
> Sent:	Monday, September 02, 2002 12.24 PM
> To:	'w3c-dist-auth@w3.org'
> Subject:	Proposal: WebDAV and transactions
>
>
> Hello,
>
> The current WebDAV specifications deal with a transactional support on a
> method base only. Either a single WebDAV method is completely and
> successfully executed, or the method is not executed at all (e.g. a
> PropPatch command will either modify all requested properties or none of
> them). A transactional support spanning multiple WebDAV methods
> is currently
> not specified.
> Multi user requirements are either handled in separate workspaces
> (Delta-V)
> or via the Lock method.
> During our discussion on the JSR 170 (Content Management API)
> implementation
> on top of WebDAV, we believe that we require longer transactions spanning
> multiple separate WebDAV methods. (This issue was already partially
> discussed in the Batch method thread). Do you also fell the
> need/requirement
> to get a standard on the way, concerning a transactional WebDAV protocol
> extension?
>
> A possible use case would be:
> An author wants to modify an html page. To successfully do so, he will PUT
> the updated html page back, PROPPATCH and UNLOCK it, DELETE all bitmap
> files, which are not references any more, and PUT (create) the newly
> referenced bitmaps files. If he wants to ensure, that either all
> his changes
> do apply (or none of them) he would surround those method call with an
> TA-BEGIN and a TA-COMMIT method call. If the author would be an API (e.g.
> JSR 170) exposing the TA functionality to an application, we believe this
> feature to be mandatory.
>
> A possible (starting) specification could be:
> WebDAV defines 3 additional methods: TA-BEGIN, TA-COMMIT and TA-ABORT. The
> TA-BEGIN method will return a TA token (e.g. via an XML response
> body). This
> TA token will be send to the following WebDAV methods, which are part of
> this transaction (e.g. via an additional header). The TA-COMMIT
> or TA-ABORT
> method will either commit or abort the transaction and invalidate the TA
> token.
> If and when an open TA, which is not used any more, is aborted, could be
> controlled similar to the lock method timeout header.
> All WebDAV methods, which either do not posses a TA token, or posses an
> invalid token are handled as today (the method is executed within its own
> TA), this would ensure upward compatibility.
> This extension would be optional, if a server supports the TA methods, it
> will state this in the OPTIONS request (similar to Delta-V).
>
>
> Does this make sense?
>
> Best regards
> Juergen Pill
>



From w3c-dist-auth-request@w3.org  Tue Sep 10 11:07:53 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16947
	for <webdav-archive@lists.ietf.org>; Tue, 10 Sep 2002 11:07:53 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8AF7iL19813;
	Tue, 10 Sep 2002 11:07:44 -0400 (EDT)
Resent-Date: Tue, 10 Sep 2002 11:07:44 -0400 (EDT)
Resent-Message-Id: <200209101507.g8AF7iL19813@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8AF7hU19793
	for <w3c-dist-auth@frink.w3.org>; Tue, 10 Sep 2002 11:07:43 -0400 (EDT)
Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA07831
	for <w3c-dist-auth@w3.org>; Tue, 10 Sep 2002 11:07:43 -0400
Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 10 Sep 2002 11:07:06 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.182]) by atl1simr002.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 10 Sep 2002 11:07:05 -0400
Received: from xythoslap ([198.144.203.248]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 10 Sep 2002 11:07:04 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: <w3c-dist-auth@w3.org>
Cc: <joels@microsoft.com>
Date: Tue, 10 Sep 2002 08:07:05 -0700
Message-ID: <000901c258db$bacb6850$29c4fea9@xythoslap>
MIME-Version: 1.0
Content-Type: multipart/mixed;    
	boundary="------------InterScan_NT_MIME_Boundary"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
X-OriginalArrivalTime: 10 Sep 2002 15:07:05.0341 (UTC) FILETIME=[B9857AD0:01C258DB]
Subject: Links to latest bis working docs
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6583
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>


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000A_01C258A1.0E6E16F0"

------=_NextPart_000_000A_01C258A1.0E6E16F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I promised yesterday I'd put up links to the most recent
work-in-progress.

http://www.sharemation.com/~milele/public/dav/draft-ietf-webdav-rfc2518b
is.doc 

http://www.sharemation.com/~milele/public/dav/RFC2518%20Changes.doc

Sometime after the Interop, I'll be doing the real formatted draft thing
of course.

Lisa


------=_NextPart_000_000A_01C258A1.0E6E16F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{margin-right:0in;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{font-family:Arial;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><!-- Converted from =
text/rtf format -->I
promised yesterday I&#8217;d put up links to the most recent =
work-in-progress.</span></font></p>

<p><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><a
href=3D"http://www.sharemation.com/~milele/public/dav/draft-ietf-webdav-r=
fc2518bis.doc">http://www.sharemation.com/~milele/public/dav/draft-ietf-w=
ebdav-rfc2518bis.doc</a></span></font>
</p>

<p><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'><a
href=3D"http://www.sharemation.com/~milele/public/dav/RFC2518%20Changes.d=
oc">http://www.sharemation.com/~milele/public/dav/RFC2518%20Changes.doc</=
a></span></font></p>

<p><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>Sometime
after the Interop, I&#8217;ll be doing the real formatted draft thing of
course.</span></font></p>

<p><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>Lisa</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_000A_01C258A1.0E6E16F0--


--------------InterScan_NT_MIME_Boundary--



From w3c-dist-auth-request@w3.org  Tue Sep 10 14:32:45 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22734
	for <webdav-archive@lists.ietf.org>; Tue, 10 Sep 2002 14:32:45 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8AIXOi13559;
	Tue, 10 Sep 2002 14:33:24 -0400 (EDT)
Resent-Date: Tue, 10 Sep 2002 14:33:24 -0400 (EDT)
Resent-Message-Id: <200209101833.g8AIXOi13559@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8AIXMU13535
	for <w3c-dist-auth@frink.w3.org>; Tue, 10 Sep 2002 14:33:22 -0400 (EDT)
Received: from cats.ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA04401
	for <w3c-dist-auth@w3.org>; Tue, 10 Sep 2002 14:33:22 -0400
Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177])
	by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g8AIWsT26505
	for <w3c-dist-auth@w3.org>; Tue, 10 Sep 2002 11:32:55 -0700 (PDT)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "WebDAV" <w3c-dist-auth@w3.org>
Date: Tue, 10 Sep 2002 11:30:31 -0700
Message-ID: <AMEPKEBLDJJCCDEJHAMIGELPFGAA.ejw@cse.ucsc.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-UCSC-CATS-MailScanner: Found to be clean
Subject: FW: [Moderator Action] WEBDAV
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6584
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>
Content-Transfer-Encoding: 7bit


Accidentally caught by the spam filter.

- Jim

-----Original Message-----
From: Willcott, Yvonne WILLCOTY
[mailto:YVONNE.WILLCOTT@LEAVENWORTH.ARMY.MIL]
Sent: Tuesday, September 10, 2002 8:32 AM
To: 'w3c-dist-auth@w3.org'
Subject: [Moderator Action] WEBDAV




We are attempting to eliminate an ftp server and want to use webdav.  One of
the problems I seem to be running into is that three of the sources who
provide us data via ftp are on mainframes.  They are 'graciously' providing
this data by a batch runstream that produces a file and immediately ftps it
with no human intervention.  As I see it with WebDAV, they would have to put
the file to their pc/server then use WebDav to transfer it.  Am I correct or
do you know of a way with webdav that this could be done without causing
them extra time since this data they are sending is a 'courtesy'?

Thanks for your time,


Yvonne Willcott
Computer Specialist
DOIM Computer Operations
(913) 684-7092, DSN 552-7092
willcoty@leavenworth.army.mil





From w3c-dist-auth-request@w3.org  Tue Sep 10 14:32:52 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22761
	for <webdav-archive@lists.ietf.org>; Tue, 10 Sep 2002 14:32:52 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8AIXTu13601;
	Tue, 10 Sep 2002 14:33:29 -0400 (EDT)
Resent-Date: Tue, 10 Sep 2002 14:33:29 -0400 (EDT)
Resent-Message-Id: <200209101833.g8AIXTu13601@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8AIXTU13581
	for <w3c-dist-auth@frink.w3.org>; Tue, 10 Sep 2002 14:33:29 -0400 (EDT)
Received: from cats.ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA04439
	for <w3c-dist-auth@w3.org>; Tue, 10 Sep 2002 14:33:28 -0400
Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177])
	by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g8AIWtT26506
	for <w3c-dist-auth@w3.org>; Tue, 10 Sep 2002 11:32:55 -0700 (PDT)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "WebDAV" <w3c-dist-auth@w3.org>
Date: Tue, 10 Sep 2002 11:30:32 -0700
Message-ID: <AMEPKEBLDJJCCDEJHAMIIELPFGAA.ejw@cse.ucsc.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_009F_01C258BD.7902B900"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-UCSC-CATS-MailScanner: Found to be clean
Subject: FW: best webDAV implementation
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6585
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>


This is a multi-part message in MIME format.

------=_NextPart_000_009F_01C258BD.7902B900
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Accidentally caught by the spam filter.

- Jim
-----Original Message-----
From: Nguyen Tuan Khang [mailto:khangnt@sat.com.vn]
Sent: Tuesday, September 10, 2002 3:22 AM
To: w3c-dist-auth@w3.org
Subject: [Moderator Action] best webDAV implementation


hi,

I have to select webDAV implementation for my project with Websphere. I
found DAV4J but the problem is that this project was released in 2000 (2
years ago) and it used xml4j version 2.0. Now the xml4j comes with version
4.0 with a lot of improvements and deprecates so that DAV4J could not run
with updated xml4j releases (around 4.0 version).

Is there anyone who uses DAV4J to help me?
or could you recommend me which webDAV implementation is good, and try to
help me with the best one for websphere.

thank you
regards
Khang
PS: I am not in the list, please include my address in the reply addresses


------=_NextPart_000_009F_01C258BD.7902B900
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 content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3207.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D318132818-10092002>Accidentally caught by the spam=20
filter.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D318132818-10092002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D318132818-10092002>-=20
Jim</SPAN></FONT></DIV>
<DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> Nguyen Tuan Khang=20
[mailto:khangnt@sat.com.vn]<BR><B>Sent:</B> Tuesday, September 10, 2002 =
3:22=20
AM<BR><B>To:</B> w3c-dist-auth@w3.org<BR><B>Subject:</B> [Moderator =
Action] best=20
webDAV implementation<BR><BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I have to select webDAV implementation =
for my=20
project with Websphere. I found DAV4J but the problem is that this =
project was=20
released in 2000 (2 years ago) and&nbsp;it used xml4j version 2.0. Now =
the xml4j=20
comes&nbsp;with version 4.0 with a lot of improvements and =
deprecates&nbsp;so=20
that&nbsp;DAV4J could not run with updated xml4j releases (around 4.0=20
version).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Is there anyone who uses DAV4J to help =
me?=20
<DIV><FONT face=3DArial size=3D2>or&nbsp;could you recommend me which =
webDAV=20
implementation is good, and try to help me with the best one for=20
websphere.</FONT></DIV></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>thank you</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>regards</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Khang</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>PS: I am not in the list, please =
include my address=20
in the reply addresses</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_009F_01C258BD.7902B900--



From w3c-dist-auth-request@w3.org  Tue Sep 10 14:37:09 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22971
	for <webdav-archive@lists.ietf.org>; Tue, 10 Sep 2002 14:37:09 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8AIbWG15812;
	Tue, 10 Sep 2002 14:37:32 -0400 (EDT)
Resent-Date: Tue, 10 Sep 2002 14:37:32 -0400 (EDT)
Resent-Message-Id: <200209101837.g8AIbWG15812@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8AIbVU15792
	for <w3c-dist-auth@frink.w3.org>; Tue, 10 Sep 2002 14:37:31 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA05532
	for <w3c-dist-auth@w3.org>; Tue, 10 Sep 2002 14:37:31 -0400
Received: (qmail 5028 invoked by uid 0); 10 Sep 2002 18:37:00 -0000
Received: from p3ee24749.dip.t-dialin.net (HELO lisa) (62.226.71.73)
  by mail.gmx.net (mp002-rz3) with SMTP; 10 Sep 2002 18:37:00 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Lisa Dusseault" <lisa@xythos.com>, <w3c-dist-auth@w3.org>
Date: Tue, 10 Sep 2002 20:36:58 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCCECJFFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-reply-to: <000901c258db$bacb6850$29c4fea9@xythoslap>
Importance: Normal
Subject: RE: Links to latest bis working docs
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6586
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>
Content-Transfer-Encoding: 7bit


Just two comments on:

1.1       Source property
The Source property has not had interoperability demonstrated, but messages
to the list support keeping some way of retrieving the source of
dynamically-generated Web pages.  An interoperable solution exists (the
Microsoft Translate header) but has received rejection on the list due to
its lack of support for dynamically-generated resources with multiple source
files.


- the Translate header violates RFC2616 which explicitly says that variant
handling is *not* supposed to switch between "getting the source" and
"executing a script"

- the actual implementation in IIS breaks RFC2616 in that it doesn't list
"Translate" as request header on which the GET result varies.


Regards, Julian


--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Lisa Dusseault
Sent: Tuesday, September 10, 2002 5:07 PM
To: w3c-dist-auth@w3.org
Cc: joels@microsoft.com
Subject: Links to latest bis working docs


I promised yesterday I'd put up links to the most recent work-in-progress.
http://www.sharemation.com/~milele/public/dav/draft-ietf-webdav-rfc2518bis.d
oc
http://www.sharemation.com/~milele/public/dav/RFC2518%20Changes.doc
Sometime after the Interop, I'll be doing the real formatted draft thing of
course.
Lisa



From w3c-dist-auth-request@w3.org  Tue Sep 10 15:35:06 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24807
	for <webdav-archive@lists.ietf.org>; Tue, 10 Sep 2002 15:35:06 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8AJQF926056;
	Tue, 10 Sep 2002 15:26:15 -0400 (EDT)
Resent-Date: Tue, 10 Sep 2002 15:26:15 -0400 (EDT)
Resent-Message-Id: <200209101926.g8AJQF926056@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8AJQEU26036
	for <w3c-dist-auth@frink.w3.org>; Tue, 10 Sep 2002 15:26:14 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA16917
	for <w3c-dist-auth@w3.org>; Tue, 10 Sep 2002 15:26:14 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 10 Sep 2002 15:16:12 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <P4FX0MQ9>; Tue, 10 Sep 2002 15:25:41 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B107839213@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Tue, 10 Sep 2002 15:25:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: Links to latest bis working docs
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6587
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>


I agree with Julian.  Since the consensus of the working group
was to reject the Translate header approach (for the reasons
Julian mentions, and others), I believe it should not be introduced
in the revised document, and definitely should not be characterized as an
"interoperable solution".

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Tuesday, September 10, 2002 2:37 PM
To: Lisa Dusseault; w3c-dist-auth@w3.org
Subject: RE: Links to latest bis working docs



Just two comments on:

1.1       Source property
The Source property has not had interoperability demonstrated, but messages
to the list support keeping some way of retrieving the source of
dynamically-generated Web pages.  An interoperable solution exists (the
Microsoft Translate header) but has received rejection on the list due to
its lack of support for dynamically-generated resources with multiple source
files.


- the Translate header violates RFC2616 which explicitly says that variant
handling is *not* supposed to switch between "getting the source" and
"executing a script"

- the actual implementation in IIS breaks RFC2616 in that it doesn't list
"Translate" as request header on which the GET result varies.


Regards, Julian


--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Lisa Dusseault
Sent: Tuesday, September 10, 2002 5:07 PM
To: w3c-dist-auth@w3.org
Cc: joels@microsoft.com
Subject: Links to latest bis working docs


I promised yesterday I'd put up links to the most recent work-in-progress.
http://www.sharemation.com/~milele/public/dav/draft-ietf-webdav-rfc2518bis.d
oc
http://www.sharemation.com/~milele/public/dav/RFC2518%20Changes.doc
Sometime after the Interop, I'll be doing the real formatted draft thing of
course.
Lisa



From w3c-dist-auth-request@w3.org  Tue Sep 10 16:05:50 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25557
	for <webdav-archive@lists.ietf.org>; Tue, 10 Sep 2002 16:05:50 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8AK66E01868;
	Tue, 10 Sep 2002 16:06:06 -0400 (EDT)
Resent-Date: Tue, 10 Sep 2002 16:06:06 -0400 (EDT)
Resent-Message-Id: <200209102006.g8AK66E01868@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8AK65U01844
	for <w3c-dist-auth@frink.w3.org>; Tue, 10 Sep 2002 16:06:05 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA25521
	for <w3c-dist-auth@w3.org>; Tue, 10 Sep 2002 16:06:05 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 10 Sep 2002 16:05:34 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 10 Sep 2002 16:05:34 -0400
Received: from xythoslap ([128.114.63.207]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 10 Sep 2002 16:05:34 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Clemm, Geoff'" <gclemm@rational.com>, <w3c-dist-auth@w3.org>
Date: Tue, 10 Sep 2002 13:05:35 -0700
Message-ID: <000a01c25905$6d190520$cf3f7280@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-reply-to: <3906C56A7BD1F54593344C05BD1374B107839213@SUS-MA1IT01>
X-OriginalArrivalTime: 10 Sep 2002 20:05:34.0304 (UTC) FILETIME=[6C185E00:01C25905]
Subject: RE: Links to latest bis working docs
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6588
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>
Content-Transfer-Encoding: 7bit


Please note that the "Translate" header does not appear in the "revised
[2518] document".  

The "RFC2518 Changes" document discusses issues that have been brought
up on the list -- including the proposal that had been made, on the
list, to standardize the Translate header.  This document is only to
help keep track of issues (together with Jason's page) and RFC bis
changes, and is not on any standards track.  Note also that this
document briefly, and I believe correctly, summarizes that the working
group rejected the solution.  

If you still have problems with this characterization and where it
appears, please explain.

Lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]
> On Behalf Of Clemm, Geoff
> Sent: Tuesday, September 10, 2002 12:26 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: Links to latest bis working docs
> 
> 
> I agree with Julian.  Since the consensus of the working group
> was to reject the Translate header approach (for the reasons
> Julian mentions, and others), I believe it should not be introduced
> in the revised document, and definitely should not be characterized as
an
> "interoperable solution".
> 
> Cheers,
> Geoff
> 
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Tuesday, September 10, 2002 2:37 PM
> To: Lisa Dusseault; w3c-dist-auth@w3.org
> Subject: RE: Links to latest bis working docs
> 
> 
> 
> Just two comments on:
> 
> 1.1       Source property
> The Source property has not had interoperability demonstrated, but
> messages
> to the list support keeping some way of retrieving the source of
> dynamically-generated Web pages.  An interoperable solution exists
(the
> Microsoft Translate header) but has received rejection on the list due
to
> its lack of support for dynamically-generated resources with multiple
> source
> files.
> 
> 
> - the Translate header violates RFC2616 which explicitly says that
variant
> handling is *not* supposed to switch between "getting the source" and
> "executing a script"
> 
> - the actual implementation in IIS breaks RFC2616 in that it doesn't
list
> "Translate" as request header on which the GET result varies.
> 
> 
> Regards, Julian
> 
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On
> Behalf Of Lisa Dusseault
> Sent: Tuesday, September 10, 2002 5:07 PM
> To: w3c-dist-auth@w3.org
> Cc: joels@microsoft.com
> Subject: Links to latest bis working docs
> 
> 
> I promised yesterday I'd put up links to the most recent
work-in-progress.
> http://www.sharemation.com/~milele/public/dav/draft-ietf-webdav-
> rfc2518bis.d
> oc
> http://www.sharemation.com/~milele/public/dav/RFC2518%20Changes.doc
> Sometime after the Interop, I'll be doing the real formatted draft
thing
> of
> course.
> Lisa



From w3c-dist-auth-request@w3.org  Tue Sep 10 16:09:42 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25611
	for <webdav-archive@lists.ietf.org>; Tue, 10 Sep 2002 16:09:42 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8AK9xx02309;
	Tue, 10 Sep 2002 16:09:59 -0400 (EDT)
Resent-Date: Tue, 10 Sep 2002 16:09:59 -0400 (EDT)
Resent-Message-Id: <200209102009.g8AK9xx02309@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8AK9wU02289
	for <w3c-dist-auth@frink.w3.org>; Tue, 10 Sep 2002 16:09:58 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA26074
	for <w3c-dist-auth@w3.org>; Tue, 10 Sep 2002 16:09:58 -0400
Received: (qmail 20631 invoked by uid 0); 10 Sep 2002 20:09:27 -0000
Received: from p3ee24749.dip.t-dialin.net (HELO lisa) (62.226.71.73)
  by mail.gmx.net (mp002-rz3) with SMTP; 10 Sep 2002 20:09:27 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Lisa Dusseault" <lisa@xythos.com>, "'Clemm, Geoff'" <gclemm@rational.com>,
        <w3c-dist-auth@w3.org>
Date: Tue, 10 Sep 2002 22:09:25 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCEECNFFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-reply-to: <000a01c25905$6d190520$cf3f7280@xythoslap>
Importance: Normal
Subject: RE: Links to latest bis working docs
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6589
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>
Content-Transfer-Encoding: 7bit


Lisa,

my complaint was that it lists only one of many reasons for rejecting yet,
but also states that there are interoperable implementations. They may
exist, but at least one of them (IIS) does not conform to RFC2616 (HTTP), so
I don't think it qualifies as relevant implementation.

Julian

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Tuesday, September 10, 2002 10:06 PM
> To: 'Clemm, Geoff'; w3c-dist-auth@w3.org
> Subject: RE: Links to latest bis working docs
>
>
>
> Please note that the "Translate" header does not appear in the "revised
> [2518] document".
>
> The "RFC2518 Changes" document discusses issues that have been brought
> up on the list -- including the proposal that had been made, on the
> list, to standardize the Translate header.  This document is only to
> help keep track of issues (together with Jason's page) and RFC bis
> changes, and is not on any standards track.  Note also that this
> document briefly, and I believe correctly, summarizes that the working
> group rejected the solution.
>
> If you still have problems with this characterization and where it
> appears, please explain.
>
> Lisa
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]
> > On Behalf Of Clemm, Geoff
> > Sent: Tuesday, September 10, 2002 12:26 PM
> > To: w3c-dist-auth@w3.org
> > Subject: RE: Links to latest bis working docs
> >
> >
> > I agree with Julian.  Since the consensus of the working group
> > was to reject the Translate header approach (for the reasons
> > Julian mentions, and others), I believe it should not be introduced
> > in the revised document, and definitely should not be characterized as
> an
> > "interoperable solution".
> >
> > Cheers,
> > Geoff
> >
> > -----Original Message-----
> > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > Sent: Tuesday, September 10, 2002 2:37 PM
> > To: Lisa Dusseault; w3c-dist-auth@w3.org
> > Subject: RE: Links to latest bis working docs
> >
> >
> >
> > Just two comments on:
> >
> > 1.1       Source property
> > The Source property has not had interoperability demonstrated, but
> > messages
> > to the list support keeping some way of retrieving the source of
> > dynamically-generated Web pages.  An interoperable solution exists
> (the
> > Microsoft Translate header) but has received rejection on the list due
> to
> > its lack of support for dynamically-generated resources with multiple
> > source
> > files.
> >
> >
> > - the Translate header violates RFC2616 which explicitly says that
> variant
> > handling is *not* supposed to switch between "getting the source" and
> > "executing a script"
> >
> > - the actual implementation in IIS breaks RFC2616 in that it doesn't
> list
> > "Translate" as request header on which the GET result varies.
> >
> >
> > Regards, Julian
> >
> >
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On
> > Behalf Of Lisa Dusseault
> > Sent: Tuesday, September 10, 2002 5:07 PM
> > To: w3c-dist-auth@w3.org
> > Cc: joels@microsoft.com
> > Subject: Links to latest bis working docs
> >
> >
> > I promised yesterday I'd put up links to the most recent
> work-in-progress.
> > http://www.sharemation.com/~milele/public/dav/draft-ietf-webdav-
> > rfc2518bis.d
> > oc
> > http://www.sharemation.com/~milele/public/dav/RFC2518%20Changes.doc
> > Sometime after the Interop, I'll be doing the real formatted draft
> thing
> > of
> > course.
> > Lisa
>



From w3c-dist-auth-request@w3.org  Tue Sep 10 16:29:45 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25977
	for <webdav-archive@lists.ietf.org>; Tue, 10 Sep 2002 16:29:45 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8AKUGd09249;
	Tue, 10 Sep 2002 16:30:16 -0400 (EDT)
Resent-Date: Tue, 10 Sep 2002 16:30:16 -0400 (EDT)
Resent-Message-Id: <200209102030.g8AKUGd09249@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8AKUFU09229
	for <w3c-dist-auth@frink.w3.org>; Tue, 10 Sep 2002 16:30:15 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA29631
	for <w3c-dist-auth@w3.org>; Tue, 10 Sep 2002 16:30:15 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 10 Sep 2002 16:20:14 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <P4FX0QKS>; Tue, 10 Sep 2002 16:29:43 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B107839215@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Tue, 10 Sep 2002 16:29:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: Links to latest bis working docs
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6590
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>


I just wanted to make sure that it continues to not appear in
the revised document (:-).  In particular, I was concerned by
the phrase "interoperable solution", as this seemed to open the
door to including it.

So the update to the "RFC 2518 Changes" document that I'd like
to see in this regard would be adding the reasons
summarized by Julian for the rejection of the Translate header,
and changing the characterization of the Translate header from an
"interoperable solution" to an "approach".

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Tuesday, September 10, 2002 4:06 PM
To: 'Clemm, Geoff'; w3c-dist-auth@w3.org
Subject: RE: Links to latest bis working docs


Please note that the "Translate" header does not appear in the "revised
[2518] document".  

The "RFC2518 Changes" document discusses issues that have been brought
up on the list -- including the proposal that had been made, on the
list, to standardize the Translate header.  This document is only to
help keep track of issues (together with Jason's page) and RFC bis
changes, and is not on any standards track.  Note also that this
document briefly, and I believe correctly, summarizes that the working
group rejected the solution.  

If you still have problems with this characterization and where it
appears, please explain.

Lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]
> On Behalf Of Clemm, Geoff
> Sent: Tuesday, September 10, 2002 12:26 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: Links to latest bis working docs
> 
> 
> I agree with Julian.  Since the consensus of the working group
> was to reject the Translate header approach (for the reasons
> Julian mentions, and others), I believe it should not be introduced
> in the revised document, and definitely should not be characterized as
an
> "interoperable solution".
> 
> Cheers,
> Geoff
> 
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Tuesday, September 10, 2002 2:37 PM
> To: Lisa Dusseault; w3c-dist-auth@w3.org
> Subject: RE: Links to latest bis working docs
> 
> 
> 
> Just two comments on:
> 
> 1.1       Source property
> The Source property has not had interoperability demonstrated, but
> messages
> to the list support keeping some way of retrieving the source of
> dynamically-generated Web pages.  An interoperable solution exists
(the
> Microsoft Translate header) but has received rejection on the list due
to
> its lack of support for dynamically-generated resources with multiple
> source
> files.
> 
> 
> - the Translate header violates RFC2616 which explicitly says that
variant
> handling is *not* supposed to switch between "getting the source" and
> "executing a script"
> 
> - the actual implementation in IIS breaks RFC2616 in that it doesn't
list
> "Translate" as request header on which the GET result varies.
> 
> 
> Regards, Julian
> 
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On
> Behalf Of Lisa Dusseault
> Sent: Tuesday, September 10, 2002 5:07 PM
> To: w3c-dist-auth@w3.org
> Cc: joels@microsoft.com
> Subject: Links to latest bis working docs
> 
> 
> I promised yesterday I'd put up links to the most recent
work-in-progress.
> http://www.sharemation.com/~milele/public/dav/draft-ietf-webdav-
> rfc2518bis.d
> oc
> http://www.sharemation.com/~milele/public/dav/RFC2518%20Changes.doc
> Sometime after the Interop, I'll be doing the real formatted draft
thing
> of
> course.
> Lisa



From w3c-dist-auth-request@w3.org  Tue Sep 10 16:37:54 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26146
	for <webdav-archive@lists.ietf.org>; Tue, 10 Sep 2002 16:37:54 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8AKbpu11282;
	Tue, 10 Sep 2002 16:37:51 -0400 (EDT)
Resent-Date: Tue, 10 Sep 2002 16:37:51 -0400 (EDT)
Resent-Message-Id: <200209102037.g8AKbpu11282@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8AKboU11262
	for <w3c-dist-auth@frink.w3.org>; Tue, 10 Sep 2002 16:37:50 -0400 (EDT)
Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA31107
	for <w3c-dist-auth@w3.org>; Tue, 10 Sep 2002 16:37:49 -0400
Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 10 Sep 2002 16:37:13 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.182]) by atl1simr002.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 10 Sep 2002 16:37:12 -0400
Received: from xythoslap ([128.114.55.179]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 10 Sep 2002 16:37:12 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>,
        "'Clemm, Geoff'" <gclemm@rational.com>, <w3c-dist-auth@w3.org>
Date: Tue, 10 Sep 2002 13:37:13 -0700
Message-ID: <000001c25909$d8ef3bd0$b3377280@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <JIEGINCHMLABHJBIGKBCEECNFFAA.julian.reschke@gmx.de>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 10 Sep 2002 20:37:12.0290 (UTC) FILETIME=[D7620C20:01C25909]
Subject: RE: Links to latest bis working docs
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6591
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>
Content-Transfer-Encoding: 7bit


Yes, I have little problem with including more information in the
*extremely brief* summary of the debate.  It is always difficult to
summarize a debate, whether briefly or at length.  I had thought that
that putting the summary in a non-standards-track document would be
safe.

I still believe that "interoperable" is a fair characterization, however
I can also add the words "non-compliant".  If we go about qualifying
implementations based on full compliance, I fear that random software
bugs would disqualify many many implementations.

lisa

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Tuesday, September 10, 2002 1:09 PM
> To: Lisa Dusseault; 'Clemm, Geoff'; w3c-dist-auth@w3.org
> Subject: RE: Links to latest bis working docs
> 
> Lisa,
> 
> my complaint was that it lists only one of many reasons for rejecting
yet,
> but also states that there are interoperable implementations. They may
> exist, but at least one of them (IIS) does not conform to RFC2616
(HTTP),
> so
> I don't think it qualifies as relevant implementation.
> 
> Julian
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> > Sent: Tuesday, September 10, 2002 10:06 PM
> > To: 'Clemm, Geoff'; w3c-dist-auth@w3.org
> > Subject: RE: Links to latest bis working docs
> >
> >
> >
> > Please note that the "Translate" header does not appear in the
"revised
> > [2518] document".
> >
> > The "RFC2518 Changes" document discusses issues that have been
brought
> > up on the list -- including the proposal that had been made, on the
> > list, to standardize the Translate header.  This document is only to
> > help keep track of issues (together with Jason's page) and RFC bis
> > changes, and is not on any standards track.  Note also that this
> > document briefly, and I believe correctly, summarizes that the
working
> > group rejected the solution.
> >
> > If you still have problems with this characterization and where it
> > appears, please explain.
> >
> > Lisa
> >
> > > -----Original Message-----
> > > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]
> > > On Behalf Of Clemm, Geoff
> > > Sent: Tuesday, September 10, 2002 12:26 PM
> > > To: w3c-dist-auth@w3.org
> > > Subject: RE: Links to latest bis working docs
> > >
> > >
> > > I agree with Julian.  Since the consensus of the working group
> > > was to reject the Translate header approach (for the reasons
> > > Julian mentions, and others), I believe it should not be
introduced
> > > in the revised document, and definitely should not be
characterized as
> > an
> > > "interoperable solution".
> > >
> > > Cheers,
> > > Geoff
> > >
> > > -----Original Message-----
> > > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > > Sent: Tuesday, September 10, 2002 2:37 PM
> > > To: Lisa Dusseault; w3c-dist-auth@w3.org
> > > Subject: RE: Links to latest bis working docs
> > >
> > >
> > >
> > > Just two comments on:
> > >
> > > 1.1       Source property
> > > The Source property has not had interoperability demonstrated, but
> > > messages
> > > to the list support keeping some way of retrieving the source of
> > > dynamically-generated Web pages.  An interoperable solution exists
> > (the
> > > Microsoft Translate header) but has received rejection on the list
due
> > to
> > > its lack of support for dynamically-generated resources with
multiple
> > > source
> > > files.
> > >
> > >
> > > - the Translate header violates RFC2616 which explicitly says that
> > variant
> > > handling is *not* supposed to switch between "getting the source"
and
> > > "executing a script"
> > >
> > > - the actual implementation in IIS breaks RFC2616 in that it
doesn't
> > list
> > > "Translate" as request header on which the GET result varies.
> > >
> > >
> > > Regards, Julian
> > >
> > >
> > > --
> > > <green/>bytes GmbH -- http://www.greenbytes.de --
tel:+492512807760
> > > -----Original Message-----
> > > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On
> > > Behalf Of Lisa Dusseault
> > > Sent: Tuesday, September 10, 2002 5:07 PM
> > > To: w3c-dist-auth@w3.org
> > > Cc: joels@microsoft.com
> > > Subject: Links to latest bis working docs
> > >
> > >
> > > I promised yesterday I'd put up links to the most recent
> > work-in-progress.
> > > http://www.sharemation.com/~milele/public/dav/draft-ietf-webdav-
> > > rfc2518bis.d
> > > oc
> > >
http://www.sharemation.com/~milele/public/dav/RFC2518%20Changes.doc
> > > Sometime after the Interop, I'll be doing the real formatted draft
> > thing
> > > of
> > > course.
> > > Lisa
> >



From w3c-dist-auth-request@w3.org  Tue Sep 10 19:24:18 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29215
	for <webdav-archive@lists.ietf.org>; Tue, 10 Sep 2002 19:24:18 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8ANOeU06308;
	Tue, 10 Sep 2002 19:24:40 -0400 (EDT)
Resent-Date: Tue, 10 Sep 2002 19:24:40 -0400 (EDT)
Resent-Message-Id: <200209102324.g8ANOeU06308@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8ANOcU06284
	for <w3c-dist-auth@frink.w3.org>; Tue, 10 Sep 2002 19:24:38 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA31672
	for <w3c-dist-auth@w3.org>; Tue, 10 Sep 2002 19:24:38 -0400
Received: (qmail 22778 invoked by uid 0); 10 Sep 2002 23:24:07 -0000
Received: from p3ee24749.dip.t-dialin.net (HELO lisa) (62.226.71.73)
  by mail.gmx.net (mp002-rz3) with SMTP; 10 Sep 2002 23:24:07 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Lisa Dusseault" <lisa@xythos.com>,
        "'Julian Reschke'" <julian.reschke@gmx.de>,
        "'Clemm, Geoff'" <gclemm@rational.com>, <w3c-dist-auth@w3.org>
Date: Wed, 11 Sep 2002 01:24:05 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCKEDDFFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-reply-to: <000001c25909$d8ef3bd0$b3377280@xythoslap>
Importance: Normal
Subject: RE: Links to latest bis working docs
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6592
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>
Content-Transfer-Encoding: 7bit


Lisa,

it probably would be safer just to say that there was a discussion and to
point to the relevant mailig list archive enties.

The problem with the "interoperable solution" is that the "solution"
*itself* is in conflict with the base spec RFC2616 (HTTP), so by definition
it can't be the protocol that an RFC based on HTTP recommends.

Julian

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Tuesday, September 10, 2002 10:37 PM
> To: 'Julian Reschke'; 'Clemm, Geoff'; w3c-dist-auth@w3.org
> Subject: RE: Links to latest bis working docs
>
>
>
> Yes, I have little problem with including more information in the
> *extremely brief* summary of the debate.  It is always difficult to
> summarize a debate, whether briefly or at length.  I had thought that
> that putting the summary in a non-standards-track document would be
> safe.
>
> I still believe that "interoperable" is a fair characterization, however
> I can also add the words "non-compliant".  If we go about qualifying
> implementations based on full compliance, I fear that random software
> bugs would disqualify many many implementations.
>
> lisa
>
> > -----Original Message-----
> > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > Sent: Tuesday, September 10, 2002 1:09 PM
> > To: Lisa Dusseault; 'Clemm, Geoff'; w3c-dist-auth@w3.org
> > Subject: RE: Links to latest bis working docs
> >
> > Lisa,
> >
> > my complaint was that it lists only one of many reasons for rejecting
> yet,
> > but also states that there are interoperable implementations. They may
> > exist, but at least one of them (IIS) does not conform to RFC2616
> (HTTP),
> > so
> > I don't think it qualifies as relevant implementation.
> >
> > Julian
> >
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >
> > > -----Original Message-----
> > > From: w3c-dist-auth-request@w3.org
> > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> > > Sent: Tuesday, September 10, 2002 10:06 PM
> > > To: 'Clemm, Geoff'; w3c-dist-auth@w3.org
> > > Subject: RE: Links to latest bis working docs
> > >
> > >
> > >
> > > Please note that the "Translate" header does not appear in the
> "revised
> > > [2518] document".
> > >
> > > The "RFC2518 Changes" document discusses issues that have been
> brought
> > > up on the list -- including the proposal that had been made, on the
> > > list, to standardize the Translate header.  This document is only to
> > > help keep track of issues (together with Jason's page) and RFC bis
> > > changes, and is not on any standards track.  Note also that this
> > > document briefly, and I believe correctly, summarizes that the
> working
> > > group rejected the solution.
> > >
> > > If you still have problems with this characterization and where it
> > > appears, please explain.
> > >
> > > Lisa
> > >
> > > > -----Original Message-----
> > > > From: w3c-dist-auth-request@w3.org
> > > [mailto:w3c-dist-auth-request@w3.org]
> > > > On Behalf Of Clemm, Geoff
> > > > Sent: Tuesday, September 10, 2002 12:26 PM
> > > > To: w3c-dist-auth@w3.org
> > > > Subject: RE: Links to latest bis working docs
> > > >
> > > >
> > > > I agree with Julian.  Since the consensus of the working group
> > > > was to reject the Translate header approach (for the reasons
> > > > Julian mentions, and others), I believe it should not be
> introduced
> > > > in the revised document, and definitely should not be
> characterized as
> > > an
> > > > "interoperable solution".
> > > >
> > > > Cheers,
> > > > Geoff
> > > >
> > > > -----Original Message-----
> > > > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > > > Sent: Tuesday, September 10, 2002 2:37 PM
> > > > To: Lisa Dusseault; w3c-dist-auth@w3.org
> > > > Subject: RE: Links to latest bis working docs
> > > >
> > > >
> > > >
> > > > Just two comments on:
> > > >
> > > > 1.1       Source property
> > > > The Source property has not had interoperability demonstrated, but
> > > > messages
> > > > to the list support keeping some way of retrieving the source of
> > > > dynamically-generated Web pages.  An interoperable solution exists
> > > (the
> > > > Microsoft Translate header) but has received rejection on the list
> due
> > > to
> > > > its lack of support for dynamically-generated resources with
> multiple
> > > > source
> > > > files.
> > > >
> > > >
> > > > - the Translate header violates RFC2616 which explicitly says that
> > > variant
> > > > handling is *not* supposed to switch between "getting the source"
> and
> > > > "executing a script"
> > > >
> > > > - the actual implementation in IIS breaks RFC2616 in that it
> doesn't
> > > list
> > > > "Translate" as request header on which the GET result varies.
> > > >
> > > >
> > > > Regards, Julian
> > > >
> > > >
> > > > --
> > > > <green/>bytes GmbH -- http://www.greenbytes.de --
> tel:+492512807760
> > > > -----Original Message-----
> > > > From: w3c-dist-auth-request@w3.org
> > > [mailto:w3c-dist-auth-request@w3.org]On
> > > > Behalf Of Lisa Dusseault
> > > > Sent: Tuesday, September 10, 2002 5:07 PM
> > > > To: w3c-dist-auth@w3.org
> > > > Cc: joels@microsoft.com
> > > > Subject: Links to latest bis working docs
> > > >
> > > >
> > > > I promised yesterday I'd put up links to the most recent
> > > work-in-progress.
> > > > http://www.sharemation.com/~milele/public/dav/draft-ietf-webdav-
> > > > rfc2518bis.d
> > > > oc
> > > >
> http://www.sharemation.com/~milele/public/dav/RFC2518%20Changes.doc
> > > > Sometime after the Interop, I'll be doing the real formatted draft
> > > thing
> > > > of
> > > > course.
> > > > Lisa
> > >
>



From w3c-dist-auth-request@w3.org  Tue Sep 10 19:28:43 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29273
	for <webdav-archive@lists.ietf.org>; Tue, 10 Sep 2002 19:28:43 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8ANT8D06521;
	Tue, 10 Sep 2002 19:29:08 -0400 (EDT)
Resent-Date: Tue, 10 Sep 2002 19:29:08 -0400 (EDT)
Resent-Message-Id: <200209102329.g8ANT8D06521@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8ANT7U06500
	for <w3c-dist-auth@frink.w3.org>; Tue, 10 Sep 2002 19:29:07 -0400 (EDT)
Received: from cs.utep.edu (mail.cs.utep.edu [129.108.5.3])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA32059
	for <w3c-dist-auth@w3.org>; Tue, 10 Sep 2002 19:29:07 -0400
From: lakshmi@cs.utep.edu
Received: from gecko (gecko [129.108.5.51])
	by cs.utep.edu (8.11.3/8.11.3) with ESMTP id g8ANSLE17322;
	Tue, 10 Sep 2002 17:28:21 -0600 (MDT)
Date: Tue, 10 Sep 2002 17:28:21 -0600 (MDT)
X-Sender:  <lakshmi@gecko>
To: Julian Reschke <julian.reschke@gmx.de>
cc: Lisa Dusseault <lisa@xythos.com>, "'Clemm, Geoff'" <gclemm@rational.com>,
        <w3c-dist-auth@w3.org>
In-Reply-To: <JIEGINCHMLABHJBIGKBCKEDDFFAA.julian.reschke@gmx.de>
Message-ID: <Pine.GSO.4.30.0209101727420.8895-100000@gecko>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: RE: Links to latest bis working docs
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6593
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>


Please remove me from this mailing list!! I ve been trying to unsubscribe
with no result.!
thanks

On Wed, 11 Sep 2002, Julian Reschke wrote:

>
> Lisa,
>
> it probably would be safer just to say that there was a discussion and to
> point to the relevant mailig list archive enties.
>
> The problem with the "interoperable solution" is that the "solution"
> *itself* is in conflict with the base spec RFC2616 (HTTP), so by definition
> it can't be the protocol that an RFC based on HTTP recommends.
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> > Sent: Tuesday, September 10, 2002 10:37 PM
> > To: 'Julian Reschke'; 'Clemm, Geoff'; w3c-dist-auth@w3.org
> > Subject: RE: Links to latest bis working docs
> >
> >
> >
> > Yes, I have little problem with including more information in the
> > *extremely brief* summary of the debate.  It is always difficult to
> > summarize a debate, whether briefly or at length.  I had thought that
> > that putting the summary in a non-standards-track document would be
> > safe.
> >
> > I still believe that "interoperable" is a fair characterization, however
> > I can also add the words "non-compliant".  If we go about qualifying
> > implementations based on full compliance, I fear that random software
> > bugs would disqualify many many implementations.
> >
> > lisa
> >
> > > -----Original Message-----
> > > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > > Sent: Tuesday, September 10, 2002 1:09 PM
> > > To: Lisa Dusseault; 'Clemm, Geoff'; w3c-dist-auth@w3.org
> > > Subject: RE: Links to latest bis working docs
> > >
> > > Lisa,
> > >
> > > my complaint was that it lists only one of many reasons for rejecting
> > yet,
> > > but also states that there are interoperable implementations. They may
> > > exist, but at least one of them (IIS) does not conform to RFC2616
> > (HTTP),
> > > so
> > > I don't think it qualifies as relevant implementation.
> > >
> > > Julian
> > >
> > > --
> > > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> > >
> > > > -----Original Message-----
> > > > From: w3c-dist-auth-request@w3.org
> > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> > > > Sent: Tuesday, September 10, 2002 10:06 PM
> > > > To: 'Clemm, Geoff'; w3c-dist-auth@w3.org
> > > > Subject: RE: Links to latest bis working docs
> > > >
> > > >
> > > >
> > > > Please note that the "Translate" header does not appear in the
> > "revised
> > > > [2518] document".
> > > >
> > > > The "RFC2518 Changes" document discusses issues that have been
> > brought
> > > > up on the list -- including the proposal that had been made, on the
> > > > list, to standardize the Translate header.  This document is only to
> > > > help keep track of issues (together with Jason's page) and RFC bis
> > > > changes, and is not on any standards track.  Note also that this
> > > > document briefly, and I believe correctly, summarizes that the
> > working
> > > > group rejected the solution.
> > > >
> > > > If you still have problems with this characterization and where it
> > > > appears, please explain.
> > > >
> > > > Lisa
> > > >
> > > > > -----Original Message-----
> > > > > From: w3c-dist-auth-request@w3.org
> > > > [mailto:w3c-dist-auth-request@w3.org]
> > > > > On Behalf Of Clemm, Geoff
> > > > > Sent: Tuesday, September 10, 2002 12:26 PM
> > > > > To: w3c-dist-auth@w3.org
> > > > > Subject: RE: Links to latest bis working docs
> > > > >
> > > > >
> > > > > I agree with Julian.  Since the consensus of the working group
> > > > > was to reject the Translate header approach (for the reasons
> > > > > Julian mentions, and others), I believe it should not be
> > introduced
> > > > > in the revised document, and definitely should not be
> > characterized as
> > > > an
> > > > > "interoperable solution".
> > > > >
> > > > > Cheers,
> > > > > Geoff
> > > > >
> > > > > -----Original Message-----
> > > > > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > > > > Sent: Tuesday, September 10, 2002 2:37 PM
> > > > > To: Lisa Dusseault; w3c-dist-auth@w3.org
> > > > > Subject: RE: Links to latest bis working docs
> > > > >
> > > > >
> > > > >
> > > > > Just two comments on:
> > > > >
> > > > > 1.1       Source property
> > > > > The Source property has not had interoperability demonstrated, but
> > > > > messages
> > > > > to the list support keeping some way of retrieving the source of
> > > > > dynamically-generated Web pages.  An interoperable solution exists
> > > > (the
> > > > > Microsoft Translate header) but has received rejection on the list
> > due
> > > > to
> > > > > its lack of support for dynamically-generated resources with
> > multiple
> > > > > source
> > > > > files.
> > > > >
> > > > >
> > > > > - the Translate header violates RFC2616 which explicitly says that
> > > > variant
> > > > > handling is *not* supposed to switch between "getting the source"
> > and
> > > > > "executing a script"
> > > > >
> > > > > - the actual implementation in IIS breaks RFC2616 in that it
> > doesn't
> > > > list
> > > > > "Translate" as request header on which the GET result varies.
> > > > >
> > > > >
> > > > > Regards, Julian
> > > > >
> > > > >
> > > > > --
> > > > > <green/>bytes GmbH -- http://www.greenbytes.de --
> > tel:+492512807760
> > > > > -----Original Message-----
> > > > > From: w3c-dist-auth-request@w3.org
> > > > [mailto:w3c-dist-auth-request@w3.org]On
> > > > > Behalf Of Lisa Dusseault
> > > > > Sent: Tuesday, September 10, 2002 5:07 PM
> > > > > To: w3c-dist-auth@w3.org
> > > > > Cc: joels@microsoft.com
> > > > > Subject: Links to latest bis working docs
> > > > >
> > > > >
> > > > > I promised yesterday I'd put up links to the most recent
> > > > work-in-progress.
> > > > > http://www.sharemation.com/~milele/public/dav/draft-ietf-webdav-
> > > > > rfc2518bis.d
> > > > > oc
> > > > >
> > http://www.sharemation.com/~milele/public/dav/RFC2518%20Changes.doc
> > > > > Sometime after the Interop, I'll be doing the real formatted draft
> > > > thing
> > > > > of
> > > > > course.
> > > > > Lisa
> > > >
> >
>



From w3c-dist-auth-request@w3.org  Wed Sep 11 02:02:27 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08858
	for <webdav-archive@lists.ietf.org>; Wed, 11 Sep 2002 02:02:27 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8B62US08701;
	Wed, 11 Sep 2002 02:02:30 -0400 (EDT)
Resent-Date: Wed, 11 Sep 2002 02:02:30 -0400 (EDT)
Resent-Message-Id: <200209110602.g8B62US08701@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8B62SU08677
	for <w3c-dist-auth@frink.w3.org>; Wed, 11 Sep 2002 02:02:28 -0400 (EDT)
Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA14057
	for <w3c-dist-auth@w3.org>; Wed, 11 Sep 2002 02:02:27 -0400
Received: from inet-mail1.oracle.com (localhost [127.0.0.1])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8B61ue18550
	for <w3c-dist-auth@w3.org>; Tue, 10 Sep 2002 23:01:57 -0700 (PDT)
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8B61uC18539
	for <w3c-dist-auth@w3.org>; Tue, 10 Sep 2002 23:01:56 -0700 (PDT)
Received: from rgmum1.us.oracle.com (rgmum1.us.oracle.com [138.1.191.22])
	by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8B61tO16714
	for <w3c-dist-auth@w3.org>; Wed, 11 Sep 2002 00:01:55 -0600 (MDT)
Received: from 152.68.17.155 by rgmum2.us.oracle.com
	with ESMTP id 61164461031724110; Wed, 11 Sep 2002 00:01:50 -0600
Message-ID: <001301c25958$5aa2d490$9b114498@esedlar>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: "Babich, Alan" <ABabich@filenet.com>,
        "'Julian Reschke'" <julian.reschke@gmx.de>,
        "Pill, Juergen" <Juergen.Pill@softwareag.com>, <w3c-dist-auth@w3.org>
References: <C3AF5E329E21D2119C4C00805F6FF58F08FE5E40@hq-expo2.filenet.com>
Date: Tue, 10 Sep 2002 00:51:57 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6594
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>
Content-Transfer-Encoding: 8bit


I think it is clear that the best way to address this requirement is through
batching up WebDAV METHODS into a single request.  We also have requirements
for doing batch methods for other reasons, and I know Microsoft has also run
into this requirement and extended the standard this way.

--Eric

----- Original Message -----
From: "Babich, Alan" <ABabich@filenet.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>; "Pill, Juergen"
<Juergen.Pill@softwareag.com>; <w3c-dist-auth@w3.org>
Sent: Monday, September 09, 2002 12:36 PM
Subject: RE: Proposal: WebDAV and transactions


>
> The database vendors faced the issue of transactions in a client-server
> network when they distributed their databases some ago. The naïve approach
> of just remoting each database call was a performance disaster on large
> networks. That is why they invented database script programming languages
> and stored procedures. Stored procedures are scripts (in a database
> programming language) that allow fairly general database transactions to
be
> programmed. These scripts are stored in the database. Clients invoke the
> scripts by passing them parameters.
>
> Besides performance, one of the advantages of stored procedures is
> standardization of the database processing. The system doesn't have to
> depend upon every client getting the update processing correct. The stored
> procedures can theoretically enforce all the checking and standardization
> required. If one limits who can write stored procedures to a small trusted
> group, the integrity of the system is protected.
>
> As you pointed out, it is sometimes the case that the processing involved
in
> WebDAV transactions as you envision them is conditional on the result of
> previous processing steps.
>
> If you give people a gun they can shoot themselves in the foot with, then
a
> certain percentage of the people will shoot themselves in the foot. (I
know
> someone who literally did that.) If the gun refuses to shoot you in the
> foot, that is a better design for the gun. In the spirit of that analogy,
I
> am proposing that the entire transaction, conditional processing and all,
> should be invoked by one method call. That would do a lot to help protect
> the performance of the system.
>
> Within the single-method constraint, there are two ways to go: (1) Specify
> the entire transaction, conditional processing and all, within the stuff
you
> send over the network in the method invocation. (2) Invent stored WebDAV
> procedures that specify WebDAV transactions (conditional processing and
> all), and have the method pass parameters to the stored procedure. You
could
> think about taking either or both of these approaches.
>
> It is an open question as to whether either of the above two approaches
can
> be done well without doing violence to HTTP and/or WebDAV.
>
> Alan
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Monday, September 09, 2002 7:34 AM
> To: Pill, Juergen; w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
> Jürgen,
>
> I think the main issue isn't that people aren't interested -- it's more
that
> they (well, I) think that it's an extremely bad idea that doesn't adher to
> the HTTP model.
>
> In particular, it would make the meaning of an HTTP method invocation
depend
> on previous method calls. That makes it hard or impossible for
> intermediaries to work with these messages.
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Pill, Juergen
> > Sent: Monday, September 09, 2002 4:17 PM
> > To: 'w3c-dist-auth@w3.org'
> > Subject: RE: Proposal: WebDAV and transactions
> >
> >
> >
> > Hello,
> >
> > I did not receive a lot of feed-back on the TA "proposal" (and the
> > statements were both positive and negative).
> >
> > Would you agree on the statement, the WebDAV group would be currently
not
> > interested in standardizing TA methods?
> >
> > As we would need this extension for the API implementation, our
> > option would
> > be to implement a proprietary WebDAV TA extension available on our
server
> > only.
> >
> > If the interest on this topic would raise again - possibly at a
> > later time -
> > we would be happy to share our experience with you.
> >
> > Best regards,
> >
> > Juergen Pill
> >
> >
> >
> >  -----Original Message-----
> > From: Pill, Juergen [mailto:Juergen.Pill@softwareag.com]
> > Sent: Monday, September 02, 2002 12.24 PM
> > To: 'w3c-dist-auth@w3.org'
> > Subject: Proposal: WebDAV and transactions
> >
> >
> > Hello,
> >
> > The current WebDAV specifications deal with a transactional support on a
> > method base only. Either a single WebDAV method is completely and
> > successfully executed, or the method is not executed at all (e.g. a
> > PropPatch command will either modify all requested properties or none of
> > them). A transactional support spanning multiple WebDAV methods
> > is currently
> > not specified.
> > Multi user requirements are either handled in separate workspaces
> > (Delta-V)
> > or via the Lock method.
> > During our discussion on the JSR 170 (Content Management API)
> > implementation
> > on top of WebDAV, we believe that we require longer transactions
spanning
> > multiple separate WebDAV methods. (This issue was already partially
> > discussed in the Batch method thread). Do you also fell the
> > need/requirement
> > to get a standard on the way, concerning a transactional WebDAV protocol
> > extension?
> >
> > A possible use case would be:
> > An author wants to modify an html page. To successfully do so, he will
PUT
> > the updated html page back, PROPPATCH and UNLOCK it, DELETE all bitmap
> > files, which are not references any more, and PUT (create) the newly
> > referenced bitmaps files. If he wants to ensure, that either all
> > his changes
> > do apply (or none of them) he would surround those method call with an
> > TA-BEGIN and a TA-COMMIT method call. If the author would be an API
(e.g.
> > JSR 170) exposing the TA functionality to an application, we believe
this
> > feature to be mandatory.
> >
> > A possible (starting) specification could be:
> > WebDAV defines 3 additional methods: TA-BEGIN, TA-COMMIT and TA-ABORT.
The
> > TA-BEGIN method will return a TA token (e.g. via an XML response
> > body). This
> > TA token will be send to the following WebDAV methods, which are part of
> > this transaction (e.g. via an additional header). The TA-COMMIT
> > or TA-ABORT
> > method will either commit or abort the transaction and invalidate the TA
> > token.
> > If and when an open TA, which is not used any more, is aborted, could be
> > controlled similar to the lock method timeout header.
> > All WebDAV methods, which either do not posses a TA token, or posses an
> > invalid token are handled as today (the method is executed within its
own
> > TA), this would ensure upward compatibility.
> > This extension would be optional, if a server supports the TA methods,
it
> > will state this in the OPTIONS request (similar to Delta-V).
> >
> >
> > Does this make sense?
> >
> > Best regards
> > Juergen Pill
> >
>
>



From w3c-dist-auth-request@w3.org  Wed Sep 11 03:34:09 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00382
	for <webdav-archive@lists.ietf.org>; Wed, 11 Sep 2002 03:34:08 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8B7YCi20088;
	Wed, 11 Sep 2002 03:34:12 -0400 (EDT)
Resent-Date: Wed, 11 Sep 2002 03:34:12 -0400 (EDT)
Resent-Message-Id: <200209110734.g8B7YCi20088@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8B7Y8U20068
	for <w3c-dist-auth@frink.w3.org>; Wed, 11 Sep 2002 03:34:08 -0400 (EDT)
Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA26941
	for <w3c-dist-auth@w3.org>; Wed, 11 Sep 2002 03:34:07 -0400
Received: from daehub01.software-ag.de by server8a.software-ag.de; (8.11.6/8.9.3)
	id g8B7XqA04501; Wed, 11 Sep 2002 09:33:53 +0200
Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2650.21)
	id <SSA8LDKQ>; Wed, 11 Sep 2002 09:33:42 +0200
Message-ID: <DFF2AC9E3583D511A21F0008C7E62106031F2B50@daemsg02.software-ag.de>
From: "Pill, Juergen" <Juergen.Pill@softwareag.com>
To: "'Jim Whitehead'" <ejw@cse.ucsc.edu>, WebDAV <w3c-dist-auth@w3.org>
Cc: "'khangnt@sat.com.vn'" <khangnt@sat.com.vn>
Date: Wed, 11 Sep 2002 09:33:41 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C25965.8D088530"
Subject: RE: best webDAV implementation
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6595
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>


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

------_=_NextPart_001_01C25965.8D088530
Content-Type: text/plain;
	charset="iso-8859-1"

Hello Khang,
 
Are you aware of Slide ( http://jakarta.apache.org/slide/index.html
<http://jakarta.apache.org/slide/index.html> ) or mod_dav (
http://www.webdav.org/mod_dav/ <http://www.webdav.org/mod_dav/> ). You will
find additional infos on servers at www.webdav.org <http://www.webdav.org/>
.
 
 
Best regards,
 
Juergen
 
 
 
 
 
-----Original Message-----
From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]
Sent: Tuesday, September 10, 2002 20.31 PM
To: WebDAV
Subject: FW: best webDAV implementation
 
Accidentally caught by the spam filter.
 
- Jim
-----Original Message-----
From: Nguyen Tuan Khang [mailto:khangnt@sat.com.vn]
Sent: Tuesday, September 10, 2002 3:22 AM
To: w3c-dist-auth@w3.org
Subject: [Moderator Action] best webDAV implementation
hi,
 
I have to select webDAV implementation for my project with Websphere. I
found DAV4J but the problem is that this project was released in 2000 (2
years ago) and it used xml4j version 2.0. Now the xml4j comes with version
4.0 with a lot of improvements and deprecates so that DAV4J could not run
with updated xml4j releases (around 4.0 version).
 
Is there anyone who uses DAV4J to help me? 
or could you recommend me which webDAV implementation is good, and try to
help me with the best one for websphere.
 
thank you
regards
Khang
PS: I am not in the list, please include my address in the reply addresses
 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C25976.50AEEF50">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle15
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:36.0pt;
	mso-footer-margin:36.0pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1027"/>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1"/>
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>H=
ello
Khang,<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>A=
re you
aware of Slide (<a =
href=3D"http://jakarta.apache.org/slide/index.html">http://jakarta.apach=
e.org/slide/index.html</a>)
or mod_dav (</span></font></span><span class=3DEmailStyle15><font =
size=3D2
color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;
font-family:Arial;color:windowtext'><a =
href=3D"http://www.webdav.org/mod_dav/">http://www.webdav.org/mod_dav/</=
a></span></font></span><span
class=3DEmailStyle15><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>). You will find =
additional
infos on servers at </span></font></span><span =
class=3DEmailStyle15><font size=3D2
color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;
font-family:Arial;color:windowtext'><a =
href=3D"http://www.webdav.org/">www.webdav.org</a></span></font></span><=
span
class=3DEmailStyle15><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>.</span></font></spa=
n><span
class=3DEmailStyle15><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:navy;mso-color-=
alt:
windowtext'><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if !supportEmptyParas]>&nbsp;<![endif]></span></font></span><span
class=3DEmailStyle15><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:navy;mso-color-=
alt:
windowtext'><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if !supportEmptyParas]>&nbsp;<![endif]></span></font></span><span
class=3DEmailStyle15><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:navy;mso-color-=
alt:
windowtext'><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>B=
est
regards,</span></font></span><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial;color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font></sp=
an></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if !supportEmptyParas]>&nbsp;<![endif]></span></font></span><span
class=3DEmailStyle15><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:navy;mso-color-=
alt:
windowtext'><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>J=
uergen</span></font></span><span
class=3DEmailStyle15><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:navy;mso-color-=
alt:
windowtext'><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if !supportEmptyParas]>&nbsp;<![endif]></span></font></span><span
class=3DEmailStyle15><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:navy;mso-color-=
alt:
windowtext'><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if !supportEmptyParas]>&nbsp;<![endif]></span></font></span><span
class=3DEmailStyle15><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:navy;mso-color-=
alt:
windowtext'><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblack
face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Jim Whitehead
[mailto:ejw@cse.ucsc.edu]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, September =
10, 2002
20.31 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> WebDAV<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> FW: best webDAV
implementation</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblue
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Accidentally
caught by the spam filter.</span></font><font color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblue
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>- =
Jim</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:
12.0pt;margin-left:36.0pt'><font size=3D2 color=3Dblack =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Nguyen Tuan Khang
[mailto:khangnt@sat.com.vn]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, September =
10, 2002
3:22 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
w3c-dist-auth@w3.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [Moderator =
Action] best
webDAV implementation</span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:black'>hi,</span></fon=
t><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:black'>I have
to select webDAV implementation for my project with Websphere. I found =
DAV4J
but the problem is that this project was released in 2000 (2 years ago)
and&nbsp;it used xml4j version 2.0. Now the xml4j comes&nbsp;with =
version 4.0
with a lot of improvements and deprecates&nbsp;so that&nbsp;DAV4J could =
not run
with updated xml4j releases (around 4.0 version).</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:black'>Is
there anyone who uses DAV4J to help me? </span></font><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:black'>or&nbsp;could
you recommend me which webDAV implementation is good, and try to help =
me with
the best one for websphere.</span></font><font size=3D2 color=3Dblack =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:black;mso-color-alt:wi=
ndowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:black'>thank
you</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:black'>regards</span><=
/font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:black'>Khang</span></f=
ont><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:black'>PS: I
am not in the list, please include my address in the reply =
addresses</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

</div>

</body>

</html>

------_=_NextPart_001_01C25965.8D088530--



From w3c-dist-auth-request@w3.org  Wed Sep 11 06:02:58 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02890
	for <webdav-archive@lists.ietf.org>; Wed, 11 Sep 2002 06:02:58 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8BA2gI04177;
	Wed, 11 Sep 2002 06:02:42 -0400 (EDT)
Resent-Date: Wed, 11 Sep 2002 06:02:42 -0400 (EDT)
Resent-Message-Id: <200209111002.g8BA2gI04177@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8BA2eU04157
	for <w3c-dist-auth@frink.w3.org>; Wed, 11 Sep 2002 06:02:40 -0400 (EDT)
Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA15238
	for <w3c-dist-auth@w3.org>; Wed, 11 Sep 2002 06:02:39 -0400
Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) 
          by dire.bris.ac.uk with SMTP-PRIV with ESMTP;
          Wed, 11 Sep 2002 11:02:33 +0100
Received: from onokahi.cs.bris.ac.uk (onokahi [137.222.107.161])	by cs.bris.ac.uk (8.9.3/8.9.3) 
          with ESMTP id LAA05661;	Wed, 11 Sep 2002 11:01:53 +0100 (BST)
Received: from cs.bris.ac.uk by onokahi.cs.bris.ac.uk (8.9.3) id LAA09690;
          Wed, 11 Sep 2002 11:01:52 +0100 (BST)
Message-ID: <3D7F1490.30490D76@cs.bris.ac.uk>
Date: Wed, 11 Sep 2002 11:01:52 +0100
From: "B. Shadgar" <shadgar@cs.bris.ac.uk>
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Sedlar <eric.sedlar@oracle.com>, w3c-dist-auth@w3.org
References: <C3AF5E329E21D2119C4C00805F6FF58F08FE5E40@hq-expo2.filenet.com> <001301c25958$5aa2d490$9b114498@esedlar>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6596
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>
Content-Transfer-Encoding: 7bit


Eric Sedlar wrote:

> I think it is clear that the best way to address this requirement is through
> batching up WebDAV METHODS into a single request.  We also have requirements
> for doing batch methods for other reasons, and I know Microsoft has also run
> into this requirement and extended the standard this way.
>
> --Eric
>

I think Batch method can help a lot in favor of transactions, But I don't know
why still it has not been accepted as a standard method in WebDAV protocol ?

Bita,



From w3c-dist-auth-request@w3.org  Wed Sep 11 06:08:08 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02990
	for <webdav-archive@lists.ietf.org>; Wed, 11 Sep 2002 06:08:07 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8BA8kM06547;
	Wed, 11 Sep 2002 06:08:46 -0400 (EDT)
Resent-Date: Wed, 11 Sep 2002 06:08:46 -0400 (EDT)
Resent-Message-Id: <200209111008.g8BA8kM06547@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8BA8jU06527
	for <w3c-dist-auth@frink.w3.org>; Wed, 11 Sep 2002 06:08:45 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id GAA16936
	for <w3c-dist-auth@w3.org>; Wed, 11 Sep 2002 06:08:44 -0400
Received: (qmail 5702 invoked by uid 0); 11 Sep 2002 10:08:13 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp016-rz3) with SMTP; 11 Sep 2002 10:08:13 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "B. Shadgar" <shadgar@cs.bris.ac.uk>,
        "Eric Sedlar" <eric.sedlar@oracle.com>, <w3c-dist-auth@w3.org>
Date: Wed, 11 Sep 2002 12:08:13 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCEEDPFFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-reply-to: <3D7F1490.30490D76@cs.bris.ac.uk>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6597
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>
Content-Transfer-Encoding: 7bit


> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of B. Shadgar
> Sent: Wednesday, September 11, 2002 12:02 PM
> To: Eric Sedlar; w3c-dist-auth@w3.org
> Subject: Re: Proposal: WebDAV and transactions
> 
> ...
> 
> I think Batch method can help a lot in favor of transactions, But 
> I don't know
> why still it has not been accepted as a standard method in WebDAV 
> protocol ?

Well, make a proposal that works and let the discussion start.

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



From w3c-dist-auth-request@w3.org  Wed Sep 11 08:13:35 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05629
	for <webdav-archive@lists.ietf.org>; Wed, 11 Sep 2002 08:13:35 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8BCE9L19304;
	Wed, 11 Sep 2002 08:14:09 -0400 (EDT)
Resent-Date: Wed, 11 Sep 2002 08:14:09 -0400 (EDT)
Resent-Message-Id: <200209111214.g8BCE9L19304@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8BCE0U19280
	for <w3c-dist-auth@frink.w3.org>; Wed, 11 Sep 2002 08:14:00 -0400 (EDT)
Received: from 140.wakasoft.com (bsl-rtr.day.com [212.249.34.130])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA04008
	for <w3c-dist-auth@w3.org>; Wed, 11 Sep 2002 08:14:00 -0400
Received: from 140.catv78.balcab.ch (localhost [127.0.0.1])
	by 140.wakasoft.com (8.12.4/8.12.4) with ESMTP id g8BCDXnW010334;
	Wed, 11 Sep 2002 05:13:33 -0700 (PDT)
Date: Wed, 11 Sep 2002 14:13:33 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: "Babich, Alan" <ABabich@filenet.com>,
        "'Julian Reschke'" <julian.reschke@gmx.de>,
        "Pill, Juergen" <Juergen.Pill@softwareag.com>, <w3c-dist-auth@w3.org>
To: "Eric Sedlar" <eric.sedlar@oracle.com>
From: "Roy T. Fielding" <fielding@apache.org>
In-Reply-To: <001301c25958$5aa2d490$9b114498@esedlar>
Message-Id: <E3F8C744-C57F-11D6-8502-000393753936@apache.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.482)
Subject: Re: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6598
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>
Content-Transfer-Encoding: 7bit


> I think it is clear that the best way to address this requirement is 
> through
> batching up WebDAV METHODS into a single request.  We also have 
> requirements
> for doing batch methods for other reasons, and I know Microsoft has also 
> run
> into this requirement and extended the standard this way.

I don't think that is clear at all.  Batching methods does nothing to
help with transactions that cannot be accomplished just as easily
(and without breaking HTTP security) by including a transaction identifier
in each request.  Changing the packaging of a sequence of interrelated
requests does not change the fact that they are a sequence of interrelated
requests.  Eventually, something has to process those requests in sequence,
as a transaction.  The server simply needs a way to accumulate requests
and a method to commit them, and therefore it makes sense to have methods
for begin-, abort-, and commit-transaction.

>> If the gun refuses to shoot you in the
>> foot, that is a better design for the gun.

In that case, a gun that is incapable of shooting at all would be
a "better" design.  Considering requirements in isolation is a waste
of energy.

>> In the spirit of that analogy, I
>> am proposing that the entire transaction, conditional processing and all,
>> should be invoked by one method call. That would do a lot to help protect
>> the performance of the system.

It would do nothing to help protect the performance of the system.
There is no effective difference between a sequence of requests with
time-outs per request and a batch request with time-outs per read.
The server still has to accumulate requests in storage and is
subject to the same service problems with stateful behavior.

The Web already has stored procedures.  There is nothing preventing an
application developer from building complex transactions within a
single method handler.  The problem is when you allow multiple methods
with differing semantics to take place under the rubric of another
method, which removes HTTP's ability to govern access rights per method.

....Roy



From w3c-dist-auth-request@w3.org  Wed Sep 11 08:40:12 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06467
	for <webdav-archive@lists.ietf.org>; Wed, 11 Sep 2002 08:40:12 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8BCepp21707;
	Wed, 11 Sep 2002 08:40:51 -0400 (EDT)
Resent-Date: Wed, 11 Sep 2002 08:40:51 -0400 (EDT)
Resent-Message-Id: <200209111240.g8BCepp21707@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8BCelU21661
	for <w3c-dist-auth@frink.w3.org>; Wed, 11 Sep 2002 08:40:47 -0400 (EDT)
Received: from dirf.bris.ac.uk (dirf.bris.ac.uk [137.222.10.72])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA07797
	for <w3c-dist-auth@w3.org>; Wed, 11 Sep 2002 08:40:47 -0400
Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) 
          by dirf.bris.ac.uk with SMTP-PRIV with ESMTP;
          Wed, 11 Sep 2002 13:40:38 +0100
Received: from onokahi.cs.bris.ac.uk (onokahi [137.222.107.161]) 
          by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id NAA25032;
          Wed, 11 Sep 2002 13:39:55 +0100 (BST)
Received: from cs.bris.ac.uk by onokahi.cs.bris.ac.uk (8.9.3) id NAA09917;
          Wed, 11 Sep 2002 13:39:55 +0100 (BST)
Message-ID: <3D7F399A.26D38B7E@cs.bris.ac.uk>
Date: Wed, 11 Sep 2002 13:39:54 +0100
From: "B. Shadgar" <shadgar@cs.bris.ac.uk>
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>, w3c-dist-auth@w3.org
References: <JIEGINCHMLABHJBIGKBCEEDPFFAA.julian.reschke@gmx.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6599
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>
Content-Transfer-Encoding: 7bit


Julian Reschke wrote:

> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of B. Shadgar
> > Sent: Wednesday, September 11, 2002 12:02 PM
> > To: Eric Sedlar; w3c-dist-auth@w3.org
> > Subject: Re: Proposal: WebDAV and transactions
> >
> > ...
> >
> > I think Batch method can help a lot in favor of transactions, But
> > I don't know
> > why still it has not been accepted as a standard method in WebDAV
> > protocol ?
>
> Well, make a proposal that works and let the discussion start.
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

A proposal for Batch method is following:

Batch Method

The Batch method is introduce to processes a bunch of methods as one
single transaction and to improve the overload of internet connection.

The request message body of a BATCH method MUST contain one-transaction
and  request-set XML elements. It is included by one or more request XML
elements. processing of request elements MUST occur in the order request
elements are received (i.e., from top to bottom). Request elements can
either all be executed or some executed which will be specified by value
of one-transaction element. If the  value is true, all of request
elements MUST be executed, thus if any error occurs during processing
all executed  requests MUST be undone and resopnse MUST return the
result of failed request. Otherwise, when the one-transaction element's
value is false, some of requests can be executed and a proper response
with 207 statuse code  MUST be prepared to shows which requested has
been done and why the others refused.

The request XML element is included by header, body and
expected-status-code elements. Header and body element contains the
header and body of given request and expected-status-code is
representing the result is expected. It can be expressed by one value or
a range of values e.g  200 <= X < 300 by xml elements.

I consider Pill's example in his proposal and try to make my mean clear:

>> Request

BATCH  /bar/  HTTP/1.1
Host: www.foo.bar
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx


<?xml version="1.0" encoding="utf-8" ?>
<D:request-set xmlns:D="DAV:">
   <D:one-transaction>true</D:one-transaction>
   <D:request>
      <D:header> The header of PUTmethod  </D:header>
      <D:body> the Body of PUT method </D:body>
      <D:expected-status-code> <or>
                                                    <li>204</li>
                                                    <li>201</li>
                                                 </or>
      </D:expected-status-code>
   </D:request>
   <D:request>
      <D:header> The header of PROPPATCH method  </D:header>
      <D:body> the Body of PROPPATCH method </D:body>
      <D:expected-status-code> 200 </D:expected-status-code>
   </D:request>
   <D:request>
      <D:header> The header of UNLOCK method  </D:header>
      <D:body> the Body of UNLOCK method </D:body>
      <D:expected-status-code>204</D:expected-status-code>
   </D:request>
   <D:request>
      <D:header> The header of Delete method  </D:header>
      <D:body> the Body of Delete method </D:body>
      <D:expected-status-code> 204</D:expected-status-code>
   </D:request>
 </D:request-set>

>> Respons

HTTP/1.1  200 Ok

or

>> Response


HTTP/1.1 403 Forbidden
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

    <?xml version="1.0" encoding="utf-8" ?>
    <D:response>
       <D:method>
               <D:status>HTTP/1.1 204 No Content </D:status>
       </D:method>
       <D:method>
               <D:status>HTTP/1.1 200 Ok</D:status>
       </D:method>
       <D:method>
                 <D:status>HTTP/1.1 204 No Content </D:status>
        </D:method>
       <D:method>
                  <D:href>http://www.foo.bar/bar/resource3>
                  <D:status>HTTP/1.1 403 Forbidden</D:status>
       </D:method>
     </D:response>


We can consider a bunch of delete methods when the one-transaction
element was false. In this case the format of the request and response
is the same, but the one-transaction element is set with false value,
and therefore failing some of Delete method dosn't cause to undone the
batch method. The response can inform the client which delete methods
are failed.

Does it make sence?

Regards,
Bita.




From w3c-dist-auth-request@w3.org  Wed Sep 11 09:21:58 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08521
	for <webdav-archive@lists.ietf.org>; Wed, 11 Sep 2002 09:21:58 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8BDM0t26819;
	Wed, 11 Sep 2002 09:22:00 -0400 (EDT)
Resent-Date: Wed, 11 Sep 2002 09:22:00 -0400 (EDT)
Resent-Message-Id: <200209111322.g8BDM0t26819@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8BDLuU26759
	for <w3c-dist-auth@frink.w3.org>; Wed, 11 Sep 2002 09:21:56 -0400 (EDT)
Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA17570
	for <w3c-dist-auth@w3.org>; Wed, 11 Sep 2002 09:21:56 -0400
Received: from daehub01.software-ag.de by server8a.software-ag.de; (8.11.6/8.9.3)
	id g8BDLcA00512; Wed, 11 Sep 2002 15:21:38 +0200
Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2650.21)
	id <SSA8LMZL>; Wed, 11 Sep 2002 15:21:27 +0200
Message-ID: <DFF2AC9E3583D511A21F0008C7E62106031F2B59@daemsg02.software-ag.de>
From: "Pill, Juergen" <Juergen.Pill@softwareag.com>
To: "'B. Shadgar'" <shadgar@cs.bris.ac.uk>,
        Julian Reschke
	 <julian.reschke@gmx.de>, w3c-dist-auth@w3.org
Date: Wed, 11 Sep 2002 15:21:26 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6600
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>


Hello,

I would like to suggest to open a new Thread for the "Batch method"
discussion or use the already started one. 

A batch method would solve the API problem situation only partly. If the API
could send all TA containing commands (without having to take decision based
on response codes or response body content), the batch method would work.
For a general purpose TA aware API I would not like to assume this.

The TA methods and the Batch methods could be seen as orthogonal features.
If the BATCH method is executed outside a TA_BEGIN, TA_COMMIT bracket, all
nested methods within the BATCH operation are executed in auto-commit mode
(each command is executed complete or not at all, some may executed with
success, some may return response error codes). If the BATCH method is
executed within a TA bracket, the BATCH method (and ALL nested contained
methods)  is due to the TA boundaries and all send methods (batch, including
the nested methods and the methods send parallel to BATCH) are either
committed or aborted.
If all methods within the batch method should be executed within a single
TA, following coding within the batch method would be required:
- open a TA (e.g. TA_BEGIN or MKTransaction)
- specify the all nested commands, e.g. PUT, DELETE, etc.
- close the TA (e.g. TA_END or Delete <ta_resource_uri>)

Both functionalities (BATCH and TA) have their distinct advantages and
computing power. A BATCH method would not solve all of the TA requirements.
TA methods would not completely solve the BATCH requirements.

Do you agree or doesn't this make sense at all?

Best regards,

Juergen






 -----Original Message-----
From: 	B. Shadgar [mailto:shadgar@cs.bris.ac.uk] 
Sent:	Wednesday, September 11, 2002 14.40 PM
To:	Julian Reschke; w3c-dist-auth@w3.org
Subject:	Re: Proposal: WebDAV and transactions


Julian Reschke wrote:

> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of B. Shadgar
> > Sent: Wednesday, September 11, 2002 12:02 PM
> > To: Eric Sedlar; w3c-dist-auth@w3.org
> > Subject: Re: Proposal: WebDAV and transactions
> >
> > ...
> >
> > I think Batch method can help a lot in favor of transactions, But
> > I don't know
> > why still it has not been accepted as a standard method in WebDAV
> > protocol ?
>
> Well, make a proposal that works and let the discussion start.
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

A proposal for Batch method is following:

Batch Method

The Batch method is introduce to processes a bunch of methods as one
single transaction and to improve the overload of internet connection.

The request message body of a BATCH method MUST contain one-transaction
and  request-set XML elements. It is included by one or more request XML
elements. processing of request elements MUST occur in the order request
elements are received (i.e., from top to bottom). Request elements can
either all be executed or some executed which will be specified by value
of one-transaction element. If the  value is true, all of request
elements MUST be executed, thus if any error occurs during processing
all executed  requests MUST be undone and resopnse MUST return the
result of failed request. Otherwise, when the one-transaction element's
value is false, some of requests can be executed and a proper response
with 207 statuse code  MUST be prepared to shows which requested has
been done and why the others refused.

The request XML element is included by header, body and
expected-status-code elements. Header and body element contains the
header and body of given request and expected-status-code is
representing the result is expected. It can be expressed by one value or
a range of values e.g  200 <= X < 300 by xml elements.

I consider Pill's example in his proposal and try to make my mean clear:

>> Request

BATCH  /bar/  HTTP/1.1
Host: www.foo.bar
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx


<?xml version="1.0" encoding="utf-8" ?>
<D:request-set xmlns:D="DAV:">
   <D:one-transaction>true</D:one-transaction>
   <D:request>
      <D:header> The header of PUTmethod  </D:header>
      <D:body> the Body of PUT method </D:body>
      <D:expected-status-code> <or>
                                                    <li>204</li>
                                                    <li>201</li>
                                                 </or>
      </D:expected-status-code>
   </D:request>
   <D:request>
      <D:header> The header of PROPPATCH method  </D:header>
      <D:body> the Body of PROPPATCH method </D:body>
      <D:expected-status-code> 200 </D:expected-status-code>
   </D:request>
   <D:request>
      <D:header> The header of UNLOCK method  </D:header>
      <D:body> the Body of UNLOCK method </D:body>
      <D:expected-status-code>204</D:expected-status-code>
   </D:request>
   <D:request>
      <D:header> The header of Delete method  </D:header>
      <D:body> the Body of Delete method </D:body>
      <D:expected-status-code> 204</D:expected-status-code>
   </D:request>
 </D:request-set>

>> Respons

HTTP/1.1  200 Ok

or

>> Response


HTTP/1.1 403 Forbidden
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

    <?xml version="1.0" encoding="utf-8" ?>
    <D:response>
       <D:method>
               <D:status>HTTP/1.1 204 No Content </D:status>
       </D:method>
       <D:method>
               <D:status>HTTP/1.1 200 Ok</D:status>
       </D:method>
       <D:method>
                 <D:status>HTTP/1.1 204 No Content </D:status>
        </D:method>
       <D:method>
                  <D:href>http://www.foo.bar/bar/resource3>
                  <D:status>HTTP/1.1 403 Forbidden</D:status>
       </D:method>
     </D:response>


We can consider a bunch of delete methods when the one-transaction
element was false. In this case the format of the request and response
is the same, but the one-transaction element is set with false value,
and therefore failing some of Delete method dosn't cause to undone the
batch method. The response can inform the client which delete methods
are failed.

Does it make sence?

Regards,
Bita.



From w3c-dist-auth-request@w3.org  Wed Sep 11 09:22:14 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08543
	for <webdav-archive@lists.ietf.org>; Wed, 11 Sep 2002 09:22:13 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8BDMpi27064;
	Wed, 11 Sep 2002 09:22:51 -0400 (EDT)
Resent-Date: Wed, 11 Sep 2002 09:22:51 -0400 (EDT)
Resent-Message-Id: <200209111322.g8BDMpi27064@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8BDMoU27044
	for <w3c-dist-auth@frink.w3.org>; Wed, 11 Sep 2002 09:22:50 -0400 (EDT)
Received: from dirf.bris.ac.uk (dirf.bris.ac.uk [137.222.10.72])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA17952
	for <w3c-dist-auth@w3.org>; Wed, 11 Sep 2002 09:22:51 -0400
Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) 
          by dirf.bris.ac.uk with SMTP-PRIV with ESMTP;
          Wed, 11 Sep 2002 14:22:38 +0100
Received: from onokahi.cs.bris.ac.uk (onokahi [137.222.107.161]) 
          by cs.bris.ac.uk (8.9.3/8.9.3) with ESMTP id OAA00154;
          Wed, 11 Sep 2002 14:20:41 +0100 (BST)
Received: from cs.bris.ac.uk by onokahi.cs.bris.ac.uk (8.9.3) id OAA09974;
          Wed, 11 Sep 2002 14:20:41 +0100 (BST)
Message-ID: <3D7F4328.BF837AD7@cs.bris.ac.uk>
Date: Wed, 11 Sep 2002 14:20:40 +0100
From: "B. Shadgar" <shadgar@cs.bris.ac.uk>
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Roy T. Fielding" <fielding@apache.org>, w3c-dist-auth@w3.org
References: <E3F8C744-C57F-11D6-8502-000393753936@apache.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6601
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>
Content-Transfer-Encoding: 7bit


"Roy T. Fielding" wrote:

> > I think it is clear that the best way to address this requirement is
> > through
> > batching up WebDAV METHODS into a single request.  We also have
> > requirements
> > for doing batch methods for other reasons, and I know Microsoft has also
> > run
> > into this requirement and extended the standard this way.
>
> I don't think that is clear at all.  Batching methods does nothing to
> help with transactions that cannot be accomplished just as easily
> (and without breaking HTTP security) by including a transaction identifier
> in each request.  Changing the packaging of a sequence of interrelated
> requests does not change the fact that they are a sequence of interrelated
> requests.  Eventually, something has to process those requests in sequence,
> as a transaction.  The server simply needs a way to accumulate requests
> and a method to commit them, and therefore it makes sense to have methods
> for begin-, abort-, and commit-transaction.

If you consider the proposal of batch method I have already sent to mailing
list, and if you consider that server would have the following schema of
handling a given method:

try {
     TA.begin();
     XXX Method();
    TA.commit();
} catch ( Exception e) {
    TA.rollback()
}

The whole of batch method would be considered as a one transaction without
having TA-methods like begin, abort and commit. For each request in the Batch
method we just simply call the corresponding method which is not a separate
transaction.

>
>
> >> If the gun refuses to shoot you in the
> >> foot, that is a better design for the gun.
>
> In that case, a gun that is incapable of shooting at all would be
> a "better" design.  Considering requirements in isolation is a waste
> of energy.

I agree with this. Every body can make its choice to shoot or not.

>
>
> >> In the spirit of that analogy, I
> >> am proposing that the entire transaction, conditional processing and all,
> >> should be invoked by one method call. That would do a lot to help protect
> >> the performance of the system.
>
> It would do nothing to help protect the performance of the system.
> There is no effective difference between a sequence of requests with
> time-outs per request and a batch request with time-outs per read.
> The server still has to accumulate requests in storage and is
> subject to the same service problems with stateful behavior.
>
> The Web already has stored procedures.  There is nothing preventing an
> application developer from building complex transactions within a
> single method handler.  The problem is when you allow multiple methods
> with differing semantics to take place under the rubric of another
> method, which removes HTTP's ability to govern access rights per method.
>
> ....Roy

Although I think that Batch method can help regarding the transactions, but it
is not enough. Because, it can only handle a transaction which made by a
sequence of WebDAV methods. However it is not the whole problem of
transactions.
Consider an application which is using WebDAV protocol as a part of it work and
it needs to do some other functionality along with the WebDAV methods as  one
transaction. In this case my proposal of batch method doesn't help that
application. It would necessary need to TA-methods or change the server code to
provide its own function. The latter one is an anathema.

If I am wrong please make me correct.

Regards
Bita.



From w3c-dist-auth-request@w3.org  Wed Sep 11 09:42:58 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09339
	for <webdav-archive@lists.ietf.org>; Wed, 11 Sep 2002 09:42:58 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8BDgQL00237;
	Wed, 11 Sep 2002 09:42:26 -0400 (EDT)
Resent-Date: Wed, 11 Sep 2002 09:42:26 -0400 (EDT)
Resent-Message-Id: <200209111342.g8BDgQL00237@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8BDgPU00212
	for <w3c-dist-auth@frink.w3.org>; Wed, 11 Sep 2002 09:42:25 -0400 (EDT)
Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA22750
	for <w3c-dist-auth@w3.org>; Wed, 11 Sep 2002 09:42:24 -0400
Received: from daehub01.software-ag.de by server8a.software-ag.de; (8.11.6/8.9.3)
	id g8BDg4A07361; Wed, 11 Sep 2002 15:42:04 +0200
Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2650.21)
	id <SSA8LN88>; Wed, 11 Sep 2002 15:41:53 +0200
Message-ID: <DFF2AC9E3583D511A21F0008C7E62106031F2B5D@daemsg02.software-ag.de>
From: "Pill, Juergen" <Juergen.Pill@softwareag.com>
To: "'B. Shadgar'" <shadgar@cs.bris.ac.uk>,
        "Roy T. Fielding"
	 <fielding@apache.org>, w3c-dist-auth@w3.org
Date: Wed, 11 Sep 2002 15:41:52 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6602
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>


Hello Bita,

Although I think that Batch method can help regarding the transactions, but
it
is not enough. Because, it can only handle a transaction which made by a
sequence of WebDAV methods. However it is not the whole problem of
transactions.
Consider an application which is using WebDAV protocol as a part of it work
and
it needs to do some other functionality along with the WebDAV methods as
one
transaction. In this case my proposal of batch method doesn't help that
application. It would necessary need to TA-methods or change the server code
to
provide its own function. The latter one is an anathema.

Do I understand you right, that you think of a scenario, in which the
application wants to access/modify data from a (or multiple) WebDAV server
and from one (or many) TA aware different data sources (.e.g. an SQL
database) AND have that access/modification wrapped in a single TA.

In this case a two-phase commit protocol (and a Transaction Monitor) would
be required, assuming WebDAV supports TA (in the 2 phase commit flavor) and
all other associated DBs and datastores would support the 2PC protocol too.

We do not have this 2PC requirement, and I believe this could be an
extension to the proposed TA requirement. (at a minimum the TA_PREPARE
method needs to be supplied). Possible we could go two steps to reach this
2PC target.

Best regards,

Juergen



 -----Original Message-----
From: 	B. Shadgar [mailto:shadgar@cs.bris.ac.uk] 
Sent:	Wednesday, September 11, 2002 15.21 PM
To:	Roy T. Fielding; w3c-dist-auth@w3.org
Subject:	Re: Proposal: WebDAV and transactions


"Roy T. Fielding" wrote:

> > I think it is clear that the best way to address this requirement is
> > through
> > batching up WebDAV METHODS into a single request.  We also have
> > requirements
> > for doing batch methods for other reasons, and I know Microsoft has also
> > run
> > into this requirement and extended the standard this way.
>
> I don't think that is clear at all.  Batching methods does nothing to
> help with transactions that cannot be accomplished just as easily
> (and without breaking HTTP security) by including a transaction identifier
> in each request.  Changing the packaging of a sequence of interrelated
> requests does not change the fact that they are a sequence of interrelated
> requests.  Eventually, something has to process those requests in
sequence,
> as a transaction.  The server simply needs a way to accumulate requests
> and a method to commit them, and therefore it makes sense to have methods
> for begin-, abort-, and commit-transaction.

If you consider the proposal of batch method I have already sent to mailing
list, and if you consider that server would have the following schema of
handling a given method:

try {
     TA.begin();
     XXX Method();
    TA.commit();
} catch ( Exception e) {
    TA.rollback()
}

The whole of batch method would be considered as a one transaction without
having TA-methods like begin, abort and commit. For each request in the
Batch
method we just simply call the corresponding method which is not a separate
transaction.

>
>
> >> If the gun refuses to shoot you in the
> >> foot, that is a better design for the gun.
>
> In that case, a gun that is incapable of shooting at all would be
> a "better" design.  Considering requirements in isolation is a waste
> of energy.

I agree with this. Every body can make its choice to shoot or not.

>
>
> >> In the spirit of that analogy, I
> >> am proposing that the entire transaction, conditional processing and
all,
> >> should be invoked by one method call. That would do a lot to help
protect
> >> the performance of the system.
>
> It would do nothing to help protect the performance of the system.
> There is no effective difference between a sequence of requests with
> time-outs per request and a batch request with time-outs per read.
> The server still has to accumulate requests in storage and is
> subject to the same service problems with stateful behavior.
>
> The Web already has stored procedures.  There is nothing preventing an
> application developer from building complex transactions within a
> single method handler.  The problem is when you allow multiple methods
> with differing semantics to take place under the rubric of another
> method, which removes HTTP's ability to govern access rights per method.
>
> ....Roy

Although I think that Batch method can help regarding the transactions, but
it
is not enough. Because, it can only handle a transaction which made by a
sequence of WebDAV methods. However it is not the whole problem of
transactions.
Consider an application which is using WebDAV protocol as a part of it work
and
it needs to do some other functionality along with the WebDAV methods as
one
transaction. In this case my proposal of batch method doesn't help that
application. It would necessary need to TA-methods or change the server code
to
provide its own function. The latter one is an anathema.

If I am wrong please make me correct.

Regards
Bita.



From w3c-dist-auth-request@w3.org  Wed Sep 11 12:22:06 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14846
	for <webdav-archive@lists.ietf.org>; Wed, 11 Sep 2002 12:22:06 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8BGMGP18551;
	Wed, 11 Sep 2002 12:22:16 -0400 (EDT)
Resent-Date: Wed, 11 Sep 2002 12:22:16 -0400 (EDT)
Resent-Message-Id: <200209111622.g8BGMGP18551@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8BGMEI18531
	for <w3c-dist-auth@frink.w3.org>; Wed, 11 Sep 2002 12:22:14 -0400 (EDT)
Received: from 140.wakasoft.com (bsl-rtr.day.com [212.249.34.130])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA26507
	for <w3c-dist-auth@w3.org>; Wed, 11 Sep 2002 12:22:14 -0400
Received: from 140.catv78.balcab.ch (localhost [127.0.0.1])
	by 140.wakasoft.com (8.12.4/8.12.4) with ESMTP id g8BGM4nW011562;
	Wed, 11 Sep 2002 09:22:04 -0700 (PDT)
Date: Wed, 11 Sep 2002 18:22:03 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: w3c-dist-auth@w3.org
To: "B. Shadgar" <shadgar@cs.bris.ac.uk>
From: "Roy T. Fielding" <fielding@apache.org>
In-Reply-To: <3D7F399A.26D38B7E@cs.bris.ac.uk>
Message-Id: <9B958940-C5A2-11D6-8502-000393753936@apache.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.482)
Subject: Re: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6603
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>
Content-Transfer-Encoding: 7bit


I'll try to explain.  It is fundamental to HTTP that intermediaries
are able to inspect the method of an HTTP request in order to determine
the semantics of a request, and thereby its associated access control
and/or authentication requirements.  What you are suggesting is that
we bypass that feature in HTTP via a new syntax that tunnels arbitrary
methods within XML via HTTP, effectively bypassing all of the benefits
of using HTTP in the first place.

Sound familiar? It should, since this is the same objection that I have
frequently given to the use of SOAP for tunneling arbitrary semantics
though an HTTP POST method.

Transactions can be accomplished by using a request to ask the server
for a transaction context, possibly multi-level, and then sending
the sequence of requests with a calculated transaction-request-id
in the header fields, to each the server responds with 202 Accepted
or an error, and finalized with a commit or abort method, to which
the server responds with the appropriate message for the entire
commit.  Such a transaction mechanism accomplishes the same thing
without violating the requirements of HTTP.

In any case, this is OUT OF SCOPE for WebDAV.  It is an HTTP issue
that is not specific to authoring and will not be solved by an
authoring-specific solution.

....Roy



From w3c-dist-auth-request@w3.org  Wed Sep 11 13:27:46 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17708
	for <webdav-archive@lists.ietf.org>; Wed, 11 Sep 2002 13:27:45 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8BHSc826406;
	Wed, 11 Sep 2002 13:28:38 -0400 (EDT)
Resent-Date: Wed, 11 Sep 2002 13:28:38 -0400 (EDT)
Resent-Message-Id: <200209111728.g8BHSc826406@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8BHSZI26382
	for <w3c-dist-auth@frink.w3.org>; Wed, 11 Sep 2002 13:28:35 -0400 (EDT)
Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA07695
	for <w3c-dist-auth@w3.org>; Wed, 11 Sep 2002 13:28:35 -0400
Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) 
          by dire.bris.ac.uk with SMTP-PRIV with ESMTP;
          Wed, 11 Sep 2002 18:28:33 +0100
Received: from onokahi.cs.bris.ac.uk (onokahi [137.222.107.161])	by cs.bris.ac.uk (8.9.3/8.9.3) 
          with ESMTP id SAA00614	for <w3c-dist-auth@w3.org.>;
          Wed, 11 Sep 2002 18:26:51 +0100 (BST)
Received: from cs.bris.ac.uk by onokahi.cs.bris.ac.uk (8.9.3) id SAA10322;
          Wed, 11 Sep 2002 18:26:51 +0100 (BST)
Message-ID: <3D7F7CDA.E326CBD2@cs.bris.ac.uk>
Date: Wed, 11 Sep 2002 18:26:50 +0100
From: "B. Shadgar" <shadgar@cs.bris.ac.uk>
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Proposal: WebDAV and transaction
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6604
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>
Content-Transfer-Encoding: 7bit


"Roy T. Fielding" wrote:

> I'll try to explain.  It is fundamental to HTTP that intermediaries
> are able to inspect the method of an HTTP request in order to
determine
> the semantics of a request, and thereby its associated access control
> and/or authentication requirements.  What you are suggesting is that
> we bypass that feature in HTTP via a new syntax that tunnels arbitrary

> methods within XML via HTTP, effectively bypassing all of the benefits

> of using HTTP in the first place.
>
> Sound familiar? It should, since this is the same objection that I
have
> frequently given to the use of SOAP for tunneling arbitrary semantics
> though an HTTP POST method.
>
> Transactions can be accomplished by using a request to ask the server
> for a transaction context, possibly multi-level, and then sending
> the sequence of requests with a calculated transaction-request-id
> in the header fields, to each the server responds with 202 Accepted
> or an error, and finalized with a commit or abort method, to which
> the server responds with the appropriate message for the entire
> commit.  Such a transaction mechanism accomplishes the same thing
> without violating the requirements of HTTP.

Thanks for your explanation. You have open a new view to me. But I
am thinking is this way stateless or not?

Regards,

Bita



From w3c-dist-auth-request@w3.org  Wed Sep 11 17:04:32 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24693
	for <webdav-archive@lists.ietf.org>; Wed, 11 Sep 2002 17:04:31 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8BL4fA28172;
	Wed, 11 Sep 2002 17:04:41 -0400 (EDT)
Resent-Date: Wed, 11 Sep 2002 17:04:41 -0400 (EDT)
Resent-Message-Id: <200209112104.g8BL4fA28172@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8BL4dI28152
	for <w3c-dist-auth@frink.w3.org>; Wed, 11 Sep 2002 17:04:39 -0400 (EDT)
Received: from hq-exgw1.filenet.com (Filenet-gw.filenet.com [198.3.8.1])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA20465
	for <w3c-dist-auth@w3.org>; Wed, 11 Sep 2002 17:04:38 -0400
Received: by cm-exgw1.filenet.com with Internet Mail Service (5.5.2653.19)
	id <SW9DLJN4>; Wed, 11 Sep 2002 14:04:07 -0700
Message-ID: <C3AF5E329E21D2119C4C00805F6FF58F08FE5E58@hq-expo2.filenet.com>
From: "Babich, Alan" <ABabich@filenet.com>
To: "'Roy T. Fielding'" <fielding@apache.org>, w3c-dist-auth@w3.org
Date: Wed, 11 Sep 2002 14:04:06 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6605
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>




-----Original Message-----
From: Roy T. Fielding [mailto:fielding@apache.org] 
Sent: Wednesday, September 11, 2002 5:14 AM
To: Eric Sedlar
Cc: Babich, Alan; 'Julian Reschke'; Pill, Juergen; w3c-dist-auth@w3.org
Subject: Re: Proposal: WebDAV and transactions

...snip...

>> In the spirit of that analogy, I
>> am proposing that the entire transaction, conditional processing and all,
>> should be invoked by one method call. That would do a lot to help protect
>> the performance of the system.

It would do nothing to help protect the performance of the system.
There is no effective difference between a sequence of requests with
time-outs per request and a batch request with time-outs per read.
The server still has to accumulate requests in storage and is
subject to the same service problems with stateful behavior.

...snip...

....Roy

That's completely false. 

Last first. The only way to eliminate state on the server that must be
maintained between method calls ("stateful behavior") is to do the entire
transaction during one method call. Period.

Going over the network multiple times for multiple method calls clearly
consumes more computing resources and elapsed time than making a single
method call. There is more overhead on the client (which doesn't matter) and
the server (which matters a lot). That's really obvious.

But where client application programmers can really kill the performance of
the entire system is by introducing the possibility of user think time into
the middle of a transaction. That is only possible when the transaction can
consist of multiple method calls: 

Between the method calls, the resources changed have to be locked on the
server. (Otherwise, you wouldn't have a transaction, because it would have
the ACID properties.) If a resource that is needed is locked by another
concurrent transaction, your transaction has to wait. If you wait, you have
to worry about waiting forever. DBMS's typically solve that problem by doing
deadlock analysis and picking a transaction to abort and rollback, if
necessary. The method call can not return until the waiting, if any, is
finished. Some remote systems don't do deadlock analysis -- they time out.
Timing out has a terrible impact on performance if it happens more than
rarely.

Let me give you a real life example that actually happened to me. I was
checking in at the gate on a flight and requesting a seat assignment. The
attendant pulled up a screen showing the availability of the kind of seat I
wanted. In the few seconds during which he said "Yes, we can satisfy your
request" and I said "OK, do it", the seat disappeared, and he had to say,
"Sorry, the assignment failed, try again.". The reason that happened is that
there were two complete transactions involved, not one. The first
transaction was a retrieval of the seat availability of the entire plane.
The second was the update transaction. In between the transactions, another
transaction got in there. 

If you provide the ability to do the retrieval as the first part of the
transaction (i.e., as a method call), all the seats on the airplane will
have to stay locked while I make up my mind. Then throughput would be so
terrible that it would be unacceptable. No one else in the country could get
a seat assignment on that plane while I was deciding what to do. 

Unfortunately, I know from plenty of personal experience that that is
exactly the way most client application programmers will initially try to
program it. Programming it that way will allow them to "shoot themselves in
the foot". Not allowing that (by requiring that transactions be a single
method call) will prevent the performance disaster (as well as eliminate
stateful behavior on the server).

In any case, it is completely false that there is no performance difference.

Alan Babich



From w3c-dist-auth-request@w3.org  Wed Sep 11 19:24:36 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28326
	for <webdav-archive@lists.ietf.org>; Wed, 11 Sep 2002 19:24:36 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8BNPLY13710;
	Wed, 11 Sep 2002 19:25:21 -0400 (EDT)
Resent-Date: Wed, 11 Sep 2002 19:25:21 -0400 (EDT)
Resent-Message-Id: <200209112325.g8BNPLY13710@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8BNPJI13689
	for <w3c-dist-auth@frink.w3.org>; Wed, 11 Sep 2002 19:25:19 -0400 (EDT)
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA11695
	for <w3c-dist-auth@w3.org>; Wed, 11 Sep 2002 19:25:18 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8BNOkIV221226;
	Wed, 11 Sep 2002 19:24:46 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77])
	by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8BNOhkn081308;
	Wed, 11 Sep 2002 19:24:44 -0400
To: willcoty@leavenworth.army.mil, "WebDAV" <w3c-dist-auth@w3.org>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF0DE2D98F.B69DE723-ON85256C30.0070DBA0@us.ibm.com>
From: Jason Crawford <ccjason@us.ibm.com>
Date: Wed, 11 Sep 2002 19:21:34 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_09042002A|September 04, 2002) at
 09/11/2002 19:24:43
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: Re: FW: [Moderator Action] WEBDAV client on mainframe
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6606
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>


                                                                                                               
                                                                                                               
                                                                                                               


Yvonne,

I don't know what software you data source has on it's mainframe.  If java,
then there are Java libraries that implement WebDAV.

If all else fails and they have HTTP libraries, they can probably do an
HTTP PUT to place the files on your server.

J.

------------------------------------------
Phone: 914-784-7569



From w3c-dist-auth-request@w3.org  Wed Sep 11 21:06:50 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29922
	for <webdav-archive@lists.ietf.org>; Wed, 11 Sep 2002 21:06:50 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8C13qI22906;
	Wed, 11 Sep 2002 21:03:52 -0400 (EDT)
Resent-Date: Wed, 11 Sep 2002 21:03:52 -0400 (EDT)
Resent-Message-Id: <200209120103.g8C13qI22906@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8C13oI22875
	for <w3c-dist-auth@frink.w3.org>; Wed, 11 Sep 2002 21:03:50 -0400 (EDT)
Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA23400
	for <w3c-dist-auth@w3.org>; Wed, 11 Sep 2002 21:03:50 -0400
Received: from inet-mail3.oracle.com (localhost [127.0.0.1])
	by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8C13FP03440
	for <w3c-dist-auth@w3.org>; Wed, 11 Sep 2002 18:03:15 -0700 (PDT)
Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14])
	by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8C13ER03426
	for <w3c-dist-auth@w3.org>; Wed, 11 Sep 2002 18:03:14 -0700 (PDT)
Received: from rgmum4.us.oracle.com (rgmum4.us.oracle.com [138.1.191.25])
	by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8C13Er09870
	for <w3c-dist-auth@w3.org>; Wed, 11 Sep 2002 19:03:14 -0600 (MDT)
Received: from dhcp-4op7-4op8-east-130-35-171-81.us.oracle.com by rgmum1.us.oracle.com
	with ESMTP id 61761811031792583; Wed, 11 Sep 2002 19:03:03 -0600
Message-ID: <000001c259f7$80099120$51ab2382@us.oracle.com>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: <w3c-dist-auth@w3.org>
References: <3906C56A7BD1F54593344C05BD1374B1078391FE@SUS-MA1IT01>
Date: Thu, 5 Sep 2002 14:46:56 -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: Interoperability for DAV:ishidden?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6607
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>
Content-Transfer-Encoding: 7bit


> I still don't see your objection to Julian's original proposal,
> i.e. if your server can (or is willing to) allow a client to operate
> directly on the resource identified by the DAV:resourceid, then it
> just makes the value of DAV:resourceid be in the HTTP: namespace.
>

How does an interoperable client know that it can do this?  Are you going to
allow an optional <href> tag in DAV:resourceid so that the client can know
to do this?  This just puts the burden on the client writer.

> There is value in a DAV:resourceid, even if it isn't something a
> client can use to directly operate on the resource, so I don't believe
> it is reasonable to require that the value of DAV:resourceid be in the
HTTP
> namespace.
>

What do you feel is unreasonable?  Finding some obscure part of the HTTP
namespace on a server to map to?  Handling requests with resource-ids?  It
seems to me that this makes resourceid simpler for simple repositories that
may not have GUIDs available, as they can just use the resource's URL if
they don't allow multiple bindings to a resource.

--Eric




From w3c-dist-auth-request@w3.org  Thu Sep 12 03:37:02 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15349
	for <webdav-archive@lists.ietf.org>; Thu, 12 Sep 2002 03:37:02 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8C7aab05260;
	Thu, 12 Sep 2002 03:36:36 -0400 (EDT)
Resent-Date: Thu, 12 Sep 2002 03:36:36 -0400 (EDT)
Resent-Message-Id: <200209120736.g8C7aab05260@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8C7aYI05236
	for <w3c-dist-auth@frink.w3.org>; Thu, 12 Sep 2002 03:36:34 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA08716
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 03:36:33 -0400
Received: (qmail 11148 invoked by uid 0); 12 Sep 2002 07:36:02 -0000
Received: from pd950c397.dip.t-dialin.net (HELO lisa) (217.80.195.151)
  by mail.gmx.net (mp013-rz3) with SMTP; 12 Sep 2002 07:36:02 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Eric Sedlar" <eric.sedlar@oracle.com>, <w3c-dist-auth@w3.org>
Date: Thu, 12 Sep 2002 09:36:01 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCMEFMFFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <000001c259f7$80099120$51ab2382@us.oracle.com>
Importance: Normal
Subject: DAV:resourceid
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6608
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>
Content-Transfer-Encoding: 7bit


(subject updated)

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> Sent: Thursday, September 05, 2002 11:47 PM
> To: w3c-dist-auth@w3.org
> Subject: Re: Interoperability for DAV:ishidden?
>
>
>
> > I still don't see your objection to Julian's original proposal,
> > i.e. if your server can (or is willing to) allow a client to operate
> > directly on the resource identified by the DAV:resourceid, then it
> > just makes the value of DAV:resourceid be in the HTTP: namespace.
> >
>
> How does an interoperable client know that it can do this?  Are

It parses the URI and determines whether it's a HTTP: or HTTPS: URL.

> you going to
> allow an optional <href> tag in DAV:resourceid so that the client can know
> to do this?  This just puts the burden on the client writer.

According to the expired bindings draft, DAV:resourceid happens to have the
DAV:href format anyway ([1]).

> > There is value in a DAV:resourceid, even if it isn't something a
> > client can use to directly operate on the resource, so I don't believe
> > it is reasonable to require that the value of DAV:resourceid be in the
> HTTP
> > namespace.
> >
>
> What do you feel is unreasonable?  Finding some obscure part of the HTTP
> namespace on a server to map to?  Handling requests with resource-ids?  It

For instance, you might want to assign resource identifiers that can travel
between servers. Using the HTTP scheme would make this impossible.

> seems to me that this makes resourceid simpler for simple
> repositories that
> may not have GUIDs available, as they can just use the resource's URL if
> they don't allow multiple bindings to a resource.

No, they can't. For instance, the resourceid would change if the resource is
moved. This is not allowed.

Julian

[1]
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-binding-protocol-02.html
#rfc.section.13.2>

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



From w3c-dist-auth-request@w3.org  Thu Sep 12 05:19:41 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17405
	for <webdav-archive@lists.ietf.org>; Thu, 12 Sep 2002 05:19:41 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8C9Jo227398;
	Thu, 12 Sep 2002 05:19:50 -0400 (EDT)
Resent-Date: Thu, 12 Sep 2002 05:19:50 -0400 (EDT)
Resent-Message-Id: <200209120919.g8C9Jo227398@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8C9JmI27374
	for <w3c-dist-auth@frink.w3.org>; Thu, 12 Sep 2002 05:19:48 -0400 (EDT)
Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA25621
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 05:19:48 -0400
Received: from daehub01.software-ag.de by server8a.software-ag.de; (8.11.6/8.9.3)
	id g8C9JSA08506; Thu, 12 Sep 2002 11:19:28 +0200
Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2650.21)
	id <SSA8L7VN>; Thu, 12 Sep 2002 11:19:16 +0200
Message-ID: <DFF2AC9E3583D511A21F0008C7E62106031F2B67@daemsg02.software-ag.de>
From: "Pill, Juergen" <Juergen.Pill@softwareag.com>
To: "'Roy T. Fielding'" <fielding@apache.org>,
        "B. Shadgar"
	 <shadgar@cs.bris.ac.uk>
Cc: w3c-dist-auth@w3.org
Date: Thu, 12 Sep 2002 11:19:13 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6609
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>


Hello,

Yesterday I was made aware of the TIP protocol
(http://www.ietf.org/rfc/rfc2371.txt). It defines a 2PC TA protocol between
TMs (transaction managers) and requires the application to pass the TID
token to the resource manager (in our scenario the WebDAV server). [The
communication between the application and the resource manager (RM) is not
covered in the standard, except for the fact, that the TID token is passed).

I can see now 3 scenarios:

a) auto commit
The application is not TA aware and sends the WebDAV commands without any TA
commands or TA token. In this case the WebDAV server acts as today (every
request is executed in a single atomic TA). 
b) global TA
In this case multiple resource managers (e.g. multiple webdav server and/or
multiple other datasources) are involved on a single node or on multiple
nodes (with a single or multiple TM). In this case the application sends the
TA_BEGIN to the local TIP aware TM, receives a TID token, which is passed to
all participating RM at every request call. In case of WebDAV the place
could be a header (in case of e.g. PUT, the body is already reserved for
content). The WebDAV server (if the implementation is TIP aware) would
recognize the TID token and enlist at the local/global TM via the TIP
protocol. At the end of the TA the application would send the TA_Commit TIP
command to the local TM and the TM would initiate the 2PC execution to all
participating TM via the TIP protocol. 
c) local TA
In this scenario the application will talk to exactly one RM (the webdav
server) and possibly a full blown TM is not available. If the server would
implement both WebDAV and (at least the 1PC part of) the TIP protocol, the
TA_BEGIN could be send to the same server as all following WebDAV commands
followed by a TA_END command.

I can see following advantages going the TIP path:

The TIP protocol is already standardized, no need for WebDAV to introduced
something new (especially new methods). If WebDAV is used outside the TIP
protocol, performance and scalability stay identical to today's situation.
The decision if a WebDAV server is TIP aware will be driven by the specific
implementation. If a server supports scenario "c" only, would be
server-implementor defined too.
If we could agree on a specific header name to carry the TID token, all TIP
enabled WebDAV servers would be interoperable and could participate in a 2PC
environment. This header agreement would be the only WebDAV/HTTP extension
necessary.

The same would apply for http too. I agree with Roy, this feature is valid
in an http context too and specific to WebDAV. Would there be interest to
agree at this header for HTTP protocol?

Does this make sense?

Best regards,

Juergen



 -----Original Message-----
From: 	Roy T. Fielding [mailto:fielding@apache.org] 
Sent:	Wednesday, September 11, 2002 18.22 PM
To:	B. Shadgar
Cc:	w3c-dist-auth@w3.org
Subject:	Re: Proposal: WebDAV and transactions


I'll try to explain.  It is fundamental to HTTP that intermediaries
are able to inspect the method of an HTTP request in order to determine
the semantics of a request, and thereby its associated access control
and/or authentication requirements.  What you are suggesting is that
we bypass that feature in HTTP via a new syntax that tunnels arbitrary
methods within XML via HTTP, effectively bypassing all of the benefits
of using HTTP in the first place.

Sound familiar? It should, since this is the same objection that I have
frequently given to the use of SOAP for tunneling arbitrary semantics
though an HTTP POST method.

Transactions can be accomplished by using a request to ask the server
for a transaction context, possibly multi-level, and then sending
the sequence of requests with a calculated transaction-request-id
in the header fields, to each the server responds with 202 Accepted
or an error, and finalized with a commit or abort method, to which
the server responds with the appropriate message for the entire
commit.  Such a transaction mechanism accomplishes the same thing
without violating the requirements of HTTP.

In any case, this is OUT OF SCOPE for WebDAV.  It is an HTTP issue
that is not specific to authoring and will not be solved by an
authoring-specific solution.

....Roy



From w3c-dist-auth-request@w3.org  Thu Sep 12 09:39:38 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23138
	for <webdav-archive@lists.ietf.org>; Thu, 12 Sep 2002 09:39:38 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8CDcU726627;
	Thu, 12 Sep 2002 09:38:30 -0400 (EDT)
Resent-Date: Thu, 12 Sep 2002 09:38:30 -0400 (EDT)
Resent-Message-Id: <200209121338.g8CDcU726627@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8CDcSI26604
	for <w3c-dist-auth@frink.w3.org>; Thu, 12 Sep 2002 09:38:29 -0400 (EDT)
Received: from 140.wakasoft.com (bsl-rtr.day.com [212.249.34.130])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA23423
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 09:38:28 -0400
Received: from 140.catv78.balcab.ch (localhost [127.0.0.1])
	by 140.wakasoft.com (8.12.4/8.12.4) with ESMTP id g8CDYTnW011967;
	Thu, 12 Sep 2002 06:34:29 -0700 (PDT)
Date: Thu, 12 Sep 2002 15:34:29 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: w3c-dist-auth@w3.org
To: "B. Shadgar" <shadgar@cs.bris.ac.uk>
From: "Roy T. Fielding" <fielding@apache.org>
In-Reply-To: <3D7F7CDA.E326CBD2@cs.bris.ac.uk>
Message-Id: <5D0C9966-C654-11D6-A960-000393753936@apache.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.482)
Subject: Re: Proposal: WebDAV and transaction
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6610
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>
Content-Transfer-Encoding: 7bit


> Thanks for your explanation. You have open a new view to me. But I
> am thinking is this way stateless or not?

As stateless as possible given that we are talking about transactions.
Each request contains all of the information necessary to understand
that request, which is the only issue left given that a transaction
implies that the requests are stored for committal rather than applied
immediately.  In other words, it is just as stateless as one method
containing lots of requests.

....Roy



From w3c-dist-auth-request@w3.org  Thu Sep 12 10:06:08 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23967
	for <webdav-archive@lists.ietf.org>; Thu, 12 Sep 2002 10:06:07 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8CE31F01188;
	Thu, 12 Sep 2002 10:03:01 -0400 (EDT)
Resent-Date: Thu, 12 Sep 2002 10:03:01 -0400 (EDT)
Resent-Message-Id: <200209121403.g8CE31F01188@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8CE30I01168
	for <w3c-dist-auth@frink.w3.org>; Thu, 12 Sep 2002 10:03:00 -0400 (EDT)
Received: from 140.wakasoft.com (bsl-rtr.day.com [212.249.34.130])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA28476
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 10:02:59 -0400
Received: from 140.catv78.balcab.ch (localhost [127.0.0.1])
	by 140.wakasoft.com (8.12.4/8.12.4) with ESMTP id g8CE1NnW011969;
	Thu, 12 Sep 2002 07:01:23 -0700 (PDT)
Date: Thu, 12 Sep 2002 16:01:23 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: w3c-dist-auth@w3.org
To: "Babich, Alan" <ABabich@filenet.com>
From: "Roy T. Fielding" <fielding@apache.org>
In-Reply-To: <C3AF5E329E21D2119C4C00805F6FF58F08FE5E58@hq-expo2.filenet.com>
Message-Id: <1F223AE0-C658-11D6-A960-000393753936@apache.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.482)
Subject: Re: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6611
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>
Content-Transfer-Encoding: 7bit


>>> In the spirit of that analogy, I
>>> am proposing that the entire transaction, conditional processing and 
>>> all,
>>> should be invoked by one method call. That would do a lot to help 
>>> protect
>>> the performance of the system.
>
> It would do nothing to help protect the performance of the system.
> There is no effective difference between a sequence of requests with
> time-outs per request and a batch request with time-outs per read.
> The server still has to accumulate requests in storage and is
> subject to the same service problems with stateful behavior.
>
> ...snip...
>
> ....Roy
>
> That's completely false.

I suggest you learn how to write an HTTP server before making statements
like that.

> Last first. The only way to eliminate state on the server that must be
> maintained between method calls ("stateful behavior") is to do the entire
> transaction during one method call. Period.

That's specious.  The only difference between one method containing many
requests and one connection containing many methods is syntax and
the number of server responses on that connection.  In one case you
are building state because of HTTP methods and the other because of
XML methods.  The server responses are not in the critical path and
therefore do not impact performance other than giving the client
important information that might be useful to determining whether
it should abort the transaction.

> Going over the network multiple times for multiple method calls clearly
> consumes more computing resources and elapsed time than making a single
> method call. There is more overhead on the client (which doesn't matter) 
> and
> the server (which matters a lot). That's really obvious.

Pipelined requests make the difference irrelevant.  The overhead of
parsing XML far exceeds the overhead imposed by parsing multiple HTTP
requests.  And, yes, non-idempotent methods can be pipelined if they
are sent as part of the context of a transaction, since building a
transaction context is inherently safe.

> But where client application programmers can really kill the performance 
> of
> the entire system is by introducing the possibility of user think time 
> into
> the middle of a transaction. That is only possible when the transaction 
> can
> consist of multiple method calls.

Unless you have time-outs on the transaction, which is true of any
performance limited system.  The protocol represents a wire syntax.
If you think that merely packaging multiple requests into a single
request method will force clients to send all requests at once, then
you seriously underestimate the creativity of HTTP client developers.
At least with multiple methods the server has a chance to respond
appropriately in the middle of the stream of requests, rather than
having to special-case the in-body request timeout handler.

> Between the method calls, the resources changed have to be locked on the
> server.

That's not how I described transactions.  I said that the requests are
collected on the server and only applied when the commit message is
received.  If the state has changed such that the methods are no longer
applicable, then the method transaction will fail on commit.

....Roy



From w3c-dist-auth-request@w3.org  Thu Sep 12 15:06:42 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03944
	for <webdav-archive@lists.ietf.org>; Thu, 12 Sep 2002 15:06:42 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8CJ3ZK27559;
	Thu, 12 Sep 2002 15:03:35 -0400 (EDT)
Resent-Date: Thu, 12 Sep 2002 15:03:35 -0400 (EDT)
Resent-Message-Id: <200209121903.g8CJ3ZK27559@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8CJ3XI27534
	for <w3c-dist-auth@frink.w3.org>; Thu, 12 Sep 2002 15:03:33 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA07650
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 15:03:32 -0400
Received: (qmail 19630 invoked by uid 0); 12 Sep 2002 19:03:21 -0000
Received: from p3ee24710.dip.t-dialin.net (HELO lisa) (62.226.71.16)
  by mail.gmx.net (mp015-rz3) with SMTP; 12 Sep 2002 19:03:21 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: <w3c-dist-auth@w3.org>
Date: Thu, 12 Sep 2002 21:03:20 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCIEHIFFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <1F223AE0-C658-11D6-A960-000393753936@apache.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: can a non-HTTP URL be the target of a redirect (301/302)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6612
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>
Content-Transfer-Encoding: 7bit


Hi,

(hopefully catching Roy's attention...-)

RFC2616 says about the 302 response status [1]:

"The requested resource resides temporarily under a different URI. Since the
redirection might be altered on occasion, the client SHOULD continue to use
the Request-URI for future requests. This response is only cacheable if
indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response.
Unless the request method was HEAD, the entity of the response SHOULD
contain a short hypertext note with a hyperlink to the new URI(s).

If the 302 status code is received in response to a request other than GET
or HEAD, the user agent MUST NOT automatically redirect the request unless
it can be confirmed by the user, since this might change the conditions
under which the request was issued. "

...and about the Location header [2]:

"The Location response-header field is used to redirect the recipient to a
location other than the Request-URI for completion of the request or
identification of a new resource. For 201 (Created) responses, the Location
is that of the new resource which was created by the request. For 3xx
responses, the location SHOULD indicate the server's preferred URI for
automatic redirection to the resource. The field value consists of a single
absolute URI.

       Location       = "Location" ":" absoluteURI"


The question: are there any restrictions on what type or absoluteURI(s) are
allowed? For instance, is it legal to redirect to

a) mailto: URLs?

b) file: URLs?



Regards,

Julian




[1] <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.3.3>
[2] <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.30>


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




From w3c-dist-auth-request@w3.org  Thu Sep 12 15:14:43 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04246
	for <webdav-archive@lists.ietf.org>; Thu, 12 Sep 2002 15:14:43 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8CJBoH28797;
	Thu, 12 Sep 2002 15:11:50 -0400 (EDT)
Resent-Date: Thu, 12 Sep 2002 15:11:50 -0400 (EDT)
Resent-Message-Id: <200209121911.g8CJBoH28797@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8CJBoI28777
	for <w3c-dist-auth@frink.w3.org>; Thu, 12 Sep 2002 15:11:50 -0400 (EDT)
Received: from hq-exgw2.filenet.com (Filenet-gw.filenet.com [198.3.8.1])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA09483
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 15:11:48 -0400
Received: by hq-exgw2.filenet.com with Internet Mail Service (5.5.2653.19)
	id <SW9DT4GL>; Thu, 12 Sep 2002 12:11:03 -0700
Message-ID: <C3AF5E329E21D2119C4C00805F6FF58F08FE5E5B@hq-expo2.filenet.com>
From: "Babich, Alan" <ABabich@filenet.com>
To: "'Roy T. Fielding'" <fielding@apache.org>, w3c-dist-auth@w3.org
Date: Thu, 12 Sep 2002 12:11:18 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6613
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>




-----Original Message-----
From: Roy T. Fielding [mailto:fielding@apache.org] 
Sent: Thursday, September 12, 2002 7:01 AM
To: Babich, Alan
Cc: w3c-dist-auth@w3.org
Subject: Re: Proposal: WebDAV and transactions

...snip...

<Alan>
> Between the method calls, the resources changed have to be locked on the
> server.
</Alan>

<Roy>
That's not how I described transactions.  I said that the requests are
collected on the server and only applied when the commit message is
received.  If the state has changed such that the methods are no longer
applicable, then the method transaction will fail on commit. 
</Roy>

That directly addresses the central issue, and I managed to miss that
somehow. >>My whole point is that when the server actually executes the
transaction, the server should have everything and do the entire transaction
all at once -- retrievals, updates, and conditional processing included.<<
Sorry if I didn't make that clear.

If you want to dribble the instructions for the transaction over piece by
piece by making separate method calls until it all gets to the server,
without actually doing any updates or retrievals, that's not something that
I am concerned with much. It would be more efficient to just send over all
the stuff at once, but I don't think it's that big of a deal to send it over
in pieces. So, doing that is OK with me.

If you want the server to do some security checking and other processing on
the individual pieces as they arrive, before actually executing the entire
transaction in the commit step, that's fine. That would help the client
pinpoint a certain subset of the possible problems in each step of the
transaction.

                                 ---

I think it would be interesting to see how the conditional processing of the
methods is specified. How much generality is achievable without getting into
syntax that doesn't resemble the current methods at all? To make arbitrary
transactions convenient, you want "program" variables, conditional
"statements", iteration "statements", and "subroutines" with parameters. If
we don't go that far, perhaps a useful set of transactions could still be
specified.

I also think it would be interesting to see how the results of the
transaction are specified. Any part of it could fail.

Alan



From w3c-dist-auth-request@w3.org  Thu Sep 12 15:21:16 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04433
	for <webdav-archive@lists.ietf.org>; Thu, 12 Sep 2002 15:21:16 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8CJLUN29696;
	Thu, 12 Sep 2002 15:21:30 -0400 (EDT)
Resent-Date: Thu, 12 Sep 2002 15:21:30 -0400 (EDT)
Resent-Message-Id: <200209121921.g8CJLUN29696@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8CJLTI29672
	for <w3c-dist-auth@frink.w3.org>; Thu, 12 Sep 2002 15:21:30 -0400 (EDT)
Received: from exchimc.pcdocs.com ([208.255.196.152])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA11413
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 15:21:29 -0400
Received: by EXCHANGE_IMC with Internet Mail Service (5.5.2650.21)
	id <RNRB9P4B>; Thu, 12 Sep 2002 15:21:07 -0400
Message-ID: <39FB3B2B1509CE43A251C50896C9BA950141B737@tallyx1>
From: Gary Cowan <Gary.Cowan@Tally.Hummingbird.com>
To: "'Babich, Alan'" <ABabich@filenet.com>,
        "'Roy T. Fielding'"
	 <fielding@apache.org>, w3c-dist-auth@w3.org
Date: Thu, 12 Sep 2002 15:20:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6614
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>


At the risk of sounding naive, I cannot understand why anyone would want or
need transactions in a WebDAV session. 

-----Original Message-----
From: Babich, Alan [mailto:ABabich@filenet.com]
Sent: Thursday, September 12, 2002 3:11 PM
To: 'Roy T. Fielding'; w3c-dist-auth@w3.org
Subject: RE: Proposal: WebDAV and transactions





-----Original Message-----
From: Roy T. Fielding [mailto:fielding@apache.org] 
Sent: Thursday, September 12, 2002 7:01 AM
To: Babich, Alan
Cc: w3c-dist-auth@w3.org
Subject: Re: Proposal: WebDAV and transactions

...snip...

<Alan>
> Between the method calls, the resources changed have to be locked on the
> server.
</Alan>

<Roy>
That's not how I described transactions.  I said that the requests are
collected on the server and only applied when the commit message is
received.  If the state has changed such that the methods are no longer
applicable, then the method transaction will fail on commit. 
</Roy>

That directly addresses the central issue, and I managed to miss that
somehow. >>My whole point is that when the server actually executes the
transaction, the server should have everything and do the entire transaction
all at once -- retrievals, updates, and conditional processing included.<<
Sorry if I didn't make that clear.

If you want to dribble the instructions for the transaction over piece by
piece by making separate method calls until it all gets to the server,
without actually doing any updates or retrievals, that's not something that
I am concerned with much. It would be more efficient to just send over all
the stuff at once, but I don't think it's that big of a deal to send it over
in pieces. So, doing that is OK with me.

If you want the server to do some security checking and other processing on
the individual pieces as they arrive, before actually executing the entire
transaction in the commit step, that's fine. That would help the client
pinpoint a certain subset of the possible problems in each step of the
transaction.

                                 ---

I think it would be interesting to see how the conditional processing of the
methods is specified. How much generality is achievable without getting into
syntax that doesn't resemble the current methods at all? To make arbitrary
transactions convenient, you want "program" variables, conditional
"statements", iteration "statements", and "subroutines" with parameters. If
we don't go that far, perhaps a useful set of transactions could still be
specified.

I also think it would be interesting to see how the results of the
transaction are specified. Any part of it could fail.

Alan



From w3c-dist-auth-request@w3.org  Thu Sep 12 15:21:51 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04466
	for <webdav-archive@lists.ietf.org>; Thu, 12 Sep 2002 15:21:51 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8CJLkZ29918;
	Thu, 12 Sep 2002 15:21:46 -0400 (EDT)
Resent-Date: Thu, 12 Sep 2002 15:21:46 -0400 (EDT)
Resent-Message-Id: <200209121921.g8CJLkZ29918@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8CJLjI29898
	for <w3c-dist-auth@frink.w3.org>; Thu, 12 Sep 2002 15:21:45 -0400 (EDT)
Received: from cats.ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA11483
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 15:21:45 -0400
Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177])
	by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g8CJLSq00935;
	Thu, 12 Sep 2002 12:21:28 -0700 (PDT)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "Roy T. Fielding" <fielding@apache.org>
Cc: <w3c-dist-auth@w3.org>
Date: Thu, 12 Sep 2002 12:19:03 -0700
Message-ID: <AMEPKEBLDJJCCDEJHAMIOEPIFGAA.ejw@cse.ucsc.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <1F223AE0-C658-11D6-A960-000393753936@apache.org>
X-UCSC-CATS-MailScanner: Found to be clean
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6615
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>
Content-Transfer-Encoding: 7bit



> That's not how I described transactions.  I said that the requests are
> collected on the server and only applied when the commit message is
> received.  If the state has changed such that the methods are no longer
> applicable, then the method transaction will fail on commit.

IMO, this model would work.

- Jim



From w3c-dist-auth-request@w3.org  Thu Sep 12 15:26:22 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04719
	for <webdav-archive@lists.ietf.org>; Thu, 12 Sep 2002 15:26:22 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8CJQfB00622;
	Thu, 12 Sep 2002 15:26:41 -0400 (EDT)
Resent-Date: Thu, 12 Sep 2002 15:26:41 -0400 (EDT)
Resent-Message-Id: <200209121926.g8CJQfB00622@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8CJQeI00601
	for <w3c-dist-auth@frink.w3.org>; Thu, 12 Sep 2002 15:26:40 -0400 (EDT)
Received: from cats.ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA12579
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 15:26:39 -0400
Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177])
	by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g8CJQTq02072
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 12:26:29 -0700 (PDT)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: <w3c-dist-auth@w3.org>
Date: Thu, 12 Sep 2002 12:24:03 -0700
Message-ID: <AMEPKEBLDJJCCDEJHAMIGEPKFGAA.ejw@cse.ucsc.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <39FB3B2B1509CE43A251C50896C9BA950141B737@tallyx1>
X-UCSC-CATS-MailScanner: Found to be clean
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6616
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>
Content-Transfer-Encoding: 7bit


One common example is to be able to write a resource and its properties in a
single operation. You want this to be a transaction, so that the resource
doesn't get updates before the properties are written, and so that if the
properties cannot be written, the resource is reverted back to it's
pre-write state.

- Jim

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Gary Cowan
> Sent: Thursday, September 12, 2002 12:21 PM
> To: 'Babich, Alan'; 'Roy T. Fielding'; w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> At the risk of sounding naive, I cannot understand why anyone
> would want or
> need transactions in a WebDAV session.
>
> -----Original Message-----
> From: Babich, Alan [mailto:ABabich@filenet.com]
> Sent: Thursday, September 12, 2002 3:11 PM
> To: 'Roy T. Fielding'; w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
>
>
> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@apache.org]
> Sent: Thursday, September 12, 2002 7:01 AM
> To: Babich, Alan
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Proposal: WebDAV and transactions
>
> ...snip...
>
> <Alan>
> > Between the method calls, the resources changed have to be locked on the
> > server.
> </Alan>
>
> <Roy>
> That's not how I described transactions.  I said that the requests are
> collected on the server and only applied when the commit message is
> received.  If the state has changed such that the methods are no longer
> applicable, then the method transaction will fail on commit.
> </Roy>
>
> That directly addresses the central issue, and I managed to miss that
> somehow. >>My whole point is that when the server actually executes the
> transaction, the server should have everything and do the entire
> transaction
> all at once -- retrievals, updates, and conditional processing included.<<
> Sorry if I didn't make that clear.
>
> If you want to dribble the instructions for the transaction over piece by
> piece by making separate method calls until it all gets to the server,
> without actually doing any updates or retrievals, that's not
> something that
> I am concerned with much. It would be more efficient to just send over all
> the stuff at once, but I don't think it's that big of a deal to
> send it over
> in pieces. So, doing that is OK with me.
>
> If you want the server to do some security checking and other
> processing on
> the individual pieces as they arrive, before actually executing the entire
> transaction in the commit step, that's fine. That would help the client
> pinpoint a certain subset of the possible problems in each step of the
> transaction.
>
>                                  ---
>
> I think it would be interesting to see how the conditional
> processing of the
> methods is specified. How much generality is achievable without
> getting into
> syntax that doesn't resemble the current methods at all? To make arbitrary
> transactions convenient, you want "program" variables, conditional
> "statements", iteration "statements", and "subroutines" with
> parameters. If
> we don't go that far, perhaps a useful set of transactions could still be
> specified.
>
> I also think it would be interesting to see how the results of the
> transaction are specified. Any part of it could fail.
>
> Alan



From w3c-dist-auth-request@w3.org  Thu Sep 12 15:41:20 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05201
	for <webdav-archive@lists.ietf.org>; Thu, 12 Sep 2002 15:41:20 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8CJfti02162;
	Thu, 12 Sep 2002 15:41:55 -0400 (EDT)
Resent-Date: Thu, 12 Sep 2002 15:41:55 -0400 (EDT)
Resent-Message-Id: <200209121941.g8CJfti02162@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8CJfsI02054
	for <w3c-dist-auth@frink.w3.org>; Thu, 12 Sep 2002 15:41:54 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA15249
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 15:41:53 -0400
Received: (qmail 16099 invoked by uid 0); 12 Sep 2002 19:41:21 -0000
Received: from p3ee24710.dip.t-dialin.net (HELO lisa) (62.226.71.16)
  by mail.gmx.net (mp018-rz3) with SMTP; 12 Sep 2002 19:41:21 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Jim Whitehead" <ejw@cse.ucsc.edu>, <w3c-dist-auth@w3.org>
Date: Thu, 12 Sep 2002 21:41:20 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCMEHLFFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <AMEPKEBLDJJCCDEJHAMIGEPKFGAA.ejw@cse.ucsc.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6617
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>
Content-Transfer-Encoding: 7bit


> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead
> Sent: Thursday, September 12, 2002 9:24 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> One common example is to be able to write a resource and its
> properties in a
> single operation. You want this to be a transaction, so that the resource
> doesn't get updates before the properties are written, and so that if the
> properties cannot be written, the resource is reverted back to it's
> pre-write state.

That's an excellent example for a case where a LOCK (or a delta-V working
resource) is all you need, right?

It get's more interesting once you want to manipulate *several* related
resources.

Julian

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



From w3c-dist-auth-request@w3.org  Thu Sep 12 15:45:04 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05269
	for <webdav-archive@lists.ietf.org>; Thu, 12 Sep 2002 15:45:04 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8CJhIm02359;
	Thu, 12 Sep 2002 15:43:18 -0400 (EDT)
Resent-Date: Thu, 12 Sep 2002 15:43:18 -0400 (EDT)
Resent-Message-Id: <200209121943.g8CJhIm02359@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8CJhII02335
	for <w3c-dist-auth@frink.w3.org>; Thu, 12 Sep 2002 15:43:18 -0400 (EDT)
Received: from exchimc.pcdocs.com ([208.255.196.152])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA15420
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 15:43:17 -0400
Received: by EXCHANGE_IMC with Internet Mail Service (5.5.2650.21)
	id <RNRB9PVY>; Thu, 12 Sep 2002 15:42:56 -0400
Message-ID: <39FB3B2B1509CE43A251C50896C9BA950141B738@tallyx1>
From: Gary Cowan <Gary.Cowan@Tally.Hummingbird.com>
To: "'Jim Whitehead'" <ejw@cse.ucsc.edu>, w3c-dist-auth@w3.org
Date: Thu, 12 Sep 2002 15:42:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6618
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>


Well I suppose, but isn't this what wrapping updates with a Lock/Unlock pair
is intended to accomplish. I have nothing against transactions, I just don't
have any need for them spanning multiple WebDAV methods. Yet:)  

-----Original Message-----
From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]
Sent: Thursday, September 12, 2002 3:24 PM
To: w3c-dist-auth@w3.org
Subject: RE: Proposal: WebDAV and transactions



One common example is to be able to write a resource and its properties in a
single operation. You want this to be a transaction, so that the resource
doesn't get updates before the properties are written, and so that if the
properties cannot be written, the resource is reverted back to it's
pre-write state.

- Jim

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Gary Cowan
> Sent: Thursday, September 12, 2002 12:21 PM
> To: 'Babich, Alan'; 'Roy T. Fielding'; w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> At the risk of sounding naive, I cannot understand why anyone
> would want or
> need transactions in a WebDAV session.
>
> -----Original Message-----
> From: Babich, Alan [mailto:ABabich@filenet.com]
> Sent: Thursday, September 12, 2002 3:11 PM
> To: 'Roy T. Fielding'; w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
>
>
> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@apache.org]
> Sent: Thursday, September 12, 2002 7:01 AM
> To: Babich, Alan
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Proposal: WebDAV and transactions
>
> ...snip...
>
> <Alan>
> > Between the method calls, the resources changed have to be locked on the
> > server.
> </Alan>
>
> <Roy>
> That's not how I described transactions.  I said that the requests are
> collected on the server and only applied when the commit message is
> received.  If the state has changed such that the methods are no longer
> applicable, then the method transaction will fail on commit.
> </Roy>
>
> That directly addresses the central issue, and I managed to miss that
> somehow. >>My whole point is that when the server actually executes the
> transaction, the server should have everything and do the entire
> transaction
> all at once -- retrievals, updates, and conditional processing included.<<
> Sorry if I didn't make that clear.
>
> If you want to dribble the instructions for the transaction over piece by
> piece by making separate method calls until it all gets to the server,
> without actually doing any updates or retrievals, that's not
> something that
> I am concerned with much. It would be more efficient to just send over all
> the stuff at once, but I don't think it's that big of a deal to
> send it over
> in pieces. So, doing that is OK with me.
>
> If you want the server to do some security checking and other
> processing on
> the individual pieces as they arrive, before actually executing the entire
> transaction in the commit step, that's fine. That would help the client
> pinpoint a certain subset of the possible problems in each step of the
> transaction.
>
>                                  ---
>
> I think it would be interesting to see how the conditional
> processing of the
> methods is specified. How much generality is achievable without
> getting into
> syntax that doesn't resemble the current methods at all? To make arbitrary
> transactions convenient, you want "program" variables, conditional
> "statements", iteration "statements", and "subroutines" with
> parameters. If
> we don't go that far, perhaps a useful set of transactions could still be
> specified.
>
> I also think it would be interesting to see how the results of the
> transaction are specified. Any part of it could fail.
>
> Alan



From w3c-dist-auth-request@w3.org  Thu Sep 12 15:59:48 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05703
	for <webdav-archive@lists.ietf.org>; Thu, 12 Sep 2002 15:59:48 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8CK0O805282;
	Thu, 12 Sep 2002 16:00:24 -0400 (EDT)
Resent-Date: Thu, 12 Sep 2002 16:00:24 -0400 (EDT)
Resent-Message-Id: <200209122000.g8CK0O805282@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8CK0NI05262
	for <w3c-dist-auth@frink.w3.org>; Thu, 12 Sep 2002 16:00:23 -0400 (EDT)
Received: from cats.ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA18148
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 16:00:23 -0400
Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177])
	by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g8CK0Bq09434;
	Thu, 12 Sep 2002 13:00:11 -0700 (PDT)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "Gary Cowan" <Gary.Cowan@Tally.Hummingbird.com>, <w3c-dist-auth@w3.org>
Date: Thu, 12 Sep 2002 12:57:46 -0700
Message-ID: <AMEPKEBLDJJCCDEJHAMIGEPNFGAA.ejw@cse.ucsc.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <39FB3B2B1509CE43A251C50896C9BA950141B738@tallyx1>
X-UCSC-CATS-MailScanner: Found to be clean
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6619
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>
Content-Transfer-Encoding: 7bit


> Well I suppose, but isn't this what wrapping updates with a
> Lock/Unlock pair is intended to accomplish. I have nothing
> against transactions, I just don't have any need for them
> spanning multiple WebDAV methods. Yet:)

Lock/unlock doesn't give you rollback capability. Even though you're the
only person who can write to a resource during a lock, it still may be the
case that you're unable to complete the PROPPATCH part of a PUT/PROPPATCH
pair. The TCP connection may go down, the server may go down, you may be
exceeding your quota, etc.

Now, if the total number of use cases is relatively small, it probably makes
more sense to create new methods explicitly for these use cases, instead of
a general purpose transaction mechanism.

- Jim




From w3c-dist-auth-request@w3.org  Thu Sep 12 16:16:46 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06099
	for <webdav-archive@lists.ietf.org>; Thu, 12 Sep 2002 16:16:46 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8CKDnd09362;
	Thu, 12 Sep 2002 16:13:49 -0400 (EDT)
Resent-Date: Thu, 12 Sep 2002 16:13:49 -0400 (EDT)
Resent-Message-Id: <200209122013.g8CKDnd09362@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8CKDmI09342
	for <w3c-dist-auth@frink.w3.org>; Thu, 12 Sep 2002 16:13:48 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA21914
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 16:13:47 -0400
Received: (qmail 29923 invoked by uid 0); 12 Sep 2002 20:13:46 -0000
Received: from p3ee24710.dip.t-dialin.net (HELO lisa) (62.226.71.16)
  by mail.gmx.net (mp004-rz3) with SMTP; 12 Sep 2002 20:13:46 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Jim Whitehead" <ejw@cse.ucsc.edu>,
        "Gary Cowan" <Gary.Cowan@Tally.Hummingbird.com>,
        <w3c-dist-auth@w3.org>
Date: Thu, 12 Sep 2002 22:13:44 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCIEHNFFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <AMEPKEBLDJJCCDEJHAMIGEPNFGAA.ejw@cse.ucsc.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6620
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>
Content-Transfer-Encoding: 7bit


> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead
> Sent: Thursday, September 12, 2002 9:58 PM
> To: Gary Cowan; w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> > Well I suppose, but isn't this what wrapping updates with a
> > Lock/Unlock pair is intended to accomplish. I have nothing
> > against transactions, I just don't have any need for them
> > spanning multiple WebDAV methods. Yet:)
>
> Lock/unlock doesn't give you rollback capability. Even though you're the
> only person who can write to a resource during a lock, it still may be the
> case that you're unable to complete the PROPPATCH part of a PUT/PROPPATCH
> pair. The TCP connection may go down, the server may go down, you may be
> exceeding your quota, etc.

But a deltaV working resource does... So I'd claim that this *particular*
use case already has a good solution.

> ...

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



From w3c-dist-auth-request@w3.org  Thu Sep 12 16:20:15 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06274
	for <webdav-archive@lists.ietf.org>; Thu, 12 Sep 2002 16:20:15 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8CKKlR10757;
	Thu, 12 Sep 2002 16:20:47 -0400 (EDT)
Resent-Date: Thu, 12 Sep 2002 16:20:47 -0400 (EDT)
Resent-Message-Id: <200209122020.g8CKKlR10757@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8CKKkI10737
	for <w3c-dist-auth@frink.w3.org>; Thu, 12 Sep 2002 16:20:46 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA23652
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 16:20:46 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 12 Sep 2002 16:10:35 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <SWGM41FN>; Thu, 12 Sep 2002 16:20:09 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B107839222@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Thu, 12 Sep 2002 16:20:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6621
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>


The Lock/Unlock doesn't give you the "rollback" functionality 
(i.e. the client has to remember the old values, and live long
enough to restore them if the later updates fail).

But it would be interesting to investigate whether the
DeltaV CHECKOUT/CHECKIN/UNCHECKOUT protocol could give clients most
of the benefits of transactions (a non-versioning server would
only keep the most recently checked in "version" of a resource).
You would create an "activity" for a given transaction,
make your changes, and then CHECKIN the activity to commit 
all the changes, or UNCHECKOUT to roll them back.  

Cheers,
Geoff

-----Original Message-----
From: Gary Cowan [mailto:Gary.Cowan@Tally.Hummingbird.com]
Sent: Thursday, September 12, 2002 3:43 PM
To: 'Jim Whitehead'; w3c-dist-auth@w3.org
Subject: RE: Proposal: WebDAV and transactions



Well I suppose, but isn't this what wrapping updates with a Lock/Unlock pair
is intended to accomplish. I have nothing against transactions, I just don't
have any need for them spanning multiple WebDAV methods. Yet:)  

-----Original Message-----
From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]
Sent: Thursday, September 12, 2002 3:24 PM
To: w3c-dist-auth@w3.org
Subject: RE: Proposal: WebDAV and transactions



One common example is to be able to write a resource and its properties in a
single operation. You want this to be a transaction, so that the resource
doesn't get updates before the properties are written, and so that if the
properties cannot be written, the resource is reverted back to it's
pre-write state.

- Jim

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Gary Cowan
> Sent: Thursday, September 12, 2002 12:21 PM
> To: 'Babich, Alan'; 'Roy T. Fielding'; w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> At the risk of sounding naive, I cannot understand why anyone
> would want or
> need transactions in a WebDAV session.
>
> -----Original Message-----
> From: Babich, Alan [mailto:ABabich@filenet.com]
> Sent: Thursday, September 12, 2002 3:11 PM
> To: 'Roy T. Fielding'; w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
>
>
> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@apache.org]
> Sent: Thursday, September 12, 2002 7:01 AM
> To: Babich, Alan
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Proposal: WebDAV and transactions
>
> ...snip...
>
> <Alan>
> > Between the method calls, the resources changed have to be locked on the
> > server.
> </Alan>
>
> <Roy>
> That's not how I described transactions.  I said that the requests are
> collected on the server and only applied when the commit message is
> received.  If the state has changed such that the methods are no longer
> applicable, then the method transaction will fail on commit.
> </Roy>
>
> That directly addresses the central issue, and I managed to miss that
> somehow. >>My whole point is that when the server actually executes the
> transaction, the server should have everything and do the entire
> transaction
> all at once -- retrievals, updates, and conditional processing included.<<
> Sorry if I didn't make that clear.
>
> If you want to dribble the instructions for the transaction over piece by
> piece by making separate method calls until it all gets to the server,
> without actually doing any updates or retrievals, that's not
> something that
> I am concerned with much. It would be more efficient to just send over all
> the stuff at once, but I don't think it's that big of a deal to
> send it over
> in pieces. So, doing that is OK with me.
>
> If you want the server to do some security checking and other
> processing on
> the individual pieces as they arrive, before actually executing the entire
> transaction in the commit step, that's fine. That would help the client
> pinpoint a certain subset of the possible problems in each step of the
> transaction.
>
>                                  ---
>
> I think it would be interesting to see how the conditional
> processing of the
> methods is specified. How much generality is achievable without
> getting into
> syntax that doesn't resemble the current methods at all? To make arbitrary
> transactions convenient, you want "program" variables, conditional
> "statements", iteration "statements", and "subroutines" with
> parameters. If
> we don't go that far, perhaps a useful set of transactions could still be
> specified.
>
> I also think it would be interesting to see how the results of the
> transaction are specified. Any part of it could fail.
>
> Alan



From w3c-dist-auth-request@w3.org  Thu Sep 12 17:01:04 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08086
	for <webdav-archive@lists.ietf.org>; Thu, 12 Sep 2002 17:01:04 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8CL1dd16218;
	Thu, 12 Sep 2002 17:01:39 -0400 (EDT)
Resent-Date: Thu, 12 Sep 2002 17:01:39 -0400 (EDT)
Resent-Message-Id: <200209122101.g8CL1dd16218@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8CL1bI16194
	for <w3c-dist-auth@frink.w3.org>; Thu, 12 Sep 2002 17:01:37 -0400 (EDT)
Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA31906
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 17:01:37 -0400
Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27])
	by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id g8CL0gh13899
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 14:00:42 -0700 (PDT)
Message-ID: <3D81007A.7060908@cse.ucsc.edu>
Date: Thu, 12 Sep 2002 14:00:42 -0700
From: Elias Sinderson <elias@cse.ucsc.edu>
Reply-To: elias@cse.ucsc.edu
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.4.1) Gecko/20020518 Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <39FB3B2B1509CE43A251C50896C9BA950141B737@tallyx1>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6622
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>
Content-Transfer-Encoding: 7bit


Updating multiple, mutually-dependant resources (related portions of a 
web site, for example) is a reasonable use case that would benefit from 
transactions.

Elias

Gary Cowan wrote:

>At the risk of sounding naive, I cannot understand why anyone would want or
>need transactions in a WebDAV session. 
>




From w3c-dist-auth-request@w3.org  Thu Sep 12 17:29:14 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08574
	for <webdav-archive@lists.ietf.org>; Thu, 12 Sep 2002 17:29:13 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8CLS8j19604;
	Thu, 12 Sep 2002 17:28:08 -0400 (EDT)
Resent-Date: Thu, 12 Sep 2002 17:28:08 -0400 (EDT)
Resent-Message-Id: <200209122128.g8CLS8j19604@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8CLS7I19584
	for <w3c-dist-auth@frink.w3.org>; Thu, 12 Sep 2002 17:28:07 -0400 (EDT)
Received: from tomts22-srv.bellnexxia.net (tomts22.bellnexxia.net [209.226.175.184])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA04116
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 17:28:06 -0400
Received: from Sridhar22 ([199.243.162.74]) by tomts22-srv.bellnexxia.net
          (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP
          id <20020912212804.EGRC15700.tomts22-srv.bellnexxia.net@Sridhar22>;
          Thu, 12 Sep 2002 17:28:04 -0400
From: "Sridhar Erukulla" <serukulla@bytequest.com>
To: "Clemm, Geoff" <gclemm@rational.com>, <w3c-dist-auth@w3.org>
Date: Thu, 12 Sep 2002 17:26:47 -0400
Message-ID: <AGEMIJDDKAJMEMCGGMPJIEIGCCAA.serukulla@bytequest.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B107839222@SUS-MA1IT01>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6623
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>
Content-Transfer-Encoding: 7bit



Naive questions:

What if the old values can't be assigned to some/all of the filed
transaction?

What would an another client see if they query for these properties while
performing the alternative method for a transaction? the old or the new
values? Here the new values should be visible only after all the requests in
the batch are completed, is this something easy to implement?

Sridhar
-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
Sent: September 12, 2002 4:20 PM
To: w3c-dist-auth@w3.org
Subject: RE: Proposal: WebDAV and transactions



The Lock/Unlock doesn't give you the "rollback" functionality
(i.e. the client has to remember the old values, and live long
enough to restore them if the later updates fail).

But it would be interesting to investigate whether the
DeltaV CHECKOUT/CHECKIN/UNCHECKOUT protocol could give clients most
of the benefits of transactions (a non-versioning server would
only keep the most recently checked in "version" of a resource).
You would create an "activity" for a given transaction,
make your changes, and then CHECKIN the activity to commit
all the changes, or UNCHECKOUT to roll them back.

Cheers,
Geoff

-----Original Message-----
From: Gary Cowan [mailto:Gary.Cowan@Tally.Hummingbird.com]
Sent: Thursday, September 12, 2002 3:43 PM
To: 'Jim Whitehead'; w3c-dist-auth@w3.org
Subject: RE: Proposal: WebDAV and transactions



Well I suppose, but isn't this what wrapping updates with a Lock/Unlock pair
is intended to accomplish. I have nothing against transactions, I just don't
have any need for them spanning multiple WebDAV methods. Yet:)

-----Original Message-----
From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]
Sent: Thursday, September 12, 2002 3:24 PM
To: w3c-dist-auth@w3.org
Subject: RE: Proposal: WebDAV and transactions



One common example is to be able to write a resource and its properties in a
single operation. You want this to be a transaction, so that the resource
doesn't get updates before the properties are written, and so that if the
properties cannot be written, the resource is reverted back to it's
pre-write state.

- Jim

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Gary Cowan
> Sent: Thursday, September 12, 2002 12:21 PM
> To: 'Babich, Alan'; 'Roy T. Fielding'; w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> At the risk of sounding naive, I cannot understand why anyone
> would want or
> need transactions in a WebDAV session.
>
> -----Original Message-----
> From: Babich, Alan [mailto:ABabich@filenet.com]
> Sent: Thursday, September 12, 2002 3:11 PM
> To: 'Roy T. Fielding'; w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
>
>
> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@apache.org]
> Sent: Thursday, September 12, 2002 7:01 AM
> To: Babich, Alan
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Proposal: WebDAV and transactions
>
> ...snip...
>
> <Alan>
> > Between the method calls, the resources changed have to be locked on the
> > server.
> </Alan>
>
> <Roy>
> That's not how I described transactions.  I said that the requests are
> collected on the server and only applied when the commit message is
> received.  If the state has changed such that the methods are no longer
> applicable, then the method transaction will fail on commit.
> </Roy>
>
> That directly addresses the central issue, and I managed to miss that
> somehow. >>My whole point is that when the server actually executes the
> transaction, the server should have everything and do the entire
> transaction
> all at once -- retrievals, updates, and conditional processing included.<<
> Sorry if I didn't make that clear.
>
> If you want to dribble the instructions for the transaction over piece by
> piece by making separate method calls until it all gets to the server,
> without actually doing any updates or retrievals, that's not
> something that
> I am concerned with much. It would be more efficient to just send over all
> the stuff at once, but I don't think it's that big of a deal to
> send it over
> in pieces. So, doing that is OK with me.
>
> If you want the server to do some security checking and other
> processing on
> the individual pieces as they arrive, before actually executing the entire
> transaction in the commit step, that's fine. That would help the client
> pinpoint a certain subset of the possible problems in each step of the
> transaction.
>
>                                  ---
>
> I think it would be interesting to see how the conditional
> processing of the
> methods is specified. How much generality is achievable without
> getting into
> syntax that doesn't resemble the current methods at all? To make arbitrary
> transactions convenient, you want "program" variables, conditional
> "statements", iteration "statements", and "subroutines" with
> parameters. If
> we don't go that far, perhaps a useful set of transactions could still be
> specified.
>
> I also think it would be interesting to see how the results of the
> transaction are specified. Any part of it could fail.
>
> Alan





From w3c-dist-auth-request@w3.org  Thu Sep 12 18:30:22 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10021
	for <webdav-archive@lists.ietf.org>; Thu, 12 Sep 2002 18:30:22 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8CMSQ624065;
	Thu, 12 Sep 2002 18:28:26 -0400 (EDT)
Resent-Date: Thu, 12 Sep 2002 18:28:26 -0400 (EDT)
Resent-Message-Id: <200209122228.g8CMSQ624065@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8CMSOI24041
	for <w3c-dist-auth@frink.w3.org>; Thu, 12 Sep 2002 18:28:24 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA12907
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 18:28:24 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 12 Sep 2002 18:18:18 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <SWGM4J1F>; Thu, 12 Sep 2002 18:27:53 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B107839224@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Thu, 12 Sep 2002 18:27:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6624
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>


DeltaV supports two transaction visibility models.

If you just have one client involved in a transaction, then you can use
the "working-resource" model.  The server assigns your client a new URL for
each
resource you are changing in a transaction, and those changes do not become
visible to other clients until you CHECKIN those changes.

If you have multiple clients involved in a transaction, then you can use
the "workspace" model.  A client allocates a workspace for the transaction,
and any other client that wants to see (or add to) the transaction can
accesses that workspace.  In this model, you commit the transaction by a
MERGE
request, at which point your changes are seen by all clients.

But in either case, a client by default only sees changes after they are
committed.  

Cheers,
Geoff


-----Original Message-----
From: Sridhar Erukulla [mailto:serukulla@bytequest.com]
Sent: Thursday, September 12, 2002 5:27 PM
To: Clemm, Geoff; w3c-dist-auth@w3.org
Subject: RE: Proposal: WebDAV and transactions



Naive questions:

What if the old values can't be assigned to some/all of the filed
transaction?

What would an another client see if they query for these properties while
performing the alternative method for a transaction? the old or the new
values? Here the new values should be visible only after all the requests in
the batch are completed, is this something easy to implement?

Sridhar
-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
Sent: September 12, 2002 4:20 PM
To: w3c-dist-auth@w3.org
Subject: RE: Proposal: WebDAV and transactions



The Lock/Unlock doesn't give you the "rollback" functionality
(i.e. the client has to remember the old values, and live long
enough to restore them if the later updates fail).

But it would be interesting to investigate whether the
DeltaV CHECKOUT/CHECKIN/UNCHECKOUT protocol could give clients most
of the benefits of transactions (a non-versioning server would
only keep the most recently checked in "version" of a resource).
You would create an "activity" for a given transaction,
make your changes, and then CHECKIN the activity to commit
all the changes, or UNCHECKOUT to roll them back.

Cheers,
Geoff

-----Original Message-----
From: Gary Cowan [mailto:Gary.Cowan@Tally.Hummingbird.com]
Sent: Thursday, September 12, 2002 3:43 PM
To: 'Jim Whitehead'; w3c-dist-auth@w3.org
Subject: RE: Proposal: WebDAV and transactions



Well I suppose, but isn't this what wrapping updates with a Lock/Unlock pair
is intended to accomplish. I have nothing against transactions, I just don't
have any need for them spanning multiple WebDAV methods. Yet:)

-----Original Message-----
From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]
Sent: Thursday, September 12, 2002 3:24 PM
To: w3c-dist-auth@w3.org
Subject: RE: Proposal: WebDAV and transactions



One common example is to be able to write a resource and its properties in a
single operation. You want this to be a transaction, so that the resource
doesn't get updates before the properties are written, and so that if the
properties cannot be written, the resource is reverted back to it's
pre-write state.

- Jim

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Gary Cowan
> Sent: Thursday, September 12, 2002 12:21 PM
> To: 'Babich, Alan'; 'Roy T. Fielding'; w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> At the risk of sounding naive, I cannot understand why anyone
> would want or
> need transactions in a WebDAV session.
>
> -----Original Message-----
> From: Babich, Alan [mailto:ABabich@filenet.com]
> Sent: Thursday, September 12, 2002 3:11 PM
> To: 'Roy T. Fielding'; w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
>
>
> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@apache.org]
> Sent: Thursday, September 12, 2002 7:01 AM
> To: Babich, Alan
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Proposal: WebDAV and transactions
>
> ...snip...
>
> <Alan>
> > Between the method calls, the resources changed have to be locked on the
> > server.
> </Alan>
>
> <Roy>
> That's not how I described transactions.  I said that the requests are
> collected on the server and only applied when the commit message is
> received.  If the state has changed such that the methods are no longer
> applicable, then the method transaction will fail on commit.
> </Roy>
>
> That directly addresses the central issue, and I managed to miss that
> somehow. >>My whole point is that when the server actually executes the
> transaction, the server should have everything and do the entire
> transaction
> all at once -- retrievals, updates, and conditional processing included.<<
> Sorry if I didn't make that clear.
>
> If you want to dribble the instructions for the transaction over piece by
> piece by making separate method calls until it all gets to the server,
> without actually doing any updates or retrievals, that's not
> something that
> I am concerned with much. It would be more efficient to just send over all
> the stuff at once, but I don't think it's that big of a deal to
> send it over
> in pieces. So, doing that is OK with me.
>
> If you want the server to do some security checking and other
> processing on
> the individual pieces as they arrive, before actually executing the entire
> transaction in the commit step, that's fine. That would help the client
> pinpoint a certain subset of the possible problems in each step of the
> transaction.
>
>                                  ---
>
> I think it would be interesting to see how the conditional
> processing of the
> methods is specified. How much generality is achievable without
> getting into
> syntax that doesn't resemble the current methods at all? To make arbitrary
> transactions convenient, you want "program" variables, conditional
> "statements", iteration "statements", and "subroutines" with
> parameters. If
> we don't go that far, perhaps a useful set of transactions could still be
> specified.
>
> I also think it would be interesting to see how the results of the
> transaction are specified. Any part of it could fail.
>
> Alan




From w3c-dist-auth-request@w3.org  Thu Sep 12 22:11:27 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13362
	for <webdav-archive@lists.ietf.org>; Thu, 12 Sep 2002 22:11:27 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8D2BR923020;
	Thu, 12 Sep 2002 22:11:27 -0400 (EDT)
Resent-Date: Thu, 12 Sep 2002 22:11:27 -0400 (EDT)
Resent-Message-Id: <200209130211.g8D2BR923020@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8D2BQI22994
	for <w3c-dist-auth@frink.w3.org>; Thu, 12 Sep 2002 22:11:26 -0400 (EDT)
Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA12444
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 22:11:25 -0400
Received: from inet-mail3.oracle.com (localhost [127.0.0.1])
	by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8D2AsP00743
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 19:10:54 -0700 (PDT)
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13])
	by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8D2AsR00732
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 19:10:54 -0700 (PDT)
Received: from rgmum3.us.oracle.com (rgmum3.us.oracle.com [138.1.191.24])
	by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8D2ArO00156
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 20:10:53 -0600 (MDT)
Received: from dhcp-4op7-4op8-east-130-35-171-81.us.oracle.com by rgmum2.us.oracle.com
	with ESMTP id 62561851031883053; Thu, 12 Sep 2002 20:10:53 -0600
Message-ID: <01bf01c25aca$2235ccc0$51ab2382@us.oracle.com>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: "Clemm, Geoff" <gclemm@rational.com>, <w3c-dist-auth@w3.org>
References: <3906C56A7BD1F54593344C05BD1374B107839222@SUS-MA1IT01>
Date: Thu, 12 Sep 2002 19:06:11 -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: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6625
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>
Content-Transfer-Encoding: 7bit


This would be ok as long as it is cheap to delete activities on your server.
I suspect this solution wouldn't perform because of the other expectations
folks have of activities (intermediate state is persistent, for example).

--Eric

----- Original Message -----
From: "Clemm, Geoff" <gclemm@rational.com>
To: <w3c-dist-auth@w3.org>
Sent: Thursday, September 12, 2002 1:20 PM
Subject: RE: Proposal: WebDAV and transactions


>
> The Lock/Unlock doesn't give you the "rollback" functionality
> (i.e. the client has to remember the old values, and live long
> enough to restore them if the later updates fail).
>
> But it would be interesting to investigate whether the
> DeltaV CHECKOUT/CHECKIN/UNCHECKOUT protocol could give clients most
> of the benefits of transactions (a non-versioning server would
> only keep the most recently checked in "version" of a resource).
> You would create an "activity" for a given transaction,
> make your changes, and then CHECKIN the activity to commit
> all the changes, or UNCHECKOUT to roll them back.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Gary Cowan [mailto:Gary.Cowan@Tally.Hummingbird.com]
> Sent: Thursday, September 12, 2002 3:43 PM
> To: 'Jim Whitehead'; w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> Well I suppose, but isn't this what wrapping updates with a Lock/Unlock
pair
> is intended to accomplish. I have nothing against transactions, I just
don't
> have any need for them spanning multiple WebDAV methods. Yet:)
>
> -----Original Message-----
> From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]
> Sent: Thursday, September 12, 2002 3:24 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> One common example is to be able to write a resource and its properties in
a
> single operation. You want this to be a transaction, so that the resource
> doesn't get updates before the properties are written, and so that if the
> properties cannot be written, the resource is reverted back to it's
> pre-write state.
>
> - Jim
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Gary Cowan
> > Sent: Thursday, September 12, 2002 12:21 PM
> > To: 'Babich, Alan'; 'Roy T. Fielding'; w3c-dist-auth@w3.org
> > Subject: RE: Proposal: WebDAV and transactions
> >
> >
> >
> > At the risk of sounding naive, I cannot understand why anyone
> > would want or
> > need transactions in a WebDAV session.
> >
> > -----Original Message-----
> > From: Babich, Alan [mailto:ABabich@filenet.com]
> > Sent: Thursday, September 12, 2002 3:11 PM
> > To: 'Roy T. Fielding'; w3c-dist-auth@w3.org
> > Subject: RE: Proposal: WebDAV and transactions
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Roy T. Fielding [mailto:fielding@apache.org]
> > Sent: Thursday, September 12, 2002 7:01 AM
> > To: Babich, Alan
> > Cc: w3c-dist-auth@w3.org
> > Subject: Re: Proposal: WebDAV and transactions
> >
> > ...snip...
> >
> > <Alan>
> > > Between the method calls, the resources changed have to be locked on
the
> > > server.
> > </Alan>
> >
> > <Roy>
> > That's not how I described transactions.  I said that the requests are
> > collected on the server and only applied when the commit message is
> > received.  If the state has changed such that the methods are no longer
> > applicable, then the method transaction will fail on commit.
> > </Roy>
> >
> > That directly addresses the central issue, and I managed to miss that
> > somehow. >>My whole point is that when the server actually executes the
> > transaction, the server should have everything and do the entire
> > transaction
> > all at once -- retrievals, updates, and conditional processing
included.<<
> > Sorry if I didn't make that clear.
> >
> > If you want to dribble the instructions for the transaction over piece
by
> > piece by making separate method calls until it all gets to the server,
> > without actually doing any updates or retrievals, that's not
> > something that
> > I am concerned with much. It would be more efficient to just send over
all
> > the stuff at once, but I don't think it's that big of a deal to
> > send it over
> > in pieces. So, doing that is OK with me.
> >
> > If you want the server to do some security checking and other
> > processing on
> > the individual pieces as they arrive, before actually executing the
entire
> > transaction in the commit step, that's fine. That would help the client
> > pinpoint a certain subset of the possible problems in each step of the
> > transaction.
> >
> >                                  ---
> >
> > I think it would be interesting to see how the conditional
> > processing of the
> > methods is specified. How much generality is achievable without
> > getting into
> > syntax that doesn't resemble the current methods at all? To make
arbitrary
> > transactions convenient, you want "program" variables, conditional
> > "statements", iteration "statements", and "subroutines" with
> > parameters. If
> > we don't go that far, perhaps a useful set of transactions could still
be
> > specified.
> >
> > I also think it would be interesting to see how the results of the
> > transaction are specified. Any part of it could fail.
> >
> > Alan
>
>



From w3c-dist-auth-request@w3.org  Thu Sep 12 23:56:05 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15120
	for <webdav-archive@lists.ietf.org>; Thu, 12 Sep 2002 23:56:05 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8D3sow09512;
	Thu, 12 Sep 2002 23:54:50 -0400 (EDT)
Resent-Date: Thu, 12 Sep 2002 23:54:50 -0400 (EDT)
Resent-Message-Id: <200209130354.g8D3sow09512@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8D3snI09486
	for <w3c-dist-auth@frink.w3.org>; Thu, 12 Sep 2002 23:54:49 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA28291
	for <w3c-dist-auth@w3.org>; Thu, 12 Sep 2002 23:54:49 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 12 Sep 2002 23:44:42 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <SWGM4R3H>; Thu, 12 Sep 2002 23:54:18 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B108258BC2@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Thu, 12 Sep 2002 23:54:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6626
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>


I don't think I see your point.

If a client is interacting with a versioning server, then
yes, the history (including the activity info) would be
saved, but if they are interacting with a non-versioning
server, they would lose the history (of both versions
and activities/transactions), but a client would be able to
use the same protocol in each case, making life easier for
a client writer.  This is very similar to auto-versioning
with locks ... a locking client just thinks it is creating
and deleting locks, but if it is doing so against a versioning
server, history will be kept.  And just as an "unlock" is
a reasonable clue that "this information is worth saving in
the history", a "commit" is even a stronger clue.

And it would be easy for a client to find out if it is
interacting with a "versioning" deltav server, by checking
if the "version history" report is available.

Cheers,
Geoff

-----Original Message-----
From: Eric Sedlar [mailto:eric.sedlar@oracle.com]
Sent: Thursday, September 12, 2002 10:06 PM
To: Clemm, Geoff; w3c-dist-auth@w3.org
Subject: Re: Proposal: WebDAV and transactions


This would be ok as long as it is cheap to delete activities on your server.
I suspect this solution wouldn't perform because of the other expectations
folks have of activities (intermediate state is persistent, for example).

--Eric

----- Original Message -----
From: "Clemm, Geoff" <gclemm@rational.com>
To: <w3c-dist-auth@w3.org>
Sent: Thursday, September 12, 2002 1:20 PM
Subject: RE: Proposal: WebDAV and transactions


>
> The Lock/Unlock doesn't give you the "rollback" functionality
> (i.e. the client has to remember the old values, and live long
> enough to restore them if the later updates fail).
>
> But it would be interesting to investigate whether the
> DeltaV CHECKOUT/CHECKIN/UNCHECKOUT protocol could give clients most
> of the benefits of transactions (a non-versioning server would
> only keep the most recently checked in "version" of a resource).
> You would create an "activity" for a given transaction,
> make your changes, and then CHECKIN the activity to commit
> all the changes, or UNCHECKOUT to roll them back.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Gary Cowan [mailto:Gary.Cowan@Tally.Hummingbird.com]
> Sent: Thursday, September 12, 2002 3:43 PM
> To: 'Jim Whitehead'; w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> Well I suppose, but isn't this what wrapping updates with a Lock/Unlock
pair
> is intended to accomplish. I have nothing against transactions, I just
don't
> have any need for them spanning multiple WebDAV methods. Yet:)
>
> -----Original Message-----
> From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]
> Sent: Thursday, September 12, 2002 3:24 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> One common example is to be able to write a resource and its properties in
a
> single operation. You want this to be a transaction, so that the resource
> doesn't get updates before the properties are written, and so that if the
> properties cannot be written, the resource is reverted back to it's
> pre-write state.
>
> - Jim
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Gary Cowan
> > Sent: Thursday, September 12, 2002 12:21 PM
> > To: 'Babich, Alan'; 'Roy T. Fielding'; w3c-dist-auth@w3.org
> > Subject: RE: Proposal: WebDAV and transactions
> >
> >
> >
> > At the risk of sounding naive, I cannot understand why anyone
> > would want or
> > need transactions in a WebDAV session.
> >
> > -----Original Message-----
> > From: Babich, Alan [mailto:ABabich@filenet.com]
> > Sent: Thursday, September 12, 2002 3:11 PM
> > To: 'Roy T. Fielding'; w3c-dist-auth@w3.org
> > Subject: RE: Proposal: WebDAV and transactions
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Roy T. Fielding [mailto:fielding@apache.org]
> > Sent: Thursday, September 12, 2002 7:01 AM
> > To: Babich, Alan
> > Cc: w3c-dist-auth@w3.org
> > Subject: Re: Proposal: WebDAV and transactions
> >
> > ...snip...
> >
> > <Alan>
> > > Between the method calls, the resources changed have to be locked on
the
> > > server.
> > </Alan>
> >
> > <Roy>
> > That's not how I described transactions.  I said that the requests are
> > collected on the server and only applied when the commit message is
> > received.  If the state has changed such that the methods are no longer
> > applicable, then the method transaction will fail on commit.
> > </Roy>
> >
> > That directly addresses the central issue, and I managed to miss that
> > somehow. >>My whole point is that when the server actually executes the
> > transaction, the server should have everything and do the entire
> > transaction
> > all at once -- retrievals, updates, and conditional processing
included.<<
> > Sorry if I didn't make that clear.
> >
> > If you want to dribble the instructions for the transaction over piece
by
> > piece by making separate method calls until it all gets to the server,
> > without actually doing any updates or retrievals, that's not
> > something that
> > I am concerned with much. It would be more efficient to just send over
all
> > the stuff at once, but I don't think it's that big of a deal to
> > send it over
> > in pieces. So, doing that is OK with me.
> >
> > If you want the server to do some security checking and other
> > processing on
> > the individual pieces as they arrive, before actually executing the
entire
> > transaction in the commit step, that's fine. That would help the client
> > pinpoint a certain subset of the possible problems in each step of the
> > transaction.
> >
> >                                  ---
> >
> > I think it would be interesting to see how the conditional
> > processing of the
> > methods is specified. How much generality is achievable without
> > getting into
> > syntax that doesn't resemble the current methods at all? To make
arbitrary
> > transactions convenient, you want "program" variables, conditional
> > "statements", iteration "statements", and "subroutines" with
> > parameters. If
> > we don't go that far, perhaps a useful set of transactions could still
be
> > specified.
> >
> > I also think it would be interesting to see how the results of the
> > transaction are specified. Any part of it could fail.
> >
> > Alan
>
>



From w3c-dist-auth-request@w3.org  Fri Sep 13 03:37:13 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27605
	for <webdav-archive@lists.ietf.org>; Fri, 13 Sep 2002 03:37:13 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8D7bFG02974;
	Fri, 13 Sep 2002 03:37:15 -0400 (EDT)
Resent-Date: Fri, 13 Sep 2002 03:37:15 -0400 (EDT)
Resent-Message-Id: <200209130737.g8D7bFG02974@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8D7bCI02879
	for <w3c-dist-auth@frink.w3.org>; Fri, 13 Sep 2002 03:37:12 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA25021
	for <w3c-dist-auth@w3.org>; Fri, 13 Sep 2002 03:37:10 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3.org>; Fri, 13 Sep 2002 09:36:58 +0200
Date: Fri, 13 Sep 2002 09:36:59 +0200
X-Mailer: Apple Mail (2.482)
Mime-Version: 1.0 (Apple Message framework v482)
Cc: w3c-dist-auth@w3.org
Message-Id: <9627E886-C6EB-11D6-9F78-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B107839222@SUS-MA1IT01>
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
From: Stefan Eissing <stefan.eissing@greenbytes.de>
To: "Clemm, Geoff" <gclemm@rational.com>
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3.org
Subject: Re: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6627
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>
Content-Transfer-Encoding: 7bit



Am Donnerstag den, 12. September 2002, um 22:20, schrieb Clemm, Geoff:

> [...]
> But it would be interesting to investigate whether the
> DeltaV CHECKOUT/CHECKIN/UNCHECKOUT protocol could give clients most
> of the benefits of transactions (a non-versioning server would
> only keep the most recently checked in "version" of a resource).
> You would create an "activity" for a given transaction,
> make your changes, and then CHECKIN the activity to commit
> all the changes, or UNCHECKOUT to roll them back.

All the use cases mentioned to me for HTTP transactions can be
done with DeltaV. It would be very interesting to hear of an
authoring use case which cannot be satisfied with deltaV
features. And then I would probably try to extend deltav...

If you want to do rdbms-like transactions in WebDAV (with
READ-COMITTED transaction isolation at least), which
are also RESTful, you need to reflect the server state in
the URIs used for the transactions. And if you do that, you'd
sooner or later end up doing what DeltaV has done with
working resource, workspace and activities.

//Stefan


> Cheers,
> Geoff
>
> -----Original Message-----
> From: Gary Cowan [mailto:Gary.Cowan@Tally.Hummingbird.com]
> Sent: Thursday, September 12, 2002 3:43 PM
> To: 'Jim Whitehead'; w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> Well I suppose, but isn't this what wrapping updates with a 
> Lock/Unlock pair
> is intended to accomplish. I have nothing against transactions, I 
> just don't
> have any need for them spanning multiple WebDAV methods. Yet:)
>
> -----Original Message-----
> From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]
> Sent: Thursday, September 12, 2002 3:24 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> One common example is to be able to write a resource and its 
> properties in a
> single operation. You want this to be a transaction, so that the 
> resource
> doesn't get updates before the properties are written, and so that 
> if the
> properties cannot be written, the resource is reverted back to it's
> pre-write state.
>
> - Jim
>
>> -----Original Message-----
>> From: w3c-dist-auth-request@w3.org
>> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Gary Cowan
>> Sent: Thursday, September 12, 2002 12:21 PM
>> To: 'Babich, Alan'; 'Roy T. Fielding'; w3c-dist-auth@w3.org
>> Subject: RE: Proposal: WebDAV and transactions
>>
>>
>>
>> At the risk of sounding naive, I cannot understand why anyone
>> would want or
>> need transactions in a WebDAV session.
>>
>> -----Original Message-----
>> From: Babich, Alan [mailto:ABabich@filenet.com]
>> Sent: Thursday, September 12, 2002 3:11 PM
>> To: 'Roy T. Fielding'; w3c-dist-auth@w3.org
>> Subject: RE: Proposal: WebDAV and transactions
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Roy T. Fielding [mailto:fielding@apache.org]
>> Sent: Thursday, September 12, 2002 7:01 AM
>> To: Babich, Alan
>> Cc: w3c-dist-auth@w3.org
>> Subject: Re: Proposal: WebDAV and transactions
>>
>> ...snip...
>>
>> <Alan>
>>> Between the method calls, the resources changed have to be locked 
>>> on the
>>> server.
>> </Alan>
>>
>> <Roy>
>> That's not how I described transactions.  I said that the requests are
>> collected on the server and only applied when the commit message is
>> received.  If the state has changed such that the methods are no 
>> longer
>> applicable, then the method transaction will fail on commit.
>> </Roy>
>>
>> That directly addresses the central issue, and I managed to miss that
>> somehow. >>My whole point is that when the server actually 
>> executes the
>> transaction, the server should have everything and do the entire
>> transaction
>> all at once -- retrievals, updates, and conditional processing 
>> included.<<
>> Sorry if I didn't make that clear.
>>
>> If you want to dribble the instructions for the transaction over 
>> piece by
>> piece by making separate method calls until it all gets to the server,
>> without actually doing any updates or retrievals, that's not
>> something that
>> I am concerned with much. It would be more efficient to just send 
>> over all
>> the stuff at once, but I don't think it's that big of a deal to
>> send it over
>> in pieces. So, doing that is OK with me.
>>
>> If you want the server to do some security checking and other
>> processing on
>> the individual pieces as they arrive, before actually executing 
>> the entire
>> transaction in the commit step, that's fine. That would help the 
>> client
>> pinpoint a certain subset of the possible problems in each step of the
>> transaction.
>>
>>                                  ---
>>
>> I think it would be interesting to see how the conditional
>> processing of the
>> methods is specified. How much generality is achievable without
>> getting into
>> syntax that doesn't resemble the current methods at all? To make 
>> arbitrary
>> transactions convenient, you want "program" variables, conditional
>> "statements", iteration "statements", and "subroutines" with
>> parameters. If
>> we don't go that far, perhaps a useful set of transactions could 
>> still be
>> specified.
>>
>> I also think it would be interesting to see how the results of the
>> transaction are specified. Any part of it could fail.
>>
>> Alan
>
>



From w3c-dist-auth-request@w3.org  Fri Sep 13 05:37:13 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29692
	for <webdav-archive@lists.ietf.org>; Fri, 13 Sep 2002 05:37:13 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8D9bn323572;
	Fri, 13 Sep 2002 05:37:49 -0400 (EDT)
Resent-Date: Fri, 13 Sep 2002 05:37:49 -0400 (EDT)
Resent-Message-Id: <200209130937.g8D9bn323572@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8D9blI23532
	for <w3c-dist-auth@frink.w3.org>; Fri, 13 Sep 2002 05:37:47 -0400 (EDT)
Received: from 140.wakasoft.com (bsl-rtr.day.com [212.249.34.130])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA15399
	for <w3c-dist-auth@w3.org>; Fri, 13 Sep 2002 05:37:46 -0400
Received: from 140.catv78.balcab.ch (localhost [127.0.0.1])
	by 140.wakasoft.com (8.12.4/8.12.4) with ESMTP id g8D9ZenW012510;
	Fri, 13 Sep 2002 02:35:40 -0700 (PDT)
Date: Fri, 13 Sep 2002 11:35:39 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: <w3c-dist-auth@w3.org>
To: "Julian Reschke" <julian.reschke@gmx.de>
From: "Roy T. Fielding" <fielding@apache.org>
In-Reply-To: <JIEGINCHMLABHJBIGKBCIEHIFFAA.julian.reschke@gmx.de>
Message-Id: <2A625F5A-C6FC-11D6-BB1B-000393753936@apache.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.482)
Subject: Re: can a non-HTTP URL be the target of a redirect (301/302)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6628
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>
Content-Transfer-Encoding: 7bit


> The question: are there any restrictions on what type or absoluteURI(s) 
> are
> allowed?

There are no such restrictions.

....Roy



From w3c-dist-auth-request@w3.org  Fri Sep 13 11:37:06 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09374
	for <webdav-archive@lists.ietf.org>; Fri, 13 Sep 2002 11:37:01 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8DFWRs28306;
	Fri, 13 Sep 2002 11:32:27 -0400 (EDT)
Resent-Date: Fri, 13 Sep 2002 11:32:27 -0400 (EDT)
Resent-Message-Id: <200209131532.g8DFWRs28306@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8DFWLI28257
	for <w3c-dist-auth@frink.w3.org>; Fri, 13 Sep 2002 11:32:21 -0400 (EDT)
Received: from cpimssmtpu09.email.msn.com (cpimssmtpu09.email.msn.com [207.46.181.84])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA19697
	for <w3c-dist-auth@w3.org>; Fri, 13 Sep 2002 11:32:21 -0400
Received: from centro ([63.231.39.60]) by cpimssmtpu09.email.msn.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 13 Sep 2002 08:30:05 -0700
Reply-To: <dennis.hamilton@acm.org>
From: "Dennis E. Hamilton" <dennis.hamilton@acm.org>
To: <w3c-dist-auth@w3.org>
Cc: "Babich, Alan" <ABabich@filenet.com>,
        "Roy T. Fielding" <fielding@apache.org>,
        "Jim Whitehead" <ejw@cse.ucsc.edu>,
        "Gary Cowan" <Gary.Cowan@Tally.Hummingbird.com>,
        "'B. Shadgar'" <shadgar@cs.bris.ac.uk>,
        "Pill, Juergen" <Juergen.Pill@softwareag.com>
Date: Fri, 13 Sep 2002 08:31:00 -0700
Message-ID: <NGBBIKAHMDNFPKNEPALECECDINAA.dennis.hamilton@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <1F223AE0-C658-11D6-A960-000393753936@apache.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 13 Sep 2002 15:30:05.0399 (UTC) FILETIME=[6F56DE70:01C25B3A]
Subject: Proposal: WebDAV and transactions - stepping back to requirements
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6630
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>
Content-Transfer-Encoding: 7bit


1.	WHAT ARE THE REQUIREMENTS?

It seems to me that the conversation on transactions is looking at different
approaches to something that might be transactions and comparing those
possible implementations without being sure that we are talking about the
same concept for transactions and whatever the requirements might be in the
context of WebDAV.

I think it is very valuable at this point to stand back and investigate
exactly what is required for transactions and what the constraints on their
support would be for WebDAV.

Here are some things that I noticed in thinking about this.  Subject-matter
experts would have something more useful to say:

2.	WHAT ARE TRANSACTIONS?

I think there needs to be agreement at this level.  This is a key point of
understanding before being able to proceed.

Here is what occurs to me:

2.1	Transaction protection is a way to assure that a persistent store
(database, etc... ) never presents an unrecognized inconsistent state, and
the failure modes always revert to a consistent state.  My understanding is
that in the general case the notion of consistency is beyond the consistency
of the store abstraction.  It is there to support the consistency required
by the application in which the store is used instrumentally.  The
consistency at the granularity of the store abstractions (e.g., WebDAV with
locking) is assumed to be handled already.  Now we are talking about
consistency in coordinated use of a store for satisfying requirements that
are operable at a different level of abstraction.

2.2	Put simply and quite generally, a transaction looks atomic to everyone
but the originating process, and it looks atomic to the originating process
outside of the critical section of the transactioned process.  And the
effect is to achieve a consistent state to all observers outside of critical
sections (the one place where rules are broken in order to be implemented).
And it is requirements of the implemented application that govern what those
consistency/atomicity conditions are and what their satisfaction is.

2.3	Transaction Processing models are highly abstracted, because we are
constrained from knowing all the particular ways that transactions may be
required in securing the consistent operation of an application.  So support
is utilitarian.  There will be limitations on the scope of support, and
understanding what those are and what the cost of going beyond it (as well
as the economy of staying within it) needs to be understood.

3. 	REQUIREMENTS FOR TRANSACTION-PROCESSING SUPPORT

Key things that I think have to be agreed around requirements for
transactions are.   I am not that great in thinking at the requirements
level, so if these don't read like requirements bear with me.  Consider
instead what might be the requirement behind quasi-requirements like these:

3.1.	What is the required atomic appearance of consistency outside of
critical (transaction-protected processing) sections?  (Express as a
principle and what people are to get out of it, not so much as a given
solution.)

3.2.	What is the required appearance of consistency within critical
sections?  (E.g., do changes to an underlying store appear to have taken
place just as they would if transaction-protection were not requested?)

3.3.	What is the ability to integrate in a transaction regime that extends
beyond the operation of a single WebDAV service?  Related to scope of
support (3.5) and

3.4.	The unobtrusiveness of transaction support in the expression of
transaction-protected processes (e.g., that there be little or no difference
beyond what it takes to signify that an operation is protected under an
identified transaction) - only expressed at the level that doesn't foretell
an implementation or protocol approach

3.5.  What is the scope of required consistency support (the place where
use-cases might help the most).

4.	CONSTRAINTS

There are constraints that will apply to the acceptable introduction of
transaction-processing support in the WebDAV protocol.  These limit the
solution space available for responding to requirements.  (Again, I am not
that practiced at differentiating between constraints and requirements.  I
recognize value in doing so.)  Here are some candidates:

4.1.	Actually using an (existing) transaction model at all.  I notice in (3)
I am presuming that transaction-protection techniques are required.  I do
think that is a given, because it is an integrative requirement (integrating
with available rather-standard mechanisms, integrating from the standpoint
of the knowledge and experience required to develop and validate
applications).  But the requirement for that or the constraint of that needs
to be surfaced.

4.1.	Supporting provisions must honor the STEP model and the spirit of HTTP
to no lesser degree than WebDAV already does (that is, simply tunneling
another protocol wouldn't count)

4.2.	If there is a way to provide a scaled-down, high-value case, it must be
convincing and not merely intended that it does scale.  (I don't know how
you do that without demonstrating a full solution, but who knows ... .)

4.3.	And scaling between non-support and (degrees of) support.  Like,
reusing already-defined methods and supplementing their request bodies or
something like that, wherever possible.  Something about failure cases in
this area, along with conditions on use of HTTP and WebDAV error status,
etc.

-- Dennis

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead
Sent: Thursday, September 12, 2002 12:58
To: Gary Cowan; w3c-dist-auth@w3.org
Subject: RE: Proposal: WebDAV and transactions

> Well I suppose, but isn't this what wrapping updates with a
> Lock/Unlock pair is intended to accomplish. I have nothing
> against transactions, I just don't have any need for them
> spanning multiple WebDAV methods. Yet:)

Lock/unlock doesn't give you rollback capability. Even though you're the
only person who can write to a resource during a lock, it still may be the
case that you're unable to complete the PROPPATCH part of a PUT/PROPPATCH
pair. The TCP connection may go down, the server may go down, you may be
exceeding your quota, etc.

Now, if the total number of use cases is relatively small, it probably makes
more sense to create new methods explicitly for these use cases, instead of
a general purpose transaction mechanism.

- Jim


-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding
Sent: Thursday, September 12, 2002 07:01
To: Babich, Alan
Cc: w3c-dist-auth@w3.org
Subject: Re: Proposal: WebDAV and transactions

[ ... ]

That's not how I described transactions.  I said that the requests are
collected on the server and only applied when the commit message is
received.  If the state has changed such that the methods are no longer
applicable, then the method transaction will fail on commit.

....Roy

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Babich, Alan
Sent: Monday, September 02, 2002 13:59
To: 'B. Shadgar'; Pill, Juergen; w3c-dist-auth@w3.org
Subject: RE: Proposal: WebDAV and transactions

One thing you do NOT want under any circumstances are
begin-transaction, end-transaction, and abort-transaction
methods.

[ ... ]




From w3c-dist-auth-request@w3.org  Fri Sep 13 11:37:14 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09389
	for <webdav-archive@lists.ietf.org>; Fri, 13 Sep 2002 11:37:14 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8DFWMt28269;
	Fri, 13 Sep 2002 11:32:22 -0400 (EDT)
Resent-Date: Fri, 13 Sep 2002 11:32:22 -0400 (EDT)
Resent-Message-Id: <200209131532.g8DFWMt28269@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8DFWLI28239
	for <w3c-dist-auth@frink.w3.org>; Fri, 13 Sep 2002 11:32:21 -0400 (EDT)
Received: from cpimssmtpu09.email.msn.com (cpimssmtpu09.email.msn.com [207.46.181.84])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA19695
	for <w3c-dist-auth@w3.org>; Fri, 13 Sep 2002 11:32:20 -0400
Received: from centro ([63.231.39.60]) by cpimssmtpu09.email.msn.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 13 Sep 2002 08:30:04 -0700
Reply-To: <dennis.hamilton@acm.org>
From: "Dennis E. Hamilton" <dennis.hamilton@acm.org>
To: "Clemm, Geoff" <gclemm@rational.com>, <w3c-dist-auth@w3.org>
Date: Fri, 13 Sep 2002 08:30:58 -0700
Message-ID: <NGBBIKAHMDNFPKNEPALEAECDINAA.dennis.hamilton@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B108258BC2@SUS-MA1IT01>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 13 Sep 2002 15:30:04.0321 (UTC) FILETIME=[6EB26110:01C25B3A]
Subject: RE: Proposal: WebDAV and transactions - optional versioning usage
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6629
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>
Content-Transfer-Encoding: 7bit


It is unclear to me how this would accomplish transaction support in the
usual way.

The appeal of bracketed transaction management is that the client does
nothing appreciable between the brackets that would not be done in a
conventional, exclusive-use-of-repository model.  At successful commit, it
is literaly as if nothing different had occurred.   And if a client aborts a
transaction, there is no operation required on the part of the client to
"undo" all of the transaction-protected operations.

So I don't think there is an "invisible" case by use of a facility that
appears to honor transactioning methods yet doesn't provide support for
transactioning.

Assuming, of course, that we are talking about something like
full-capability transaction processing integration.

-- Dennis

Dennis E. Hamilton
AIIM DMware Technical Coordinator
------------------
mailto:dennis.hamilton@acm.org  tel. +1-206-932-6970
http://DMware.info/             cel. +1-206-779-9430
     ODMA Support http://ODMA.info/

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
Sent: Thursday, September 12, 2002 20:54
To: w3c-dist-auth@w3.org
Subject: RE: Proposal: WebDAV and transactions



I don't think I see your point.

If a client is interacting with a versioning server, then
yes, the history (including the activity info) would be
saved, but if they are interacting with a non-versioning
server, they would lose the history (of both versions
and activities/transactions), but a client would be able to
use the same protocol in each case, making life easier for
a client writer.  This is very similar to auto-versioning
with locks ... a locking client just thinks it is creating
and deleting locks, but if it is doing so against a versioning
server, history will be kept.  And just as an "unlock" is
a reasonable clue that "this information is worth saving in
the history", a "commit" is even a stronger clue.

And it would be easy for a client to find out if it is
interacting with a "versioning" deltav server, by checking
if the "version history" report is available.

Cheers,
Geoff

-----Original Message-----
From: Eric Sedlar [mailto:eric.sedlar@oracle.com]
Sent: Thursday, September 12, 2002 10:06 PM
To: Clemm, Geoff; w3c-dist-auth@w3.org
Subject: Re: Proposal: WebDAV and transactions


This would be ok as long as it is cheap to delete activities on your server.
I suspect this solution wouldn't perform because of the other expectations
folks have of activities (intermediate state is persistent, for example).

--Eric

----- Original Message -----
From: "Clemm, Geoff" <gclemm@rational.com>
To: <w3c-dist-auth@w3.org>
Sent: Thursday, September 12, 2002 1:20 PM
Subject: RE: Proposal: WebDAV and transactions


>
> The Lock/Unlock doesn't give you the "rollback" functionality
> (i.e. the client has to remember the old values, and live long
> enough to restore them if the later updates fail).
>
> But it would be interesting to investigate whether the
> DeltaV CHECKOUT/CHECKIN/UNCHECKOUT protocol could give clients most
> of the benefits of transactions (a non-versioning server would
> only keep the most recently checked in "version" of a resource).
> You would create an "activity" for a given transaction,
> make your changes, and then CHECKIN the activity to commit
> all the changes, or UNCHECKOUT to roll them back.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Gary Cowan [mailto:Gary.Cowan@Tally.Hummingbird.com]
> Sent: Thursday, September 12, 2002 3:43 PM
> To: 'Jim Whitehead'; w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> Well I suppose, but isn't this what wrapping updates with a Lock/Unlock
pair
> is intended to accomplish. I have nothing against transactions, I just
don't
> have any need for them spanning multiple WebDAV methods. Yet:)
>
> -----Original Message-----
> From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]
> Sent: Thursday, September 12, 2002 3:24 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: Proposal: WebDAV and transactions
>
>
>
> One common example is to be able to write a resource and its properties in
a
> single operation. You want this to be a transaction, so that the resource
> doesn't get updates before the properties are written, and so that if the
> properties cannot be written, the resource is reverted back to it's
> pre-write state.
>
> - Jim
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Gary Cowan
> > Sent: Thursday, September 12, 2002 12:21 PM
> > To: 'Babich, Alan'; 'Roy T. Fielding'; w3c-dist-auth@w3.org
> > Subject: RE: Proposal: WebDAV and transactions
> >
> >
> >
> > At the risk of sounding naive, I cannot understand why anyone
> > would want or
> > need transactions in a WebDAV session.
> >
> > -----Original Message-----
> > From: Babich, Alan [mailto:ABabich@filenet.com]
> > Sent: Thursday, September 12, 2002 3:11 PM
> > To: 'Roy T. Fielding'; w3c-dist-auth@w3.org
> > Subject: RE: Proposal: WebDAV and transactions
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Roy T. Fielding [mailto:fielding@apache.org]
> > Sent: Thursday, September 12, 2002 7:01 AM
> > To: Babich, Alan
> > Cc: w3c-dist-auth@w3.org
> > Subject: Re: Proposal: WebDAV and transactions
> >
> > ...snip...
> >
> > <Alan>
> > > Between the method calls, the resources changed have to be locked on
the
> > > server.
> > </Alan>
> >
> > <Roy>
> > That's not how I described transactions.  I said that the requests are
> > collected on the server and only applied when the commit message is
> > received.  If the state has changed such that the methods are no longer
> > applicable, then the method transaction will fail on commit.
> > </Roy>
> >
> > That directly addresses the central issue, and I managed to miss that
> > somehow. >>My whole point is that when the server actually executes the
> > transaction, the server should have everything and do the entire
> > transaction
> > all at once -- retrievals, updates, and conditional processing
included.<<
> > Sorry if I didn't make that clear.
> >
> > If you want to dribble the instructions for the transaction over piece
by
> > piece by making separate method calls until it all gets to the server,
> > without actually doing any updates or retrievals, that's not
> > something that
> > I am concerned with much. It would be more efficient to just send over
all
> > the stuff at once, but I don't think it's that big of a deal to
> > send it over
> > in pieces. So, doing that is OK with me.
> >
> > If you want the server to do some security checking and other
> > processing on
> > the individual pieces as they arrive, before actually executing the
entire
> > transaction in the commit step, that's fine. That would help the client
> > pinpoint a certain subset of the possible problems in each step of the
> > transaction.
> >
> >                                  ---
> >
> > I think it would be interesting to see how the conditional
> > processing of the
> > methods is specified. How much generality is achievable without
> > getting into
> > syntax that doesn't resemble the current methods at all? To make
arbitrary
> > transactions convenient, you want "program" variables, conditional
> > "statements", iteration "statements", and "subroutines" with
> > parameters. If
> > we don't go that far, perhaps a useful set of transactions could still
be
> > specified.
> >
> > I also think it would be interesting to see how the results of the
> > transaction are specified. Any part of it could fail.
> >
> > Alan
>
>






From w3c-dist-auth-request@w3.org  Fri Sep 13 15:55:30 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17081
	for <webdav-archive@lists.ietf.org>; Fri, 13 Sep 2002 15:55:29 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8DJt3f27100;
	Fri, 13 Sep 2002 15:55:03 -0400 (EDT)
Resent-Date: Fri, 13 Sep 2002 15:55:03 -0400 (EDT)
Resent-Message-Id: <200209131955.g8DJt3f27100@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8DJt1I27074
	for <w3c-dist-auth@frink.w3.org>; Fri, 13 Sep 2002 15:55:01 -0400 (EDT)
Received: from hq-exgw2.filenet.com (Filenet-gw.filenet.com [198.3.8.1])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA02897
	for <w3c-dist-auth@w3.org>; Fri, 13 Sep 2002 15:55:00 -0400
Received: by hq-exgw2.filenet.com with Internet Mail Service (5.5.2653.19)
	id <SW9D4KT8>; Fri, 13 Sep 2002 12:54:13 -0700
Message-ID: <C3AF5E329E21D2119C4C00805F6FF58F08FE5E5F@hq-expo2.filenet.com>
From: "Babich, Alan" <ABabich@filenet.com>
To: "'dennis.hamilton@acm.org'" <dennis.hamilton@acm.org>,
        w3c-dist-auth@w3.org
Date: Fri, 13 Sep 2002 12:54:27 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
Subject: RE: Proposal: WebDAV and transactions - stepping back to requirem 	ents
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6631
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>


I agree with Dennis that everyone should agree on what transactions actually
are. To contribute to that discussion, I think we can all agree that
transactions satisfy the well know ACID properties:

A - atomic
C - concurrent
I - independent
D - durable

Atomic: 
Either the entire transaction is reflected in the repository or none of it
is, not matter what happens (including software and hardware successes or
failures). There is no action on the part of the client to achieve
atomicity. The server must guarantee atomicity when executing a transaction.
Thus, if the repository is partially updated and there is a system crash or
an error condition arises in the conditional processing, then the
transaction is rolled back (i.e., undone, aborted). That includes both its
updates and its transaction level locks.

Concurrent: 
Multiple transactions against the repository can run concurrently.

Independent: 
This is absolutely critical: Transaction independence means that any
transaction that is programmed so that when it is running alone against the
repository it is correct, will remain correct when it is run in an arbitrary
concurrent mix of transactions against the repository. That requires two
phase locking at the transaction level. In the first phase, locks are
accumulated. In the second phase (which is the duration of either the
end-transaction method or the abort-transaction method) all of the locks are
released. The transaction level locks guarantee that the transaction can
make correct decisions based on the contents of the repository. The
transaction level of locking is at a lower level than the WebDAV LOCK and
UNLOCK methods. Those methods are like RCS locks in a source code control
system -- the WebDAV locks can persist for days, weeks, or months.
Transaction level locks on resources in the repository persist only for the
duration of the transaction. (To further the RCS analogy, the RCS checkout
and checkin operations are transactions.) Because locking is required,
deadlocks are possible. Therefore, transaction "code" must process deadlock
errors. (Deadlock errors should be retried by restarting the transaction
from the beginning. The server guarantees that retrying deadlock errors will
not result in an infinite waste of processing -- progress will always be
made in the overall mix of transactions.)

Durable: 
Once the client receives notification that the transaction has completed
successfully, the transaction is reflected permanently in the repository,
even if there is a server crash immediately afterward. In general that
requires the server to log the changes the transaction makes, and, when
restarting after the crash, to apply the redo and undo log records (i.e.,
the after and before images) to the repository. The recovery process makes
the repository reflect all the transactions that were completely finished,
but reflect nothing at all from the transactions that were in progress when
the crash occurred. Two phase locking is necessary for application of the
recovery log to get the repository back into the exact state it was when the
system crashed as opposed to some other state.

Alan Babich

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Friday, September 13, 2002 8:31 AM
To: w3c-dist-auth@w3.org
Cc: Babich, Alan; Roy T. Fielding; Jim Whitehead; Gary Cowan; 'B. Shadgar';
Pill, Juergen
Subject: Proposal: WebDAV and transactions - stepping back to requirements

1.	WHAT ARE THE REQUIREMENTS?

It seems to me that the conversation on transactions is looking at different
approaches to something that might be transactions and comparing those
possible implementations without being sure that we are talking about the
same concept for transactions and whatever the requirements might be in the
context of WebDAV.

I think it is very valuable at this point to stand back and investigate
exactly what is required for transactions and what the constraints on their
support would be for WebDAV.

Here are some things that I noticed in thinking about this.  Subject-matter
experts would have something more useful to say:

2.	WHAT ARE TRANSACTIONS?

I think there needs to be agreement at this level.  This is a key point of
understanding before being able to proceed.

Here is what occurs to me:

2.1	Transaction protection is a way to assure that a persistent store
(database, etc... ) never presents an unrecognized inconsistent state, and
the failure modes always revert to a consistent state.  My understanding is
that in the general case the notion of consistency is beyond the consistency
of the store abstraction.  It is there to support the consistency required
by the application in which the store is used instrumentally.  The
consistency at the granularity of the store abstractions (e.g., WebDAV with
locking) is assumed to be handled already.  Now we are talking about
consistency in coordinated use of a store for satisfying requirements that
are operable at a different level of abstraction.

2.2	Put simply and quite generally, a transaction looks atomic to
everyone
but the originating process, and it looks atomic to the originating process
outside of the critical section of the transactioned process.  And the
effect is to achieve a consistent state to all observers outside of critical
sections (the one place where rules are broken in order to be implemented).
And it is requirements of the implemented application that govern what those
consistency/atomicity conditions are and what their satisfaction is.

2.3	Transaction Processing models are highly abstracted, because we are
constrained from knowing all the particular ways that transactions may be
required in securing the consistent operation of an application.  So support
is utilitarian.  There will be limitations on the scope of support, and
understanding what those are and what the cost of going beyond it (as well
as the economy of staying within it) needs to be understood.

3. 	REQUIREMENTS FOR TRANSACTION-PROCESSING SUPPORT

Key things that I think have to be agreed around requirements for
transactions are.   I am not that great in thinking at the requirements
level, so if these don't read like requirements bear with me.  Consider
instead what might be the requirement behind quasi-requirements like these:

3.1.	What is the required atomic appearance of consistency outside of
critical (transaction-protected processing) sections?  (Express as a
principle and what people are to get out of it, not so much as a given
solution.)

3.2.	What is the required appearance of consistency within critical
sections?  (E.g., do changes to an underlying store appear to have taken
place just as they would if transaction-protection were not requested?)

3.3.	What is the ability to integrate in a transaction regime that
extends
beyond the operation of a single WebDAV service?  Related to scope of
support (3.5) and

3.4.	The unobtrusiveness of transaction support in the expression of
transaction-protected processes (e.g., that there be little or no difference
beyond what it takes to signify that an operation is protected under an
identified transaction) - only expressed at the level that doesn't foretell
an implementation or protocol approach

3.5.  What is the scope of required consistency support (the place where
use-cases might help the most).

4.	CONSTRAINTS

There are constraints that will apply to the acceptable introduction of
transaction-processing support in the WebDAV protocol.  These limit the
solution space available for responding to requirements.  (Again, I am not
that practiced at differentiating between constraints and requirements.  I
recognize value in doing so.)  Here are some candidates:

4.1.	Actually using an (existing) transaction model at all.  I notice in
(3)
I am presuming that transaction-protection techniques are required.  I do
think that is a given, because it is an integrative requirement (integrating
with available rather-standard mechanisms, integrating from the standpoint
of the knowledge and experience required to develop and validate
applications).  But the requirement for that or the constraint of that needs
to be surfaced.

4.1.	Supporting provisions must honor the STEP model and the spirit of
HTTP
to no lesser degree than WebDAV already does (that is, simply tunneling
another protocol wouldn't count)

4.2.	If there is a way to provide a scaled-down, high-value case, it must
be
convincing and not merely intended that it does scale.  (I don't know how
you do that without demonstrating a full solution, but who knows ... .)

4.3.	And scaling between non-support and (degrees of) support.  Like,
reusing already-defined methods and supplementing their request bodies or
something like that, wherever possible.  Something about failure cases in
this area, along with conditions on use of HTTP and WebDAV error status,
etc.

-- Dennis

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead
Sent: Thursday, September 12, 2002 12:58
To: Gary Cowan; w3c-dist-auth@w3.org
Subject: RE: Proposal: WebDAV and transactions

> Well I suppose, but isn't this what wrapping updates with a
> Lock/Unlock pair is intended to accomplish. I have nothing
> against transactions, I just don't have any need for them
> spanning multiple WebDAV methods. Yet:)

Lock/unlock doesn't give you rollback capability. Even though you're the
only person who can write to a resource during a lock, it still may be the
case that you're unable to complete the PROPPATCH part of a PUT/PROPPATCH
pair. The TCP connection may go down, the server may go down, you may be
exceeding your quota, etc.

Now, if the total number of use cases is relatively small, it probably makes
more sense to create new methods explicitly for these use cases, instead of
a general purpose transaction mechanism.

- Jim


-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding
Sent: Thursday, September 12, 2002 07:01
To: Babich, Alan
Cc: w3c-dist-auth@w3.org
Subject: Re: Proposal: WebDAV and transactions

[ ... ]

That's not how I described transactions.  I said that the requests are
collected on the server and only applied when the commit message is
received.  If the state has changed such that the methods are no longer
applicable, then the method transaction will fail on commit.

....Roy

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Babich, Alan
Sent: Monday, September 02, 2002 13:59
To: 'B. Shadgar'; Pill, Juergen; w3c-dist-auth@w3.org
Subject: RE: Proposal: WebDAV and transactions

One thing you do NOT want under any circumstances are
begin-transaction, end-transaction, and abort-transaction
methods.

[ ... ]



From w3c-dist-auth-request@w3.org  Fri Sep 13 18:01:27 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20119
	for <webdav-archive@lists.ietf.org>; Fri, 13 Sep 2002 18:01:27 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8DLnQN12866;
	Fri, 13 Sep 2002 17:49:26 -0400 (EDT)
Resent-Date: Fri, 13 Sep 2002 17:49:26 -0400 (EDT)
Resent-Message-Id: <200209132149.g8DLnQN12866@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8DLnOI12836
	for <w3c-dist-auth@frink.w3.org>; Fri, 13 Sep 2002 17:49:24 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA22367
	for <w3c-dist-auth@w3.org>; Fri, 13 Sep 2002 17:49:24 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 13 Sep 2002 17:39:17 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <SWGMWDFF>; Fri, 13 Sep 2002 17:48:54 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B107839230@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Fri, 13 Sep 2002 17:48:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Proposal: WebDAV and transactions - optional versioning usage
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6632
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>


In a stateless protocol, such as HTTP, something special needs to be
done to tell the server what transaction the operation is to be
applied to.  Since the automatic addition of a header can be done in a
way that is effectively invisible to a client, that is one approach to
consider.  In particular, this was considered seriously for (and for a
while, part of) DeltaV, but was finally rejected because it introduces
unacceptable complexities in various advanced use cases (such as
cross-transaction queries, which DeltaV allows).

Instead, in the DeltaV model, with workspace transactioning,
you prefix each URL with the name of the workspace that identifies
the transaction.  Alternatively, with working resource transactioning,
the server gives you a separate URL for each resource you want to
modify as part of the transaction.

If we find that the workspace or working resource transactioning model
is not sufficiently invisible to a client, we could always consider
reintroducing the "Workspace" header, for transactioning usage of
DeltaV.

Cheers,
Geoff


   From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]

   It is unclear to me how this would accomplish transaction support
   in the usual way.

   The appeal of bracketed transaction management is that the client
   does nothing appreciable between the brackets that would not be
   done in a conventional, exclusive-use-of-repository model.  At
   successful commit, it is literaly as if nothing different had
   occurred.  And if a client aborts a transaction, there is no
   operation required on the part of the client to "undo" all of the
   transaction-protected operations.

   So I don't think there is an "invisible" case by use of a facility that
   appears to honor transactioning methods yet doesn't provide support for
   transactioning.

   Assuming, of course, that we are talking about something like
   full-capability transaction processing integration.

   -----Original Message-----
   From: Clemm, Geoff

   If a client is interacting with a versioning server, then
   yes, the history (including the activity info) would be
   saved, but if they are interacting with a non-versioning
   server, they would lose the history (of both versions
   and activities/transactions), but a client would be able to
   use the same protocol in each case, making life easier for
   a client writer.  This is very similar to auto-versioning
   with locks ... a locking client just thinks it is creating
   and deleting locks, but if it is doing so against a versioning
   server, history will be kept.  And just as an "unlock" is
   a reasonable clue that "this information is worth saving in
   the history", a "commit" is even a stronger clue.

   And it would be easy for a client to find out if it is
   interacting with a "versioning" deltav server, by checking
   if the "version history" report is available.



From w3c-dist-auth-request@w3.org  Sun Sep 15 14:15:01 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08229
	for <webdav-archive@lists.ietf.org>; Sun, 15 Sep 2002 14:15:01 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8FIEd929210;
	Sun, 15 Sep 2002 14:14:39 -0400 (EDT)
Resent-Date: Sun, 15 Sep 2002 14:14:39 -0400 (EDT)
Resent-Message-Id: <200209151814.g8FIEd929210@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8FIEbI29169
	for <w3c-dist-auth@frink.w3.org>; Sun, 15 Sep 2002 14:14:37 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA12434
	for <w3c-dist-auth@w3c.org>; Sun, 15 Sep 2002 14:14:37 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Sun, 15 Sep 2002 14:14:06 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Sun, 15 Sep 2002 14:14:06 -0400
Received: from xythoslap ([198.144.203.248]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Sun, 15 Sep 2002 14:13:42 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Sun, 15 Sep 2002 11:13:38 -0700
Message-ID: <000001c25ce3$a00bba90$29c4fea9@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 15 Sep 2002 18:13:42.0946 (UTC) FILETIME=[9FE12820:01C25CE3]
Subject: Issues from Interop/Interim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6633
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>
Content-Transfer-Encoding: 7bit


We had a great interop last week, IMO. Overall, servers and clients now
have much greater success, and more consistent expectations of each
other.  Progress was made on issues and recommendations for RFC2518bis
and quota draft. 

I tried to keep track of all the Interop issues and recommendations that
people thought should feed into RFC2518 bis.  I'll list all these issues
in this first email, then start more detailed discussions on some of
them in separate email.  These are in no particular order.  

Not all the reasons, justifications or scenarios for these suggestions
are given here.  To the extent that we discussed each of these, WG
meeting consensus was reached in each case.  Of course the final
resolution for each issue and the content of RFC2518 bis are fully
subject to discussion on the list.

- Be more clear more about what a client should do about various errors
that may return in a 207.   2518 could explain for each error case, what
the client might expect to do - retry a different way, give up, etc.

- Clients should accept cookies.  More on this in later email.  

- Simplify timeout definition so that it only allows one TimeType, and
no "other".

- Add a new string in DAV: header to advertise support for RFC2518 bis

- Change the DAV: header BNF to allow coded URLs syntactically.

- Error responses that must contain headers (like 302) don't contain
those headers in multistatus.  E.g. when you MOVE a collection, but one
of the collection members is redirected, a 302 would be most convenient
and normally comes along with a location. Clarify in 2518 bis.

- Be more clear in xml element definitions how they can be extended and
why. 

- Support absolute paths as well as absolute URIs in Destination header.
URI spec has token "abs_path" which would work.

- Change section 13.7 (and others?) to be perfectly clear that last
modified and etags should ONLY reflect the results of GET requests, not
property or other state changes like lock.

-  Be clear in spec that servers MUST do ETags. Explain how necessary
this is to solve the lost update problem.

-  COPY request, destination on different server: how to fail? 502

- Litmus large path names causing failure? Specify better what error to
return. 

- Close out issue on PUT creating intermediate collections.  We will
not.

- Changing ETags on LOCK?  No

- How to force authentication from clients? Ilya will propose OPTIONS
header.

- Servers must use trailing slash whenever collection URLs are returned.
Language proposed for 2518 bis

- Servers should not be allowed to withhold lock owner information from
clients. Clients control the content of this element, thus clients can
decide on sensitivity.

- LOCK on non-existent resource creates a resource.  What is
content-type?  Server defined, or use 204.

- Clients get confused if host names change; Clients expect
full/relative URLs? Dealt with in text on multistatus response

- Body in MKCOL - must be XML?, no it doesn't have to be!

- Can a single principal take out >1 shared lock?  Yes!

- Are shared write locks interoperable?  Yes-humans can decide when to
update the document that is locked with shared locks.  Automatic
processes probably shouldn't use shared locks.

- Should if and lock-token header be split up? Yes

- BODY on LOCK refresh - can client reset timeout or owner? No body. Yes
clients can refresh timeout with header, but not owner because LOCK
refresh has no body.

- Source property is "out" of bis. Proposal for authoring dynamic
content should be in another draft.

- If header should not be required in order to supply a lock token to
change a locked resource. A proposal is needed for a new header that
does not force the request to fail if the lock token is no longer
applicable. More on this in a later email.

NON-2518 ISSUE:
- Quota draft was edited. It should be reissued and go to proposed.




From w3c-dist-auth-request@w3.org  Sun Sep 15 14:32:13 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08469
	for <webdav-archive@lists.ietf.org>; Sun, 15 Sep 2002 14:32:13 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8FIWqH01464;
	Sun, 15 Sep 2002 14:32:52 -0400 (EDT)
Resent-Date: Sun, 15 Sep 2002 14:32:52 -0400 (EDT)
Resent-Message-Id: <200209151832.g8FIWqH01464@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8FIWpI01427
	for <w3c-dist-auth@frink.w3.org>; Sun, 15 Sep 2002 14:32:51 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA14337
	for <w3c-dist-auth@w3c.org>; Sun, 15 Sep 2002 14:32:51 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Sun, 15 Sep 2002 14:32:20 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Sun, 15 Sep 2002 14:32:20 -0400
Received: from xythoslap ([198.144.203.248]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Sun, 15 Sep 2002 14:31:56 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Sun, 15 Sep 2002 11:31:53 -0700
Message-ID: <000701c25ce6$2c119b20$29c4fea9@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 15 Sep 2002 18:31:56.0870 (UTC) FILETIME=[2BE8B660:01C25CE6]
Subject: Interop issue: Proposal for fixing lock token provision
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6635
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>
Content-Transfer-Encoding: 7bit



At this week's Interop event, as at last year's, many interoperability
problems were found with scenarios involving change methods where a lock
token is required.  A long, animated, exciting conversation was held to
finally achieve  consensus among attendees on goals for a new way to
supply lock tokens to servers.

GOALS for Lock Token Provision
------------------------------

1. Clients should be able to provide lock tokens in conditional requests
that cause the request to fail if the token does not still match the
state. This goal is currently met by the If header, but this goal must
continue to be met by any new solution.

2. Clients should ALSO be able to provide multiple unqualified lock
tokens in order to prove that they have those tokens and can do write
requests legally, in a way that does not impose conditions on the
success of the request. This mechanism should not use or affect the
Lock-Token header which is required in UNLOCK to specify a single lock
token to remove or refresh. This mechanism should be capable of
supporting many values.

3. Servers should be able to inform clients when lock tokens being used
in any way are no longer valid.   This helps clients keep their
understanding of the server's state up-to-date.

Discussions on how to solve
---------------------------

1. Already solved by If header. Only slight clarifications needed to
improve basic interoperability of this header (see below).

2. The mechanism to provide multiple tokens could easily be a new
header. The syntax should involve comma-separated values, because then
lines can be split across multiple instances of the header according to
RFC2616 header rules.

3. A new response header or two could allow servers to return invalid or
unnecessary lock tokens.  This should be a response header so that the
information can easily be marshaled even on responses that already
contain a body. Again, the response header syntax should be
comma-separated.

Slight changes to existing definitions
--------------------------------------

- The existing Lock-Token header is used to specify a single lock token,
in methods that must operate on a single lock.  It is used on UNLOCK to
remove a lock.  The LOCK refresh request should ALSO use this header
(and the If header should continue to be supported by servers in order
to handle existing clients).  This includes the clarification that LOCK
refresh can only be used to refresh a single lock.  That's a good thing,
because the Timeout header only exists once per request too.

 - An untagged token in the IF header should apply ONLY to the resource
named in the Request-URI.  The original definition is that they apply to
any resources "affected" by the request. This has turned out to be too
ambiguous and arduous to determine.  Also most lock tokens only apply to
one resource, not the entire set of resources "affected" by a request
like MOVE/COPY. Since any token in the IF header can be tagged with a
URL in order to make it explicit what resource the token refers to, we
can make the untagged token equally explicit without removing any client
functionality in the If header.

Lisa



From w3c-dist-auth-request@w3.org  Sun Sep 15 15:01:56 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08228
	for <webdav-archive@lists.ietf.org>; Sun, 15 Sep 2002 14:15:00 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8FIEkD29229;
	Sun, 15 Sep 2002 14:14:46 -0400 (EDT)
Resent-Date: Sun, 15 Sep 2002 14:14:46 -0400 (EDT)
Resent-Message-Id: <200209151814.g8FIEkD29229@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8FIEbI29168
	for <w3c-dist-auth@frink.w3.org>; Sun, 15 Sep 2002 14:14:37 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA12433
	for <w3c-dist-auth@w3c.org>; Sun, 15 Sep 2002 14:14:37 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Sun, 15 Sep 2002 14:14:06 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Sun, 15 Sep 2002 14:14:06 -0400
Received: from xythoslap ([198.144.203.248]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Sun, 15 Sep 2002 14:13:51 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Sun, 15 Sep 2002 11:13:50 -0700
Message-ID: <000101c25ce3$a5387f30$29c4fea9@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 15 Sep 2002 18:13:51.0618 (UTC) FILETIME=[A50C6620:01C25CE3]
Subject: Interop issue: Can we require clients to accept cookies?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6634
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>
Content-Transfer-Encoding: 7bit



RFC 2518 is silent on cookies.  It requires support for RFC2068 (now
RFC2616), but does not reference the HTTP Cookie RFC (RFC 2965).

Some WebDAV servers, however, rely on setting cookies to keep a session
for an unauthenticated user. For Basic authentication, cookies can
vastly reduce the number of times a nearly-clear-text password is sent
over the network, so cookies can make the interaction more secure.
Session cookies are less secure than Digest authentication, however
servers with low security requirements and high performance requirements
may prefer to use cookies.

In addition to being used for keeping sessions, cookies may be used to
keep track of other client preferences (this is theoretical as I do not
know of any actual examples).

Thus, it was proposed that RFC2518 bis reference RFC2965, and say that
"clients SHOULD support cookies". 

Discuss?
Lisa



From w3c-dist-auth-request@w3.org  Sun Sep 15 15:09:52 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09393
	for <webdav-archive@lists.ietf.org>; Sun, 15 Sep 2002 15:09:52 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8FJAKl03878;
	Sun, 15 Sep 2002 15:10:21 -0400 (EDT)
Resent-Date: Sun, 15 Sep 2002 15:10:21 -0400 (EDT)
Resent-Message-Id: <200209151910.g8FJAKl03878@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8FJAJI03852
	for <w3c-dist-auth@frink.w3.org>; Sun, 15 Sep 2002 15:10:19 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA17502
	for <w3c-dist-auth@w3c.org>; Sun, 15 Sep 2002 15:10:19 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Sun, 15 Sep 2002 15:09:48 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Sun, 15 Sep 2002 15:09:48 -0400
Received: from xythoslap ([198.144.203.248]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Sun, 15 Sep 2002 15:09:43 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Sun, 15 Sep 2002 12:09:37 -0700
Message-ID: <000901c25ceb$73684b40$29c4fea9@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 15 Sep 2002 19:09:44.0091 (UTC) FILETIME=[73472EB0:01C25CEB]
Subject: Notes for Sept 9 WG meeting (by Dennis Hamilton)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6636
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>
Content-Transfer-Encoding: 7bit




Interim WebDAV Meeting
2002-09-09 Session


Held at the University of California at Santa Cruz
during the September 2000 interoperability-confirmation tests

Last Updated 2002-09-10-13:05 -0700 (pdt)

  _____  


Attendance
<file:///A:\2002-09-09-WebDAV.htm#AttendancePreliminaries#AttendancePrel
iminaries>  and Preliminaries


Action <file:///A:\2002-09-09-WebDAV.htm#ActionItems#ActionItems>  Items


1. Agenda <file:///A:\2002-09-09-WebDAV.htm#Agenda#Agenda> 


2. ACL
<file:///A:\2002-09-09-WebDAV.htm#ACLSpecificationStatus#ACLSpecificatio
nStatus>  Status


3. DASL
<file:///A:\2002-09-09-WebDAV.htm#DASLSpecificationStatus#DASLSpecificat
ionStatus>  Status


4. Property
<file:///A:\2002-09-09-WebDAV.htm#PropertyRegistration#PropertyRegistrat
ion>  Registration


5. RFC 2518 bis <file:///A:\2002-09-09-WebDAV.htm#2518bis#2518bis>
Issues

  _____  


Attendance and Preliminaries


Attendees:


*	Lisa Dusseault, co-chair 
*	Jim Whitehead, co-chair 

[enter names from list circulated in the meeting]

We met upstairs from the Interop event, starting shortly after 3pm.

Dennis Hamilton agreed to take notes for this session.

Dan Brotsky requested that the group acknowledge the contribution that
Jason Crawford has made in managing the issues list.  There was nodded
ascent.

At the end, based on the amount of discussion and speed on the agenda,
it was agreed to change the September 10 session from 3-6pm to 1pm -
6pm.

The session ended promptly at 6pm.


Action Items


[who?] Communicate the working group's appreciation to Jason Crawford.

Dennis Hamilton: turn over notes from this session before he leaves on
09-10.

Lisa Dusseault: 

*         Provide links to her latest drafts of 2518bis for people to be
able to review. [done by e-mail to the list, 09-10] 

*         Circulate paragraph on what behavior for PropFind for members
of a collection MUST be implemented. 

Jim Whitehead: Contact Ned Freed about the workings of registration
procedures via IETF/IANA (re feasibility for use in Property
<file:///A:\2002-09-09-WebDAV.htm#PropertyRegistration#PropertyRegistrat
ion>  Registration)

Dan Brotsky: Send out a note on clarifying lock
<file:///A:\2002-09-09-WebDAV.htm#LockDiscovery#LockDiscovery>
discovery and that this not be defeated by servers refusing to disclose
the necessary information for lock discovery to be meaningful.

Ilya : Write the paragraph on forcing
<file:///A:\2002-09-09-WebDAV.htm#ForcingAuthentication#ForcingAuthentic
ation>  authentication that will go to the list and into RFC 1518 bis.


1. Agenda


In creating the agenda, Lisa remarks that the working group needs to
review its charter.  We agreed to carry this to the September 10
session.

Also there is a topic on Interoperability Process and what does 2 by 2
interoperability mean?  This was added in under the RFC 2518 bis
<file:///A:\2002-09-09-WebDAV.htm#2518bis#2518bis>  discussion.

1.      Kudos for Jason
<file:///A:\2002-09-09-WebDAV.htm#ActionItems#ActionItems>  -  

2.      Status of the ACL
<file:///A:\2002-09-09-WebDAV.htm#ACLSpecificationStatus#ACLSpecificatio
nStatus>  Specification and of DASL
<file:///A:\2002-09-09-WebDAV.htm#DASLSpecificationStatus#DASLSpecificat
ionStatus>  (Search) 

3.      Property Registration (15 minutes) 

4.      RFC 2518 bis <file:///A:\2002-09-09-WebDAV.htm#2518bis#2518bis>
issues  

o        Start with the ones on the board in the interoperability work 

o        Litmus tests 

o        Continue with others 


2. ACL Status


The ACL Status was summarized by Jim and Lisa:

1.      The specification is in the hands of the Area Director for
review.   

2.      The review process is slow and WebDAV is in spin-wait until it
is sent back for changes or posted as approved. 

3.      All known issues have been resolved in the document that is
under review. 


3. DASL Status


The DASL history was reviewed.  The DASL working group had been
disbanded after going inactive. Since then, Julian Reschke has been
maintaining the specification and posts versions as Internet Drafts,
providing an informal process on the side of WebDAV.

In the discussion:

1.      Lisa mentions that there are open problems around character sets
and languages that DASL will also bump into.  She provided a little
background on how difficult it is to make a successful specification
anywhere that there are character strings intended for human
interpretation.  Sorting is also a big concern, because collating
sequences have such variability at the international level. 

2.      The topic of how to advance more rapidly was raised, but no
suggestions came forth, beyond to continue encouraging Julian and
promote people working on it. 


4. Property Registration


Jim Whitehead provided an overview of the situation, raised by

*         So many properties being defined in 2518, and the allied
specifications, etc. 

*         People wanting to have a way to add properties and have them
be standardized in some sense 

Dennis provided some background on how this became a project on AIIM
(that he has been sandbagging for well over a year now).  The purpose is
provided on DMware site project description
(http://DMware.info/projects/P010100.htm).   

Dennis summarized the levels that seem to be of concern, and he came to
ask which level do people see as appropriate, and if that is the answer,
what is the problem that is being solved: 

*         That a property identification is taken and has been used 

*         That a property identification has been taken and the
authority on the property is so-and-so. 

*         That a property identification has been taken by so-and-so and
here is how to find a description of the property intended for human
comprehension 

*         That a property identification  ... and here's a description
intended for computer processing 

Dennis assumes that the last bullet is over the edge for the WebDAV
community, although it matters for managed documents when we look at
metadata discovery requirements and even model discovery requirements
(e.g., finding the rules for playing nice in manipulation of coordinated
WebDAV resources).  Dennis has been operating on the assumption that
there is room enough in WebDAV  for there to be private or
specific-community (i.e., vertical) agreements on properties (just like
there are so many flavors of XML agreements).  But there is also a sense
that some fundamental registration approach be agreed in the overall
community.

Jim Whitehead described his initial assumption that something like IANA
MIME-type registration could work for WebDAV properties.  Dennis said
that the requirement to put MIME-type specifications through the
Informational RFC process seemed particularly heavyweight and he thought
the community would want something easier to use.

In the discussion, it was suggested that once an overall procedure is
established, making additional submissions could be as simple as filling
out a form and then going through a registration process that gave rise
to an Informational RFC by a very simple process, along with appearance
on an IANA registry.  One benefit of using an IETF/IANA scheme is the
persistence of the IETF repository of rfcs, and its likely long-term
stability in contrast with anything that is maintained separately or by
a small group.

There was inconclusive discussion on how to follow up with IETF/IANA on
this.  Dennis said he had enough to put something on the list and widen
the discussion. Jim Whitehead is going to do check with Ned Freed on the
IETF/IANA protocol for having their agreement to register property
registrations.

It is also felt that the registry is needed for even the DAV:
properties, because there are so many and their status needs to be
maintained over time.  The registry mechanism is not exclusively for the
DAV: properties, but it is important to handle them.

The following explosion of topics was identified.  It became clear in
the discussion that creating a registration procedure and (especially)
agreeing on what to register about a property will push back on places
where the property model is not adequately or clearly specified.

1.      Registry for the DAV namespace and the rules for what are these,
which ones are being deprecated, and what to do with them.  The registry
is something that can be used to normalize the DAV namespace.   

2.      What to do about provisional, anticipatory, and experimental
ones that don't end up in a final specification. 

3.      Discussion of grandfathering and/or deprecating the stray DAV:
properties that aren't in the specification, or put (some) in the
specification 

4.      Discussion about DAV: as a reserved namespace and the business
of the URI of the namespace, DAV: as a URI prefix, etc. 

5.      Say what are the rules for the DAV namespace. 

6.      Dan Brotsky: The model for properties is not circumscribed
enough, but people want to know what the rules are --  

o        when can I be sure that a property will be dead,  

o        how I can find out if values have changed, and  

o        can the server enumerate this or that about the properties.   

o        The property model may not be tight enough.  There is also the
problem of the syntax of the values. 

7.      Jim Whitehead thinks that property access (read)
interoperability can come with some ease and property creation/setting
interoperability might take more.  We might want to take the easy case
first. 

8.      Jim Whitehead knows Ned Freed and this game would then work.
Then for us the question is what does the form look like and what kind
of things might not be OK to handle this way.  Needs to be discussed on
the mailing list. 

9.      What are the reasonable questions to answer on a property
registration questionnaire: 

o        Protected versus writable 

o        Name and namespace 

*         XML 1.1 recommendations on element and attribute names.  Any
XML language rules work 

o        Static or dynamic 

o        Live or dead 

*         Great discussion about the distinctions live and dead, etc.,
and what is going on here. 

o        authority defining the property 

o        syntax of values 

o        under what conditions will the property change 

o        configuration versus not 

o        syntax enforced versus not 

o        is it searchable? 

o        responds to PROPFIND ALL? 

o        cacheable? 

o        dependencies among properties 

o        notes - things not covered in other questions 

o        resource type that property defined on 

*         collection only? 

o        conditions under which property can be written 

o        terms and conditions of use, legal conditions 

o        questions about permanence of properties and invariance,
invariance of the definition - we must take a stand on this one way or
the other. 

o        inheritability -- it is a form of liveness 

o        date of definition 

o        software it appears in - who implements it 

o        review authority and acceptance of the definition 

*         DAV namespace properties 

*         Use of namespace 

*         Namespace registrations? 

10.  The work on this will drive tightening of the property model. 

11.  This list may not be complete, and what do we do?  Do we understand
enough to have a strawman list. 

12.  Dependent properties? 

13.  Semantics and syntax of the property 

We ended declaring that we had done enough (in much more than 15
minutes). 


5. 2518 bis Issues


5.1 Meta-discussion


We had a meta-discussion on the word "bis."  Lisa had assumed the word
is German.  Dennis thought it was French (because the ISO uses it).  We
concluded that this usage is probably from Latin.  [Checking a very
laptop translator dictionary: In Italian it is an adjective for "second"
and it is also used for "encore."  In French it has that and the sense
of "repeat" as well as being an adjective for a color (grayish-brown)
and an adverb for "twice."  In German it is the preposition for "until,
by, through." --dh:]


5.1.1 Interoperability Process


This conversation was in "bullets":

*         Need a quick breakage list 

*         Availability of free software (regarding testing and
confirmation) 

*         More clients in test 

*         Always-online clients 

*         Litmus and Litmus-like test suites available as clients 

*         Ways for servers to request tests from a client. 


5.1.2 Defining 2 by 2 interoperability


Question on what the IETF community definition is for this.  More
bullets:

*         WebDAV has done due diligence in that regard 

*         As much as has been done, the interoperability story isn't
that great 

o        pairwise confirmation of features is not the same as pairwise
confirmation of the feature set, and this leaves lots of disconnects 

*         Let's not make more work with the IETF 

*         But let's get to where it says WebDAV  on the box means there
are not any material problems that an user would have to deal with 


5.2 "Board" Issues


During the interoperability sessions on the first day, a number of
topics for breakage came up.


5.2.1 Breakage Involving Presumably-Resolved Issues


These are issues that are thought to have been resolved and
disambiguated in the specification, yet implementations are still
deviating.  These are areas where more is required, either in being
clear or in having more to a facility for it to work properly. 


5.2.1.1 Having lock information be discoverable


Clients need untampered ownership of a lock that the server does not
monkey with it, and in bis, servers are not supposed to muck with the
owner value, so what about servers being free to withhold elements of
lock discovery?

Either get all the information but be forbidden to discover the lock.

Brotsky to send out a note on this one.


5.2.1.2 How can clients force authentication?


The problem of not being made to authenticate until trying to write.
This leaves users in the awkward position of doing lots of work and
then, when it is time to put something, an unanticipated authentication
requirement comes up.

Question about how to force authentication at the beginning of a
"session" so that user doesn't do a lot of work and then be confronted
with an authentication requirement

Lisa likes the idea of using the header and working there.

Also, don't want to break the practice of forcing users to be
authenticated from the get-go.

Options that force authentication to write are desired.  Methods have
special fire-wall implications, and we got lost in hilarity about
methods prefixed by X-.

We fell back to Options.  

Brotsky offered the example of PROPPATCH of a read-only property, as a
roundabout way to provoke authentication.

We came  back to Options.

Prefer something like the connect specification.  Want to ask Julian to
write the rfc.  Ilya will write the paragraph that goes to the list and
into the spec.


5.2.1.3 Collections without the slash


All places where a URL is returned, if it is for a collection, the
specification says "should" provide the slash, not must.

When you say PropFind, the returned URLs should always have a slash
after the segment for a collection.  This segued into the overall
problem of PropFind responses for collections:


5.2.1.4 PropFind Responses for Collections


Are relative URLs allowed in propfind responses?

Jim W: So is this a spec language issue or is something needed in the
protocol?

Brotsky: Servers must not be confusing to clients and we need to see how
to do that.  We probably ought to do relatives more, it needs to be
relative to the URI in the request: relative, absolute, or fully
qualified (anything not fully qualified is considered a relative URI in
the specification) -- we have to be really careful about the
specification language

Difficulties are with the client handling the different cases of what
comes back.  

Brotsky says that servers must use proper internal URIs, and it is
strictly defined, in terms of internal member URI.  The question is can
the top level URI be different than the one the client offered.

Lots of discussion on prefixes of URIs, how to get around this.  And
whether servers are allowed to optimize the client's future behavior.
Brotsky wants the server to be gentle with the client.  In the case at
hand, the client is asking "tell me what the internal members of this
collection are."  If the server can return whatever it wants, the client
is under a terrible burden.

Lisa has some language for a MUST to add to the specification based on
presence of a content location header.

In the absence of a content location header, there is discussion about
not having the same level of MUST-ness for the request URL.

Conversation about what a client is, and Brotsky says that HTTP says.
Needs more discussion, and RFC 2518 may need to be more emphatic that it
is relying on the HTTP 1.1 definition of client and have people be clear
about the implications.


5.3 New Open Issues


We didn't get that far.  The September 10 meeting will begin at 1pm and
continue to 6pm to ensure coverage of more issues.

 




From w3c-dist-auth-request@w3.org  Sun Sep 15 16:47:03 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10838
	for <webdav-archive@lists.ietf.org>; Sun, 15 Sep 2002 16:47:03 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8FKhhF08566;
	Sun, 15 Sep 2002 16:43:43 -0400 (EDT)
Resent-Date: Sun, 15 Sep 2002 16:43:43 -0400 (EDT)
Resent-Message-Id: <200209152043.g8FKhhF08566@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8FKhgI08540
	for <w3c-dist-auth@frink.w3.org>; Sun, 15 Sep 2002 16:43:42 -0400 (EDT)
Received: from cpimssmtpu10.email.msn.com (cpimssmtpu10.email.msn.com [207.46.181.85])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA25755
	for <w3c-dist-auth@w3c.org>; Sun, 15 Sep 2002 16:43:42 -0400
Received: from centro ([63.231.39.60]) by cpimssmtpu10.email.msn.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Sun, 15 Sep 2002 13:42:07 -0700
Reply-To: <dennis.hamilton@acm.org>
From: "Dennis E. Hamilton" <dennis.hamilton@acm.org>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Sun, 15 Sep 2002 13:43:09 -0700
Message-ID: <NGBBIKAHMDNFPKNEPALEMEDPINAA.dennis.hamilton@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-reply-to: <000901c25ceb$73684b40$29c4fea9@xythoslap>
Importance: Normal
X-OriginalArrivalTime: 15 Sep 2002 20:42:07.0756 (UTC) FILETIME=[5B8F54C0:01C25CF8]
Subject: RE: Notes for Sept 9 WG meeting (by Dennis Hamilton) - HTML Available
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6637
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>
Content-Transfer-Encoding: 7bit


The HTML version of these notes is at

	http://DMware.info/WebDAV/2002-09-09-WebDAV.htm

It is identical except the shortcuts work and I added Ilya's full name in
the action items.

-- Dennis

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
Sent: Sunday, September 15, 2002 12:10
To: Webdav WG
Subject: Notes for Sept 9 WG meeting (by Dennis Hamilton)





Interim WebDAV Meeting
2002-09-09 Session


Held at the University of California at Santa Cruz
during the September 2000 interoperability-confirmation tests

Last Updated 2002-09-10-13:05 -0700 (pdt)






From w3c-dist-auth-request@w3.org  Mon Sep 16 01:01:08 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17118
	for <webdav-archive@lists.ietf.org>; Mon, 16 Sep 2002 01:01:07 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8G51jX10125;
	Mon, 16 Sep 2002 01:01:45 -0400 (EDT)
Resent-Date: Mon, 16 Sep 2002 01:01:45 -0400 (EDT)
Resent-Message-Id: <200209160501.g8G51jX10125@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8G51aI10055
	for <w3c-dist-auth@frink.w3.org>; Mon, 16 Sep 2002 01:01:36 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA11480
	for <w3c-dist-auth@w3c.org>; Mon, 16 Sep 2002 01:01:34 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id WAA32076 sender ccjason@us.ibm.com for w3c-dist-auth@w3c.org; Sun, 15 Sep 2002 22:01:26 -0700
Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by sunbelt.seagull.net (8.9.3) with ESMTP id WAA32028 sender ccjason@us.ibm.com; Sun, 15 Sep 2002 22:01:23 -0700
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8G50plg037902; Mon, 16 Sep 2002 01:00:51 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8G50osC126158; Mon, 16 Sep 2002 01:00:51 -0400
To: "Lisa Dusseault" <nnlisa___at___xythos.com@smallcue.com>
Cc: "Webdav WG" <nnw3c-dist-auth___at___w3c.org@smallcue.com>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF1E4FFDED.A8C2A281-ON85256C36.0009E0DD@us.ibm.com>
From: Jason Crawford <ccjason@us.ibm.com>
Date: Sun, 15 Sep 2002 21:50:04 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_09122002|September 12, 2002) at 09/16/2002 01:00:50
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: Re: Interop issue: Can we require clients to accept cookies?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6640
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>





> Thus, it was proposed that RFC2518 bis reference RFC2965, and say that
> "clients SHOULD support cookies".

My first impression is that I wouldn't want anything stronger than this.
It doesn't seem like something that's strictly required.  Just something
that appears to be prudent in a quality product.


------------------------------------------
Phone: 914-784-7569



From w3c-dist-auth-request@w3.org  Mon Sep 16 01:47:08 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17119
	for <webdav-archive@lists.ietf.org>; Mon, 16 Sep 2002 01:01:07 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8G51bX10085;
	Mon, 16 Sep 2002 01:01:37 -0400 (EDT)
Resent-Date: Mon, 16 Sep 2002 01:01:37 -0400 (EDT)
Resent-Message-Id: <200209160501.g8G51bX10085@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8G51aI10038
	for <w3c-dist-auth@frink.w3.org>; Mon, 16 Sep 2002 01:01:36 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA11479
	for <w3c-dist-auth@w3c.org>; Mon, 16 Sep 2002 01:01:34 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id WAA32069 sender ccjason@us.ibm.com for w3c-dist-auth@w3c.org; Sun, 15 Sep 2002 22:01:26 -0700
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by sunbelt.seagull.net (8.9.3) with ESMTP id WAA32027 sender ccjason@us.ibm.com; Sun, 15 Sep 2002 22:01:23 -0700
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8G50olN019002; Mon, 16 Sep 2002 01:00:50 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8G50nsC017162; Mon, 16 Sep 2002 01:00:49 -0400
To: <nndennis.hamilton___at___acm.org@smallcue.com>
Cc: "Webdav WG" <nnw3c-dist-auth___at___w3c.org@smallcue.com>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFB87AE51A.0018295F-ON85256C36.0009AB51@us.ibm.com>
From: Jason Crawford <ccjason@us.ibm.com>
Date: Sun, 15 Sep 2002 21:47:24 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_09122002|September 12, 2002) at 09/16/2002 01:00:49
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: RE: Notes for Sept 9 WG meeting (by Dennis Hamilton) - HTML Available
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6639
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>





Wow.  You guys did great.

Thanks for the recognition.  It sounds like Lisa and Jim and everyone did a
great job.

I'll do my best to get everything you guys listed on to the issues list.

J.

------------------------------------------
Phone: 914-784-7569



From w3c-dist-auth-request@w3.org  Mon Sep 16 01:47:09 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17115
	for <webdav-archive@lists.ietf.org>; Mon, 16 Sep 2002 01:01:07 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8G51Y410033;
	Mon, 16 Sep 2002 01:01:34 -0400 (EDT)
Resent-Date: Mon, 16 Sep 2002 01:01:34 -0400 (EDT)
Resent-Message-Id: <200209160501.g8G51Y410033@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8G51VI10003
	for <w3c-dist-auth@frink.w3.org>; Mon, 16 Sep 2002 01:01:31 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA11477
	for <w3c-dist-auth@w3c.org>; Mon, 16 Sep 2002 01:01:30 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id WAA32084 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Sun, 15 Sep 2002 22:01:26 -0700
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by sunbelt.seagull.net (8.9.3) with ESMTP id WAA32029 sender obsfucated@us.ibm.com; Sun, 15 Sep 2002 22:01:24 -0700
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8G50qIV006392; Mon, 16 Sep 2002 01:00:52 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8G50qgg108114; Mon, 16 Sep 2002 01:00:52 -0400
To: "Lisa Dusseault" <lisa@xythos.com>
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF0B0E0B30.9C69F241-ON85256C36.000A6C69@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Sun, 15 Sep 2002 21:55:14 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_09122002|September 12, 2002) at 09/16/2002 01:00:51
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: Re: Interop issue: Proposal for fixing lock token provision
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6638
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>





> 1. Clients should be able to provide lock tokens in conditional requests
> that cause the request to fail if the token does not still match the
> state. This goal is currently met by the If header, but this goal must
> continue to be met by any new solution.

Could someone say more about this.  An example of why a client might
want this would complete the picture.


------------------------------------------
Phone: 914-784-7569



From w3c-dist-auth-request@w3.org  Mon Sep 16 06:10:26 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29530
	for <webdav-archive@lists.ietf.org>; Mon, 16 Sep 2002 06:10:26 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8GAAmb11603;
	Mon, 16 Sep 2002 06:10:48 -0400 (EDT)
Resent-Date: Mon, 16 Sep 2002 06:10:48 -0400 (EDT)
Resent-Message-Id: <200209161010.g8GAAmb11603@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8GAAkI11576
	for <w3c-dist-auth@frink.w3.org>; Mon, 16 Sep 2002 06:10:46 -0400 (EDT)
Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA17077
	for <w3c-dist-auth@w3c.org>; Mon, 16 Sep 2002 06:10:45 -0400
Received: from manyfish.co.uk ([62.253.142.7]) by mta06-svc.ntlworld.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20020916101044.PFMG295.mta06-svc.ntlworld.com@manyfish.co.uk>
          for <w3c-dist-auth@w3c.org>; Mon, 16 Sep 2002 11:10:44 +0100
Received: (from joe@localhost)
	by manyfish.co.uk (8.11.6/8.11.6) id g8GAAi329717
	for w3c-dist-auth@w3c.org; Mon, 16 Sep 2002 11:10:44 +0100
Date: Mon, 16 Sep 2002 11:10:44 +0100
From: Joe Orton <joe@manyfish.co.uk>
To: Webdav WG <w3c-dist-auth@w3c.org>
Message-ID: <20020916111044.A29690@light.plus.com>
Mail-Followup-To: Webdav WG <w3c-dist-auth@w3c.org>
References: <000101c25ce3$a5387f30$29c4fea9@xythoslap>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <000101c25ce3$a5387f30$29c4fea9@xythoslap>; from lisa@xythos.com on Sun, Sep 15, 2002 at 11:13:50AM -0700
Subject: Re: Interop issue: Can we require clients to accept cookies?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6641
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>


On Sun, Sep 15, 2002 at 11:13:50AM -0700, Lisa Dusseault wrote:
> RFC 2518 is silent on cookies.  It requires support for RFC2068 (now
> RFC2616), but does not reference the HTTP Cookie RFC (RFC 2965).
> 
> Some WebDAV servers, however, rely on setting cookies to keep a session
> for an unauthenticated user. For Basic authentication, cookies can
> vastly reduce the number of times a nearly-clear-text password is sent
> over the network, so cookies can make the interaction more secure.
>
> Session cookies are less secure than Digest authentication, however
> servers with low security requirements and high performance requirements
> may prefer to use cookies.
>
> In addition to being used for keeping sessions, cookies may be used to
> keep track of other client preferences (this is theoretical as I do not
> know of any actual examples).
> 
> Thus, it was proposed that RFC2518 bis reference RFC2965, and say that
> "clients SHOULD support cookies". 

I'd strongly oppose that and hope the DAV spec remains silent on cookie
support.  There is a whole section in RFC2964 discouraging the use of
cookies as an authentication mechanism.

Regards,

joe






From w3c-dist-auth-request@w3.org  Mon Sep 16 06:16:51 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29616
	for <webdav-archive@lists.ietf.org>; Mon, 16 Sep 2002 06:16:51 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8GAHaE12135;
	Mon, 16 Sep 2002 06:17:36 -0400 (EDT)
Resent-Date: Mon, 16 Sep 2002 06:17:36 -0400 (EDT)
Resent-Message-Id: <200209161017.g8GAHaE12135@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8GAHZI12091
	for <w3c-dist-auth@frink.w3.org>; Mon, 16 Sep 2002 06:17:35 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with SMTP id GAA17967
	for <w3c-dist-auth@w3c.org>; Mon, 16 Sep 2002 06:17:35 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3c.org>; Mon, 16 Sep 2002 12:17:02 +0200
Date: Mon, 16 Sep 2002 10:44:00 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
To: "Lisa Dusseault" <lisa@xythos.com>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <000101c25ce3$a5387f30$29c4fea9@xythoslap>
Message-Id: <726C697C-C950-11D6-9F78-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.482)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: Interop issue: Can we require clients to accept cookies?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6642
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>
Content-Transfer-Encoding: 7bit



Am Sonntag den, 15. September 2002, um 20:13, schrieb Lisa Dusseault:
>
> RFC 2518 is silent on cookies.  It requires support for RFC2068 (now
> RFC2616), but does not reference the HTTP Cookie RFC (RFC 2965).
>
> Some WebDAV servers, however, rely on setting cookies to keep a session
> for an unauthenticated user. For Basic authentication, cookies can
> vastly reduce the number of times a nearly-clear-text password is sent
> over the network, so cookies can make the interaction more secure.
> Session cookies are less secure than Digest authentication, however
> servers with low security requirements and high performance 
> requirements
> may prefer to use cookies.
>
> In addition to being used for keeping sessions, cookies may be used to
> keep track of other client preferences (this is theoretical as I do not
> know of any actual examples).
>
> Thus, it was proposed that RFC2518 bis reference RFC2965, and say that
> "clients SHOULD support cookies".

I think we agree that a server should not depend on the client
handling cookies. WebDAV needs to function without them.

Therefore the spec should not mention them. I see the risk that
servers or client implementors might be tempted to rely on it.

It is certainly a good idea to collect implementation advice in
some FAQ or the webdav book of why.

//Stefan




From w3c-dist-auth-request@w3.org  Mon Sep 16 06:20:46 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29656
	for <webdav-archive@lists.ietf.org>; Mon, 16 Sep 2002 06:20:46 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8GALYC13082;
	Mon, 16 Sep 2002 06:21:34 -0400 (EDT)
Resent-Date: Mon, 16 Sep 2002 06:21:34 -0400 (EDT)
Resent-Message-Id: <200209161021.g8GALYC13082@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8GALXI13055
	for <w3c-dist-auth@frink.w3.org>; Mon, 16 Sep 2002 06:21:33 -0400 (EDT)
Received: from mta05-svc.ntlworld.com (mta05-svc.ntlworld.com [62.253.162.45])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA18534
	for <w3c-dist-auth@w3.org>; Mon, 16 Sep 2002 06:21:33 -0400
Received: from manyfish.co.uk ([62.253.142.7]) by mta05-svc.ntlworld.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20020916102133.ZWNN14766.mta05-svc.ntlworld.com@manyfish.co.uk>;
          Mon, 16 Sep 2002 11:21:33 +0100
Received: (from joe@localhost)
	by manyfish.co.uk (8.11.6/8.11.6) id g8GALWa29731;
	Mon, 16 Sep 2002 11:21:32 +0100
Date: Mon, 16 Sep 2002 11:21:32 +0100
From: Joe Orton <joe@manyfish.co.uk>
To: Jason Crawford <ccjason@us.ibm.com>
Cc: w3c-dist-auth@w3.org
Message-ID: <20020916112132.B29690@light.plus.com>
Mail-Followup-To: Jason Crawford <ccjason@us.ibm.com>, w3c-dist-auth@w3.org
References: <OF1E4FFDED.A8C2A281-ON85256C36.0009E0DD@us.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <OF1E4FFDED.A8C2A281-ON85256C36.0009E0DD@us.ibm.com>; from ccjason@us.ibm.com on Sun, Sep 15, 2002 at 09:50:04PM -0400
Subject: Re: Interop issue: Can we require clients to accept cookies?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6643
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>


On Sun, Sep 15, 2002 at 09:50:04PM -0400, Jason Crawford wrote:
> > Thus, it was proposed that RFC2518 bis reference RFC2965, and say that
> > "clients SHOULD support cookies".
> 
> My first impression is that I wouldn't want anything stronger than this.
> It doesn't seem like something that's strictly required.  Just something
> that appears to be prudent in a quality product.

Adding a "SHOULD" requirement that client authors implement a separate
26-page RFC would not appear to be prudent in a quality protocol spec.

Regards,

joe



From w3c-dist-auth-request@w3.org  Mon Sep 16 07:17:04 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00311
	for <webdav-archive@lists.ietf.org>; Mon, 16 Sep 2002 07:17:04 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8GBHer18362;
	Mon, 16 Sep 2002 07:17:40 -0400 (EDT)
Resent-Date: Mon, 16 Sep 2002 07:17:40 -0400 (EDT)
Resent-Message-Id: <200209161117.g8GBHer18362@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8GBHcI18332
	for <w3c-dist-auth@frink.w3.org>; Mon, 16 Sep 2002 07:17:38 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA27618
	for <w3c-dist-auth@w3c.org>; Mon, 16 Sep 2002 07:17:38 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 16 Sep 2002 07:07:02 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <SWGMXYNQ>; Mon, 16 Sep 2002 07:16:35 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B108258ECA@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: Webdav WG <w3c-dist-auth@w3c.org>
Date: Mon, 16 Sep 2002 07:16:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: Interop issue: Can we require clients to accept cookies?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6644
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>


I agree with Stefan (i.e. that nothing about cookies should
appear in 2518bis), for the reasons he states, unless I hear a
compelling argument for why clients should be required to accept
cookies in order for WebDAV to work properly.

Cheers,
Geoff

-----Original Message-----
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
Sent: Monday, September 16, 2002 4:44 AM
To: Lisa Dusseault
Cc: Webdav WG
Subject: Re: Interop issue: Can we require clients to accept cookies?




Am Sonntag den, 15. September 2002, um 20:13, schrieb Lisa Dusseault:
>
> RFC 2518 is silent on cookies.  It requires support for RFC2068 (now
> RFC2616), but does not reference the HTTP Cookie RFC (RFC 2965).
>
> Some WebDAV servers, however, rely on setting cookies to keep a session
> for an unauthenticated user. For Basic authentication, cookies can
> vastly reduce the number of times a nearly-clear-text password is sent
> over the network, so cookies can make the interaction more secure.
> Session cookies are less secure than Digest authentication, however
> servers with low security requirements and high performance 
> requirements
> may prefer to use cookies.
>
> In addition to being used for keeping sessions, cookies may be used to
> keep track of other client preferences (this is theoretical as I do not
> know of any actual examples).
>
> Thus, it was proposed that RFC2518 bis reference RFC2965, and say that
> "clients SHOULD support cookies".

I think we agree that a server should not depend on the client
handling cookies. WebDAV needs to function without them.

Therefore the spec should not mention them. I see the risk that
servers or client implementors might be tempted to rely on it.

It is certainly a good idea to collect implementation advice in
some FAQ or the webdav book of why.

//Stefan



From w3c-dist-auth-request@w3.org  Mon Sep 16 07:55:50 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01144
	for <webdav-archive@lists.ietf.org>; Mon, 16 Sep 2002 07:55:50 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8GBsjD22386;
	Mon, 16 Sep 2002 07:54:45 -0400 (EDT)
Resent-Date: Mon, 16 Sep 2002 07:54:45 -0400 (EDT)
Resent-Message-Id: <200209161154.g8GBsjD22386@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8GBshI22359
	for <w3c-dist-auth@frink.w3.org>; Mon, 16 Sep 2002 07:54:43 -0400 (EDT)
Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA01446
	for <w3c-dist-auth@w3.org>; Mon, 16 Sep 2002 07:54:42 -0400
Received: from daehub01.software-ag.de by server8a.software-ag.de; (8.11.6/8.9.3)
	id g8GBsaA11656; Mon, 16 Sep 2002 13:54:36 +0200
Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2653.19)
	id <TANADVP3>; Mon, 16 Sep 2002 13:54:20 +0200
Message-ID: <DFF2AC9E3583D511A21F0008C7E6210602E347CB@daemsg02.software-ag.de>
From: "Zaretzke, Peter" <Peter.Zaretzke@softwareag.com>
To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
Date: Mon, 16 Sep 2002 13:54:25 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C25D77.CDDB7C00"
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6645
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>


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

------_=_NextPart_001_01C25D77.CDDB7C00
Content-Type: text/plain

Some thoughts regarding the question "Who needs transactions with WebDAV?"

For me the major benefit of being able to control a transaction is
CONSISTENCY (and convenience). Keeping track of multiple dependent
modifications on WebDAV resources can become hard for a client and is
usually not what a application programmer wants to do. He wants to define
his "transaction" spanning multiple (WebDAV) calls and depending on the
return codes or his user decision he wants to commit or rollback
(all-or-nothing). Millions of SQL applications are working this way and I
can't see what is wrong with it.  

Batch processing does not really help here since some applications rely on
that intermediate modifications are available at the server, e.g. for query
purposes. Collecting modifications on the client would make query processing
far more complex since the server result has to be combined with the client
side modified resources. Additionally I would like to have the ability to
react on the return codes for single calls. BTW: processing a batch request
requires transactions on the server anyway (all-or-nothing), otherwise it
would be possible to create inconsistencies if the 3rd of 5 dependent PUTs
fails.  

Another aspect is working ISOLATION. Workspaces and activities are helpful
here. But creating something like a transaction with it, means programming
it on the client. Why should somebody re-invent the "transaction logging
wheel" in his application? Will somebody accept to go back to file-based
application programming style (without transactions) if he is familiar with
SQL database programming? 

For me it does not matter if the COMMIT, ROLLBACK methods are part of the
WebDAV protocol. If there is already a protocol that covers this - great,
let's take it and make it a (optional?) WebDAV extension like DASL or ACL.
But I definitely need server transactions to write complex WebDAV
applications without too complex coding. 

I see a WebDAV server as a Resource Manager like any database with nice
extensions like versioning, configuration management, etc. In my opinion a
successful general-purpose WebDAV server has to cover the common RM
features. I'm currently working on a Content Repository API on top of a
WebDAV server, which is intended to become compliant to JSR170
(http://www.jcp.org/jsr/detail/170.jsp
<http://www.jcp.org/jsr/detail/170.jsp> ) where transaction control is
planned to be part of Level 2. 

Any comments?

Peter
-------------------
Peter Zaretzke
Software AG


------_=_NextPart_001_01C25D77.CDDB7C00
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Proposal: WebDAV and transactions</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Some thoughts regarding the =
question &quot;Who needs transactions with WebDAV?&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">For me the major benefit of =
being able to control a transaction is CONSISTENCY (and convenience). =
Keeping track of multiple dependent modifications on WebDAV resources =
can become hard for a client and is usually not what a application =
programmer wants to do. He wants to define his &quot;transaction&quot; =
spanning multiple (WebDAV) calls and depending on the return codes or =
his user decision he wants to commit or rollback (all-or-nothing). =
Millions of SQL applications are working this way and I can't see what =
is wrong with it.&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Batch processing does not really =
help here since some applications rely on that intermediate =
modifications are available at the server, e.g. for query purposes. =
Collecting modifications on the client would make query processing far =
more complex since the server result has to be combined with the client =
side modified resources. Additionally I would like to have the ability =
to react on the return codes for single calls. BTW: processing a batch =
request requires transactions on the server anyway (all-or-nothing), =
otherwise it would be possible to create inconsistencies if the 3rd of =
5 dependent PUTs fails.&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Another aspect is working =
ISOLATION. Workspaces and activities are helpful here. But creating =
something like a transaction with it, means programming it on the =
client. Why should somebody re-invent the &quot;transaction logging =
wheel&quot; in his application? Will somebody accept to go back to =
file-based application programming style (without transactions) if he =
is familiar with SQL database programming? </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">For me it does not matter if the =
COMMIT, ROLLBACK methods are part of the WebDAV protocol. If there is =
already a protocol that covers this - great, let's take it and make it =
a (optional?) WebDAV extension like DASL or ACL. But I definitely need =
server transactions to write complex WebDAV applications without too =
complex coding. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">I see a WebDAV server as a =
Resource Manager like any database with nice extensions like =
versioning, configuration management, etc. In my opinion a successful =
general-purpose WebDAV server has to cover the common RM features. I'm =
currently working on a Content Repository API on top of a WebDAV =
server, which is intended to become compliant to JSR170 (</FONT><A =
HREF=3D"http://www.jcp.org/jsr/detail/170.jsp"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">http://www.jcp.org/jsr/detail/170.jsp</FONT></U></A><FONT SIZE=3D2 =
FACE=3D"Courier New">) where transaction control is planned to be part =
of Level 2. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Any comments?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Peter</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">-------------------</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Peter Zaretzke</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Software AG</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C25D77.CDDB7C00--



From w3c-dist-auth-request@w3.org  Mon Sep 16 09:23:48 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04232
	for <webdav-archive@lists.ietf.org>; Mon, 16 Sep 2002 09:23:48 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8GDOFc03592;
	Mon, 16 Sep 2002 09:24:15 -0400 (EDT)
Resent-Date: Mon, 16 Sep 2002 09:24:15 -0400 (EDT)
Resent-Message-Id: <200209161324.g8GDOFc03592@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8GDODI03564
	for <w3c-dist-auth@frink.w3.org>; Mon, 16 Sep 2002 09:24:13 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA17934
	for <w3c-dist-auth@w3c.org>; Mon, 16 Sep 2002 09:24:13 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 16 Sep 2002 08:44:25 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <SWGMX7QA>; Mon, 16 Sep 2002 08:54:06 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B108258EED@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: Webdav WG <w3c-dist-auth@w3c.org>
Date: Mon, 16 Sep 2002 08:54:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: Issue: Requiring server to use / terminated URL for returned coll 	ections
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6646
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>


I strongly object to adding a MUST for servers returning slash
terminated URLs for collections.

Most repositories do not allow trailing segment-separator characters
in the segment name of a resource, and therefore these trailing
segment-separator characters are commonly just stripped off before
that segment name is stored in the repository.  This means that in
order to decide whether to add the segement-separator character back
on, the implementation must query the repository for the type of each
resource identified by that segment.  Forcing this cost on the server
is only justified if it provides some compelling benefit to the
client.

The only concrete motivation I have heard for making this requirement
is to save a 302 redirect round trip for a client when the server
redirects a GET request on a collection to an internal member of the
request-URL (e.g. redirects "GET /foo" to "GET /foo/index.html").
Having the trailing slash present in the request-URL allows the server
to silently redirect the request to the internal member of the
request-URL without breaking client-side relative reference
processing.

But no WebDAV methods other than GET is redirected in this
fashion, and WebDAV clients will commonly not be doing a GET on a
collection (they will be doing a PROPFIND, and use the results to
construct a display), and so the overall benefit to a client of
avoiding a redirect on a GET to a collection is significantly
outweighed by the server cycles being wasted to determine whether or
not a collection member is a collection.

If a client cares whether or not a resource is a collection, it
can do a PROPFIND for its DAV:resourcetype.  That way, server
cycles are spent only when needed.

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Sunday, September 15, 2002 2:14 PM
Subject: Issues from Interop/Interim WG Meeting

...
- Servers must use trailing slash whenever collection URLs are returned.
Language proposed for 2518 bis
...



From w3c-dist-auth-request@w3.org  Mon Sep 16 09:58:40 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05439
	for <webdav-archive@lists.ietf.org>; Mon, 16 Sep 2002 09:58:39 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8GDwxV10385;
	Mon, 16 Sep 2002 09:58:59 -0400 (EDT)
Resent-Date: Mon, 16 Sep 2002 09:58:59 -0400 (EDT)
Resent-Message-Id: <200209161358.g8GDwxV10385@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8GDwvI10359
	for <w3c-dist-auth@frink.w3.org>; Mon, 16 Sep 2002 09:58:57 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA28343
	for <w3c-dist-auth@w3.org>; Mon, 16 Sep 2002 09:58:57 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 16 Sep 2002 09:32:41 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <SWGMX9L9>; Mon, 16 Sep 2002 09:41:15 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B108258F1A@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
Date: Mon, 16 Sep 2002 09:41:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6647
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>


Just to be clear here, I wasn't suggesting that we actually use the
DeltaV protocol as a WebDAV transaction protocol.  You need different
versioning and transactioning methods for a server that supports both
versioning and transactions, so that a client can say whether it wants
versioning behavior or transactioning behavior.

I was just making the point that a repository that supported
transactions (but not versioning) could sensibly interact with a
DeltaV client by defining transaction boundaries on certain DeltaV
constructs.  Conversely, depending on how the transactioning
protocol is defined, a repository that supported versioning
(but not transactions) might be able to sensibly interoperate
with a transactioning client by mapping the transactioning
requests into server-side workspace functionality.

Cheers,
Geoff

-----Original Message-----
From: Zaretzke, Peter [mailto:Peter.Zaretzke@softwareag.com]
Sent: Monday, September 16, 2002 7:54 AM
To: 'w3c-dist-auth@w3.org'
Subject: RE: Proposal: WebDAV and transactions


Some thoughts regarding the question "Who needs transactions with WebDAV?" 
For me the major benefit of being able to control a transaction is
CONSISTENCY (and convenience). Keeping track of multiple dependent
modifications on WebDAV resources can become hard for a client and is
usually not what a application programmer wants to do. He wants to define
his "transaction" spanning multiple (WebDAV) calls and depending on the
return codes or his user decision he wants to commit or rollback
(all-or-nothing). Millions of SQL applications are working this way and I
can't see what is wrong with it.  
Batch processing does not really help here since some applications rely on
that intermediate modifications are available at the server, e.g. for query
purposes. Collecting modifications on the client would make query processing
far more complex since the server result has to be combined with the client
side modified resources. Additionally I would like to have the ability to
react on the return codes for single calls. BTW: processing a batch request
requires transactions on the server anyway (all-or-nothing), otherwise it
would be possible to create inconsistencies if the 3rd of 5 dependent PUTs
fails.  
Another aspect is working ISOLATION. Workspaces and activities are helpful
here. But creating something like a transaction with it, means programming
it on the client. Why should somebody re-invent the "transaction logging
wheel" in his application? Will somebody accept to go back to file-based
application programming style (without transactions) if he is familiar with
SQL database programming? 
For me it does not matter if the COMMIT, ROLLBACK methods are part of the
WebDAV protocol. If there is already a protocol that covers this - great,
let's take it and make it a (optional?) WebDAV extension like DASL or ACL.
But I definitely need server transactions to write complex WebDAV
applications without too complex coding. 
I see a WebDAV server as a Resource Manager like any database with nice
extensions like versioning, configuration management, etc. In my opinion a
successful general-purpose WebDAV server has to cover the common RM
features. I'm currently working on a Content Repository API on top of a
WebDAV server, which is intended to become compliant to JSR170
(http://www.jcp.org/jsr/detail/170.jsp) where transaction control is planned
to be part of Level 2. 
Any comments? 



From w3c-dist-auth-request@w3.org  Mon Sep 16 10:08:58 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05731
	for <webdav-archive@lists.ietf.org>; Mon, 16 Sep 2002 10:08:58 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8GE9Dx12927;
	Mon, 16 Sep 2002 10:09:13 -0400 (EDT)
Resent-Date: Mon, 16 Sep 2002 10:09:13 -0400 (EDT)
Resent-Message-Id: <200209161409.g8GE9Dx12927@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8GE9CI12896
	for <w3c-dist-auth@frink.w3.org>; Mon, 16 Sep 2002 10:09:12 -0400 (EDT)
Received: from cpimssmtpu04.email.msn.com (cpimssmtpu04.email.msn.com [207.46.181.80])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA32342
	for <w3c-dist-auth@w3.org>; Mon, 16 Sep 2002 10:09:12 -0400
Received: from centro ([63.231.39.60]) by cpimssmtpu04.email.msn.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 16 Sep 2002 07:07:38 -0700
Reply-To: <dennis.hamilton@acm.org>
From: "Dennis E. Hamilton" <dennis.hamilton@acm.org>
To: "Zaretzke, Peter" <Peter.Zaretzke@softwareag.com>
Cc: "Bernard Chester" <bchester@imergeconsult.com>, <w3c-dist-auth@w3.org>,
        <Juergen.Pill@softwareag.com>
Date: Mon, 16 Sep 2002 07:08:38 -0700
Message-ID: <NGBBIKAHMDNFPKNEPALEIEEGINAA.dennis.hamilton@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <DFF2AC9E3583D511A21F0008C7E6210602E347CB@daemsg02.software-ag.de>
X-OriginalArrivalTime: 16 Sep 2002 14:07:38.0146 (UTC) FILETIME=[69C93820:01C25D8A]
Subject: RE: Proposal: WebDAV and transactions
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6648
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>
Content-Transfer-Encoding: 7bit


Peter,

Thank you for your comments, and also for the link to the JSR170 work.  This
is a very useful perspective on the integration requirements of content
repositories and I say it applies just as strongly for integration of
managed documents in content services.  I will make sure that other
organizations are aware of this initiative and also of the requirements that
are emerging around WebDAV integration in transactional applications.

Personally, I resonate with your thoughts around providing developers ways
to reuse common skills and patterns in developing transaction-protected
operation sequences and especially the testing and verification of them.

It is an interesting idea to see how transaction control could be introduced
as a supplementary standard in a way that serves HTTP and its WebDAV
extensions.  Something to think about.  I think WebDAV developers would have
a strong interest in that to the degree it impacts the appeal of WebDAV
servers for integration into enterprise applications.

-- Dennis

Dennis E. Hamilton
AIIM DMware Technical Coordinator
------------------
mailto:dennis.hamilton@acm.org  tel. +1-206-932-6970
http://DMware.info/             cel. +1-206-779-9430
     ODMA Support http://ODMA.info/

-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Zaretzke, Peter
Sent: Monday, September 16, 2002 04:54
To: 'w3c-dist-auth@w3.org'
Subject: RE: Proposal: WebDAV and transactions


Some thoughts regarding the question "Who needs transactions with WebDAV?"

[ ... ]

I'm currently working on a Content Repository API on top of a WebDAV server,
which is intended to become compliant to JSR170
(http://www.jcp.org/jsr/detail/170.jsp) where transaction control is planned
to be part of Level 2.

Any comments?
Peter
-------------------
Peter Zaretzke
Software AG




From w3c-dist-auth-request@w3.org  Mon Sep 16 16:41:05 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16632
	for <webdav-archive@lists.ietf.org>; Mon, 16 Sep 2002 16:41:04 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8GKfCG07119;
	Mon, 16 Sep 2002 16:41:12 -0400 (EDT)
Resent-Date: Mon, 16 Sep 2002 16:41:12 -0400 (EDT)
Resent-Message-Id: <200209162041.g8GKfCG07119@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8GKfBI07091
	for <w3c-dist-auth@frink.w3.org>; Mon, 16 Sep 2002 16:41:11 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA24549
	for <w3c-dist-auth@w3c.org>; Mon, 16 Sep 2002 16:41:10 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Mon, 16 Sep 2002 16:40:27 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Mon, 16 Sep 2002 16:40:27 -0400
Received: from xythoslap ([216.36.77.241]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Mon, 16 Sep 2002 16:40:04 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Clemm, Geoff'" <gclemm@rational.com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Mon, 16 Sep 2002 13:40:03 -0700
Message-ID: <002a01c25dc1$3c4a2a80$b701a8c0@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B108258EED@SUS-MA1IT01>
X-OriginalArrivalTime: 16 Sep 2002 20:40:04.0415 (UTC) FILETIME=[3C74BCF0:01C25DC1]
Subject: RE: Issue: Requiring server to use / terminated URL for returned coll 	ections
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6649
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>
Content-Transfer-Encoding: 7bit


I'll try to recall more of the interop issues around using trailing
slashes in collection URLs.  If anybody else can remember details,
please fill in.
(Dan B?)

> Most repositories do not allow trailing segment-separator characters
> in the segment name of a resource, and therefore these trailing
> segment-separator characters are commonly just stripped off before
> that segment name is stored in the repository.  This means that in
> order to decide whether to add the segement-separator character back
> on, the implementation must query the repository for the type of each
> resource identified by that segment.  Forcing this cost on the server
> is only justified if it provides some compelling benefit to the
> client.

Yes, the server must know the type of each resource in order to
construct its URL properly. Or the repository could save or cache the
URL for each resource. There are lots of options.

> The only concrete motivation I have heard for making this requirement
> is to save a 302 redirect round trip for a client when the server
> redirects a GET request on a collection to an internal member of the
> request-URL (e.g. redirects "GET /foo" to "GET /foo/index.html").
> Having the trailing slash present in the request-URL allows the server
> to silently redirect the request to the internal member of the
> request-URL without breaking client-side relative reference
> processing.

There are other problems encountered and discussed at the interop.  In
fact, the GET/redirect problem is one of the least troublesome because
it's just a performance problem, not (typically) an interoperability
problem.
 - Clients aren't consistent in supporting redirects for other methods
besides GET. Yet if the client sends a bad Request-URI (a collection
path without a trailing slash), the server needs to do something.
 - Servers aren't consistent in putting the trailing slash in various
places: the Content-Location header, the Location header, and <href>
elements inside Multi-Status. Clients need to look for the trailing
slash and possibly add it in order to be able to do further operations.
E.g. clients would like to be able to display results consistently in
folder views, yet servers aren't consistent.
 - Clients need to know how to generate a correct URL for a MKCOL, PUT,
MOVE or COPY to create a new resource in an existing collection. This
means parsing the collection URL to make sure it ends in a slash before
adding the terminal part.

> But no WebDAV methods other than GET is redirected in this
> fashion, and WebDAV clients will commonly not be doing a GET on a
> collection (they will be doing a PROPFIND, and use the results to
> construct a display), and so the overall benefit to a client of
> avoiding a redirect on a GET to a collection is significantly
> outweighed by the server cycles being wasted to determine whether or
> not a collection member is a collection.

First, this is an issue not only for GET.  The problems with other
methods are not just redirects, but how the client constructs URLs for
new resources.  

Second, it's a matter of opinion what situation has what benefits and
which wastes cycles where. Certainly avoiding redirects improves
performance for the client because it reduces roundtrips. Also providing
correct URLs saves cycles on the client although that's usually less of
a concern.  Note that for some servers, a redirect is higher cost than
just making the URLs correct, because a redirect is an entirely new
request, new database or filesystem query, etc.

> If a client cares whether or not a resource is a collection, it
> can do a PROPFIND for its DAV:resourcetype.  That way, server
> cycles are spent only when needed.

It's not only that the client cares what type of resource the URL refers
to, although knowing that is nice. It's also how to construct correct
new URLs and how to interpret the results of a PROPFIND.

Since there have been actual interoperability problems, I still find
this a good candidate for making the specification clearer, even if this
is a few more cycles on the server. Real interoperability problems are
much worse problems than a minor increased burden on the server.

Lisa

> 
> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Sunday, September 15, 2002 2:14 PM
> Subject: Issues from Interop/Interim WG Meeting
> 
> ...
> - Servers must use trailing slash whenever collection URLs are
returned.
> Language proposed for 2518 bis
> ...



From w3c-dist-auth-request@w3.org  Mon Sep 16 16:48:00 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16805
	for <webdav-archive@lists.ietf.org>; Mon, 16 Sep 2002 16:48:00 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8GKmZQ08503;
	Mon, 16 Sep 2002 16:48:35 -0400 (EDT)
Resent-Date: Mon, 16 Sep 2002 16:48:35 -0400 (EDT)
Resent-Message-Id: <200209162048.g8GKmZQ08503@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8GKmYI08477
	for <w3c-dist-auth@frink.w3.org>; Mon, 16 Sep 2002 16:48:34 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA26018
	for <w3c-dist-auth@w3c.org>; Mon, 16 Sep 2002 16:48:34 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Mon, 16 Sep 2002 16:47:16 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Mon, 16 Sep 2002 16:47:14 -0400
Received: from xythoslap ([216.36.77.241]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Mon, 16 Sep 2002 16:46:51 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Jason Crawford'" <nn683849@smallcue.com>
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Mon, 16 Sep 2002 13:46:50 -0700
Message-ID: <002c01c25dc2$2eff5840$b701a8c0@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <OF0B0E0B30.9C69F241-ON85256C36.000A6C69@us.ibm.com>
X-OriginalArrivalTime: 16 Sep 2002 20:46:51.0613 (UTC) FILETIME=[2F2A38D0:01C25DC2]
Subject: RE: Interop issue: Proposal for fixing lock token provision
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6650
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>
Content-Transfer-Encoding: 7bit


The original WebDAV plan for locks was that the client would LOCK the
resource, then GET, then issue PUT.  The client only wants this PUT
request to succeed if the lock was still there.  This avoids the lost
update problem if the lock disappeared somehow and the resource was
changed in between the GET and the PUT.  This goal can be accomplished
by putting the lock token in an IF header.  That's why we need to keep
the existing behaviour, which is reflected in goal #1 which you quoted.
(Note that this is necessary for those servers that do not support ETags
even though they MUST)

However, an even better approach is for the client to LOCK the resource,
then GET (note the ETag), then issue a PUT with the ETag in the If-Match
header. This way, the request is really testing directly to see if the
resource has changed, rather than whether the lock is still there.  The
request can succeed if the lock is gone away, as long as the resource
has not been updated.  This scenario is met by goal #2 (not quoted)

lisa

> -----Original Message-----
> From: Jason Crawford [mailto:nn683849@smallcue.com]
> Sent: Sunday, September 15, 2002 6:55 PM
> To: Lisa Dusseault
> Cc: 'Webdav WG'
> Subject: Re: Interop issue: Proposal for fixing lock token provision
> 
> 
> 
> 
> > 1. Clients should be able to provide lock tokens in conditional
requests
> > that cause the request to fail if the token does not still match the
> > state. This goal is currently met by the If header, but this goal
must
> > continue to be met by any new solution.
> 
> Could someone say more about this.  An example of why a client might
> want this would complete the picture.
> 
> 
> ------------------------------------------
> Phone: 914-784-7569



From w3c-dist-auth-request@w3.org  Mon Sep 16 19:33:16 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19933
	for <webdav-archive@lists.ietf.org>; Mon, 16 Sep 2002 19:33:16 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8GNY1029665;
	Mon, 16 Sep 2002 19:34:01 -0400 (EDT)
Resent-Date: Mon, 16 Sep 2002 19:34:01 -0400 (EDT)
Resent-Message-Id: <200209162334.g8GNY1029665@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8GNY0I29639
	for <w3c-dist-auth@frink.w3.org>; Mon, 16 Sep 2002 19:34:00 -0400 (EDT)
Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA24321
	for <w3c-dist-auth@w3c.org>; Mon, 16 Sep 2002 19:33:59 -0400
Received: from inet-mail1.oracle.com (localhost [127.0.0.1])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8GNXTe12232
	for <w3c-dist-auth@w3c.org>; Mon, 16 Sep 2002 16:33:29 -0700 (PDT)
Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8GNXSC12206
	for <w3c-dist-auth@w3c.org>; Mon, 16 Sep 2002 16:33:28 -0700 (PDT)
Received: from oracle.com (ikirnos-pc.us.oracle.com [130.35.68.81])
	by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8GNXRN20867
	for <w3c-dist-auth@w3c.org>; Mon, 16 Sep 2002 17:33:27 -0600 (MDT)
Message-ID: <3D866AD0.75C87385@oracle.com>
Date: Mon, 16 Sep 2002 16:35:44 -0700
From: Ilya Kirnos <ilya.kirnos@oracle.com>
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Webdav WG <w3c-dist-auth@w3c.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6651
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>
Content-Transfer-Encoding: 7bit


Clients currently have no reliable means of forcing the server to
authenticate them (they can try to preemptively send credentials, but
this works only for basic auth, not for digest).  This can lead to
situations where the client finds out that it was required to
authenticate too late and only after doing lots of work, such as when
putting a large file only to get a 401 back at the end of the transfer.

To address this problem, it was proposed to add a Force-Authenticate
OPTIONS header which would force a compliant server to issue an
authentication challenge to the client, a la:

Force-Authenticate = "Force-Authenticate" ":" ("T" | "F")

The Force-Authenticate header would be used with the OPTIONS method to
specify that the client wants to be
challenged for authentication credentials to the resource identified by
the Request-URI.  A value of "T"
indicates that a compliant DAV server MUST respond with a 401
Unauthorized status code (see
[RFC2068], section 10.4.2) if the resource identified by the Request-URI
is protected, i.e., there exists a  DAV method (read,  write, or
otherwise) that may result in a 401 response for this Request-URI.  Put
another way, if the server does *not* respond with a 401, it is
guaranteeing to the client that any DAV operation it may want to apply
to the Request-URI will not return a 401.

This means that the client has a way of finding out beforehand whether
it needs credentials to perform an operation, and the server has the
option of saying "no credentials necessary" if it is sure that in fact
no credentials are necessary (for example, servers that have no access
control at all, if any such exist).  I thought it was important to keep
this option open, although I suspect that most servers would always want
to challenge since they couldn't really be sure.

Comments?

-ilya



From w3c-dist-auth-request@w3.org  Mon Sep 16 19:45:19 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20076
	for <webdav-archive@lists.ietf.org>; Mon, 16 Sep 2002 19:45:19 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8GNk7U01712;
	Mon, 16 Sep 2002 19:46:07 -0400 (EDT)
Resent-Date: Mon, 16 Sep 2002 19:46:07 -0400 (EDT)
Resent-Message-Id: <200209162346.g8GNk7U01712@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8GNk5I01682
	for <w3c-dist-auth@frink.w3.org>; Mon, 16 Sep 2002 19:46:05 -0400 (EDT)
Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA26004
	for <w3c-dist-auth@w3c.org>; Mon, 16 Sep 2002 19:46:05 -0400
Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27])
	by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id g8GNjTh26136
	for <w3c-dist-auth@w3c.org>; Mon, 16 Sep 2002 16:45:29 -0700 (PDT)
Message-ID: <3D866D19.6030608@cse.ucsc.edu>
Date: Mon, 16 Sep 2002 16:45:29 -0700
From: Elias Sinderson <elias@cse.ucsc.edu>
Reply-To: Webdav WG <w3c-dist-auth@w3.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.4.1) Gecko/20020518 Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
CC: Webdav WG <w3c-dist-auth@w3c.org>
References: <000101c25ce3$a5387f30$29c4fea9@xythoslap>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Interop issue: Can we require clients to accept cookies?
To: w3c-dist-auth@w3.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6652
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>
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

>RFC 2518 is silent on cookies.... it was proposed that RFC2518 bis ... say that
>"clients SHOULD support cookies".
>
I generally agree with the previous posts in this thread - against 
cookies, or at least the language above being included in RFC2518 bis. 
Aside from the other reasons brought up previously, cookies break the 
REST architectural model. Rather than further entrench their use, it 
would be nice for WebDAV to help move HTTP away from the use of cookies.


Elias




From w3c-dist-auth-request@w3.org  Mon Sep 16 20:36:03 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20956
	for <webdav-archive@lists.ietf.org>; Mon, 16 Sep 2002 20:36:03 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8H0asC08652;
	Mon, 16 Sep 2002 20:36:54 -0400 (EDT)
Resent-Date: Mon, 16 Sep 2002 20:36:54 -0400 (EDT)
Resent-Message-Id: <200209170036.g8H0asC08652@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8H0aqI08626
	for <w3c-dist-auth@frink.w3.org>; Mon, 16 Sep 2002 20:36:52 -0400 (EDT)
Received: from 140.wakasoft.com (64-60-92-50.cust.telepacific.net [64.60.92.50])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA00494
	for <w3c-dist-auth@w3c.org>; Mon, 16 Sep 2002 20:36:51 -0400
Received: from 140.catv78.balcab.ch (localhost [127.0.0.1])
	by 140.wakasoft.com (8.12.4/8.12.4) with ESMTP id g8H0afnW013923;
	Mon, 16 Sep 2002 17:36:41 -0700 (PDT)
Date: Mon, 16 Sep 2002 17:36:40 -0700
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: Webdav WG <w3c-dist-auth@w3c.org>
To: Ilya Kirnos <ilya.kirnos@oracle.com>
From: "Roy T. Fielding" <fielding@apache.org>
In-Reply-To: <3D866AD0.75C87385@oracle.com>
Message-Id: <8849D3D8-C9D5-11D6-8B7B-000393753936@apache.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.482)
Subject: Re: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6653
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>
Content-Transfer-Encoding: 7bit


Authorization is granted/denied based on the method of the request.
There might even be different challenges per method.  In other words,
this idea won't work for HTTP.

The original idea of OPTIONS was that, if the client wished to test the
options for a specific request, then it would include that request's
request-line and headers in the body of the OPTIONS request.  The server
would then look at the body to determine what the options would be and
report that back to the client.  However, since the WG did not want to
define the format of such a response, the feature got dropped.

The alternative was to simply issue the request with Expect: 100-continue.

I don't know if that is sufficient for your problem, but I do know that
using a T/F request header field on OPTIONS is not.  A minimum would be
to list the methods in that field instead.  I also suggest finding a
less verbose field name.

....Roy



From w3c-dist-auth-request@w3.org  Mon Sep 16 20:48:34 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21186
	for <webdav-archive@lists.ietf.org>; Mon, 16 Sep 2002 20:48:34 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8H0nQc09660;
	Mon, 16 Sep 2002 20:49:26 -0400 (EDT)
Resent-Date: Mon, 16 Sep 2002 20:49:26 -0400 (EDT)
Resent-Message-Id: <200209170049.g8H0nQc09660@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8H0nOI09630
	for <w3c-dist-auth@frink.w3.org>; Mon, 16 Sep 2002 20:49:24 -0400 (EDT)
Received: from 140.wakasoft.com (64-60-92-50.cust.telepacific.net [64.60.92.50])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA02259
	for <w3c-dist-auth@w3c.org>; Mon, 16 Sep 2002 20:49:23 -0400
Received: from 140.catv78.balcab.ch (localhost [127.0.0.1])
	by 140.wakasoft.com (8.12.4/8.12.4) with ESMTP id g8H0mbnW013951;
	Mon, 16 Sep 2002 17:48:37 -0700 (PDT)
Date: Mon, 16 Sep 2002 17:48:37 -0700
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: Webdav WG <w3c-dist-auth@w3c.org>
To: "Clemm, Geoff" <gclemm@rational.com>
From: "Roy T. Fielding" <fielding@apache.org>
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B108258EED@SUS-MA1IT01>
Message-Id: <338BE886-C9D7-11D6-8B7B-000393753936@apache.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.482)
Subject: Re: Issue: Requiring server to use / terminated URL for returned coll 	ections
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6654
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>
Content-Transfer-Encoding: 7bit


> I strongly object to adding a MUST for servers returning slash
> terminated URLs for collections.
>
> Most repositories do not allow trailing segment-separator characters
> in the segment name of a resource, and therefore these trailing
> segment-separator characters are commonly just stripped off before
> that segment name is stored in the repository.  This means that in
> order to decide whether to add the segement-separator character back
> on, the implementation must query the repository for the type of each
> resource identified by that segment.  Forcing this cost on the server
> is only justified if it provides some compelling benefit to the
> client.

That's simply not true.  Most repositories store the type of a resource
along with the resource name in the collection (a.k.a. directory) and
thus that information is available at the time the segment is used
within a link describing the collection at no extra cost to the server.

All other repositories are fully capable of improving their internal
implementation.  OTOH, the protocol specification is responsible for
specifying that which is clearly most efficient for the protocol and
for those servers that have already anticipated its implementation.

....Roy



From w3c-dist-auth-request@w3.org  Tue Sep 17 04:18:16 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07295
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 04:18:16 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8H8Djk08864;
	Tue, 17 Sep 2002 04:13:45 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 04:13:45 -0400 (EDT)
Resent-Message-Id: <200209170813.g8H8Djk08864@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8H8DgI08838
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 04:13:42 -0400 (EDT)
Received: from smtp-relay-2.adobe.com (smtp-relay-2.adobe.com [192.150.11.2])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA11666
	for <w3c-dist-auth@w3.org>; Tue, 17 Sep 2002 04:13:41 -0400
Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51])
	by smtp-relay-2.adobe.com (8.12.3/8.12.3) with ESMTP id g8H8ATdL012535
	for <w3c-dist-auth@w3.org>; Tue, 17 Sep 2002 01:10:29 -0700 (PDT)
Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192])
	by inner-relay-1.corp.adobe.com (8.12.3/8.12.3) with ESMTP id g8H8DhZW007040
	for <w3c-dist-auth@w3.org>; Tue, 17 Sep 2002 01:13:43 -0700 (PDT)
Received: from dan.local.brotsky.com ([130.248.188.115]) by
          mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul
          11 2001 16:32:57) with ESMTP id H2KPHT00.JN5 for
          <w3c-dist-auth@w3.org>; Tue, 17 Sep 2002 01:13:05 -0700 
Date: Tue, 17 Sep 2002 01:13:04 -0700
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v543)
From: Dan Brotsky <dbrotsky@adobe.com>
To: Webdav WG <w3c-dist-auth@w3.org>
Content-Transfer-Encoding: 7bit
In-Reply-To: <3D866D19.6030608@cse.ucsc.edu>
Message-Id: <4A544AFD-CA15-11D6-84D7-0003931036B4@adobe.com>
X-Mailer: Apple Mail (2.543)
Subject: Re: Interop issue: Can we require clients to accept cookies?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6655
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>
Content-Transfer-Encoding: 7bit


>
> Lisa Dusseault wrote:
>
>> RFC 2518 is silent on cookies.... it was proposed that RFC2518 bis 
>> ... say that
>> "clients SHOULD support cookies".

I also strongly oppose any mention of cookies, and would vehemently 
oppose any proposal that clients SHOULD support cookies with WebDAV.  
In addition to all the very good arguments mentioned so far, I would 
add that the cookie spec *requires* providing explicit user control of 
the use of cookies.  This means that clients which support cookies have 
to support a whole bunch of UI that has arguably nothing to do with 
distributed authoring, either complicating their user model or forcing 
them to tie together the use of their client with the use of a browser 
(where cookie control UI typically lives).

By the way, Adobe has yet to test against a WebDAV server that does 
cookie-based authentication that did not (in our view) start out with 
some serious security holes.  Even our own implementations, for use 
with servers that provided Web-based UIs, took months to get to a 
reasonably-secure place.

If I were to advocate that the spec say anything about cookies, it 
would be that servers SHOULD NOT use cookies as an authentication 
mechanism.

     dan



From w3c-dist-auth-request@w3.org  Tue Sep 17 04:56:08 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07888
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 04:56:07 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8H8pdQ13278;
	Tue, 17 Sep 2002 04:51:39 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 04:51:39 -0400 (EDT)
Resent-Message-Id: <200209170851.g8H8pdQ13278@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8H8pcI13252
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 04:51:38 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA21060
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 04:51:37 -0400
Received: (qmail 17838 invoked by uid 0); 17 Sep 2002 08:51:06 -0000
Received: from pd950c385.dip.t-dialin.net (HELO lisa) (217.80.195.133)
  by mail.gmx.net (mp012-rz3) with SMTP; 17 Sep 2002 08:51:06 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Lisa Dusseault" <lisa@xythos.com>, "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 10:51:04 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCOEMJFFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <000001c25ce3$a00bba90$29c4fea9@xythoslap>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: extending the DAV: HTTP header, was: Issues from Interop/Interim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6656
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>
Content-Transfer-Encoding: 7bit


> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Sunday, September 15, 2002 8:14 PM
> To: Webdav WG
> Subject: Issues from Interop/Interim WG Meeting
>
> ...
>
> - Add a new string in DAV: header to advertise support for RFC2518 bis
>
> - Change the DAV: header BNF to allow coded URLs syntactically.
>
> ...

Questions:

1) I thought that the goal for RFC2518bis is to clarify and to simply the
protocol, not to extend it. Why do we need a new compliance class then? And
what does it mean for an existing server? For instance, if the server only
implements the "simplified" form of LOCK-NULL resources, is it allowed to
advertise compliance class "2". IMHO, it should (otherwise interoperability
with old clients may break), so why a new class then?

2) If the spec extends how compliance classes are defined, I'd like to see a
use case first. Note that advertising support for a specific live property
IMHO is not a valid use case, so servers doing this should be fixed (there's
a better way to do it, which is adding the property to the set reported in
DAV:supported-live-property-set as defined in RFC3253).

Julian

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



From w3c-dist-auth-request@w3.org  Tue Sep 17 04:59:14 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07918
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 04:59:14 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8H8ttW13623;
	Tue, 17 Sep 2002 04:55:55 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 04:55:55 -0400 (EDT)
Resent-Message-Id: <200209170855.g8H8ttW13623@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8H8ttI13597
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 04:55:55 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA21867
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 04:55:54 -0400
Received: (qmail 8348 invoked by uid 0); 17 Sep 2002 08:55:23 -0000
Received: from pd950c385.dip.t-dialin.net (HELO lisa) (217.80.195.133)
  by mail.gmx.net (mp003-rz3) with SMTP; 17 Sep 2002 08:55:23 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Lisa Dusseault" <lisa@xythos.com>, "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 10:55:22 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCCEMKFFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <000001c25ce3$a00bba90$29c4fea9@xythoslap>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: 302 in miultistattus, was: Issues from Interop/Interim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6657
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>
Content-Transfer-Encoding: 7bit


> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Sunday, September 15, 2002 8:14 PM
> To: Webdav WG
> Subject: Issues from Interop/Interim WG Meeting
>
> ...
> - Error responses that must contain headers (like 302) don't contain
> those headers in multistatus.  E.g. when you MOVE a collection, but one
> of the collection members is redirected, a 302 would be most convenient
> and normally comes along with a location. Clarify in 2518 bis.
> ...

That's in fact a very interesting problem, which is partly solved in the
expired redirect references draft [1]. If we can come up with a similarm but
more generic format, I'm all for it. But is it reasonable to attempt to
resolve this in RFC2518bis?

Julian


[1]
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-02.
html#rfc.section.7.3>

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



From w3c-dist-auth-request@w3.org  Tue Sep 17 05:01:53 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07962
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 05:01:53 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8H8wSY14015;
	Tue, 17 Sep 2002 04:58:28 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 04:58:28 -0400 (EDT)
Resent-Message-Id: <200209170858.g8H8wSY14015@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8H8wRI13986
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 04:58:27 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA22530
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 04:58:27 -0400
Received: (qmail 20093 invoked by uid 0); 17 Sep 2002 08:57:56 -0000
Received: from pd950c385.dip.t-dialin.net (HELO lisa) (217.80.195.133)
  by mail.gmx.net (mp004-rz3) with SMTP; 17 Sep 2002 08:57:56 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Lisa Dusseault" <lisa@xythos.com>, "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 10:57:54 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCGEMKFFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <000001c25ce3$a00bba90$29c4fea9@xythoslap>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: ETags, was: Issues from Interop/Interim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6658
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>
Content-Transfer-Encoding: 7bit


> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Sunday, September 15, 2002 8:14 PM
> To: Webdav WG
> Subject: Issues from Interop/Interim WG Meeting
>
> ...
> -  Be clear in spec that servers MUST do ETags. Explain how necessary
> this is to solve the lost update problem.
> ..

ETags are a good thing, correct. However, HTTP (RFC2616) doesn't require
them, RFC2518 doesn't require them, and they '*aren't* required for
interoperability. So there's no way to require them in RFC2518bis -- it
would break all servers that don't have them.

Julian

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



From w3c-dist-auth-request@w3.org  Tue Sep 17 05:24:58 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08476
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 05:24:57 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8H9LLo19935;
	Tue, 17 Sep 2002 05:21:21 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 05:21:21 -0400 (EDT)
Resent-Message-Id: <200209170921.g8H9LLo19935@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8H9LJI19908
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 05:21:19 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA29594
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 05:21:19 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 11:20:55 +0200
Date: Tue, 17 Sep 2002 11:20:55 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: Webdav WG <w3c-dist-auth@w3c.org>
To: Ilya Kirnos <ilya.kirnos@oracle.com>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <3D866AD0.75C87385@oracle.com>
Message-Id: <C4FA8640-CA1E-11D6-9F78-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.482)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6659
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>
Content-Transfer-Encoding: 7bit


Ilya,

Am Dienstag den, 17. September 2002, um 01:35, schrieb Ilya Kirnos:

>
> Clients currently have no reliable means of forcing the server to
> authenticate them (they can try to preemptively send credentials, but
> this works only for basic auth, not for digest).  This can lead to
> situations where the client finds out that it was required to
> authenticate too late and only after doing lots of work, such as when
> putting a large file only to get a 401 back at the end of the transfer.

A bad user experience, agreed.

However it would be more elegant if the client could send
the request without the server executing it and checking thus
the authentication for the specific method call. That would also
give any intermediates, like proxies, a chance to determine if
they need any authorization.

My idea would be to use the IF header for this purpose. A client
can send a request with an invalid lock token in the IF header.
The server, being DAV-compliant, will never execute the request.

Now this solution depends on the order of authentication vs. IF
header check. Therefore my proposal depends on

- does every known server check authentication before lock tokens?
- could 2518bis say something like: "All user authentication SHOULD
   take place before other request headers like IF are processed."?

//Stefan

> To address this problem, it was proposed to add a Force-Authenticate
> OPTIONS header which would force a compliant server to issue an
> authentication challenge to the client, a la:
>
> Force-Authenticate = "Force-Authenticate" ":" ("T" | "F")
>
> The Force-Authenticate header would be used with the OPTIONS method to
> specify that the client wants to be
> challenged for authentication credentials to the resource identified by
> the Request-URI.  A value of "T"
> indicates that a compliant DAV server MUST respond with a 401
> Unauthorized status code (see
> [RFC2068], section 10.4.2) if the resource identified by the 
> Request-URI
> is protected, i.e., there exists a  DAV method (read,  write, or
> otherwise) that may result in a 401 response for this Request-URI.  Put
> another way, if the server does *not* respond with a 401, it is
> guaranteeing to the client that any DAV operation it may want to apply
> to the Request-URI will not return a 401.
>
> This means that the client has a way of finding out beforehand whether
> it needs credentials to perform an operation, and the server has the
> option of saying "no credentials necessary" if it is sure that in fact
> no credentials are necessary (for example, servers that have no access
> control at all, if any such exist).  I thought it was important to keep
> this option open, although I suspect that most servers would 
> always want
> to challenge since they couldn't really be sure.
>
> Comments?
>
> -ilya
>
>





From w3c-dist-auth-request@w3.org  Tue Sep 17 10:15:21 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15886
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 10:15:21 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HE8Ox05413;
	Tue, 17 Sep 2002 10:08:24 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 10:08:24 -0400 (EDT)
Resent-Message-Id: <200209171408.g8HE8Ox05413@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HE8OI05387
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 10:08:24 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA27724
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 10:08:24 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 17 Sep 2002 09:58:07 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <TBFBN1GW>; Tue, 17 Sep 2002 10:07:53 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10841D57D@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: Webdav WG <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 09:37:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: Issue: Requiring server to use / terminated URL for returned  	coll 	ections
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6661
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>


By "repository", I did not mean "file system".  In particular, we
store our information in relational tables, and we do not imbed in
the database keys information about whether or not the key is to
a "collection" object or a "non-collection" object.  

And as to whether this would "improve the internal representation",
storing redundant information on a reference is not an "improvement",
it is a costly change that needs compelling motivation.  So perhaps
we should focus on the "compelling motivation" before spending too
much time on "how costly" it would be for a server.

Cheers,
Geoff

 
-----Original Message-----
From: Roy T. Fielding [mailto:fielding@apache.org]
Sent: Monday, September 16, 2002 8:49 PM
To: Clemm, Geoff
Cc: Webdav WG
Subject: Re: Issue: Requiring server to use / terminated URL for
returned coll ections


> I strongly object to adding a MUST for servers returning slash
> terminated URLs for collections.
>
> Most repositories do not allow trailing segment-separator characters
> in the segment name of a resource, and therefore these trailing
> segment-separator characters are commonly just stripped off before
> that segment name is stored in the repository.  This means that in
> order to decide whether to add the segement-separator character back
> on, the implementation must query the repository for the type of each
> resource identified by that segment.  Forcing this cost on the server
> is only justified if it provides some compelling benefit to the
> client.

That's simply not true.  Most repositories store the type of a resource
along with the resource name in the collection (a.k.a. directory) and
thus that information is available at the time the segment is used
within a link describing the collection at no extra cost to the server.

All other repositories are fully capable of improving their internal
implementation.  OTOH, the protocol specification is responsible for
specifying that which is clearly most efficient for the protocol and
for those servers that have already anticipated its implementation.

....Roy



From w3c-dist-auth-request@w3.org  Tue Sep 17 10:15:22 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15900
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 10:15:22 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HE88d05331;
	Tue, 17 Sep 2002 10:08:08 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 10:08:08 -0400 (EDT)
Resent-Message-Id: <200209171408.g8HE88d05331@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HE86I05305
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 10:08:06 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA27618
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 10:08:06 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 17 Sep 2002 09:57:49 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <TBFBN1FQ>; Tue, 17 Sep 2002 10:07:35 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10841D57B@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 09:37:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: Issue: Requiring server to use / terminated URL for returned  	collections
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6660
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>



   From: Lisa Dusseault [mailto:lisa@xythos.com]

   > ... the implementation must
   > query the repository for the type of each resource identified by
   > that segment.  Forcing this cost on the server is only justified
   > if it provides some compelling benefit to the client.

   Yes, the server must know the type of each resource in order to
   construct its URL properly.

In general, this is not true.  A given segment name can refer to
various types of resources.  In particular, it is not true for any of
the DeltaV types (activity, version history, workspace) or of any of
the ACL types (principal, group principal).  It is not true for the
advanced collection types (redirect reference).  In fact, the only
exception is collection vs. non-collection.  In all other cases, we
let the client (preferably) or the server decide on any naming
conventions/constraints, and 2518 gives servers the option in this
case (i.e. to automatically add a slash to a request, to produce
typeless names).  I need to see some compelling reasons why a
collection requires protocol-imposed naming constraints.

   Or the repository could save or cache the
   URL for each resource. There are lots of options.

If the repository semantics are that /x/y can refer either to
a collection or to a non-collection, it cannot save the URL in
a reference, because it might have changed since it was saved.
Correctly maintaining a "cache" is very complex for a sophisticated
repository, so introducing functionality that requires one is
only done for compelling reasons.

   > The only concrete motivation I have heard for making this
   > requirement is to save a 302 redirect round trip for a client
   > when the server redirects a GET request on a collection to an
   > internal member of the request-URL (e.g. redirects "GET /foo" to
   > "GET /foo/index.html").

   There are other problems encountered and discussed at the interop.
   In fact, the GET/redirect problem is one of the least troublesome
   because it's just a performance problem, not (typically) an
   interoperability problem.

OK, I'm happy to focus on interoperability issues.

    - Clients aren't consistent in supporting redirects for other
   methods besides GET. Yet if the client sends a bad Request-URI (a
   collection path without a trailing slash), the server needs to do
   something.

If a client doesn't support 302 redirects, then it is broken,
end of story.  Once the Advanced Collection redirect protocol
is adopted, a client will be able to interoperably create
redirects, and it will be even more important that clients
that do not accept redirects are fixed.  So if anything,
I consider this an argument against the proposal, so that
the broken clients are identified and flushed out as early
as possible.

A couple of additional comments on the section above:

Since when is a collection path without a trailing slash a "bad
Request-URI"?  RFC-2518 explicitly states in Section 5.2 that "a
resource may accept a URI without a trailing '/' to point to a
collection."  If you are proposing to change this semantics, then I
object even more vigorously (but I'll save those objections until
I verify that you are proposing to make this change).

Note also that there is no requirement in 2518 for a server to
redirect a non-GET request (it just needs to return the '/' terminated
name in a Location header).  Note that I have no problem with
requiring that a Location header be returned, since if the server
is applying a method to a resource, it will have had to find out
what type of resource it is anyway.

    - Servers aren't consistent in putting the trailing slash in
   various places: the Content-Location header, the Location header,
   and <href> elements inside Multi-Status. Clients need to look for
   the trailing slash and possibly add it in order to be able to do
   further operations.

This appears to be based on the same false premise as above, i.e.
that a client needs to add a trailing slash to make a request
on a collection.  If a server has such a requirement, then certainly
it will return its collection URLs in the trailing slash form.
If the server automatically redirects /x/y to the collection named
/x/y/, then there is no need for a client to do that processing.
In either case, the client just takes the URL produced by the
server, and uses it.

   E.g. clients would like to be able to display results consistently
   in folder views, yet servers aren't consistent.

This is neither a performance nor an interoperability issue.
If a server automatically redirects slash terminated names,
then it is not inconsistent for the client to
use and display the non-slash terminated form of the URL.

    - Clients need to know how to generate a correct URL for a MKCOL,
   PUT, MOVE or COPY to create a new resource in an existing
   collection. This means parsing the collection URL to make sure it
   ends in a slash before adding the terminal part.

Let's see ... 

   if (str[strlen-1] != '/') str[strlen++] = '/'

Suffice it to say, I find this argument less than compelling.

   > But no WebDAV methods other than GET is redirected in this
   > fashion, and WebDAV clients will commonly not be doing a GET on a
   > collection (they will be doing a PROPFIND, and use the results to
   > construct a display), and so the overall benefit to a client of
   > avoiding a redirect on a GET to a collection is significantly
   > outweighed by the server cycles being wasted to determine whether or
   > not a collection member is a collection.

   First, this is an issue not only for GET.  The problems with other
   methods are not just redirects, but how the client constructs URLs
   for new resources.

As indicated above, I find the "clients can't be expected to figure
out how to add a trailing slash when adding a new segment to a URL"
argument uncompelling.  File system clients have been doing it for
decades.

   Second, it's a matter of opinion what situation has what benefits
   and which wastes cycles where. Certainly avoiding redirects
   improves performance for the client because it reduces
   roundtrips.

It is a matter of semantics, not opinion, as to whether methods other
than GET need to be 302 redirected (costly) or can be silently
redirected on the server (effectively no cost).

   Also providing correct URLs saves cycles on the client
   although that's usually less of a concern.

Given the cycles necessary to perform the preceding C statement
(a few machine instructions), I'd say "absolutely no concern
in this case".

   Note that for some servers, a redirect is higher cost than just
   making the URLs correct, because a redirect is an entirely new
   request, new database or filesystem query, etc.

As indicated above, the 302 redirect is only required for a GET, and
WebDAV clients commonly use PROPFIND and not GET to retrieve the state
of a collection.

   > If a client cares whether or not a resource is a collection, it
   > can do a PROPFIND for its DAV:resourcetype.  That way, server
   > cycles are spent only when needed.

   It's not only that the client cares what type of resource the URL
   refers to, although knowing that is nice. It's also how to
   construct correct new URLs and how to interpret the results of a
   PROPFIND.

We have dealt with the "difficulty of adding a slash" above.
How is a "trailing slash" needed to interpret the results of
a PROPFIND?  If you care about the type of a member, you ask
for its DAV:resourcetype in that PROPFIND.

   Since there have been actual interoperability problems, I still
   find this a good candidate for making the specification clearer,
   even if this is a few more cycles on the server. Real
   interoperability problems are much worse problems than a minor
   increased burden on the server.

The only real interoperability problem I saw identified above was the
"clients don't redirect properly", and the solution there is to fix
the broken clients, not change URL conventions so that the broken
clients work better in this one case of redirection.  (I consider the
addition of a slash when extending a URL to be a trivial coding issue,
not an interoperability problem).

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Tue Sep 17 10:19:24 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16293
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 10:19:24 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HECb806253;
	Tue, 17 Sep 2002 10:12:37 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 10:12:37 -0400 (EDT)
Resent-Message-Id: <200209171412.g8HECb806253@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HECZI06216
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 10:12:35 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA29306
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 10:12:35 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 17 Sep 2002 10:02:19 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <TBFBN1WS>; Tue, 17 Sep 2002 10:12:05 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10841D589@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: Webdav WG <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 09:49:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: extending the DAV: HTTP header, was: Issues from Interop/Inte 	rim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6662
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>


I agree with both of Julian's points.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Tuesday, September 17, 2002 4:51 AM
To: Lisa Dusseault; Webdav WG
Subject: extending the DAV: HTTP header, was: Issues from
Interop/Interim WG Meeting



> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Sunday, September 15, 2002 8:14 PM
> To: Webdav WG
> Subject: Issues from Interop/Interim WG Meeting
>
> ...
>
> - Add a new string in DAV: header to advertise support for RFC2518 bis
>
> - Change the DAV: header BNF to allow coded URLs syntactically.
>
> ...

Questions:

1) I thought that the goal for RFC2518bis is to clarify and to simply the
protocol, not to extend it. Why do we need a new compliance class then? And
what does it mean for an existing server? For instance, if the server only
implements the "simplified" form of LOCK-NULL resources, is it allowed to
advertise compliance class "2". IMHO, it should (otherwise interoperability
with old clients may break), so why a new class then?

2) If the spec extends how compliance classes are defined, I'd like to see a
use case first. Note that advertising support for a specific live property
IMHO is not a valid use case, so servers doing this should be fixed (there's
a better way to do it, which is adding the property to the set reported in
DAV:supported-live-property-set as defined in RFC3253).

Julian

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



From w3c-dist-auth-request@w3.org  Tue Sep 17 10:19:33 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16307
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 10:19:33 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HED8p06384;
	Tue, 17 Sep 2002 10:13:08 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 10:13:08 -0400 (EDT)
Resent-Message-Id: <200209171413.g8HED8p06384@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HED7I06358
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 10:13:07 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA29693
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 10:13:07 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 17 Sep 2002 10:02:50 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <TBFBN1X8>; Tue, 17 Sep 2002 10:12:36 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10841D58A@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: Webdav WG <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 09:50:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6663
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>


I agree.

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Tuesday, September 17, 2002 4:58 AM
To: Lisa Dusseault; Webdav WG
Subject: ETags, was: Issues from Interop/Interim WG Meeting



> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Sunday, September 15, 2002 8:14 PM
> To: Webdav WG
> Subject: Issues from Interop/Interim WG Meeting
>
> ...
> -  Be clear in spec that servers MUST do ETags. Explain how necessary
> this is to solve the lost update problem.
> ..

ETags are a good thing, correct. However, HTTP (RFC2616) doesn't require
them, RFC2518 doesn't require them, and they '*aren't* required for
interoperability. So there's no way to require them in RFC2518bis -- it
would break all servers that don't have them.

Julian

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



From w3c-dist-auth-request@w3.org  Tue Sep 17 10:23:36 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16579
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 10:23:36 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HEOZR08038;
	Tue, 17 Sep 2002 10:24:35 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 10:24:35 -0400 (EDT)
Resent-Message-Id: <200209171424.g8HEOZR08038@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HEOXI08006
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 10:24:33 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA04072
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 10:24:33 -0400
Received: (qmail 32165 invoked by uid 0); 17 Sep 2002 14:24:02 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp012-rz3) with SMTP; 17 Sep 2002 14:24:02 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Clemm, Geoff" <gclemm@rational.com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 16:24:01 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCGENFFFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10841D57B@SUS-MA1IT01>
Importance: Normal
Subject: RE: Issue: Requiring server to use / terminated URL for returned  	collections
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6664
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>
Content-Transfer-Encoding: 7bit


Like Geoff said,

except:

> As indicated above, the 302 redirect is only required for a GET, and
> WebDAV clients commonly use PROPFIND and not GET to retrieve the state
> of a collection.

Where does this distinction come from?

I really don't want to get into a situation where 1) HEAD and 2)
PROPFIND/depth 0 say different things about the same resource.

Julian

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



From w3c-dist-auth-request@w3.org  Tue Sep 17 11:49:35 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19759
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 11:49:35 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HFoOG20324;
	Tue, 17 Sep 2002 11:50:24 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 11:50:24 -0400 (EDT)
Resent-Message-Id: <200209171550.g8HFoOG20324@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HFoMI20298
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 11:50:22 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA11398
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 11:50:22 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 17 Sep 2002 11:40:04 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <TDCRS8PN>; Tue, 17 Sep 2002 11:49:50 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10841D60F@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 11:49:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Issue: Requiring server to use / terminated URL for returned  	 	collections
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6665
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>


Good question, Julian.

I was going to respond "so that client side relative URL
processing is correct".  But of course, a better
way to handle that would be for the GET to just return the
slash-terminated name (or even better, the resource that it
is really redirecting the request to, such as "index.html")
in the Content-Location field, since the client is required
to use the value in the Content-Location field as the base
for relative URL processing.

So a 302 redirect is not even required for GET processing
(i.e. the server can just automatically forward the request
without an extra roundtrip for the 302 redirect).

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Tuesday, September 17, 2002 10:24 AM
To: Clemm, Geoff; 'Webdav WG'
Subject: RE: Issue: Requiring server to use / terminated URL for
returned collections



Like Geoff said,

except:

> As indicated above, the 302 redirect is only required for a GET, and
> WebDAV clients commonly use PROPFIND and not GET to retrieve the state
> of a collection.

Where does this distinction come from?

I really don't want to get into a situation where 1) HEAD and 2)
PROPFIND/depth 0 say different things about the same resource.

Julian

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



From w3c-dist-auth-request@w3.org  Tue Sep 17 13:36:22 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22970
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 13:36:22 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HHbEr28947;
	Tue, 17 Sep 2002 13:37:14 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 13:37:14 -0400 (EDT)
Resent-Message-Id: <200209171737.g8HHbEr28947@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HHbAI28921
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 13:37:10 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA02727
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 13:37:10 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 17 Sep 2002 13:10:57 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 17 Sep 2002 13:10:51 -0400
Received: from xythoslap ([216.36.77.241]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 17 Sep 2002 13:10:51 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Clemm, Geoff'" <gclemm@rational.com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 10:10:51 -0700
Message-ID: <006f01c25e6d$2d538650$b701a8c0@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10841D57B@SUS-MA1IT01>
X-OriginalArrivalTime: 17 Sep 2002 17:10:51.0626 (UTC) FILETIME=[2CD2E4A0:01C25E6D]
Subject: RE: Issue: Requiring server to use / terminated URL for returned  	collections
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6666
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>
Content-Transfer-Encoding: 7bit


> In general, this is not true.  A given segment name can refer to
> various types of resources.  In particular, it is not true for any of
> the DeltaV types (activity, version history, workspace) or of any of
> the ACL types (principal, group principal).  It is not true for the
> advanced collection types (redirect reference).  In fact, the only
> exception is collection vs. non-collection.  In all other cases, we
> let the client (preferably) or the server decide on any naming
> conventions/constraints, and 2518 gives servers the option in this
> case (i.e. to automatically add a slash to a request, to produce
> typeless names).  I need to see some compelling reasons why a
> collection requires protocol-imposed naming constraints.

Another reason was given by Roy in an older mail:

"There are no known examples of HTTP servers for which the URI without a
slash is the SAME RESOURCE as the URI with a slash.  Automatically
providing two different URI for the same resource, particularly when
they cross hierarchical syntax, instantly doubles the application
name space (bad for IR and QA) and creates holes in access control."

If the server consistently uses the same URL for each resource, then
it's easier for clients and intermediaries to handle (cache, compare,
concatenate paths, etc) those resources.

> Since when is a collection path without a trailing slash a "bad
> Request-URI"?  RFC-2518 explicitly states in Section 5.2 that "a
> resource may accept a URI without a trailing '/' to point to a
> collection."  If you are proposing to change this semantics, then I
> object even more vigorously (but I'll save those objections until
> I verify that you are proposing to make this change).

I don't think it matters too much which one you pick, with trailing
slash or without (with trailing slash is slightly more convenient
because it's a marker for collections). However, there was strong
opinion that the spec should pick one. Allowing such flexibility, as
usual, makes life harder for clients.

> Note also that there is no requirement in 2518 for a server to
> redirect a non-GET request (it just needs to return the '/' terminated
> name in a Location header).  Note that I have no problem with
> requiring that a Location header be returned, since if the server
> is applying a method to a resource, it will have had to find out
> what type of resource it is anyway.

Yes. And if the server returns the slash-terminated name in a Location
header, it should use the SAME name everywhere else in the response.

> This appears to be based on the same false premise as above, i.e.
> that a client needs to add a trailing slash to make a request
> on a collection.  

Not only that, but the client also needs to add a trailing slash in
order to make a request on children of the collection.

 
> The only real interoperability problem I saw identified above was the
> "clients don't redirect properly", and the solution there is to fix
> the broken clients, not change URL conventions so that the broken
> clients work better in this one case of redirection.  (I consider the
> addition of a slash when extending a URL to be a trivial coding issue,
> not an interoperability problem).

Also an interoperability problem found was "clients don't append new
child names properly onto collection names".

Lisa



From w3c-dist-auth-request@w3.org  Tue Sep 17 13:40:01 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23065
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 13:40:01 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HHf2d29209;
	Tue, 17 Sep 2002 13:41:02 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 13:41:02 -0400 (EDT)
Resent-Message-Id: <200209171741.g8HHf2d29209@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HHf0I29182
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 13:41:00 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA03586
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 13:40:59 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 17 Sep 2002 13:27:45 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 17 Sep 2002 13:27:45 -0400
Received: from xythoslap ([216.36.77.241]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 17 Sep 2002 13:27:44 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Clemm, Geoff'" <gclemm@rational.com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 10:27:45 -0700
Message-ID: <007401c25e6f$8964ca60$b701a8c0@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10841D60F@SUS-MA1IT01>
X-OriginalArrivalTime: 17 Sep 2002 17:27:45.0098 (UTC) FILETIME=[88E672A0:01C25E6F]
Subject: RE: Issue: Requiring server to use / terminated URL for returned  	 	collections
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6667
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>
Content-Transfer-Encoding: 7bit


I dug out another testimonial to the interoperability problems of not
consistently using trailing slashes. 

Geoff Alexander said:
"We are developing a WebDAV server and have encountered interoperability
problem with request on collections in which the resource does not have
a
trailing slash.  Where do things stand on this issue?  Our testing
indicates
that the above does not work in the real world.  For example, both IE 5
and
Netscape 4.7 do not properly process relative references in response to
a
GET request on a collection without the trailing slash..  I guess one
could
say that IE and Netscape only support the HTTP protocol and not WebDAV
protocol, but then our server would have to determine whether the
request
was HTTP or WebDAV (which is not a workable solution).  Also, we have
encountered interoperability problem with other WebDAV clients."

http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0247.html

lisa




From w3c-dist-auth-request@w3.org  Tue Sep 17 13:41:03 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23144
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 13:41:03 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HHfv729332;
	Tue, 17 Sep 2002 13:41:57 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 13:41:57 -0400 (EDT)
Resent-Message-Id: <200209171741.g8HHfv729332@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HHfuI29303
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 13:41:56 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA03810
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 13:41:56 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 17 Sep 2002 13:40:15 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 17 Sep 2002 13:40:15 -0400
Received: from xythoslap ([216.36.77.241]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 17 Sep 2002 13:40:14 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Clemm, Geoff'" <gclemm@rational.com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 10:40:15 -0700
Message-ID: <007701c25e71$486c07b0$b701a8c0@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10841D589@SUS-MA1IT01>
X-OriginalArrivalTime: 17 Sep 2002 17:40:15.0104 (UTC) FILETIME=[47F04800:01C25E71]
Subject: RE: extending the DAV: HTTP header, was: Issues from Interop/Inte 	rim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6668
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>
Content-Transfer-Encoding: 7bit


A new compliance class was suggested at the WG meeting particularly so
that clients could rely on Ilya's solution to ask the server to return a
401 so they could force authentication.  It would also be needed if we
followed the current proposal for provision of lock tokens, to add a new
header which does not cause the request to fail.

The intention of the text draft is that a server could advertise
compliance with 1 + bis, or with 1 + 2 + bis (or if it does not support
bis, with 1 or with 1 + 2).

Interoperability with old clients is very important and was always kept
under consideration at the WG meeting.  Changes that add new headers,
without deleting old headers or otherwise making old syntax illegal,
continue to allow servers to interoperate with old clients.

Consensus was quite clear at the WG meeting on both these issues.  I
report this to the list to make it clear that significant dissent on the
list, along with feasible alternative solutions to the problems
encountered, would be required to overturn that.

Lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]
> On Behalf Of Clemm, Geoff
> Sent: Tuesday, September 17, 2002 6:50 AM
> To: Webdav WG
> Subject: RE: extending the DAV: HTTP header, was: Issues from
Interop/Inte
> rim WG Meeting
> 
> 
> I agree with both of Julian's points.
> 
> Cheers,
> Geoff
> 
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Tuesday, September 17, 2002 4:51 AM
> To: Lisa Dusseault; Webdav WG
> Subject: extending the DAV: HTTP header, was: Issues from
> Interop/Interim WG Meeting
> 
> 
> 
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> > Sent: Sunday, September 15, 2002 8:14 PM
> > To: Webdav WG
> > Subject: Issues from Interop/Interim WG Meeting
> >
> > ...
> >
> > - Add a new string in DAV: header to advertise support for RFC2518
bis
> >
> > - Change the DAV: header BNF to allow coded URLs syntactically.
> >
> > ...
> 
> Questions:
> 
> 1) I thought that the goal for RFC2518bis is to clarify and to simply
the
> protocol, not to extend it. Why do we need a new compliance class
then?
> And
> what does it mean for an existing server? For instance, if the server
only
> implements the "simplified" form of LOCK-NULL resources, is it allowed
to
> advertise compliance class "2". IMHO, it should (otherwise
> interoperability
> with old clients may break), so why a new class then?
> 
> 2) If the spec extends how compliance classes are defined, I'd like to
see
> a
> use case first. Note that advertising support for a specific live
property
> IMHO is not a valid use case, so servers doing this should be fixed
> (there's
> a better way to do it, which is adding the property to the set
reported in
> DAV:supported-live-property-set as defined in RFC3253).
> 
> Julian
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Tue Sep 17 14:24:20 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25020
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 14:24:20 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HIPHc01934;
	Tue, 17 Sep 2002 14:25:17 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 14:25:17 -0400 (EDT)
Resent-Message-Id: <200209171825.g8HIPHc01934@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HIPFI01886
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 14:25:15 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA14579
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 14:25:15 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 17 Sep 2002 14:24:35 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 17 Sep 2002 14:24:35 -0400
Received: from xythoslap ([216.36.77.241]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 17 Sep 2002 14:24:12 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 11:24:12 -0700
Message-ID: <009401c25e77$6c58bff0$b701a8c0@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B108258ECA@SUS-MA1IT01>
X-OriginalArrivalTime: 17 Sep 2002 18:24:12.0383 (UTC) FILETIME=[6BE11EF0:01C25E77]
Subject: RE: Interop issue: Can we require clients to accept cookies?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6669
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>
Content-Transfer-Encoding: 7bit


Consensus on requiring clients to accept cookies is quite clear: we
should NOT require WebDAV clients to accept or use cookies.  

It seems to me that the text in RFC2518 (silent on cookies) is
sufficient and nothing needs to be added.

lisa




From w3c-dist-auth-request@w3.org  Tue Sep 17 14:24:44 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25039
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 14:24:44 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HIPjL01993;
	Tue, 17 Sep 2002 14:25:45 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 14:25:45 -0400 (EDT)
Resent-Message-Id: <200209171825.g8HIPjL01993@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HIPiI01967
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 14:25:44 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA14713
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 14:25:44 -0400
Received: (qmail 4353 invoked by uid 0); 17 Sep 2002 18:16:01 -0000
Received: from p3ee24731.dip.t-dialin.net (HELO lisa) (62.226.71.49)
  by mail.gmx.net (mp006-rz3) with SMTP; 17 Sep 2002 18:16:01 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Lisa Dusseault" <lisa@xythos.com>, "'Clemm, Geoff'" <gclemm@rational.com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 20:16:00 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCGEOAFFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <007701c25e71$486c07b0$b701a8c0@xythoslap>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: RE: extending the DAV: HTTP header, was: Issues from Interop/Inte 	rim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6670
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>
Content-Transfer-Encoding: 7bit


Lisa,

I think the answer to this is that this change should be discussed *after*
there's a consensus about the new header. If, as you say, the introduction
of the new header requires a new conformance class, that's (to me) a strong
indication that it doesn't belong into RFC2518bis.

Julian

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Tuesday, September 17, 2002 7:40 PM
> To: 'Clemm, Geoff'; 'Webdav WG'
> Subject: RE: extending the DAV: HTTP header, was: Issues from
> Interop/Inte rim WG Meeting
>
>
>
> A new compliance class was suggested at the WG meeting particularly so
> that clients could rely on Ilya's solution to ask the server to return a
> 401 so they could force authentication.  It would also be needed if we
> followed the current proposal for provision of lock tokens, to add a new
> header which does not cause the request to fail.
>
> The intention of the text draft is that a server could advertise
> compliance with 1 + bis, or with 1 + 2 + bis (or if it does not support
> bis, with 1 or with 1 + 2).
>
> Interoperability with old clients is very important and was always kept
> under consideration at the WG meeting.  Changes that add new headers,
> without deleting old headers or otherwise making old syntax illegal,
> continue to allow servers to interoperate with old clients.
>
> Consensus was quite clear at the WG meeting on both these issues.  I
> report this to the list to make it clear that significant dissent on the
> list, along with feasible alternative solutions to the problems
> encountered, would be required to overturn that.
>
> Lisa
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]
> > On Behalf Of Clemm, Geoff
> > Sent: Tuesday, September 17, 2002 6:50 AM
> > To: Webdav WG
> > Subject: RE: extending the DAV: HTTP header, was: Issues from
> Interop/Inte
> > rim WG Meeting
> >
> >
> > I agree with both of Julian's points.
> >
> > Cheers,
> > Geoff
> >
> > -----Original Message-----
> > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > Sent: Tuesday, September 17, 2002 4:51 AM
> > To: Lisa Dusseault; Webdav WG
> > Subject: extending the DAV: HTTP header, was: Issues from
> > Interop/Interim WG Meeting
> >
> >
> >
> > > From: w3c-dist-auth-request@w3.org
> > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> > > Sent: Sunday, September 15, 2002 8:14 PM
> > > To: Webdav WG
> > > Subject: Issues from Interop/Interim WG Meeting
> > >
> > > ...
> > >
> > > - Add a new string in DAV: header to advertise support for RFC2518
> bis
> > >
> > > - Change the DAV: header BNF to allow coded URLs syntactically.
> > >
> > > ...
> >
> > Questions:
> >
> > 1) I thought that the goal for RFC2518bis is to clarify and to simply
> the
> > protocol, not to extend it. Why do we need a new compliance class
> then?
> > And
> > what does it mean for an existing server? For instance, if the server
> only
> > implements the "simplified" form of LOCK-NULL resources, is it allowed
> to
> > advertise compliance class "2". IMHO, it should (otherwise
> > interoperability
> > with old clients may break), so why a new class then?
> >
> > 2) If the spec extends how compliance classes are defined, I'd like to
> see
> > a
> > use case first. Note that advertising support for a specific live
> property
> > IMHO is not a valid use case, so servers doing this should be fixed
> > (there's
> > a better way to do it, which is adding the property to the set
> reported in
> > DAV:supported-live-property-set as defined in RFC3253).
> >
> > Julian
> >
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Tue Sep 17 14:34:12 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25313
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 14:34:12 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HIZ6n02477;
	Tue, 17 Sep 2002 14:35:06 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 14:35:06 -0400 (EDT)
Resent-Message-Id: <200209171835.g8HIZ6n02477@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HIZ5I02451
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 14:35:05 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA16869
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 14:35:05 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 17 Sep 2002 14:34:34 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 17 Sep 2002 14:34:33 -0400
Received: from xythoslap ([216.36.77.241]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 17 Sep 2002 14:34:10 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 11:34:10 -0700
Message-ID: <009501c25e78$d1024ab0$b701a8c0@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
X-OriginalArrivalTime: 17 Sep 2002 18:34:10.0781 (UTC) FILETIME=[D08D68D0:01C25E78]
Subject: WebDAV Meeting in Atlanta
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6671
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>
Content-Transfer-Encoding: 7bit



Location information is out for the 55th IETF in Atlanta
(http://www.ietf.org/meetings/IETF-55.html)

I plan to ask the IETF for a meeting slot for WebDAV in Atlanta.  If you
can attend, I encourage you to do so (and let me know if there are any
particular conflicts to avoid). The WG meeting in Santa Cruz was very
productive -- discussions improved understanding on many issues that had
languished on the list.

In addition to the WebDAV WG meeting, there are usually other WG
meetings of interest to Web/WebDAV people. E.g based on the last couple
IETFs, one might expect to see meetings in Atlanta including:
 - Open Pluggable Edge [Web] Services WG, 
 - The Jabber BOF in Yokohama was quite interesting as Jabber is a
XML-based protocol that some see as a general-purpose quick messaging
protocol, not just for instant messaging
 - Simple Network and Alarm Protocol: was discussed at Lemonade (Unified
or Enhanced Messaging) BOF
 - Cross Registry Information Service Protocol (was BOF)
 - Geographic Information Privacy considerations WG
 - XML Configuration BOF (Ops area)
 - Audio/Video Transport WG (Transport area)

Lisa



From w3c-dist-auth-request@w3.org  Tue Sep 17 15:15:35 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26739
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 15:15:35 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HJFso06048;
	Tue, 17 Sep 2002 15:15:54 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 15:15:54 -0400 (EDT)
Resent-Message-Id: <200209171915.g8HJFso06048@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HJFqI06018
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 15:15:52 -0400 (EDT)
Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA27547
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 15:15:52 -0400
Received: from inet-mail3.oracle.com (localhost [127.0.0.1])
	by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8HJFLP16781
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 12:15:21 -0700 (PDT)
Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15])
	by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8HJFJR16769;
	Tue, 17 Sep 2002 12:15:19 -0700 (PDT)
Received: from oracle.com (ikirnos-pc.us.oracle.com [130.35.68.81])
	by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8HJFJN03834;
	Tue, 17 Sep 2002 13:15:19 -0600 (MDT)
Message-ID: <3D877FCE.EDF1A5C4@oracle.com>
Date: Tue, 17 Sep 2002 12:17:34 -0700
From: Ilya Kirnos <ilya.kirnos@oracle.com>
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Roy T. Fielding" <fielding@apache.org>
CC: Webdav WG <w3c-dist-auth@w3c.org>
References: <8849D3D8-C9D5-11D6-8B7B-000393753936@apache.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6672
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>
Content-Transfer-Encoding: 7bit



"Roy T. Fielding" wrote:

> Authorization is granted/denied based on the method of the request.
> There might even be different challenges per method.  In other words,
> this idea won't work for HTTP.
>

right, i was hoping to finesse the issue by saying that if any method needed
authentication, the server should challenge.  however, if challenges differ
for different methods, then obviously this won't work.

>
> The original idea of OPTIONS was that, if the client wished to test the
> options for a specific request, then it would include that request's
> request-line and headers in the body of the OPTIONS request.  The server
> would then look at the body to determine what the options would be and
> report that back to the client.  However, since the WG did not want to
> define the format of such a response, the feature got dropped.
>
> The alternative was to simply issue the request with Expect: 100-continue.
>
> I don't know if that is sufficient for your problem, but I do know that
> using a T/F request header field on OPTIONS is not.  A minimum would be
> to list the methods in that field instead.  I also suggest finding a
> less verbose field name.
>

sounds like an idea to me, but if in fact it is common for servers to have
different challenges for different methods, then we have a whole new set of
problems.  would the order of the list of methods determine which challenge is
returned?  do clients have to issue this OPTIONS request for each new
operation they try to do (i.e., i sent a list that had PUT first for my last
operation, but now i'm about to do a PROPPATCH -- do i have to send a new list
that has PROPPATCH first?).

perhaps in its response the server could return which methods the challenge
would cover if successfully answered.  so the sequence would look like:

request:

OPTIONS /blah HTTP/1.1
Host: blah
Force-Authenticate: PUT, PROPPATCH, etc...

response:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: ....
Authenticate-Methods: PUT, PROPPATCH, etc...

and now the client can send a PUT, PROPPATCH, or etc... if it has the right
credential for the challenge.

From my experience with HTTP server configurations, most challenges tend to
cover either all write methods or none (at least if the configuration is done
properly), but this would leave the door open for those that do something
different.

-ilya




From w3c-dist-auth-request@w3.org  Tue Sep 17 15:18:37 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26887
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 15:18:37 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HJJDX06420;
	Tue, 17 Sep 2002 15:19:13 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 15:19:13 -0400 (EDT)
Resent-Message-Id: <200209171919.g8HJJDX06420@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HJJCI06394
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 15:19:12 -0400 (EDT)
Received: from inet-mail2.oracle.com (inet-mail2.oracle.com [148.87.2.202])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA28418
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 15:19:12 -0400
Received: from inet-mail2.oracle.com (localhost [127.0.0.1])
	by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8HJIfZ25115
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 12:18:41 -0700 (PDT)
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13])
	by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8HJIZZ25032;
	Tue, 17 Sep 2002 12:18:35 -0700 (PDT)
Received: from oracle.com (ikirnos-pc.us.oracle.com [130.35.68.81])
	by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8HJIYO23796;
	Tue, 17 Sep 2002 13:18:34 -0600 (MDT)
Message-ID: <3D878092.92497362@oracle.com>
Date: Tue, 17 Sep 2002 12:20:50 -0700
From: Ilya Kirnos <ilya.kirnos@oracle.com>
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stefan Eissing <stefan.eissing@greenbytes.de>
CC: Webdav WG <w3c-dist-auth@w3c.org>
References: <C4FA8640-CA1E-11D6-9F78-00039384827E@greenbytes.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6673
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>
Content-Transfer-Encoding: 7bit



Stefan Eissing wrote:

> Ilya,
>
> Am Dienstag den, 17. September 2002, um 01:35, schrieb Ilya Kirnos:
>
> >
> > Clients currently have no reliable means of forcing the server to
> > authenticate them (they can try to preemptively send credentials, but
> > this works only for basic auth, not for digest).  This can lead to
> > situations where the client finds out that it was required to
> > authenticate too late and only after doing lots of work, such as when
> > putting a large file only to get a 401 back at the end of the transfer.
>
> A bad user experience, agreed.
>
> However it would be more elegant if the client could send
> the request without the server executing it and checking thus
> the authentication for the specific method call. That would also
> give any intermediates, like proxies, a chance to determine if
> they need any authorization.
>
> My idea would be to use the IF header for this purpose. A client
> can send a request with an invalid lock token in the IF header.
> The server, being DAV-compliant, will never execute the request.
>
> Now this solution depends on the order of authentication vs. IF
> header check. Therefore my proposal depends on
>
> - does every known server check authentication before lock tokens?
> - could 2518bis say something like: "All user authentication SHOULD
>    take place before other request headers like IF are processed."?
>

i'm not sure this would work, since DAV servers don't even have to support
locking to be compliant.

-ilya




From w3c-dist-auth-request@w3.org  Tue Sep 17 15:38:48 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27728
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 15:38:48 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HJdik08631;
	Tue, 17 Sep 2002 15:39:44 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 15:39:44 -0400 (EDT)
Resent-Message-Id: <200209171939.g8HJdik08631@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HJdgI08601
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 15:39:42 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA01550
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 15:39:42 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 17 Sep 2002 15:29:24 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <TDNR9FXD>; Tue, 17 Sep 2002 15:39:07 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B107839237@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 14:20:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: extending the DAV: HTTP header, was: Issues from Interop/Inte 	 	rim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6674
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>


WG meetings are not, I repeat, *NOT*, where these kinds
of decisions are made.  These decisions are made by the working
group as a whole as represented by consensus on the mailing list.

One does not "report decisions to the list", one makes suggestions
to the list, and then determines whether or not there is consensus
on the list.

This is especially true for a working group meeting that was not
even held at an IETF meeting, and especially true in these times
of restricted travel funds, where physical presence at a meeting
can often be infeasible.

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Tuesday, September 17, 2002 1:40 PM
To: 'Clemm, Geoff'; 'Webdav WG'
Subject: RE: extending the DAV: HTTP header, was: Issues from
Interop/Inte rim WG Meeting


...

Consensus was quite clear at the WG meeting on both these issues.  I
report this to the list to make it clear that significant dissent on the
list, along with feasible alternative solutions to the problems
encountered, would be required to overturn that.



From w3c-dist-auth-request@w3.org  Tue Sep 17 16:27:02 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28834
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 16:27:01 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HKRid11439;
	Tue, 17 Sep 2002 16:27:44 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 16:27:44 -0400 (EDT)
Resent-Message-Id: <200209172027.g8HKRid11439@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HKRgI11413
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 16:27:42 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA10583
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 16:27:42 -0400
Received: (qmail 13867 invoked by uid 0); 17 Sep 2002 19:46:53 -0000
Received: from p3ee24731.dip.t-dialin.net (HELO lisa) (62.226.71.49)
  by mail.gmx.net (mp012-rz3) with SMTP; 17 Sep 2002 19:46:53 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Ilya Kirnos" <ilya.kirnos@oracle.com>,
        "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 21:46:52 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCKEOFFFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <3D877FCE.EDF1A5C4@oracle.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: RE: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6675
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>
Content-Transfer-Encoding: 7bit


Some thoughts....

1) Do we really have an interop issue at all? From what I hear, it's
considered a problem that when submitting a large PUT, you may not hear
about the 401 before you have sent the whole request. So that's "just" a
performance issue (actually, a known one).

2) If there *would be* consensus that we need this kind of
you-wikll-have-to-authenticate-for-PUT signalling, I'd propose to make this
a live property. Just issue a PROPFIND on it in case you want to know. No
new request header (-> HTTP header namespace unaffected), no new OPTIONS
semantics, no new compliance class.

3) Finally -- we should be looking for *existing* ways to solve this problem
for RFC2518bis. For instance:

3a) Try a PROPPATCH first -- if you can't change the metadata, it's likely
that you won't be able to change the content either.

3b) Try a zero-length PUT first.

3c) Try a LOCK first.

3d) Try a PUT with known-to-fail If header first (-> Stefan's proposal).

...and so on.


Julian

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Ilya Kirnos
> Sent: Tuesday, September 17, 2002 9:18 PM
> To: Roy T. Fielding
> Cc: Webdav WG
> Subject: Re: Interop issue: how can clients force authentication?
>
>
>
>
> "Roy T. Fielding" wrote:
>
> > Authorization is granted/denied based on the method of the request.
> > There might even be different challenges per method.  In other words,
> > this idea won't work for HTTP.
> >
>
> right, i was hoping to finesse the issue by saying that if any
> method needed
> authentication, the server should challenge.  however, if
> challenges differ
> for different methods, then obviously this won't work.
>
> >
> > The original idea of OPTIONS was that, if the client wished to test the
> > options for a specific request, then it would include that request's
> > request-line and headers in the body of the OPTIONS request.  The server
> > would then look at the body to determine what the options would be and
> > report that back to the client.  However, since the WG did not want to
> > define the format of such a response, the feature got dropped.
> >
> > The alternative was to simply issue the request with Expect:
> 100-continue.
> >
> > I don't know if that is sufficient for your problem, but I do know that
> > using a T/F request header field on OPTIONS is not.  A minimum would be
> > to list the methods in that field instead.  I also suggest finding a
> > less verbose field name.
> >
>
> sounds like an idea to me, but if in fact it is common for servers to have
> different challenges for different methods, then we have a whole
> new set of
> problems.  would the order of the list of methods determine which
> challenge is
> returned?  do clients have to issue this OPTIONS request for each new
> operation they try to do (i.e., i sent a list that had PUT first
> for my last
> operation, but now i'm about to do a PROPPATCH -- do i have to
> send a new list
> that has PROPPATCH first?).
>
> perhaps in its response the server could return which methods the
> challenge
> would cover if successfully answered.  so the sequence would look like:
>
> request:
>
> OPTIONS /blah HTTP/1.1
> Host: blah
> Force-Authenticate: PUT, PROPPATCH, etc...
>
> response:
>
> HTTP/1.1 401 Unauthorized
> WWW-Authenticate: ....
> Authenticate-Methods: PUT, PROPPATCH, etc...
>
> and now the client can send a PUT, PROPPATCH, or etc... if it has
> the right
> credential for the challenge.
>
> From my experience with HTTP server configurations, most
> challenges tend to
> cover either all write methods or none (at least if the
> configuration is done
> properly), but this would leave the door open for those that do something
> different.
>
> -ilya
>
>



From w3c-dist-auth-request@w3.org  Tue Sep 17 16:42:47 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29656
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 16:42:47 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HKh6L12493;
	Tue, 17 Sep 2002 16:43:06 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 16:43:06 -0400 (EDT)
Resent-Message-Id: <200209172043.g8HKh6L12493@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HKh4I12467
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 16:43:04 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA14940
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 16:43:04 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 17 Sep 2002 16:41:30 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 17 Sep 2002 16:41:28 -0400
Received: from xythoslap ([216.36.77.241]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 17 Sep 2002 16:41:05 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Clemm, Geoff'" <gclemm@rational.com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 13:41:04 -0700
Message-ID: <00af01c25e8a$8b747c40$b701a8c0@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B107839237@SUS-MA1IT01>
X-OriginalArrivalTime: 17 Sep 2002 20:41:05.0152 (UTC) FILETIME=[8B123800:01C25E8A]
Subject: RE: extending the DAV: HTTP header, was: Issues from Interop/Inte 	 	rim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6676
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>
Content-Transfer-Encoding: 7bit


I'm sorry Geoff, I tried to be careful in my wording exactly because of
these issues, of which I am in fact very sensitive.  Let clarify and fix
the misquote.

I said "I report this to the list" (that the WG had consensus).  I did
not say "report decisions to the list".  It is appropriate to convey WG
meeting consensus to the mailing list.  This was an official open WG
meeting and therefore taking consensus of the meeting attendees was an
appropriate thing to do.

I also specifically said in the paragraph you quote that the mailing
list could "overturn" this consensus.  The mailing list can do this with
any WG consensus, just as it can also confirm, or fail to overturn.  

Consensus was achieved at the WG meeting on various recommendations and
proposals to make to the list.  Nobody used the words "decisions".
Nobody said anything was final.

Mailing list participation and review is crucial to the IETF process.
However, if a WG is not allowed to determine consensus in person, at
official WG meetings, and report recommendations to the list, then the
WG loses an important tool for making progress.

Lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]
> On Behalf Of Clemm, Geoff
> Sent: Tuesday, September 17, 2002 11:21 AM
> To: 'Webdav WG'
> Subject: RE: extending the DAV: HTTP header, was: Issues from
Interop/Inte
> rim WG Meeting
> 
> 
> WG meetings are not, I repeat, *NOT*, where these kinds
> of decisions are made.  These decisions are made by the working
> group as a whole as represented by consensus on the mailing list.
> 
> One does not "report decisions to the list", one makes suggestions
> to the list, and then determines whether or not there is consensus
> on the list.
> 
> This is especially true for a working group meeting that was not
> even held at an IETF meeting, and especially true in these times
> of restricted travel funds, where physical presence at a meeting
> can often be infeasible.
> 
> Cheers,
> Geoff
> 
> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Tuesday, September 17, 2002 1:40 PM
> To: 'Clemm, Geoff'; 'Webdav WG'
> Subject: RE: extending the DAV: HTTP header, was: Issues from
> Interop/Inte rim WG Meeting
> 
> 
> ...
> 
> Consensus was quite clear at the WG meeting on both these issues.  I
> report this to the list to make it clear that significant dissent on
the
> list, along with feasible alternative solutions to the problems
> encountered, would be required to overturn that.



From w3c-dist-auth-request@w3.org  Tue Sep 17 17:13:46 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00971
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 17:13:46 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HLEbR15183;
	Tue, 17 Sep 2002 17:14:37 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 17:14:37 -0400 (EDT)
Resent-Message-Id: <200209172114.g8HLEbR15183@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HLEZI15157
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 17:14:35 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA23605
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 17:14:35 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 17 Sep 2002 17:14:04 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 17 Sep 2002 17:14:04 -0400
Received: from xythoslap ([216.36.77.241]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 17 Sep 2002 17:13:40 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 14:13:37 -0700
Message-ID: <00bb01c25e8f$191bc5e0$b701a8c0@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
X-OriginalArrivalTime: 17 Sep 2002 21:13:40.0877 (UTC) FILETIME=[18C62BD0:01C25E8F]
Subject: New RFC2518 bis draft
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6677
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>
Content-Transfer-Encoding: 7bit


 

A new RFC2518 draft was submitted to internet-drafts. I wanted to get it
out quickly because after last week there were lots of changes, which
deserve to be read in full form rather than the bulleted "teaser" list
of issues that previously went to the list.  Don't worry, it will still
change, I expect lots of feedback.

 

The text draft, along with the Word doc version (with revision marks)
and the "RFC2518 Changes" document which lists by issue, can all be
found in this (slash-terminated!) WebDAV collection:
http://www.sharemation.com/~milele/public/dav/

 

Lisa




From w3c-dist-auth-request@w3.org  Tue Sep 17 18:22:53 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02571
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 18:22:52 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HMKQj19679;
	Tue, 17 Sep 2002 18:20:26 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 18:20:26 -0400 (EDT)
Resent-Message-Id: <200209172220.g8HMKQj19679@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HMKOI19649
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 18:20:24 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA02042
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 18:20:24 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 17 Sep 2002 18:10:06 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <TDR3M7RX>; Tue, 17 Sep 2002 18:19:53 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B107839249@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 17:37:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: Issue: Requiring server to use / terminated URL for returned  	 	 	collections
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6678
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>


There was not enough information in this message to determine
what exactly was the problem that he was reporting.  You can type
in a non-slash terminated URL into IE5 (e.g.
<http://www.webdav.org/deltav>, and relative references are
handled properly.

Perhaps he was testing against a poorly implemented server
(i.e. one that did not either 302-redirect to the slash terminated
or did not return a slash-terminated Content-Location header).

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Tuesday, September 17, 2002 1:28 PM
To: 'Clemm, Geoff'; 'Webdav WG'
Subject: RE: Issue: Requiring server to use / terminated URL for
returned collections



I dug out another testimonial to the interoperability problems of not
consistently using trailing slashes. 

Geoff Alexander said:
"We are developing a WebDAV server and have encountered interoperability
problem with request on collections in which the resource does not have
a
trailing slash.  Where do things stand on this issue?  Our testing
indicates
that the above does not work in the real world.  For example, both IE 5
and
Netscape 4.7 do not properly process relative references in response to
a
GET request on a collection without the trailing slash..  I guess one
could
say that IE and Netscape only support the HTTP protocol and not WebDAV
protocol, but then our server would have to determine whether the
request
was HTTP or WebDAV (which is not a workable solution).  Also, we have
encountered interoperability problem with other WebDAV clients."

http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0247.html

lisa



From w3c-dist-auth-request@w3.org  Tue Sep 17 18:26:57 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02674
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 18:26:57 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HMMlM19839;
	Tue, 17 Sep 2002 18:22:47 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 18:22:47 -0400 (EDT)
Resent-Message-Id: <200209172222.g8HMMlM19839@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HMMkI19812
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 18:22:46 -0400 (EDT)
Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA02415
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 18:22:46 -0400
Received: from inet-mail4.oracle.com (localhost [127.0.0.1])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8HMMF705453
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 15:22:15 -0700 (PDT)
Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8HMMEp05443;
	Tue, 17 Sep 2002 15:22:14 -0700 (PDT)
Received: from oracle.com (ikirnos-pc.us.oracle.com [130.35.68.81])
	by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8HMMEj05172;
	Tue, 17 Sep 2002 16:22:14 -0600 (MDT)
Message-ID: <3D87AB9D.E7508AA2@oracle.com>
Date: Tue, 17 Sep 2002 15:24:29 -0700
From: Ilya Kirnos <ilya.kirnos@oracle.com>
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
CC: Webdav WG <w3c-dist-auth@w3c.org>
References: <JIEGINCHMLABHJBIGKBCKEOFFFAA.julian.reschke@gmx.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6679
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>
Content-Transfer-Encoding: 7bit



Julian Reschke wrote:

> Some thoughts....
>
> 1) Do we really have an interop issue at all? From what I hear, it's
> considered a problem that when submitting a large PUT, you may not hear
> about the 401 before you have sent the whole request. So that's "just" a
> performance issue (actually, a known one).
>

that's just one example, although a pretty severe one.  in general, i believe
it's a must that clients have a way to authenticate themselves when they wish.

>
> 2) If there *would be* consensus that we need this kind of
> you-wikll-have-to-authenticate-for-PUT signalling, I'd propose to make this
> a live property. Just issue a PROPFIND on it in case you want to know. No
> new request header (-> HTTP header namespace unaffected), no new OPTIONS
> semantics, no new compliance class.
>

we discussed something like this in the WG meeting.  an OPTIONS header seemed
like a cleaner approach to me.


>
> 3) Finally -- we should be looking for *existing* ways to solve this problem
> for RFC2518bis. For instance:
>

we also discussed this in the meeting and rejected in turn each method that came
up.   none of them seemed reliable/clean enough, but i'm willing to hear
suggestions.  (see my comments below)


>
> 3a) Try a PROPPATCH first -- if you can't change the metadata, it's likely
> that you won't be able to change the content either.
>

likely, but not certain.  and now you've possibly changed the metadata.

>
> 3b) Try a zero-length PUT first.
>

probably would work, but leaves a file behind (remember, i just wanted to
authenticate, not necessarily upload anything.)

>
> 3c) Try a LOCK first.
>

servers don't have to support locking.

>
> 3d) Try a PUT with known-to-fail If header first (-> Stefan's proposal).
>

maybe.  what's known to fail?


-ilya




From w3c-dist-auth-request@w3.org  Tue Sep 17 18:55:58 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03181
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 18:55:58 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HMuva22654;
	Tue, 17 Sep 2002 18:56:57 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 18:56:57 -0400 (EDT)
Resent-Message-Id: <200209172256.g8HMuva22654@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HMutI22628
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 18:56:55 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA06111
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 18:56:55 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 17 Sep 2002 18:46:38 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <TDR3M9AH>; Tue, 17 Sep 2002 18:56:25 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10783924A@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 18:49:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: extending the DAV: HTTP header, was: Issues from Interop/Inte 	rim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6680
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>


Sorry about the typographical confusion.  The quotes around "report
decisions to the list" were not intended to indicate a quote from your
message, but rather my summary of what you appeared to be saying.  In
particular, the relevant lines were:

> significant dissent on the list, along with feasible alternative
> solutions to the problems encountered, would be required to overturn
> that.

So to restate my point, consensus in a working group meeting only
means that you have something to propose to the working group
(i.e. the mailing list).  To adopt a change requires consensus in the
working group (i.e. the mailing list), not merely the lack of
"significant dissent" (this is a quote :-), nor the availability of
"feasible alternative solutions" (also a quote).  In particular, a
change can be found "not good enough" (not a quote :-) even if there
are no alternatives.

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Tuesday, September 17, 2002 4:41 PM
To: 'Clemm, Geoff'; 'Webdav WG'
Subject: RE: extending the DAV: HTTP header, was: Issues from
Interop/Inte rim WG Meeting


I'm sorry Geoff, I tried to be careful in my wording exactly because of
these issues, of which I am in fact very sensitive.  Let clarify and fix
the misquote.

I said "I report this to the list" (that the WG had consensus).  I did
not say "report decisions to the list".  It is appropriate to convey WG
meeting consensus to the mailing list.  This was an official open WG
meeting and therefore taking consensus of the meeting attendees was an
appropriate thing to do.

I also specifically said in the paragraph you quote that the mailing
list could "overturn" this consensus.  The mailing list can do this with
any WG consensus, just as it can also confirm, or fail to overturn.  

Consensus was achieved at the WG meeting on various recommendations and
proposals to make to the list.  Nobody used the words "decisions".
Nobody said anything was final.

Mailing list participation and review is crucial to the IETF process.
However, if a WG is not allowed to determine consensus in person, at
official WG meetings, and report recommendations to the list, then the
WG loses an important tool for making progress.

Lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]
> On Behalf Of Clemm, Geoff
> Sent: Tuesday, September 17, 2002 11:21 AM
> To: 'Webdav WG'
> Subject: RE: extending the DAV: HTTP header, was: Issues from
Interop/Inte
> rim WG Meeting
> 
> 
> WG meetings are not, I repeat, *NOT*, where these kinds
> of decisions are made.  These decisions are made by the working
> group as a whole as represented by consensus on the mailing list.
> 
> One does not "report decisions to the list", one makes suggestions
> to the list, and then determines whether or not there is consensus
> on the list.
> 
> This is especially true for a working group meeting that was not
> even held at an IETF meeting, and especially true in these times
> of restricted travel funds, where physical presence at a meeting
> can often be infeasible.
> 
> Cheers,
> Geoff
> 
> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Tuesday, September 17, 2002 1:40 PM
> To: 'Clemm, Geoff'; 'Webdav WG'
> Subject: RE: extending the DAV: HTTP header, was: Issues from
> Interop/Inte rim WG Meeting
> 
> 
> ...
> 
> Consensus was quite clear at the WG meeting on both these issues.  I
> report this to the list to make it clear that significant dissent on
the
> list, along with feasible alternative solutions to the problems
> encountered, would be required to overturn that.



From w3c-dist-auth-request@w3.org  Tue Sep 17 19:37:22 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03867
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 19:37:21 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8HNcFm29312;
	Tue, 17 Sep 2002 19:38:15 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 19:38:15 -0400 (EDT)
Resent-Message-Id: <200209172338.g8HNcFm29312@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8HNcDI29276
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 19:38:13 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA12808
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 19:38:12 -0400
Received: (qmail 24716 invoked by uid 0); 17 Sep 2002 23:38:07 -0000
Received: from pd950c388.dip.t-dialin.net (HELO lisa) (217.80.195.136)
  by mail.gmx.net (mp016-rz3) with SMTP; 17 Sep 2002 23:38:07 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Ilya Kirnos" <ilya.kirnos@oracle.com>,
        "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Wed, 18 Sep 2002 01:38:06 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCEEOKFFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <3D87AB9D.E7508AA2@oracle.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: RE: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6681
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>
Content-Transfer-Encoding: 7bit


> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Ilya Kirnos
> Sent: Wednesday, September 18, 2002 12:24 AM
> To: Julian Reschke
> Cc: Webdav WG
> Subject: Re: Interop issue: how can clients force authentication?
>
>
>
>
> Julian Reschke wrote:
>
> > Some thoughts....
> >
> > 1) Do we really have an interop issue at all? From what I hear, it's
> > considered a problem that when submitting a large PUT, you may not hear
> > about the 401 before you have sent the whole request. So that's "just" a
> > performance issue (actually, a known one).
> >
>
> that's just one example, although a pretty severe one.  in
> general, i believe
> it's a must that clients have a way to authenticate themselves
> when they wish.

I think at this point you should make clear what problem you want to solve.

From what I hear now, you want to authenticate, but not for a specific
method call on a specific resource. What is this supposed to *mean*? What
principals are known may depend on the request URI. Whether (and as who)
you need to authenticate to apply a certain method to a resource depends on
the resource *and* the method.

In general, the answer -- you'lll have to try.

So please restate what was considered to be an actual interop problem.

> >
> > 2) If there *would be* consensus that we need this kind of
> > you-wikll-have-to-authenticate-for-PUT signalling, I'd propose
> to make this
> > a live property. Just issue a PROPFIND on it in case you want
> to know. No
> > new request header (-> HTTP header namespace unaffected), no new OPTIONS
> > semantics, no new compliance class.
> >
>
> we discussed something like this in the WG meeting.  an OPTIONS
> header seemed
> like a cleaner approach to me.

Cleaner in what way? I have listed a few reasons not to use OPTIONS (I even
forgot to mention that it'll save you a roundtrip in case you have to do a
PROPFIND first anyway).

> > 3) Finally -- we should be looking for *existing* ways to solve
> this problem
> > for RFC2518bis. For instance:
> >
>
> we also discussed this in the meeting and rejected in turn each
> method that came
> up.   none of them seemed reliable/clean enough, but i'm willing to hear
> suggestions.  (see my comments below)
>
>
> >
> > 3a) Try a PROPPATCH first -- if you can't change the metadata,
> it's likely
> > that you won't be able to change the content either.
> >
>
> likely, but not certain.  and now you've possibly changed the metadata.
>
> >
> > 3b) Try a zero-length PUT first.
> >
>
> probably would work, but leaves a file behind (remember, i just wanted to
> authenticate, not necessarily upload anything.)

Right. Lesson learned -- it doesn't make sense to try to come up for
workarounds until the problem is clearly stated.

> > 3c) Try a LOCK first.
> >
>
> servers don't have to support locking.

Yes. Servers don't have to support authentication either.

> > 3d) Try a PUT with known-to-fail If header first (-> Stefan's proposal).
> >
>
> maybe.  what's known to fail?

An invalid lock token, an invalid ETag, ...


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



From w3c-dist-auth-request@w3.org  Tue Sep 17 20:31:07 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04592
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 20:31:06 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8I0VwC02155;
	Tue, 17 Sep 2002 20:31:58 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 20:31:58 -0400 (EDT)
Resent-Message-Id: <200209180031.g8I0VwC02155@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8I0VrI02125
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 20:31:53 -0400 (EDT)
Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA19988
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 20:31:53 -0400
Received: from inet-mail4.oracle.com (localhost [127.0.0.1])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8I0VM715295
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 17:31:22 -0700 (PDT)
Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8I0VLp15291
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 17:31:21 -0700 (PDT)
Received: from rgmum2.us.oracle.com (rgmum2.us.oracle.com [138.1.191.23])
	by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8I0VLr05195
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 18:31:21 -0600 (MDT)
Received: from dhcp-4op7-4op8-east-130-35-171-81.us.oracle.com by rgmum3.us.oracle.com
	with ESMTP id 64993481032309079; Tue, 17 Sep 2002 18:31:19 -0600
Message-ID: <019901c25eaa$055987c0$51ab2382@us.oracle.com>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: "Julian Reschke" <julian.reschke@gmx.de>,
        "Ilya Kirnos" <ilya.kirnos@oracle.com>,
        "Webdav WG" <w3c-dist-auth@w3c.org>
Cc: "Sam Idicula" <Sam.Idicula@oracle.com>
References: <JIEGINCHMLABHJBIGKBCKEOFFFAA.julian.reschke@gmx.de>
Date: Tue, 17 Sep 2002 17:26:23 -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: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6682
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>
Content-Transfer-Encoding: 7bit


What we do is to send the authentication challenge for any method other than
GET or HEAD or OPTIONS.  I recall from the interop event that a number of
other servers did the same thing.

Most clients issue a LOCK or PROPFIND first and avoid this problem, but
perhaps this could be spelled out in the spec.

--Eric

----- Original Message -----
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Ilya Kirnos" <ilya.kirnos@oracle.com>; "Webdav WG"
<w3c-dist-auth@w3c.org>
Sent: Tuesday, September 17, 2002 12:46 PM
Subject: RE: Interop issue: how can clients force authentication?


>
> Some thoughts....
>
> 1) Do we really have an interop issue at all? From what I hear, it's
> considered a problem that when submitting a large PUT, you may not hear
> about the 401 before you have sent the whole request. So that's "just" a
> performance issue (actually, a known one).
>
> 2) If there *would be* consensus that we need this kind of
> you-wikll-have-to-authenticate-for-PUT signalling, I'd propose to make
this
> a live property. Just issue a PROPFIND on it in case you want to know. No
> new request header (-> HTTP header namespace unaffected), no new OPTIONS
> semantics, no new compliance class.
>
> 3) Finally -- we should be looking for *existing* ways to solve this
problem
> for RFC2518bis. For instance:
>
> 3a) Try a PROPPATCH first -- if you can't change the metadata, it's likely
> that you won't be able to change the content either.
>
> 3b) Try a zero-length PUT first.
>
> 3c) Try a LOCK first.
>
> 3d) Try a PUT with known-to-fail If header first (-> Stefan's proposal).
>
> ..and so on.
>
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Ilya Kirnos
> > Sent: Tuesday, September 17, 2002 9:18 PM
> > To: Roy T. Fielding
> > Cc: Webdav WG
> > Subject: Re: Interop issue: how can clients force authentication?
> >
> >
> >
> >
> > "Roy T. Fielding" wrote:
> >
> > > Authorization is granted/denied based on the method of the request.
> > > There might even be different challenges per method.  In other words,
> > > this idea won't work for HTTP.
> > >
> >
> > right, i was hoping to finesse the issue by saying that if any
> > method needed
> > authentication, the server should challenge.  however, if
> > challenges differ
> > for different methods, then obviously this won't work.
> >
> > >
> > > The original idea of OPTIONS was that, if the client wished to test
the
> > > options for a specific request, then it would include that request's
> > > request-line and headers in the body of the OPTIONS request.  The
server
> > > would then look at the body to determine what the options would be and
> > > report that back to the client.  However, since the WG did not want to
> > > define the format of such a response, the feature got dropped.
> > >
> > > The alternative was to simply issue the request with Expect:
> > 100-continue.
> > >
> > > I don't know if that is sufficient for your problem, but I do know
that
> > > using a T/F request header field on OPTIONS is not.  A minimum would
be
> > > to list the methods in that field instead.  I also suggest finding a
> > > less verbose field name.
> > >
> >
> > sounds like an idea to me, but if in fact it is common for servers to
have
> > different challenges for different methods, then we have a whole
> > new set of
> > problems.  would the order of the list of methods determine which
> > challenge is
> > returned?  do clients have to issue this OPTIONS request for each new
> > operation they try to do (i.e., i sent a list that had PUT first
> > for my last
> > operation, but now i'm about to do a PROPPATCH -- do i have to
> > send a new list
> > that has PROPPATCH first?).
> >
> > perhaps in its response the server could return which methods the
> > challenge
> > would cover if successfully answered.  so the sequence would look like:
> >
> > request:
> >
> > OPTIONS /blah HTTP/1.1
> > Host: blah
> > Force-Authenticate: PUT, PROPPATCH, etc...
> >
> > response:
> >
> > HTTP/1.1 401 Unauthorized
> > WWW-Authenticate: ....
> > Authenticate-Methods: PUT, PROPPATCH, etc...
> >
> > and now the client can send a PUT, PROPPATCH, or etc... if it has
> > the right
> > credential for the challenge.
> >
> > From my experience with HTTP server configurations, most
> > challenges tend to
> > cover either all write methods or none (at least if the
> > configuration is done
> > properly), but this would leave the door open for those that do
something
> > different.
> >
> > -ilya
> >
> >
>
>



From w3c-dist-auth-request@w3.org  Tue Sep 17 20:51:56 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04890
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 20:51:56 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8I0qhB03426;
	Tue, 17 Sep 2002 20:52:43 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 20:52:43 -0400 (EDT)
Resent-Message-Id: <200209180052.g8I0qhB03426@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8I0qfI03400
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 20:52:41 -0400 (EDT)
Received: from inet-mail2.oracle.com (inet-mail2.oracle.com [148.87.2.202])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA22236
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 20:52:40 -0400
Received: from inet-mail2.oracle.com (localhost [127.0.0.1])
	by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8I0q9Z17596
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 17:52:09 -0700 (PDT)
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13])
	by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8I0q8Z17576
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 17:52:08 -0700 (PDT)
Received: from rgmum3.us.oracle.com (rgmum3.us.oracle.com [138.1.191.24])
	by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8I0q7O07386
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 18:52:07 -0600 (MDT)
Received: from dhcp-4op7-4op8-east-130-35-171-81.us.oracle.com by rgmum2.us.oracle.com
	with ESMTP id 65003821032310327; Tue, 17 Sep 2002 18:52:07 -0600
Message-ID: <022201c25eac$ecbc1450$51ab2382@us.oracle.com>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: "Clemm, Geoff" <gclemm@rational.com>, "Webdav WG" <w3c-dist-auth@w3c.org>
References: <3906C56A7BD1F54593344C05BD1374B10841D58A@SUS-MA1IT01>
Date: Tue, 17 Sep 2002 17:47:11 -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: ETags, was: Issues from Interop/Interim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6683
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>
Content-Transfer-Encoding: 7bit


As long as you don't mind a client saying something to the effect of:

"This server does not support the minimal level of functionality that
<product> requires of a WebDAV server (ETags).  We strongly discourage you
from using this server, as you may lose work."

when it points at your server, then go ahead and don't support ETags.

--Eric

----- Original Message -----
From: "Clemm, Geoff" <gclemm@rational.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Sent: Tuesday, September 17, 2002 6:50 AM
Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting


>
> I agree.
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Tuesday, September 17, 2002 4:58 AM
> To: Lisa Dusseault; Webdav WG
> Subject: ETags, was: Issues from Interop/Interim WG Meeting
>
>
>
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> > Sent: Sunday, September 15, 2002 8:14 PM
> > To: Webdav WG
> > Subject: Issues from Interop/Interim WG Meeting
> >
> > ...
> > -  Be clear in spec that servers MUST do ETags. Explain how necessary
> > this is to solve the lost update problem.
> > ..
>
> ETags are a good thing, correct. However, HTTP (RFC2616) doesn't require
> them, RFC2518 doesn't require them, and they '*aren't* required for
> interoperability. So there's no way to require them in RFC2518bis -- it
> would break all servers that don't have them.
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>



From w3c-dist-auth-request@w3.org  Tue Sep 17 21:16:59 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05310
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 21:16:59 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8I1Htp04936;
	Tue, 17 Sep 2002 21:17:55 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 21:17:55 -0400 (EDT)
Resent-Message-Id: <200209180117.g8I1Htp04936@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8I1HrI04906
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 21:17:53 -0400 (EDT)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA24804
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 21:17:52 -0400
Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225])
	by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g8I1Hph19814
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 18:17:51 -0700 (PDT)
Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5d657d56e2118164e150c@mailgate2.apple.com> for <w3c-dist-auth@w3c.org>;
 Tue, 17 Sep 2002 18:17:51 -0700
Received: from apple.com (luthji.apple.com [17.202.43.76])
	by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g8I1HpV12942
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 18:17:51 -0700 (PDT)
Date: Tue, 17 Sep 2002 18:17:40 -0700
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
From: Jim Luther <luther.j@apple.com>
To: Webdav WG <w3c-dist-auth@w3c.org>
Content-Transfer-Encoding: 7bit
In-Reply-To: <022201c25eac$ecbc1450$51ab2382@us.oracle.com>
Message-Id: <6D0A58D8-CAA4-11D6-A0E5-0003934B6A22@apple.com>
X-Mailer: Apple Mail (2.546)
Subject: Digest authentication
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6684
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>
Content-Transfer-Encoding: 7bit


(the post copied below reminded me to say something)

The Mac OS X 10.2 WebDAV file system client posts a warning for Basic 
authentication over connections which are not secure.

Because RFC2518 section 1.71 says, "Since Basic authentication for 
HTTP/1.1 performs essentially clear text transmission of a password, 
Basic authentication MUST NOT be used to authenticate a WebDAV client 
to a server unless the connection is secure", we thought about 
disabling Basic authentication until our client supports secure 
connections. However, we found many servers allow access over insecure 
connections, require authentication, but support only Basic and not 
Digest. Instead of cutting off access to those servers (which do not 
comply with RFC2518), we decided to allow Basic to be used but only 
after the user clicks through a warning dialog which reads, "You have 
been challenged by a WebDAV server which is not secure. If you continue 
and supply your username and password, they can be read while in 
transit."

Once secure connection support is added to our client, we may revisit 
this issue and only allow Basic authentication when the connection is 
secure.

I should have brought this issue up during the Interop event in Santa 
Cruz, because many of the servers I tested against there did not 
support Digest authentication. Since Digest support is a MUST in 
RFC2518, it would be nice if our client could depend on it and not have 
to bother users with a warning.

- Jim

On Tuesday, September 17, 2002, at 05:47 PM, Eric Sedlar wrote:

>
> As long as you don't mind a client saying something to the effect of:
>
> "This server does not support the minimal level of functionality that
> <product> requires of a WebDAV server (ETags).  We strongly discourage 
> you
> from using this server, as you may lose work."
>
> when it points at your server, then go ahead and don't support ETags.
>
> --Eric
>
> ----- Original Message -----
> From: "Clemm, Geoff" <gclemm@rational.com>
> To: "Webdav WG" <w3c-dist-auth@w3c.org>
> Sent: Tuesday, September 17, 2002 6:50 AM
> Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
>
>
>>
>> I agree.
>>
>> -----Original Message-----
>> From: Julian Reschke [mailto:julian.reschke@gmx.de]
>> Sent: Tuesday, September 17, 2002 4:58 AM
>> To: Lisa Dusseault; Webdav WG
>> Subject: ETags, was: Issues from Interop/Interim WG Meeting
>>
>>
>>
>>> From: w3c-dist-auth-request@w3.org
>>> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
>>> Sent: Sunday, September 15, 2002 8:14 PM
>>> To: Webdav WG
>>> Subject: Issues from Interop/Interim WG Meeting
>>>
>>> ...
>>> -  Be clear in spec that servers MUST do ETags. Explain how necessary
>>> this is to solve the lost update problem.
>>> ..
>>
>> ETags are a good thing, correct. However, HTTP (RFC2616) doesn't 
>> require
>> them, RFC2518 doesn't require them, and they '*aren't* required for
>> interoperability. So there's no way to require them in RFC2518bis -- 
>> it
>> would break all servers that don't have them.
>>
>> Julian
>>
>> --
>> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>>
>>
>



From w3c-dist-auth-request@w3.org  Tue Sep 17 21:21:12 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05372
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 21:21:11 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8I1MBI05882;
	Tue, 17 Sep 2002 21:22:11 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 21:22:11 -0400 (EDT)
Resent-Message-Id: <200209180122.g8I1MBI05882@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8I1M9I05854
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 21:22:09 -0400 (EDT)
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA25663
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 21:22:09 -0400
Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225])
	by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g8I1M5919301
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 18:22:06 -0700 (PDT)
Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5d658136f3118164e150c@mailgate2.apple.com> for <w3c-dist-auth@w3c.org>;
 Tue, 17 Sep 2002 18:22:05 -0700
Received: from apple.com (luthji.apple.com [17.202.43.76])
	by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g8I1M5V16307
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 18:22:05 -0700 (PDT)
Date: Tue, 17 Sep 2002 18:21:54 -0700
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
From: Jim Luther <luther.j@apple.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Content-Transfer-Encoding: 7bit
In-Reply-To: <009401c25e77$6c58bff0$b701a8c0@xythoslap>
Message-Id: <047293A2-CAA5-11D6-A0E5-0003934B6A22@apple.com>
X-Mailer: Apple Mail (2.546)
Subject: Re: Interop issue: Can we require clients to accept cookies?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6685
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>
Content-Transfer-Encoding: 7bit


On Tuesday, September 17, 2002, at 11:24 AM, Lisa Dusseault wrote:
>
> Consensus on requiring clients to accept cookies is quite clear: we
> should NOT require WebDAV clients to accept or use cookies.
>
> It seems to me that the text in RFC2518 (silent on cookies) is
> sufficient and nothing needs to be added.
>
> lisa

I also agree that WebDAV should say nothing about cookies. We don't 
have any plans to add support for cookies to our client.

- Jim



From w3c-dist-auth-request@w3.org  Tue Sep 17 21:36:18 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05758
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 21:36:17 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8I1bF007719;
	Tue, 17 Sep 2002 21:37:15 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 21:37:15 -0400 (EDT)
Resent-Message-Id: <200209180137.g8I1bF007719@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8I1bDI07693
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 21:37:13 -0400 (EDT)
Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA27891
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 21:37:12 -0400
Received: from inet-mail4.oracle.com (localhost [127.0.0.1])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8I1af705058
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 18:36:41 -0700 (PDT)
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8I1afp05052;
	Tue, 17 Sep 2002 18:36:41 -0700 (PDT)
Received: from oracle.com (ikirnos-pc.us.oracle.com [130.35.68.81])
	by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8I1aeO18537;
	Tue, 17 Sep 2002 19:36:40 -0600 (MDT)
Message-ID: <3D87D930.66156D05@oracle.com>
Date: Tue, 17 Sep 2002 18:38:56 -0700
From: Ilya Kirnos <ilya.kirnos@oracle.com>
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
CC: Webdav WG <w3c-dist-auth@w3c.org>
References: <JIEGINCHMLABHJBIGKBCEEOKFFAA.julian.reschke@gmx.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6686
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>
Content-Transfer-Encoding: 7bit



Julian Reschke wrote:

> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Ilya Kirnos
> > Sent: Wednesday, September 18, 2002 12:24 AM
> > To: Julian Reschke
> > Cc: Webdav WG
> > Subject: Re: Interop issue: how can clients force authentication?
> >
> >
> >
> >
> > Julian Reschke wrote:
> >
> > > Some thoughts....
> > >
> > > 1) Do we really have an interop issue at all? From what I hear, it's
> > > considered a problem that when submitting a large PUT, you may not hear
> > > about the 401 before you have sent the whole request. So that's "just" a
> > > performance issue (actually, a known one).
> > >
> >
> > that's just one example, although a pretty severe one.  in
> > general, i believe
> > it's a must that clients have a way to authenticate themselves
> > when they wish.
>
> I think at this point you should make clear what problem you want to solve.
>
> From what I hear now, you want to authenticate, but not for a specific
> method call on a specific resource. What is this supposed to *mean*? What
> principals are known may depend on the request URI. Whether (and as who)
> you need to authenticate to apply a certain method to a resource depends on
> the resource *and* the method.
>
> In general, the answer -- you'lll have to try.
>

okay.  this answer is currently not sufficient, for example in the case of a
large PUT.  whether it's an interop or a performance problem, i believe it's
something that needs to be addressed.  if there is something already in the spec
that solves the problem, i would be happy to use it.


>
> So please restate what was considered to be an actual interop problem.
>

clients need a way to authenticate themselves before performing a potentially
expensive operation.  the only such operation that has come up in
interoperability testing thus far is a large PUT, but it is conceivable that
clients will need this for other operations as well.


> > we discussed something like this in the WG meeting.  an OPTIONS
> > header seemed
> > like a cleaner approach to me.
>
> Cleaner in what way? I have listed a few reasons not to use OPTIONS (I even
> forgot to mention that it'll save you a roundtrip in case you have to do a
> PROPFIND first anyway).
>

it was largely based on intuition.  i guess i'd have to see the exact proposal
for this new property to tell you exactly, but if it turns out to be
satisfactory, i'd be happy to use it.

>
> > > 3c) Try a LOCK first.
> > >
> >
> > servers don't have to support locking.
>
> Yes. Servers don't have to support authentication either.
>

i don't see your point.  these issues are orthogonal: a server may want support
authentication but not locking, so i'd like to divorce authentication from
locking if at all possible.

>
> > > 3d) Try a PUT with known-to-fail If header first (-> Stefan's proposal).
> > >
> >
> > maybe.  what's known to fail?
>
> An invalid lock token, an invalid ETag, ...
>

again, i'd like to stay away from a dependency on locking if possible, and etags
support isn't required if i recall correctly.

-ilya




From w3c-dist-auth-request@w3.org  Tue Sep 17 22:11:29 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06366
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 22:11:29 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8I2CKS10697;
	Tue, 17 Sep 2002 22:12:20 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 22:12:20 -0400 (EDT)
Resent-Message-Id: <200209180212.g8I2CKS10697@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8I2CII10671
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 22:12:18 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id WAA32506
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 22:12:18 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 17 Sep 2002 22:11:06 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 17 Sep 2002 22:11:06 -0400
Received: from xythoslap ([198.144.203.248]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 17 Sep 2002 22:10:42 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Ilya Kirnos'" <ilya.kirnos@oracle.com>,
        "'Julian Reschke'" <julian.reschke@gmx.de>
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 19:10:42 -0700
Message-ID: <00d801c25eb8$97ee85a0$b701a8c0@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3D87D930.66156D05@oracle.com>
X-OriginalArrivalTime: 18 Sep 2002 02:10:43.0345 (UTC) FILETIME=[97CAF810:01C25EB8]
Subject: RE: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6687
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>
Content-Transfer-Encoding: 7bit


> this answer is currently not sufficient, for example in the case of a
> large PUT.  whether it's an interop or a performance problem, i
believe
> it's
> something that needs to be addressed.  if there is something already
in
> the spec
> that solves the problem, i would be happy to use it.

There are other problems. In a collection, an unauthenticated user may
have sufficient privilege to see some (publicly visible) resources, but
not others. A PROPFIND to this collection would therefore not reveal all
child resources.  Also, a PROPFIND might return only some publicly
visible properties, not others which might be considered slightly
"sensitive" (like quota?) and not revealed to unauthenticated users.

A PUT to a new resource may be accepted even from anonymous users, but
if the user is unauthenticated, the new resource cannot be initialized
in the same way.  For example, the owner may not set to the user who
created it, or the new resource may go to the collection owner for
approval.

There may be other methods which an unauthenticated user can receive a
success response, but which would work even better if the user were
authenticated.

Can anybody come up with other clever ways for the client to try to
authenticate?  E.g. is it possible for a client to send a reasonable
Digest authentication header with its first request (probably a
PROPFIND, but whatever method happens to be first), and if the
information therein (e.g. realm) is bad, the server responds with the
WWW-Authenticate header with the correct prompting?  That doesn't quite
solve Ilya's performance problem, but perhaps the HTTP 1.1. Continue
mechanism would solve that specific issue.

Lisa



From w3c-dist-auth-request@w3.org  Tue Sep 17 22:56:51 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07255
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 22:56:51 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8I2vo715655;
	Tue, 17 Sep 2002 22:57:50 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 22:57:50 -0400 (EDT)
Resent-Message-Id: <200209180257.g8I2vo715655@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8I2vnI15618
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 22:57:49 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA06387
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 22:57:49 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 17 Sep 2002 22:47:31 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <TDR3NFH1>; Tue, 17 Sep 2002 22:57:18 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10841D7BF@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: Webdav WG <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 22:57:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6689
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>


I have no objection to such a warning (in fact, it sounds
like a good idea to me).  But I agree with Julian
that RFC2518bis should not invalidate a whole class of 
valid 2518 servers, even for a worthy cause such as ETag support.

Cheers,
Geoff

-----Original Message-----
From: Eric Sedlar [mailto:eric.sedlar@oracle.com]
Sent: Tuesday, September 17, 2002 8:47 PM
To: Clemm, Geoff; Webdav WG
Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting


As long as you don't mind a client saying something to the effect of:

"This server does not support the minimal level of functionality that
<product> requires of a WebDAV server (ETags).  We strongly discourage you
from using this server, as you may lose work."

when it points at your server, then go ahead and don't support ETags.

--Eric

----- Original Message -----
From: "Clemm, Geoff" <gclemm@rational.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Sent: Tuesday, September 17, 2002 6:50 AM
Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting


>
> I agree.
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Tuesday, September 17, 2002 4:58 AM
> To: Lisa Dusseault; Webdav WG
> Subject: ETags, was: Issues from Interop/Interim WG Meeting
>
>
>
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> > Sent: Sunday, September 15, 2002 8:14 PM
> > To: Webdav WG
> > Subject: Issues from Interop/Interim WG Meeting
> >
> > ...
> > -  Be clear in spec that servers MUST do ETags. Explain how necessary
> > this is to solve the lost update problem.
> > ..
>
> ETags are a good thing, correct. However, HTTP (RFC2616) doesn't require
> them, RFC2518 doesn't require them, and they '*aren't* required for
> interoperability. So there's no way to require them in RFC2518bis -- it
> would break all servers that don't have them.
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>



From w3c-dist-auth-request@w3.org  Tue Sep 17 22:56:57 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07269
	for <webdav-archive@lists.ietf.org>; Tue, 17 Sep 2002 22:56:57 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8I2vob15638;
	Tue, 17 Sep 2002 22:57:50 -0400 (EDT)
Resent-Date: Tue, 17 Sep 2002 22:57:50 -0400 (EDT)
Resent-Message-Id: <200209180257.g8I2vob15638@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8I2vlI15591
	for <w3c-dist-auth@frink.w3.org>; Tue, 17 Sep 2002 22:57:47 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA06385
	for <w3c-dist-auth@w3c.org>; Tue, 17 Sep 2002 22:57:47 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 17 Sep 2002 22:47:29 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <TDR3NFHB>; Tue, 17 Sep 2002 22:57:16 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10841D7BE@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: Webdav WG <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 22:57:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6688
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>


   From: Ilya Kirnos [mailto:ilya.kirnos@oracle.com]

   Julian Reschke wrote:

   > Try a PUT with known-to-fail If header first (-> Stefan's
   > proposal).

I agree that Stefan's proposal is the most appealing.

   maybe.  what's known to fail?

   > An invalid lock token, an invalid ETag, ...

Actually, I'd suggest a simple logical contradition, i.e.:

If: ("A" Not "A")

   again, i'd like to stay away from a dependency on locking if
   possible, and etags support isn't required if i recall correctly.

etag support isn't required, and locking support isn't required,
but support for the If header is required.

So I suggest we check whether any server which does the If check
before it does an authentication check.  It certainly shouldn't,
since the success or failure of the If check tells you something
about the resource which you probably shouldn't know if you are
not authenticated.

I would have no objection to adding a statement to 2518bis that
states that a server SHOULD do authentication checks before any
If checks.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Wed Sep 18 01:25:34 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09531
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 01:25:34 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8I5QLg01387;
	Wed, 18 Sep 2002 01:26:21 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 01:26:21 -0400 (EDT)
Resent-Message-Id: <200209180526.g8I5QLg01387@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8I5QGI01347
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 01:26:16 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA25351
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 01:26:15 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id WAA07654 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Tue, 17 Sep 2002 22:25:59 -0700
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by sunbelt.seagull.net (8.9.3) with ESMTP id WAA07622 sender obsfucated@us.ibm.com; Tue, 17 Sep 2002 22:25:54 -0700
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8I5PJIV206010; Wed, 18 Sep 2002 01:25:20 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8I5PI9M112026; Wed, 18 Sep 2002 01:25:18 -0400
To: "Lisa Dusseault" <lisa@xythos.com>
Cc: "'Ilya Kirnos'" <ilya.kirnos@oracle.com>,
        "'Julian Reschke'" <julian.reschke@gmx.de>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF52096242.4B411BB1-ON85256C38.0018AE1B@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Wed, 18 Sep 2002 00:34:21 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_09122002|September 12, 2002) at 09/18/2002 01:25:18
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: RE: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6690
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>





> There may be other methods which an unauthenticated user can receive a
> success response, but which would work even better if the user were
> authenticated.

Shouldn't the server just ask for authentication for those methods?


------------------------------------------
Phone: 914-784-7569



From w3c-dist-auth-request@w3.org  Wed Sep 18 02:17:41 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21979
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 02:17:41 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8I6GtN04283;
	Wed, 18 Sep 2002 02:16:55 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 02:16:55 -0400 (EDT)
Resent-Message-Id: <200209180616.g8I6GtN04283@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8I6GrI04257
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 02:16:53 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id CAA30735
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 02:16:53 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 18 Sep 2002 02:14:31 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Wed, 18 Sep 2002 02:14:30 -0400
Received: from xythoslap ([198.144.203.248]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Wed, 18 Sep 2002 02:14:30 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Clemm, Geoff'" <gclemm@rational.com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 23:14:29 -0700
Message-ID: <00e801c25eda$a64052b0$b701a8c0@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10841D7BE@SUS-MA1IT01>
X-OriginalArrivalTime: 18 Sep 2002 06:14:30.0501 (UTC) FILETIME=[A641D950:01C25EDA]
Subject: RE: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6691
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>
Content-Transfer-Encoding: 7bit


 
> Actually, I'd suggest a simple logical contradition, i.e.:
> 
> If: ("A" Not "A")
> 
...
> 
> etag support isn't required, and locking support isn't required,
> but support for the If header is required.

I'm not so sure a server will implement the If header if it doesn't
implement locking.  I'd agree it's required, but it may not be there.
And there's certainly no requirement now that servers do authentication
checks when they do If checks.  That's not required by RFC2518 -- e.g.
if the If test fails because it's logically impossible, then why bother
authenticating?

This seems like trying to fit a round peg in a square hole.

> 
> So I suggest we check whether any server which does the If check
> before it does an authentication check.  It certainly shouldn't,
> since the success or failure of the If check tells you something
> about the resource which you probably shouldn't know if you are
> not authenticated.
> 
> I would have no objection to adding a statement to 2518bis that
> states that a server SHOULD do authentication checks before any
> If checks.
> 
> Cheers,
> Geoff



From w3c-dist-auth-request@w3.org  Wed Sep 18 02:21:31 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26707
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 02:21:31 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8I6M3S06792;
	Wed, 18 Sep 2002 02:22:03 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 02:22:03 -0400 (EDT)
Resent-Message-Id: <200209180622.g8I6M3S06792@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8I6M1I06762
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 02:22:01 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id CAA32173
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 02:22:01 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 18 Sep 2002 02:12:29 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Wed, 18 Sep 2002 02:12:29 -0400
Received: from xythoslap ([198.144.203.248]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Wed, 18 Sep 2002 02:12:05 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Jason Crawford'" <nn683849@smallcue.com>
Cc: "'Ilya Kirnos'" <ilya.kirnos@oracle.com>,
        "'Julian Reschke'" <julian.reschke@gmx.de>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Tue, 17 Sep 2002 23:12:04 -0700
Message-ID: <00e701c25eda$504efaf0$b701a8c0@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <OF52096242.4B411BB1-ON85256C38.0018AE1B@us.ibm.com>
X-OriginalArrivalTime: 18 Sep 2002 06:12:06.0331 (UTC) FILETIME=[505340B0:01C25EDA]
Subject: RE: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6692
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>
Content-Transfer-Encoding: 7bit


> -----Original Message-----
> From: Jason Crawford [mailto:nn683849@smallcue.com]
> Sent: Tuesday, September 17, 2002 9:34 PM
> To: Lisa Dusseault
> Cc: 'Ilya Kirnos'; 'Julian Reschke'; 'Webdav WG'
> Subject: RE: Interop issue: how can clients force authentication?
> 
> > There may be other methods which an unauthenticated user can receive
a
> > success response, but which would work even better if the user were
> > authenticated.
> 
> Shouldn't the server just ask for authentication for those methods?
> 

Not necessarily; if it's possible for the request to return a success
response if the user is unauthenticated, then the server must do so
right away or it may never be able to give a success response.

If a 401 error is returned the first time a client asks to do one of
these methods (like a PROPFIND to a partially-readable collection), how
does the server know the client will ever make the same request?  Maybe
the user doesn't know a username/password and so hits "cancel", and the
client doesn't retry.  And if the client software retries, again without
a username/password, by your logic the server would just respond 401
again.

Lisa



From w3c-dist-auth-request@w3.org  Wed Sep 18 03:12:55 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04789
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 03:12:55 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8I7DUu12896;
	Wed, 18 Sep 2002 03:13:30 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 03:13:30 -0400 (EDT)
Resent-Message-Id: <200209180713.g8I7DUu12896@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8I7DSI12870
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 03:13:28 -0400 (EDT)
Received: from inet-mail2.oracle.com (inet-mail2.oracle.com [148.87.2.202])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA06366
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 03:13:28 -0400
Received: from inet-mail2.oracle.com (localhost [127.0.0.1])
	by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8I7CuZ18946
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 00:12:57 -0700 (PDT)
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13])
	by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8I7CuZ18929
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 00:12:56 -0700 (PDT)
Received: from rgmum1.us.oracle.com (rgmum1.us.oracle.com [138.1.191.22])
	by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8I7CtO29446
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 01:12:55 -0600 (MDT)
Received: from 152.68.17.155 by rgmum3.us.oracle.com
	with ESMTP id 65110221032333174; Wed, 18 Sep 2002 01:12:54 -0600
Message-ID: <014701c25ee2$55c8fb90$9b114498@esedlar>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
References: <3906C56A7BD1F54593344C05BD1374B10841D7BF@SUS-MA1IT01>
Date: Wed, 18 Sep 2002 00:09:31 -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: ETags, was: Issues from Interop/Interim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6693
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>
Content-Transfer-Encoding: 7bit


RFC2518bis wouldn't invalidate a class of servers if it includes a new token
in the DAV: header to indicate support for RFC2518bis.  Clients would still
have to deal with no-Etag servers to support RFC2518, but this might
accellerate implementation of Etags.

--Eric

----- Original Message -----
From: "Clemm, Geoff" <gclemm@rational.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Sent: Tuesday, September 17, 2002 7:57 PM
Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting


>
> I have no objection to such a warning (in fact, it sounds
> like a good idea to me).  But I agree with Julian
> that RFC2518bis should not invalidate a whole class of
> valid 2518 servers, even for a worthy cause such as ETag support.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Eric Sedlar [mailto:eric.sedlar@oracle.com]
> Sent: Tuesday, September 17, 2002 8:47 PM
> To: Clemm, Geoff; Webdav WG
> Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting
>
>
> As long as you don't mind a client saying something to the effect of:
>
> "This server does not support the minimal level of functionality that
> <product> requires of a WebDAV server (ETags).  We strongly discourage you
> from using this server, as you may lose work."
>
> when it points at your server, then go ahead and don't support ETags.
>
> --Eric
>
> ----- Original Message -----
> From: "Clemm, Geoff" <gclemm@rational.com>
> To: "Webdav WG" <w3c-dist-auth@w3c.org>
> Sent: Tuesday, September 17, 2002 6:50 AM
> Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
>
>
> >
> > I agree.
> >
> > -----Original Message-----
> > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > Sent: Tuesday, September 17, 2002 4:58 AM
> > To: Lisa Dusseault; Webdav WG
> > Subject: ETags, was: Issues from Interop/Interim WG Meeting
> >
> >
> >
> > > From: w3c-dist-auth-request@w3.org
> > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> > > Sent: Sunday, September 15, 2002 8:14 PM
> > > To: Webdav WG
> > > Subject: Issues from Interop/Interim WG Meeting
> > >
> > > ...
> > > -  Be clear in spec that servers MUST do ETags. Explain how necessary
> > > this is to solve the lost update problem.
> > > ..
> >
> > ETags are a good thing, correct. However, HTTP (RFC2616) doesn't require
> > them, RFC2518 doesn't require them, and they '*aren't* required for
> > interoperability. So there's no way to require them in RFC2518bis -- it
> > would break all servers that don't have them.
> >
> > Julian
> >
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >
> >
>
>



From w3c-dist-auth-request@w3.org  Wed Sep 18 04:07:11 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05484
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 04:07:10 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8I87xm16974;
	Wed, 18 Sep 2002 04:07:59 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 04:07:59 -0400 (EDT)
Resent-Message-Id: <200209180807.g8I87xm16974@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8I87sI16913
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 04:07:54 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA13623
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 04:07:53 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 10:07:40 +0200
Date: Wed, 18 Sep 2002 10:07:42 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
To: "Eric Sedlar" <eric.sedlar@oracle.com>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <014701c25ee2$55c8fb90$9b114498@esedlar>
Message-Id: <B4CC2CD7-CADD-11D6-9F78-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.482)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6694
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>
Content-Transfer-Encoding: 7bit



Am Mittwoch den, 18. September 2002, um 09:09, schrieb Eric Sedlar:

>
> RFC2518bis wouldn't invalidate a class of servers if it includes a 
> new token
> in the DAV: header to indicate support for RFC2518bis.  Clients 
> would still
> have to deal with no-Etag servers to support RFC2518, but this might
> accellerate implementation of Etags.

But support for ETag on a resource is visible on the getETag Property.
What better place to look for ETag support than there?

//Stefan


> --Eric
>
> ----- Original Message -----
> From: "Clemm, Geoff" <gclemm@rational.com>
> To: "Webdav WG" <w3c-dist-auth@w3c.org>
> Sent: Tuesday, September 17, 2002 7:57 PM
> Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
>
>
>>
>> I have no objection to such a warning (in fact, it sounds
>> like a good idea to me).  But I agree with Julian
>> that RFC2518bis should not invalidate a whole class of
>> valid 2518 servers, even for a worthy cause such as ETag support.
>>
>> Cheers,
>> Geoff
>>
>> -----Original Message-----
>> From: Eric Sedlar [mailto:eric.sedlar@oracle.com]
>> Sent: Tuesday, September 17, 2002 8:47 PM
>> To: Clemm, Geoff; Webdav WG
>> Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting
>>
>>
>> As long as you don't mind a client saying something to the effect of:
>>
>> "This server does not support the minimal level of functionality that
>> <product> requires of a WebDAV server (ETags).  We strongly 
>> discourage you
>> from using this server, as you may lose work."
>>
>> when it points at your server, then go ahead and don't support ETags.
>>
>> --Eric
>>
>> ----- Original Message -----
>> From: "Clemm, Geoff" <gclemm@rational.com>
>> To: "Webdav WG" <w3c-dist-auth@w3c.org>
>> Sent: Tuesday, September 17, 2002 6:50 AM
>> Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
>>
>>
>>>
>>> I agree.
>>>
>>> -----Original Message-----
>>> From: Julian Reschke [mailto:julian.reschke@gmx.de]
>>> Sent: Tuesday, September 17, 2002 4:58 AM
>>> To: Lisa Dusseault; Webdav WG
>>> Subject: ETags, was: Issues from Interop/Interim WG Meeting
>>>
>>>
>>>
>>>> From: w3c-dist-auth-request@w3.org
>>>> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
>>>> Sent: Sunday, September 15, 2002 8:14 PM
>>>> To: Webdav WG
>>>> Subject: Issues from Interop/Interim WG Meeting
>>>>
>>>> ...
>>>> -  Be clear in spec that servers MUST do ETags. Explain how 
>>>> necessary
>>>> this is to solve the lost update problem.
>>>> ..
>>>
>>> ETags are a good thing, correct. However, HTTP (RFC2616) doesn't 
>>> require
>>> them, RFC2518 doesn't require them, and they '*aren't* required for
>>> interoperability. So there's no way to require them in 
>>> RFC2518bis -- it
>>> would break all servers that don't have them.
>>>
>>> Julian
>>>
>>> --
>>> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>>>
>>>
>>
>>
>
>





From w3c-dist-auth-request@w3.org  Wed Sep 18 04:24:12 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05708
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 04:23:45 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8I8OCm18464;
	Wed, 18 Sep 2002 04:24:12 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 04:24:12 -0400 (EDT)
Resent-Message-Id: <200209180824.g8I8OCm18464@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8I8O9I18412
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 04:24:09 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA16084
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 04:24:09 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 10:23:27 +0200
Date: Wed, 18 Sep 2002 10:23:29 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: "'Clemm, Geoff'" <gclemm@rational.com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
To: "Lisa Dusseault" <lisa@xythos.com>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <00e801c25eda$a64052b0$b701a8c0@xythoslap>
Message-Id: <E95E4968-CADF-11D6-9F78-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.482)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6695
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>
Content-Transfer-Encoding: 7bit



Am Mittwoch den, 18. September 2002, um 08:14, schrieb Lisa Dusseault:

>
>
>> Actually, I'd suggest a simple logical contradition, i.e.:
>>
>> If: ("A" Not "A")
>>
> ....
>>
>> etag support isn't required, and locking support isn't required,
>> but support for the If header is required.
>
> I'm not so sure a server will implement the If header if it doesn't
> implement locking.  I'd agree it's required, but it may not be there.
> And there's certainly no requirement now that servers do authentication
> checks when they do If checks.  That's not required by RFC2518 -- e.g.
> if the If test fails because it's logically impossible, then why bother
> authenticating?

First, I bet that 100% of all non-broken, existing servers do
authentication checks before looking at the request resource and
its properities like locks. It's the sensible thing to do, as a
user might not even have read permission on the resource. So
one probably should prevent him/her from finding out about the lock
status of the resource.

Second, there is no requirement at the moment. But then, we are
talking about new requirements for servers. The orginal proposal
wants to introduce a new HTTP header, if I remember correctly.
If checking authentication first is the sensible thing to do
for security reasons, then 2518 bis should say so.

If you compare the two existing proposal, you'd find that
the invalid IF Header will work against all current servers
which:
1) check IF header (that will be all servers with locking)
2) check authentication before everything else

whereas the new Enforce Header will only work against
future servers which implement the feature.

It would therefore be interesting to hear what client implementors
think about the two proposals.

> This seems like trying to fit a round peg in a square hole.

Engineering answer: that is no problem if the diameter is
equal or less than the side of the square.

//Stefan

>>
>> So I suggest we check whether any server which does the If check
>> before it does an authentication check.  It certainly shouldn't,
>> since the success or failure of the If check tells you something
>> about the resource which you probably shouldn't know if you are
>> not authenticated.
>>
>> I would have no objection to adding a statement to 2518bis that
>> states that a server SHOULD do authentication checks before any
>> If checks.
>>
>> Cheers,
>> Geoff
>
>





From w3c-dist-auth-request@w3.org  Wed Sep 18 04:31:57 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05775
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 04:31:56 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8I8Wqe20433;
	Wed, 18 Sep 2002 04:32:52 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 04:32:52 -0400 (EDT)
Resent-Message-Id: <200209180832.g8I8Wqe20433@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8I8WpI20407
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 04:32:51 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA17788
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 04:32:50 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 10:32:36 +0200
Date: Wed, 18 Sep 2002 10:32:38 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: "'Ilya Kirnos'" <ilya.kirnos@oracle.com>,
        "'Julian Reschke'" <julian.reschke@gmx.de>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
To: "Lisa Dusseault" <lisa@xythos.com>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <00d801c25eb8$97ee85a0$b701a8c0@xythoslap>
Message-Id: <308FC293-CAE1-11D6-9F78-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.482)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6696
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>
Content-Transfer-Encoding: 7bit



Am Mittwoch den, 18. September 2002, um 04:10, schrieb Lisa Dusseault:

> [...]
> Can anybody come up with other clever ways for the client to try to
> authenticate?  E.g. is it possible for a client to send a reasonable
> Digest authentication header with its first request (probably a
> PROPFIND, but whatever method happens to be first), and if the
> information therein (e.g. realm) is bad, the server responds with the
> WWW-Authenticate header with the correct prompting?  That doesn't quite
> solve Ilya's performance problem, but perhaps the HTTP 1.1. Continue
> mechanism would solve that specific issue.

As someone on the list already pointed out, the client cannot
guess a valid Digest Authentication header. It's one main strength
of digest authentication that the client is not able to do this.
Otherwise an attacker might be able to use a replay attack.

I'm not sure however what a server will do upon seeing a nonsense
Authenticate header from the client. Will it always send a challenge
back? (Unfortunately we cannot make this a requirement in WebDAV
since this belongs in another RFC).

//Stefan




From w3c-dist-auth-request@w3.org  Wed Sep 18 04:33:06 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05797
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 04:33:06 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8I8Y0L20528;
	Wed, 18 Sep 2002 04:34:00 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 04:34:00 -0400 (EDT)
Resent-Message-Id: <200209180834.g8I8Y0L20528@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8I8XxI20502
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 04:33:59 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA17932
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 04:33:58 -0400
Received: (qmail 11334 invoked by uid 0); 18 Sep 2002 08:33:48 -0000
Received: from p3ee2476a.dip.t-dialin.net (HELO lisa) (62.226.71.106)
  by mail.gmx.net (mp012-rz3) with SMTP; 18 Sep 2002 08:33:48 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Eric Sedlar" <eric.sedlar@oracle.com>,
        "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Wed, 18 Sep 2002 10:33:36 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCCEPEFFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <014701c25ee2$55c8fb90$9b114498@esedlar>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6697
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>
Content-Transfer-Encoding: 7bit


Eric,

the problem in requiring things is that you may get what you thought you
want, but then discover it was wrong to ask for it.

If you declare a server that doesn't have entity tags non-compliant, you
might get the server implementor to reconsider his/her decision. In some
cases, there may be a very good technical reason not to supply entity tags -
for instance, if your store is a file system, and you don't have any
additional place for metadata. Computing a reliable entity tag just from the
file's properties (timestamp, length...) is impossible, but the implementor
might attempt it anyway. In the end you'll get a server that *does* supply
entity tags, but they only work most of the time, so they aren't reliable.
That's worse than not having them at all.

So, there are valid reasons for RFC2616 to make these things optional (same
for server timestamps). I'm happy with language that explains that entity
tags are an important feature, but it should also make clear that if a
server can't provide reliable entity tags, it shouldn't attempt to.

Julian

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> Sent: Wednesday, September 18, 2002 9:10 AM
> To: Webdav WG
> Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting
>
>
>
> RFC2518bis wouldn't invalidate a class of servers if it includes
> a new token
> in the DAV: header to indicate support for RFC2518bis.  Clients
> would still
> have to deal with no-Etag servers to support RFC2518, but this might
> accellerate implementation of Etags.
>
> --Eric
>
> ----- Original Message -----
> From: "Clemm, Geoff" <gclemm@rational.com>
> To: "Webdav WG" <w3c-dist-auth@w3c.org>
> Sent: Tuesday, September 17, 2002 7:57 PM
> Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
>
>
> >
> > I have no objection to such a warning (in fact, it sounds
> > like a good idea to me).  But I agree with Julian
> > that RFC2518bis should not invalidate a whole class of
> > valid 2518 servers, even for a worthy cause such as ETag support.
> >
> > Cheers,
> > Geoff
> >
> > -----Original Message-----
> > From: Eric Sedlar [mailto:eric.sedlar@oracle.com]
> > Sent: Tuesday, September 17, 2002 8:47 PM
> > To: Clemm, Geoff; Webdav WG
> > Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting
> >
> >
> > As long as you don't mind a client saying something to the effect of:
> >
> > "This server does not support the minimal level of functionality that
> > <product> requires of a WebDAV server (ETags).  We strongly
> discourage you
> > from using this server, as you may lose work."
> >
> > when it points at your server, then go ahead and don't support ETags.
> >
> > --Eric
> >
> > ----- Original Message -----
> > From: "Clemm, Geoff" <gclemm@rational.com>
> > To: "Webdav WG" <w3c-dist-auth@w3c.org>
> > Sent: Tuesday, September 17, 2002 6:50 AM
> > Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
> >
> >
> > >
> > > I agree.
> > >
> > > -----Original Message-----
> > > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > > Sent: Tuesday, September 17, 2002 4:58 AM
> > > To: Lisa Dusseault; Webdav WG
> > > Subject: ETags, was: Issues from Interop/Interim WG Meeting
> > >
> > >
> > >
> > > > From: w3c-dist-auth-request@w3.org
> > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> > > > Sent: Sunday, September 15, 2002 8:14 PM
> > > > To: Webdav WG
> > > > Subject: Issues from Interop/Interim WG Meeting
> > > >
> > > > ...
> > > > -  Be clear in spec that servers MUST do ETags. Explain how
> necessary
> > > > this is to solve the lost update problem.
> > > > ..
> > >
> > > ETags are a good thing, correct. However, HTTP (RFC2616)
> doesn't require
> > > them, RFC2518 doesn't require them, and they '*aren't* required for
> > > interoperability. So there's no way to require them in
> RFC2518bis -- it
> > > would break all servers that don't have them.
> > >
> > > Julian
> > >
> > > --
> > > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> > >
> > >
> >
> >
>



From w3c-dist-auth-request@w3.org  Wed Sep 18 04:35:06 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05858
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 04:35:06 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8I8a7B20771;
	Wed, 18 Sep 2002 04:36:07 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 04:36:07 -0400 (EDT)
Resent-Message-Id: <200209180836.g8I8a7B20771@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8I8a6I20741
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 04:36:06 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA18372
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 04:36:05 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 10:34:59 +0200
Date: Wed, 18 Sep 2002 10:35:01 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: Julian Reschke <julian.reschke@gmx.de>, Webdav WG <w3c-dist-auth@w3c.org>
To: Ilya Kirnos <ilya.kirnos@oracle.com>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <3D87D930.66156D05@oracle.com>
Message-Id: <85D59A30-CAE1-11D6-9F78-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.482)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6698
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>
Content-Transfer-Encoding: 7bit



Am Mittwoch den, 18. September 2002, um 03:38, schrieb Ilya Kirnos:

> [...]
>> From what I hear now, you want to authenticate, but not for a specific
>> method call on a specific resource. What is this supposed to 
>> *mean*? What
>> principals are known may depend on the request URI. Whether (and 
>> as who)
>> you need to authenticate to apply a certain method to a resource 
>> depends on
>> the resource *and* the method.
>>
>> In general, the answer -- you'lll have to try.
>>
>
> okay.  this answer is currently not sufficient, for example in the 
> case of a
> large PUT.  whether it's an interop or a performance problem, i 
> believe it's
> something that needs to be addressed.  if there is something 
> already in the spec
> that solves the problem, i would be happy to use it.

Well, as someone (Roy?) mentioned, the Expect header in RFC 2616 servs
that pupose.

//Stefan




From w3c-dist-auth-request@w3.org  Wed Sep 18 04:36:37 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05882
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 04:36:37 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8I8beL20931;
	Wed, 18 Sep 2002 04:37:40 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 04:37:40 -0400 (EDT)
Resent-Message-Id: <200209180837.g8I8beL20931@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8I8bcI20905
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 04:37:38 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA18888
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 04:37:38 -0400
Received: (qmail 11803 invoked by uid 0); 18 Sep 2002 08:37:06 -0000
Received: from p3ee2476a.dip.t-dialin.net (HELO lisa) (62.226.71.106)
  by mail.gmx.net (mp003-rz3) with SMTP; 18 Sep 2002 08:37:06 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Lisa Dusseault" <lisa@xythos.com>,
        "'Ilya Kirnos'" <ilya.kirnos@oracle.com>
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Wed, 18 Sep 2002 10:37:05 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCAEPFFFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <00d801c25eb8$97ee85a0$b701a8c0@xythoslap>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: RE: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6699
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>
Content-Transfer-Encoding: 7bit


Lisa,

I think this...:

> ...
> There may be other methods which an unauthenticated user can receive a
> success response, but which would work even better if the user were
> authenticated.
> ...

makes it clear that we need some more time to precisely describe what the
actual problem is. It's an interesting problem, and I suppose it needs to be
discussed in relation to the ACL spec. However I don't think there's any
reason to declare it an interop problem just to rush a quick workaround into
RFC2518bis.

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



From w3c-dist-auth-request@w3.org  Wed Sep 18 06:46:19 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07940
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 06:46:18 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IAl8f12609;
	Wed, 18 Sep 2002 06:47:08 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 06:47:08 -0400 (EDT)
Resent-Message-Id: <200209181047.g8IAl8f12609@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IAl6I12583
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 06:47:06 -0400 (EDT)
Received: from foem.leiden.webweaving.org (chuck@fia224-72.dsl.hccnet.nl [62.251.72.224])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA11624
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 06:47:05 -0400
Received: from foem (foem [10.11.0.2])
	by foem.leiden.webweaving.org (8.12.5/8.12.5) with ESMTP id g8IAkqoe042304
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Wed, 18 Sep 2002 12:46:53 +0200 (CEST)
	(envelope-from dirkx@webweaving.org)
Date: Wed, 18 Sep 2002 12:46:52 +0200 (CEST)
From: Dirk-Willem van Gulik <dirkx@webweaving.org>
X-X-Sender: dirkx@foem.leiden.webweaving.org
To: Jim Luther <luther.j@apple.com>
cc: Webdav WG <w3c-dist-auth@w3c.org>
In-Reply-To: <6D0A58D8-CAA4-11D6-A0E5-0003934B6A22@apple.com>
Message-ID: <20020918124206.Q4587-100000@foem.leiden.webweaving.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: Digest authentication
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6700
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>




On Tue, 17 Sep 2002, Jim Luther wrote:

> I should have brought this issue up during the Interop event in Santa
> Cruz, because many of the servers I tested against there did not
> support Digest authentication. Since Digest support is a MUST in
> RFC2518, it would be nice if our client could depend on it and not have
> to bother users with a warning.

Note that Apache 1.3 has most recently (2002-10-10) been patched to
interoperate with Apple's DAV client in MacOS 10.x

The issue was that the "Authorization" line contained a mix of quoted and
non quoted tokens; and apache used to barf on a non quoated uri value
which non alphanum chars. This is now fixed. Apache 2.0 was fine all along.

That should add a nice block of servers which interoperate.

Dw



From w3c-dist-auth-request@w3.org  Wed Sep 18 07:58:14 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09268
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 07:58:14 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IBwjN21789;
	Wed, 18 Sep 2002 07:58:45 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 07:58:45 -0400 (EDT)
Resent-Message-Id: <200209181158.g8IBwjN21789@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IBwiI21761
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 07:58:44 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA24807
	for <w3c-dist-auth@w3.org>; Wed, 18 Sep 2002 07:58:43 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09200;
	Wed, 18 Sep 2002 07:56:39 -0400 (EDT)
Message-Id: <200209181156.HAA09200@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: w3c-dist-auth@w3.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 18 Sep 2002 07:56:39 -0400
Subject: I-D ACTION:draft-ietf-webdav-rfc2518bis-02.txt
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6701
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>


--NextPart

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

	Title		: HTTP Extensions for Distributed Authoring û WebDAV 
                          RFC2518 bis
	Author(s)	: Y. Goland et al.
	Filename	: draft-ietf-webdav-rfc2518bis-02.txt
	Pages		: 87
	Date		: 2002-9-17
	
WebDAV consists of a set of methods, headers, and content-types 
ancillary to HTTP/1.1 for the management of resource properties, 
creation and management of resource collections, namespace 
manipulation, and resource locking (collision avoidance). 
RFC2518 was published in February 1998, and this draft makes only 
minor revisions mostly due to interoperability experience.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

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

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

Content-Type: text/plain
Content-ID:	<2002-9-17143620.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-webdav-rfc2518bis-02.txt

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

Content-Type: text/plain
Content-ID:	<2002-9-17143620.I-D@ietf.org>

--OtherAccess--

--NextPart--




From w3c-dist-auth-request@w3.org  Wed Sep 18 08:28:27 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10240
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 08:28:27 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8ICTPH24927;
	Wed, 18 Sep 2002 08:29:25 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 08:29:25 -0400 (EDT)
Resent-Message-Id: <200209181229.g8ICTPH24927@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8ICTNI24897
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 08:29:23 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA30141
	for <w3c-dist-auth@w3.org>; Wed, 18 Sep 2002 08:29:22 -0400
Received: (qmail 23417 invoked by uid 0); 18 Sep 2002 12:28:51 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp009-rz3) with SMTP; 18 Sep 2002 12:28:51 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: <w3c-dist-auth@w3.org>
Date: Wed, 18 Sep 2002 14:28:45 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCGEPLFFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <200209181156.HAA09200@ietf.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-02.txt
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6702
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>
Content-Transfer-Encoding: 8bit


Sorry,

but I really have a problem with the process here. Why is the I-D submitted
*before* there is consensus on the changes?

Julian

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of
> Internet-Drafts@ietf.org
> Sent: Wednesday, September 18, 2002 1:57 PM
> To: IETF-Announce:
> Cc: w3c-dist-auth@w3.org
> Subject: I-D ACTION:draft-ietf-webdav-rfc2518bis-02.txt
>
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> This draft is a work item of the WWW Distributed Authoring and
> Versioning Working Group of the IETF.
>
> 	Title		: HTTP Extensions for Distributed Authoring
> û WebDAV
>                           RFC2518 bis
> 	Author(s)	: Y. Goland et al.
> 	Filename	: draft-ietf-webdav-rfc2518bis-02.txt
> 	Pages		: 87
> 	Date		: 2002-9-17
>
> WebDAV consists of a set of methods, headers, and content-types
> ancillary to HTTP/1.1 for the management of resource properties,
> creation and management of resource collections, namespace
> manipulation, and resource locking (collision avoidance).
> RFC2518 was published in February 1998, and this draft makes only
> minor revisions mostly due to interoperability experience.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-webdav-rfc2518bis-02.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of
> the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with
> the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-webdav-rfc2518bis-02.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-webdav-rfc2518bis-02.txt".
>
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>



From w3c-dist-auth-request@w3.org  Wed Sep 18 09:32:43 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12320
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 09:32:43 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IDXWw03657;
	Wed, 18 Sep 2002 09:33:32 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 09:33:32 -0400 (EDT)
Resent-Message-Id: <200209181333.g8IDXWw03657@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IDXUI03630
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 09:33:30 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA12146
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 09:33:29 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 15:33:25 +0200
Date: Wed, 18 Sep 2002 15:33:23 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
To: "Clemm, Geoff" <gclemm@rational.com>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10841D60F@SUS-MA1IT01>
Message-Id: <34258176-CB0B-11D6-9F78-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.482)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: Issue: Requiring server to use / terminated URL for returned  	 	collections
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6703
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>
Content-Transfer-Encoding: 7bit



Am Dienstag den, 17. September 2002, um 17:49, schrieb Clemm, Geoff:
> Good question, Julian.
>
> I was going to respond "so that client side relative URL
> processing is correct".  But of course, a better
> way to handle that would be for the GET to just return the
> slash-terminated name (or even better, the resource that it
> is really redirecting the request to, such as "index.html")
> in the Content-Location field, since the client is required
> to use the value in the Content-Location field as the base
> for relative URL processing.

I agree with you that RFC 2616 clearly states this purpose of
Content-Location.

However, neither IE 5.0, nor IE 6.0, nor Mozilla 1.1 gives
my beautiful Content-Location header any justice: it is
completely ignored when resolving relative uri references
inside the HTML page.

So, for all practical purposes, a 302 is required.

//Stefan


> So a 302 redirect is not even required for GET processing
> (i.e. the server can just automatically forward the request
> without an extra roundtrip for the 302 redirect).
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Tuesday, September 17, 2002 10:24 AM
> To: Clemm, Geoff; 'Webdav WG'
> Subject: RE: Issue: Requiring server to use / terminated URL for
> returned collections
>
>
>
> Like Geoff said,
>
> except:
>
>> As indicated above, the 302 redirect is only required for a GET, and
>> WebDAV clients commonly use PROPFIND and not GET to retrieve the state
>> of a collection.
>
> Where does this distinction come from?
>
> I really don't want to get into a situation where 1) HEAD and 2)
> PROPFIND/depth 0 say different things about the same resource.
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>





From w3c-dist-auth-request@w3.org  Wed Sep 18 10:38:51 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15636
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 10:38:51 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IEdPg19938;
	Wed, 18 Sep 2002 10:39:25 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 10:39:25 -0400 (EDT)
Resent-Message-Id: <200209181439.g8IEdPg19938@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IEdNI19908
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 10:39:23 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA30021
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 10:39:22 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 18 Sep 2002 10:29:04 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <TDR3N9TF>; Wed, 18 Sep 2002 10:38:52 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10841D847@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Wed, 18 Sep 2002 10:38:51 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: Issue: Requiring server to use / terminated URL for returned  	 	collections
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6704
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>


   From: Lisa Dusseault [mailto:lisa@xythos.com]

   > ... I need to see some compelling reasons why a
   > collection requires protocol-imposed naming constraints.

   Another reason was given by Roy in an older mail:

   "There are no known examples of HTTP servers for which the URI
   without a slash is the SAME RESOURCE as the URI with a slash.

That is because pre-WebDAV HTTP servers just redirected a request on
what WebDAV identifies as a collection (with or without the last
slash) to some server-defined member of that collection
(e.g. index.html).

   Automatically providing two different URI for the same resource,
   particularly when they cross hierarchical syntax, instantly doubles
   the application name space (bad for IR and QA) and creates holes in
   access control."

If that is in fact a problem, then the server won't do it.  On the
other hand, if the server's implementation does not support trailing
separator characters, and the user expects this equivalence because
all other protocols that access this server do so, it may be
significantly more complex (for both the implementor and a user of the
repository) to try to fake trailing separator characters as indicating
a separate resource.  That is why the mapping of URIs to types of
resources needs to be under the server's control, not predefined by
the protocol.

   If the server consistently uses the same URL for each resource,
   then it's easier for clients and intermediaries to handle (cache,
   compare, concatenate paths, etc) those resources.

With the presence of multiple bindings to the same resource
(something that is explicitly allowed by the rfc2616, and
explicitly supported by the BIND protocol extension), the
client cannot assume that there is only one URI for a given
resource.  Any client that assumes otherwise has a serious bug
that should be fixed.

   > Since when is a collection path without a trailing slash a "bad
   > Request-URI"?  RFC-2518 explicitly states in Section 5.2 that "a
   > resource may accept a URI without a trailing '/' to point to a
   > collection."  If you are proposing to change this semantics, then
   > I object even more vigorously (but I'll save those objections
   > until I verify that you are proposing to make this change).

   I don't think it matters too much which one you pick, with trailing
   slash or without (with trailing slash is slightly more convenient
   because it's a marker for collections). However, there was strong
   opinion that the spec should pick one. Allowing such flexibility,
   as usual, makes life harder for clients.

The only client complexity that we have identified is the need for the
client to add a '/' before adding a new segment, if there is not yet a
slash there (usually in one line of code).  Given that file system
clients have dealt with this for years with no issues, I see no reason
why this is any harder for HTTP/WebDAV clients.  If the spec is
ambiguous, or the algorithms required are complex, then certainly one
can fix the protocol, but if a client just has a bug with a simple
fix, you fix the client -- you don't change the protocol to workaround
that bug for a few special cases.

   > Note also that there is no requirement in 2518 for a server to
   > redirect a non-GET request (it just needs to return the '/'
   > terminated name in a Location header).  Note that I have no
   > problem with requiring that a Location header be returned, since
   > if the server is applying a method to a resource, it will have
   > had to find out what type of resource it is anyway.

   Yes. And if the server returns the slash-terminated name in a
   Location header, it should use the SAME name everywhere else in the
   response.

That is an opinion with which I disagree.

   > The only real interoperability problem I saw identified above was
   > the "clients don't redirect properly", and the solution there is
   > to fix the broken clients, not change URL conventions so that the
   > broken clients work better in this one case of redirection.  (I
   > consider the addition of a slash when extending a URL to be a
   > trivial coding issue, not an interoperability problem).

   Also an interoperability problem found was "clients don't append new
   child names properly onto collection names".

That was the "trivial coding issue" I was referring to.  A client that
appends a new segment to a URL without ensuring there is a
preceding '/' just has a bug, and a bug that is trivial to fix.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Wed Sep 18 11:34:33 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17983
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 11:34:33 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IFZMe28131;
	Wed, 18 Sep 2002 11:35:22 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 11:35:22 -0400 (EDT)
Resent-Message-Id: <200209181535.g8IFZMe28131@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IFZJI28071
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 11:35:19 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA12921
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 11:35:17 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id IAA23576 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Wed, 18 Sep 2002 08:35:16 -0700
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by sunbelt.seagull.net (8.9.3) with ESMTP id IAA23545 sender obsfucated@us.ibm.com; Wed, 18 Sep 2002 08:35:13 -0700
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8IFYej2139236; Wed, 18 Sep 2002 11:34:40 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8IFYYpK063856; Wed, 18 Sep 2002 11:34:35 -0400
To: "Lisa Dusseault" <lisa@xythos.com>
Cc: "'Ilya Kirnos'" <ilya.kirnos@oracle.com>,
        "'Julian Reschke'" <julian.reschke@gmx.de>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF2694B2AD.F04AA33C-ON85256C38.00531AF3@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Wed, 18 Sep 2002 11:33:10 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_09122002|September 12, 2002) at 09/18/2002 11:34:35
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: RE: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6705
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>





On Tuesday, 09/17/2002 at 11:12 MST, "Lisa Dusseault" wrote:
> > -----Original Message-----
> > > There may be other methods which an unauthenticated user can
> > > receive a
> > > success response, but which would work even better if the user were
> > > authenticated.
> >
> > Shouldn't the server just ask for authentication for those methods?
> >
>
> Not necessarily; if it's possible for the request to return a success
> response if the user is unauthenticated, then the server must do so
> right away or it may never be able to give a success response.
>
> If a 401 error is returned the first time a client asks to do one of
> these methods (like a PROPFIND to a partially-readable collection), how
> does the server know the client will ever make the same request?  Maybe
> the user doesn't know a username/password and so hits "cancel", and the
> client doesn't retry.  And if the client software retries, again without
> a username/password, by your logic the server would just respond 401
> again.

So let me turn this around.  Instead of a client asking to be
authenticated, what if the approach becomes that the client asks
not to be authenticated.   Three options...

1) The client just has a header saying that he choses to be unauthenticated
on a given request.   If the server doesn't see this, and the method could
change it's behavior if authenticated, the server asks for authentication.

or

2) The server simply tries to authenticate and the client responds with
something that indicates that he choses not to authenticate or choses
to authenticate anonymously.  The way to do that can be standardized
or the server can pass info to indicate how to do that... which can be
standardized.

or

3) The user is simply told by other means what userid and password
to use to authenticate themselves as an underprivledged (probably
anonymous) user.   And if they subsequently want to change who they
are authenticated as, the user does that in their client GUI.
Subsequent requests are submitted unauthenticated and when the
server finally wants authentication info for a request, it will ask.

I assume this takes care of this one test case.  Will it take care of the
other test cases?

Please forgive me if the above options seem silly, but I don't really
know what the other test cases are.   I could come up with one, but
I don't want to create a red herring.   Could we clearly state what the
scenarios are that we'd like to address?    Lisa has done a good job
outlining this one, but I haven't seen any other scenerio clearly
outlined.

J.



From w3c-dist-auth-request@w3.org  Wed Sep 18 12:30:14 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20094
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 12:30:14 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IGUV303164;
	Wed, 18 Sep 2002 12:30:31 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 12:30:31 -0400 (EDT)
Resent-Message-Id: <200209181630.g8IGUV303164@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IGUTI03138
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 12:30:29 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA25201
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 12:30:29 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 18 Sep 2002 12:29:53 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Wed, 18 Sep 2002 12:29:53 -0400
Received: from xythoslap ([198.144.203.248]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Wed, 18 Sep 2002 12:29:29 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Stefan Eissing'" <stefan.eissing@greenbytes.de>
Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Wed, 18 Sep 2002 09:29:28 -0700
Message-ID: <010401c25f30$903e0dd0$b701a8c0@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <E95E4968-CADF-11D6-9F78-00039384827E@greenbytes.de>
X-OriginalArrivalTime: 18 Sep 2002 16:29:29.0818 (UTC) FILETIME=[8FF6CBA0:01C25F30]
Subject: RE: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6706
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>
Content-Transfer-Encoding: 7bit


> First, I bet that 100% of all non-broken, existing servers do
> authentication checks before looking at the request resource and
> its properities like locks. It's the sensible thing to do, as a
> user might not even have read permission on the resource. So
> one probably should prevent him/her from finding out about the lock
> status of the resource.

No, and why should they?  There's nothing in RFC2518 that requires
servers to support locks only for authenticated users.  If a resource is
publicly writable, there may be nothing to prevent unauthenticated users
from taking out locks and using lock tokens.  Recall that the If header
can also be used with ETags, which are not at all associated with how a
user is authenticated.

Also, recall that in order to "do authentication checks", the server
must respond to the client with a 401 with the WWW-Authenticate header,
then the client must make another request.  

Of course if the client sent its authentication information on the first
request, the server is likely to check it.  However, the client can't
even send its authentication information if it doesn't yet know whether
the server supports digest or basic, or what realm, nonce, etc.  That's
why Ilya wants to be able to ask the server to reply with a
WWW-Authenticate header.  

Lisa



From w3c-dist-auth-request@w3.org  Wed Sep 18 12:33:10 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20179
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 12:33:10 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IGYC703641;
	Wed, 18 Sep 2002 12:34:12 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 12:34:12 -0400 (EDT)
Resent-Message-Id: <200209181634.g8IGYC703641@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IGY0I03614
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 12:34:00 -0400 (EDT)
Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA26032
	for <w3c-dist-auth@w3.org>; Wed, 18 Sep 2002 12:34:00 -0400
Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 18 Sep 2002 12:33:26 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.182]) by atl1simr002.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Wed, 18 Sep 2002 12:33:26 -0400
Received: from xythoslap ([198.144.203.248]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Wed, 18 Sep 2002 12:33:25 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>, <w3c-dist-auth@w3.org>
Date: Wed, 18 Sep 2002 09:33:21 -0700
Message-ID: <010501c25f31$1cc0f880$b701a8c0@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <JIEGINCHMLABHJBIGKBCGEPLFFAA.julian.reschke@gmx.de>
X-OriginalArrivalTime: 18 Sep 2002 16:33:25.0572 (UTC) FILETIME=[1C7C0040:01C25F31]
Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-02.txt
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6707
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>
Content-Transfer-Encoding: 7bit


A draft is not a consensus document.  The draft contains specific text,
and it is often necessary to see the specific text to find out if there
is consensus.

WG consensus is required to bring the draft to the IESG, not to publish
a draft.

lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]
> On Behalf Of Julian Reschke
> Sent: Wednesday, September 18, 2002 5:29 AM
> To: w3c-dist-auth@w3.org
> Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-02.txt
> 
> 
> Sorry,
> 
> but I really have a problem with the process here. Why is the I-D
> submitted
> *before* there is consensus on the changes?
> 



From w3c-dist-auth-request@w3.org  Wed Sep 18 12:40:39 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20430
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 12:40:39 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IGfTI04545;
	Wed, 18 Sep 2002 12:41:29 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 12:41:29 -0400 (EDT)
Resent-Message-Id: <200209181641.g8IGfTI04545@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IGfRI04515
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 12:41:27 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA27566
	for <w3c-dist-auth@w3.org>; Wed, 18 Sep 2002 12:41:26 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20382;
	Wed, 18 Sep 2002 12:39:39 -0400 (EDT)
Message-Id: <200209181639.MAA20382@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: w3c-dist-auth@w3.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 18 Sep 2002 12:39:38 -0400
Subject: I-D ACTION:draft-ietf-webdav-rfc2518bis-02.txt
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6708
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>


--NextPart

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

	Title		: HTTP Extensions for Distributed Authoring - WebDAV 
                          RFC2518 bis
	Author(s)	: Y. Goland et al.
	Filename	: draft-ietf-webdav-rfc2518bis-02.txt
	Pages		: 87
	Date		: 2002-9-17
	
WebDAV consists of a set of methods, headers, and content-types 
ancillary to HTTP/1.1 for the management of resource properties, 
creation and management of resource collections, namespace 
manipulation, and resource locking (collision avoidance). 
RFC2518 was published in February 1998, and this draft makes only 
minor revisions mostly due to interoperability experience.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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


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

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

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

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

Content-Type: text/plain
Content-ID:	<2002-9-18125223.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-webdav-rfc2518bis-02.txt

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

Content-Type: text/plain
Content-ID:	<2002-9-18125223.I-D@ietf.org>

--OtherAccess--

--NextPart--




From w3c-dist-auth-request@w3.org  Wed Sep 18 12:43:32 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20522
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 12:43:32 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IGiUt04842;
	Wed, 18 Sep 2002 12:44:30 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 12:44:30 -0400 (EDT)
Resent-Message-Id: <200209181644.g8IGiUt04842@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IGiTI04816
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 12:44:29 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA28393
	for <w3c-dist-auth@w3.org>; Wed, 18 Sep 2002 12:44:28 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 18 Sep 2002 12:43:53 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Wed, 18 Sep 2002 12:43:52 -0400
Received: from xythoslap ([198.144.203.248]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Wed, 18 Sep 2002 12:43:52 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>, <w3c-dist-auth@w3.org>
Date: Wed, 18 Sep 2002 09:43:51 -0700
Message-ID: <010701c25f32$92615110$b701a8c0@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <JIEGINCHMLABHJBIGKBCGEPLFFAA.julian.reschke@gmx.de>
X-OriginalArrivalTime: 18 Sep 2002 16:43:52.0416 (UTC) FILETIME=[921CCE00:01C25F32]
Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-02.txt
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6709
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>
Content-Transfer-Encoding: 7bit


> but I really have a problem with the process here. Why is the I-D
> submitted
> *before* there is consensus on the changes?
> 
To be clear, I thought that for all the issues in the draft, either:
 - they weren't controversial,
 - OR they were controversial but consensus (not unanimity) was close.

And in any case, it's the exact wording that needs to be seen to
determine real consensus.  When I-D's are published, it's correct to
publish them to the I-D repository, rather than just circulate them on
the list.  If we were only to circulate a RFC2518-bis text document on
the DAV list, then non-list-members wouldn't have the same awareness and
accessibility to the document that they have if documents are published
correctly.

Also, I thought this goes without saying, but nobody is implying that
this I-D is anywhere ready for WG last call.  There are major unresolved
issues.

We always encourage discussion and if desired straw polls on the list. 

lisa



From w3c-dist-auth-request@w3.org  Wed Sep 18 12:51:12 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20932
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 12:51:12 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IGoWR05820;
	Wed, 18 Sep 2002 12:50:32 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 12:50:32 -0400 (EDT)
Resent-Message-Id: <200209181650.g8IGoWR05820@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IGoVI05782
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 12:50:31 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA30299
	for <w3c-dist-auth@w3.org>; Wed, 18 Sep 2002 12:50:30 -0400
Received: (qmail 26384 invoked by uid 0); 18 Sep 2002 16:49:59 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp013-rz3) with SMTP; 18 Sep 2002 16:49:59 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Lisa Dusseault" <lisa@xythos.com>, <w3c-dist-auth@w3.org>
Date: Wed, 18 Sep 2002 18:49:59 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCAEAGFGAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <010701c25f32$92615110$b701a8c0@xythoslap>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-02.txt
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6710
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>
Content-Transfer-Encoding: 7bit


Lisa,

it's just that I think a *lot* of bad mood could be avoided if there was a
time window between edits on the I-D and the actual submission. As you have
seen, many of the changes you made *are* controversial. So maybe the
approach the WG is/was using for the ACL draft makes more sense (submit when
stable instead of submit when new)?

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Wednesday, September 18, 2002 6:44 PM
> To: 'Julian Reschke'; w3c-dist-auth@w3.org
> Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-02.txt
>
>
>
> > but I really have a problem with the process here. Why is the I-D
> > submitted
> > *before* there is consensus on the changes?
> >
> To be clear, I thought that for all the issues in the draft, either:
>  - they weren't controversial,
>  - OR they were controversial but consensus (not unanimity) was close.
>
> And in any case, it's the exact wording that needs to be seen to
> determine real consensus.  When I-D's are published, it's correct to
> publish them to the I-D repository, rather than just circulate them on
> the list.  If we were only to circulate a RFC2518-bis text document on
> the DAV list, then non-list-members wouldn't have the same awareness and
> accessibility to the document that they have if documents are published
> correctly.
>
> Also, I thought this goes without saying, but nobody is implying that
> this I-D is anywhere ready for WG last call.  There are major unresolved
> issues.
>
> We always encourage discussion and if desired straw polls on the list.
>
> lisa
>



From w3c-dist-auth-request@w3.org  Wed Sep 18 12:51:59 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20966
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 12:51:59 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IGpcb05938;
	Wed, 18 Sep 2002 12:51:38 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 12:51:38 -0400 (EDT)
Resent-Message-Id: <200209181651.g8IGpcb05938@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IGpbI05912
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 12:51:37 -0400 (EDT)
Received: from matrixmail.matrixone.net (mail.matrix-one.com [4.17.165.4])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA30697
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 12:51:37 -0400
Received: from msx2am.matrixone.net 
	by matrixmail.matrixone.net (8.11.6+Sun/8.10.1) with ESMTP id g8IGouv12970;
	Wed, 18 Sep 2002 12:50:57 -0400 (EDT)
Received: by msx2am.matrixone.net with Internet Mail Service (5.5.2653.19)
	id <TD4VXAW2>; Wed, 18 Sep 2002 12:50:56 -0400
Message-ID: <9150DCE0CCB4D411A7DB00508BB0DBF202E5C8D2@msx1am.matrixone.net>
From: "Dyer, Kevin" <kevin.dyer@matrixone.com>
To: "'Lisa Dusseault '" <lisa@xythos.com>,
        "''Stefan Eissing' '"
	 <stefan.eissing@greenbytes.de>
Cc: "'Webdav WG '" <w3c-dist-auth@w3c.org>
Date: Wed, 18 Sep 2002 12:50:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C25F33.8D98B000"
Subject: RE: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6711
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>


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

------_=_NextPart_001_01C25F33.8D98B000
Content-Type: text/plain

I believe that Stefan was implying for a server to validate through the ACLs
that a resource is protected and that a user has not been authenticated. If
both are true then a server would not give out such information because to
some people even the names of the files are competition sensitive.

If the ACLs indicate that a resource is unprotected then it would not matter
if the client has provided authentication credentials or not.

That said, there is nothing in RFC2518 that states a client and server can
not communicate through an out of band communication path, say LDAP or
application registry, to initialize the client. This would allow a client to
be able to ask up front for authentication credentials. 

-----Original Message-----
From: Lisa Dusseault
To: 'Stefan Eissing'
Cc: Webdav WG
Sent: 9/18/02 12:29 PM
Subject: RE: Interop issue: how can clients force authentication?


> First, I bet that 100% of all non-broken, existing servers do
> authentication checks before looking at the request resource and
> its properities like locks. It's the sensible thing to do, as a
> user might not even have read permission on the resource. So
> one probably should prevent him/her from finding out about the lock
> status of the resource.

No, and why should they?  There's nothing in RFC2518 that requires
servers to support locks only for authenticated users.  If a resource is
publicly writable, there may be nothing to prevent unauthenticated users
from taking out locks and using lock tokens.  Recall that the If header
can also be used with ETags, which are not at all associated with how a
user is authenticated.

Also, recall that in order to "do authentication checks", the server
must respond to the client with a 401 with the WWW-Authenticate header,
then the client must make another request.  

Of course if the client sent its authentication information on the first
request, the server is likely to check it.  However, the client can't
even send its authentication information if it doesn't yet know whether
the server supports digest or basic, or what realm, nonce, etc.  That's
why Ilya wants to be able to ask the server to reply with a
WWW-Authenticate header.  

Lisa

------_=_NextPart_001_01C25F33.8D98B000
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Interop issue: how can clients force authentication?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I believe that Stefan was implying for a server to =
validate through the ACLs that a resource is protected and that a user =
has not been authenticated. If both are true then a server would not =
give out such information because to some people even the names of the =
files are competition sensitive.</FONT></P>

<P><FONT SIZE=3D2>If the ACLs indicate that a resource is unprotected =
then it would not matter if the client has provided authentication =
credentials or not.</FONT></P>

<P><FONT SIZE=3D2>That said, there is nothing in RFC2518 that states a =
client and server can not communicate through an out of band =
communication path, say LDAP or application registry, to initialize the =
client. This would allow a client to be able to ask up front for =
authentication credentials. </FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Lisa Dusseault</FONT>
<BR><FONT SIZE=3D2>To: 'Stefan Eissing'</FONT>
<BR><FONT SIZE=3D2>Cc: Webdav WG</FONT>
<BR><FONT SIZE=3D2>Sent: 9/18/02 12:29 PM</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Interop issue: how can clients force =
authentication?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; First, I bet that 100% of all non-broken, =
existing servers do</FONT>
<BR><FONT SIZE=3D2>&gt; authentication checks before looking at the =
request resource and</FONT>
<BR><FONT SIZE=3D2>&gt; its properities like locks. It's the sensible =
thing to do, as a</FONT>
<BR><FONT SIZE=3D2>&gt; user might not even have read permission on the =
resource. So</FONT>
<BR><FONT SIZE=3D2>&gt; one probably should prevent him/her from =
finding out about the lock</FONT>
<BR><FONT SIZE=3D2>&gt; status of the resource.</FONT>
</P>

<P><FONT SIZE=3D2>No, and why should they?&nbsp; There's nothing in =
RFC2518 that requires</FONT>
<BR><FONT SIZE=3D2>servers to support locks only for authenticated =
users.&nbsp; If a resource is</FONT>
<BR><FONT SIZE=3D2>publicly writable, there may be nothing to prevent =
unauthenticated users</FONT>
<BR><FONT SIZE=3D2>from taking out locks and using lock tokens.&nbsp; =
Recall that the If header</FONT>
<BR><FONT SIZE=3D2>can also be used with ETags, which are not at all =
associated with how a</FONT>
<BR><FONT SIZE=3D2>user is authenticated.</FONT>
</P>

<P><FONT SIZE=3D2>Also, recall that in order to &quot;do authentication =
checks&quot;, the server</FONT>
<BR><FONT SIZE=3D2>must respond to the client with a 401 with the =
WWW-Authenticate header,</FONT>
<BR><FONT SIZE=3D2>then the client must make another request.&nbsp; =
</FONT>
</P>

<P><FONT SIZE=3D2>Of course if the client sent its authentication =
information on the first</FONT>
<BR><FONT SIZE=3D2>request, the server is likely to check it.&nbsp; =
However, the client can't</FONT>
<BR><FONT SIZE=3D2>even send its authentication information if it =
doesn't yet know whether</FONT>
<BR><FONT SIZE=3D2>the server supports digest or basic, or what realm, =
nonce, etc.&nbsp; That's</FONT>
<BR><FONT SIZE=3D2>why Ilya wants to be able to ask the server to reply =
with a</FONT>
<BR><FONT SIZE=3D2>WWW-Authenticate header.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Lisa</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C25F33.8D98B000--



From w3c-dist-auth-request@w3.org  Wed Sep 18 12:57:33 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21177
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 12:57:32 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IGwRB06926;
	Wed, 18 Sep 2002 12:58:27 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 12:58:27 -0400 (EDT)
Resent-Message-Id: <200209181658.g8IGwRB06926@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IGwRI06896
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 12:58:27 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA32314
	for <w3c-dist-auth@w3.org>; Wed, 18 Sep 2002 12:58:26 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 18 Sep 2002 12:57:45 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Wed, 18 Sep 2002 12:57:40 -0400
Received: from xythoslap ([198.144.203.248]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Wed, 18 Sep 2002 12:57:39 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>, <w3c-dist-auth@w3.org>
Date: Wed, 18 Sep 2002 09:57:39 -0700
Message-ID: <011101c25f34$7f95b150$b701a8c0@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <JIEGINCHMLABHJBIGKBCAEAGFGAA.julian.reschke@gmx.de>
X-OriginalArrivalTime: 18 Sep 2002 16:57:39.0890 (UTC) FILETIME=[7F535120:01C25F34]
Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-02.txt
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6712
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>
Content-Transfer-Encoding: 7bit


I replied in private mail, but again, here's the relevant standards on
this issue:

http://www.ietf.org/ietf/1id-guidelines.txt:
"The Internet-Drafts directories are available to provide authors with
the ability to distribute and solicit comments on documents they may
eventually submit to the IESG for publication as an RFC."

http://www.ietf.org/rfc/rfc2026.txt;
" During the development of a specification, draft versions of the
   document are made available for informal review and comment by
   placing them in the IETF's "Internet-Drafts" directory, which is
   replicated on a number of Internet hosts.  This makes an evolving
   working document readily available to a wide audience, facilitating
   the process of review and revision."

I won't take a stand on whether it was wrong of the ACL editors to
circulate drafts in such a manner that you had to be a mailing list
member in order to know there was new text to look at.  It's a grey
area, because when multiple authors are working on a new document, it's
important to be able to share it.  

I firmly believe that it is correct for a draft to go to the IETF
Internet-Draft repository when it is circulated to the entire WG mailing
list.  I would be happy to have Patrick, Ned or Harald correct me on
this.

Lisa

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Wednesday, September 18, 2002 9:50 AM
> To: Lisa Dusseault; w3c-dist-auth@w3.org
> Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-02.txt
> 
> Lisa,
> 
> it's just that I think a *lot* of bad mood could be avoided if there
was a
> time window between edits on the I-D and the actual submission. As you
> have
> seen, many of the changes you made *are* controversial. So maybe the
> approach the WG is/was using for the ACL draft makes more sense
(submit
> when
> stable instead of submit when new)?
> 
> Julian
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> > Sent: Wednesday, September 18, 2002 6:44 PM
> > To: 'Julian Reschke'; w3c-dist-auth@w3.org
> > Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-02.txt
> >
> >
> >
> > > but I really have a problem with the process here. Why is the I-D
> > > submitted
> > > *before* there is consensus on the changes?
> > >
> > To be clear, I thought that for all the issues in the draft, either:
> >  - they weren't controversial,
> >  - OR they were controversial but consensus (not unanimity) was
close.
> >
> > And in any case, it's the exact wording that needs to be seen to
> > determine real consensus.  When I-D's are published, it's correct to
> > publish them to the I-D repository, rather than just circulate them
on
> > the list.  If we were only to circulate a RFC2518-bis text document
on
> > the DAV list, then non-list-members wouldn't have the same awareness
and
> > accessibility to the document that they have if documents are
published
> > correctly.
> >
> > Also, I thought this goes without saying, but nobody is implying
that
> > this I-D is anywhere ready for WG last call.  There are major
unresolved
> > issues.
> >
> > We always encourage discussion and if desired straw polls on the
list.
> >
> > lisa
> >



From w3c-dist-auth-request@w3.org  Wed Sep 18 13:28:21 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22590
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 13:28:21 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IHRX714012;
	Wed, 18 Sep 2002 13:27:33 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 13:27:33 -0400 (EDT)
Resent-Message-Id: <200209181727.g8IHRX714012@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IHRRI13985
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 13:27:27 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA08429
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 13:27:26 -0400
Received: (qmail 31025 invoked by uid 0); 18 Sep 2002 17:27:22 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp015-rz3) with SMTP; 18 Sep 2002 17:27:22 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: <dennis.hamilton@acm.org>, "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Wed, 18 Sep 2002 19:27:22 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCIEAIFGAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <NGBBIKAHMDNFPKNEPALEMEDPINAA.dennis.hamilton@acm.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: property registry, was: Notes for Sept 9 WG meeting (by Dennis Hamilton) - HTML Available
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6713
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>
Content-Transfer-Encoding: 7bit


Hi,

I see that there's a lot of activity around property registration. However,
I'm not convinced that we really need that. Let me explain why.

What's the purpose of a property registration? I can think of

1) Avoiding name collisions and

2) Providing additional information about existing properties.

Re 1): this problem doesn't need a new solution. Properties are identified
by a qualified XML name (so the combination of namespace name and local
name). People defining new properties should use a namespace they control,
and if they do that properly, there's no reason to expect name collisions.

Re 2): as for documentation purposes, this is already partly solved by the
XML namespace mechanism. Simply choose one where it's easy to supply
authorative information, such as a HTTP URL or a name of an RFC
("urn:ietf:rfc:nnnn"). As for automatic discovery of machine-readable
property definitions, this definitively needs a lot of additional work.

PS re 2): we currently use the DAV: namespace to identify properties, ACL
privileges, error conditions, REPORT names and DASL search grammars (more?).
However, there's no proper definition of the DAV: URI scheme (stating
purpose, structure and possibly names that are in use). I think what we
really should do is issue a separate document that collects the name
definitions from the various WebDAV specs.


Julian



> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dennis E. Hamilton
> Sent: Sunday, September 15, 2002 10:43 PM
> To: Webdav WG
> Subject: RE: Notes for Sept 9 WG meeting (by Dennis Hamilton) - HTML
> Available
>
>
>
> The HTML version of these notes is at
>
> 	http://DMware.info/WebDAV/2002-09-09-WebDAV.htm
>
> It is identical except the shortcuts work and I added Ilya's full name in
> the action items.


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



From w3c-dist-auth-request@w3.org  Wed Sep 18 13:28:21 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22594
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 13:28:21 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IHSYg14277;
	Wed, 18 Sep 2002 13:28:34 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 13:28:34 -0400 (EDT)
Resent-Message-Id: <200209181728.g8IHSYg14277@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IHSUI14247
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 13:28:30 -0400 (EDT)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA08588
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 13:28:30 -0400
Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225])
	by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g8IHSTh25668
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 10:28:29 -0700 (PDT)
Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5d68f5f9d8118164e150c@mailgate2.apple.com>;
 Wed, 18 Sep 2002 10:28:29 -0700
Received: from apple.com (luthji.apple.com [17.202.43.76])
	by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g8IHSSV24315;
	Wed, 18 Sep 2002 10:28:28 -0700 (PDT)
Date: Wed, 18 Sep 2002 10:28:17 -0700
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: Webdav WG <w3c-dist-auth@w3c.org>
To: Dirk-Willem van Gulik <dirkx@webweaving.org>
From: Jim Luther <luther.j@apple.com>
In-Reply-To: <20020918124206.Q4587-100000@foem.leiden.webweaving.org>
Message-Id: <04E6BDDD-CB2C-11D6-A0E5-0003934B6A22@apple.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
Subject: Re: Digest authentication
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6714
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>
Content-Transfer-Encoding: 7bit


On Wednesday, September 18, 2002, at 03:46 AM, Dirk-Willem van Gulik 
wrote:

>
> On Tue, 17 Sep 2002, Jim Luther wrote:
>
>> I should have brought this issue up during the Interop event in Santa
>> Cruz, because many of the servers I tested against there did not
>> support Digest authentication. Since Digest support is a MUST in
>> RFC2518, it would be nice if our client could depend on it and not 
>> have
>> to bother users with a warning.
>
> Note that Apache 1.3 has most recently (2002-10-10) been patched to
> interoperate with Apple's DAV client in MacOS 10.x
>
> The issue was that the "Authorization" line contained a mix of quoted 
> and
> non quoted tokens; and apache used to barf on a non quoated uri value
> which non alphanum chars. This is now fixed. Apache 2.0 was fine all 
> along.

All of the tokens in our Authorization header are quoted in the Mac OS 
X 10.1.3 and later WebDAV file system clients. That bug was only in the 
10.1.1 client.

Since all of the Mac OS X 10.1.x updates were free to 10.1 customers, 
most users that haven't moved to 10.2 should be running 10.1.5.

- Jim



From w3c-dist-auth-request@w3.org  Wed Sep 18 13:31:06 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22789
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 13:31:06 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IHVfH14889;
	Wed, 18 Sep 2002 13:31:41 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 13:31:41 -0400 (EDT)
Resent-Message-Id: <200209181731.g8IHVfH14889@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IHVZI14860
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 13:31:35 -0400 (EDT)
Received: from foem.leiden.webweaving.org (chuck@fia224-72.dsl.hccnet.nl [62.251.72.224])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA09175
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 13:31:34 -0400
Received: from foem (foem [10.11.0.2])
	by foem.leiden.webweaving.org (8.12.5/8.12.5) with ESMTP id g8IHVPoe056500
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Wed, 18 Sep 2002 19:31:25 +0200 (CEST)
	(envelope-from dirkx@webweaving.org)
Date: Wed, 18 Sep 2002 19:31:25 +0200 (CEST)
From: Dirk-Willem van Gulik <dirkx@webweaving.org>
X-X-Sender: dirkx@foem.leiden.webweaving.org
To: Jim Luther <luther.j@apple.com>
cc: Webdav WG <w3c-dist-auth@w3c.org>
In-Reply-To: <04E6BDDD-CB2C-11D6-A0E5-0003934B6A22@apple.com>
Message-ID: <20020918193040.U4587-100000@foem.leiden.webweaving.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: Digest authentication
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6715
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>




On Wed, 18 Sep 2002, Jim Luther wrote:

> All of the tokens in our Authorization header are quoted in the Mac OS
> X 10.1.3 and later WebDAV file system clients.

The UA string reported with this issue was:

	 "WebDAVFS/1.2 (01208000) Darwin/6.0 (Power Macintosh)"

> That bug was only in the 10.1.1 client.

Not sure if it is a 'bug' -> the RFC seems to allow for it.

> Since all of the Mac OS X 10.1.x updates were free to 10.1 customers,
> most users that haven't moved to 10.2 should be running 10.1.5.

Good to hear.

Dw



From w3c-dist-auth-request@w3.org  Wed Sep 18 14:07:40 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24103
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 14:07:40 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8II8Qw20462;
	Wed, 18 Sep 2002 14:08:26 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 14:08:26 -0400 (EDT)
Resent-Message-Id: <200209181808.g8II8Qw20462@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8II8MI20436
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 14:08:22 -0400 (EDT)
Received: from inet-mail2.oracle.com (inet-mail2.oracle.com [148.87.2.202])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA19165
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 14:08:22 -0400
Received: from inet-mail2.oracle.com (localhost [127.0.0.1])
	by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8II7pZ04309
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 11:07:51 -0700 (PDT)
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13])
	by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8II7oZ04293
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 11:07:50 -0700 (PDT)
Received: from rgmum1.us.oracle.com (rgmum1.us.oracle.com [138.1.191.22])
	by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8II7nO15635
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 12:07:49 -0600 (MDT)
Received: from 152.68.17.155 by rgmum1.us.oracle.com
	with ESMTP id 65422741032372468; Wed, 18 Sep 2002 12:07:48 -0600
Message-ID: <01e001c25f3d$d0b45c40$9b114498@esedlar>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: "Stefan Eissing" <stefan.eissing@greenbytes.de>
Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
References: <B4CC2CD7-CADD-11D6-9F78-00039384827E@greenbytes.de>
Date: Wed, 18 Sep 2002 11:04:21 -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: ETags, was: Issues from Interop/Interim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6716
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>
Content-Transfer-Encoding: 7bit


I still don't see how if RFC2518bis requires ETag support it would
invalidate existing servers.  Clients will continue to support ETag-less
servers to support an older version of the WebDAV spec, until ETag-less
servers are phased out.

----- Original Message -----
From: "Stefan Eissing" <stefan.eissing@greenbytes.de>
To: "Eric Sedlar" <eric.sedlar@oracle.com>
Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
Sent: Wednesday, September 18, 2002 1:07 AM
Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting


>
> Am Mittwoch den, 18. September 2002, um 09:09, schrieb Eric Sedlar:
>
> >
> > RFC2518bis wouldn't invalidate a class of servers if it includes a
> > new token
> > in the DAV: header to indicate support for RFC2518bis.  Clients
> > would still
> > have to deal with no-Etag servers to support RFC2518, but this might
> > accellerate implementation of Etags.
>
> But support for ETag on a resource is visible on the getETag Property.
> What better place to look for ETag support than there?
>
> //Stefan
>
>
> > --Eric
> >
> > ----- Original Message -----
> > From: "Clemm, Geoff" <gclemm@rational.com>
> > To: "Webdav WG" <w3c-dist-auth@w3c.org>
> > Sent: Tuesday, September 17, 2002 7:57 PM
> > Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
> >
> >
> >>
> >> I have no objection to such a warning (in fact, it sounds
> >> like a good idea to me).  But I agree with Julian
> >> that RFC2518bis should not invalidate a whole class of
> >> valid 2518 servers, even for a worthy cause such as ETag support.
> >>
> >> Cheers,
> >> Geoff
> >>
> >> -----Original Message-----
> >> From: Eric Sedlar [mailto:eric.sedlar@oracle.com]
> >> Sent: Tuesday, September 17, 2002 8:47 PM
> >> To: Clemm, Geoff; Webdav WG
> >> Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting
> >>
> >>
> >> As long as you don't mind a client saying something to the effect of:
> >>
> >> "This server does not support the minimal level of functionality that
> >> <product> requires of a WebDAV server (ETags).  We strongly
> >> discourage you
> >> from using this server, as you may lose work."
> >>
> >> when it points at your server, then go ahead and don't support ETags.
> >>
> >> --Eric
> >>
> >> ----- Original Message -----
> >> From: "Clemm, Geoff" <gclemm@rational.com>
> >> To: "Webdav WG" <w3c-dist-auth@w3c.org>
> >> Sent: Tuesday, September 17, 2002 6:50 AM
> >> Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
> >>
> >>
> >>>
> >>> I agree.
> >>>
> >>> -----Original Message-----
> >>> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> >>> Sent: Tuesday, September 17, 2002 4:58 AM
> >>> To: Lisa Dusseault; Webdav WG
> >>> Subject: ETags, was: Issues from Interop/Interim WG Meeting
> >>>
> >>>
> >>>
> >>>> From: w3c-dist-auth-request@w3.org
> >>>> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> >>>> Sent: Sunday, September 15, 2002 8:14 PM
> >>>> To: Webdav WG
> >>>> Subject: Issues from Interop/Interim WG Meeting
> >>>>
> >>>> ...
> >>>> -  Be clear in spec that servers MUST do ETags. Explain how
> >>>> necessary
> >>>> this is to solve the lost update problem.
> >>>> ..
> >>>
> >>> ETags are a good thing, correct. However, HTTP (RFC2616) doesn't
> >>> require
> >>> them, RFC2518 doesn't require them, and they '*aren't* required for
> >>> interoperability. So there's no way to require them in
> >>> RFC2518bis -- it
> >>> would break all servers that don't have them.
> >>>
> >>> Julian
> >>>
> >>> --
> >>> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >>>
> >>>
> >>
> >>
> >
> >
>
>
>
>



From w3c-dist-auth-request@w3.org  Wed Sep 18 14:11:54 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24245
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 14:11:53 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IICoH20967;
	Wed, 18 Sep 2002 14:12:50 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 14:12:50 -0400 (EDT)
Resent-Message-Id: <200209181812.g8IICoH20967@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IICmI20941
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 14:12:48 -0400 (EDT)
Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA20170
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 14:12:48 -0400
Received: from inet-mail4.oracle.com (localhost [127.0.0.1])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8IICH725242
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 11:12:17 -0700 (PDT)
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13])
	by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8IICGp25233
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 11:12:16 -0700 (PDT)
Received: from rgmum1.us.oracle.com (rgmum1.us.oracle.com [138.1.191.22])
	by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8IICGO20728
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 12:12:16 -0600 (MDT)
Received: from 152.68.17.155 by rgmum2.us.oracle.com
	with ESMTP id 65426911032372735; Wed, 18 Sep 2002 12:12:15 -0600
Message-ID: <01f301c25f3e$70093d60$9b114498@esedlar>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
References: <JIEGINCHMLABHJBIGKBCCEPEFFAA.julian.reschke@gmx.de>
Date: Wed, 18 Sep 2002 11:08:48 -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: ETags, was: Issues from Interop/Interim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6717
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>
Content-Transfer-Encoding: 7bit


Well, it really all depends on how compelling the use cases are that require
ETag support.  It's ok to make servers do things that may be hard for some
implementations if it delivers solid benefits for the client.  I heard some
pretty solid use cases at the Interop event.

In your filesystem example, as long as all of the access to the files can be
intercepted by the server software somehow, keeping around an ETag is not a
big problem as you can bump up a sequence number on each write.  A simple
filesystem based server may also have problems with supporting UUIDs as
well.

--Eric

----- Original Message -----
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Eric Sedlar" <eric.sedlar@oracle.com>; "Webdav WG"
<w3c-dist-auth@w3c.org>
Sent: Wednesday, September 18, 2002 1:33 AM
Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting


> Eric,
>
> the problem in requiring things is that you may get what you thought you
> want, but then discover it was wrong to ask for it.
>
> If you declare a server that doesn't have entity tags non-compliant, you
> might get the server implementor to reconsider his/her decision. In some
> cases, there may be a very good technical reason not to supply entity
tags -
> for instance, if your store is a file system, and you don't have any
> additional place for metadata. Computing a reliable entity tag just from
the
> file's properties (timestamp, length...) is impossible, but the
implementor
> might attempt it anyway. In the end you'll get a server that *does* supply
> entity tags, but they only work most of the time, so they aren't reliable.
> That's worse than not having them at all.
>
> So, there are valid reasons for RFC2616 to make these things optional
(same
> for server timestamps). I'm happy with language that explains that entity
> tags are an important feature, but it should also make clear that if a
> server can't provide reliable entity tags, it shouldn't attempt to.
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> > Sent: Wednesday, September 18, 2002 9:10 AM
> > To: Webdav WG
> > Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting
> >
> >
> >
> > RFC2518bis wouldn't invalidate a class of servers if it includes
> > a new token
> > in the DAV: header to indicate support for RFC2518bis.  Clients
> > would still
> > have to deal with no-Etag servers to support RFC2518, but this might
> > accellerate implementation of Etags.
> >
> > --Eric
> >
> > ----- Original Message -----
> > From: "Clemm, Geoff" <gclemm@rational.com>
> > To: "Webdav WG" <w3c-dist-auth@w3c.org>
> > Sent: Tuesday, September 17, 2002 7:57 PM
> > Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
> >
> >
> > >
> > > I have no objection to such a warning (in fact, it sounds
> > > like a good idea to me).  But I agree with Julian
> > > that RFC2518bis should not invalidate a whole class of
> > > valid 2518 servers, even for a worthy cause such as ETag support.
> > >
> > > Cheers,
> > > Geoff
> > >
> > > -----Original Message-----
> > > From: Eric Sedlar [mailto:eric.sedlar@oracle.com]
> > > Sent: Tuesday, September 17, 2002 8:47 PM
> > > To: Clemm, Geoff; Webdav WG
> > > Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting
> > >
> > >
> > > As long as you don't mind a client saying something to the effect of:
> > >
> > > "This server does not support the minimal level of functionality that
> > > <product> requires of a WebDAV server (ETags).  We strongly
> > discourage you
> > > from using this server, as you may lose work."
> > >
> > > when it points at your server, then go ahead and don't support ETags.
> > >
> > > --Eric
> > >
> > > ----- Original Message -----
> > > From: "Clemm, Geoff" <gclemm@rational.com>
> > > To: "Webdav WG" <w3c-dist-auth@w3c.org>
> > > Sent: Tuesday, September 17, 2002 6:50 AM
> > > Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
> > >
> > >
> > > >
> > > > I agree.
> > > >
> > > > -----Original Message-----
> > > > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > > > Sent: Tuesday, September 17, 2002 4:58 AM
> > > > To: Lisa Dusseault; Webdav WG
> > > > Subject: ETags, was: Issues from Interop/Interim WG Meeting
> > > >
> > > >
> > > >
> > > > > From: w3c-dist-auth-request@w3.org
> > > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> > > > > Sent: Sunday, September 15, 2002 8:14 PM
> > > > > To: Webdav WG
> > > > > Subject: Issues from Interop/Interim WG Meeting
> > > > >
> > > > > ...
> > > > > -  Be clear in spec that servers MUST do ETags. Explain how
> > necessary
> > > > > this is to solve the lost update problem.
> > > > > ..
> > > >
> > > > ETags are a good thing, correct. However, HTTP (RFC2616)
> > doesn't require
> > > > them, RFC2518 doesn't require them, and they '*aren't* required for
> > > > interoperability. So there's no way to require them in
> > RFC2518bis -- it
> > > > would break all servers that don't have them.
> > > >
> > > > Julian
> > > >
> > > > --
> > > > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> > > >
> > > >
> > >
> > >
> >
>
>



From w3c-dist-auth-request@w3.org  Wed Sep 18 14:13:00 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24274
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 14:13:00 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IIDww21206;
	Wed, 18 Sep 2002 14:13:58 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 14:13:58 -0400 (EDT)
Resent-Message-Id: <200209181813.g8IIDww21206@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IIDuI21173
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 14:13:56 -0400 (EDT)
Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA20563
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 14:13:56 -0400
Received: from inet-mail1.oracle.com (localhost [127.0.0.1])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8IIDPe02161
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 11:13:25 -0700 (PDT)
Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8IIDPC02146
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 11:13:25 -0700 (PDT)
Received: from rgmum1.us.oracle.com (rgmum1.us.oracle.com [138.1.191.22])
	by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8IIDOO21996
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 12:13:24 -0600 (MDT)
Received: from 152.68.17.155 by rgmum4.us.oracle.com
	with ESMTP id 65428141032372803; Wed, 18 Sep 2002 12:13:23 -0600
Message-ID: <020c01c25f3e$988c5560$9b114498@esedlar>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: "Julian Reschke" <julian.reschke@gmx.de>,
        "Lisa Dusseault" <lisa@xythos.com>,
        "'Ilya Kirnos'" <ilya.kirnos@oracle.com>
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
References: <JIEGINCHMLABHJBIGKBCAEPFFFAA.julian.reschke@gmx.de>
Date: Wed, 18 Sep 2002 11:09:56 -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: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6718
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>
Content-Transfer-Encoding: 7bit


Authentication is explicitly out of the scope of the ACL spec.
Authentication is assumed to be handled at the HTTP level, and there are
already plenty of schemes for this.

--Eric

----- Original Message -----
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Lisa Dusseault" <lisa@xythos.com>; "'Ilya Kirnos'"
<ilya.kirnos@oracle.com>
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Sent: Wednesday, September 18, 2002 1:37 AM
Subject: RE: Interop issue: how can clients force authentication?


..

> makes it clear that we need some more time to precisely describe what the
> actual problem is. It's an interesting problem, and I suppose it needs to
be
> discussed in relation to the ACL spec. However I don't think there's any
> reason to declare it an interop problem just to rush a quick workaround
into
> RFC2518bis.
>




From w3c-dist-auth-request@w3.org  Wed Sep 18 14:14:56 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24355
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 14:14:56 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IIFq721591;
	Wed, 18 Sep 2002 14:15:52 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 14:15:52 -0400 (EDT)
Resent-Message-Id: <200209181815.g8IIFq721591@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IIFpI21565
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 14:15:51 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA21065
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 14:15:51 -0400
Received: (qmail 7996 invoked by uid 0); 18 Sep 2002 18:15:20 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp006-rz3) with SMTP; 18 Sep 2002 18:15:20 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Eric Sedlar" <eric.sedlar@oracle.com>,
        "Stefan Eissing" <stefan.eissing@greenbytes.de>
Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Wed, 18 Sep 2002 20:15:19 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCOEAKFGAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <01e001c25f3d$d0b45c40$9b114498@esedlar>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6719
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>
Content-Transfer-Encoding: 7bit


Eric,

if RFC2518bis requires ETag support, old, otherwise RFC2518-compliant and
non-ETag-supporting servers will not be compliant to RFC2518bis. So
something that was fully compliant before, isn't in the with the revision. I
don't think this is allowed at this publication stage.

Julian

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> Sent: Wednesday, September 18, 2002 8:04 PM
> To: Stefan Eissing
> Cc: Webdav WG
> Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting
>
>
>
> I still don't see how if RFC2518bis requires ETag support it would
> invalidate existing servers.  Clients will continue to support ETag-less
> servers to support an older version of the WebDAV spec, until ETag-less
> servers are phased out.
>
> ----- Original Message -----
> From: "Stefan Eissing" <stefan.eissing@greenbytes.de>
> To: "Eric Sedlar" <eric.sedlar@oracle.com>
> Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
> Sent: Wednesday, September 18, 2002 1:07 AM
> Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting
>
>
> >
> > Am Mittwoch den, 18. September 2002, um 09:09, schrieb Eric Sedlar:
> >
> > >
> > > RFC2518bis wouldn't invalidate a class of servers if it includes a
> > > new token
> > > in the DAV: header to indicate support for RFC2518bis.  Clients
> > > would still
> > > have to deal with no-Etag servers to support RFC2518, but this might
> > > accellerate implementation of Etags.
> >
> > But support for ETag on a resource is visible on the getETag Property.
> > What better place to look for ETag support than there?
> >
> > //Stefan
> >
> >
> > > --Eric
> > >
> > > ----- Original Message -----
> > > From: "Clemm, Geoff" <gclemm@rational.com>
> > > To: "Webdav WG" <w3c-dist-auth@w3c.org>
> > > Sent: Tuesday, September 17, 2002 7:57 PM
> > > Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
> > >
> > >
> > >>
> > >> I have no objection to such a warning (in fact, it sounds
> > >> like a good idea to me).  But I agree with Julian
> > >> that RFC2518bis should not invalidate a whole class of
> > >> valid 2518 servers, even for a worthy cause such as ETag support.
> > >>
> > >> Cheers,
> > >> Geoff
> > >>
> > >> -----Original Message-----
> > >> From: Eric Sedlar [mailto:eric.sedlar@oracle.com]
> > >> Sent: Tuesday, September 17, 2002 8:47 PM
> > >> To: Clemm, Geoff; Webdav WG
> > >> Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting
> > >>
> > >>
> > >> As long as you don't mind a client saying something to the effect of:
> > >>
> > >> "This server does not support the minimal level of functionality that
> > >> <product> requires of a WebDAV server (ETags).  We strongly
> > >> discourage you
> > >> from using this server, as you may lose work."
> > >>
> > >> when it points at your server, then go ahead and don't support ETags.
> > >>
> > >> --Eric
> > >>
> > >> ----- Original Message -----
> > >> From: "Clemm, Geoff" <gclemm@rational.com>
> > >> To: "Webdav WG" <w3c-dist-auth@w3c.org>
> > >> Sent: Tuesday, September 17, 2002 6:50 AM
> > >> Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
> > >>
> > >>
> > >>>
> > >>> I agree.
> > >>>
> > >>> -----Original Message-----
> > >>> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > >>> Sent: Tuesday, September 17, 2002 4:58 AM
> > >>> To: Lisa Dusseault; Webdav WG
> > >>> Subject: ETags, was: Issues from Interop/Interim WG Meeting
> > >>>
> > >>>
> > >>>
> > >>>> From: w3c-dist-auth-request@w3.org
> > >>>> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> > >>>> Sent: Sunday, September 15, 2002 8:14 PM
> > >>>> To: Webdav WG
> > >>>> Subject: Issues from Interop/Interim WG Meeting
> > >>>>
> > >>>> ...
> > >>>> -  Be clear in spec that servers MUST do ETags. Explain how
> > >>>> necessary
> > >>>> this is to solve the lost update problem.
> > >>>> ..
> > >>>
> > >>> ETags are a good thing, correct. However, HTTP (RFC2616) doesn't
> > >>> require
> > >>> them, RFC2518 doesn't require them, and they '*aren't* required for
> > >>> interoperability. So there's no way to require them in
> > >>> RFC2518bis -- it
> > >>> would break all servers that don't have them.
> > >>>
> > >>> Julian
> > >>>
> > >>> --
> > >>> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> > >>>
> > >>>
> > >>
> > >>
> > >
> > >
> >
> >
> >
> >
>



From w3c-dist-auth-request@w3.org  Wed Sep 18 14:27:43 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24754
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 14:27:43 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IISmY22923;
	Wed, 18 Sep 2002 14:28:48 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 14:28:48 -0400 (EDT)
Resent-Message-Id: <200209181828.g8IISmY22923@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IISkI22896
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 14:28:46 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA23387
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 14:28:46 -0400
Received: (qmail 10985 invoked by uid 0); 18 Sep 2002 18:28:15 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp004-rz3) with SMTP; 18 Sep 2002 18:28:15 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Eric Sedlar" <eric.sedlar@oracle.com>,
        "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Wed, 18 Sep 2002 20:28:14 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCAEAMFGAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <01f301c25f3e$70093d60$9b114498@esedlar>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6720
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>
Content-Transfer-Encoding: 7bit


> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> Sent: Wednesday, September 18, 2002 8:09 PM
> To: Webdav WG
> Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting
>
>
>
> Well, it really all depends on how compelling the use cases are
> that require
> ETag support.  It's ok to make servers do things that may be hard for some
> implementations if it delivers solid benefits for the client.  I
> heard some
> pretty solid use cases at the Interop event.

Hard yes, impossible no.

If a server that complies to RFC2518 doesn't comply to RFC2518bis, then
we've broken the IETF publication process, haven't we?

> In your filesystem example, as long as all of the access to the
> files can be
> intercepted by the server software somehow, keeping around an
> ETag is not a
> big problem as you can bump up a sequence number on each write.  A simple

Incrementing sequence numbers isn't the problem. Persisting them may be.

> filesystem based server may also have problems with supporting UUIDs as
> well.

UUIDs for what?

Julian

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



From w3c-dist-auth-request@w3.org  Wed Sep 18 14:52:49 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25900
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 14:52:49 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IIrHl25439;
	Wed, 18 Sep 2002 14:53:17 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 14:53:17 -0400 (EDT)
Resent-Message-Id: <200209181853.g8IIrHl25439@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IIrGI25413
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 14:53:16 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA27763
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 14:53:16 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 18 Sep 2002 14:52:40 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Wed, 18 Sep 2002 14:52:40 -0400
Received: from xythoslap ([198.144.203.248]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Wed, 18 Sep 2002 14:52:39 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Wed, 18 Sep 2002 11:52:38 -0700
Message-ID: <013301c25f44$905f3a50$b701a8c0@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <JIEGINCHMLABHJBIGKBCAEAMFGAA.julian.reschke@gmx.de>
X-OriginalArrivalTime: 18 Sep 2002 18:52:40.0114 (UTC) FILETIME=[902DF120:01C25F44]
Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6721
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>
Content-Transfer-Encoding: 7bit


> If a server that complies to RFC2518 doesn't comply to RFC2518bis,
then
> we've broken the IETF publication process, haven't we?

I don't think that's necessarily true.  I checked with my local IAB
member, and we don't think it's forbidden to upgrade a standard from
Proposed Standard to Draft Standard, even if in the process the standard
becomes somewhat more stringent in what constitutes compliance from
implementations. (He says particularly if the requirement is a SHOULD
now.)  It's a difficult judgement call, and one must weigh the
interoperability concerns of both making and not making the change. But
in principle, it's not forbidden. 

Our ADs will certainly weigh in on this when we've hashed it out more
amongst ourselves, but in the meantime we shouldn't have to restrict
ourselves rigidly in this matter.

Lisa



From w3c-dist-auth-request@w3.org  Wed Sep 18 15:10:52 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26778
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 15:10:52 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IJBom04973;
	Wed, 18 Sep 2002 15:11:50 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 15:11:50 -0400 (EDT)
Resent-Message-Id: <200209181911.g8IJBom04973@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IJBkI04858
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 15:11:47 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA31849
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 15:11:46 -0400
Received: (qmail 5449 invoked by uid 0); 18 Sep 2002 19:11:15 -0000
Received: from p3ee2471d.dip.t-dialin.net (HELO lisa) (62.226.71.29)
  by mail.gmx.net (mp013-rz3) with SMTP; 18 Sep 2002 19:11:15 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Lisa Dusseault" <lisa@xythos.com>,
        "'Julian Reschke'" <julian.reschke@gmx.de>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Wed, 18 Sep 2002 21:11:13 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCIEAOFGAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <013301c25f44$905f3a50$b701a8c0@xythoslap>
Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6722
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>
Content-Transfer-Encoding: 7bit


> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Wednesday, September 18, 2002 8:53 PM
> To: 'Julian Reschke'; 'Webdav WG'
> Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
>
>
>
> > If a server that complies to RFC2518 doesn't comply to RFC2518bis,
> then
> > we've broken the IETF publication process, haven't we?
>
> I don't think that's necessarily true.  I checked with my local IAB
> member, and we don't think it's forbidden to upgrade a standard from
> Proposed Standard to Draft Standard, even if in the process the standard
> becomes somewhat more stringent in what constitutes compliance from
> implementations. (He says particularly if the requirement is a SHOULD
> now.)  It's a difficult judgement call, and one must weigh the

But it isn't a SHOULD right now.

RFC2518 says:

"The getetag property MUST be defined on any DAV compliant resource that
returns the Etag header."

So if I have an HTTP resource for which HEAD/GET wouldn't return an ETag
header, it's absolutely OK not to return the DAV:getetag property.

> interoperability concerns of both making and not making the change. But
> in principle, it's not forbidden.
>
> Our ADs will certainly weigh in on this when we've hashed it out more
> amongst ourselves, but in the meantime we shouldn't have to restrict
> ourselves rigidly in this matter.



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



From w3c-dist-auth-request@w3.org  Wed Sep 18 16:08:30 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28511
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 16:08:29 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8IK9It06719;
	Wed, 18 Sep 2002 16:09:18 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 16:09:18 -0400 (EDT)
Resent-Message-Id: <200209182009.g8IK9It06719@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8IK9GB06685
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 16:09:16 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA11657
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 16:09:16 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 18 Sep 2002 13:54:28 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <TDR33LVK>; Wed, 18 Sep 2002 14:04:17 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10783924E@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: Webdav WG <w3c-dist-auth@w3c.org>
Date: Wed, 18 Sep 2002 14:04:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6723
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>


I think this thread is diverging a bit from the key aspects
of the proposal to use the If header instead of inventing a
new header.

In particular, suppose a client used the new header.  This request
will fail against every existing DAV server.  Suppose instead the client
used the If header, using the:
  If ("a" Not "a")
form.  This request will do what is desired against every existing
DAV server that:
- supports the If header (correctly) and that 
- does any authentication checks before the If checks.

For all new DAV servers, they can equally well either implement a new
header, or could implement the If header (which they should do anyway),
and make sure they do any authentication checks before the If check
(which they should do anyway).

I believe it is clear that it provides increased interoperability
to use the If header approach, since this provides at least some
interoperability with existing servers, while the new header (or new
anything) approach does not.

Cheers,
Geoff


-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Wednesday, September 18, 2002 12:29 PM
To: 'Stefan Eissing'
Cc: Webdav WG
Subject: RE: Interop issue: how can clients force authentication?



> First, I bet that 100% of all non-broken, existing servers do
> authentication checks before looking at the request resource and
> its properities like locks. It's the sensible thing to do, as a
> user might not even have read permission on the resource. So
> one probably should prevent him/her from finding out about the lock
> status of the resource.

No, and why should they?  There's nothing in RFC2518 that requires
servers to support locks only for authenticated users.  If a resource is
publicly writable, there may be nothing to prevent unauthenticated users
from taking out locks and using lock tokens.  Recall that the If header
can also be used with ETags, which are not at all associated with how a
user is authenticated.

Also, recall that in order to "do authentication checks", the server
must respond to the client with a 401 with the WWW-Authenticate header,
then the client must make another request.  

Of course if the client sent its authentication information on the first
request, the server is likely to check it.  However, the client can't
even send its authentication information if it doesn't yet know whether
the server supports digest or basic, or what realm, nonce, etc.  That's
why Ilya wants to be able to ask the server to reply with a
WWW-Authenticate header.  

Lisa



From w3c-dist-auth-request@w3.org  Wed Sep 18 19:58:31 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04097
	for <webdav-archive@lists.ietf.org>; Wed, 18 Sep 2002 19:58:30 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8INxJ602577;
	Wed, 18 Sep 2002 19:59:19 -0400 (EDT)
Resent-Date: Wed, 18 Sep 2002 19:59:19 -0400 (EDT)
Resent-Message-Id: <200209182359.g8INxJ602577@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8INxHB02547
	for <w3c-dist-auth@frink.w3.org>; Wed, 18 Sep 2002 19:59:17 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA21184
	for <w3c-dist-auth@w3c.org>; Wed, 18 Sep 2002 19:59:17 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 18 Sep 2002 17:19:26 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <TDR335BB>; Wed, 18 Sep 2002 17:29:15 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B107839253@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: Webdav WG <w3c-dist-auth@w3c.org>
Date: Wed, 18 Sep 2002 17:29:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6724
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>


And even if we are theoretically allowed to make such a change,
I believe we should do so only for the most compelling reasons,
since a change of this kind will make an implementor much less likely
to put a great deal of effort into supporting a given RFC if
the working group has a track record of releasing later revisions
of that RFC that put their original implementation into non-compliance.

On a related topic, working to marshall new functionality through
existing machinery rewards an implementor for going to the effort of being
fully compliant, and increases the likelihood that implementors will bother
to do so.  

Otherwise, we are sending out the message that an implementor
should just implement the subset they feel like in the way that the
feel like, counting on "interoperability concerns" to cause the protocol
to be revised to match their implementation.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Wednesday, September 18, 2002 2:15 PM
To: Eric Sedlar; Stefan Eissing
Cc: Webdav WG
Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting



Eric,

if RFC2518bis requires ETag support, old, otherwise RFC2518-compliant and
non-ETag-supporting servers will not be compliant to RFC2518bis. So
something that was fully compliant before, isn't in the with the revision. I
don't think this is allowed at this publication stage.

Julian

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> Sent: Wednesday, September 18, 2002 8:04 PM
> To: Stefan Eissing
> Cc: Webdav WG
> Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting
>
>
>
> I still don't see how if RFC2518bis requires ETag support it would
> invalidate existing servers.  Clients will continue to support ETag-less
> servers to support an older version of the WebDAV spec, until ETag-less
> servers are phased out.
>
> ----- Original Message -----
> From: "Stefan Eissing" <stefan.eissing@greenbytes.de>
> To: "Eric Sedlar" <eric.sedlar@oracle.com>
> Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
> Sent: Wednesday, September 18, 2002 1:07 AM
> Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting
>
>
> >
> > Am Mittwoch den, 18. September 2002, um 09:09, schrieb Eric Sedlar:
> >
> > >
> > > RFC2518bis wouldn't invalidate a class of servers if it includes a
> > > new token
> > > in the DAV: header to indicate support for RFC2518bis.  Clients
> > > would still
> > > have to deal with no-Etag servers to support RFC2518, but this might
> > > accellerate implementation of Etags.
> >
> > But support for ETag on a resource is visible on the getETag Property.
> > What better place to look for ETag support than there?
> >
> > //Stefan
> >
> >
> > > --Eric
> > >
> > > ----- Original Message -----
> > > From: "Clemm, Geoff" <gclemm@rational.com>
> > > To: "Webdav WG" <w3c-dist-auth@w3c.org>
> > > Sent: Tuesday, September 17, 2002 7:57 PM
> > > Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
> > >
> > >
> > >>
> > >> I have no objection to such a warning (in fact, it sounds
> > >> like a good idea to me).  But I agree with Julian
> > >> that RFC2518bis should not invalidate a whole class of
> > >> valid 2518 servers, even for a worthy cause such as ETag support.
> > >>
> > >> Cheers,
> > >> Geoff
> > >>
> > >> -----Original Message-----
> > >> From: Eric Sedlar [mailto:eric.sedlar@oracle.com]
> > >> Sent: Tuesday, September 17, 2002 8:47 PM
> > >> To: Clemm, Geoff; Webdav WG
> > >> Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting
> > >>
> > >>
> > >> As long as you don't mind a client saying something to the effect of:
> > >>
> > >> "This server does not support the minimal level of functionality that
> > >> <product> requires of a WebDAV server (ETags).  We strongly
> > >> discourage you
> > >> from using this server, as you may lose work."
> > >>
> > >> when it points at your server, then go ahead and don't support ETags.
> > >>
> > >> --Eric
> > >>
> > >> ----- Original Message -----
> > >> From: "Clemm, Geoff" <gclemm@rational.com>
> > >> To: "Webdav WG" <w3c-dist-auth@w3c.org>
> > >> Sent: Tuesday, September 17, 2002 6:50 AM
> > >> Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
> > >>
> > >>
> > >>>
> > >>> I agree.
> > >>>
> > >>> -----Original Message-----
> > >>> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > >>> Sent: Tuesday, September 17, 2002 4:58 AM
> > >>> To: Lisa Dusseault; Webdav WG
> > >>> Subject: ETags, was: Issues from Interop/Interim WG Meeting
> > >>>
> > >>>
> > >>>
> > >>>> From: w3c-dist-auth-request@w3.org
> > >>>> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> > >>>> Sent: Sunday, September 15, 2002 8:14 PM
> > >>>> To: Webdav WG
> > >>>> Subject: Issues from Interop/Interim WG Meeting
> > >>>>
> > >>>> ...
> > >>>> -  Be clear in spec that servers MUST do ETags. Explain how
> > >>>> necessary
> > >>>> this is to solve the lost update problem.
> > >>>> ..
> > >>>
> > >>> ETags are a good thing, correct. However, HTTP (RFC2616) doesn't
> > >>> require
> > >>> them, RFC2518 doesn't require them, and they '*aren't* required for
> > >>> interoperability. So there's no way to require them in
> > >>> RFC2518bis -- it
> > >>> would break all servers that don't have them.
> > >>>
> > >>> Julian
> > >>>
> > >>> --
> > >>> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> > >>>
> > >>>
> > >>
> > >>
> > >
> > >
> >
> >
> >
> >
>



From w3c-dist-auth-request@w3.org  Thu Sep 19 04:57:36 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27333
	for <webdav-archive@lists.ietf.org>; Thu, 19 Sep 2002 04:57:36 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8J8wNU18380;
	Thu, 19 Sep 2002 04:58:24 -0400 (EDT)
Resent-Date: Thu, 19 Sep 2002 04:58:24 -0400 (EDT)
Resent-Message-Id: <200209190858.g8J8wNU18380@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8J8wHB18354
	for <w3c-dist-auth@frink.w3.org>; Thu, 19 Sep 2002 04:58:17 -0400 (EDT)
Received: from kurgan.lyra.org (kurgan.lyra.org [198.144.203.198])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA00499
	for <w3c-dist-auth@w3.org>; Thu, 19 Sep 2002 04:58:17 -0400
Received: (from gstein@localhost)
	by kurgan.lyra.org (8.9.3/8.9.3) id BAA21173;
	Thu, 19 Sep 2002 01:58:35 -0700
X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f
Date: Thu, 19 Sep 2002 01:58:35 -0700
From: Greg Stein <gstein@lyra.org>
To: Lisa Dusseault <lisa@xythos.com>
Cc: "'Julian Reschke'" <julian.reschke@gmx.de>, w3c-dist-auth@w3.org
Message-ID: <20020919015835.A21144@lyra.org>
Mail-Followup-To: Lisa Dusseault <lisa@xythos.com>,
	'Julian Reschke' <julian.reschke@gmx.de>, w3c-dist-auth@w3.org
References: <JIEGINCHMLABHJBIGKBCAEAGFGAA.julian.reschke@gmx.de> <011101c25f34$7f95b150$b701a8c0@xythoslap>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <011101c25f34$7f95b150$b701a8c0@xythoslap>; from lisa@xythos.com on Wed, Sep 18, 2002 at 09:57:39AM -0700
X-URL: http://www.lyra.org/greg/
Subject: Re: I-D ACTION:draft-ietf-webdav-rfc2518bis-02.txt
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6725
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>


On Wed, Sep 18, 2002 at 09:57:39AM -0700, Lisa Dusseault wrote:
>...
> I firmly believe that it is correct for a draft to go to the IETF
> Internet-Draft repository when it is circulated to the entire WG mailing
> list.  I would be happy to have Patrick, Ned or Harald correct me on
> this.

I *completely* agree with your position, Lisa. I don't think Julian should
have taken any issue with the posting of a new I-D. Having a new I-D
provides a concrete draft for further discussion and refinement. People can
now refer to the -02 draft, rather than some nebulous concept of "lisa's
draft as of last Tuesday".

Please keep sending in new I-D's each time you have additional content.
You've got at least one supporter here :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From w3c-dist-auth-request@w3.org  Thu Sep 19 05:52:13 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28388
	for <webdav-archive@lists.ietf.org>; Thu, 19 Sep 2002 05:52:13 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8J9qP524969;
	Thu, 19 Sep 2002 05:52:25 -0400 (EDT)
Resent-Date: Thu, 19 Sep 2002 05:52:25 -0400 (EDT)
Resent-Message-Id: <200209190952.g8J9qP524969@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8J9qMB24935
	for <w3c-dist-auth@frink.w3.org>; Thu, 19 Sep 2002 05:52:22 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA09903
	for <w3c-dist-auth@w3c.org>; Thu, 19 Sep 2002 05:52:22 -0400
Received: (qmail 26338 invoked by uid 0); 19 Sep 2002 09:51:51 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp006-rz3) with SMTP; 19 Sep 2002 09:51:51 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Thu, 19 Sep 2002 11:51:48 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCIECBFGAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B107839253@SUS-MA1IT01>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6726
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>
Content-Transfer-Encoding: 7bit


Some more thoughts on ETags:

1) Even for a server that *in general* supplies ETags, there may be some
special resources that can't have them. So requiring them won't work.
Example: a very common implementation for WebDAV ACL principal resources
will be a proxy resource that talks to a usermanagement back-end. These
resources may have content (for instance, a vCard entity body), but they
won't have an entity tag (because they are dynamically generated from a
remote object). This basically applies to all resources that are dynamically
created and not easily cached. So is a server that has GETtable, but
non-cacheable principal resources compliant to RFC2518bis?

2) It was said that lack of ETag is an interop problem. I can see why some
authoring clients would want to require that a resource that they are going
to modify has valid ETags. However, on a RFC2518-compliant server a client
can easily detect whether ETags are supported, and thus refuse to modify the
resource accordingly. This really isn't a problem -- it just means that a
particular client can't modify a particular resource, and the user can be
notified. However, it would be a much bigger problem if a server claims that
it has ETags, but they don't work properly. In this case, the user agent
will try to take advantage of ETag handling, and this may result in lost
updates, faulty cache contents and so on. So *this* is what the revision of
RFC2518 should say: if you can't provide proper ETags for a resource, it's
better that you *don't* try and thus let clients that rely on proper ETag
handling fail in a predictable way.

Julian

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



From w3c-dist-auth-request@w3.org  Thu Sep 19 17:28:11 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24121
	for <webdav-archive@lists.ietf.org>; Thu, 19 Sep 2002 17:28:11 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8JLPh716535;
	Thu, 19 Sep 2002 17:25:43 -0400 (EDT)
Resent-Date: Thu, 19 Sep 2002 17:25:43 -0400 (EDT)
Resent-Message-Id: <200209192125.g8JLPh716535@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8JLPfB16509
	for <w3c-dist-auth@frink.w3.org>; Thu, 19 Sep 2002 17:25:41 -0400 (EDT)
Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA14903
	for <w3c-dist-auth@w3c.org>; Thu, 19 Sep 2002 17:25:41 -0400
Received: from inet-mail3.oracle.com (localhost [127.0.0.1])
	by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8JLP9P27030
	for <w3c-dist-auth@w3c.org>; Thu, 19 Sep 2002 14:25:10 -0700 (PDT)
Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14])
	by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8JLP9R27014;
	Thu, 19 Sep 2002 14:25:09 -0700 (PDT)
Received: from oracle.com (ikirnos-pc.us.oracle.com [130.35.68.81])
	by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8JLP8r05905;
	Thu, 19 Sep 2002 15:25:08 -0600 (MDT)
Message-ID: <3D8A413A.7008C518@oracle.com>
Date: Thu, 19 Sep 2002 14:27:22 -0700
From: Ilya Kirnos <ilya.kirnos@oracle.com>
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Clemm, Geoff" <gclemm@rational.com>
CC: Webdav WG <w3c-dist-auth@w3c.org>
References: <3906C56A7BD1F54593344C05BD1374B10783924E@SUS-MA1IT01>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6727
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>
Content-Transfer-Encoding: 7bit


the fact that this may already work with some implementations is a plus.  on
the other hand it would pretty much be a hack.  when i see something like
If: ("a" Not "a"), client authentication is not exactly the first thing that
comes to mind.  a new header would make this idea very explicit and probably
less prone to implementation errors.  however, i'd like to see this feature
implemented in some shape or form, so if there's consensus on the If header,
it'd be fine with me.

-ilya


"Clemm, Geoff" wrote:

> I think this thread is diverging a bit from the key aspects
> of the proposal to use the If header instead of inventing a
> new header.
>
> In particular, suppose a client used the new header.  This request
> will fail against every existing DAV server.  Suppose instead the client
> used the If header, using the:
>   If ("a" Not "a")
> form.  This request will do what is desired against every existing
> DAV server that:
> - supports the If header (correctly) and that
> - does any authentication checks before the If checks.
>
> For all new DAV servers, they can equally well either implement a new
> header, or could implement the If header (which they should do anyway),
> and make sure they do any authentication checks before the If check
> (which they should do anyway).
>
> I believe it is clear that it provides increased interoperability
> to use the If header approach, since this provides at least some
> interoperability with existing servers, while the new header (or new
> anything) approach does not.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Wednesday, September 18, 2002 12:29 PM
> To: 'Stefan Eissing'
> Cc: Webdav WG
> Subject: RE: Interop issue: how can clients force authentication?
>
> > First, I bet that 100% of all non-broken, existing servers do
> > authentication checks before looking at the request resource and
> > its properities like locks. It's the sensible thing to do, as a
> > user might not even have read permission on the resource. So
> > one probably should prevent him/her from finding out about the lock
> > status of the resource.
>
> No, and why should they?  There's nothing in RFC2518 that requires
> servers to support locks only for authenticated users.  If a resource is
> publicly writable, there may be nothing to prevent unauthenticated users
> from taking out locks and using lock tokens.  Recall that the If header
> can also be used with ETags, which are not at all associated with how a
> user is authenticated.
>
> Also, recall that in order to "do authentication checks", the server
> must respond to the client with a 401 with the WWW-Authenticate header,
> then the client must make another request.
>
> Of course if the client sent its authentication information on the first
> request, the server is likely to check it.  However, the client can't
> even send its authentication information if it doesn't yet know whether
> the server supports digest or basic, or what realm, nonce, etc.  That's
> why Ilya wants to be able to ask the server to reply with a
> WWW-Authenticate header.
>
> Lisa



From w3c-dist-auth-request@w3.org  Thu Sep 19 23:37:31 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01439
	for <webdav-archive@lists.ietf.org>; Thu, 19 Sep 2002 23:37:31 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8K3cRn21789;
	Thu, 19 Sep 2002 23:38:27 -0400 (EDT)
Resent-Date: Thu, 19 Sep 2002 23:38:27 -0400 (EDT)
Resent-Message-Id: <200209200338.g8K3cRn21789@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8K3cOB21755
	for <w3c-dist-auth@frink.w3.org>; Thu, 19 Sep 2002 23:38:24 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA04081
	for <w3c-dist-auth@w3c.org>; Thu, 19 Sep 2002 23:38:23 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id UAA01141 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Thu, 19 Sep 2002 20:38:20 -0700
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by sunbelt.seagull.net (8.9.3) with ESMTP id UAA01105 sender obsfucated@us.ibm.com; Thu, 19 Sep 2002 20:38:16 -0700
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8K3bhvI140482; Thu, 19 Sep 2002 23:37:43 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8K3bf7S142326; Thu, 19 Sep 2002 23:37:42 -0400
To: Ilya Kirnos <ilya.kirnos@oracle.com>
Cc: "Clemm, Geoff" <gclemm@Rational.Com>, Webdav WG <w3c-dist-auth@w3c.org>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF953D3997.79352410-ON85256C3A.00131FE3@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Thu, 19 Sep 2002 23:32:03 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_09122002|September 12, 2002) at 09/19/2002 23:37:41
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: Re: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6728
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>





On Thursday, 09/19/2002 at 02:27 MST, Ilya Kirnos wrote:
> the fact that this may already work with some implementations is a plus.
on
> the other hand it would pretty much be a hack.  when i see something like
> If: ("a" Not "a"), client authentication is not exactly the first thing
that
> comes to mind.  a new header would make this idea very explicit and
probably
> less prone to implementation errors.  however, i'd like to see this
feature
> implemented in some shape or form, so if there's consensus on the If
header,
> it'd be fine with me.

I'd like to see two things...

1) A clear problem statement with scenarios
2) A clear statement of the/this proposal

Thanks guys

J.




From w3c-dist-auth-request@w3.org  Fri Sep 20 08:40:05 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20260
	for <webdav-archive@lists.ietf.org>; Fri, 20 Sep 2002 08:40:05 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8KCe7S14528;
	Fri, 20 Sep 2002 08:40:07 -0400 (EDT)
Resent-Date: Fri, 20 Sep 2002 08:40:07 -0400 (EDT)
Resent-Message-Id: <200209201240.g8KCe7S14528@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8KCe5B14492
	for <w3c-dist-auth@frink.w3.org>; Fri, 20 Sep 2002 08:40:05 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA11408
	for <w3c-dist-auth@w3c.org>; Fri, 20 Sep 2002 08:40:05 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 20 Sep 2002 08:29:41 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <TDR3SQJV>; Fri, 20 Sep 2002 08:39:34 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10841DD95@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: Webdav WG <w3c-dist-auth@w3c.org>
Date: Fri, 20 Sep 2002 08:39:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6729
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>


I believe the problem statement is:

The problem: A client wants to check if the current user is
authenticated to do an operation before it has that user provide the
input for that operation, and before it performs expensive 
computations to set up the input for that request.

The proposal: Document in the 2518bis that the authentication check
SHOULD be performed before the If header check (so that a simple
contradictory If header can be used to check the authentication for
"dummy version" of the operation, i.e. one with dummy values that did
not require user input or expensive calculations on the client).

As a general design note wrt some of the alternatives proposed:
Adding new protocol semantics (e.g. a new header) for each interesting
use case would rapidly produce a protocol so complex as to be
unusable.  I believe adding explicit marshalling for semantics that
are already supported adds complexity, not clarity, and that increased
complexity will increase the implementation errors, not decrease them.

Cheers,
Geoff


-----Original Message-----
From: Jason Crawford [mailto:nn683849@smallcue.com]


On Thursday, 09/19/2002 at 02:27 MST, Ilya Kirnos wrote:
> the fact that this may already work with some implementations is a plus.
on
> the other hand it would pretty much be a hack.  when i see something like
> If: ("a" Not "a"), client authentication is not exactly the first thing
that
> comes to mind.  a new header would make this idea very explicit and
probably
> less prone to implementation errors.  however, i'd like to see this
feature
> implemented in some shape or form, so if there's consensus on the If
header,
> it'd be fine with me.

I'd like to see two things...

1) A clear problem statement with scenarios
2) A clear statement of the/this proposal

Thanks guys

J.



From w3c-dist-auth-request@w3.org  Fri Sep 20 11:38:56 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26287
	for <webdav-archive@lists.ietf.org>; Fri, 20 Sep 2002 11:38:54 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8KFVts04060;
	Fri, 20 Sep 2002 11:31:55 -0400 (EDT)
Resent-Date: Fri, 20 Sep 2002 11:31:55 -0400 (EDT)
Resent-Message-Id: <200209201531.g8KFVts04060@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8KFVrB04034
	for <w3c-dist-auth@frink.w3.org>; Fri, 20 Sep 2002 11:31:53 -0400 (EDT)
Received: from matrixmail.matrixone.net (mail.matrix-one.com [4.17.165.4])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA17206
	for <w3c-dist-auth@w3c.org>; Fri, 20 Sep 2002 11:31:53 -0400
Received: from msx2am.matrixone.net 
	by matrixmail.matrixone.net (8.10.1/8.10.1) with ESMTP id g8KFV9e05196;
	Fri, 20 Sep 2002 11:31:10 -0400 (EDT)
Received: by msx2am.matrixone.net with Internet Mail Service (5.5.2653.19)
	id <TD4VX36J>; Fri, 20 Sep 2002 11:31:09 -0400
Message-ID: <9150DCE0CCB4D411A7DB00508BB0DBF202E5C8E3@msx1am.matrixone.net>
From: "Dyer, Kevin" <kevin.dyer@matrixone.com>
To: "'Clemm, Geoff'" <gclemm@Rational.Com>,
        Webdav WG
	 <w3c-dist-auth@w3c.org>
Date: Fri, 20 Sep 2002 11:31:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C260BA.BDF21E20"
Subject: RE: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6730
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>


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

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

>From: Clemm, Geoff [mailto:gclemm@Rational.Com]
>I believe the problem statement is:
>
>The problem: A client wants to check if the current user is
>authenticated to do an operation before it has that user provide the
>input for that operation, and before it performs expensive 
>computations to set up the input for that request.

With this as the problem statement, I believe that we need to look outside
of our own protocol here and take a look at one or more protocols that only
deal with the authentication and authorization of users and systems. Why
does WebDAV have to come up with the whole package themselves? If we look at
the SAML specifications for a moment, it provides the ability to request
from a server what a particular user is asking for and get back a complete
answer. Yes, it is another call but the user is guaranteed to have a
complete answer as to authentication and authorization across a large circle
of influence. By adopting SAML as the back-end mechanism we will also pick
up a true single sign-on capability for WebDAV, something we've talked about
and alluded to but have not considered it in the RFC.

			Comments, rocks, bottles, or stones?

				Kevin

____________________________________________ 
Kevin J. Dyer
Sr. Technologist, Product Management
kevin.dyer@matrixone.com

TEL:     978-322-2011
FAX:     978-322-2040
MOBILE:  978-549-0971

MatrixOne, Inc.
Two Executive Drive
Chelmsford, MA  01824  USA
www.matrixone.com

"Changing the way the world brings products to market" (tm)
____________________________________________

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Interop issue: how can clients force authentication?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&gt;From: Clemm, Geoff [<A =
HREF=3D"mailto:gclemm@Rational.Com">mailto:gclemm@Rational.Com</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt;I believe the problem statement is:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;The problem: A client wants to check if the =
current user is</FONT>
<BR><FONT SIZE=3D2>&gt;authenticated to do an operation before it has =
that user provide the</FONT>
<BR><FONT SIZE=3D2>&gt;input for that operation, and before it performs =
expensive </FONT>
<BR><FONT SIZE=3D2>&gt;computations to set up the input for that =
request.</FONT>
</P>

<P><FONT SIZE=3D2>With this as the problem statement, I believe that we =
need to look outside of our own protocol here and take a look at one or =
more protocols that only deal with the authentication and authorization =
of users and systems. Why does WebDAV have to come up with the whole =
package themselves? If we look at the SAML specifications for a moment, =
it provides the ability to request from a server what a particular user =
is asking for and get back a complete answer. Yes, it is another call =
but the user is guaranteed to have a complete answer as to =
authentication and authorization across a large circle of influence. By =
adopting SAML as the back-end mechanism we will also pick up a true =
single sign-on capability for WebDAV, something we've talked about and =
alluded to but have not considered it in the RFC.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Comments, =
rocks, bottles, or stones?</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Kevin</FONT>
</P>

<P><FONT SIZE=3D2>____________________________________________ </FONT>
<BR><FONT SIZE=3D2>Kevin J. Dyer</FONT>
<BR><FONT SIZE=3D2>Sr. Technologist, Product Management</FONT>
<BR><FONT SIZE=3D2>kevin.dyer@matrixone.com</FONT>
</P>

<P><FONT SIZE=3D2>TEL:&nbsp;&nbsp;&nbsp;&nbsp; 978-322-2011</FONT>
<BR><FONT SIZE=3D2>FAX:&nbsp;&nbsp;&nbsp;&nbsp; 978-322-2040</FONT>
<BR><FONT SIZE=3D2>MOBILE:&nbsp; 978-549-0971</FONT>
</P>

<P><FONT SIZE=3D2>MatrixOne, Inc.</FONT>
<BR><FONT SIZE=3D2>Two Executive Drive</FONT>
<BR><FONT SIZE=3D2>Chelmsford, MA&nbsp; 01824&nbsp; USA</FONT>
<BR><FONT SIZE=3D2>www.matrixone.com</FONT>
</P>

<P><FONT SIZE=3D2>&quot;Changing the way the world brings products to =
market&quot; (tm)</FONT>
<BR><FONT SIZE=3D2>____________________________________________</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C260BA.BDF21E20--



From w3c-dist-auth-request@w3.org  Fri Sep 20 12:04:14 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27490
	for <webdav-archive@lists.ietf.org>; Fri, 20 Sep 2002 12:04:13 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8KFvOS07589;
	Fri, 20 Sep 2002 11:57:24 -0400 (EDT)
Resent-Date: Fri, 20 Sep 2002 11:57:24 -0400 (EDT)
Resent-Message-Id: <200209201557.g8KFvOS07589@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8KFvMB07563
	for <w3c-dist-auth@frink.w3.org>; Fri, 20 Sep 2002 11:57:22 -0400 (EDT)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA24646
	for <w3c-dist-auth@w3.org>; Fri, 20 Sep 2002 11:57:18 -0400
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 20 Sep 2002 08:56:51 -0700
Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 20 Sep 2002 08:56:51 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 20 Sep 2002 08:56:51 -0700
Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 20 Sep 2002 08:56:51 -0700
Received: from WIN-MSG-06.wingroup.windeploy.ntdev.microsoft.com ([157.54.2.22]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0);
	 Fri, 20 Sep 2002 08:56:51 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6757.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Date: Fri, 20 Sep 2002 08:56:51 -0700
Message-ID: <F8E386E0BEC2B942A525499AB0823EB84CAC0F@win-msg-06.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: XML in LOCK <owner> tag should be self-contained
Thread-Index: AcJgvlX+Sea6dJ1yQa6YyukZNLvXrA==
From: "John Spaith" <jspaith@windows.microsoft.com>
To: <w3c-dist-auth@w3.org>
X-OriginalArrivalTime: 20 Sep 2002 15:56:51.0453 (UTC) FILETIME=[558382D0:01C260BE]
Subject: XML in LOCK <owner> tag should be self-contained
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6731
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>


This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C260BE.55624783"

------_=_NextPart_001_01C260BE.55624783
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Ladies and Gentleman,
=20
At the WebDAV interop fest, we saw that some servers weren't doing the
right thing when clients send them <owner> tags on a LOCK request.  When
doing a LOCK a client can put in XML in the owner tag, and this XML
often times has namespaces prefixes in it.  So we have something like...

=20
LOCK
=20
<xml>
 <lockinfo xmlns:MyNS=3D"MyNameSpace">
  [...]
   <owner>
      <MyNS:MyTag>...</MyNS:MyTag>
   </owner>
  [...]
=20
When the server returns this owner tag on a lockdiscovery, it has to
also return the definition of the MyNS namespace in the <owner> tags or
clients will choke on not recognizing MyNS prefix.  Having to keep track
of prefix mappings when parsing the LOCK body is an added piece of
complexity that servers don't really need.  It would be better if we
could require (or more likely strongly encourage) clients to make any
XML inside the <owner> tag work standalone, i.e. forcing them to define
any namespaces they use there.  They would send something like this on a
LOCK.
=20
 <owner>
   <MyNS:MyTag xmlns:MyNS=3D"MyNameSpace">...</MyNS:MyTag>
 </owner>
=20
This way the server could just keep a copy of the data between the
<owner> tags without any extra processing.
=20
Steps to increase interop:
1. Server implementers should be aware of this and code accordingly.  A
number of servers at the WebDAV interop fest only copied the data
between <owner> tags, not doing the extra name space processing.
=20
2. We should say something to the effect that clients SHOULD send
self-contained XML data with all the namespaces prefixes they used
defined between the <owner> tags to workaround servers that don't handle
this correctly.
=20
3. We should practice what we preach in the spec.  For instance in RFC
2518 example 8.10.8, we have <D:href> inside an <owner> tag that could
cause certain servers to have the problem described here.
=20
4. We should keep general scenario in mind when writing specs in the
future that involve one party saving XML with namespace tags in it from
another party, possibly saying that the client MUST send self-contained
XML.
=20
Alas, since RFC 2518 is a done-deal there's not much we can do on #3.
Issues #1 and #2 are mostly education issues for WebDAV client and
server implementers.  The main reason I'm writing this is for #4, so
that we can be aware of this scenario in the future.
=20
Thank you,
John Spaith
Software Design Engineer
Windows CE
Microsoft

------_=_NextPart_001_01C260BE.55624783
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2719.2200" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D917511418-19092002><FONT face=3DArial size=3D2>Ladies =
and=20
Gentleman,</FONT></SPAN></DIV>
<DIV><SPAN class=3D917511418-19092002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D917511418-19092002><FONT size=3D+0><FONT face=3DArial =
size=3D2>At the=20
WebDAV interop fest, we saw that some servers weren't doing the right =
thing when=20
clients send them &lt;owner&gt; tags on a LOCK request.&nbsp; When doing =
a LOCK=20
a client can put in XML in the owner tag, and this XML often times has=20
namespaces prefixes in it.&nbsp; So we have something like...</FONT>=20
<DIV><SPAN class=3D908173318-12092002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D908173318-12092002><FONT face=3DArial=20
size=3D2>LOCK</FONT></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D908173318-12092002><FONT face=3DArial=20
size=3D2>&lt;xml&gt;</FONT></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><FONT face=3DArial =
size=3D2>&nbsp;&lt;lockinfo=20
xmlns:MyNS=3D"MyNameSpace"&gt;</FONT></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><FONT face=3DArial size=3D2>&nbsp; =

[...]</FONT></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;=20
&lt;owner&gt;</FONT></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;MyNS:MyTag&gt;...&lt;/MyNS:MyTag&gt;</FONT></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;=20
&lt;/owner&gt;</FONT></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><FONT face=3DArial size=3D2>&nbsp; =

[...]</FONT></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D908173318-12092002><FONT face=3DArial size=3D2>When =
the server=20
returns this owner tag on a lockdiscovery, it has to also return the =
definition=20
of the MyNS namespace in the &lt;owner&gt; tags or client<SPAN=20
class=3D917511418-19092002>s</SPAN> will choke on not recognizing MyNS=20
prefix.<SPAN class=3D917511418-19092002>&nbsp;&nbsp;</SPAN><SPAN=20
class=3D917511418-19092002>Having to keep track of prefix mappings when =
parsing=20
the LOCK body is </SPAN><SPAN class=3D917511418-19092002>an added piece =
of=20
complexity that servers don't really need</SPAN>.&nbsp; It would be =
better if we=20
could require&nbsp;<SPAN class=3D917511418-19092002>(or more likely =
strongly=20
encourage) </SPAN>clients to make any XML<SPAN =
class=3D917511418-19092002>=20
</SPAN>inside the &lt;owner&gt; tag work standalone, i.e. forcing them =
to define=20
any namespaces they use there.&nbsp; They would send something like this =
on a=20
LOCK.</FONT></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D908173318-12092002><FONT face=3DArial=20
size=3D2>&nbsp;&lt;owner&gt;</FONT></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;=20
&lt;MyNS:MyTag=20
xmlns:MyNS=3D"MyNameSpace"&gt;...&lt;/MyNS:MyTag&gt;</FONT></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><FONT face=3DArial=20
size=3D2>&nbsp;&lt;/owner&gt;</FONT></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><FONT=20
face=3DArial size=3D2>This way the server could just keep a copy of the =
data between=20
the &lt;owner&gt; tags without any extra =
processing.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><FONT=20
face=3DArial size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><SPAN=20
class=3D917511418-19092002><FONT face=3DArial size=3D2>Steps to increase =

interop:</FONT></SPAN></SPAN></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><SPAN=20
class=3D917511418-19092002><FONT face=3DArial size=3D2>1. Server =
implementers should=20
be aware of this and code accordingly.&nbsp;&nbsp;A number of servers at =
the=20
WebDAV interop fest only copied the data between &lt;owner&gt; tags, not =
doing=20
the extra name space processing.</FONT></SPAN></SPAN></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><SPAN=20
class=3D917511418-19092002><FONT face=3DArial=20
size=3D2></FONT></SPAN></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><SPAN=20
class=3D917511418-19092002><FONT face=3DArial size=3D2>2. We should say =
something to=20
the effect that clients SHOULD send self-contained XML data with all the =

namespaces prefixes they used defined between the &lt;owner&gt; tags to=20
workaround servers that don't handle this=20
correctly.</FONT></SPAN></SPAN></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><FONT=20
face=3DArial size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><FONT=20
face=3DArial size=3D2><SPAN class=3D917511418-19092002>3. We should =
practice what we=20
preach in the spec.&nbsp; For instance in RFC 2518 example 8.10.8, we =
have=20
&lt;D:href&gt; inside an &lt;owner&gt; tag that could cause certain =
servers to=20
have the problem described here.</SPAN></FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><FONT=20
face=3DArial size=3D2><SPAN=20
class=3D917511418-19092002></SPAN></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><FONT=20
face=3DArial size=3D2><SPAN class=3D917511418-19092002>4. We should keep =
general=20
scenario in mind when writing specs in the future that involve one party =
saving=20
XML with namespace tags in it from another party, possibly saying that =
the=20
client MUST send self-contained XML.</SPAN></FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><FONT=20
face=3DArial size=3D2><SPAN=20
class=3D917511418-19092002></SPAN></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><FONT=20
face=3DArial size=3D2><SPAN=20
class=3D917511418-19092002></SPAN></FONT></SPAN></SPAN><SPAN=20
class=3D908173318-12092002><SPAN class=3D908173318-12092002><FONT =
face=3DArial=20
size=3D2><SPAN class=3D917511418-19092002>Alas, since RFC 2518 is a =
done-deal=20
there's not much we can do on #3.&nbsp; Issues #1 and #2 are mostly =
education=20
issues for WebDAV client and server implementers.&nbsp; The main reason =
I'm=20
writing this is for #4, so that we can be aware of this scenario in the=20
future.</SPAN></FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><FONT=20
face=3DArial size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><SPAN=20
class=3D917511418-19092002><FONT face=3DArial size=3D2>Thank=20
you,</FONT></SPAN></SPAN></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><SPAN=20
class=3D917511418-19092002><FONT face=3DArial size=3D2>John=20
Spaith</FONT></SPAN></SPAN></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><SPAN=20
class=3D917511418-19092002><FONT face=3DArial size=3D2>Software Design=20
Engineer</FONT></SPAN></SPAN></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><SPAN=20
class=3D917511418-19092002><FONT face=3DArial size=3D2>Windows=20
CE</FONT></SPAN></SPAN></SPAN></DIV>
<DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><SPAN=20
class=3D917511418-19092002><FONT face=3DArial=20
size=3D2>Microsoft</FONT></SPAN></SPAN></SPAN></DIV></FONT></SPAN></DIV><=
/BODY></HTML>
=00
------_=_NextPart_001_01C260BE.55624783--

--------------InterScan_NT_MIME_Boundary--



From w3c-dist-auth-request@w3.org  Fri Sep 20 13:11:26 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00100
	for <webdav-archive@lists.ietf.org>; Fri, 20 Sep 2002 13:11:26 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8KH28M16250;
	Fri, 20 Sep 2002 13:02:08 -0400 (EDT)
Resent-Date: Fri, 20 Sep 2002 13:02:08 -0400 (EDT)
Resent-Message-Id: <200209201702.g8KH28M16250@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8KH25B16189
	for <w3c-dist-auth@frink.w3.org>; Fri, 20 Sep 2002 13:02:05 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA10955
	for <w3c-dist-auth@w3.org>; Fri, 20 Sep 2002 13:02:04 -0400
Received: (qmail 22882 invoked by uid 0); 20 Sep 2002 17:01:33 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp018-rz3) with SMTP; 20 Sep 2002 17:01:33 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: <w3c-dist-auth@w3.org>
Date: Fri, 20 Sep 2002 19:01:32 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCMEEPFGAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <F8E386E0BEC2B942A525499AB0823EB84CAC0F@win-msg-06.wingroup.windeploy.ntdev.microsoft.com>
Subject: comments on RFC2518bis-02
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6732
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>
Content-Transfer-Encoding: 7bit


1) References to RFC2616

References have been updated to point to RFC2616 rather than RFC2068, but it
seems that all (most?) section numbers still need to be updated.


2) Section 4.4

Replace "MUST not" by "MUST NOT"


3) Section 4.6

I think this section needs to be deleted (it refers to the source link
stuff)


4) Section 6.3, p1

Replace

"A lock token is returned by every successful LOCK operation in the
lockdiscovery property in the response body, and can also be found through
lock discovery on a resource."

by

"A lock token is returned by every successful LOCK operation in the
lock-token header of the response, and can also be found through lock
discovery on a resource"


5) Section 6.3, p3

Replace

"However resources are free to return any URI scheme so long as it meets the
uniqueness requirements."

by

"However servers are free to use any IETF-registered URI scheme so long as
it meets the uniqueness requirements."


6) Section 8.1, p1 (use of XML)

Replace

"Some of the following new HTTP methods use XML as a request and response
format.  All DAV compliant clients and resources MUST use   XML parsers that
are compliant with [REC-XML].  All XML used in either requests or responses
MUST be, at minimum, well formed.  If a server receives ill-formed XML in a
request it MUST reject the entire request with a 400 (Bad Request)."

by

"Some of the following new HTTP methods use XML as a request and response
format.  All DAV compliant clients and resources MUST use   XML parsers that
are compliant with [REC-XML] and [REC-XML-NAMES].  All XML used in either
requests or responses MUST be, at minimum, well formed and
namespace-well-formed.  If a server receives ill-formed XML in a request it
MUST reject the entire request with a 400 (Bad Request)."


7) Section 8.1, p2 (required bodies)

says...: "In cases where a request body is present but would be ignored by a
server, the server MUST reject the request with 415 (Unsupported Media
Type)."

I don't understand this requirement. If a body isn't defined, it should be
ignored, right?


8) Section 8.1, p3 (required headers)

"Note that HTTP 1.1 requires the Date header in all responses." -> not
true - clockless origin servers are treated as a special case

"WebDAV servers MUST support ETags correctly and MUST return the ETag header
in all GET and PUT responses. " -> strong disagreement (see separate thread
on the mailing list)


9) Section 8.2

"URLs for collections appearing in the results MUST end in a '/'
character." -> I don't think we have consensus on this.

Furthermore, this section seems to attempt to define a subset of relative
URI resolution -- I think this is a VERY bad idea. Clients should properly
resolve URIs against the request URI -- if we must, we can simplify this
requirement by restricting the set of allowed relative URIs to those
starting with an absolute path.


10) Section 8.2.2

"The resource http://www.foo.bar/container/index.html, a member of the
"container" collection, has nine properties defined on it,
http://www.foo.bar/boxschema/bigbox, DAV:creationdate, DAV:displayname,
DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, DAV:getlastmodified,
DAV:resourcetype, and DAV:supportedlock." -> bad syntax for property names.

Also: the example for propfind/allprop is missing.


11) Section 8.3

"All DAV compliant resources MUST support the PROPPATCH method and MUST
process instructions that are specified using the propertyupdate, set, and
remove XML elements of the DAV schema" -> What is the "DAV schema"???

Also, replace

"Instruction processing MUST occur in the order instructions are received
(i.e., from top to bottom)"

by

"Instruction processing MUST occur in document order" (standard XML
processing term)


12) Section 8.7

Replace

"If an error occurs with a resource other than the resource identified in
the Request-URI then the response MUST be a 207 (Multi-Status), and the
errored resourceAs URL MUST appear with the specific error."

by

"If an error occurs with a resource other than the resource identified in
the Request-URI then the response MUST be a 207 (Multi-Status), and the URL
of the resource causing the failure MUST appear with the specific error."

(similar wording appears several times in later sections)

Also, replace

"424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi-Status)."

by

"424 (Failed Dependency) errors SHOULD NOT appear in the 207
(Multi-Status)."


13) Section 8.11, refreshing locks

"A locks is refreshed by sending a new LOCK request to the resource which is
the root of the lock."

Question: does it really need to be the root?


14)  Section 8.11, The Effect of Locks on Properties and Collections

"This means that if a collection is locked, its lock-token is required in
all these cases:
-	DELETE a collection's direct  internal member
-	MOVE a member out of the collection
-	MOVE a member into the collection, unless it overwrites a pre-existing
member"

I think the latter is not really consistent with RFC3253.


15) Section 8.11, Locking unmapped URLs

"A server MUST respond successfully to a GET request to an empty resource,
either by using a 204 No Content response, or by using 200 OK with a
Content-Length header indicating zero length and an server-determined
Content-Type."

Do not mention the content type at all. No content type is fine as well.


16) Section 8.11.2

Replace

"Lock-Token: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)"

by

"Lock-Token: <opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>"


17) Section 8.12

Replace

"A successful response to an UNLOCK method does not mean that the resource
is unlocked."

by

"A successful response to an UNLOCK method does not mean that there are no
locks left on the resource."

(at least I think this is the intent of the sentence, otherwise it needs to
be rephrased differently)



18) Section 9.1

I'd like to see the rational for the "extend" production.


19) Section 9.3

Language describing the process of relative URI resolution should go.


20) Section 9.4

See mailing list thread.


21) Section 11.4

Replace

" - The server does not ever accept this method on this kind of resource.
For example, a PUT is not accepted on a collection."

by

" - The server does not ever accept this method on this kind of resource.
For example, if a PUT is not accepted on a collection."


22) Section 11.5

I think that there are *many* more cases that can cause a 409 (see RFC3253)


23) Section 12

Again, an attempt to define relative URI resolution. Don't do that, just
refer to RFC2396 and say that URIs in a multistatus response are resolved
against the request URI.


24) Section 12.1

Proposal: add an example.


25) Section 13.4 (lockroot)

Proposal: only require it for deep locks.


26) Section 13.6

Replace:

"Identifies the associated resource as a collection. The resourcetype
property of a collection resource MUST have this value"

by

"Identifies the associated resource as a collection. The resourcetype
property of a collection resource MUST contain this element."


27) Section 13.16

Remove

"May contain additional elements not defined in this document."

That's true for *all* XML in request/response bodies (also reccurs in other
places)


28)  Section 13.24

Replace

"Language tagging information in the property's value (in the "xml:lang"
attribute, if present MUST be persistently stored along with the property,
and MUST be subsequently retrievable using PROPFIND."

by

"Language tagging information in scope of the property (in the "xml:lang"
attribute, if present MUST be persistently stored along with the property,
and MUST be subsequently retrievable using PROPFIND."


29) Section 13.26

Replace

"The allprop XML element specifies that all property names  and values on
the resource are to be returned."

by

"The allprop XML element specifies that all names and values of all dead
properties and the live properties defined by this document on the resource
are to be returned."


30) Section 14.7

"A change in a property SHOULD NOT cause the last-modified date to change,
because clients MAY rely on the last-modified date to know when to overwrite
the existing body."

I think this is a new requirement that hasn't been discussed. BTW: it's
inconsistent with the attempt to make ETags a MUST -- if you have Etags, you
don't have to rely on the last modified date anyway.


31) Section 18.6, Reduction of Security due to Source Link

can be removed


32) Section 19, IANA consideration (old text)

"URIs are used for both names, for several reasons. Assignment of a URI does
not require a request to a central naming authority, and hence allow WebDAV
property names and XML elements to be quickly defined by any WebDAV user or
application.  URIs also provide a unique address space, ensuring that the
distributed users of WebDAV will not have collisions among the property
names and XML elements they create"

This is wrong. Properties are NOT identified by URIs. They are identified by
XML QNames.




33) Editorial note

I think that removing the section numbers from the 3rd-level section names
is a bad idea.





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



From w3c-dist-auth-request@w3.org  Fri Sep 20 13:20:34 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00508
	for <webdav-archive@lists.ietf.org>; Fri, 20 Sep 2002 13:20:34 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8KHCug18306;
	Fri, 20 Sep 2002 13:12:56 -0400 (EDT)
Resent-Date: Fri, 20 Sep 2002 13:12:56 -0400 (EDT)
Resent-Message-Id: <200209201712.g8KHCug18306@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8KHCsB18235
	for <w3c-dist-auth@frink.w3.org>; Fri, 20 Sep 2002 13:12:54 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA14548
	for <w3c-dist-auth@w3.org>; Fri, 20 Sep 2002 13:12:53 -0400
Received: (qmail 24077 invoked by uid 0); 20 Sep 2002 17:12:22 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp009-rz3) with SMTP; 20 Sep 2002 17:12:22 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "John Spaith" <jspaith@windows.microsoft.com>, <w3c-dist-auth@w3.org>
Date: Fri, 20 Sep 2002 19:12:21 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCCEFBFGAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000B_01C260D9.A52A2E90"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <F8E386E0BEC2B942A525499AB0823EB84CAC0F@win-msg-06.wingroup.windeploy.ntdev.microsoft.com>
Subject: RE: XML in LOCK <owner> tag should be self-contained
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6733
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>


This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C260D9.A52A2E90
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

MessageI think this is identical to the problem of how faithfully the
namespace prefixes are preserved inside dead properties.

IMHO

- namespace information must be preserved (hopefully this is obvious)
- namespace prefixes on elements *inside* prooerty values should be
preserved
- namespace declarations that are needed but appeared outside the actual
property may be returned anywhere recreating the correct scope

This should then also apply the content of the DAV:owner element.

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

  -----Original Message-----
  From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of John Spaith
  Sent: Friday, September 20, 2002 5:57 PM
  To: w3c-dist-auth@w3.org
  Subject: XML in LOCK <owner> tag should be self-contained


  Ladies and Gentleman,

  At the WebDAV interop fest, we saw that some servers weren't doing the
right thing when clients send them <owner> tags on a LOCK request.  When
doing a LOCK a client can put in XML in the owner tag, and this XML often
times has namespaces prefixes in it.  So we have something like...

  LOCK

  <xml>
   <lockinfo xmlns:MyNS="MyNameSpace">
    [...]
     <owner>
        <MyNS:MyTag>...</MyNS:MyTag>
     </owner>
    [...]

  When the server returns this owner tag on a lockdiscovery, it has to also
return the definition of the MyNS namespace in the <owner> tags or clients
will choke on not recognizing MyNS prefix.  Having to keep track of prefix
mappings when parsing the LOCK body is an added piece of complexity that
servers don't really need.  It would be better if we could require (or more
likely strongly encourage) clients to make any XML inside the <owner> tag
work standalone, i.e. forcing them to define any namespaces they use there.
They would send something like this on a LOCK.

   <owner>
     <MyNS:MyTag xmlns:MyNS="MyNameSpace">...</MyNS:MyTag>
   </owner>

  This way the server could just keep a copy of the data between the <owner>
tags without any extra processing.

  Steps to increase interop:
  1. Server implementers should be aware of this and code accordingly.  A
number of servers at the WebDAV interop fest only copied the data between
<owner> tags, not doing the extra name space processing.

  2. We should say something to the effect that clients SHOULD send
self-contained XML data with all the namespaces prefixes they used defined
between the <owner> tags to workaround servers that don't handle this
correctly.

  3. We should practice what we preach in the spec.  For instance in RFC
2518 example 8.10.8, we have <D:href> inside an <owner> tag that could cause
certain servers to have the problem described here.

  4. We should keep general scenario in mind when writing specs in the
future that involve one party saving XML with namespace tags in it from
another party, possibly saying that the client MUST send self-contained XML.

  Alas, since RFC 2518 is a done-deal there's not much we can do on #3.
Issues #1 and #2 are mostly education issues for WebDAV client and server
implementers.  The main reason I'm writing this is for #4, so that we can be
aware of this scenario in the future.

  Thank you,
  John Spaith
  Software Design Engineer
  Windows CE
  Microsoft

------=_NextPart_000_000B_01C260D9.A52A2E90
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D666090917-20092002><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
think this is identical to the problem of how faithfully the namespace =
prefixes=20
are preserved inside dead properties.</FONT></SPAN></DIV>
<DIV><SPAN class=3D666090917-20092002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D666090917-20092002><FONT face=3DArial color=3D#0000ff =

size=3D2>IMHO</FONT></SPAN></DIV>
<DIV><SPAN class=3D666090917-20092002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D666090917-20092002><FONT face=3DArial color=3D#0000ff =
size=3D2>-=20
namespace information must be preserved (hopefully this is=20
obvious)</FONT></SPAN></DIV>
<DIV><SPAN class=3D666090917-20092002><FONT face=3DArial color=3D#0000ff =
size=3D2>-=20
namespace prefixes on elements *inside* prooerty values should be=20
preserved</FONT></SPAN></DIV>
<DIV><SPAN class=3D666090917-20092002><FONT face=3DArial color=3D#0000ff =
size=3D2>-=20
namespace declarations that are needed but appeared outside the actual =
property=20
may be returned anywhere recreating the correct =
scope</FONT></SPAN></DIV>
<DIV><SPAN class=3D666090917-20092002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D666090917-20092002><FONT face=3DArial color=3D#0000ff =
size=3D2>This=20
should then also apply the content of the DAV:owner =
element.</FONT></SPAN></DIV>
<DIV><SPAN class=3D666090917-20092002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D666090917-20092002><FONT face=3DArial color=3D#0000ff =

size=3D2>Julian</FONT></SPAN></DIV>
<P><FONT size=3D2>--<BR>&lt;green/&gt;bytes GmbH -- <A=20
href=3D"http://www.greenbytes.de/" =
target=3D_blank>http://www.greenbytes.de</A> --=20
tel:+492512807760 </FONT></P>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
w3c-dist-auth-request@w3.org=20
  [mailto:w3c-dist-auth-request@w3.org]<B>On Behalf Of </B>John=20
  Spaith<BR><B>Sent:</B> Friday, September 20, 2002 5:57 =
PM<BR><B>To:</B>=20
  w3c-dist-auth@w3.org<BR><B>Subject:</B> XML in LOCK &lt;owner&gt; tag =
should=20
  be self-contained<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D917511418-19092002><FONT face=3DArial =
size=3D2>Ladies and=20
  Gentleman,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D917511418-19092002><FONT face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D917511418-19092002><FONT size=3D+0><FONT =
face=3DArial size=3D2>At=20
  the WebDAV interop fest, we saw that some servers weren't doing the =
right=20
  thing when clients send them &lt;owner&gt; tags on a LOCK =
request.&nbsp; When=20
  doing a LOCK a client can put in XML in the owner tag, and this XML =
often=20
  times has namespaces prefixes in it.&nbsp; So we have something =
like...</FONT>=20

  <DIV><SPAN class=3D908173318-12092002><FONT face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D908173318-12092002><FONT face=3DArial=20
  size=3D2>LOCK</FONT></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><FONT face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D908173318-12092002><FONT face=3DArial=20
  size=3D2>&lt;xml&gt;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><FONT face=3DArial =
size=3D2>&nbsp;&lt;lockinfo=20
  xmlns:MyNS=3D"MyNameSpace"&gt;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><FONT face=3DArial =
size=3D2>&nbsp;=20
  [...]</FONT></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;=20
  &lt;owner&gt;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><FONT face=3DArial=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &lt;MyNS:MyTag&gt;...&lt;/MyNS:MyTag&gt;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;=20
  &lt;/owner&gt;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><FONT face=3DArial =
size=3D2>&nbsp;=20
  [...]</FONT></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><FONT face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D908173318-12092002><FONT face=3DArial size=3D2>When =
the server=20
  returns this owner tag on a lockdiscovery, it has to also return the=20
  definition of the MyNS namespace in the &lt;owner&gt; tags or =
client<SPAN=20
  class=3D917511418-19092002>s</SPAN> will choke on not recognizing MyNS =

  prefix.<SPAN class=3D917511418-19092002>&nbsp;&nbsp;</SPAN><SPAN=20
  class=3D917511418-19092002>Having to keep track of prefix mappings =
when parsing=20
  the LOCK body is </SPAN><SPAN class=3D917511418-19092002>an added =
piece of=20
  complexity that servers don't really need</SPAN>.&nbsp; It would be =
better if=20
  we could require&nbsp;<SPAN class=3D917511418-19092002>(or more likely =
strongly=20
  encourage) </SPAN>clients to make any XML<SPAN =
class=3D917511418-19092002>=20
  </SPAN>inside the &lt;owner&gt; tag work standalone, i.e. forcing them =
to=20
  define any namespaces they use there.&nbsp; They would send something =
like=20
  this on a LOCK.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><FONT face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D908173318-12092002><FONT face=3DArial=20
  size=3D2>&nbsp;&lt;owner&gt;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;=20
  &lt;MyNS:MyTag=20
  =
xmlns:MyNS=3D"MyNameSpace"&gt;...&lt;/MyNS:MyTag&gt;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><FONT face=3DArial=20
  size=3D2>&nbsp;&lt;/owner&gt;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><FONT face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><FONT=20
  face=3DArial size=3D2>This way the server could just keep a copy of =
the data=20
  between the &lt;owner&gt; tags without any extra=20
  processing.</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><FONT=20
  face=3DArial size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><SPAN=20
  class=3D917511418-19092002><FONT face=3DArial size=3D2>Steps to =
increase=20
  interop:</FONT></SPAN></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><SPAN=20
  class=3D917511418-19092002><FONT face=3DArial size=3D2>1. Server =
implementers should=20
  be aware of this and code accordingly.&nbsp;&nbsp;A number of servers =
at the=20
  WebDAV interop fest only copied the data between &lt;owner&gt; tags, =
not doing=20
  the extra name space processing.</FONT></SPAN></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><SPAN=20
  class=3D917511418-19092002><FONT face=3DArial=20
  size=3D2></FONT></SPAN></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><SPAN=20
  class=3D917511418-19092002><FONT face=3DArial size=3D2>2. We should =
say something to=20
  the effect that clients SHOULD send self-contained XML data with all =
the=20
  namespaces prefixes they used defined between the &lt;owner&gt; tags =
to=20
  workaround servers that don't handle this=20
  correctly.</FONT></SPAN></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><FONT=20
  face=3DArial size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><FONT=20
  face=3DArial size=3D2><SPAN class=3D917511418-19092002>3. We should =
practice what we=20
  preach in the spec.&nbsp; For instance in RFC 2518 example 8.10.8, we =
have=20
  &lt;D:href&gt; inside an &lt;owner&gt; tag that could cause certain =
servers to=20
  have the problem described here.</SPAN></FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><FONT=20
  face=3DArial size=3D2><SPAN=20
  class=3D917511418-19092002></SPAN></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><FONT=20
  face=3DArial size=3D2><SPAN class=3D917511418-19092002>4. We should =
keep general=20
  scenario in mind when writing specs in the future that involve one =
party=20
  saving XML with namespace tags in it from another party, possibly =
saying that=20
  the client MUST send self-contained =
XML.</SPAN></FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><FONT=20
  face=3DArial size=3D2><SPAN=20
  class=3D917511418-19092002></SPAN></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><FONT=20
  face=3DArial size=3D2><SPAN=20
  class=3D917511418-19092002></SPAN></FONT></SPAN></SPAN><SPAN=20
  class=3D908173318-12092002><SPAN class=3D908173318-12092002><FONT =
face=3DArial=20
  size=3D2><SPAN class=3D917511418-19092002>Alas, since RFC 2518 is a =
done-deal=20
  there's not much we can do on #3.&nbsp; Issues #1 and #2 are mostly =
education=20
  issues for WebDAV client and server implementers.&nbsp; The main =
reason I'm=20
  writing this is for #4, so that we can be aware of this scenario in =
the=20
  future.</SPAN></FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><FONT=20
  face=3DArial size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><SPAN=20
  class=3D917511418-19092002><FONT face=3DArial size=3D2>Thank=20
  you,</FONT></SPAN></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><SPAN=20
  class=3D917511418-19092002><FONT face=3DArial size=3D2>John=20
  Spaith</FONT></SPAN></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><SPAN=20
  class=3D917511418-19092002><FONT face=3DArial size=3D2>Software Design =

  Engineer</FONT></SPAN></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><SPAN=20
  class=3D917511418-19092002><FONT face=3DArial size=3D2>Windows=20
  CE</FONT></SPAN></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D908173318-12092002><SPAN =
class=3D908173318-12092002><SPAN=20
  class=3D917511418-19092002><FONT face=3DArial=20
  =
size=3D2>Microsoft</FONT></SPAN></SPAN></SPAN></DIV></FONT></SPAN></DIV><=
/BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_000B_01C260D9.A52A2E90--



From w3c-dist-auth-request@w3.org  Sat Sep 21 21:03:02 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19756
	for <webdav-archive@lists.ietf.org>; Sat, 21 Sep 2002 21:03:02 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8M0taZ28938;
	Sat, 21 Sep 2002 20:55:36 -0400 (EDT)
Resent-Date: Sat, 21 Sep 2002 20:55:36 -0400 (EDT)
Resent-Message-Id: <200209220055.g8M0taZ28938@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8M0tYB28906
	for <w3c-dist-auth@frink.w3.org>; Sat, 21 Sep 2002 20:55:34 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA15699
	for <w3c-dist-auth@w3.org>; Sat, 21 Sep 2002 20:55:30 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id RAA18664 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Sat, 21 Sep 2002 17:55:19 -0700
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by sunbelt.seagull.net (8.9.3) with ESMTP id RAA18642 sender obsfucated@us.ibm.com; Sat, 21 Sep 2002 17:55:18 -0700
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8M0slEv128236; Sat, 21 Sep 2002 20:54:47 -0400
Received: from d01ml233.pok.ibm.com (d01ml233.pok.ibm.com [9.56.224.56]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8M0siuu167784; Sat, 21 Sep 2002 20:54:44 -0400
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: w3c-dist-auth@w3.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF69E4488B.6A417B47-ON85256C3C.00029B95@pok.ibm.com>
From: "Jason Crawford" <nn683849@smallcue.com>
Date: Sat, 21 Sep 2002 20:39:31 -0400
X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.10 |March 22, 2002) at 09/21/2002 08:54:43 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: Re: comments on RFC2518bis-02, sec 13.16
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6734
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>


> 27) Section 13.16
>
> Remove
>
> "May contain additional elements not defined in this document."
>
> That's true for *all* XML in request/response bodies (also reccurs in
other
> places)

It's also said in 13.17.  I'd say leave it.



------------------------------------------
Phone: 914-784-7569





From w3c-dist-auth-request@w3.org  Sat Sep 21 21:23:38 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20025
	for <webdav-archive@lists.ietf.org>; Sat, 21 Sep 2002 21:23:38 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8M1H2B29896;
	Sat, 21 Sep 2002 21:17:02 -0400 (EDT)
Resent-Date: Sat, 21 Sep 2002 21:17:02 -0400 (EDT)
Resent-Message-Id: <200209220117.g8M1H2B29896@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8M1H1B29870
	for <w3c-dist-auth@frink.w3.org>; Sat, 21 Sep 2002 21:17:01 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA17800
	for <w3c-dist-auth@w3.org>; Sat, 21 Sep 2002 21:17:01 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id SAA21137 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Sat, 21 Sep 2002 18:17:00 -0700
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by sunbelt.seagull.net (8.9.3) with ESMTP id SAA21102 sender obsfucated@us.ibm.com; Sat, 21 Sep 2002 18:16:58 -0700
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8M1GREv238316; Sat, 21 Sep 2002 21:16:27 -0400
Received: from d01ml233.pok.ibm.com (d01ml233.pok.ibm.com [9.56.224.56]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8M1GOlf102614; Sat, 21 Sep 2002 21:16:24 -0400
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: w3c-dist-auth@w3.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF400ADCAF.0936079D-ON85256C3C.00048ECE@pok.ibm.com>
From: "Jason Crawford" <nn683849@smallcue.com>
Date: Sat, 21 Sep 2002 20:55:42 -0400
X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.10 |March 22, 2002) at 09/21/2002 09:16:24 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: Re: comments on RFC2518bis-02, sec 6.3
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6735
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>


> 5) Section 6.3, p3
>
> Replace
>
> "However resources are free to return any URI scheme so long as it meets
the
> uniqueness requirements."
>
> by
>
> "However servers are free to use any IETF-registered URI scheme so long
as
> it meets the uniqueness requirements."

? Is it important to be IETF registered ?



------------------------------------------
Phone: 914-784-7569





From w3c-dist-auth-request@w3.org  Sun Sep 22 06:24:22 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05416
	for <webdav-archive@lists.ietf.org>; Sun, 22 Sep 2002 06:24:22 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8MAOxb16498;
	Sun, 22 Sep 2002 06:24:59 -0400 (EDT)
Resent-Date: Sun, 22 Sep 2002 06:24:59 -0400 (EDT)
Resent-Message-Id: <200209221024.g8MAOxb16498@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8MAOvB16472
	for <w3c-dist-auth@frink.w3.org>; Sun, 22 Sep 2002 06:24:57 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id GAA14449
	for <w3c-dist-auth@w3.org>; Sun, 22 Sep 2002 06:24:57 -0400
Received: (qmail 20564 invoked by uid 0); 22 Sep 2002 10:24:26 -0000
Received: from p3ee2481b.dip.t-dialin.net (HELO lisa) (62.226.72.27)
  by mail.gmx.net (mp007-rz3) with SMTP; 22 Sep 2002 10:24:26 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Jason Crawford" <nn683849@smallcue.com>,
        "Julian Reschke" <julian.reschke@gmx.de>
Cc: <w3c-dist-auth@w3.org>
Date: Sun, 22 Sep 2002 12:24:18 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCAEGLFGAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <OF69E4488B.6A417B47-ON85256C3C.00029B95@pok.ibm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: comments on RFC2518bis-02, sec 13.16
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6736
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>
Content-Transfer-Encoding: 7bit


> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford
> Sent: Sunday, September 22, 2002 2:40 AM
> To: Julian Reschke
> Cc: w3c-dist-auth@w3.org
> Subject: Re: comments on RFC2518bis-02, sec 13.16
>
>
>
> > 27) Section 13.16
> >
> > Remove
> >
> > "May contain additional elements not defined in this document."
> >
> > That's true for *all* XML in request/response bodies (also reccurs in
> other
> > places)
>
> It's also said in 13.17.  I'd say leave it.

I think it's wrong. *All* XML elemens may be extended. If we only mention it
for specific element, people may read it saying that this is not the case
anymore.

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



From w3c-dist-auth-request@w3.org  Sun Sep 22 06:26:19 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05444
	for <webdav-archive@lists.ietf.org>; Sun, 22 Sep 2002 06:26:19 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8MAROm16854;
	Sun, 22 Sep 2002 06:27:24 -0400 (EDT)
Resent-Date: Sun, 22 Sep 2002 06:27:24 -0400 (EDT)
Resent-Message-Id: <200209221027.g8MAROm16854@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8MARNB16828
	for <w3c-dist-auth@frink.w3.org>; Sun, 22 Sep 2002 06:27:23 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id GAA14874
	for <w3c-dist-auth@w3.org>; Sun, 22 Sep 2002 06:27:23 -0400
Received: (qmail 3607 invoked by uid 0); 22 Sep 2002 10:26:52 -0000
Received: from p3ee2481b.dip.t-dialin.net (HELO lisa) (62.226.72.27)
  by mail.gmx.net (mp018-rz3) with SMTP; 22 Sep 2002 10:26:52 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Jason Crawford" <nn683849@smallcue.com>,
        "Julian Reschke" <julian.reschke@gmx.de>
Cc: <w3c-dist-auth@w3.org>
Date: Sun, 22 Sep 2002 12:26:45 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCEEGLFGAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <OF400ADCAF.0936079D-ON85256C3C.00048ECE@pok.ibm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: comments on RFC2518bis-02, sec 6.3
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6737
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>
Content-Transfer-Encoding: 7bit


> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford
> Sent: Sunday, September 22, 2002 2:56 AM
> To: Julian Reschke
> Cc: w3c-dist-auth@w3.org
> Subject: Re: comments on RFC2518bis-02, sec 6.3
>
>
>
> > 5) Section 6.3, p3
> >
> > Replace
> >
> > "However resources are free to return any URI scheme so long as it meets
> the
> > uniqueness requirements."
> >
> > by
> >
> > "However servers are free to use any IETF-registered URI scheme so long
> as
> > it meets the uniqueness requirements."
>
> ? Is it important to be IETF registered ?

Yes. A non-registered URI scheme doesn't have *any* guaranteed uniqueness,
so it doesn't serve it's stated purpose...

TAG:

http://www.w3.org/TR/2002/WD-webarch-20020830/#URI-scheme



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



From w3c-dist-auth-request@w3.org  Sun Sep 22 09:22:19 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07340
	for <webdav-archive@lists.ietf.org>; Sun, 22 Sep 2002 09:22:19 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8MDNCr03839;
	Sun, 22 Sep 2002 09:23:12 -0400 (EDT)
Resent-Date: Sun, 22 Sep 2002 09:23:12 -0400 (EDT)
Resent-Message-Id: <200209221323.g8MDNCr03839@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8MDNAB03792
	for <w3c-dist-auth@frink.w3.org>; Sun, 22 Sep 2002 09:23:10 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA05064
	for <w3c-dist-auth@w3.org>; Sun, 22 Sep 2002 09:23:10 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id GAA05247 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Sun, 22 Sep 2002 06:23:09 -0700
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by sunbelt.seagull.net (8.9.3) with ESMTP id GAA05231 sender obsfucated@us.ibm.com; Sun, 22 Sep 2002 06:23:08 -0700
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8MDMblN044754; Sun, 22 Sep 2002 09:22:37 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8MDMZRW067610; Sun, 22 Sep 2002 09:22:35 -0400
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: w3c-dist-auth@w3.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF878A6AA1.7278E0D1-ON85256C3C.0047833E@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Sun, 22 Sep 2002 09:12:19 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_09192002|September 19, 2002) at 09/22/2002 09:22:35
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: RE: comments on RFC2518bis-02, sec 13.16
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6738
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>





On Sunday, 09/22/2002 at 12:24 ZE2, "Julian Reschke"
<nnjulian.reschke___at___gmx.de@smallcue.com> wrote:
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford
> > Sent: Sunday, September 22, 2002 2:40 AM
> > To: Julian Reschke
> > Cc: w3c-dist-auth@w3.org
> > Subject: Re: comments on RFC2518bis-02, sec 13.16
> >
> >
> >
> > > 27) Section 13.16
> > >
> > > Remove
> > >
> > > "May contain additional elements not defined in this document."
> > >
> > > That's true for *all* XML in request/response bodies (also reccurs in
> > other
> > > places)
> >
> > It's also said in 13.17.  I'd say leave it.
>
> I think it's wrong. *All* XML elemens may be extended. If we only mention
it
> for specific element, people may read it saying that this is not the case
> anymore.

So how about adding "as with all XML elements"?   Or "as per [ref]"?
I just think it's a good idea to remind folks since they won't always be
aware
of this.  I believe there was even confusion on this list six months ago in
a
compatibility discussion involving the dav:source tag until this was
pointed
out.




From w3c-dist-auth-request@w3.org  Sun Sep 22 23:52:01 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18682
	for <webdav-archive@lists.ietf.org>; Sun, 22 Sep 2002 23:52:00 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8N3pxd14937;
	Sun, 22 Sep 2002 23:51:59 -0400 (EDT)
Resent-Date: Sun, 22 Sep 2002 23:51:59 -0400 (EDT)
Resent-Message-Id: <200209230351.g8N3pxd14937@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8N3pvB14882
	for <w3c-dist-auth@frink.w3.org>; Sun, 22 Sep 2002 23:51:57 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA04051
	for <w3c-dist-auth@w3c.org>; Sun, 22 Sep 2002 23:51:57 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id UAA15741 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Sun, 22 Sep 2002 20:51:54 -0700
Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by sunbelt.seagull.net (8.9.3) with ESMTP id UAA15705 sender obsfucated@us.ibm.com; Sun, 22 Sep 2002 20:51:51 -0700
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8N3pKlg018388; Sun, 22 Sep 2002 23:51:20 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8N3pJRX079458; Sun, 22 Sep 2002 23:51:19 -0400
To: "Clemm, Geoff" <gclemm@Rational.Com>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFA605B1CB.0A2D239C-ON85256C3D.000E6D14@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Sun, 22 Sep 2002 22:48:48 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_09192002|September 19, 2002) at 09/22/2002 23:51:17
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: RE: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6739
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>





> The problem: A client wants to check if the current user is
> authenticated to do an operation before it has that user provide the
> input for that operation, and before it performs expensive
> computations to set up the input for that request.

This seems to be a bit beyond our current scope.  But given the
solution to this is likely to be trivial, and some people seem to value
this, I can't protest much.


> The proposal: Document in the 2518bis that the authentication check
> SHOULD be performed before the If header check (so that a simple
> contradictory If header can be used to check the authentication for
> "dummy version" of the operation, i.e. one with dummy values that did
> not require user input or expensive calculations on the client).

I like this solution since it's probably a good thing in general to
indicate the order of header checking.  This will create consistancy
that should aid clients greatly in understanding responses.

I do recall we got into a very brief discussion of order of header
evaluation
a while back.  I forget what the topic was or what order we decided.  I
suggest
we go with your proposal and see if any problems turn up.

I can't say I'm a fan of use of NOT in a If: header  though.  :-)  But the
concept
of submitting a predictably false If header seems fine with me.




From w3c-dist-auth-request@w3.org  Sun Sep 22 23:52:03 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18696
	for <webdav-archive@lists.ietf.org>; Sun, 22 Sep 2002 23:52:03 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8N3q5315071;
	Sun, 22 Sep 2002 23:52:05 -0400 (EDT)
Resent-Date: Sun, 22 Sep 2002 23:52:05 -0400 (EDT)
Resent-Message-Id: <200209230352.g8N3q5315071@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8N3q0B14956
	for <w3c-dist-auth@frink.w3.org>; Sun, 22 Sep 2002 23:52:00 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA04057
	for <w3c-dist-auth@w3c.org>; Sun, 22 Sep 2002 23:51:58 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id UAA15842 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Sun, 22 Sep 2002 20:51:57 -0700
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by sunbelt.seagull.net (8.9.3) with ESMTP id UAA15702 sender obsfucated@us.ibm.com; Sun, 22 Sep 2002 20:51:51 -0700
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8N3pKlN117570; Sun, 22 Sep 2002 23:51:20 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8N3pIRY032590; Sun, 22 Sep 2002 23:51:19 -0400
To: "Dyer, Kevin" <kevin.dyer@matrixone.com>
Cc: "'Clemm, Geoff'" <gclemm@Rational.Com>, Webdav WG <w3c-dist-auth@w3c.org>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF8B93DAB0.CFBF8DFF-ON85256C3D.000D6AA0@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Sun, 22 Sep 2002 22:37:14 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_09192002|September 19, 2002) at 09/22/2002 23:51:17
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Subject: RE: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6741
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>





> With this as the problem statement, I believe that we need to look
outside of
> our own protocol here and take a look at one or more protocols that o=
nly
deal
> with the authentication and authorization of users and systems. Why d=
oes
WebDAV
> have to come up with the whole package themselves? If we look at the =
SAML

> specifications for a moment, it provides the ability to request from =
a
server
> what a particular user is asking for and get back a complete answer. =
Yes,
it is
> another call but the user is guaranteed to have a complete answer as =
to
> authentication and authorization across a large circle of influence. =
By
> adopting SAML as the back-end mechanism we will also pick up a true
single
> sign-on capability for WebDAV, something we've talked about and allud=
ed
to but
> have not considered it in the RFC.
>
> =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 Com=
ments, rocks, bottles, or stones?

SAML is probably pretty good, but our needs appear to be minimal (or le=
ss)
and
as you can see from Geoff's posting, providing that capability in some =
form
would
probably be trivial. That doesn't mean that clients shouldn't/can't use=

SAML.  They
can if they want.  But it's not something that is generally required to=

achieve the
WebDAV functionality and interoperability, at least not for
this problem,  so it probably doesn't need to go in the base WebDAV spe=
c.
=




From w3c-dist-auth-request@w3.org  Sun Sep 22 23:52:18 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18710
	for <webdav-archive@lists.ietf.org>; Sun, 22 Sep 2002 23:52:13 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8N3q2K15033;
	Sun, 22 Sep 2002 23:52:02 -0400 (EDT)
Resent-Date: Sun, 22 Sep 2002 23:52:02 -0400 (EDT)
Resent-Message-Id: <200209230352.g8N3q2K15033@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8N3q0B14944
	for <w3c-dist-auth@frink.w3.org>; Sun, 22 Sep 2002 23:52:00 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA04056
	for <w3c-dist-auth@w3c.org>; Sun, 22 Sep 2002 23:51:58 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id UAA15837 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Sun, 22 Sep 2002 20:51:57 -0700
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by sunbelt.seagull.net (8.9.3) with ESMTP id UAA15703 sender obsfucated@us.ibm.com; Sun, 22 Sep 2002 20:51:51 -0700
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8N3pKlN099634; Sun, 22 Sep 2002 23:51:20 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8N3pJRY079458; Sun, 22 Sep 2002 23:51:20 -0400
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Lisa Dusseault" <lisa@xythos.com>, "Webdav WG" <w3c-dist-auth@w3c.org>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFDD065666.58529C95-ON85256C3D.0011A605@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Sun, 22 Sep 2002 23:22:45 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_09192002|September 19, 2002) at 09/22/2002 23:51:17
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6740
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>





I just noticed that I hadn't weighed in on this subject.

I think over the months we've shown plenty of things that etags help with.
They are a good thing and their value is self evident.  But I don't think
this is a reason to REQUIRE them in the spec.  It will sometimes be
difficult to implement them and plenty can get done without them.  I think
they fall in the same category as locks.  They are a great thing and a
server that supports them is almost always a superior server, and clients
are free to refuse to work on servers that lack the capability, but we
should not REQUIRE support for them.

That's not to say that we can't make it very clear that they do provide
value and should be implemented if possible.  I think it's even fine to
have a section that outlines situations where etags are invaluable.

J.

------------------------------------------
Phone: 914-784-7569



From w3c-dist-auth-request@w3.org  Sun Sep 22 23:52:40 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18728
	for <webdav-archive@lists.ietf.org>; Sun, 22 Sep 2002 23:52:39 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8N3qAh15119;
	Sun, 22 Sep 2002 23:52:10 -0400 (EDT)
Resent-Date: Sun, 22 Sep 2002 23:52:10 -0400 (EDT)
Resent-Message-Id: <200209230352.g8N3qAh15119@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8N3q0B14961
	for <w3c-dist-auth@frink.w3.org>; Sun, 22 Sep 2002 23:52:00 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA04066
	for <w3c-dist-auth@w3.org>; Sun, 22 Sep 2002 23:52:00 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id UAA15836 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Sun, 22 Sep 2002 20:51:57 -0700
Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by sunbelt.seagull.net (8.9.3) with ESMTP id UAA15704 sender obsfucated@us.ibm.com; Sun, 22 Sep 2002 20:51:51 -0700
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8N3pKlg205172; Sun, 22 Sep 2002 23:51:20 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8N3pJRW079458; Sun, 22 Sep 2002 23:51:19 -0400
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "John Spaith" <jspaith@windows.microsoft.com>, w3c-dist-auth@w3.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF89F75DDA.9C3916BF-ON85256C3D.000C3724@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Sun, 22 Sep 2002 22:21:26 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_09192002|September 19, 2002) at 09/22/2002 23:51:16
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: RE: XML in LOCK <owner> tag should be self-contained
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6742
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>





I agree with Julian that this is covered in issue
DAVOWNER_FIELD_IS_CLIENT_CONTROLED which references issue PROP_ROUNDTRIP.

See http://www.webdav.org/wg/rfcdev/issues.htm

------------------------------------------
Phone: 914-784-7569



From w3c-dist-auth-request@w3.org  Mon Sep 23 02:35:52 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00478
	for <webdav-archive@lists.ietf.org>; Mon, 23 Sep 2002 02:35:52 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8N6aXg05787;
	Mon, 23 Sep 2002 02:36:33 -0400 (EDT)
Resent-Date: Mon, 23 Sep 2002 02:36:33 -0400 (EDT)
Resent-Message-Id: <200209230636.g8N6aXg05787@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8N6aVB05761
	for <w3c-dist-auth@frink.w3.org>; Mon, 23 Sep 2002 02:36:31 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id CAA31248
	for <w3c-dist-auth@w3.org>; Mon, 23 Sep 2002 02:36:31 -0400
Received: (qmail 11579 invoked by uid 0); 23 Sep 2002 06:36:00 -0000
Received: from p3ee24740.dip.t-dialin.net (HELO lisa) (62.226.71.64)
  by mail.gmx.net (mp001-rz3) with SMTP; 23 Sep 2002 06:36:00 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Jason Crawford" <nn683849@smallcue.com>, <w3c-dist-auth@w3.org>
Date: Mon, 23 Sep 2002 08:35:40 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCGEHKFGAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <OF878A6AA1.7278E0D1-ON85256C3C.0047833E@us.ibm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: comments on RFC2518bis-02, sec 13.16
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6743
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>
Content-Transfer-Encoding: 7bit


> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford
> Sent: Sunday, September 22, 2002 3:12 PM
> To: Julian Reschke
> Cc: w3c-dist-auth@w3.org
> Subject: RE: comments on RFC2518bis-02, sec 13.16
>
> ...
>
> So how about adding "as with all XML elements"?   Or "as per [ref]"?

Better.

> I just think it's a good idea to remind folks since they won't always be
> aware
> of this.  I believe there was even confusion on this list six
> months ago in
> a
> compatibility discussion involving the dav:source tag until this was
> pointed
> out.

I still dislike this because if it's mentioned in one place, people may
deduce that it says something about the cases where it doesn't.

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



From w3c-dist-auth-request@w3.org  Mon Sep 23 09:41:08 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08581
	for <webdav-archive@lists.ietf.org>; Mon, 23 Sep 2002 09:41:07 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8NDeRe17930;
	Mon, 23 Sep 2002 09:40:27 -0400 (EDT)
Resent-Date: Mon, 23 Sep 2002 09:40:27 -0400 (EDT)
Resent-Message-Id: <200209231340.g8NDeRe17930@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8NDeOB17851
	for <w3c-dist-auth@frink.w3.org>; Mon, 23 Sep 2002 09:40:24 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA04149
	for <w3c-dist-auth@w3.org>; Mon, 23 Sep 2002 09:40:24 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 23 Sep 2002 09:29:48 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <TDR3V42W>; Mon, 23 Sep 2002 09:39:49 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10841E077@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Mon, 23 Sep 2002 09:39:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: comments on RFC2518bis-02, sec 13.16
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6744
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>


   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   > From: Jason Crawford

   > So how about adding "as with all XML elements"?  Or "as per
   > [ref]"?  I just think it's a good idea to remind folks since they
   > won't always be aware of this.  I believe there was even
   > confusion on this list six months ago in a compatibility
   > discussion involving the dav:source tag until this was pointed
   > out.

   I still dislike this because if it's mentioned in one place, people
   may deduce that it says something about the cases where it doesn't.

I agree with Julian.  Picking a couple of spots to emphasize this
general rule could easily lead people to (mistakenly) conclude that
the rule is only important in those places.  I believe that the
original 2518 approach is better, i.e. state the general rule clearly
in one place.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Mon Sep 23 09:41:20 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08615
	for <webdav-archive@lists.ietf.org>; Mon, 23 Sep 2002 09:41:20 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8NDeXn17946;
	Mon, 23 Sep 2002 09:40:33 -0400 (EDT)
Resent-Date: Mon, 23 Sep 2002 09:40:33 -0400 (EDT)
Resent-Message-Id: <200209231340.g8NDeXn17946@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8NDeOB17873
	for <w3c-dist-auth@frink.w3.org>; Mon, 23 Sep 2002 09:40:24 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA04154
	for <w3c-dist-auth@w3.org>; Mon, 23 Sep 2002 09:40:24 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 23 Sep 2002 09:29:51 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <TDR3V42X>; Mon, 23 Sep 2002 09:39:52 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10841E078@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Mon, 23 Sep 2002 09:39:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: XML in LOCK <owner> tag should be self-contained
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6745
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>


I believe that in general we need to distinguish what the spec should
say to allow for client/server interop, and what a "interop guide"
should say about interoperating with poorly implemented clients or
servers.

For this particular thread, a client should be able to send legal
XML, especially since the client will often be using a generic
XML parsing/unparsing package that doesn't have provisions for 
"replicating" namespace declarations within certain nodes.

So I agree with suggestion 1 (i.e. servers should handle this case
correctly), and disagree with suggestions 2, 3, and 4.

To emphasize, I'm happy to have an "interop guide" document that tells
a client about this particular server bug, and how to workaround it,
but I would object to placing this language/advice in the protocol.  A
client should not be forced to work around server bugs (although it of
course is free to do so), and the spec should not be made more complex
or harder to implement just to provide interoperability with buggy
servers.

Cheers,
Geoff

   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   I think this is identical to the problem of how faithfully the
   namespace prefixes are preserved inside dead properties.

   IMHO

   - namespace information must be preserved (hopefully this is obvious)
   - namespace prefixes on elements *inside* property values should be
preserved
   - namespace declarations that are needed but appeared outside the actual
property may be returned anywhere recreating the correct scope

   This should then also apply the content of the DAV:owner element.

   From: John Spaith

   At the WebDAV interop fest, we saw that some servers weren't doing
   the right thing when clients send them <owner> tags on a LOCK
   request.  When doing a LOCK a client can put in XML in the owner
   tag, and this XML often times has namespaces prefixes in it.  So we
   have something like...

   LOCK

   <xml>
    <lockinfo xmlns:MyNS="MyNameSpace">
     [...]
      <owner>
	 <MyNS:MyTag>...</MyNS:MyTag>
      </owner>
     [...]

   When the server returns this owner tag on a lockdiscovery, it has
   to also return the definition of the MyNS namespace in the <owner>
   tags or clients will choke on not recognizing MyNS prefix.  Having
   to keep track of prefix mappings when parsing the LOCK body is an
   added piece of complexity that servers don't really need.  It would
   be better if we could require (or more likely strongly encourage)
   clients to make any XML inside the <owner> tag work standalone,
   i.e. forcing them to define any namespaces they use there.  They
   would send something like this on a LOCK.

    <owner>
      <MyNS:MyTag xmlns:MyNS="MyNameSpace">...</MyNS:MyTag>
    </owner>

   This way the server could just keep a copy of the data between the
   <owner> tags without any extra processing.

   Steps to increase interop:

   1. Server implementers should be aware of this and code
      accordingly.  A number of servers at the WebDAV interop fest
      only copied the data between <owner> tags, not doing the extra
      name space processing.

   2. We should say something to the effect that clients SHOULD send
      self-contained XML data with all the namespaces prefixes they
      used defined between the <owner> tags to workaround servers that
      don't handle this correctly.

   3. We should practice what we preach in the spec.  For instance in
      RFC 2518 example 8.10.8, we have <D:href> inside an <owner> tag
      that could cause certain servers to have the problem described
      here.

   4. We should keep general scenario in mind when writing specs in
      the future that involve one party saving XML with namespace tags
      in it from another party, possibly saying that the client MUST
      send self-contained XML.

   Alas, since RFC 2518 is a done-deal there's not much we can do on
   #3.  Issues #1 and #2 are mostly education issues for WebDAV client
   and server implementers.  The main reason I'm writing this is for
   #4, so that we can be aware of this scenario in the future.



From w3c-dist-auth-request@w3.org  Mon Sep 23 11:22:16 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12582
	for <webdav-archive@lists.ietf.org>; Mon, 23 Sep 2002 11:22:16 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8NFLbn06406;
	Mon, 23 Sep 2002 11:21:37 -0400 (EDT)
Resent-Date: Mon, 23 Sep 2002 11:21:37 -0400 (EDT)
Resent-Message-Id: <200209231521.g8NFLbn06406@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8NFLaB06374
	for <w3c-dist-auth@frink.w3.org>; Mon, 23 Sep 2002 11:21:36 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA03347
	for <w3c-dist-auth@w3.org>; Mon, 23 Sep 2002 11:21:23 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id IAA08275 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Mon, 23 Sep 2002 08:21:09 -0700
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by sunbelt.seagull.net (8.9.3) with ESMTP id IAA08222 sender obsfucated@us.ibm.com; Mon, 23 Sep 2002 08:20:43 -0700
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8NFJ1Ev328756; Mon, 23 Sep 2002 11:19:01 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8NFIxOt079464; Mon, 23 Sep 2002 11:18:59 -0400
To: "Clemm, Geoff" <gclemm@Rational.Com>
Cc: w3c-dist-auth@w3.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF38CCFCE3.BBF47486-ON85256C3D.0052CF40@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Mon, 23 Sep 2002 11:05:18 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_09192002|September 19, 2002) at 09/23/2002 11:18:59
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: RE: comments on RFC2518bis-02, sec 13.16
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6746
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>





<<
I agree with Julian.  Picking a couple of spots to emphasize this
general rule could easily lead people to (mistakenly) conclude that
the rule is only important in those places.  I believe that the
original 2518 approach is better, i.e. state the general rule clearly
in one place.
>>
Agreed.  Saying it on one place is the best approach.

------------------------------------------
Phone: 914-784-7569



From w3c-dist-auth-request@w3.org  Mon Sep 23 17:52:43 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26622
	for <webdav-archive@lists.ietf.org>; Mon, 23 Sep 2002 17:52:43 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8NLrV129395;
	Mon, 23 Sep 2002 17:53:31 -0400 (EDT)
Resent-Date: Mon, 23 Sep 2002 17:53:31 -0400 (EDT)
Resent-Message-Id: <200209232153.g8NLrV129395@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8NLrSB29369
	for <w3c-dist-auth@frink.w3.org>; Mon, 23 Sep 2002 17:53:28 -0400 (EDT)
Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA25207
	for <w3c-dist-auth@w3c.org>; Mon, 23 Sep 2002 17:53:27 -0400
Received: from inet-mail1.oracle.com (localhost [127.0.0.1])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8NLque29697
	for <w3c-dist-auth@w3c.org>; Mon, 23 Sep 2002 14:52:57 -0700 (PDT)
Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15])
	by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g8NLqsC29672;
	Mon, 23 Sep 2002 14:52:54 -0700 (PDT)
Received: from oracle.com (ikirnos-pc.us.oracle.com [130.35.68.81])
	by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g8NLqrj02843;
	Mon, 23 Sep 2002 15:52:53 -0600 (MDT)
Message-ID: <3D8F8DB7.4214CB74@oracle.com>
Date: Mon, 23 Sep 2002 14:55:03 -0700
From: Ilya Kirnos <ilya.kirnos@oracle.com>
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jason Crawford <nn683849@smallcue.com>
CC: "Clemm, Geoff" <gclemm@Rational.Com>, Webdav WG <w3c-dist-auth@w3c.org>,
        Lisa Dusseault <lisa@xythos.com>
References: <OFA605B1CB.0A2D239C-ON85256C3D.000E6D14@us.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Interop issue: how can clients force authentication?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6747
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>
Content-Transfer-Encoding: 7bit


sounds like we've got a proposal that there's some agreement on.

lisa, what's the next step for getting this into the spec?

thanks.

-ilya



Jason Crawford wrote:

> > The problem: A client wants to check if the current user is
> > authenticated to do an operation before it has that user provide the
> > input for that operation, and before it performs expensive
> > computations to set up the input for that request.
>
> This seems to be a bit beyond our current scope.  But given the
> solution to this is likely to be trivial, and some people seem to value
> this, I can't protest much.
>
> > The proposal: Document in the 2518bis that the authentication check
> > SHOULD be performed before the If header check (so that a simple
> > contradictory If header can be used to check the authentication for
> > "dummy version" of the operation, i.e. one with dummy values that did
> > not require user input or expensive calculations on the client).
>
> I like this solution since it's probably a good thing in general to
> indicate the order of header checking.  This will create consistancy
> that should aid clients greatly in understanding responses.
>
> I do recall we got into a very brief discussion of order of header
> evaluation
> a while back.  I forget what the topic was or what order we decided.  I
> suggest
> we go with your proposal and see if any problems turn up.
>
> I can't say I'm a fan of use of NOT in a If: header  though.  :-)  But the
> concept
> of submitting a predictably false If header seems fine with me.



From w3c-dist-auth-request@w3.org  Mon Sep 23 19:33:19 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29289
	for <webdav-archive@lists.ietf.org>; Mon, 23 Sep 2002 19:33:18 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8NNY5Q08794;
	Mon, 23 Sep 2002 19:34:05 -0400 (EDT)
Resent-Date: Mon, 23 Sep 2002 19:34:05 -0400 (EDT)
Resent-Message-Id: <200209232334.g8NNY5Q08794@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8NNY2B08764
	for <w3c-dist-auth@frink.w3.org>; Mon, 23 Sep 2002 19:34:02 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA09134
	for <w3c-dist-auth@w3c.org>; Mon, 23 Sep 2002 19:33:57 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id QAA19521 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Mon, 23 Sep 2002 16:33:43 -0700
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by sunbelt.seagull.net (8.9.3) with ESMTP id QAA19391 sender obsfucated@us.ibm.com; Mon, 23 Sep 2002 16:32:19 -0700
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8NNV6vI159788; Mon, 23 Sep 2002 19:31:07 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8NNV4r0044148; Mon, 23 Sep 2002 19:31:04 -0400
To: "Clemm, Geoff" <gclemm@Rational.Com>
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFDE4294DA.56D4AE1C-ON85256C3D.007B87DA@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Mon, 23 Sep 2002 19:13:23 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_09192002|September 19, 2002) at 09/23/2002 19:31:04
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: RE: Issue: Requiring server to use / terminated URL for returned collections
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6748
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>





Wow.  What a discussion this has been.   I'll try to pull this together.  I
can't claim to have understood everything said since some comments were
terse and were not followed up.

There has been a statement that there is an interoperability issue with not
having the server always return a trailing slash when refering to a
collection.   Apparently there were true interoperability problems, but no
hard interoperability problems were brought up in the discussion except as
noted below.

Geoff admitted that it is helpful for a client/server to use the slash for
GET requests to collections because it creates the possibility of just
returning the content of the ./index.html file (for example) without a
redirect.   (Otherwise the relative URL's inside the index.html file might
need to be fixed up.)   There was some additional discussion that the
redirect might not even be necessary if browsers better supported the
Content-Location header.  (Perhaps we need to get the attention of some
teams writing some browsers?)

Geoff asserted that it can be expensive for a server to determine if a
non-slash terminated URL maps to a collection or not.  He'd rather not have
to make that calculation unless explicitly required.   Some folks expressed
the thinking that hopefully that cost can be avoided by techniques and that
making a second request to the server clearly has a performance price.
Geoff asserted that (in my words, not his) that the second request
(PROPFIND) is probably necessary anyway if any other information is needed.

It was asserted that the server should at least be consistant in what it
returns.  Although no detail on this point was provided I think the point
was that a server shouldn't be passing a mixture of slash terminated and
non-terminated URL's for the same resource.  By doing so it leaves the
client to notice and assume at some risk  that they are really the same
resource.  (An example might help make this case.)

No one has protested the returning of the terminating slash.  There was
just some protesting that it be required.

As far as I know, and I know there had previously been discussion that
would violate this assertion, if the server sends a URL with a terminating
slash, the client can assume there is a collection at that location.  If
this assertion remains true, the server returning this slash when accessed
by a client that leverages this insight, can appear to be a more responsive
server than one that doesn't return the trailing slash.

I think the remaining issues are...

Were there truly some interop issues with not always returning a trailing
slash?  What were they?  Would a requirement of consistancy work just as
well as requiring a terminating slash?

Certain broken behaviors in existing clients/servers was mentioned.  What
products, people, etc do we need to follow up with?

Can a client assume that, if a server returns a URL that ends in a slash,
the resource referenced is a collection?





------------------------------------------
Phone: 914-784-7569



From w3c-dist-auth-request@w3.org  Tue Sep 24 15:32:31 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10032
	for <webdav-archive@lists.ietf.org>; Tue, 24 Sep 2002 15:32:31 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8OJWsJ08051;
	Tue, 24 Sep 2002 15:32:54 -0400 (EDT)
Resent-Date: Tue, 24 Sep 2002 15:32:54 -0400 (EDT)
Resent-Message-Id: <200209241932.g8OJWsJ08051@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8OJWpB08025
	for <w3c-dist-auth@frink.w3.org>; Tue, 24 Sep 2002 15:32:51 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA08504
	for <w3c-dist-auth@w3c.org>; Tue, 24 Sep 2002 15:32:41 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id MAA11452 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Tue, 24 Sep 2002 12:32:33 -0700
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by sunbelt.seagull.net (8.9.3) with ESMTP id MAA11435 sender obsfucated@us.ibm.com; Tue, 24 Sep 2002 12:32:27 -0700
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8OJVtEv139274; Tue, 24 Sep 2002 15:31:55 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8OJVrLK065164; Tue, 24 Sep 2002 15:31:53 -0400
To: "Lisa Dusseault" <lisa@xythos.com>
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF905B94D0.1F65D129-ON85256C3E.0069DFFC@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Tue, 24 Sep 2002 15:27:58 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_09192002|September 19, 2002) at 09/24/2002 15:31:52
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: Re: Interop issue: Proposal for fixing lock token provision
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6749
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>





This thread seemed to get overlooked, so I want to get discussion going on
it...

On Sunday, 09/15/2002 at 11:31 MST, "Lisa Dusseault" wrote:
> At this week's Interop event, as at last year's, many interoperability
> problems were found with scenarios involving change methods where a lock
> token is required.  A long, animated, exciting conversation was held to
> finally achieve  consensus among attendees on goals for a new way to
> supply lock tokens to servers.
>
> GOALS for Lock Token Provision
> ------------------------------
>
> 1. Clients should be able to provide lock tokens in conditional requests
> that cause the request to fail if the token does not still match the
> state. This goal is currently met by the If header, but this goal must
> continue to be met by any new solution.
>
> 2. Clients should ALSO be able to provide multiple unqualified lock
> tokens in order to prove that they have those tokens and can do write
> requests legally, in a way that does not impose conditions on the
> success of the request. This mechanism should not use or affect the
> Lock-Token header which is required in UNLOCK to specify a single lock
> token to remove or refresh. This mechanism should be capable of
> supporting many values.
>
> 3. Servers should be able to inform clients when lock tokens being used
> in any way are no longer valid.   This helps clients keep their
> understanding of the server's state up-to-date.

I basically agree with (1) and (2).  I value keeping the server driven
submission
of tokens seperate from client driven consistancy checks.  Hopefully this
will
simplify the If: header semantics.

(3) is new to me.  I'd like to hear more discussion on it.  Perhaps as a
seperate
thread.


> Discussions on how to solve
> ---------------------------
>
> 1. Already solved by If header. Only slight clarifications needed to
> improve basic interoperability of this header (see below).

OK

> 2. The mechanism to provide multiple tokens could easily be a new
> header. The syntax should involve comma-separated values, because then
> lines can be split across multiple instances of the header according to
> RFC2616 header rules.

OK.  I can see how that can be implemented without breaking compatibility.


> 3. A new response header or two could allow servers to return invalid or
> unnecessary lock tokens.  This should be a response header so that the
> information can easily be marshaled even on responses that already
> contain a body. Again, the response header syntax should be
> comma-separated.

I'd like to hear more about the requirement for this.


>
> Slight changes to existing definitions
> --------------------------------------
>
> - The existing Lock-Token header is used to specify a single lock token,
> in methods that must operate on a single lock.  It is used on UNLOCK to
> remove a lock.  The LOCK refresh request should ALSO use this header
> (and the If header should continue to be supported by servers in order
> to handle existing clients).  This includes the clarification that LOCK
> refresh can only be used to refresh a single lock.  That's a good thing,
> because the Timeout header only exists once per request too.

OK with me.


>  - An untagged token in the IF header should apply ONLY to the resource
> named in the Request-URI.  The original definition is that they apply to
> any resources "affected" by the request. This has turned out to be too
> ambiguous and arduous to determine.  Also most lock tokens only apply to
> one resource, not the entire set of resources "affected" by a request
> like MOVE/COPY. Since any token in the IF header can be tagged with a
> URL in order to make it explicit what resource the token refers to, we
> can make the untagged token equally explicit without removing any client
> functionality in the If header.

OK.

So what do other people have to say?

J.

------------------------------------------
Phone: 914-784-7569



From w3c-dist-auth-request@w3.org  Wed Sep 25 10:52:04 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28311
	for <webdav-archive@lists.ietf.org>; Wed, 25 Sep 2002 10:52:03 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8PEbNE03660;
	Wed, 25 Sep 2002 10:37:23 -0400 (EDT)
Resent-Date: Wed, 25 Sep 2002 10:37:23 -0400 (EDT)
Resent-Message-Id: <200209251437.g8PEbNE03660@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8PEbKB03634
	for <w3c-dist-auth@frink.w3.org>; Wed, 25 Sep 2002 10:37:20 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA05202
	for <w3c-dist-auth@w3c.org>; Wed, 25 Sep 2002 10:37:18 -0400
Received: from greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3c.org>; Wed, 25 Sep 2002 16:36:54 +0200
Date: Wed, 25 Sep 2002 16:36:54 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: "Lisa Dusseault" <lisa@xythos.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
To: Jason Crawford <nn683849@smallcue.com>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <OF905B94D0.1F65D129-ON85256C3E.0069DFFC@us.ibm.com>
Message-Id: <3C948226-D094-11D6-BF8C-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: Interop issue: Proposal for fixing lock token provision
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6750
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>
Content-Transfer-Encoding: 7bit



Am Dienstag, 24.09.02, um 21:27 Uhr (Europe/Berlin) schrieb Jason 
Crawford:

> This thread seemed to get overlooked, so I want to get discussion 
> going on
> it...
>
> On Sunday, 09/15/2002 at 11:31 MST, "Lisa Dusseault" wrote:
>> At this week's Interop event, as at last year's, many interoperability
>> problems were found with scenarios involving change methods where a 
>> lock
>> token is required.  A long, animated, exciting conversation was held 
>> to
>> finally achieve  consensus among attendees on goals for a new way to
>> supply lock tokens to servers.
>>
>> GOALS for Lock Token Provision
>> ------------------------------
>>
>> 1. Clients should be able to provide lock tokens in conditional 
>> requests
>> that cause the request to fail if the token does not still match the
>> state. This goal is currently met by the If header, but this goal must
>> continue to be met by any new solution.
>>
>> 2. Clients should ALSO be able to provide multiple unqualified lock
>> tokens in order to prove that they have those tokens and can do write
>> requests legally, in a way that does not impose conditions on the
>> success of the request. This mechanism should not use or affect the
>> Lock-Token header which is required in UNLOCK to specify a single lock
>> token to remove or refresh. This mechanism should be capable of
>> supporting many values.
>>
>> 3. Servers should be able to inform clients when lock tokens being 
>> used
>> in any way are no longer valid.   This helps clients keep their
>> understanding of the server's state up-to-date.
>
> I basically agree with (1) and (2).  I value keeping the server driven
> submission
> of tokens seperate from client driven consistancy checks.  Hopefully 
> this
> will
> simplify the If: header semantics.
>
> (3) is new to me.  I'd like to hear more discussion on it.  Perhaps as 
> a
> seperate
> thread.

Without having been present at the meeting, I undestand item (3) like
this:

If a client does not bother with the If: header any longer and only uses
the new, to-be-defined header, it will never notice that locks have
expired. If the server returns the invalid lock tokens, the client
does not have to check itself.

That's how I understand it. I have not thought through if I like
the idea, though.

Now for (2): Except for the "unqualified" part, this can be expressed
with current If header syntax as

If: <resource-uri>(<lock-token>)(Not<lock-token>)

I'm not sure wether we need the unqualified part. It would be nice
thought to bring "comma support" into If header so that there can
be multiple If header lines in a request. Does anyone see a possibility
for this?

>
>> Discussions on how to solve
>> ---------------------------
>>
>> 1. Already solved by If header. Only slight clarifications needed to
>> improve basic interoperability of this header (see below).
>
> OK
>
>> 2. The mechanism to provide multiple tokens could easily be a new
>> header. The syntax should involve comma-separated values, because then
>> lines can be split across multiple instances of the header according 
>> to
>> RFC2616 header rules.
>
> OK.  I can see how that can be implemented without breaking 
> compatibility.
>
>
>> 3. A new response header or two could allow servers to return invalid 
>> or
>> unnecessary lock tokens.  This should be a response header so that the
>> information can easily be marshaled even on responses that already
>> contain a body. Again, the response header syntax should be
>> comma-separated.
>
> I'd like to hear more about the requirement for this.

See my explanation above.

>
>>
>> Slight changes to existing definitions
>> --------------------------------------
>>
>> - The existing Lock-Token header is used to specify a single lock 
>> token,
>> in methods that must operate on a single lock.  It is used on UNLOCK 
>> to
>> remove a lock.  The LOCK refresh request should ALSO use this header
>> (and the If header should continue to be supported by servers in order
>> to handle existing clients).  This includes the clarification that 
>> LOCK
>> refresh can only be used to refresh a single lock.  That's a good 
>> thing,
>> because the Timeout header only exists once per request too.
>
> OK with me.

dito.

>
>>  - An untagged token in the IF header should apply ONLY to the 
>> resource
>> named in the Request-URI.  The original definition is that they apply 
>> to
>> any resources "affected" by the request. This has turned out to be too
>> ambiguous and arduous to determine.  Also most lock tokens only apply 
>> to
>> one resource, not the entire set of resources "affected" by a request
>> like MOVE/COPY. Since any token in the IF header can be tagged with a
>> URL in order to make it explicit what resource the token refers to, we
>> can make the untagged token equally explicit without removing any 
>> client
>> functionality in the If header.
>
> OK.

It's good to clarify this. My client stumbled over different
server interpretations for COPY. It's never clear if an unqualified
token identifies the request resource, its children or even also the
destination resource as well. I refrain from using unqualified tokens.

So, I'd say this clarification is needed.

//Stefan





From w3c-dist-auth-request@w3.org  Wed Sep 25 12:03:55 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00674
	for <webdav-archive@lists.ietf.org>; Wed, 25 Sep 2002 12:03:55 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8PFnV725608;
	Wed, 25 Sep 2002 11:49:31 -0400 (EDT)
Resent-Date: Wed, 25 Sep 2002 11:49:31 -0400 (EDT)
Resent-Message-Id: <200209251549.g8PFnV725608@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8PFnTB25582
	for <w3c-dist-auth@frink.w3.org>; Wed, 25 Sep 2002 11:49:29 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA25283
	for <w3c-dist-auth@w3c.org>; Wed, 25 Sep 2002 11:49:29 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 25 Sep 2002 11:38:37 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <TRMH76CD>; Wed, 25 Sep 2002 11:48:35 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1085A8F17@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Wed, 25 Sep 2002 11:48:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C264AA.FF843EB0"
Subject: RE: Issue: Requiring server to use / terminated URL for returned  	collections
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6751
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>


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

------_=_NextPart_001_01C264AA.FF843EB0
Content-Type: text/plain

   From: Jason Crawford [mailto:nn683849@smallcue.com]

   I think the remaining issues are...

   Were there truly some interop issues with not always returning a
   trailing slash?  What were they?  Would a requirement of
   consistancy work just as well as requiring a terminating slash?

   Certain broken behaviors in existing clients/servers was mentioned.
   What products, people, etc do we need to follow up with?

   Can a client assume that, if a server returns a URL that ends in a
   slash, the resource referenced is a collection?

I would have no problem with that requirement, if it can be 
demonstrated to have significant client value.

Cheers,
Geoff

------_=_NextPart_001_01C264AA.FF843EB0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: Issue: Requiring server to use / terminated URL for returned collections</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&nbsp;&nbsp; From: Jason Crawford [<A HREF="mailto:nn683849@smallcue.com">mailto:nn683849@smallcue.com</A>]</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; I think the remaining issues are...</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; Were there truly some interop issues with not always returning a</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; trailing slash?&nbsp; What were they?&nbsp; Would a requirement of</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; consistancy work just as well as requiring a terminating slash?</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; Certain broken behaviors in existing clients/servers was mentioned.</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; What products, people, etc do we need to follow up with?</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; Can a client assume that, if a server returns a URL that ends in a</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; slash, the resource referenced is a collection?</FONT>
</P>

<P><FONT SIZE=2>I would have no problem with that requirement, if it can be </FONT>
<BR><FONT SIZE=2>demonstrated to have significant client value.</FONT>
</P>

<P><FONT SIZE=2>Cheers,</FONT>
<BR><FONT SIZE=2>Geoff</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C264AA.FF843EB0--



From w3c-dist-auth-request@w3.org  Wed Sep 25 13:46:56 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04266
	for <webdav-archive@lists.ietf.org>; Wed, 25 Sep 2002 13:46:55 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8PHlPg21514;
	Wed, 25 Sep 2002 13:47:25 -0400 (EDT)
Resent-Date: Wed, 25 Sep 2002 13:47:25 -0400 (EDT)
Resent-Message-Id: <200209251747.g8PHlPg21514@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8PHlMB21484
	for <w3c-dist-auth@frink.w3.org>; Wed, 25 Sep 2002 13:47:22 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA21780
	for <w3c-dist-auth@w3c.org>; Wed, 25 Sep 2002 13:47:08 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id KAA05102 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Wed, 25 Sep 2002 10:47:00 -0700
Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by sunbelt.seagull.net (8.9.3) with ESMTP id KAA05079 sender obsfucated@us.ibm.com; Wed, 25 Sep 2002 10:46:58 -0700
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8PHkRGb159408; Wed, 25 Sep 2002 13:46:27 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8PHkPw2025066; Wed, 25 Sep 2002 13:46:25 -0400
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: "Lisa Dusseault" <lisa@xythos.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF305F2C6E.6524134D-ON85256C3F.00514403@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Wed, 25 Sep 2002 13:41:22 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_09232002|September 23, 2002) at 09/25/2002 13:46:24
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: Re: Interop issue: Proposal for fixing lock token provision
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6752
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>





On Wednesday, 09/25/2002 at 04:36 ZE2, Stefan Eissing  wrote:
> Am Dienstag, 24.09.02, um 21:27 Uhr (Europe/Berlin) schrieb Jason
> Crawford:
>
> >> 2. Clients should ALSO be able to provide multiple unqualified lock
> >> tokens in order to prove that they have those tokens and can do write
> >> requests legally, in a way that does not impose conditions on the
> >> success of the request. This mechanism should not use or affect the
> >> Lock-Token header which is required in UNLOCK to specify a single lock
> >> token to remove or refresh. This mechanism should be capable of
> >> supporting many values.
> >>
> >> ...
> Now for (2): Except for the "unqualified" part, this can be expressed
> with current If header syntax as
> ...

I think part of their point here was that they want to seperate the
submission of lock tokens to satisfy the server's enforcement of
locking rules  from the clients' submission of pre-reqs for the
request   One type of submission (tokens) is pretty simple.
The other (conditional expressions) is not quite as simple.  But in
combination in the same header it makes for messy semantics.
For that reason, the If: header wasn't advocated for (2).   At least that's
what
I assume based on previous  discussions.


------------------------------------------
Phone: 914-784-7569



From w3c-dist-auth-request@w3.org  Thu Sep 26 14:26:57 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17318
	for <webdav-archive@lists.ietf.org>; Thu, 26 Sep 2002 14:26:57 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8QIRi610001;
	Thu, 26 Sep 2002 14:27:44 -0400 (EDT)
Resent-Date: Thu, 26 Sep 2002 14:27:44 -0400 (EDT)
Resent-Message-Id: <200209261827.g8QIRi610001@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8QIReB09939
	for <w3c-dist-auth@frink.w3.org>; Thu, 26 Sep 2002 14:27:40 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA24481;
	Thu, 26 Sep 2002 14:27:40 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 26 Sep 2002 14:17:01 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <TRMH0JMJ>; Thu, 26 Sep 2002 14:27:10 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B107839285@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "WebDAV (E-mail)" <w3c-dist-auth@w3.org>, ietf-dav-versioning@w3.org
Date: Thu, 26 Sep 2002 14:27:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2658A.54A35E00"
Subject: Required properties with no value [WAS: workspace property on res 	ources that aren't in workspaces]
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6753
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>


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

------_=_NextPart_001_01C2658A.54A35E00
Content-Type: text/plain;
	charset="iso-8859-1"

This is a good question, and it applies to any "required" property that
sometimes has "no value" (e.g. DAV:checked-in and DAV:checked-out).

So this question probably should be answered in 2518bis (I'll forward
this message to the WebDAV list), but we certainly could take a stab
at it in the DeltaV context first.

Like Julian, I'd probably be inclined to "b", but don't feel strongly
either way.  Anyone prefer "a", prefer to decide separately for each
property, or prefer that we leave it up to the server?

Cheers,
Geoff

   From: Julian Reschke [mailto:julian.reschke@greenbytes.de]

   section 6.2.1 [of rfc 3253] says:

   "The DAV:workspace property of a workspace resource MUST identify
   itself.  The DAV:workspace property of any other type of resource
   MUST be the same as the DAV:workspace of its parent collection."

   It seems to be undefined however what the value is if a resource doesn't
   *have* a (DAV-compliant) parent collection, for instance the root of my
DAV
   namespace.

   So what should it be?

   a) not present
   b) empty (no href)

   Julian (leaning to b)

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>Required properties with no value [WAS: workspace property on =
resources that aren't in workspaces]</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>This is a good question, and it applies to any =
&quot;required&quot; property that</FONT>
<BR><FONT SIZE=3D2>sometimes has &quot;no value&quot; (e.g. =
DAV:checked-in and DAV:checked-out).</FONT>
</P>

<P><FONT SIZE=3D2>So this question probably should be answered in =
2518bis (I'll forward</FONT>
<BR><FONT SIZE=3D2>this message to the WebDAV list), but we certainly =
could take a stab</FONT>
<BR><FONT SIZE=3D2>at it in the DeltaV context first.</FONT>
</P>

<P><FONT SIZE=3D2>Like Julian, I'd probably be inclined to =
&quot;b&quot;, but don't feel strongly</FONT>
<BR><FONT SIZE=3D2>either way.&nbsp; Anyone prefer &quot;a&quot;, =
prefer to decide separately for each</FONT>
<BR><FONT SIZE=3D2>property, or prefer that we leave it up to the =
server?</FONT>
</P>

<P><FONT SIZE=3D2>Cheers,</FONT>
<BR><FONT SIZE=3D2>Geoff</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; From: Julian Reschke [<A =
HREF=3D"mailto:julian.reschke@greenbytes.de">mailto:julian.reschke@green=
bytes.de</A>]</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; section 6.2.1 [of rfc 3253] says:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; &quot;The DAV:workspace property of a =
workspace resource MUST identify</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; itself.&nbsp; The DAV:workspace =
property of any other type of resource</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; MUST be the same as the DAV:workspace =
of its parent collection.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; It seems to be undefined however what =
the value is if a resource doesn't</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; *have* a (DAV-compliant) parent =
collection, for instance the root of my DAV</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; namespace.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; So what should it be?</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; a) not present</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; b) empty (no href)</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; Julian (leaning to b)</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2658A.54A35E00--



From w3c-dist-auth-request@w3.org  Thu Sep 26 16:45:15 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21459
	for <webdav-archive@lists.ietf.org>; Thu, 26 Sep 2002 16:45:15 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8QKjxl02956;
	Thu, 26 Sep 2002 16:46:00 -0400 (EDT)
Resent-Date: Thu, 26 Sep 2002 16:46:00 -0400 (EDT)
Resent-Message-Id: <200209262046.g8QKjxl02956@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8QKjtB02860
	for <w3c-dist-auth@frink.w3.org>; Thu, 26 Sep 2002 16:45:55 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA20257;
	Thu, 26 Sep 2002 16:45:53 -0400
Received: from lisa [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R);
	Thu, 26 Sep 2002 22:45:04 +0200
From: "Julian Reschke" <julian.reschke@greenbytes.de>
To: "Clemm, Geoff" <gclemm@rational.com>,
        "WebDAV \(E-mail\)" <w3c-dist-auth@w3.org>,
        <ietf-dav-versioning@w3.org>
Date: Thu, 26 Sep 2002 22:45:00 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCOEPPFGAA.julian.reschke@greenbytes.de>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000E_01C265AE.589DD9D0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B107839285@SUS-MA1IT01>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
X-MDRemoteIP: 192.168.1.23
X-Return-Path: julian.reschke@greenbytes.de
Subject: RE: Required properties with no value [WAS: workspace property on res 	ources that aren't in workspaces]
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6754
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>


This is a multi-part message in MIME format.

------=_NextPart_000_000E_01C265AE.589DD9D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Required properties with no value [WAS: workspace property on resources that
aren't in workspaces]I think this case is a bit different.

For DAV:checked-in and DAV:checked-out the spec is very clear that they
aren't *present* for resources that don't happen to be checked-out /
checked-in.

In *this* case (DAV:workspace), the spec is just silent about the value for
a resource that happens to be in no workspace.

Furthermore, I don't think a) would work for DAV:checked-in -- clients
already check for the *presence* of this property to find out whether a
resource is checked-in, and RFC3253 explicitly says this is ok...:

"This property appears on a checked-in version-controlled resource, and
identifies a version that has the same content and dead properties as the
version-controlled resource. This property is removed when the resource is
checked out, and then added back (identifying a new version) when the
resource is checked back in."

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

  -----Original Message-----
  From: ietf-dav-versioning-request@w3.org
[mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
  Sent: Thursday, September 26, 2002 8:27 PM
  To: WebDAV (E-mail); ietf-dav-versioning@w3.org
  Subject: Required properties with no value [WAS: workspace property on res
ources that aren't in workspaces]


  This is a good question, and it applies to any "required" property that
  sometimes has "no value" (e.g. DAV:checked-in and DAV:checked-out).

  So this question probably should be answered in 2518bis (I'll forward
  this message to the WebDAV list), but we certainly could take a stab
  at it in the DeltaV context first.

  Like Julian, I'd probably be inclined to "b", but don't feel strongly
  either way.  Anyone prefer "a", prefer to decide separately for each
  property, or prefer that we leave it up to the server?

  Cheers,
  Geoff

     From: Julian Reschke [mailto:julian.reschke@greenbytes.de]

     section 6.2.1 [of rfc 3253] says:

     "The DAV:workspace property of a workspace resource MUST identify
     itself.  The DAV:workspace property of any other type of resource
     MUST be the same as the DAV:workspace of its parent collection."

     It seems to be undefined however what the value is if a resource
doesn't
     *have* a (DAV-compliant) parent collection, for instance the root of my
DAV
     namespace.

     So what should it be?

     a) not present
     b) empty (no href)

     Julian (leaning to b)

------=_NextPart_000_000E_01C265AE.589DD9D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Required properties with no value [WAS: workspace =
property on resources that aren't in workspaces]</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D324373820-26092002><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
think this case is a bit different.</FONT></SPAN></DIV>
<DIV><SPAN class=3D324373820-26092002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D324373820-26092002><FONT face=3DArial color=3D#0000ff =
size=3D2>For=20
DAV:checked-in and DAV:checked-out the spec is very clear that they =
aren't=20
*present* for resources that don't happen to be checked-out /=20
checked-in.</FONT></SPAN></DIV>
<DIV><SPAN class=3D324373820-26092002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D324373820-26092002><FONT face=3DArial color=3D#0000ff =
size=3D2>In=20
*this* case (DAV:workspace), the spec is just silent about the value for =
a=20
resource that happens to be in no workspace.</FONT></SPAN></DIV>
<DIV><SPAN class=3D324373820-26092002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D324373820-26092002><FONT face=3DArial color=3D#0000ff =

size=3D2>Furthermore, I don't think a) would work for DAV:checked-in -- =
clients=20
already check for the *presence* of this property to find out whether a =
resource=20
is checked-in, and RFC3253 explicitly says this is =
ok...:</FONT></SPAN></DIV>
<DIV><SPAN class=3D324373820-26092002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D324373820-26092002><FONT face=3DArial color=3D#0000ff =
size=3D2>"<FONT=20
color=3D#000000>This property appears on a checked-in version-controlled =
resource,=20
and identifies a version that has the same content and dead properties =
as the=20
version-controlled resource. This property is removed when the resource =
is=20
checked out, and then added back (identifying a new version) when the =
resource=20
is checked back in."</FONT></FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<P><FONT size=3D2>--<BR>&lt;green/&gt;bytes GmbH -- <A=20
href=3D"http://www.greenbytes.de/" =
target=3D_blank>http://www.greenbytes.de</A> --=20
tel:+492512807760 </FONT></P>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B>=20
  ietf-dav-versioning-request@w3.org=20
  [mailto:ietf-dav-versioning-request@w3.org]<B>On Behalf Of </B>Clemm,=20
  Geoff<BR><B>Sent:</B> Thursday, September 26, 2002 8:27 =
PM<BR><B>To:</B>=20
  WebDAV (E-mail); ietf-dav-versioning@w3.org<BR><B>Subject:</B> =
Required=20
  properties with no value [WAS: workspace property on res ources that =
aren't in=20
  workspaces]<BR><BR></FONT></DIV>
  <P><FONT size=3D2>This is a good question, and it applies to any =
"required"=20
  property that</FONT> <BR><FONT size=3D2>sometimes has "no value" (e.g. =

  DAV:checked-in and DAV:checked-out).</FONT> </P>
  <P><FONT size=3D2>So this question probably should be answered in =
2518bis (I'll=20
  forward</FONT> <BR><FONT size=3D2>this message to the WebDAV list), =
but we=20
  certainly could take a stab</FONT> <BR><FONT size=3D2>at it in the =
DeltaV=20
  context first.</FONT> </P>
  <P><FONT size=3D2>Like Julian, I'd probably be inclined to "b", but =
don't feel=20
  strongly</FONT> <BR><FONT size=3D2>either way.&nbsp; Anyone prefer =
"a", prefer=20
  to decide separately for each</FONT> <BR><FONT size=3D2>property, or =
prefer that=20
  we leave it up to the server?</FONT> </P>
  <P><FONT size=3D2>Cheers,</FONT> <BR><FONT size=3D2>Geoff</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; From: Julian Reschke [<A=20
  =
href=3D"mailto:julian.reschke@greenbytes.de">mailto:julian.reschke@greenb=
ytes.de</A>]</FONT>=20
  </P>
  <P><FONT size=3D2>&nbsp;&nbsp; section 6.2.1 [of rfc 3253] =
says:</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; "The DAV:workspace property of a =
workspace=20
  resource MUST identify</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; =
itself.&nbsp; The=20
  DAV:workspace property of any other type of resource</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp; MUST be the same as the DAV:workspace of its =
parent=20
  collection."</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; It seems to be undefined however what =
the value=20
  is if a resource doesn't</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; *have* =
a=20
  (DAV-compliant) parent collection, for instance the root of my =
DAV</FONT>=20
  <BR><FONT size=3D2>&nbsp;&nbsp; namespace.</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; So what should it be?</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; a) not present</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp; b) empty (no href)</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; Julian (leaning to b)</FONT>=20
</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_000E_01C265AE.589DD9D0--




From w3c-dist-auth-request@w3.org  Fri Sep 27 00:34:17 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01683
	for <webdav-archive@lists.ietf.org>; Fri, 27 Sep 2002 00:34:16 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8R4ZDl04839;
	Fri, 27 Sep 2002 00:35:13 -0400 (EDT)
Resent-Date: Fri, 27 Sep 2002 00:35:13 -0400 (EDT)
Resent-Message-Id: <200209270435.g8R4ZDl04839@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8R4ZAB04800
	for <w3c-dist-auth@frink.w3.org>; Fri, 27 Sep 2002 00:35:11 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA26809
	for <w3c-dist-auth@w3c.org>; Fri, 27 Sep 2002 00:35:05 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id VAA28836 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Thu, 26 Sep 2002 21:34:51 -0700
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by sunbelt.seagull.net (8.9.3) with ESMTP id VAA28819 sender obsfucated@us.ibm.com; Thu, 26 Sep 2002 21:34:50 -0700
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8R4YI4x123066; Fri, 27 Sep 2002 00:34:18 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8R4YHxK066716; Fri, 27 Sep 2002 00:34:17 -0400
To: "Clemm, Geoff" <gclemm@Rational.Com>
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFF91D0EAB.2D0FCB4A-ON85256C41.0017F87F@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Fri, 27 Sep 2002 00:29:29 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_09252002|September 25, 2002) at 09/27/2002 00:34:16
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Subject: RE: Issue: Requiring server to use / terminated URL for returned collections
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6755
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>





On Wednesday, 09/25/2002 at 11:48 AST, "Clemm, Geoff" wrote:
> =A0=A0 From: Jason Crawford [mailto:nn683849@smallcue.com]
>
> =A0=A0 I think the remaining issues are...
>
> =A0=A0 Were there truly some interop issues with not always returning=
 a
> =A0=A0 trailing slash?=A0 What were they?=A0 Would a requirement of
> =A0=A0 consistancy work just as well as requiring a terminating slash=
?
>
> =A0=A0 Certain broken behaviors in existing clients/servers was menti=
oned.
> =A0=A0 What products, people, etc do we need to follow up with?
>
> =A0=A0 Can a client assume that, if a server returns a URL that ends =
in a
> =A0=A0 slash, the resource referenced is a collection?
>
> I would have no problem with that requirement, if it can be
> demonstrated to have significant client value.

Okay guys. I could make this case, but I'd prefer someone
that builds clients to make it  since it is clients that would would
benefit.

A proposal came out of the
interop that we have servers always return slash terminated
URL's for collections.  That proposal is meeting some
resistance, but there is another proposal on the table that appears
to have some of the advantages of the original proposal.  Geoff
has left the door open for this proposal if a case is made.  If you
were at the interop and have a case to present related
to slash termination, please present it.

J.=




From w3c-dist-auth-request@w3.org  Fri Sep 27 09:49:30 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20595
	for <webdav-archive@lists.ietf.org>; Fri, 27 Sep 2002 09:49:30 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8RDgvb27821;
	Fri, 27 Sep 2002 09:42:57 -0400 (EDT)
Resent-Date: Fri, 27 Sep 2002 09:42:57 -0400 (EDT)
Resent-Message-Id: <200209271342.g8RDgvb27821@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8RDgtB27795
	for <w3c-dist-auth@frink.w3.org>; Fri, 27 Sep 2002 09:42:55 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA24795
	for <w3c-dist-auth@w3c.org>; Fri, 27 Sep 2002 09:42:55 -0400
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 27 Sep 2002 09:32:12 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <TRM2A4VC>; Fri, 27 Sep 2002 09:42:23 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1085A9376@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Fri, 27 Sep 2002 09:42:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2662B.B444F480"
Subject: RE: Interop issue: Proposal for fixing lock token provision
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6756
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>


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

------_=_NextPart_001_01C2662B.B444F480
Content-Type: text/plain

Could someone post what exactly were the interoperability problems
that were found?  As far as I can tell, the If header is a superior
way of handling the locking scenarios than the alternatives being
proposed.

In particular, I do not find the "separation of concerns" argument
convincing, since issue #3 (detecting when you have an
invalid lock token) is exactly the reason why a single header
is used both to check state and demonstrate possession of the
required token (i.e. I believe the concerns are inherently linked).

In particular, I do not support #2, because it leads a client to
perform updates against resources that it has lost its lock on.
Why would a client ever want to do that, instead of reacquiring
a lock?  A key benefit of locks as currently defined is that they
solve the lost update problem for servers that cannot provide etags,
but updating a resource for which you have lost your lock 
opens you up to the lost update problem.

Note: If lengthy If headers has proven to be a problem, I am
happy to allow a "," to separate If clauses, so that
you can submit multiple If headers in one request.

Cheers,
Geoff


-----Original Message-----
From: Jason Crawford [mailto:nn683849@smallcue.com]

This thread seemed to get overlooked, so I want to get discussion going on
it...

On Sunday, 09/15/2002 at 11:31 MST, "Lisa Dusseault" wrote:
> At this week's Interop event, as at last year's, many interoperability
> problems were found with scenarios involving change methods where a lock
> token is required.  A long, animated, exciting conversation was held to
> finally achieve  consensus among attendees on goals for a new way to
> supply lock tokens to servers.
>
> GOALS for Lock Token Provision
> ------------------------------
>
> 1. Clients should be able to provide lock tokens in conditional requests
> that cause the request to fail if the token does not still match the
> state. This goal is currently met by the If header, but this goal must
> continue to be met by any new solution.
>
> 2. Clients should ALSO be able to provide multiple unqualified lock
> tokens in order to prove that they have those tokens and can do write
> requests legally, in a way that does not impose conditions on the
> success of the request. This mechanism should not use or affect the
> Lock-Token header which is required in UNLOCK to specify a single lock
> token to remove or refresh. This mechanism should be capable of
> supporting many values.
>
> 3. Servers should be able to inform clients when lock tokens being used
> in any way are no longer valid.   This helps clients keep their
> understanding of the server's state up-to-date.

I basically agree with (1) and (2).  I value keeping the server driven
submission
of tokens seperate from client driven consistancy checks.  Hopefully this
will
simplify the If: header semantics.

(3) is new to me.  I'd like to hear more discussion on it.  Perhaps as a
seperate
thread.


> Discussions on how to solve
> ---------------------------
>
> 1. Already solved by If header. Only slight clarifications needed to
> improve basic interoperability of this header (see below).

OK

> 2. The mechanism to provide multiple tokens could easily be a new
> header. The syntax should involve comma-separated values, because then
> lines can be split across multiple instances of the header according to
> RFC2616 header rules.

OK.  I can see how that can be implemented without breaking compatibility.


> 3. A new response header or two could allow servers to return invalid or
> unnecessary lock tokens.  This should be a response header so that the
> information can easily be marshaled even on responses that already
> contain a body. Again, the response header syntax should be
> comma-separated.

I'd like to hear more about the requirement for this.


>
> Slight changes to existing definitions
> --------------------------------------
>
> - The existing Lock-Token header is used to specify a single lock token,
> in methods that must operate on a single lock.  It is used on UNLOCK to
> remove a lock.  The LOCK refresh request should ALSO use this header
> (and the If header should continue to be supported by servers in order
> to handle existing clients).  This includes the clarification that LOCK
> refresh can only be used to refresh a single lock.  That's a good thing,
> because the Timeout header only exists once per request too.

OK with me.


>  - An untagged token in the IF header should apply ONLY to the resource
> named in the Request-URI.  The original definition is that they apply to
> any resources "affected" by the request. This has turned out to be too
> ambiguous and arduous to determine.  Also most lock tokens only apply to
> one resource, not the entire set of resources "affected" by a request
> like MOVE/COPY. Since any token in the IF header can be tagged with a
> URL in order to make it explicit what resource the token refers to, we
> can make the untagged token equally explicit without removing any client
> functionality in the If header.

OK.

So what do other people have to say?

J.

------------------------------------------
Phone: 914-784-7569

------_=_NextPart_001_01C2662B.B444F480
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: Interop issue: Proposal for fixing lock token provision</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Could someone post what exactly were the interoperability problems</FONT>
<BR><FONT SIZE=2>that were found?&nbsp; As far as I can tell, the If header is a superior</FONT>
<BR><FONT SIZE=2>way of handling the locking scenarios than the alternatives being</FONT>
<BR><FONT SIZE=2>proposed.</FONT>
</P>

<P><FONT SIZE=2>In particular, I do not find the &quot;separation of concerns&quot; argument</FONT>
<BR><FONT SIZE=2>convincing, since issue #3 (detecting when you have an</FONT>
<BR><FONT SIZE=2>invalid lock token) is exactly the reason why a single header</FONT>
<BR><FONT SIZE=2>is used both to check state and demonstrate possession of the</FONT>
<BR><FONT SIZE=2>required token (i.e. I believe the concerns are inherently linked).</FONT>
</P>

<P><FONT SIZE=2>In particular, I do not support #2, because it leads a client to</FONT>
<BR><FONT SIZE=2>perform updates against resources that it has lost its lock on.</FONT>
<BR><FONT SIZE=2>Why would a client ever want to do that, instead of reacquiring</FONT>
<BR><FONT SIZE=2>a lock?&nbsp; A key benefit of locks as currently defined is that they</FONT>
<BR><FONT SIZE=2>solve the lost update problem for servers that cannot provide etags,</FONT>
<BR><FONT SIZE=2>but updating a resource for which you have lost your lock </FONT>
<BR><FONT SIZE=2>opens you up to the lost update problem.</FONT>
</P>

<P><FONT SIZE=2>Note: If lengthy If headers has proven to be a problem, I am</FONT>
<BR><FONT SIZE=2>happy to allow a &quot;,&quot; to separate If clauses, so that</FONT>
<BR><FONT SIZE=2>you can submit multiple If headers in one request.</FONT>
</P>

<P><FONT SIZE=2>Cheers,</FONT>
<BR><FONT SIZE=2>Geoff</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Jason Crawford [<A HREF="mailto:nn683849@smallcue.com">mailto:nn683849@smallcue.com</A>]</FONT>
</P>

<P><FONT SIZE=2>This thread seemed to get overlooked, so I want to get discussion going on</FONT>
<BR><FONT SIZE=2>it...</FONT>
</P>

<P><FONT SIZE=2>On Sunday, 09/15/2002 at 11:31 MST, &quot;Lisa Dusseault&quot; wrote:</FONT>
<BR><FONT SIZE=2>&gt; At this week's Interop event, as at last year's, many interoperability</FONT>
<BR><FONT SIZE=2>&gt; problems were found with scenarios involving change methods where a lock</FONT>
<BR><FONT SIZE=2>&gt; token is required.&nbsp; A long, animated, exciting conversation was held to</FONT>
<BR><FONT SIZE=2>&gt; finally achieve&nbsp; consensus among attendees on goals for a new way to</FONT>
<BR><FONT SIZE=2>&gt; supply lock tokens to servers.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; GOALS for Lock Token Provision</FONT>
<BR><FONT SIZE=2>&gt; ------------------------------</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; 1. Clients should be able to provide lock tokens in conditional requests</FONT>
<BR><FONT SIZE=2>&gt; that cause the request to fail if the token does not still match the</FONT>
<BR><FONT SIZE=2>&gt; state. This goal is currently met by the If header, but this goal must</FONT>
<BR><FONT SIZE=2>&gt; continue to be met by any new solution.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; 2. Clients should ALSO be able to provide multiple unqualified lock</FONT>
<BR><FONT SIZE=2>&gt; tokens in order to prove that they have those tokens and can do write</FONT>
<BR><FONT SIZE=2>&gt; requests legally, in a way that does not impose conditions on the</FONT>
<BR><FONT SIZE=2>&gt; success of the request. This mechanism should not use or affect the</FONT>
<BR><FONT SIZE=2>&gt; Lock-Token header which is required in UNLOCK to specify a single lock</FONT>
<BR><FONT SIZE=2>&gt; token to remove or refresh. This mechanism should be capable of</FONT>
<BR><FONT SIZE=2>&gt; supporting many values.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; 3. Servers should be able to inform clients when lock tokens being used</FONT>
<BR><FONT SIZE=2>&gt; in any way are no longer valid.&nbsp;&nbsp; This helps clients keep their</FONT>
<BR><FONT SIZE=2>&gt; understanding of the server's state up-to-date.</FONT>
</P>

<P><FONT SIZE=2>I basically agree with (1) and (2).&nbsp; I value keeping the server driven</FONT>
<BR><FONT SIZE=2>submission</FONT>
<BR><FONT SIZE=2>of tokens seperate from client driven consistancy checks.&nbsp; Hopefully this</FONT>
<BR><FONT SIZE=2>will</FONT>
<BR><FONT SIZE=2>simplify the If: header semantics.</FONT>
</P>

<P><FONT SIZE=2>(3) is new to me.&nbsp; I'd like to hear more discussion on it.&nbsp; Perhaps as a</FONT>
<BR><FONT SIZE=2>seperate</FONT>
<BR><FONT SIZE=2>thread.</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; Discussions on how to solve</FONT>
<BR><FONT SIZE=2>&gt; ---------------------------</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; 1. Already solved by If header. Only slight clarifications needed to</FONT>
<BR><FONT SIZE=2>&gt; improve basic interoperability of this header (see below).</FONT>
</P>

<P><FONT SIZE=2>OK</FONT>
</P>

<P><FONT SIZE=2>&gt; 2. The mechanism to provide multiple tokens could easily be a new</FONT>
<BR><FONT SIZE=2>&gt; header. The syntax should involve comma-separated values, because then</FONT>
<BR><FONT SIZE=2>&gt; lines can be split across multiple instances of the header according to</FONT>
<BR><FONT SIZE=2>&gt; RFC2616 header rules.</FONT>
</P>

<P><FONT SIZE=2>OK.&nbsp; I can see how that can be implemented without breaking compatibility.</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; 3. A new response header or two could allow servers to return invalid or</FONT>
<BR><FONT SIZE=2>&gt; unnecessary lock tokens.&nbsp; This should be a response header so that the</FONT>
<BR><FONT SIZE=2>&gt; information can easily be marshaled even on responses that already</FONT>
<BR><FONT SIZE=2>&gt; contain a body. Again, the response header syntax should be</FONT>
<BR><FONT SIZE=2>&gt; comma-separated.</FONT>
</P>

<P><FONT SIZE=2>I'd like to hear more about the requirement for this.</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Slight changes to existing definitions</FONT>
<BR><FONT SIZE=2>&gt; --------------------------------------</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; - The existing Lock-Token header is used to specify a single lock token,</FONT>
<BR><FONT SIZE=2>&gt; in methods that must operate on a single lock.&nbsp; It is used on UNLOCK to</FONT>
<BR><FONT SIZE=2>&gt; remove a lock.&nbsp; The LOCK refresh request should ALSO use this header</FONT>
<BR><FONT SIZE=2>&gt; (and the If header should continue to be supported by servers in order</FONT>
<BR><FONT SIZE=2>&gt; to handle existing clients).&nbsp; This includes the clarification that LOCK</FONT>
<BR><FONT SIZE=2>&gt; refresh can only be used to refresh a single lock.&nbsp; That's a good thing,</FONT>
<BR><FONT SIZE=2>&gt; because the Timeout header only exists once per request too.</FONT>
</P>

<P><FONT SIZE=2>OK with me.</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt;&nbsp; - An untagged token in the IF header should apply ONLY to the resource</FONT>
<BR><FONT SIZE=2>&gt; named in the Request-URI.&nbsp; The original definition is that they apply to</FONT>
<BR><FONT SIZE=2>&gt; any resources &quot;affected&quot; by the request. This has turned out to be too</FONT>
<BR><FONT SIZE=2>&gt; ambiguous and arduous to determine.&nbsp; Also most lock tokens only apply to</FONT>
<BR><FONT SIZE=2>&gt; one resource, not the entire set of resources &quot;affected&quot; by a request</FONT>
<BR><FONT SIZE=2>&gt; like MOVE/COPY. Since any token in the IF header can be tagged with a</FONT>
<BR><FONT SIZE=2>&gt; URL in order to make it explicit what resource the token refers to, we</FONT>
<BR><FONT SIZE=2>&gt; can make the untagged token equally explicit without removing any client</FONT>
<BR><FONT SIZE=2>&gt; functionality in the If header.</FONT>
</P>

<P><FONT SIZE=2>OK.</FONT>
</P>

<P><FONT SIZE=2>So what do other people have to say?</FONT>
</P>

<P><FONT SIZE=2>J.</FONT>
</P>

<P><FONT SIZE=2>------------------------------------------</FONT>
<BR><FONT SIZE=2>Phone: 914-784-7569</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2662B.B444F480--



From w3c-dist-auth-request@w3.org  Mon Sep 30 10:42:36 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06219
	for <webdav-archive@lists.ietf.org>; Mon, 30 Sep 2002 10:42:35 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8UEgfK06325;
	Mon, 30 Sep 2002 10:42:42 -0400 (EDT)
Resent-Date: Mon, 30 Sep 2002 10:42:42 -0400 (EDT)
Resent-Message-Id: <200209301442.g8UEgfK06325@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8UEgdB06299
	for <w3c-dist-auth@frink.w3.org>; Mon, 30 Sep 2002 10:42:39 -0400 (EDT)
Received: from sunbelt.seagull.net ([199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA16622
	for <w3c-dist-auth@w3c.org>; Mon, 30 Sep 2002 10:42:37 -0400
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id HAA15760 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Mon, 30 Sep 2002 07:42:26 -0700
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by sunbelt.seagull.net (8.9.3) with ESMTP id HAA15740 sender obsfucated@us.ibm.com; Mon, 30 Sep 2002 07:42:25 -0700
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8UEfrVL027768; Mon, 30 Sep 2002 10:41:53 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8UEfp7E155356; Mon, 30 Sep 2002 10:41:52 -0400
To: "Clemm, Geoff" <gclemm@Rational.Com>
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF905C40B2.E25571F4-ON85256C41.0052C189@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Mon, 30 Sep 2002 10:33:54 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_09252002|September 25, 2002) at 09/30/2002 10:41:51
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Subject: RE: Interop issue: Proposal for fixing lock token provision
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6757
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>





On Friday, 09/27/2002 at 09:42 AST, "Clemm, Geoff"
<nngclemm___at___Rational.Com@smallcue.com> wrote:
> In particular, I do not find the "separation of concerns" argument
> convincing, since issue #3 (detecting when you have an
> invalid lock token) is exactly the reason why a single header
> is used both to check state and demonstrate possession of the
> required token (i.e. I believe the concerns are inherently linked).

I actually just figured out what that case is, but I don't want to
focus on that in this note.   I'd first like to discuss moving
 the token submission functionality to a different header.


> In particular, I do not support #2, because it leads a client to
> perform updates against resources that it has lost its lock on.
They probably should be checking for an etag rather than a
lock anyway.  If the client is only doing content editing, the lock
check is just something that can be done if you don't have etag
support.  If the etag hasn't changed, you are probably fine doing
the PUT operation just checking the etag.    And in fact doing
the etag checking will allow the client to check for content
changes that occured despite the fact that he locked locked the
resource.

You could check both the etag and the lock.  But if it's the last
PUT operation you plan to do before unlocking, checking the lock
is just going to make things chatty and delay the PUT that you'll want =
to
do anyway.  Why?  Because if someone as aquired a new
lock, you'll be told anyway.   And if someone modified the
resource, the etag check will already catch this.   Finding out there
is no lock there if you' just going to unlock anyway doesn't do
any good.

Better servers support etags, but some won't or won't be able
to.  In this case, the best the client can do is check for lock
still being there.  The client should do that.  And in the case of
property modifications (which don't change etags), they'll want
to check for locks rather than etags anyway.   This will let them
know if another client has had a chance to modify the resource.

But I think this is a client responsibility.  The server should
not force the client to do this.  It's up to the server to offer lock
support and to correctly implement it.  And it's up to the client
to use them as it needs to.  We already allow a client to decide
if it uses locks.  Let it also be the case with this.   I've already
indicated a case above where it wasn't appropriate to
check for a lock.   Let the client decide.


> Why would a client ever want to do that, instead of reacquiring
> a lock?
If they successfuly check the etag, it doesn't matter if they still
have the lock.

> A key benefit of locks as currently defined is that they
> solve the lost update problem for servers that cannot provide etags,
Yup.  So if a server supports etags, the client often doesn't need to
check for the lock.

> but updating a resource for which you have lost your lock
> opens you up to the lost update problem.

...in the absense of etags.

> Note: If lengthy If headers has proven to be a problem, I am
> happy to allow a "," to separate If clauses, so that
> you can submit multiple If headers in one request.

It's not really the length that's the problem in my mind.  It's
the fact that we have to define what it means for the If:
header to have *submitted* the token.  The If: header
can be quite sophisticated and we might choose to make
it even more sophisticated as we discover more requirements.
If we combine the functionality, then it constrains how much
we can extend the If: header.

Yes, we could say that clients can support multiple If:
headers.  (I forget if we already do.)  But we'd end up
defining two types of If: headers for the two purposes.

I'd prefer to seperate those explicitly.  WebDAV is only
in version 1 now and hopefully a design decision like
this will clarify the protocol now and avoid specification
headaches down the road.

J.=




From w3c-dist-auth-request@w3.org  Mon Sep 30 11:02:06 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06844
	for <webdav-archive@lists.ietf.org>; Mon, 30 Sep 2002 11:02:05 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8UF31n08514;
	Mon, 30 Sep 2002 11:03:01 -0400 (EDT)
Resent-Date: Mon, 30 Sep 2002 11:03:01 -0400 (EDT)
Resent-Message-Id: <200209301503.g8UF31n08514@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8UF2wB08484
	for <w3c-dist-auth@frink.w3.org>; Mon, 30 Sep 2002 11:02:58 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA22691
	for <w3c-dist-auth@w3c.org>; Mon, 30 Sep 2002 11:02:57 -0400
Received: from greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3c.org>; Mon, 30 Sep 2002 17:02:46 +0200
Date: Mon, 30 Sep 2002 17:02:44 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
To: Jason Crawford <nn683849@smallcue.com>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <OF905C40B2.E25571F4-ON85256C41.0052C189@us.ibm.com>
Message-Id: <AC9E37F6-D485-11D6-9660-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: Interop issue: Proposal for fixing lock token provision
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6758
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>
Content-Transfer-Encoding: 7bit



Am Montag, 30.09.02, um 16:33 Uhr (Europe/Berlin) schrieb Jason 
Crawford:

I agree with Jasons arguments concerning the update of resources
with PUT and using ETags in order to detect unexpected changes.

However, when the client wants to change properties, access rights
or version information (e.g. checkin), then the ETag will not tell
anything useful about the status of the resource.

For these use cases clients will continue to need the lock-token(s)
in the If: header.

In the light of this, is it useful to add another header where lock
token can also be supplied? What do client implementors say?

//Stefan

> [...]
>
>> In particular, I do not support #2, because it leads a client to
>> perform updates against resources that it has lost its lock on.
> They probably should be checking for an etag rather than a
> lock anyway.  If the client is only doing content editing, the lock
> check is just something that can be done if you don't have etag
> support.  If the etag hasn't changed, you are probably fine doing
> the PUT operation just checking the etag.    And in fact doing
> the etag checking will allow the client to check for content
> changes that occured despite the fact that he locked locked the
> resource.
>
> You could check both the etag and the lock.  But if it's the last
> PUT operation you plan to do before unlocking, checking the lock
> is just going to make things chatty and delay the PUT that you'll want 
> =
> to
> do anyway.  Why?  Because if someone as aquired a new
> lock, you'll be told anyway.   And if someone modified the
> resource, the etag check will already catch this.   Finding out there
> is no lock there if you' just going to unlock anyway doesn't do
> any good.
>
> Better servers support etags, but some won't or won't be able
> to.  In this case, the best the client can do is check for lock
> still being there.  The client should do that.  And in the case of
> property modifications (which don't change etags), they'll want
> to check for locks rather than etags anyway.   This will let them
> know if another client has had a chance to modify the resource.
>
> But I think this is a client responsibility.  The server should
> not force the client to do this.  It's up to the server to offer lock
> support and to correctly implement it.  And it's up to the client
> to use them as it needs to.  We already allow a client to decide
> if it uses locks.  Let it also be the case with this.   I've already
> indicated a case above where it wasn't appropriate to
> check for a lock.   Let the client decide.
>
>
>> Why would a client ever want to do that, instead of reacquiring
>> a lock?
> If they successfuly check the etag, it doesn't matter if they still
> have the lock.
>
>> A key benefit of locks as currently defined is that they
>> solve the lost update problem for servers that cannot provide etags,
> Yup.  So if a server supports etags, the client often doesn't need to
> check for the lock.
>
>> but updating a resource for which you have lost your lock
>> opens you up to the lost update problem.
>
> ....in the absense of etags.
>
>> Note: If lengthy If headers has proven to be a problem, I am
>> happy to allow a "," to separate If clauses, so that
>> you can submit multiple If headers in one request.
>
> It's not really the length that's the problem in my mind.  It's
> the fact that we have to define what it means for the If:
> header to have *submitted* the token.  The If: header
> can be quite sophisticated and we might choose to make
> it even more sophisticated as we discover more requirements.
> If we combine the functionality, then it constrains how much
> we can extend the If: header.
>
> Yes, we could say that clients can support multiple If:
> headers.  (I forget if we already do.)  But we'd end up
> defining two types of If: headers for the two purposes.
>
> I'd prefer to seperate those explicitly.  WebDAV is only
> in version 1 now and hopefully a design decision like
> this will clarify the protocol now and avoid specification
> headaches down the road.
>
> J.=
>





From w3c-dist-auth-request@w3.org  Mon Sep 30 12:47:39 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12027
	for <webdav-archive@lists.ietf.org>; Mon, 30 Sep 2002 12:47:39 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8UGmcB22274;
	Mon, 30 Sep 2002 12:48:38 -0400 (EDT)
Resent-Date: Mon, 30 Sep 2002 12:48:38 -0400 (EDT)
Resent-Message-Id: <200209301648.g8UGmcB22274@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8UGmaB22231
	for <w3c-dist-auth@frink.w3.org>; Mon, 30 Sep 2002 12:48:36 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA17458
	for <w3c-dist-auth@w3c.org>; Mon, 30 Sep 2002 12:48:36 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Mon, 30 Sep 2002 12:48:03 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Mon, 30 Sep 2002 12:48:03 -0400
Received: from xythoslap ([216.36.77.241]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Mon, 30 Sep 2002 12:47:39 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Mon, 30 Sep 2002 09:47:42 -0700
Message-ID: <00ee01c268a1$18a009c0$29c4fea9@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
X-OriginalArrivalTime: 30 Sep 2002 16:47:40.0105 (UTC) FILETIME=[16C86390:01C268A1]
Subject: FW: 55th IETF WG/BOF Scheduling - DRAFT Agenda
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6759
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>
Content-Transfer-Encoding: 7bit


The WebDAV WG meeting at Atlanta is tentatively scheduled for Tuesday
afternoon, November 19. Note that the IETF schedule may change if
conflicts arise.  Other interesting tentatively scheduled meetings:
 - Monday am: Apps area open meeting
 - Monday pm: Open Pluggable Edge [Web] Services
 - Wednesday pm: LDAP replication
 - Wednesday pm: Cross-registry Information Services Protocol
 - Wednesday eve: IAB Plenary
 - Thursday eve: IESG Plenary

Let Jim and me know if you've got items for the agenda.  I am sure we'll
discuss RFC2518 bis issues, including how to handle lock tokens &
trailing slashes.  We may also discuss DASL.

Lisa




From w3c-dist-auth-request@w3.org  Mon Sep 30 12:55:57 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12443
	for <webdav-archive@lists.ietf.org>; Mon, 30 Sep 2002 12:55:56 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8UGtW723211;
	Mon, 30 Sep 2002 12:55:32 -0400 (EDT)
Resent-Date: Mon, 30 Sep 2002 12:55:32 -0400 (EDT)
Resent-Message-Id: <200209301655.g8UGtW723211@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8UGtTB23185
	for <w3c-dist-auth@frink.w3.org>; Mon, 30 Sep 2002 12:55:29 -0400 (EDT)
Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA19520
	for <w3c-dist-auth@w3c.org>; Mon, 30 Sep 2002 12:55:29 -0400
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.5255);
	 Mon, 30 Sep 2002 09:54:01 -0700
Received: from 10.197.0.60 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 30 Sep 2002 09:53:23 -0700
Received: from DF-BOWWOW.platinum.corp.microsoft.com ([10.197.1.8]) by DF-YURI.platinum.corp.microsoft.com with Microsoft SMTPSVC(6.0.3663.0);
	 Mon, 30 Sep 2002 09:53:23 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Date: Mon, 30 Sep 2002 09:53:21 -0700
Message-ID: <4B52672946805F4D8B93BA8FEDD30F2501A2883B@DF-BOWWOW.platinum.corp.microsoft.com>
Thread-Topic: 55th IETF WG/BOF Scheduling - DRAFT Agenda
Thread-Index: AcJooUvjt7FzSvu4Sk2zJR5rqkv9TwAAFTjA
From: "Joel Soderberg" <joels@Exchange.Microsoft.com>
To: "Lisa Dusseault" <lisa@xythos.com>, "Webdav WG" <w3c-dist-auth@w3c.org>
Cc: "Jim Whitehead" <ejw@cse.ucsc.edu>
X-OriginalArrivalTime: 30 Sep 2002 16:53:23.0308 (UTC) FILETIME=[E35902C0:01C268A1]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g8UGtTB23185
Subject: RE: 55th IETF WG/BOF Scheduling - DRAFT Agenda
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6760
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>
Content-Transfer-Encoding: 8bit


Lisa, just wanted to let you know I am registered and booked for the WG
meeting.  Thanks for driving this.  Do you have a tentative cast of
characters?

Joels

-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com] 
Sent: Monday, September 30, 2002 9:48 AM
To: Webdav WG
Subject: FW: 55th IETF WG/BOF Scheduling - DRAFT Agenda


The WebDAV WG meeting at Atlanta is tentatively scheduled for Tuesday
afternoon, November 19. Note that the IETF schedule may change if
conflicts arise.  Other interesting tentatively scheduled meetings:
 - Monday am: Apps area open meeting
 - Monday pm: Open Pluggable Edge [Web] Services
 - Wednesday pm: LDAP replication
 - Wednesday pm: Cross-registry Information Services Protocol
 - Wednesday eve: IAB Plenary
 - Thursday eve: IESG Plenary

Let Jim and me know if you've got items for the agenda.  I am sure we'll
discuss RFC2518 bis issues, including how to handle lock tokens &
trailing slashes.  We may also discuss DASL.

Lisa




From w3c-dist-auth-request@w3.org  Mon Sep 30 13:05:44 2002
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12791
	for <webdav-archive@lists.ietf.org>; Mon, 30 Sep 2002 13:05:44 -0400 (EDT)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id g8UH6ok24707;
	Mon, 30 Sep 2002 13:06:50 -0400 (EDT)
Resent-Date: Mon, 30 Sep 2002 13:06:50 -0400 (EDT)
Resent-Message-Id: <200209301706.g8UH6ok24707@frink.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g8UH6mB24676
	for <w3c-dist-auth@frink.w3.org>; Mon, 30 Sep 2002 13:06:48 -0400 (EDT)
Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA22318
	for <w3c-dist-auth@w3c.org>; Mon, 30 Sep 2002 13:06:48 -0400
Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Mon, 30 Sep 2002 13:06:01 -0400 (Eastern Daylight Time)
Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453);
	 Mon, 30 Sep 2002 13:06:00 -0400
Received: from xythoslap ([216.36.77.241]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453);
	 Mon, 30 Sep 2002 13:06:00 -0400
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Joel Soderberg'" <joels@Exchange.Microsoft.com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Cc: "'Jim Whitehead'" <ejw@cse.ucsc.edu>
Date: Mon, 30 Sep 2002 10:06:02 -0700
Message-ID: <00f401c268a3$a8935120$29c4fea9@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <4B52672946805F4D8B93BA8FEDD30F2501A2883B@DF-BOWWOW.platinum.corp.microsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
X-OriginalArrivalTime: 30 Sep 2002 17:06:00.0638 (UTC) FILETIME=[A6C065E0:01C268A3]
Subject: RE: 55th IETF WG/BOF Scheduling - DRAFT Agenda
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6761
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>
Content-Transfer-Encoding: 7bit


We usually don't know until people show up who's going to show up.
However, it wouldn't hurt for people to let the mailing list know if
they've decided to show.  I'll be there!

Perhaps we can have a "friends of webdav" lunch on Tuesday for
additional discussions or just socializing?  If anybody else is
available, we can meet by the message board at 11:45 am & pick a lunch
spot. Tuesday night may be the social, which would conflict somewhat
with dinner plans.

lisa

> -----Original Message-----
> From: Joel Soderberg [mailto:joels@Exchange.Microsoft.com]
> Sent: Monday, September 30, 2002 9:53 AM
> To: Lisa Dusseault; Webdav WG
> Cc: Jim Whitehead
> Subject: RE: 55th IETF WG/BOF Scheduling - DRAFT Agenda
> 
> Lisa, just wanted to let you know I am registered and booked for the
WG
> meeting.  Thanks for driving this.  Do you have a tentative cast of
> characters?
> 
> Joels
> 
> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Monday, September 30, 2002 9:48 AM
> To: Webdav WG
> Subject: FW: 55th IETF WG/BOF Scheduling - DRAFT Agenda
> 
> 
> The WebDAV WG meeting at Atlanta is tentatively scheduled for Tuesday
> afternoon, November 19. Note that the IETF schedule may change if
> conflicts arise.  Other interesting tentatively scheduled meetings:
>  - Monday am: Apps area open meeting
>  - Monday pm: Open Pluggable Edge [Web] Services
>  - Wednesday pm: LDAP replication
>  - Wednesday pm: Cross-registry Information Services Protocol
>  - Wednesday eve: IAB Plenary
>  - Thursday eve: IESG Plenary
> 
> Let Jim and me know if you've got items for the agenda.  I am sure
we'll
> discuss RFC2518 bis issues, including how to handle lock tokens &
> trailing slashes.  We may also discuss DASL.
> 
> Lisa