From w3c-dist-auth-request@w3.org  Sat Feb  1 01:12:06 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29709
	for <webdav-archive@lists.ietf.org>; Sat, 1 Feb 2003 01:12:06 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h116EYv04333;
	Sat, 1 Feb 2003 01:14:34 -0500 (EST)
Resent-Date: Sat, 1 Feb 2003 01:14:34 -0500 (EST)
Resent-Message-Id: <200302010614.h116EYv04333@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h116EWD04297
	for <w3c-dist-auth@frink.w3.org>; Sat, 1 Feb 2003 01:14:32 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA26459
	for <w3c-dist-auth@w3c.org>; Sat, 1 Feb 2003 01:14:32 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18eqv8-0008Ig-00; Sat, 01 Feb 2003 06:14:30 +0000
Received: from [198.144.203.248] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18eqv8-0008IV-00; Sat, 01 Feb 2003 06:14:30 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Lisa Dusseault'" <lisa@xythos.com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Fri, 31 Jan 2003 22:14:32 -0800
Message-ID: <007a01c2c9b9$303d9470$f876fea9@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.4024
Importance: Normal
In-Reply-To: <000001c2c31c$c7866710$b701a8c0@xythoslap>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Old-X-Envelope-To: lisa@xythos.com,
 w3c-dist-auth@w3c.org
Subject: RE: Using If and not failing
X-Archived-At: http://www.w3.org/mid/007a01c2c9b9$303d9470$f876fea9@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7184
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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've been looking into this some more. This trick should also work with
tagged lists.  However, since multiple tagged lists are ANDed together
(" If the state of the resource to which the header is applied does not
match any of the specified state lists then the request MUST fail") it
has to be done a little differently.

<no-lock> here represents a lock token that the client made up, which is
intended to Fail.
If: <href1> (<locktoken1> Not <no-lock>) <href2> (<locktoken2> Not
<no-lock>)

This evaluates as 
	((href1 matches locktoken1) OR NOT (href1 matches no-lock))
	AND  ((href2 matches locktoken2) OR NOT (href2 matches no-lock))

I tested this against Xythos WFS, and clients can use this syntax to
make sure that the request does not fail even if locktoken1 or
locktoken2 are no longer there.  Of course this should always be used
with ETag checks. 

lisa


> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com] 
> Sent: Thursday, January 23, 2003 12:20 PM
> To: Webdav WG
> Subject: Using If and not failing
> 
> 
> 
>  
> Did anybody point out that there's an interesting way for the 
> client to
> ensure that the If header never fails the request, by always 
> providing a
> "true" statement?
>  
> -          One or more tokens can be put in parentheses to 
> form a group
> or list
> -          Multiple lists can be included and they are ORed together
>  
> So if the client wants to put a bunch of locktokens in the If 
> header it
> can put any number of them in there, all separated by virtual "OR"s:
>  
> DOSTUFF /resourceurl.html HTTP/1.1
> If: (<locktoken1>) (<locktoken2>) (<locktoken3)
>  
> This request will succeed if the any of the clauses match.
> 
> 
> 
> 




From w3c-dist-auth-request@w3.org  Sat Feb  1 04:55:37 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03063
	for <webdav-archive@lists.ietf.org>; Sat, 1 Feb 2003 04:55:36 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h119w0i26838;
	Sat, 1 Feb 2003 04:58:00 -0500 (EST)
Resent-Date: Sat, 1 Feb 2003 04:58:00 -0500 (EST)
Resent-Message-Id: <200302010958.h119w0i26838@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h119vwD26805
	for <w3c-dist-auth@frink.w3.org>; Sat, 1 Feb 2003 04:57:58 -0500 (EST)
Received: from mail.gmx.net (mail.gmx.net [213.165.65.60])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA23029
	for <w3c-dist-auth@w3c.org>; Sat, 1 Feb 2003 04:57:58 -0500
Received: (qmail 5046 invoked by uid 0); 1 Feb 2003 09:57:50 -0000
Received: from pD950C25E.dip.t-dialin.net (HELO lisa) (217.80.194.94)
  by mail.gmx.net (mp010-rz3) with SMTP; 1 Feb 2003 09:57:50 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Lisa Dusseault" <lisa@xythos.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Sat, 1 Feb 2003 10:57:35 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCCEOPGFAA.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.6604 (9.0.2911.0)
Importance: Normal
In-Reply-To: <007a01c2c9b9$303d9470$f876fea9@xythoslap>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: RE: Using If and not failing
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEOPGFAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7185
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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,

you are aware that this exactly the proposal that Geoff and myself have been
making for some months now?

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: Saturday, February 01, 2003 7:15 AM
> To: 'Lisa Dusseault'; 'Webdav WG'
> Subject: RE: Using If and not failing
>
>
>
>
> I've been looking into this some more. This trick should also work with
> tagged lists.  However, since multiple tagged lists are ANDed together
> (" If the state of the resource to which the header is applied does not
> match any of the specified state lists then the request MUST fail") it
> has to be done a little differently.
>
> <no-lock> here represents a lock token that the client made up, which is
> intended to Fail.
> If: <href1> (<locktoken1> Not <no-lock>) <href2> (<locktoken2> Not
> <no-lock>)
>
> This evaluates as
> 	((href1 matches locktoken1) OR NOT (href1 matches no-lock))
> 	AND  ((href2 matches locktoken2) OR NOT (href2 matches no-lock))
>
> I tested this against Xythos WFS, and clients can use this syntax to
> make sure that the request does not fail even if locktoken1 or
> locktoken2 are no longer there.  Of course this should always be used
> with ETag checks.
>
> lisa
>
>
> > -----Original Message-----
> > From: Lisa Dusseault [mailto:lisa@xythos.com]
> > Sent: Thursday, January 23, 2003 12:20 PM
> > To: Webdav WG
> > Subject: Using If and not failing
> >
> >
> >
> >
> > Did anybody point out that there's an interesting way for the
> > client to
> > ensure that the If header never fails the request, by always
> > providing a
> > "true" statement?
> >
> > -          One or more tokens can be put in parentheses to
> > form a group
> > or list
> > -          Multiple lists can be included and they are ORed together
> >
> > So if the client wants to put a bunch of locktokens in the If
> > header it
> > can put any number of them in there, all separated by virtual "OR"s:
> >
> > DOSTUFF /resourceurl.html HTTP/1.1
> > If: (<locktoken1>) (<locktoken2>) (<locktoken3)
> >
> > This request will succeed if the any of the clauses match.
> >
> >
> >
> >
>
>



From w3c-dist-auth-request@w3.org  Sat Feb  1 10:12:42 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07762
	for <webdav-archive@lists.ietf.org>; Sat, 1 Feb 2003 10:12:42 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h11FF7611463;
	Sat, 1 Feb 2003 10:15:07 -0500 (EST)
Resent-Date: Sat, 1 Feb 2003 10:15:07 -0500 (EST)
Resent-Message-Id: <200302011515.h11FF7611463@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h11FF6D11430
	for <w3c-dist-auth@frink.w3.org>; Sat, 1 Feb 2003 10:15:06 -0500 (EST)
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 KAA30176
	for <w3c-dist-auth@w3c.org>; Sat, 1 Feb 2003 10:15:06 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Sat, 01 Feb 2003 09:59:38 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <C8Q6Q4WA>; Sat, 1 Feb 2003 10:14:34 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE201BC8791@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Sat, 1 Feb 2003 10:14:34 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: Using If and not failing
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE201BC8791@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7186
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


Yes, this proposal appears in the thread 
"Submitting tokens without a validity check"
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0284.html
based on a suggestion from Stefan:
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0390.html 
The final form of this proposal (with constant
tokens) appears in a message from Julian:
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0286.html

Since at the time, Lisa was the only one who
objected to this proposal, it sounds like we
now all agree that this is the right approach?

Cheers,
Geoff


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Saturday, February 01, 2003 4:58 AM
To: Lisa Dusseault; 'Webdav WG'
Subject: RE: Using If and not failing



Lisa,

you are aware that this exactly the proposal that Geoff and myself have been
making for some months now?

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: Saturday, February 01, 2003 7:15 AM
> To: 'Lisa Dusseault'; 'Webdav WG'
> Subject: RE: Using If and not failing
>
>
>
>
> I've been looking into this some more. This trick should also work with
> tagged lists.  However, since multiple tagged lists are ANDed together
> (" If the state of the resource to which the header is applied does not
> match any of the specified state lists then the request MUST fail") it
> has to be done a little differently.
>
> <no-lock> here represents a lock token that the client made up, which is
> intended to Fail.
> If: <href1> (<locktoken1> Not <no-lock>) <href2> (<locktoken2> Not
> <no-lock>)
>
> This evaluates as
> 	((href1 matches locktoken1) OR NOT (href1 matches no-lock))
> 	AND  ((href2 matches locktoken2) OR NOT (href2 matches no-lock))
>
> I tested this against Xythos WFS, and clients can use this syntax to
> make sure that the request does not fail even if locktoken1 or
> locktoken2 are no longer there.  Of course this should always be used
> with ETag checks.
>
> lisa
>
>
> > -----Original Message-----
> > From: Lisa Dusseault [mailto:lisa@xythos.com]
> > Sent: Thursday, January 23, 2003 12:20 PM
> > To: Webdav WG
> > Subject: Using If and not failing
> >
> >
> >
> >
> > Did anybody point out that there's an interesting way for the
> > client to
> > ensure that the If header never fails the request, by always
> > providing a
> > "true" statement?
> >
> > -          One or more tokens can be put in parentheses to
> > form a group
> > or list
> > -          Multiple lists can be included and they are ORed together
> >
> > So if the client wants to put a bunch of locktokens in the If
> > header it
> > can put any number of them in there, all separated by virtual "OR"s:
> >
> > DOSTUFF /resourceurl.html HTTP/1.1
> > If: (<locktoken1>) (<locktoken2>) (<locktoken3)
> >
> > This request will succeed if the any of the clauses match.
> >
> >
> >
> >
>
>



From w3c-dist-auth-request@w3.org  Sat Feb  1 14:08:02 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14605
	for <webdav-archive@lists.ietf.org>; Sat, 1 Feb 2003 14:08:02 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h11J8jG10279;
	Sat, 1 Feb 2003 14:08:45 -0500 (EST)
Resent-Date: Sat, 1 Feb 2003 14:08:45 -0500 (EST)
Resent-Message-Id: <200302011908.h11J8jG10279@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h11J8hD10247
	for <w3c-dist-auth@frink.w3.org>; Sat, 1 Feb 2003 14:08:43 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA27023
	for <w3c-dist-auth@w3c.org>; Sat, 1 Feb 2003 14:08:43 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18f30D-00022N-00; Sat, 01 Feb 2003 19:08:33 +0000
Received: from [198.144.203.248] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18f30D-00022C-00; Sat, 01 Feb 2003 19:08:33 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Sat, 1 Feb 2003 11:08:36 -0800
Message-ID: <009b01c2ca25$52921020$f876fea9@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.4024
Importance: Normal
In-Reply-To: <JIEGINCHMLABHJBIGKBCCEOPGFAA.julian.reschke@gmx.de>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Old-X-Envelope-To: julian.reschke@gmx.de,
 w3c-dist-auth@w3c.org
Subject: RE: Using If and not failing
X-Archived-At: http://www.w3.org/mid/009b01c2ca25$52921020$f876fea9@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7187
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 am aware it's the same solution in spirit. However, a slight
tweak makes it a little shorter, or in the the untagged list case, quite
a bit shorter.

Your proposal was (mail from Tue 10/8/2002):
  If: <http://www.foo.bar/resource1>
(<locktoken:a-write-lock-token>)(Not <locktoken:a-write-lock-token>))

That's rather long, and it's unnecessary to put a real lock token in the
negative clause.  The client can at least shrink the header a bit using
  If: <http://www.foo.bar/resource1>
(<locktoken:a-write-lock-token>)(Not <no-lock>)

But if the client can get away with using an untagged list production,
it's even shorter:
  If: (<locktoken:a-write-lock-token>) (Not <no-lock>)

RFC2518: "If multiple No-tag-list productions are used then one only
needs to match the state of the resource for the method to be allowed to
continue."

Lisa

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de] 
> Sent: Saturday, February 01, 2003 1:58 AM
> To: Lisa Dusseault; 'Webdav WG'
> Subject: RE: Using If and not failing
> 
> 
> Lisa,
> 
> you are aware that this exactly the proposal that Geoff and 
> myself have been
> making for some months now?
> 
> Julian
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 




From w3c-dist-auth-request@w3.org  Sat Feb  1 14:26:02 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14825
	for <webdav-archive@lists.ietf.org>; Sat, 1 Feb 2003 14:26:01 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h11JRML13444;
	Sat, 1 Feb 2003 14:27:22 -0500 (EST)
Resent-Date: Sat, 1 Feb 2003 14:27:22 -0500 (EST)
Resent-Message-Id: <200302011927.h11JRML13444@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h11JRKD13407
	for <w3c-dist-auth@frink.w3.org>; Sat, 1 Feb 2003 14:27:20 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA29323
	for <w3c-dist-auth@w3c.org>; Sat, 1 Feb 2003 14:27:20 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18f3IJ-000271-00; Sat, 01 Feb 2003 19:27:15 +0000
Received: from [198.144.203.248] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18f3II-00026q-00; Sat, 01 Feb 2003 19:27:15 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Clemm, Geoff'" <gclemm@rational.com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Sat, 1 Feb 2003 11:27:17 -0800
Message-ID: <009d01c2ca27$ef254e50$f876fea9@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.4024
Importance: Normal
In-Reply-To: <E4F2D33B98DF7E4880884B9F0E6FDEE201BC8791@SUS-MA1IT01>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Old-X-Envelope-To: gclemm@rational.com,
 w3c-dist-auth@w3c.org
Subject: RE: Using If and not failing
X-Archived-At: http://www.w3.org/mid/009d01c2ca27$ef254e50$f876fea9@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7188
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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



To be clear, I did not object to the proposal per se.  I've been echoing
the recommendation that it's at least a good interim solution, and I
only tweaked the solution you call the "final form" in my recent emails.

However, I felt the proposal wasn't sufficient to completely solve the
interoperability problems.  I still worry on that point, and I'm *not*
the only one.  

 - Jim W has expressed concern that any proposal that allows the If
header to succeed regardless of server state is weakening the ability of
the If header to correct the client's incorrect state. That objection
applied both to a "here are all my locktokens" approach and to the
proposals showing how to work around the current syntax.

 - Dan Brotsky saw these proposals and still felt strongly that a much
more simple approach was necessary for long-term interoperability.

In other words, we're not done yet.  We are still refining our
understanding of various issues and proposals surrounding the If header.
The If header still has other problems:

 - the "ignored clauses" that the list decided shouldn't be ignored
 - Uncertainty or at least implementation differences in what locks are
required to do various operations
 - Confusion on whether multiple lists are ANDed together (tagged list)
or ORed together (no-tag)
 - You(geoff) suggested dropping the no-tag-list production (Oct 7 2002)
 - Jason suggested that no-tag-list production always apply to
Request-URI only (Oct 12 2002)

We still need more input from more WG members. 

Lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff
> Sent: Saturday, February 01, 2003 7:15 AM
> To: 'Webdav WG'
> Subject: RE: Using If and not failing
> 
> 
> 
> Yes, this proposal appears in the thread 
> "Submitting tokens without a validity check"
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0284.html
> based on a suggestion from Stefan:
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0
> 390.html 
> The final form of this proposal (with constant
> tokens) appears in a message from Julian:
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0286.html
> 
> Since at the time, Lisa was the only one who
> objected to this proposal, it sounds like we
> now all agree that this is the right approach?
> 
> Cheers,
> Geoff
> 
> 
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Saturday, February 01, 2003 4:58 AM
> To: Lisa Dusseault; 'Webdav WG'
> Subject: RE: Using If and not failing
> 
> 
> 
> Lisa,
> 
> you are aware that this exactly the proposal that Geoff and 
> myself have been
> making for some months now?
> 
> 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: Saturday, February 01, 2003 7:15 AM
> > To: 'Lisa Dusseault'; 'Webdav WG'
> > Subject: RE: Using If and not failing
> >
> >
> >
> >
> > I've been looking into this some more. This trick should 
> also work with
> > tagged lists.  However, since multiple tagged lists are 
> ANDed together
> > (" If the state of the resource to which the header is 
> applied does not
> > match any of the specified state lists then the request 
> MUST fail") it
> > has to be done a little differently.
> >
> > <no-lock> here represents a lock token that the client made 
> up, which is
> > intended to Fail.
> > If: <href1> (<locktoken1> Not <no-lock>) <href2> (<locktoken2> Not
> > <no-lock>)
> >
> > This evaluates as
> > 	((href1 matches locktoken1) OR NOT (href1 matches no-lock))
> > 	AND  ((href2 matches locktoken2) OR NOT (href2 matches no-lock))
> >
> > I tested this against Xythos WFS, and clients can use this syntax to
> > make sure that the request does not fail even if locktoken1 or
> > locktoken2 are no longer there.  Of course this should 
> always be used
> > with ETag checks.
> >
> > lisa
> >
> >
> > > -----Original Message-----
> > > From: Lisa Dusseault [mailto:lisa@xythos.com]
> > > Sent: Thursday, January 23, 2003 12:20 PM
> > > To: Webdav WG
> > > Subject: Using If and not failing
> > >
> > >
> > >
> > >
> > > Did anybody point out that there's an interesting way for the
> > > client to
> > > ensure that the If header never fails the request, by always
> > > providing a
> > > "true" statement?
> > >
> > > -          One or more tokens can be put in parentheses to
> > > form a group
> > > or list
> > > -          Multiple lists can be included and they are 
> ORed together
> > >
> > > So if the client wants to put a bunch of locktokens in the If
> > > header it
> > > can put any number of them in there, all separated by 
> virtual "OR"s:
> > >
> > > DOSTUFF /resourceurl.html HTTP/1.1
> > > If: (<locktoken1>) (<locktoken2>) (<locktoken3)
> > >
> > > This request will succeed if the any of the clauses match.
> > >
> > >
> > >
> > >
> >
> >
> 
> 




From w3c-dist-auth-request@w3.org  Sat Feb  1 14:56:39 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15212
	for <webdav-archive@lists.ietf.org>; Sat, 1 Feb 2003 14:56:39 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h11JxCo16738;
	Sat, 1 Feb 2003 14:59:12 -0500 (EST)
Resent-Date: Sat, 1 Feb 2003 14:59:12 -0500 (EST)
Resent-Message-Id: <200302011959.h11JxCo16738@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h11JxBD16706
	for <w3c-dist-auth@frink.w3.org>; Sat, 1 Feb 2003 14:59:11 -0500 (EST)
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 OAA32728
	for <w3c-dist-auth@w3c.org>; Sat, 1 Feb 2003 14:59:10 -0500
Received: (qmail 3574 invoked by uid 0); 1 Feb 2003 19:58:47 -0000
Received: from pD950C25E.dip.t-dialin.net (HELO lisa) (217.80.194.94)
  by mail.gmx.net (mp017-rz3) with SMTP; 1 Feb 2003 19:58:47 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Sat, 1 Feb 2003 20:58:38 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCCEPHGFAA.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.6604 (9.0.2911.0)
In-Reply-To: <009b01c2ca25$52921020$f876fea9@xythoslap>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: RE: Using If and not failing
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEPHGFAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7189
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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,

please see:

	http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0286.html

:-)

BTW: the token will still need to be a syntactically valid legal, so it MUST
contain a (registered) scheme name, thus the proposal to use "DAV:no-lock".

Julian

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

> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Saturday, February 01, 2003 8:09 PM
> To: 'Julian Reschke'; 'Webdav WG'
> Subject: RE: Using If and not failing
>
>
> Yes, I am aware it's the same solution in spirit. However, a slight
> tweak makes it a little shorter, or in the the untagged list case, quite
> a bit shorter.
>
> Your proposal was (mail from Tue 10/8/2002):
>   If: <http://www.foo.bar/resource1>
> (<locktoken:a-write-lock-token>)(Not <locktoken:a-write-lock-token>))
>
> That's rather long, and it's unnecessary to put a real lock token in the
> negative clause.  The client can at least shrink the header a bit using
>   If: <http://www.foo.bar/resource1>
> (<locktoken:a-write-lock-token>)(Not <no-lock>)
>
> But if the client can get away with using an untagged list production,
> it's even shorter:
>   If: (<locktoken:a-write-lock-token>) (Not <no-lock>)
>
> RFC2518: "If multiple No-tag-list productions are used then one only
> needs to match the state of the resource for the method to be allowed to
> continue."
>
> Lisa
>
> > -----Original Message-----
> > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > Sent: Saturday, February 01, 2003 1:58 AM
> > To: Lisa Dusseault; 'Webdav WG'
> > Subject: RE: Using If and not failing
> >
> >
> > Lisa,
> >
> > you are aware that this exactly the proposal that Geoff and
> > myself have been
> > making for some months now?
> >
> > Julian
> >
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >
>
>



From w3c-dist-auth-request@w3.org  Sat Feb  1 15:09:11 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15390
	for <webdav-archive@lists.ietf.org>; Sat, 1 Feb 2003 15:09:11 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h11KB0Z17714;
	Sat, 1 Feb 2003 15:11:00 -0500 (EST)
Resent-Date: Sat, 1 Feb 2003 15:11:00 -0500 (EST)
Resent-Message-Id: <200302012011.h11KB0Z17714@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h11KAwD17681
	for <w3c-dist-auth@frink.w3.org>; Sat, 1 Feb 2003 15:10:58 -0500 (EST)
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 PAA01629
	for <w3c-dist-auth@w3c.org>; Sat, 1 Feb 2003 15:10:57 -0500
Received: (qmail 14694 invoked by uid 0); 1 Feb 2003 20:10:26 -0000
Received: from pD950C25E.dip.t-dialin.net (HELO lisa) (217.80.194.94)
  by mail.gmx.net (mp021-rz3) with SMTP; 1 Feb 2003 20:10:26 -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: Sat, 1 Feb 2003 21:10:17 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCAEPIGFAA.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.6604 (9.0.2911.0)
In-Reply-To: <009d01c2ca27$ef254e50$f876fea9@xythoslap>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: RE: Using If and not failing
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEPIGFAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7190
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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: Saturday, February 01, 2003 8:27 PM
> To: 'Clemm, Geoff'; 'Webdav WG'
> Subject: RE: Using If and not failing
>
>
>
>
> To be clear, I did not object to the proposal per se.  I've been echoing
> the recommendation that it's at least a good interim solution, and I
> only tweaked the solution you call the "final form" in my recent emails.
>
> However, I felt the proposal wasn't sufficient to completely solve the
> interoperability problems.  I still worry on that point, and I'm *not*
> the only one.
>
>  - Jim W has expressed concern that any proposal that allows the If
> header to succeed regardless of server state is weakening the ability of
> the If header to correct the client's incorrect state. That objection
> applied both to a "here are all my locktokens" approach and to the
> proposals showing how to work around the current syntax.

Technically speaking, they *don't* workaround the server state. The client
says "let the request succeed if my locktoken is still valid, or if it's
gone", and this is what happens. This works *by design*. Not that I think
that it's ever a good idea to send this kind of request.

>  - Dan Brotsky saw these proposals and still felt strongly that a much
> more simple approach was necessary for long-term interoperability.

I'd like to hear that directly from him, not as hear-say. In particular, it
would be nice if the group of client programmers that thinks that there *is*
an issue would actually sit down and try how the proposed usage of the
existing If header turns out to work.

> In other words, we're not done yet.  We are still refining our
> understanding of various issues and proposals surrounding the If header.
> The If header still has other problems:
>
>  - the "ignored clauses" that the list decided shouldn't be ignored
>  - Uncertainty or at least implementation differences in what locks are
> required to do various operations

-> GULP.

>  - Confusion on whether multiple lists are ANDed together (tagged list)
> or ORed together (no-tag)

Could you please explain the nature of the problem?

>  - You(geoff) suggested dropping the no-tag-list production (Oct 7 2002)
>  - Jason suggested that no-tag-list production always apply to
> Request-URI only (Oct 12 2002)

That was my impression as well.

> We still need more input from more WG members.

On the other hand, we've been working on this issue for almost 6 months
wiith little progress. So my *concrete* proposal about how to proceed is:

1) allow comma separated notation for tagged lists (to workaround proxy
limitations)

2) use GULP as a basis to clearly explain which resources are affected

3) add a set of the tests I wrote to Litmus

4) write a separate document (?) that gives guidelines on "safe" authoring.

Note that if we left out 2), this would be no change for RFC2518 at all, and
all servers compliant to RFC2518 should already behave as desired.


Julian


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



From w3c-dist-auth-request@w3.org  Sat Feb  1 20:03:09 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18327
	for <webdav-archive@lists.ietf.org>; Sat, 1 Feb 2003 20:03:09 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1215N005327;
	Sat, 1 Feb 2003 20:05:23 -0500 (EST)
Resent-Date: Sat, 1 Feb 2003 20:05:23 -0500 (EST)
Resent-Message-Id: <200302020105.h1215N005327@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1215MD05295
	for <w3c-dist-auth@frink.w3.org>; Sat, 1 Feb 2003 20:05:22 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA07507
	for <w3c-dist-auth@w3c.org>; Sat, 1 Feb 2003 20:05:21 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18f8ZU-0003Ff-00; Sun, 02 Feb 2003 01:05:20 +0000
Received: from [198.144.203.248] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18f8ZT-0003F5-00; Sun, 02 Feb 2003 01:05:19 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>,
        "'Clemm, Geoff'" <gclemm@rational.com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Sat, 1 Feb 2003 17:05:22 -0800
Message-ID: <00b601c2ca57$29921440$f876fea9@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.4024
Importance: Normal
In-Reply-To: <JIEGINCHMLABHJBIGKBCAEPIGFAA.julian.reschke@gmx.de>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Old-X-Envelope-To: gclemm@rational.com,
 julian.reschke@gmx.de,
 w3c-dist-auth@w3c.org
Subject: RE: Using If and not failing
X-Archived-At: http://www.w3.org/mid/00b601c2ca57$29921440$f876fea9@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7191
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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



> >  - Dan Brotsky saw these proposals and still felt strongly 
> that a much
> > more simple approach was necessary for long-term interoperability.
> 
> I'd like to hear that directly from him, not as hear-say. In 
> particular, it
> would be nice if the group of client programmers that thinks 
> that there *is*
> an issue would actually sit down and try how the proposed usage of the
> existing If header turns out to work.

Please see:
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0118.html

> >  - Confusion on whether multiple lists are ANDed together 
> (tagged list)
> > or ORed together (no-tag)
> 
> Could you please explain the nature of the problem?

Section 9.4.1, No-tag-list production:

"If multiple No-tag-list productions are used then one only needs to
match the state of the resource for the method to be allowed to
continue." 

Conclusion: multiple untagged lists only one needs to match --> OR

Section 9.4.2, Tagged-list Production:

"When the If header is applied to a particular resource, the Tagged-
list productions MUST be searched to determine if any of the listed
resources match the operand resource(s) for the current method. If none
of the resource productions match the current resource then the header
MUST be ignored. If one of the resource productions does match the name
of the resource under consideration then the list productions following
the resource production MUST be applied to the resource in the manner
specified in the previous section. "

Conclusion: multiple tagged lists each needs to match --> AND

Note that in the previous quoted paragraphs, the part about ignoring
clauses will be removed if we continue by our previous consensus.

One of your proposals:
> 1) allow comma separated notation for tagged lists (to 
> workaround proxy
> limitations)

This completely breaks the syntax of the header for clients sending
requests to servers that don't immediately support 2518bis.  Clients
wouldn't actually be able to use commas for years because there is
currently no way to see if a server supports 2518bis.  I'm pointing this
out because if we decide to do this, we have to be clear on
understanding it's not going to be very useful for a long time.

Lisa




From w3c-dist-auth-request@w3.org  Sun Feb  2 05:58:40 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04272
	for <webdav-archive@lists.ietf.org>; Sun, 2 Feb 2003 05:58:39 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h12B0qJ07080;
	Sun, 2 Feb 2003 06:00:52 -0500 (EST)
Resent-Date: Sun, 2 Feb 2003 06:00:52 -0500 (EST)
Resent-Message-Id: <200302021100.h12B0qJ07080@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h12B0pD07044
	for <w3c-dist-auth@frink.w3.org>; Sun, 2 Feb 2003 06:00:51 -0500 (EST)
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 GAA15472
	for <w3c-dist-auth@w3c.org>; Sun, 2 Feb 2003 06:00:50 -0500
Received: (qmail 23309 invoked by uid 0); 2 Feb 2003 11:00:14 -0000
Received: from p3EE24727.dip.t-dialin.net (HELO lisa) (62.226.71.39)
  by mail.gmx.net (mp013-rz3) with SMTP; 2 Feb 2003 11:00:14 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Sun, 2 Feb 2003 11:59:58 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCIEABGGAA.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.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <00b601c2ca57$29921440$f876fea9@xythoslap>
Importance: Normal
Subject: RE: Using If and not failing
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEABGGAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7192
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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, February 02, 2003 2:05 AM
> To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG'
> Subject: RE: Using If and not failing
>
> ...
>
> One of your proposals:
> > 1) allow comma separated notation for tagged lists (to
> > workaround proxy
> > limitations)
>
> This completely breaks the syntax of the header for clients sending
> requests to servers that don't immediately support 2518bis.  Clients
> wouldn't actually be able to use commas for years because there is
> currently no way to see if a server supports 2518bis.  I'm pointing this
> out because if we decide to do this, we have to be clear on
> understanding it's not going to be very useful for a long time.

Yes.

I wrote:

> Note that if we left out 2), this would be no change for RFC2518 at all,
and
> all servers compliant to RFC2518 should already behave as desired.

but I *meant* to write:

Note that if we left out 1), this would be no change for RFC2518 at all, and
all servers compliant to RFC2518 should already behave as desired.


What you say is true and applies to *any* "new" feature in RFC2518bis --
therefore it makes sense to avoid them wherever possible (thus the proposal
to use the If header instead of inventing a new header).



Julian

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



From w3c-dist-auth-request@w3.org  Sun Feb  2 06:06:31 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04340
	for <webdav-archive@lists.ietf.org>; Sun, 2 Feb 2003 06:06:31 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h12B9CV07778;
	Sun, 2 Feb 2003 06:09:12 -0500 (EST)
Resent-Date: Sun, 2 Feb 2003 06:09:12 -0500 (EST)
Resent-Message-Id: <200302021109.h12B9CV07778@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h12B9BD07746
	for <w3c-dist-auth@frink.w3.org>; Sun, 2 Feb 2003 06:09:11 -0500 (EST)
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 GAA16271
	for <w3c-dist-auth@w3c.org>; Sun, 2 Feb 2003 06:09:11 -0500
Received: (qmail 12006 invoked by uid 0); 2 Feb 2003 11:08:35 -0000
Received: from p3EE24727.dip.t-dialin.net (HELO lisa) (62.226.71.39)
  by mail.gmx.net (mp015-rz3) with SMTP; 2 Feb 2003 11:08:35 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Sun, 2 Feb 2003 12:08:16 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCIEACGGAA.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.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <00b601c2ca57$29921440$f876fea9@xythoslap>
Importance: Normal
Subject: RE: Using If and not failing
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEACGGAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7193
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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, February 02, 2003 2:05 AM
> To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG'
> Subject: RE: Using If and not failing
>
>
>
>
> > >  - Dan Brotsky saw these proposals and still felt strongly that a much
> > > more simple approach was necessary for long-term interoperability.
> >
> > I'd like to hear that directly from him, not as hear-say. In particular,
it
> > would be nice if the group of client programmers that thinks that there
*is*
> > an issue would actually sit down and try how the proposed usage of the
> > existing If header turns out to work.
>
> Please see:
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0118.html
>
> ...

I'm aware of the original mail.

Fact is, there has been extensive dicussion about this mail (with Dan *not*
returning to the list). We have tried to analyze the problem, and we have
made proposals how to achieve the desired semantics. I even posted a test
suite.

We are now waiting for feedback, in particular a discussion whether our
proposal works for the clients or not (in which case they need to explain
*why*). It seems to be impossible to get this kind of feedback. Until we get
it, I'd propose to consider this particular issue (how to let a request
succeed when the lock token is known, but the lock has gone away) as closed.

Julian

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



From w3c-dist-auth-request@w3.org  Sun Feb  2 09:35:46 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06314
	for <webdav-archive@lists.ietf.org>; Sun, 2 Feb 2003 09:35:46 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h12EcGR06108;
	Sun, 2 Feb 2003 09:38:16 -0500 (EST)
Resent-Date: Sun, 2 Feb 2003 09:38:16 -0500 (EST)
Resent-Message-Id: <200302021438.h12EcGR06108@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h12EcFD06057
	for <w3c-dist-auth@frink.w3.org>; Sun, 2 Feb 2003 09:38:15 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA11648
	for <w3c-dist-auth@w3c.org>; Sun, 2 Feb 2003 09:38:14 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18fLG9-0006lH-00; Sun, 02 Feb 2003 14:38:13 +0000
Received: from [198.144.203.248] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18fLG8-0006l6-00; Sun, 02 Feb 2003 14:38:13 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Sun, 2 Feb 2003 06:38:14 -0800
Message-ID: <00c901c2cac8$b840ce40$f876fea9@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.4024
Importance: Normal
In-Reply-To: <JIEGINCHMLABHJBIGKBCIEABGGAA.julian.reschke@gmx.de>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Old-X-Envelope-To: julian.reschke@gmx.de,
 w3c-dist-auth@w3c.org
Subject: RE: Using If and not failing
X-Archived-At: http://www.w3.org/mid/00c901c2cac8$b840ce40$f876fea9@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7194
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


Previous conversation abridged: 

> > One of your proposals:
> > > 1) allow comma separated notation for tagged lists (to
> > > workaround proxy
> > > limitations)
> >
> > This completely breaks the syntax of the header for clients sending
> > requests to servers that don't immediately support 2518bis.  Clients
> > wouldn't actually be able to use commas for years because there is
> > currently no way to see if a server supports 2518bis.  I'm 
> pointing this
> > out because if we decide to do this, we have to be clear on
> > understanding it's not going to be very useful for a long time.
> 
> What you say is true and applies to *any* "new" feature in 
> RFC2518bis --
> therefore it makes sense to avoid them wherever possible 
> (thus the proposal
> to use the If header instead of inventing a new header).

I don't think my logic supports your conclusion.

Adding commas to the If header is *exactly* as disruptive as inventing a
new header.  
 - At first, clients will not support this, knowing that very few
servers support the new syntax or header, and having no easy way to
distinguish
 - Later, some clients may include logic to do both/either once many
servers support the new syntax or header
 - Finally, in a few years, most clients will move to the new paradigm,
*if* it adds value, once all servers are known to support the new syntax
or header.
 - If the change does not add sufficient value, clients will never
switch over.

Given that changing the syntax and adding a header are identical in
interoperability cost, if we rule out one solely because of the cost we
logically rule out the other.  

Lisa




From w3c-dist-auth-request@w3.org  Sun Feb  2 13:23:20 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09970
	for <webdav-archive@lists.ietf.org>; Sun, 2 Feb 2003 13:23:20 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h12IPGS01042;
	Sun, 2 Feb 2003 13:25:16 -0500 (EST)
Resent-Date: Sun, 2 Feb 2003 13:25:16 -0500 (EST)
Resent-Message-Id: <200302021825.h12IPGS01042@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h12IPDD01010
	for <w3c-dist-auth@frink.w3.org>; Sun, 2 Feb 2003 13:25:13 -0500 (EST)
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 NAA05132
	for <w3c-dist-auth@w3c.org>; Sun, 2 Feb 2003 13:25:13 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Sun, 02 Feb 2003 13:09:43 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <C8Q6RDQV>; Sun, 2 Feb 2003 13:24:41 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE201BC87D0@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Sun, 2 Feb 2003 13:24:40 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: Using If and not failing
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE201BC87D0@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7195
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 have been two ways proposed to submit lock tokens
without the request failing if the locks don't match:

(1) Extend the if header syntax to allow comma 
separated lists, and use "NOT (<DAV:no-lock>)" pattern
if you want to ignore whether the locks are valid.

(2) Add a new header.

Both of these involve extending the protocol, so we do
need some way of letting the client know that it is
talking to a 2518bis server (so that it knows whether
or not to use the extension).  Let us just then move
forward on the assumption that we will define some 
appropriate new value for the DAV: header.

Now as for deciding between which of these two approaches
to use:

The advantage of the first approach is that it is needed
anyway for correct use of the locking protocol for COPY
or MOVE when a large number of locks are present.
So we should make this extension in 2518bis, whether or
not we believe the protocol should support ignoring
invalid locks.  But once we make this needed change, the
new header becomes redundant.

Therefore I strongly prefer approach (1).  I also strongly
prefer that we settle this issue once and for all, and move
on.  

Cheers,
Geoff
 



From w3c-dist-auth-request@w3.org  Sun Feb  2 15:55:18 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11691
	for <webdav-archive@lists.ietf.org>; Sun, 2 Feb 2003 15:55:18 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h12KtQr12606;
	Sun, 2 Feb 2003 15:55:26 -0500 (EST)
Resent-Date: Sun, 2 Feb 2003 15:55:26 -0500 (EST)
Resent-Message-Id: <200302022055.h12KtQr12606@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h12KtOD12574
	for <w3c-dist-auth@frink.w3.org>; Sun, 2 Feb 2003 15:55:24 -0500 (EST)
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 PAA21022
	for <w3c-dist-auth@w3c.org>; Sun, 2 Feb 2003 15:55:24 -0500
Received: (qmail 463 invoked by uid 0); 2 Feb 2003 20:54:48 -0000
Received: from p3EE24727.dip.t-dialin.net (HELO lisa) (62.226.71.39)
  by mail.gmx.net (mp016-rz3) with SMTP; 2 Feb 2003 20:54:48 -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: Sun, 2 Feb 2003 21:54:16 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCCEBBGGAA.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.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <00c901c2cac8$b840ce40$f876fea9@xythoslap>
Importance: Normal
Subject: RE: Using If and not failing
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEBBGGAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7196
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


> Previous conversation abridged:
>
> > > One of your proposals:
> > > > 1) allow comma separated notation for tagged lists (to
> > > > workaround proxy
> > > > limitations)
> > >
> > > This completely breaks the syntax of the header for clients sending
> > > requests to servers that don't immediately support 2518bis.  Clients
> > > wouldn't actually be able to use commas for years because there is
> > > currently no way to see if a server supports 2518bis.  I'm
> > pointing this
> > > out because if we decide to do this, we have to be clear on
> > > understanding it's not going to be very useful for a long time.
> >
> > What you say is true and applies to *any* "new" feature in
> > RFC2518bis --
> > therefore it makes sense to avoid them wherever possible
> > (thus the proposal
> > to use the If header instead of inventing a new header).
>
> I don't think my logic supports your conclusion.
>
> Adding commas to the If header is *exactly* as disruptive as inventing a
> new header.

Yes.

However, we *already* have the desired behaviour (for the conditional
operation). So this is something that is already supported by RFC2518, and
we should use it. Clients can use it *now*.

The *only* thing that's missing (and it's only a problem when there are
misbehaving proxies in the communication path) is the change to allow comma
separated lists. Whether we do *that* change is a completely separate issue.


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



From w3c-dist-auth-request@w3.org  Sun Feb  2 23:26:47 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18310
	for <webdav-archive@lists.ietf.org>; Sun, 2 Feb 2003 23:26:42 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h134T0h27901;
	Sun, 2 Feb 2003 23:29:00 -0500 (EST)
Resent-Date: Sun, 2 Feb 2003 23:29:00 -0500 (EST)
Resent-Message-Id: <200302030429.h134T0h27901@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h134SxD27869
	for <w3c-dist-auth@frink.w3.org>; Sun, 2 Feb 2003 23:28:59 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA12266
	for <w3c-dist-auth@w3c.org>; Sun, 2 Feb 2003 23:28:59 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18fYE6-0002rd-00
	for w3c-dist-auth@w3c.org; Mon, 03 Feb 2003 04:28:58 +0000
Received: from [198.144.203.248] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18fYE6-0002rS-00
	for w3c-dist-auth@w3c.org; Mon, 03 Feb 2003 04:28:58 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Sun, 2 Feb 2003 20:28:58 -0800
Message-ID: <00f201c2cb3c$c5d804a0$f876fea9@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.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Subject: Normative reference updates
X-Archived-At: http://www.w3.org/mid/00f201c2cb3c$c5d804a0$f876fea9@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7197
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 just noticed that since RFC2518, a bunch of WebDAV's normative
references have themselves been updated, not just HTTP 1.1.

HTTP: RFC2068 --> RFC2616
I'm pretty sure this one's OK - I've looked at 2616 pretty thoroughly
and never noticed anything that WebDAV wasn't compliant with.

Language identification: RFC1766 obsoleted by two documents
 - RFC3066, "Best Current Practice" 
 - RFC3282, Draft Standard
 - Which of these two -- or both -- does RFC2518bis need to make
normative reference to? Informational reference?  Are there any changes
which would require changes in WebDAV?

REC-XML 
 - http://www.w3.org/TR/1998/REC-xml-19980210 was updated to
http://www.w3.org/TR/2000/REC-xml-20001006
 - Any changes required to WebDAV?

Digest Auth, RFC2069 --> RFC2617
 - Any changes required?

ISO-* -- I don't know

These normative references have not changed their status:
URN Syntax, RFC2141 - still proposed standard
UTF8, RFC2279 - still draft standard
Charset, RFC2277 -- still best current practice
Compliance keywords, RFC2199 -- still Best Current Practice
URI, RFC2396 -- still Draft standard

That means three new normative references definitely need to be reviewed
to make sure we're staying compliant.  Any volunteers for any of them?
Anybody know about the ISO standards?

Lisa




From w3c-dist-auth-request@w3.org  Sun Feb  2 23:54:25 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18553
	for <webdav-archive@lists.ietf.org>; Sun, 2 Feb 2003 23:54:25 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h134uG229531;
	Sun, 2 Feb 2003 23:56:16 -0500 (EST)
Resent-Date: Sun, 2 Feb 2003 23:56:16 -0500 (EST)
Resent-Message-Id: <200302030456.h134uG229531@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h134uED29495
	for <w3c-dist-auth@frink.w3.org>; Sun, 2 Feb 2003 23:56:14 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA14778
	for <w3c-dist-auth@w3c.org>; Sun, 2 Feb 2003 23:56:14 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18fYeT-0002yw-00; Mon, 03 Feb 2003 04:56:13 +0000
Received: from [198.144.203.248] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18fYeS-0002yl-00; Mon, 03 Feb 2003 04:56:13 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>, <w3c-dist-auth@w3c.org>
Date: Sun, 2 Feb 2003 20:56:13 -0800
Message-ID: <00f401c2cb40$9439b2f0$f876fea9@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.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Old-X-Envelope-To: julian.reschke@gmx.de,
 w3c-dist-auth@w3c.org
Subject: RE: Summary of If header eval tests
X-Archived-At: http://www.w3.org/mid/00f401c2cb40$9439b2f0$f876fea9@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7198
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 it's great that you've done this research. It helps to get some
real data into our planning!

> So contrary to what we believed, protecting conditional PUTs 
> using strong
> etags currently does not interoperate well at all.
>
> How do we move forward on this issue?

I'm not sure.  Here's my guess:
 - Decide that preventing lost updates is actually important
 - Decide that strong ETags is the only way to do that effectively 
 - Exhort server implementors to do a better job of Etags and If header
 - Put the tests in Litmus -- which I understand you're already doing --
and announce
 - Hold another interoperability event where we record the results of
this effort

That holds back draft standard until we can hold another interop event,
but if we hold another summer interop as we have the last two years,
draft standard would probably take that long anyway.

Any other ideas? 

Lisa 




From w3c-dist-auth-request@w3.org  Mon Feb  3 05:48:53 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02401
	for <webdav-archive@lists.ietf.org>; Mon, 3 Feb 2003 05:48:53 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h13Aorl07238;
	Mon, 3 Feb 2003 05:50:53 -0500 (EST)
Resent-Date: Mon, 3 Feb 2003 05:50:53 -0500 (EST)
Resent-Message-Id: <200302031050.h13Aorl07238@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h13AoqD07188
	for <w3c-dist-auth@frink.w3.org>; Mon, 3 Feb 2003 05:50:52 -0500 (EST)
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 FAA31978
	for <w3c-dist-auth@w3c.org>; Mon, 3 Feb 2003 05:50:51 -0500
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, 03 Feb 2003 11:49:45 +0100
Date: Mon, 3 Feb 2003 11:49:59 +0100
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: w3c-dist-auth@w3c.org
To: Jim Luther <luther.j@apple.com>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <7014771D-3541-11D7-B386-0003934B6A22@apple.com>
Message-Id: <3DAFB683-3765-11D7-A23E-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: Is HTTP/1.1 required for WebDAV?
X-Archived-At: http://www.w3.org/mid/3DAFB683-3765-11D7-A23E-00039384827E@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7199
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 Freitag, 31.01.03, um 18:28 Uhr (Europe/Berlin) schrieb Jim Luther:

>
> I thought it was pretty clear in rfc2518 (and rfc2518 bis) that WebDAV 
> servers and clients are HTTP/1.1 servers and clients because the 
> introduction section of the rfc starts off, "This document describes 
> an extension to the HTTP/1.1 protocol that allows clients to perform 
> remote web content authoring operations."

I agree that WebDAV server and clients should implement HTTP/1.1.

> However, during interoperability testing I've found several servers 
> which return HTTP/1.0 in the Status-Line of their response message and 
> behave as HTTP/1.0 servers (i.e., they do not handle HTTP/1.1 
> persistent connections correctly, there are no Content-Length headers 
> in a response with a message-body, etc.). For the most part, the Mac 
> OS X WebDAV file system client works with these servers but it works 
> much slower because of transaction aborts and retries.

So, servers implementing 1.1 are rewarded with better performance/user 
perception. Good.

>
> Should WebDAV clients refuse to use HTTP/1.0 servers and should WebDAV 
> servers refuse to work with HTTP/1.0 clients?

I think refusing to interop with a HTTP/1.0 server is not the intention 
of HTTP/1.1. Contrary,
HTTP/1.1 was carefully designed to allow interoperability. Even if all 
servers support HTTP/1.1,
there are a lot of poxies wich only support HTTP/1.0. SAP's 
implementation will therefore
keep support for HTTP/1.0.

>
> If yes, should rfc2518 bis make HTTP/1.1 (or later) a MUST?
>
I think it does already, maybe it should say so in a stronger way. But 
I doubt that
it will have the consequences for your production code that you'd like 
to have.

//Stefan





From w3c-dist-auth-request@w3.org  Mon Feb  3 07:31:38 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05819
	for <webdav-archive@lists.ietf.org>; Mon, 3 Feb 2003 07:31:38 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h13CYCQ17664;
	Mon, 3 Feb 2003 07:34:12 -0500 (EST)
Resent-Date: Mon, 3 Feb 2003 07:34:12 -0500 (EST)
Resent-Message-Id: <200302031234.h13CYCQ17664@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h13CYAD17604
	for <w3c-dist-auth@frink.w3.org>; Mon, 3 Feb 2003 07:34:10 -0500 (EST)
Received: from mail.gmx.net (mail.gmx.net [213.165.65.60])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA14789
	for <w3c-dist-auth@w3c.org>; Mon, 3 Feb 2003 07:34:10 -0500
Received: (qmail 9493 invoked by uid 0); 3 Feb 2003 12:33:38 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp001-rz3) with SMTP; 3 Feb 2003 12:33:38 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Mon, 3 Feb 2003 13:33:38 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCIECFGGAA.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.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <00f201c2cb3c$c5d804a0$f876fea9@xythoslap>
Subject: RE: Normative reference updates
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIECFGGAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7200
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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: Monday, February 03, 2003 5:29 AM
> To: Webdav WG
> Subject: Normative reference updates
>
>
>
>
> I just noticed that since RFC2518, a bunch of WebDAV's normative
> references have themselves been updated, not just HTTP 1.1.
>
> ...
>
> Language identification: RFC1766 obsoleted by two documents
>  - RFC3066, "Best Current Practice"
>  - RFC3282, Draft Standard
>  - Which of these two -- or both -- does RFC2518bis need to make
> normative reference to? Informational reference?  Are there any changes
> which would require changes in WebDAV?

I think the best change would be just to remove the sentence with these
references (it's part of XML's language handling, we don't need to repeat
that information).

> REC-XML
>  - http://www.w3.org/TR/1998/REC-xml-19980210 was updated to
> http://www.w3.org/TR/2000/REC-xml-20001006
>  - Any changes required to WebDAV?

No.

> ...
>
> ISO-* -- I don't know

ISO-8601: we need that for the date format -- AFAIR, we had planned drop our
own definition anyway, and to use a specific subset that happens to be the
same (was that an IETF or a W3C spec?)

ISO-639: see RFC1766

> ..


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



From w3c-dist-auth-request@w3.org  Mon Feb  3 07:35:15 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05933
	for <webdav-archive@lists.ietf.org>; Mon, 3 Feb 2003 07:35:15 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h13Cboe20260;
	Mon, 3 Feb 2003 07:37:50 -0500 (EST)
Resent-Date: Mon, 3 Feb 2003 07:37:50 -0500 (EST)
Resent-Message-Id: <200302031237.h13Cboe20260@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h13CbnD20228
	for <w3c-dist-auth@frink.w3.org>; Mon, 3 Feb 2003 07:37:49 -0500 (EST)
Received: from mail.gmx.net (mail.gmx.net [213.165.65.60])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA16276
	for <w3c-dist-auth@w3c.org>; Mon, 3 Feb 2003 07:37:48 -0500
Received: (qmail 2424 invoked by uid 0); 3 Feb 2003 12:37:17 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp011-rz3) with SMTP; 3 Feb 2003 12:37:17 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: <w3c-dist-auth@w3c.org>
Date: Mon, 3 Feb 2003 13:37:17 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCMECFGGAA.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.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <00f401c2cb40$9439b2f0$f876fea9@xythoslap>
Subject: RE: Summary of If header eval tests
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMECFGGAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7201
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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: Monday, February 03, 2003 5:56 AM
> To: 'Julian Reschke'; w3c-dist-auth@w3c.org
> Subject: RE: Summary of If header eval tests
>
>
>
> Julian it's great that you've done this research. It helps to get some
> real data into our planning!

Thanks.

> > So contrary to what we believed, protecting conditional PUTs using
strong
> > etags currently does not interoperate well at all.
> >
> > How do we move forward on this issue?
>
> I'm not sure.  Here's my guess:
>  - Decide that preventing lost updates is actually important

I don't think we need to decide that :-)

>  - Decide that strong ETags is the only way to do that effectively

...the best...

>  - Exhort server implementors to do a better job of Etags and If header
>  - Put the tests in Litmus -- which I understand you're already doing --
> and announce

Nope, I'm currently not doing it. Joe Orton, are you listening?

>  - Hold another interoperability event where we record the results of
> this effort
>
> That holds back draft standard until we can hold another interop event,
> but if we hold another summer interop as we have the last two years,
> draft standard would probably take that long anyway.
>
> Any other ideas?

I think it's sufficient to add the test cases to Litmus and make sure that
clients submit correct If headers. This can be tested without a specific
face-to-face meeting...

Julian

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



From w3c-dist-auth-request@w3.org  Mon Feb  3 07:54:12 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06701
	for <webdav-archive@lists.ietf.org>; Mon, 3 Feb 2003 07:54:12 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h13CuUQ26921;
	Mon, 3 Feb 2003 07:56:30 -0500 (EST)
Resent-Date: Mon, 3 Feb 2003 07:56:30 -0500 (EST)
Resent-Message-Id: <200302031256.h13CuUQ26921@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h13CuSD26885
	for <w3c-dist-auth@frink.w3.org>; Mon, 3 Feb 2003 07:56:28 -0500 (EST)
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 HAA21565
	for <w3c-dist-auth@w3c.org>; Mon, 3 Feb 2003 07:56:28 -0500
Received: from manyfish.co.uk ([62.253.142.244]) by mta06-svc.ntlworld.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20030203125621.FIJJ4022.mta06-svc.ntlworld.com@manyfish.co.uk>
          for <w3c-dist-auth@w3c.org>; Mon, 3 Feb 2003 12:56:21 +0000
Received: from monolith.fishnet (localhost.localdomain [127.0.0.1])
	by manyfish.co.uk (8.12.5/8.12.5) with ESMTP id h13Cumeg025773
	for <w3c-dist-auth@w3c.org>; Mon, 3 Feb 2003 12:56:49 GMT
Received: (from joe@localhost)
	by monolith.fishnet (8.12.5/8.12.5/Submit) id h13CumCw025772
	for w3c-dist-auth@w3c.org; Mon, 3 Feb 2003 12:56:48 GMT
Date: Mon, 3 Feb 2003 12:56:48 +0000
From: Joe Orton <joe@manyfish.co.uk>
To: w3c-dist-auth@w3c.org
Message-ID: <20030203125648.GA25699@manyfish.co.uk>
Mail-Followup-To: w3c-dist-auth@w3c.org
References: <00f401c2cb40$9439b2f0$f876fea9@xythoslap> <JIEGINCHMLABHJBIGKBCMECFGGAA.julian.reschke@gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <JIEGINCHMLABHJBIGKBCMECFGGAA.julian.reschke@gmx.de>
User-Agent: Mutt/1.4i
Subject: Re: Summary of If header eval tests
X-Archived-At: http://www.w3.org/mid/20030203125648.GA25699@manyfish.co.uk
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7202
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 Mon, Feb 03, 2003 at 01:37:17PM +0100, Julian Reschke wrote:
> >  - Exhort server implementors to do a better job of Etags and If header
> >  - Put the tests in Litmus -- which I understand you're already doing --
> > and announce
> 
> Nope, I'm currently not doing it. Joe Orton, are you listening?

Only with one ear - you'd like all the tests in the update-tests.js file
you posted re-implemented in litmus?

joe



From w3c-dist-auth-request@w3.org  Mon Feb  3 08:16:27 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07134
	for <webdav-archive@lists.ietf.org>; Mon, 3 Feb 2003 08:16:27 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h13DBSP29043;
	Mon, 3 Feb 2003 08:11:28 -0500 (EST)
Resent-Date: Mon, 3 Feb 2003 08:11:28 -0500 (EST)
Resent-Message-Id: <200302031311.h13DBSP29043@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h13DBRD29011
	for <w3c-dist-auth@frink.w3.org>; Mon, 3 Feb 2003 08:11:27 -0500 (EST)
Received: from mail.gmx.net (mail.gmx.net [213.165.65.60])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA25605
	for <w3c-dist-auth@w3c.org>; Mon, 3 Feb 2003 08:11:26 -0500
Received: (qmail 5351 invoked by uid 0); 3 Feb 2003 13:10:55 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp004-rz3) with SMTP; 3 Feb 2003 13:10:55 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Joe Orton" <joe@manyfish.co.uk>, <w3c-dist-auth@w3c.org>
Date: Mon, 3 Feb 2003 14:10:55 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCKECGGGAA.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.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <20030203125648.GA25699@manyfish.co.uk>
Subject: RE: Summary of If header eval tests
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKECGGGAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7203
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 Joe Orton
> Sent: Monday, February 03, 2003 1:57 PM
> To: w3c-dist-auth@w3c.org
> Subject: Re: Summary of If header eval tests
> 
> 
> 
> On Mon, Feb 03, 2003 at 01:37:17PM +0100, Julian Reschke wrote:
> > >  - Exhort server implementors to do a better job of Etags and 
> If header
> > >  - Put the tests in Litmus -- which I understand you're 
> already doing --
> > > and announce
> > 
> > Nope, I'm currently not doing it. Joe Orton, are you listening?
> 
> Only with one ear - you'd like all the tests in the update-tests.js file
> you posted re-implemented in litmus?

Right. Basically it's a sequence of

- create locked resource
- various conditional updates (using PUT)
- UNLOCK
- some more tests involving if-match and etag

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



From w3c-dist-auth-request@w3.org  Tue Feb  4 01:12:48 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01739
	for <webdav-archive@lists.ietf.org>; Tue, 4 Feb 2003 01:12:47 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h146ESH00252;
	Tue, 4 Feb 2003 01:14:28 -0500 (EST)
Resent-Date: Tue, 4 Feb 2003 01:14:28 -0500 (EST)
Resent-Message-Id: <200302040614.h146ESH00252@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h146EQD00213
	for <w3c-dist-auth@frink.w3.org>; Tue, 4 Feb 2003 01:14:26 -0500 (EST)
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 BAA27539
	for <w3c-dist-auth@w3c.org>; Tue, 4 Feb 2003 01:14:26 -0500
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 h146Dsn20702
	for <w3c-dist-auth@w3c.org>; Mon, 3 Feb 2003 22:13:54 -0800 (PST)
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 h146Dra20694
	for <w3c-dist-auth@w3c.org>; Mon, 3 Feb 2003 22:13:53 -0800 (PST)
Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1])
	by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id h146Drt20610
	for <w3c-dist-auth@w3c.org>; Mon, 3 Feb 2003 23:13:53 -0700 (MST)
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 h146DoI20558
	for <w3c-dist-auth@w3c.org>; Mon, 3 Feb 2003 23:13:50 -0700 (MST)
Received: from dhcp-4op7-4op8-west-130-35-170-44.us.oracle.com by rgmum3.us.oracle.com
	with ESMTP id 12186461044339215; Mon, 03 Feb 2003 23:13:35 -0600
Message-ID: <003201c2cc14$8cf6c530$2caa2382@us.oracle.com>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Cc: "Carol Palmer" <carol.palmer@oracle.com>
Date: Mon, 3 Feb 2003 22:13:34 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002F_01C2CBD1.7E74C360"
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: Belated minutes of 55th IETF WebDAV meeting
X-Archived-At: http://www.w3.org/mid/003201c2cc14$8cf6c530$2caa2382@us.oracle.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7204
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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_002F_01C2CBD1.7E74C360
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

WebDAV WG meeting, IETF 55, Atlanta, Nov 19, 2002

=20

               =20

ACL Spec

Main point of discussion is the ACL spec, and the IESG review thereof.

=B7         Geoff points out major features of the ACL draft:

o        what privileges do I have

o        what is the relationship between privileges

o        what are the principles available

o        writing of the ACL

=B7         One issue raised by the IESG was regarding the privileges =
needed for DELETE.  The sense of the WG was that it would be ok to add =
<D:delete> permission is added to control access to the DELETE method

=B7         Major discussion on the complexity of the spec, especially =
of acl-semantics.  No conclusion other than that the IESG is very firm =
on this issue.

=20

RFC2518bis issues

=20

  a.. No objections in the room to If header =
simplification/clarification
  b.. Proposal for the Locktokens-Used header:
    a.. Geoff is concerned about the backwards compatability =
requirements of the Locktokens-Used
    b.. The assertion is that Locktokens-Used addresses no additional =
use cases beyond the If/Not-If technique that is supported (although not =
on many server) (Geoff)
    c.. Joel / Lisa believe that header length causes problems with the =
If/Not-If case
    d.. locktoken-used is for the use case where we want to write =
whether or not we have the lock, whereas If header is needed for the =
case where we only want to update if we have the lock
    e.. If header needs to be fixed to handle comma separation to avoid =
the header length problem regardless
    f.. Possibility of the (*) to match URL in the If token to unify the =
two headers
  c.. Consensus on required use of ETags, but only on resources that =
accept a PUT-i.e. not a generated resource
  d.. XML Namespaces-no new ideas other than some worry about control =
chars in XML tag names
  e.. Next version of RFC2518 should include warning about how horrible =
DAV: URI scheme is
  f.. Need to discuss whether the allprop include should be experimental =
on the list
  g.. Other drafts (allprop, quota, property datatypes, bindings)-should =
we postpone discussion on one of these?  No one seems to think we need =
to wait.
    a.. Quotas-clarify that the quota-free applies to current collection =
(don't need to say anything about subcollections)
  h.. Attribute values in property names?  Do these need to be =
persisted?  Why? (Joel)
    a.. Joel-no, this requires a real XML data store.  The attributes =
can be reserved for metadata.
=20

WG business=20

=20

  a.. Interop report for last meeting?  Lisa promises to look into this
=20


------=_NextPart_000_002F_01C2CBD1.7E74C360
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt 0.25in"><B=20
style=3D"mso-bidi-font-weight: normal"><FONT face=3D"Times New =
Roman">WebDAV WG=20
meeting, IETF 55, Atlanta, Nov 19, 2002<?xml:namespace prefix =3D o ns =
=3D=20
"urn:schemas-microsoft-com:office:office" /><o:p></o:p></FONT></B></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt 0.25in"><o:p><FONT=20
face=3D"Times New Roman">&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"mso-tab-count: 1"><FONT=20
face=3D"Times New =
Roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=20
</FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt 0.25in"><B=20
style=3D"mso-bidi-font-weight: normal"><FONT face=3D"Times New =
Roman">ACL=20
Spec<o:p></o:p></FONT></B></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt 0.25in"><FONT=20
face=3D"Times New Roman">Main point of discussion is the ACL spec, and =
the IESG=20
review thereof.</FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.75in; TEXT-INDENT: -0.25in; mso-list: l1 =
level1 lfo2; tab-stops: list .75in"><SPAN=20
style=3D"FONT-FAMILY: Symbol; mso-fareast-font-family: Symbol; =
mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore">=B7<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><FONT face=3D"Times New Roman">Geoff points out =
major=20
features of the ACL draft:</FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 1.25in; TEXT-INDENT: -0.25in; mso-list: l1 =
level2 lfo2; tab-stops: list 1.25in"><SPAN=20
style=3D"FONT-FAMILY: 'Courier New'; mso-fareast-font-family: 'Courier =
New'"><SPAN=20
style=3D"mso-list: Ignore">o<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><FONT face=3D"Times New Roman">what privileges do I =

have</FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 1.25in; TEXT-INDENT: -0.25in; mso-list: l1 =
level2 lfo2; tab-stops: list 1.25in"><SPAN=20
style=3D"FONT-FAMILY: 'Courier New'; mso-fareast-font-family: 'Courier =
New'"><SPAN=20
style=3D"mso-list: Ignore">o<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><FONT face=3D"Times New Roman">what is the =
relationship=20
between privileges</FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 1.25in; TEXT-INDENT: -0.25in; mso-list: l1 =
level2 lfo2; tab-stops: list 1.25in"><SPAN=20
style=3D"FONT-FAMILY: 'Courier New'; mso-fareast-font-family: 'Courier =
New'"><SPAN=20
style=3D"mso-list: Ignore">o<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><FONT face=3D"Times New Roman">what are the =
principles=20
available</FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 1.25in; TEXT-INDENT: -0.25in; mso-list: l1 =
level2 lfo2; tab-stops: list 1.25in"><SPAN=20
style=3D"FONT-FAMILY: 'Courier New'; mso-fareast-font-family: 'Courier =
New'"><SPAN=20
style=3D"mso-list: Ignore">o<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><FONT face=3D"Times New Roman">writing of the =
ACL</FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.75in; TEXT-INDENT: -0.25in; mso-list: l1 =
level1 lfo2; tab-stops: list .75in"><SPAN=20
style=3D"FONT-FAMILY: Symbol; mso-fareast-font-family: Symbol; =
mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore">=B7<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><FONT face=3D"Times New Roman">One issue raised by =
the IESG=20
was regarding the privileges needed for DELETE.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>The sense of the WG was that =
it would be=20
ok to add &lt;D:delete&gt; permission is added to control access to the =
DELETE=20
method</FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.75in; TEXT-INDENT: -0.25in; mso-list: l1 =
level1 lfo2; tab-stops: list .75in"><SPAN=20
style=3D"FONT-FAMILY: Symbol; mso-fareast-font-family: Symbol; =
mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore">=B7<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><FONT face=3D"Times New Roman">Major discussion on =
the=20
complexity of the spec, especially of acl-semantics.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>No conclusion other than that =
the IESG=20
is very firm on this issue.</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt 0.75in"><o:p><FONT=20
face=3D"Times New Roman">&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt 0.25in"><B=20
style=3D"mso-bidi-font-weight: normal"><FONT face=3D"Times New =
Roman">RFC2518bis=20
issues<o:p></o:p></FONT></B></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20
face=3D"Times New Roman">&nbsp;</FONT></o:p></P>
<UL style=3D"MARGIN-TOP: 0in" type=3Ddisc>
  <LI class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo1; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman">No objections in the room to If header=20
  simplification/clarification</FONT></LI>
  <LI class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo1; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman">Proposal for the Locktokens-Used =
header:</FONT></LI>
  <UL style=3D"MARGIN-TOP: 0in" type=3Dcircle>
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level2 lfo1; tab-stops: =
list 1.0in"><FONT=20
    face=3D"Times New Roman">Geoff is concerned about the backwards =
compatability=20
    requirements of the Locktokens-Used</FONT></LI>
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level2 lfo1; tab-stops: =
list 1.0in"><FONT=20
    face=3D"Times New Roman">The assertion is that Locktokens-Used =
addresses no=20
    additional use cases beyond the If/Not-If technique that is =
supported=20
    (although not on many server) (Geoff)</FONT></LI>
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level2 lfo1; tab-stops: =
list 1.0in"><FONT=20
    face=3D"Times New Roman">Joel / Lisa believe that header length =
causes=20
    problems with the If/Not-If case</FONT></LI>
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level2 lfo1; tab-stops: =
list 1.0in"><FONT=20
    face=3D"Times New Roman">locktoken-used is for the use case where we =
want to=20
    write whether or not we have the lock, whereas If header is needed =
for the=20
    case where we only want to update if we have the lock</FONT></LI>
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level2 lfo1; tab-stops: =
list 1.0in"><FONT=20
    face=3D"Times New Roman">If header needs to be fixed to handle comma =

    separation to avoid the header length problem regardless</FONT></LI>
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level2 lfo1; tab-stops: =
list 1.0in"><FONT=20
    face=3D"Times New Roman">Possibility of the (*) to match URL in the =
If token=20
    to unify the two headers</FONT></LI></UL>
  <LI class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo1; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman">Consensus on required use of ETags, but only =
on=20
  resources that accept a PUT=97i.e. not a generated =
resource</FONT></LI>
  <LI class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo1; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman">XML Namespaces=97no new ideas other than some =
worry about=20
  control chars in XML tag names</FONT></LI>
  <LI class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo1; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman">Next version of RFC2518 should include =
warning about=20
  how horrible DAV: URI scheme is</FONT></LI>
  <LI class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo1; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman">Need to discuss whether the allprop include =
should be=20
  experimental on the list</FONT></LI>
  <LI class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo1; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman">Other drafts (allprop, quota, property =
datatypes,=20
  bindings)=97should we postpone discussion on one of these?<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>No one seems to think we =
need to=20
  wait.</FONT></LI>
  <UL style=3D"MARGIN-TOP: 0in" type=3Dcircle>
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level2 lfo1; tab-stops: =
list 1.0in"><FONT=20
    face=3D"Times New Roman">Quotas=97clarify that the quota-free =
applies to current=20
    collection (don=92t need to say anything about =
subcollections)</FONT></LI></UL>
  <LI class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo1; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman">Attribute values in property names?<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>Do these need to be =
persisted?<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>Why? (Joel)</FONT></LI>
  <UL style=3D"MARGIN-TOP: 0in" type=3Dcircle>
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level2 lfo1; tab-stops: =
list 1.0in"><FONT=20
    face=3D"Times New Roman">Joel=97no, this requires a real XML data =
store.<SPAN=20
    style=3D"mso-spacerun: yes">&nbsp; </SPAN>The attributes can be =
reserved for=20
    metadata.</FONT></LI></UL></UL>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt 0.25in"><B=20
style=3D"mso-bidi-font-weight: normal"><o:p><FONT=20
face=3D"Times New Roman">&nbsp;</FONT></o:p></B></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt 0.25in"><B=20
style=3D"mso-bidi-font-weight: normal"><FONT face=3D"Times New Roman">WG =
business=20
<o:p></o:p></FONT></B></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20
face=3D"Times New Roman">&nbsp;</FONT></o:p></P>
<UL style=3D"MARGIN-TOP: 0in" type=3Ddisc>
  <LI class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo1; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman">Interop report for last meeting?<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>Lisa promises to look into=20
  this</FONT></LI></UL>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20
face=3D"Times New =
Roman">&nbsp;</FONT></o:p></P></FONT></DIV></BODY></HTML>

------=_NextPart_000_002F_01C2CBD1.7E74C360--



From w3c-dist-auth-request@w3.org  Tue Feb  4 06:47:26 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17555
	for <webdav-archive@lists.ietf.org>; Tue, 4 Feb 2003 06:47:25 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h14BnQ427034;
	Tue, 4 Feb 2003 06:49:26 -0500 (EST)
Resent-Date: Tue, 4 Feb 2003 06:49:26 -0500 (EST)
Resent-Message-Id: <200302041149.h14BnQ427034@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h14BnLD27000
	for <w3c-dist-auth@frink.w3.org>; Tue, 4 Feb 2003 06:49:21 -0500 (EST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA18235
	for <w3c-dist-auth@w3.org>; Tue, 4 Feb 2003 06:49:17 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17396;
	Tue, 4 Feb 2003 06:45:38 -0500 (EST)
Message-Id: <200302041145.GAA17396@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: Tue, 04 Feb 2003 06:45:38 -0500
Subject: I-D ACTION:draft-ietf-webdav-ordering-protocol-05.txt
X-Archived-At: http://www.w3.org/mid/200302041145.GAA17396@ietf.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7205
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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		: WebDAV Ordered Collections Protocol
	Author(s)	: J. Slein, E. Whitehead et al.
	Filename	: draft-ietf-webdav-ordering-protocol-05.txt
	Pages		: 41
	Date		: 2003-2-3
	
This specification extends the WebDAV Distributed Authoring Protocol
to support server-side ordering of collection members. Of particular
interest are orderings that are not based on property values, and so
cannot be achieved using a search protocol's ordering option and
cannot be maintained automatically by the server. Protocol elements
are defined to let clients specify the position in the ordering of
each collection member, as well as the semantics governing the
ordering.
Distribution of this document is unlimited. Please send comments to
the Distributed Authoring and Versioning (WebDAV) working group at
w3c-dist-auth@w3.org, which may be joined by sending a message with
subject 'subscribe' to w3c-dist-auth-request@w3.org.
Discussions of the WEBDAV working group are archived at URL:
http://lists.w3.org/Archives/Public/w3c-dist-auth/.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-protocol-05.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-ordering-protocol-05.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-ordering-protocol-05.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:	<2003-2-3125657.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-webdav-ordering-protocol-05.txt

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

Content-Type: text/plain
Content-ID:	<2003-2-3125657.I-D@ietf.org>

--OtherAccess--

--NextPart--




From w3c-dist-auth-request@w3.org  Tue Feb  4 14:49:01 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02715
	for <webdav-archive@lists.ietf.org>; Tue, 4 Feb 2003 14:48:56 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h14JouD11080;
	Tue, 4 Feb 2003 14:50:56 -0500 (EST)
Resent-Date: Tue, 4 Feb 2003 14:50:56 -0500 (EST)
Resent-Message-Id: <200302041950.h14JouD11080@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h14JotD11048
	for <w3c-dist-auth@frink.w3.org>; Tue, 4 Feb 2003 14:50:55 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA12000
	for <w3c-dist-auth@w3c.org>; Tue, 4 Feb 2003 14:50:54 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18g95p-0000Xo-00
	for w3c-dist-auth@w3c.org; Tue, 04 Feb 2003 19:50:53 +0000
Received: from [216.36.77.241] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18g95p-0000Xd-00
	for w3c-dist-auth@w3c.org; Tue, 04 Feb 2003 19:50:53 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Tue, 4 Feb 2003 11:50:55 -0800
Message-ID: <00e001c2cc86$bb63f790$f8cb90c6@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.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Subject: Stringprep for WebDAV & DASL
X-Archived-At: http://www.w3.org/mid/00e001c2cc86$bb63f790$f8cb90c6@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7206
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 learning about this StringPrep standard for XMPP string comparisons,
and obviously it would be useful for WebDAV too, particularly DASL.

http://www.ietf.org/rfc/rfc3454.txt

To make string comparisons work more reliably, a proposal like DASL can
define a StringPrep "profile", selecting the characters, mappings and
foldings most appropriate to that application.

I'm not clear yet on whether it's possible to just import StringPrep
entire, without creating a profile.

Lisa




From w3c-dist-auth-request@w3.org  Tue Feb  4 16:30:20 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04850
	for <webdav-archive@lists.ietf.org>; Tue, 4 Feb 2003 16:30:15 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h14LWeh29405;
	Tue, 4 Feb 2003 16:32:40 -0500 (EST)
Resent-Date: Tue, 4 Feb 2003 16:32:40 -0500 (EST)
Resent-Message-Id: <200302042132.h14LWeh29405@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h14LWcD29373
	for <w3c-dist-auth@frink.w3.org>; Tue, 4 Feb 2003 16:32:38 -0500 (EST)
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 QAA02750
	for <w3c-dist-auth@w3c.org>; Tue, 4 Feb 2003 16:32:38 -0500
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 h14LW6V07863
	for <w3c-dist-auth@w3c.org>; Tue, 4 Feb 2003 13:32:06 -0800 (PST)
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 h14LW5I07850
	for <w3c-dist-auth@w3c.org>; Tue, 4 Feb 2003 13:32:05 -0800 (PST)
Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1])
	by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id h14LW5t24309
	for <w3c-dist-auth@w3c.org>; Tue, 4 Feb 2003 14:32:05 -0700 (MST)
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 h14LW4I24288
	for <w3c-dist-auth@w3c.org>; Tue, 4 Feb 2003 14:32:04 -0700 (MST)
Received: from dhcp-4op7-4op8-west-130-35-170-44.us.oracle.com by rgmum5.us.oracle.com
	with ESMTP id 12596161044394156; Tue, 04 Feb 2003 14:29:16 -0600
Message-ID: <011201c2cc94$77aa97d0$2caa2382@us.oracle.com>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: <joels@exchange.microsoft.com>
Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Tue, 4 Feb 2003 13:29:15 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_010F_01C2CC51.695DFDE0"
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: DAV bug in folder copy in Windows/Office 2K
X-Archived-At: http://www.w3.org/mid/011201c2cc94$77aa97d0$2caa2382@us.oracle.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7207
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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_010F_01C2CC51.695DFDE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

MessageJoel--

  There is a bug in Windows2K/Office2K where dragging one folder onto =
another deletes everything at the destination URL if it already exists, =
rather than just copying in the contents.

  Do you know if there is a patch to the DAV client in =
Windows2K/Office2K to get the new HEAD/MKCOL behavior?

--Eric

From: Mark D. Drake=20
To: Eric Sedlar=20
Cc: Syam Pannala ; Sam.idicular@oracle.com=20
Sent: Tuesday, January 14, 2003 5:36 PM
Subject: WebDav behavoir


Eric

The issues appears to be that with Office XP the WebDAV client uses HEAD =
to determine if the directory already exists and only issues MKCOL if =
the target is not found. With 2K it appears to issues MKCOL, and if the =
target exists it issues DELTE followed by MKCOL..

The question is, is there a patch for Windows 2K / Office 2K that will =
provide the preferred (Office XP) behavoir, under Windows 2K / Office =
2K.

-Mark

----- Original Message -----=20
From: Mark D. Drake=20
To: Eric Sedlar=20
Sent: Wednesday, January 15, 2003 3:22 PM


With Office 2K

Test Case

Map a WebFolder to a DAV Server -> create a Folder called testcase on =
Dav Server.
Create a Folder called Parent on the Desktop
Create a Folder called Child inside Parent.
Create a Folder called Sibling on the Desktop.

Copy Parent from the Desktop to the Testcase folder on the Dav Server -> =
This should create a folder called parent on the Dav Server.
Open the Parent Folder on the Dav Server -> It should contain a folder =
callled Child
Copy the Sibling folder from the Desktop to the Parent Folder on the Dav =
Server. -> The Parent Folder should now contain subfolders Child and =
Sibling.

Navigate the to the Testcase folder on the Dav Server
Copy the Parent Folder from the Desktop to the Dav Server -> When =
prompted about overwriting select 'Yes to All' option
Open the Parent Folder on the Dav Server -> Note that it does not =
contain a folder called Sibling..

If the same actions are taken with Office XP the Parent Folder will =
contain both child and sibling after the second copy completes. From a =
Windows perspective this is the expected and desired behavoir...


Regards=20
<MDD>=20
_________________________________________________________________________=
_____=20

Mark D. Drake                                         Phone:  =
650.506.5244=20
Senior Product Manager,                               Fax: 650.633.2987
XML Infrastructure,                                   Cell: 415.297.1337
Server Technology
Oracle Corporation
500 Oracle Parkway, #706 / MS 4OP-706=20
Redwood Shores, CA 94065=20

External Web: (http://www.oracle.com)
Internal Web: (http://xdb.us.oracle.com)

Email: mark.drake@oracle.com=20



------=_NextPart_000_010F_01C2CC51.695DFDE0
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>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Joel--</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; There is a bug in =
Windows2K/Office2K where=20
dragging one folder onto another deletes everything at the destination =
URL if it=20
already exists, rather than just copying in the contents.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;Do you know if&nbsp;there =
is a patch to=20
the DAV client in Windows2K/Office2K to get the new HEAD/MKCOL=20
behavior?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>--Eric</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>
<DIV=20
style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B> <A=20
title=3Dmark.drake@oracle.com href=3D"mailto:mark.drake@oracle.com">Mark =
D.=20
Drake</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Deric.sedlar@oracle.com=20
href=3D"mailto:eric.sedlar@oracle.com">Eric Sedlar</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=3DSYAM.PANNALA@oracle.com=20
href=3D"mailto:SYAM.PANNALA@oracle.com">Syam Pannala</A> ; <A=20
title=3DSam.idicular@oracle.com=20
href=3D"mailto:Sam.idicular@oracle.com">Sam.idicular@oracle.com</A> =
</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, January 14, 2003 =
5:36=20
PM</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Subject:</B> WebDav behavoir</DIV>
<DIV><BR></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D012431501-15012003>Eric</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D012431501-15012003></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D012431501-15012003>The issues=20
appears to be that with Office XP the WebDAV client uses HEAD to =
determine if=20
the directory already exists and only issues MKCOL if the target is not =
found.=20
With 2K it appears to issues MKCOL, and if the target exists it issues =
DELTE=20
followed by MKCOL..</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D012431501-15012003></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D012431501-15012003>The question=20
is, is there a patch for Windows 2K / Office 2K that will provide the =
preferred=20
(Office XP) behavoir, under Windows 2K / Office =
2K.</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D012431501-15012003></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D012431501-15012003>-Mark</SPAN></FONT></FONT></DIV></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV style=3D"FONT: 10pt arial">----- Original Message -----=20
<DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20
title=3Dmark.drake@oracle.com href=3D"mailto:mark.drake@oracle.com">Mark =
D.=20
Drake</A> </DIV>
<DIV><B>To:</B> <A title=3Deric.sedlar@oracle.com=20
href=3D"mailto:eric.sedlar@oracle.com">Eric Sedlar</A> </DIV>
<DIV><B>Sent:</B> Wednesday, January 15, 2003 3:22 PM</DIV></DIV>
<DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D554321623-15012003>With =
Office=20
2K</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D554321623-15012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D554321623-15012003>Test=20
Case</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D554321623-15012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D554321623-15012003>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D554321623-15012003>Map a =
WebFolder to a=20
DAV Server -&gt; create a Folder called testcase on Dav=20
Server.</SPAN></FONT></DIV>Create a Folder called Parent on the=20
Desktop</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D554321623-15012003>Create =
a Folder=20
called Child inside Parent.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D554321623-15012003>Create =
a Folder=20
called Sibling on the Desktop.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D554321623-15012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D554321623-15012003>Copy =
Parent from the=20
Desktop to the Testcase folder on the Dav Server -&gt; =
</SPAN></FONT><FONT=20
face=3DArial size=3D2><SPAN class=3D554321623-15012003>This should =
create a folder=20
called parent on the Dav Server.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D554321623-15012003>Open =
the Parent=20
Folder on the Dav Server -&gt; It should contain a folder callled=20
Child</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D554321623-15012003>Copy =
the Sibling=20
folder from the&nbsp;Desktop to the Parent Folder on the Dav Server. =
-&gt; The=20
Parent Folder should now contain subfolders Child and=20
Sibling.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D554321623-15012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D554321623-15012003>Navigate the to the=20
Testcase folder on the Dav Server</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D554321623-15012003>Copy =
the Parent=20
Folder from the Desktop to the Dav Server -&gt; When prompted about =
overwriting=20
select 'Yes to All' option</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D554321623-15012003>Open =
the Parent=20
Folder on the Dav Server -&gt; Note that it does not contain a folder =
called=20
Sibling..</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D554321623-15012003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D554321623-15012003>If the =
same actions=20
are taken with Office XP the Parent Folder will contain both child and =
sibling=20
after the second copy completes. From a Windows perspective this is the =
expected=20
and desired behavoir...</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D554321623-15012003></SPAN></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV><!-- Converted from text/plain format --><FONT =
size=3D2></FONT>
<DIV align=3Dleft><FONT size=3D2>
<P align=3Dleft>Regards <BR>&lt;MDD&gt;=20
<BR>_____________________________________________________________________=
_________=20
</P>
<P>Mark D.=20
Drake&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Phone:&nbsp;&nbsp;650.506.5244=20
<BR>Senior Product=20
Manager,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Fax:=20
650.633.2987<BR>XML=20
Infrastructure,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
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;Cell:=20
415.297.1337<BR>Server Technology<BR>Oracle Corporation<BR>500 Oracle =
Parkway,=20
#706 / MS 4OP-706 <BR>Redwood Shores, CA 94065 <BR><BR>External Web: =
(</FONT><A=20
href=3D"http://www.oracle.com/"><U><FONT color=3D#0000ff=20
size=3D2>http://www.oracle.com</U></FONT></A><FONT =
size=3D2>)<BR>Internal Web:=20
(</FONT><A href=3D"http://xdb.us.oracle.com/"><U><FONT color=3D#0000ff=20
size=3D2>http://xdb.us.oracle.com</U></FONT></A><FONT size=3D2>)</P>
<P>Email: mark.drake@oracle.com </FONT></P></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_010F_01C2CC51.695DFDE0--



From w3c-dist-auth-request@w3.org  Wed Feb  5 00:36:36 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16515
	for <webdav-archive@lists.ietf.org>; Wed, 5 Feb 2003 00:36:36 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h155cQn24716;
	Wed, 5 Feb 2003 00:38:26 -0500 (EST)
Resent-Date: Wed, 5 Feb 2003 00:38:26 -0500 (EST)
Resent-Message-Id: <200302050538.h155cQn24716@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h155cPD24678
	for <w3c-dist-auth@frink.w3.org>; Wed, 5 Feb 2003 00:38:25 -0500 (EST)
Received: from newgennet.newgen.co.in (root@[203.168.76.148])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA30608
	for <w3c-dist-auth@w3c.org>; Wed, 5 Feb 2003 00:38:13 -0500
Received: from nhweb.newgen.co.in ([203.168.76.5])
	by newgennet.newgen.co.in (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA10933
	for <w3c-dist-auth@w3c.org>; Wed, 5 Feb 2003 11:05:51 +0530
X-Authentication-Warning: newgennet.newgen.co.in: Host [203.168.76.5] claimed to be nhweb.newgen.co.in
Received: from anil (ws208.newgen.co.in [192.168.5.208])
	by nhweb.newgen.co.in (8.12.3/8.12.3/Debian -4) with SMTP id h1559g7f031756
	for <w3c-dist-auth@w3c.org>; Wed, 5 Feb 2003 10:39:45 +0530
Message-ID: <003401c2ccd4$49280dd0$d005a8c0@anil>
From: "Anil Bhandari" <anilb@newgen.co.in>
To: <w3c-dist-auth@w3c.org>
Date: Wed, 5 Feb 2003 10:36:01 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0031_01C2CD02.60E208D0"
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: Problem with Folder Creation in WinNT/Win2000P
X-Archived-At: http://www.w3.org/mid/003401c2ccd4$49280dd0$d005a8c0@anil
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7208
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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_0031_01C2CD02.60E208D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi=20

i have mapped a WebFolder to a DAV Server and now i am creating a new =
folder to a location where i do not have "write-rights".  In this case, =
i am sending the xml response corresponding to Forbidden status code =
inside the multistatus tag. Although a new folder is not created here =
but it is not throwing any error message. Is there any way out of it?

please help me.

thanx in advance.

Anil


------=_NextPart_000_0031_01C2CD02.60E208D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>i have mapped a WebFolder to a DAV =
Server and now i=20
am creating a new folder to a location where i do not have =
"write-rights".&nbsp;=20
In this case,&nbsp;i am sending the&nbsp;xml&nbsp;response corresponding =
to=20
Forbidden status code inside the multistatus tag. Although&nbsp;a new =
folder is=20
not&nbsp;created here but it is not throwing any error message. Is there =
any way=20
out of it?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>please help me.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>thanx in advance.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anil</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0031_01C2CD02.60E208D0--



From w3c-dist-auth-request@w3.org  Wed Feb  5 08:49:35 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25042
	for <webdav-archive@lists.ietf.org>; Wed, 5 Feb 2003 08:49:35 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h15Dpqm21518;
	Wed, 5 Feb 2003 08:51:52 -0500 (EST)
Resent-Date: Wed, 5 Feb 2003 08:51:52 -0500 (EST)
Resent-Message-Id: <200302051351.h15Dpqm21518@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h15DpoD21486
	for <w3c-dist-auth@frink.w3.org>; Wed, 5 Feb 2003 08:51:50 -0500 (EST)
Received: from mail.gmx.net (mail.gmx.net [213.165.65.60])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA02596
	for <w3c-dist-auth@w3.org>; Wed, 5 Feb 2003 08:51:49 -0500
Received: (qmail 24621 invoked by uid 0); 5 Feb 2003 13:51:18 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp004-rz3) with SMTP; 5 Feb 2003 13:51:18 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: <w3c-dist-auth@w3.org>
Date: Wed, 5 Feb 2003 14:51:18 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCGEHCGGAA.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.6604 (9.0.2911.0)
Importance: Normal
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <200302041145.GAA17396@ietf.org>
Subject: RE: I-D ACTION:draft-ietf-webdav-ordering-protocol-05.txt
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEHCGGAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7209
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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.

The draft as it has been submitted is considered "finished", and therefore
it would be nice if it could be reviewed even by those that won't implement
it in the near future.

The original draft has been in "Last Call" over three years ago, but for
some reason it was never submitted as RFC. Since then, the following changes
were made:

B.1  Since draft-ietf-webdav-ordering-protocol dated December 1999
Updated contact information for all previous authors.
Specify charset when using text/xml media type.
Made sure artwork fits into 72 columns.
Removed "Public" header from OPTIONS example.
Added Julian Reschke to list of authors.
Fixed broken XML in PROPFIND example and added DAV:orderingtype to list of
requested properties.
Added support for DAV:supported-live-property-set and
DAV:supported-method-set as mandatory features.

B.2  Since draft-ietf-webdav-ordering-protocol-02
Updated change log to refer to expired draft version as "December 1999"
version.
Started rewrite marshalling in RFC3253-style and added precondition and
postcondition definitions.
On his request, removed Geoff Clemm's name from the author list (moved to
Acknowledgments).
Renamed "References" to "Normative References".
Removed reference to "MKREF" method.

B.3  Since draft-ietf-webdav-ordering-protocol-03
Added a set of issues regarding marshalling.
Changed host names to use proper "example" domain names (no change
tracking). Fixed host/destination header conflicts. Fixed "allow" header
(multiline). Removed irrelevant response headers. Abbreviated some URIs (no
change tracking).
Removed Jim Davis and Chuck Fay from the author list (and added them to the
Acknowledgements section).
Updated section on setting the position when adding new members, removed old
section on Position header.
Started work on Index section.
Changed structure for section 7 (no change tracking).
Removed header and XML elements section (contents moved to other sections).
Started new section on relation to versioned collections as per RFC3253.
Do not return 424's for in ORDERPATCH multistatus (it's atomic anyway).

B.4  Since draft-ietf-webdav-ordering-protocol-04
Added proper reference to definition of "Coded-URL".
Closed issue ordering-type-values (content model simplified and XML element
/ DAV property renamed) and updated examples.
Renamed precondition DAV:orderingtype-set to DAV:ordering-type-set (no
change tracking).
Closed issue ordered-header-name (header name changed to "ordering-type",
contents matches live property).
Closed issue ordermember-format (now takes segment instead of href).
Renamed compliance class to "ordered-collections" for consistency with newer
specs, and to allow detection of compliance to final version of spec.
Updated reference to XML spec to 1.0, 2nd edition.


Regards, Julian


[1] <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0337.html>


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



From w3c-dist-auth-request@w3.org  Wed Feb  5 11:01:16 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29476
	for <webdav-archive@lists.ietf.org>; Wed, 5 Feb 2003 11:01:15 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h15G3pZ15616;
	Wed, 5 Feb 2003 11:03:51 -0500 (EST)
Resent-Date: Wed, 5 Feb 2003 11:03:51 -0500 (EST)
Resent-Message-Id: <200302051603.h15G3pZ15616@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h15G3nD15584
	for <w3c-dist-auth@frink.w3.org>; Wed, 5 Feb 2003 11:03:49 -0500 (EST)
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 LAA08802
	for <w3c-dist-auth@w3.org>; Wed, 5 Feb 2003 11:03:49 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 05 Feb 2003 10:48:09 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <1L2CA6BS>; Wed, 5 Feb 2003 11:03:13 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED676@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Wed, 5 Feb 2003 11:03:12 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: I-D ACTION:draft-ietf-webdav-ordering-protocol-05.txt
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED676@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7210
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 reviewed draft -05, and I think it is in excellent shape for
submission to the IESG (congratulations to Julian and his co-authors
for a fine job!).

I have just a couple of typos to report in section 7:
DAV:orderding-type-set => DAV:ordering-type-set
DAV:orderding-modified => DAV:ordering-modified

For aesthetic reasons, I would have preferred that the DAV:ordermember
element type have a hyphen, i.e. "DAV:order-member".  But I wouldn't
violently object if it is left the way it is.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Wednesday, February 05, 2003 8:51 AM
To: w3c-dist-auth@w3.org
Subject: RE: I-D ACTION:draft-ietf-webdav-ordering-protocol-05.txt



Hi.

The draft as it has been submitted is considered "finished", and therefore
it would be nice if it could be reviewed even by those that won't implement
it in the near future.

The original draft has been in "Last Call" over three years ago, but for
some reason it was never submitted as RFC. Since then, the following changes
were made:

B.1  Since draft-ietf-webdav-ordering-protocol dated December 1999
Updated contact information for all previous authors.
Specify charset when using text/xml media type.
Made sure artwork fits into 72 columns.
Removed "Public" header from OPTIONS example.
Added Julian Reschke to list of authors.
Fixed broken XML in PROPFIND example and added DAV:orderingtype to list of
requested properties.
Added support for DAV:supported-live-property-set and
DAV:supported-method-set as mandatory features.

B.2  Since draft-ietf-webdav-ordering-protocol-02
Updated change log to refer to expired draft version as "December 1999"
version.
Started rewrite marshalling in RFC3253-style and added precondition and
postcondition definitions.
On his request, removed Geoff Clemm's name from the author list (moved to
Acknowledgments).
Renamed "References" to "Normative References".
Removed reference to "MKREF" method.

B.3  Since draft-ietf-webdav-ordering-protocol-03
Added a set of issues regarding marshalling.
Changed host names to use proper "example" domain names (no change
tracking). Fixed host/destination header conflicts. Fixed "allow" header
(multiline). Removed irrelevant response headers. Abbreviated some URIs (no
change tracking).
Removed Jim Davis and Chuck Fay from the author list (and added them to the
Acknowledgements section).
Updated section on setting the position when adding new members, removed old
section on Position header.
Started work on Index section.
Changed structure for section 7 (no change tracking).
Removed header and XML elements section (contents moved to other sections).
Started new section on relation to versioned collections as per RFC3253.
Do not return 424's for in ORDERPATCH multistatus (it's atomic anyway).

B.4  Since draft-ietf-webdav-ordering-protocol-04
Added proper reference to definition of "Coded-URL".
Closed issue ordering-type-values (content model simplified and XML element
/ DAV property renamed) and updated examples.
Renamed precondition DAV:orderingtype-set to DAV:ordering-type-set (no
change tracking).
Closed issue ordered-header-name (header name changed to "ordering-type",
contents matches live property).
Closed issue ordermember-format (now takes segment instead of href).
Renamed compliance class to "ordered-collections" for consistency with newer
specs, and to allow detection of compliance to final version of spec.
Updated reference to XML spec to 1.0, 2nd edition.


Regards, Julian


[1] <http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0337.html>


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



From w3c-dist-auth-request@w3.org  Wed Feb  5 11:30:11 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00493
	for <webdav-archive@lists.ietf.org>; Wed, 5 Feb 2003 11:30:10 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h15GS0W20481;
	Wed, 5 Feb 2003 11:28:00 -0500 (EST)
Resent-Date: Wed, 5 Feb 2003 11:28:00 -0500 (EST)
Resent-Message-Id: <200302051628.h15GS0W20481@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h15GRxD20448
	for <w3c-dist-auth@frink.w3.org>; Wed, 5 Feb 2003 11:27:59 -0500 (EST)
Received: from mail.gmx.net (mail.gmx.net [213.165.65.60])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA15409
	for <w3c-dist-auth@w3.org>; Wed, 5 Feb 2003 11:27:58 -0500
Received: (qmail 18017 invoked by uid 0); 5 Feb 2003 16:27:12 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp009-rz3) with SMTP; 5 Feb 2003 16:27:12 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Clemm, Geoff" <gclemm@rational.com>, <w3c-dist-auth@w3.org>
Date: Wed, 5 Feb 2003 17:27:11 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCAEHJGGAA.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.6604 (9.0.2911.0)
Importance: Normal
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED676@SUS-MA1IT01>
Subject: RE: I-D ACTION:draft-ietf-webdav-ordering-protocol-05.txt
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEHJGGAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7211
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 Clemm, Geoff
> Sent: Wednesday, February 05, 2003 5:03 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: I-D ACTION:draft-ietf-webdav-ordering-protocol-05.txt
>
>
>
> I have reviewed draft -05, and I think it is in excellent shape for
> submission to the IESG (congratulations to Julian and his co-authors
> for a fine job!).
>
> I have just a couple of typos to report in section 7:
> DAV:orderding-type-set => DAV:ordering-type-set
> DAV:orderding-modified => DAV:ordering-modified

Of course these are the typos that I've put in on purpose to see whether
people are reading it thourougly :-)

> For aesthetic reasons, I would have preferred that the DAV:ordermember
> element type have a hyphen, i.e. "DAV:order-member".  But I wouldn't
> violently object if it is left the way it is.

Agreed. I think I'll change that as well.

Julian

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



From w3c-dist-auth-request@w3.org  Fri Feb  7 08:57:15 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11461
	for <webdav-archive@lists.ietf.org>; Fri, 7 Feb 2003 08:57:15 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h17DxEF21499;
	Fri, 7 Feb 2003 08:59:14 -0500 (EST)
Resent-Date: Fri, 7 Feb 2003 08:59:14 -0500 (EST)
Resent-Message-Id: <200302071359.h17DxEF21499@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h17DxCD21462
	for <w3c-dist-auth@frink.w3.org>; Fri, 7 Feb 2003 08:59:12 -0500 (EST)
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 IAA17035
	for <w3c-dist-auth@w3.org>; Fri, 7 Feb 2003 08:59:11 -0500
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>; Fri, 07 Feb 2003 14:58:46 +0100
From: "Julian Reschke" <julian.reschke@greenbytes.de>
To: <w3c-dist-auth@w3.org>
Date: Fri, 7 Feb 2003 14:58:46 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCAELPGGAA.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.6604 (9.0.2911.0)
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
X-MDaemon-Deliver-To: w3c-dist-auth@w3.org
Subject: BIND issue: 4_SPECIAL OVERWRITE_STATUS
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAELPGGAA.julian.reschke@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7212
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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,

back in October, Stefan Eissing wrote:

> Maybe it would be more appropriate to reuse the response codes as
> defined for MOVE in RFC 2518:
>
> 201: newly created
> 204: replaced existing resource
>etc.

I agree. MOVE should be identical to BIND/DELETE, and therefore consistency
with MOVE response codes seems to make sense.

Proposal:

Add the sentence:

"In case of success, the server SHOULD return 201 (Created) when a new
binding was created and 204 (No Content) when an existing binding was
replaced".

Julian

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




From w3c-dist-auth-request@w3.org  Fri Feb  7 08:59:43 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11538
	for <webdav-archive@lists.ietf.org>; Fri, 7 Feb 2003 08:59:42 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h17E2RJ22842;
	Fri, 7 Feb 2003 09:02:27 -0500 (EST)
Resent-Date: Fri, 7 Feb 2003 09:02:27 -0500 (EST)
Resent-Message-Id: <200302071402.h17E2RJ22842@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h17E2PD22810
	for <w3c-dist-auth@frink.w3.org>; Fri, 7 Feb 2003 09:02:25 -0500 (EST)
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 JAA17975
	for <w3c-dist-auth@w3.org>; Fri, 7 Feb 2003 09:02:25 -0500
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>; Fri, 07 Feb 2003 15:01:38 +0100
From: "Julian Reschke" <julian.reschke@greenbytes.de>
To: <w3c-dist-auth@w3.org>
Date: Fri, 7 Feb 2003 15:01:38 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCEELPGGAA.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.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <JIEGINCHMLABHJBIGKBCAELPGGAA.julian.reschke@greenbytes.de>
X-MDRemoteIP: 192.168.1.23
X-Return-Path: julian.reschke@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3.org
Subject: BIND issue: 5.1_LOOP_STATUS
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEELPGGAA.julian.reschke@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7213
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


Back in October, Geoff Clemm wrote:

> If we handled it the way proposed below, the old clients will just ignore
> the new element, and the user will incorrectly conclude that the
collection
> had no child by that name.  With the original proposal, users of
> old clients will be told that there is a child, and will get the
> error message that they've already seen that child, so it is
> being left out of the report.  I think the later is preferable.

I agree that introducing a new error marshalling concept just for an edge
case here (Depth: infinity and bind loop) is unnecessary, in particular if
it may confuse old clients. Therefore the issue should be closed.

Julian

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




From w3c-dist-auth-request@w3.org  Fri Feb  7 09:08:06 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11828
	for <webdav-archive@lists.ietf.org>; Fri, 7 Feb 2003 09:08:05 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h17EAhw27133;
	Fri, 7 Feb 2003 09:10:43 -0500 (EST)
Resent-Date: Fri, 7 Feb 2003 09:10:43 -0500 (EST)
Resent-Message-Id: <200302071410.h17EAhw27133@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h17EAeD27006
	for <w3c-dist-auth@frink.w3.org>; Fri, 7 Feb 2003 09:10:40 -0500 (EST)
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 JAA20244
	for <w3c-dist-auth@w3.org>; Fri, 7 Feb 2003 09:10:07 -0500
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>; Fri, 07 Feb 2003 15:09:09 +0100
From: "Julian Reschke" <julian.reschke@greenbytes.de>
To: <w3c-dist-auth@w3.org>
Date: Fri, 7 Feb 2003 15:09:09 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCAEMAGGAA.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.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <JIEGINCHMLABHJBIGKBCEELPGGAA.julian.reschke@greenbytes.de>
X-MDRemoteIP: 192.168.1.23
X-Return-Path: julian.reschke@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3.org
Subject: new BIND issue: example host names
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEMAGGAA.julian.reschke@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7214
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 other thing we'll need to change at some point are the host names that
are used in the examples (RFC2606 lists reserved domain names that can be
used).

Julian

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





From w3c-dist-auth-request@w3.org  Fri Feb  7 12:13:43 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15822
	for <webdav-archive@lists.ietf.org>; Fri, 7 Feb 2003 12:13:42 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h17HGTE04437;
	Fri, 7 Feb 2003 12:16:29 -0500 (EST)
Resent-Date: Fri, 7 Feb 2003 12:16:29 -0500 (EST)
Resent-Message-Id: <200302071716.h17HGTE04437@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h17HGSD04405
	for <w3c-dist-auth@frink.w3.org>; Fri, 7 Feb 2003 12:16:28 -0500 (EST)
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 MAA19822
	for <w3c-dist-auth@w3.org>; Fri, 7 Feb 2003 12:16:28 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 07 Feb 2003 12:00:43 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <1L2CFB2H>; Fri, 7 Feb 2003 12:15:51 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE201DA0232@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "WebDAV (E-mail)" <w3c-dist-auth@w3.org>
Date: Fri, 7 Feb 2003 12:13:52 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2CECC.497ACCB0"
Subject: WebDAV meeting at the 56'th IETF?
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE201DA0232@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7215
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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_01C2CECC.497ACCB0
Content-Type: text/plain;
	charset="iso-8859-1"

Are we planning on having a WebDAV meeting next month?
 I didn't see anything on the IETF-56 Agenda.

Cheers,
Geoff


------_=_NextPart_001_01C2CECC.497ACCB0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.45">
<TITLE>WebDAV meeting at the 56'th IETF?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2 FACE="Arial">Are we planning on having a WebDAV meeting next month?</FONT>
<BR><FONT SIZE=2 FACE="Arial">&nbsp;I didn't see anything on the IETF-56 Agenda.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Cheers,</FONT>
<BR><FONT SIZE=2 FACE="Arial">Geoff</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2CECC.497ACCB0--



From w3c-dist-auth-request@w3.org  Fri Feb  7 17:05:02 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22966
	for <webdav-archive@lists.ietf.org>; Fri, 7 Feb 2003 17:05:01 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h17M7N513886;
	Fri, 7 Feb 2003 17:07:23 -0500 (EST)
Resent-Date: Fri, 7 Feb 2003 17:07:23 -0500 (EST)
Resent-Message-Id: <200302072207.h17M7N513886@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h17M7LD13854
	for <w3c-dist-auth@frink.w3.org>; Fri, 7 Feb 2003 17:07:21 -0500 (EST)
Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA18939
	for <w3c-dist-auth@w3.org>; Fri, 7 Feb 2003 17:07:20 -0500
Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196])
	by ucsc.edu (8.10.1/8.10.1) with SMTP id h17M6iY14565;
	Fri, 7 Feb 2003 14:06:45 -0800 (PST)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "Clemm, Geoff" <gclemm@rational.com>,
        "WebDAV \(E-mail\)" <w3c-dist-auth@w3.org>
Date: Fri, 7 Feb 2003 14:02:16 -0800
Message-ID: <AMEPKEBLDJJCCDEJHAMICELIGFAA.ejw@cse.ucsc.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00B1_01C2CEB1.85CFB330"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <E4F2D33B98DF7E4880884B9F0E6FDEE201DA0232@SUS-MA1IT01>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
X-UCSC-CATS-MailScanner: Found to be clean
Subject: RE: WebDAV meeting at the 56'th IETF?
X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMICELIGFAA.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7216
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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_00B1_01C2CEB1.85CFB330
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

WebDAV meeting at the 56'th IETF?Yes, definitely. A meeting slot was
requested only recently, and so I expect a WG slot will appear in the next
rev. of the IETF-56 agenda.

- Jim
  -----Original Message-----
  From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Clemm, Geoff
  Sent: Friday, February 07, 2003 9:14 AM
  To: WebDAV (E-mail)
  Subject: WebDAV meeting at the 56'th IETF?


  Are we planning on having a WebDAV meeting next month?
   I didn't see anything on the IETF-56 Agenda.

  Cheers,
  Geoff


------=_NextPart_000_00B1_01C2CEB1.85CFB330
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>WebDAV meeting at the 56'th IETF?</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3207.2500" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D807110122-07022003>Yes,=20
definitely. A meeting slot was requested only recently, and so I expect =
a WG=20
slot will appear in the next rev. of the IETF-56 =
agenda.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D807110122-07022003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D807110122-07022003>-=20
Jim</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
w3c-dist-auth-request@w3.org=20
  [mailto:w3c-dist-auth-request@w3.org]<B>On Behalf Of </B>Clemm,=20
  Geoff<BR><B>Sent:</B> Friday, February 07, 2003 9:14 AM<BR><B>To:</B> =
WebDAV=20
  (E-mail)<BR><B>Subject:</B> WebDAV meeting at the 56'th=20
  IETF?<BR><BR></DIV></FONT>
  <P><FONT face=3DArial size=3D2>Are we planning on having a WebDAV =
meeting next=20
  month?</FONT> <BR><FONT face=3DArial size=3D2>&nbsp;I didn't see =
anything on the=20
  IETF-56 Agenda.</FONT> </P>
  <P><FONT face=3DArial size=3D2>Cheers,</FONT> <BR><FONT face=3DArial=20
  size=3D2>Geoff</FONT> </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00B1_01C2CEB1.85CFB330--



From w3c-dist-auth-request@w3.org  Fri Feb  7 21:05:27 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27699
	for <webdav-archive@lists.ietf.org>; Fri, 7 Feb 2003 21:05:27 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1828AN20661;
	Fri, 7 Feb 2003 21:08:10 -0500 (EST)
Resent-Date: Fri, 7 Feb 2003 21:08:10 -0500 (EST)
Resent-Message-Id: <200302080208.h1828AN20661@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h18289D20626
	for <w3c-dist-auth@frink.w3.org>; Fri, 7 Feb 2003 21:08:09 -0500 (EST)
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 VAA21241
	for <w3c-dist-auth@w3.org>; Fri, 7 Feb 2003 21:08:09 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 07 Feb 2003 20:52:29 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <1L2CF8T6>; Fri, 7 Feb 2003 21:07:38 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE201DA0347@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Fri, 7 Feb 2003 21:07:37 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: BIND issue: 5.1_LOOP_STATUS
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE201DA0347@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7218
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


OK, I'll mark this issue as closed unless someone objects.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
Sent: Friday, February 07, 2003 9:02 AM
To: w3c-dist-auth@w3.org
Subject: BIND issue: 5.1_LOOP_STATUS



Back in October, Geoff Clemm wrote:

> If we handled it the way proposed below, the old clients will just ignore
> the new element, and the user will incorrectly conclude that the
collection
> had no child by that name.  With the original proposal, users of
> old clients will be told that there is a child, and will get the
> error message that they've already seen that child, so it is
> being left out of the report.  I think the later is preferable.

I agree that introducing a new error marshalling concept just for an edge
case here (Depth: infinity and bind loop) is unnecessary, in particular if
it may confuse old clients. Therefore the issue should be closed.

Julian

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



From w3c-dist-auth-request@w3.org  Fri Feb  7 21:05:27 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27698
	for <webdav-archive@lists.ietf.org>; Fri, 7 Feb 2003 21:05:27 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1828Fk20759;
	Fri, 7 Feb 2003 21:08:15 -0500 (EST)
Resent-Date: Fri, 7 Feb 2003 21:08:15 -0500 (EST)
Resent-Message-Id: <200302080208.h1828Fk20759@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1828ED20706
	for <w3c-dist-auth@frink.w3.org>; Fri, 7 Feb 2003 21:08:14 -0500 (EST)
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 VAA21272
	for <w3c-dist-auth@w3.org>; Fri, 7 Feb 2003 21:08:14 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 07 Feb 2003 20:52:31 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <1L2CF8T7>; Fri, 7 Feb 2003 21:07:40 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE201DA0348@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: Julian Reschke <julian.reschke@greenbytes.de>, w3c-dist-auth@w3.org
Date: Fri, 7 Feb 2003 21:07:38 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: new BIND issue: example host names
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE201DA0348@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7219
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


Done.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
Sent: Friday, February 07, 2003 9:09 AM
To: w3c-dist-auth@w3.org
Subject: new BIND issue: example host names



Hi,

one other thing we'll need to change at some point are the host names that
are used in the examples (RFC2606 lists reserved domain names that can be
used).

Julian

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




From w3c-dist-auth-request@w3.org  Fri Feb  7 21:05:28 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27703
	for <webdav-archive@lists.ietf.org>; Fri, 7 Feb 2003 21:05:27 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h18288F20621;
	Fri, 7 Feb 2003 21:08:08 -0500 (EST)
Resent-Date: Fri, 7 Feb 2003 21:08:08 -0500 (EST)
Resent-Message-Id: <200302080208.h18288F20621@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h18287D20574
	for <w3c-dist-auth@frink.w3.org>; Fri, 7 Feb 2003 21:08:07 -0500 (EST)
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 VAA21232
	for <w3c-dist-auth@w3.org>; Fri, 7 Feb 2003 21:08:07 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 07 Feb 2003 20:52:27 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <1L2CF8T5>; Fri, 7 Feb 2003 21:07:36 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE201DA0346@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Fri, 7 Feb 2003 21:07:36 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: BIND issue: 4_SPECIAL OVERWRITE_STATUS
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE201DA0346@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7217
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 also agree.  I'll make this change and mark the issue as
closed, unless someone objects.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
Sent: Friday, February 07, 2003 8:59 AM
To: w3c-dist-auth@w3.org
Subject: BIND issue: 4_SPECIAL OVERWRITE_STATUS



Hi,

back in October, Stefan Eissing wrote:

> Maybe it would be more appropriate to reuse the response codes as
> defined for MOVE in RFC 2518:
>
> 201: newly created
> 204: replaced existing resource
>etc.

I agree. MOVE should be identical to BIND/DELETE, and therefore consistency
with MOVE response codes seems to make sense.

Proposal:

Add the sentence:

"In case of success, the server SHOULD return 201 (Created) when a new
binding was created and 204 (No Content) when an existing binding was
replaced".

Julian

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



From w3c-dist-auth-request@w3.org  Sat Feb  8 12:51:16 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26209
	for <webdav-archive@lists.ietf.org>; Sat, 8 Feb 2003 12:51:16 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h18Hjsm08168;
	Sat, 8 Feb 2003 12:45:54 -0500 (EST)
Resent-Date: Sat, 8 Feb 2003 12:45:54 -0500 (EST)
Resent-Message-Id: <200302081745.h18Hjsm08168@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h18HjqD08096
	for <w3c-dist-auth@frink.w3.org>; Sat, 8 Feb 2003 12:45:52 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA29012
	for <w3c-dist-auth@w3c.org>; Sat, 8 Feb 2003 12:45:51 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18hZ2v-000510-00; Sat, 08 Feb 2003 17:45:45 +0000
Received: from [198.144.203.248] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18hZ2t-00050p-00; Sat, 08 Feb 2003 17:45:44 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>
Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Sat, 8 Feb 2003 09:45:46 -0800
Message-ID: <03e801c2cf99$e97eea70$f8cb90c6@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.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Old-X-Envelope-To: julian.reschke@gmx.de,
 w3c-dist-auth@w3c.org
Subject: Review of ordering draft, version 05
X-Archived-At: http://www.w3.org/mid/03e801c2cf99$e97eea70$f8cb90c6@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7220
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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



Since we're getting close to last call on the ordering draft, I reviewed
it all again (it's been years since I did so before).  Here are all my
comments.

Section 3:
"This document uses the terms "precondition" as "postcondition" as
   defined in [RFC3253]. "

Should be "and", not "as"

I don't think it's sufficient to just import the definitions of
precondition and postcondition. These are concepts that can clarify
what's going on, but unless it's accompanied by really plain English,
future readers of the specification won't be able to extract the
information they need. Long-timer WG participants may know the meaning,
but I'm learning more and more about people who never come to the
working groups, who may only read little pieces of our specifications
(e.g. a developer who doesn't usually do protocol implementation but is
assigned to fix a bug).  Server implementors won't bother verifying
whether some condition is one they have to enforce, or simply ignore it.
I strongly recommend including the standard MUST/MAY/SHOULD language
that specification readers are familiar with, particularly in the
postconditions which are not just error code definitions but also
specify behavior.

As an example, I'll jump ahead to the first precondition and
postcondition in section 5.1.  I'm not even sure what they mean, but
I'll try to guess in order to restate them. Here's what I'd like to see:

 Additional Preconditions:

      (DAV:ordered-collections-supported): Error used when the client
attempts to create an ordered collection, if the server does not support
the creation of ordered collections in this namespace.

  Additional Postconditions:

      (DAV:ordering-type-set): The server MUST set the ordering-type
property on the new resource to the value specified in the Ordering-Type
header by the client. If it cannot, this error should be used.

That's just a sample; all of the postconditions and preconditions need
to be full sentences explaining what must or may happen.

Section 5.1:
"If the Ordering-Type header is not present, the collection will be
unordered."

"Will be" is ambiguous standards language.  It implies MUST but doesn't
really require anything.  "... the server MUST create the collection as
unordered" is one possibility. However, it's fine to say "... the
collection MAY be created as unordered" if we want to give servers the
freedom to make new collections ordered by default.

Section 5.1: I don't see how the ordering-type-set postcondition can be
implemented. How can the server tell the difference between an ordering
type that it must support, or an ordering type that it's not supposed to
know about but just advertise?  
  Or is the server just supposed to set the value, period?  If that's
the case, then why isn't this simply a MUST requirement, rather than a
postcondition?
I suspect I don't really understand the ordering-type-set postcondition,
thus it probably just has to be explained more in the specification.
 

Section 6.1
The "segment" definition in BNF is imported from RFC2396.  But that
definition says that a segment can contain a "param":
	RFC2396
	  "segment       = *pchar *( ";" param )"

What would the param be or mean?  I suspect we'll have to define our own
here.

" The server MUST insert the new member into the ordering at the
      location specified in the Position header, if one is present (and
      if the collection is ordered)."

What does the "one" refer to in "if one is present"?  I think this means
"If the collection is ordered and a new member is inserted with the
Position header, the server MUST insert the new member into the ordering
at the location specified in the header."

" (DAV:collection-must-be-ordered): the target collection must be
      ordered."

Does this mean that the request to PUT a resource *fails* if the client
includes a Position header and the collection isn't ordered?  That's
expensive for a client to have fail.  I don't know if that's what client
implementors are going to want to happen.

"    (DAV:segment-must-identify-member): the referenced segment must
      identify a resource that exists and is different from the affected
      resource."

Again, does this mean the server MUST fail the PUT request if the
segment in the Position header doesn't exist?

"     (DAV:position-set): the newly created collection member was
      created at the specified position."

Shouldn't the server always create the new member at the specified
position (a MUST)? Under what circumstances would this ever not happen?

Specification organization: how about putting the Position and
Ordering-Type header definitions in their own sections, titled "Position
Header" and "Ordering-Type Header". That makes it easier for people to
use the specification as a reference.


Section 7.

"     <!ELEMENT orderpatch (ordering-type?, ordermember*) >"

This definition makes the orderpatch element (thus the ORDERPATCH
request body) non-extensible unless we say otherwise.  We could put in
the "elements not understood by the server MUST be ignored" language, or
redefine certain elements as

      <!ELEMENT orderpatch (ordering-type?, ordermember*, ANY) >

We need to say that the list of <ordermember> elements in the orderpatch
body is itself order-dependent -- I believe the server must process them
in the order they appear, first to last.  Actually, this is specified in
section 7.1 under the example, but it should be said in section 7.

"      (DAV:orderding-modified): if the request body contained
      DAV:ordermember elements, the ordering of internal member URIs in
      the collection identified by the request-URI has been changed
      based on instructions in the DAV:ordermember elements."

Isn't this a simple MUST rather than a postcondition?  "The server MUST
order internal member URIs in the collection identified by the
request-URI based on instructions in the DAV:ordermember elements in the
ORDERPATCH request body." Under what conditions would this
ordering-modified error be returned to the client?

Section 7.2.

This example shows what happens if the fourth <segment> element in the
request body does not name a valid segment.  By analogy, I can see what
would be returned if the second <segment> element were invalid. However,
I'm not clear what would happen if the first or third <segment> element
were invalid.  What would be returned in the <href> element in the error
response?

"Because ORDERPATCH is an atomic method, the request to
   reposition nunavut.desc (which would otherwise have succeeded) failed
   as well, but doesn't need to be expressed in the multistatus response
   body."

One of the things we've learned from RFC2518 interoperability is that's
not necessarily true. When a server does a MOVE on a collection, the
client has a hard time figuring out which things moved and which didn't.
Some responses have the failed dependency error, others don't.  Should
we consider being more specific here? The server could simply include a
424 Failed Dependency error for each ordering that failed because of the
atomicity of the method.

Section 9.1.

"The property DAV:version-controlled-binding-set ([RFC3253], section
   14.2.1) records the set of version-controlled bindings in the
   collection. For ordered collections, the DAV:version-controlled-
   binding elements MUST appear in the ordering defined for the checked-
   in ordered collection."

This is true only for working collections when versioned collections are
supported. At a minimum, change to:

"The property DAV:version-controlled-binding-set ([RFC3253], section
   14.2.1) records the set of version-controlled bindings in a
   working collection (part of the versioned collections feature). 
   For an ordered working collections, the 
   DAV:version-controlled-binding elements MUST appear in the ordering 
   defined for the associated checked-in ordered collection."

Doesn't that mean that the user can't reorder a collection that they've
checked out into a working collection?  

Section 10 (Discovery).

"  Furthermore, RFC 3253 [RFC3253] introduces the live properties
   DAV:supported-method-set (section 3.1.3) and DAV:supported-live-
   property-set (section 3.1.4). Servers MUST support these properties
   as defined in RFC 3253."

Do you mean that any server that supports this specification must
support these two RFC3253 properties as well? If so, that could be made
a little more clear like this:

"  Furthermore, RFC 3253 [RFC3253] introduces the live properties
   DAV:supported-method-set (section 3.1.3) and DAV:supported-live-
   property-set (section 3.1.4). Servers supporting ordered-collections
   MUST support these properties as defined in RFC 3253 even if the
   server does not support any RFC3253 features."

Section 16. Acknowledgements

"Lisa Lippert" was me, but my name is now "Lisa Dusseault" again...  I'd
much prefer to be listed as Dusseault!

Lisa




From w3c-dist-auth-request@w3.org  Sat Feb  8 14:47:34 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29248
	for <webdav-archive@lists.ietf.org>; Sat, 8 Feb 2003 14:47:34 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h18JgFH01969;
	Sat, 8 Feb 2003 14:42:15 -0500 (EST)
Resent-Date: Sat, 8 Feb 2003 14:42:15 -0500 (EST)
Resent-Message-Id: <200302081942.h18JgFH01969@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h18JgED01937
	for <w3c-dist-auth@frink.w3.org>; Sat, 8 Feb 2003 14:42:14 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA25627
	for <w3c-dist-auth@w3c.org>; Sat, 8 Feb 2003 14:42:14 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18hard-0005Sl-00
	for w3c-dist-auth@w3c.org; Sat, 08 Feb 2003 19:42:13 +0000
Received: from [198.144.203.248] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18harc-0005Sa-00
	for w3c-dist-auth@w3c.org; Sat, 08 Feb 2003 19:42:13 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Sat, 8 Feb 2003 11:42:15 -0800
Message-ID: <03f001c2cfaa$2f2b44f0$f8cb90c6@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.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Subject: Finding out who locked a resource
X-Archived-At: http://www.w3.org/mid/03f001c2cfaa$2f2b44f0$f8cb90c6@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7221
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 of the things that 2518 didn't try to do, because it had to finish
in finite time, was to specify exactly how a lock owner is shown. One of
the problems was there was no way to identify users.

Now that Access control exists, there is a way to identify users, and
the problem can be solved much more nicely.  I suggest we add an element
"principal-URL" to the lock properties. The element is defined in the
Access control specification, but it would appear inside the "lockinfo"
element as part of the "lockdiscovery" property.  This wouldn't
interfere with the "owner" element, which already is used by some
clients.

My approach would be to add this to access control, since that will
probably get this useful element standardized sooner.  "A server MUST
include the principal-URL element inside the lockinfo element of a
lockdiscovery property value, if the LOCK request that created the lock
successfully authenticated as a known principal."

Lisa




From w3c-dist-auth-request@w3.org  Sat Feb  8 15:01:10 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29492
	for <webdav-archive@lists.ietf.org>; Sat, 8 Feb 2003 15:01:10 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h18JuIA09235;
	Sat, 8 Feb 2003 14:56:18 -0500 (EST)
Resent-Date: Sat, 8 Feb 2003 14:56:18 -0500 (EST)
Resent-Message-Id: <200302081956.h18JuIA09235@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h18JuHD09183
	for <w3c-dist-auth@frink.w3.org>; Sat, 8 Feb 2003 14:56:17 -0500 (EST)
Received: from mail.gmx.net (mail.gmx.net [213.165.65.60])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA29314
	for <w3c-dist-auth@w3c.org>; Sat, 8 Feb 2003 14:56:16 -0500
Received: (qmail 27166 invoked by uid 0); 8 Feb 2003 19:55:32 -0000
Received: from pD950C259.dip.t-dialin.net (HELO lisa) (217.80.194.89)
  by mail.gmx.net (mp001-rz3) with SMTP; 8 Feb 2003 19:55:32 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Lisa Dusseault" <lisa@xythos.com>, "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Sat, 8 Feb 2003 20:55:16 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCOENPGGAA.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.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <03e801c2cf99$e97eea70$f8cb90c6@xythoslap>
Subject: RE: Review of ordering draft, version 05
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOENPGGAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7222
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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,

thanks for the review of the document. My comments are inline.

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Saturday, February 08, 2003 6:46 PM
> To: 'Julian Reschke'
> Cc: Webdav WG
> Subject: Review of ordering draft, version 05
>
>
>
>
> Since we're getting close to last call on the ordering draft, I reviewed
> it all again (it's been years since I did so before).  Here are all my
> comments.
>
> Section 3:
> "This document uses the terms "precondition" as "postcondition" as
>    defined in [RFC3253]. "
>
> Should be "and", not "as"

Fixed.

> I don't think it's sufficient to just import the definitions of
> precondition and postcondition. These are concepts that can clarify
> what's going on, but unless it's accompanied by really plain English,
> future readers of the specification won't be able to extract the
> information they need. Long-timer WG participants may know the meaning,
> but I'm learning more and more about people who never come to the
> working groups, who may only read little pieces of our specifications
> (e.g. a developer who doesn't usually do protocol implementation but is
> assigned to fix a bug).  Server implementors won't bother verifying
> whether some condition is one they have to enforce, or simply ignore it.

Well, the simple answer is, there *are* not pre/postconditions a server can
ignore. Quoting from RFC3253, section 1.6:

---> A "precondition" of a method describes the state of the server that
must be true for that method to be performed. A "postcondition" of a method
describes the state of the server that must be true after that method has
been completed. If a method precondition or postcondition for a request is
not satisfied, the response status of the request MUST be either 403
(Forbidden) if the request should not be repeated because it will always
fail, or 409 (Conflict) if it is expected that the user might be able to
resolve the conflict and resubmit the request.<---

> I strongly recommend including the standard MUST/MAY/SHOULD language
> that specification readers are familiar with, particularly in the
> postconditions which are not just error code definitions but also
> specify behavior.

Actually the goal was to do that by normatively referring to RFC3253.

> As an example, I'll jump ahead to the first precondition and
> postcondition in section 5.1.  I'm not even sure what they mean, but
> I'll try to guess in order to restate them. Here's what I'd like to see:
>
>  Additional Preconditions:
>
>       (DAV:ordered-collections-supported): Error used when the client
> attempts to create an ordered collection, if the server does not support
> the creation of ordered collections in this namespace.
>
>   Additional Postconditions:
>
>       (DAV:ordering-type-set): The server MUST set the ordering-type
> property on the new resource to the value specified in the Ordering-Type
> header by the client. If it cannot, this error should be used.
>
> That's just a sample; all of the postconditions and preconditions need
> to be full sentences explaining what must or may happen.

All of them are MUSTs. Thinking of it (and remembering the WG discussion),
the ACL spec may want to clarify that it's using the terminology in a way
that is not fully compatible to RFC3253.

> Section 5.1:
> "If the Ordering-Type header is not present, the collection will be
> unordered."
>
> "Will be" is ambiguous standards language.  It implies MUST but doesn't
> really require anything.  "... the server MUST create the collection as
> unordered" is one possibility. However, it's fine to say "... the
> collection MAY be created as unordered" if we want to give servers the
> freedom to make new collections ordered by default.

That's a good question. Is there any specific behaviour we want to mandate?
Are there use cases where a server may want to default to a specific
ordering type when none was given?

> Section 5.1: I don't see how the ordering-type-set postcondition can be
> implemented. How can the server tell the difference between an ordering
> type that it must support, or an ordering type that it's not supposed to
> know about but just advertise?

Correct.

All we want to say that the ordering type was set as given:

(DAV:ordering-type-set): the collection was created with the specified
ordering type.


>   Or is the server just supposed to set the value, period?  If that's
> the case, then why isn't this simply a MUST requirement, rather than a
> postcondition?

Again, all conditons are MUSTs.

> I suspect I don't really understand the ordering-type-set postcondition,
> thus it probably just has to be explained more in the specification.
>
>
> Section 6.1
> The "segment" definition in BNF is imported from RFC2396.  But that
> definition says that a segment can contain a "param":
> 	RFC2396
> 	  "segment       = *pchar *( ";" param )"
>
> What would the param be or mean?  I suspect we'll have to define our own
> here.

No, we don't. We just inherit. It means whatever RFC2396 wants it to mean.

> " The server MUST insert the new member into the ordering at the
>       location specified in the Position header, if one is present (and
>       if the collection is ordered)."
>
> What does the "one" refer to in "if one is present"?  I think this means
> "If the collection is ordered and a new member is inserted with the
> Position header, the server MUST insert the new member into the ordering
> at the location specified in the header."

Rewritten as:

"When the Position header is present, the server MUST insert the new member
into the ordering at the specified location."

> " (DAV:collection-must-be-ordered): the target collection must be
>       ordered."
>
> Does this mean that the request to PUT a resource *fails* if the client
> includes a Position header and the collection isn't ordered?  That's
> expensive for a client to have fail.  I don't know if that's what client
> implementors are going to want to happen.

It's what the spec has been saying for a long time.

I also don't see why that's a problem. It will only be a problem if

- the collection was ordered at time x
- a client does a PUT at time y and specifies a location header (if it
doesn't care, it can let it default to "last") *and*
- between x and y the collection was set to unordered by somebody else.

Seems like a case where I really *want* the request to fail. The client can
always use a sequence of PUT (without Position) and ORDERPATCH if this is
really an issue.

> "    (DAV:segment-must-identify-member): the referenced segment must
>       identify a resource that exists and is different from the affected
>       resource."
>
> Again, does this mean the server MUST fail the PUT request if the
> segment in the Position header doesn't exist?

Yes.

> "     (DAV:position-set): the newly created collection member was
>       created at the specified position."
>
> Shouldn't the server always create the new member at the specified
> position (a MUST)? Under what circumstances would this ever not happen?

Yes, it's a MUST.

> Specification organization: how about putting the Position and
> Ordering-Type header definitions in their own sections, titled "Position
> Header" and "Ordering-Type Header". That makes it easier for people to
> use the specification as a reference.

However it also leads to text duplication. People can use both the TOC and
the index to locate the relevant section.

> Section 7.
>
> "     <!ELEMENT orderpatch (ordering-type?, ordermember*) >"
>
> This definition makes the orderpatch element (thus the ORDERPATCH
> request body) non-extensible unless we say otherwise.  We could put in
> the "elements not understood by the server MUST be ignored" language, or

No, it doesn't. It uses DTD fragments in *exactly* the same way as RFC2518
and RFC3253, that is the standard WebDAV extensibility rules apply.

> redefine certain elements as
>
>       <!ELEMENT orderpatch (ordering-type?, ordermember*, ANY) >
>
> We need to say that the list of <ordermember> elements in the orderpatch
> body is itself order-dependent -- I believe the server must process them
> in the order they appear, first to last.  Actually, this is specified in
> section 7.1 under the example, but it should be said in section 7.

Correct.

Section 7 changed to say: "The ordering of internal member URIs in the
collection identified by the Request-URI is changed based on instructions in
the order-member XML elements in the order they appear in the request."

Also the explanations for example 7.1 were still assuming the old "href"
based syntax, I've updated that as well.

> "      (DAV:orderding-modified): if the request body contained
>       DAV:ordermember elements, the ordering of internal member URIs in
>       the collection identified by the request-URI has been changed
>       based on instructions in the DAV:ordermember elements."
>
> Isn't this a simple MUST rather than a postcondition?  "The server MUST
> order internal member URIs in the collection identified by the
> request-URI based on instructions in the DAV:ordermember elements in the
> ORDERPATCH request body." Under what conditions would this
> ordering-modified error be returned to the client?

That would be a server error (it's MUST).

> Section 7.2.
>
> This example shows what happens if the fourth <segment> element in the
> request body does not name a valid segment.  By analogy, I can see what
> would be returned if the second <segment> element were invalid. However,
> I'm not clear what would happen if the first or third <segment> element
> were invalid.  What would be returned in the <href> element in the error
> response?

The URI that identifies the member that could not be repositioned. As per

"Since multiple changes can be requested in a single ORDERPATCH request, if
any problems are encountered, the server MUST return a 207 (Multi-Status)
response (defined in [RFC2518]), containing DAV:response elements for either
the request-URI (when the DAV:ordering-type could not be modified) or URIs
of collection members to be repositioned (when an individual positioning
request expressed as DAV:order-member could not be fulfilled)."

> "Because ORDERPATCH is an atomic method, the request to
>    reposition nunavut.desc (which would otherwise have succeeded) failed
>    as well, but doesn't need to be expressed in the multistatus response
>    body."
>
> One of the things we've learned from RFC2518 interoperability is that's
> not necessarily true. When a server does a MOVE on a collection, the
> client has a hard time figuring out which things moved and which didn't.

That's because MOVE in RFC2518 is not atomic.

> Some responses have the failed dependency error, others don't.  Should
> we consider being more specific here? The server could simply include a
> 424 Failed Dependency error for each ordering that failed because of the
> atomicity of the method.

How would that help? A client can rely on the request being atomic.

> Section 9.1.
>
> "The property DAV:version-controlled-binding-set ([RFC3253], section
>    14.2.1) records the set of version-controlled bindings in the
>    collection. For ordered collections, the DAV:version-controlled-
>    binding elements MUST appear in the ordering defined for the checked-
>    in ordered collection."
>
> This is true only for working collections when versioned collections are
> supported. At a minimum, change to:

The property DAV:version-controlled-binding-set is only defined for
collection versions. So yes, this only applies to servers that support
versioned collections.

> ...
>
> Doesn't that mean that the user can't reorder a collection that they've
> checked out into a working collection?

Why would it mean that? A working collection doesn't have that property.

What indeed is missing here is some words about how the ordering in
DAV:version-controlled-binding-set affects UPDATE and CHECKOUT of collection
versions.

> Section 10 (Discovery).
>
> "  Furthermore, RFC 3253 [RFC3253] introduces the live properties
>    DAV:supported-method-set (section 3.1.3) and DAV:supported-live-
>    property-set (section 3.1.4). Servers MUST support these properties
>    as defined in RFC 3253."
>
> Do you mean that any server that supports this specification must
> support these two RFC3253 properties as well? If so, that could be made

Yes.

> a little more clear like this:
>
> "  Furthermore, RFC 3253 [RFC3253] introduces the live properties
>    DAV:supported-method-set (section 3.1.3) and DAV:supported-live-
>    property-set (section 3.1.4). Servers supporting ordered-collections
>    MUST support these properties as defined in RFC 3253 even if the
>    server does not support any RFC3253 features."

Well, in that case it supports RFC3253 features (namely these two live
properties). I'd say that normatively referring to a specific part of
another RFC should really be clear enough.

> Section 16. Acknowledgements
>
> "Lisa Lippert" was me, but my name is now "Lisa Dusseault" again...  I'd
> much prefer to be listed as Dusseault!

Done.

Again,

thanks for the review!

Julian

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



From w3c-dist-auth-request@w3.org  Sat Feb  8 15:18:56 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29797
	for <webdav-archive@lists.ietf.org>; Sat, 8 Feb 2003 15:18:56 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h18KE3g20437;
	Sat, 8 Feb 2003 15:14:03 -0500 (EST)
Resent-Date: Sat, 8 Feb 2003 15:14:03 -0500 (EST)
Resent-Message-Id: <200302082014.h18KE3g20437@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h18KE2D20390
	for <w3c-dist-auth@frink.w3.org>; Sat, 8 Feb 2003 15:14:02 -0500 (EST)
Received: from mail.gmx.net (mail.gmx.net [213.165.65.60])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA00960
	for <w3c-dist-auth@w3c.org>; Sat, 8 Feb 2003 15:14:01 -0500
Received: (qmail 30391 invoked by uid 0); 8 Feb 2003 20:13:21 -0000
Received: from pD950C259.dip.t-dialin.net (HELO lisa) (217.80.194.89)
  by mail.gmx.net (mp005-rz3) with SMTP; 8 Feb 2003 20:13:21 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Lisa Dusseault" <lisa@xythos.com>, "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Sat, 8 Feb 2003 21:13:06 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCMEOAGGAA.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.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <03f001c2cfaa$2f2b44f0$f8cb90c6@xythoslap>
Subject: RE: Finding out who locked a resource
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEOAGGAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7223
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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: Saturday, February 08, 2003 8:42 PM
> To: Webdav WG
> Subject: Finding out who locked a resource
>
>
>
>
> One of the things that 2518 didn't try to do, because it had to finish
> in finite time, was to specify exactly how a lock owner is shown. One of
> the problems was there was no way to identify users.
>
> Now that Access control exists, there is a way to identify users, and
> the problem can be solved much more nicely.  I suggest we add an element
> "principal-URL" to the lock properties. The element is defined in the
> Access control specification, but it would appear inside the "lockinfo"
> element as part of the "lockdiscovery" property.  This wouldn't
> interfere with the "owner" element, which already is used by some
> clients.
>
> My approach would be to add this to access control, since that will
> probably get this useful element standardized sooner.  "A server MUST
> include the principal-URL element inside the lockinfo element of a
> lockdiscovery property value, if the LOCK request that created the lock
> successfully authenticated as a known principal."

Agreed.

Are there any security concerns here? The DAV:owner live property is a MUST
property as well, so this doesn't seem to be an issue.

Julian

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



From w3c-dist-auth-request@w3.org  Tue Feb 11 00:19:19 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09033
	for <webdav-archive@lists.ietf.org>; Tue, 11 Feb 2003 00:19:18 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1B5M0316151;
	Tue, 11 Feb 2003 00:22:00 -0500 (EST)
Resent-Date: Tue, 11 Feb 2003 00:22:00 -0500 (EST)
Resent-Message-Id: <200302110522.h1B5M0316151@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1B5LwR16034
	for <w3c-dist-auth@frink.w3.org>; Tue, 11 Feb 2003 00:21:59 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA06649
	for <w3c-dist-auth@w3c.org>; Tue, 11 Feb 2003 00:21:58 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18iSrl-00047a-00
	for w3c-dist-auth@w3c.org; Tue, 11 Feb 2003 05:21:57 +0000
Received: from [198.144.203.248] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18iSrk-00047P-00
	for w3c-dist-auth@w3c.org; Tue, 11 Feb 2003 05:21:57 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Mon, 10 Feb 2003 21:22:00 -0800
Message-ID: <001001c2d18d$815cc610$f8cb90c6@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.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Subject: FW: IETF Meetings and Overhead Projectors
X-Archived-At: http://www.w3.org/mid/001001c2d18d$815cc610$f8cb90c6@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7224
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


FYI -- don't bother bringing overhead slides or blanks to WG meetings
unless we know ahead of time you need an overhead.  Since most people
bring laptops for presentations anyway, this won't impact us much.

Which reminds me -- we need input for the agenda for the SF WebDAV
meeting (which is *tentatively* scheduled for Tuesday, March 18).
Particularly, I need volunteers to lead discussions on various topics
like ACLs, bindings, ordered collections, search, RFC2518bis issues.

Lisa

-----Original Message-----
From: owner-wgchairs@ietf.org [mailto:owner-wgchairs@ietf.org] On Behalf
Of Marcia Beaulieu
Sent: Monday, February 10, 2003 7:46 AM
To: wgchairs@ietf.org; bofchairs@ietf.org
Cc: Dinara Suleymanova
Subject: IETF Meetings and Overhead Projectors


Hi all,

Starting with the IETF meeting in San Francisco, overhead projectors
will
not be
provided in the meeting rooms unless specifically requested.  Data
projectors will
be in all working group and BOF meeting rooms.

If you feel there is a need for an overhead projector in your session,
please send
your request to agenda@ietf.org

Thanks,

Marcia








From w3c-dist-auth-request@w3.org  Tue Feb 11 00:54:51 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10228
	for <webdav-archive@lists.ietf.org>; Tue, 11 Feb 2003 00:54:51 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1B5vT319696;
	Tue, 11 Feb 2003 00:57:29 -0500 (EST)
Resent-Date: Tue, 11 Feb 2003 00:57:29 -0500 (EST)
Resent-Message-Id: <200302110557.h1B5vT319696@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1B5vRR19664
	for <w3c-dist-auth@frink.w3.org>; Tue, 11 Feb 2003 00:57:27 -0500 (EST)
Received: from newgennet.newgen.co.in (IDENT:0@[203.168.76.148])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA12048
	for <w3c-dist-auth@w3c.org>; Tue, 11 Feb 2003 00:57:22 -0500
Received: from nhweb.newgen.co.in ([203.168.76.5])
	by newgennet.newgen.co.in (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA04751
	for <w3c-dist-auth@w3c.org>; Tue, 11 Feb 2003 11:24:44 +0530
X-Authentication-Warning: newgennet.newgen.co.in: Host [203.168.76.5] claimed to be nhweb.newgen.co.in
Received: from anil (ws152.newgen.co.in [192.168.5.152])
	by nhweb.newgen.co.in (8.12.3/8.12.3/Debian -4) with SMTP id h1B67eYZ018960
	for <w3c-dist-auth@w3c.org>; Tue, 11 Feb 2003 11:37:43 +0530
Message-ID: <007e01c2d192$ef2e3b10$9805a8c0@anil>
From: "Anil Bhandari" <anilb@newgen.co.in>
To: <w3c-dist-auth@w3c.org>
Date: Tue, 11 Feb 2003 11:30:49 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_007B_01C2D1C1.072E66D0"
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: Versioning Clients
X-Archived-At: http://www.w3.org/mid/007e01c2d192$ef2e3b10$9805a8c0@anil
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7225
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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_007B_01C2D1C1.072E66D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi

Can anybody tell me about the WebDAV Versioning clients that are =
available today?
i have incorporated the versioning (rfc 3253) feature in my Webdav =
server and now i want to test it through some standard versioning =
clients available.

Thanx

Anil

------=_NextPart_000_007B_01C2D1C1.072E66D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Can anybody tell me about the WebDAV =
Versioning=20
clients that are available today?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>i have&nbsp;incorporated =
the&nbsp;versioning (rfc=20
3253) feature in my Webdav server&nbsp;and now i want to test it through =
some=20
standard versioning clients available.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanx</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anil</FONT></DIV></BODY></HTML>

------=_NextPart_000_007B_01C2D1C1.072E66D0--



From w3c-dist-auth-request@w3.org  Tue Feb 11 06:47:53 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28909
	for <webdav-archive@lists.ietf.org>; Tue, 11 Feb 2003 06:47:53 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1BBo5Y09207;
	Tue, 11 Feb 2003 06:50:05 -0500 (EST)
Resent-Date: Tue, 11 Feb 2003 06:50:05 -0500 (EST)
Resent-Message-Id: <200302111150.h1BBo5Y09207@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1BBo4R09175
	for <w3c-dist-auth@frink.w3.org>; Tue, 11 Feb 2003 06:50:04 -0500 (EST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA14974
	for <w3c-dist-auth@w3.org>; Tue, 11 Feb 2003 06:50:00 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28733;
	Tue, 11 Feb 2003 06:46:16 -0500 (EST)
Message-Id: <200302111146.GAA28733@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: Tue, 11 Feb 2003 06:46:15 -0500
Subject: I-D ACTION:draft-ietf-webdav-bind-01.txt
X-Archived-At: http://www.w3.org/mid/200302111146.GAA28733@ietf.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7226
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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		: Binding Extensions to WebDAV
	Author(s)	: G. Clemm, J. Crawford et al.
	Filename	: draft-ietf-webdav-bind-01.txt
	Pages		: 19
	Date		: 2003-2-10
	
This specification defines bindings, and the BIND method for creating 
multiple bindings to the same resource.  Creating a new binding to a 
resource causes at least one new URI to be mapped to that resource.  
Servers are required to insure the integrity of any bindings that they 
allow to be created.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-01.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-bind-01.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-bind-01.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:	<2003-2-10133029.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-webdav-bind-01.txt

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

Content-Type: text/plain
Content-ID:	<2003-2-10133029.I-D@ietf.org>

--OtherAccess--

--NextPart--




From w3c-dist-auth-request@w3.org  Tue Feb 11 12:57:56 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13287
	for <webdav-archive@lists.ietf.org>; Tue, 11 Feb 2003 12:57:56 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1BHxNf18436;
	Tue, 11 Feb 2003 12:59:23 -0500 (EST)
Resent-Date: Tue, 11 Feb 2003 12:59:23 -0500 (EST)
Resent-Message-Id: <200302111759.h1BHxNf18436@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1BHx8R18400
	for <w3c-dist-auth@frink.w3.org>; Tue, 11 Feb 2003 12:59:08 -0500 (EST)
Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA24079
	for <w3c-dist-auth@w3c.org>; Tue, 11 Feb 2003 12:59:08 -0500
Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196])
	by ucsc.edu (8.10.1/8.10.1) with SMTP id h1BHwQY07023;
	Tue, 11 Feb 2003 09:58:29 -0800 (PST)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "Anil Bhandari" <anilb@newgen.co.in>, <w3c-dist-auth@w3c.org>
Cc: <joe@manyfish.co.uk>
Date: Tue, 11 Feb 2003 09:53:56 -0800
Message-ID: <AMEPKEBLDJJCCDEJHAMIAEBBGGAA.ejw@cse.ucsc.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_008E_01C2D1B3.7E1483A0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <007e01c2d192$ef2e3b10$9805a8c0@anil>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
X-UCSC-CATS-MailScanner: Found to be clean
Subject: RE: Versioning Clients
X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIAEBBGGAA.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7227
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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_008E_01C2D1B3.7E1483A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

We have incorporated basic versioning capability into the Cadaver client,
and have submitted the code patches to Joe Orton. He is in the process of
incorporating them into the mainline code base for Cadaver, and this should
be part of the next release.

- Jim
  -----Original Message-----
  From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Anil Bhandari
  Sent: Monday, February 10, 2003 10:01 PM
  To: w3c-dist-auth@w3c.org
  Subject: Versioning Clients


  Hi

  Can anybody tell me about the WebDAV Versioning clients that are available
today?
  i have incorporated the versioning (rfc 3253) feature in my Webdav server
and now i want to test it through some standard versioning clients
available.

  Thanx

  Anil

------=_NextPart_000_008E_01C2D1B3.7E1483A0
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 =
class=3D473405217-11022003>We=20
have incorporated basic versioning capability into the Cadaver client, =
and have=20
submitted the code patches to Joe Orton. He is in the process of =
incorporating=20
them into the mainline code base for Cadaver, and this should be part of =
the=20
next release.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D473405217-11022003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D473405217-11022003>-=20
Jim</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
w3c-dist-auth-request@w3.org=20
  [mailto:w3c-dist-auth-request@w3.org]<B>On Behalf Of </B>Anil=20
  Bhandari<BR><B>Sent:</B> Monday, February 10, 2003 10:01 =
PM<BR><B>To:</B>=20
  w3c-dist-auth@w3c.org<BR><B>Subject:</B> Versioning=20
  Clients<BR><BR></DIV></FONT>
  <DIV><FONT face=3DArial size=3D2>Hi</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Can anybody tell me about the WebDAV =
Versioning=20
  clients that are available today?</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>i have&nbsp;incorporated =
the&nbsp;versioning (rfc=20
  3253) feature in my Webdav server&nbsp;and now i want to test it =
through some=20
  standard versioning clients available.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Thanx</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial =
size=3D2>Anil</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_008E_01C2D1B3.7E1483A0--



From w3c-dist-auth-request@w3.org  Wed Feb 12 10:04:12 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05401
	for <webdav-archive@lists.ietf.org>; Wed, 12 Feb 2003 10:04:12 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1CF6b512576;
	Wed, 12 Feb 2003 10:06:37 -0500 (EST)
Resent-Date: Wed, 12 Feb 2003 10:06:37 -0500 (EST)
Resent-Message-Id: <200302121506.h1CF6b512576@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1CF6YR12534
	for <w3c-dist-auth@frink.w3.org>; Wed, 12 Feb 2003 10:06:34 -0500 (EST)
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 KAA20007
	for <w3c-dist-auth@w3.org>; Wed, 12 Feb 2003 10:06:33 -0500
Received: (qmail 22776 invoked by uid 0); 12 Feb 2003 15:06:32 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp013-rz3) with SMTP; 12 Feb 2003 15:06:32 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: <w3c-dist-auth@w3.org>
Date: Wed, 12 Feb 2003 16:06:32 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCGEFCGHAA.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.6604 (9.0.2911.0)
In-Reply-To: <200302111146.GAA28733@ietf.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: I-D ACTION:draft-ietf-webdav-bind-01.txt
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEFCGHAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7228
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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,

this draft differs from the latest edits made in October in that two open
issues have been resolved (both were raised by myself and resolved in
agreement between Geoff and me). I therefore the working group to issue the
"last call" for this spec.

Julian

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



From w3c-dist-auth-request@w3.org  Wed Feb 12 14:33:03 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12962
	for <webdav-archive@lists.ietf.org>; Wed, 12 Feb 2003 14:33:03 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1CJZlK15333;
	Wed, 12 Feb 2003 14:35:47 -0500 (EST)
Resent-Date: Wed, 12 Feb 2003 14:35:47 -0500 (EST)
Resent-Message-Id: <200302121935.h1CJZlK15333@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1CJZkR15301
	for <w3c-dist-auth@frink.w3.org>; Wed, 12 Feb 2003 14:35:46 -0500 (EST)
Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA19916
	for <w3c-dist-auth@w3.org>; Wed, 12 Feb 2003 14:35:45 -0500
Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196])
	by ucsc.edu (8.10.1/8.10.1) with SMTP id h1CJW3s19983
	for <w3c-dist-auth@w3.org>; Wed, 12 Feb 2003 11:32:03 -0800 (PST)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "WebDAV" <w3c-dist-auth@w3.org>
Date: Wed, 12 Feb 2003 11:27:32 -0800
Message-ID: <AMEPKEBLDJJCCDEJHAMIGEDGGGAA.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
X-UCSC-CATS-MailScanner: Found to be clean
Subject: San Francisco IETF WebDAV slot
X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIGEDGGGAA.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7229
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 will be meeting at the San Francisco IETF meeting. At present,
we have been assigned the time slot:

TUESDAY, March 18, 2003
1545-1645 Afternoon Sessions III
APP     webdav    WWW Distributed Authoring and Versioning WG

For information on the meeting, including registration instructions, see:

http://www.ietf.org/meetings/IETF-56.html

Note that the early registration deadline is March 7, 2003.

- Jim




From w3c-dist-auth-request@w3.org  Wed Feb 12 15:48:54 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15318
	for <webdav-archive@lists.ietf.org>; Wed, 12 Feb 2003 15:48:54 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1CKpbK11135;
	Wed, 12 Feb 2003 15:51:37 -0500 (EST)
Resent-Date: Wed, 12 Feb 2003 15:51:37 -0500 (EST)
Resent-Message-Id: <200302122051.h1CKpbK11135@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1CKpZR11102
	for <w3c-dist-auth@frink.w3.org>; Wed, 12 Feb 2003 15:51:35 -0500 (EST)
Received: from mail7.uunet.ca (root@mail7.uunet.ca [142.77.1.26])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA11655
	for <w3c-dist-auth@w3.org>; Wed, 12 Feb 2003 15:51:35 -0500
Received: from newtradetech.com (h209-71-207-130.gtconnect.net [209.71.207.130]) by mail7.uunet.ca with ESMTP id <522529-27082>; Wed, 12 Feb 2003 15:49:20 -0500
Message-ID: <3E4AB4ED.9090502@newtradetech.com>
Date: Wed, 12 Feb 2003 15:56:13 -0500
From: Andre John Mas <ajmas@newtradetech.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: shares
X-Archived-At: http://www.w3.org/mid/3E4AB4ED.9090502@newtradetech.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7230
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 would like to know whether with webdav there is any provision
to advertising the shares available on a given server? The idea,
with the, conjunction of a technology such as Rendezvous, would
be to list the servers with 'shares' in local area and then list
the webdav resources being made available by the server.

regards

Andre



From w3c-dist-auth-request@w3.org  Wed Feb 12 18:17:18 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18677
	for <webdav-archive@lists.ietf.org>; Wed, 12 Feb 2003 18:17:13 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1CNJQ011580;
	Wed, 12 Feb 2003 18:19:26 -0500 (EST)
Resent-Date: Wed, 12 Feb 2003 18:19:26 -0500 (EST)
Resent-Message-Id: <200302122319.h1CNJQ011580@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1CNJPR11546
	for <w3c-dist-auth@frink.w3.org>; Wed, 12 Feb 2003 18:19:25 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA20328
	for <w3c-dist-auth@w3.org>; Wed, 12 Feb 2003 18:19:25 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18j69y-0005G8-00; Wed, 12 Feb 2003 23:19:22 +0000
Received: from nat.briank.com ([198.144.201.195] helo=xythos.com)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18j69y-0005Fx-00; Wed, 12 Feb 2003 23:19:22 +0000
Date: Wed, 12 Feb 2003 15:19:18 -0800
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: w3c-dist-auth@w3.org
To: Andre John Mas <ajmas@newtradetech.com>
From: Brian Korver <briank@xythos.com>
In-Reply-To: <3E4AB4ED.9090502@newtradetech.com>
Message-Id: <68BD77A8-3EE0-11D7-ABB3-000393751598@xythos.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Old-X-Envelope-To: w3c-dist-auth@w3.org,
 ajmas@newtradetech.com
Subject: Re: shares
X-Archived-At: http://www.w3.org/mid/68BD77A8-3EE0-11D7-ABB3-000393751598@xythos.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7231
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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, February 12, 2003, at 12:56 PM, Andre John Mas wrote:
> Hi,
>
> I would like to know whether with webdav there is any provision
> to advertising the shares available on a given server? The idea,
> with the, conjunction of a technology such as Rendezvous, would
> be to list the servers with 'shares' in local area and then list
> the webdav resources being made available by the server.
>
> regards
>
> Andre

Ander,

No, there isn't.  It would be nice tho'.

-brian
briank@xythos.com




From w3c-dist-auth-request@w3.org  Thu Feb 13 11:39:58 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17566
	for <webdav-archive@lists.ietf.org>; Thu, 13 Feb 2003 11:39:58 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1DGgEE08360;
	Thu, 13 Feb 2003 11:42:14 -0500 (EST)
Resent-Date: Thu, 13 Feb 2003 11:42:14 -0500 (EST)
Resent-Message-Id: <200302131642.h1DGgEE08360@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1DGgCR08324
	for <w3c-dist-auth@frink.w3.org>; Thu, 13 Feb 2003 11:42:12 -0500 (EST)
Received: from mail11.uunet.ca (root@mail11.uunet.ca [142.77.1.48])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA23269
	for <w3c-dist-auth@w3.org>; Thu, 13 Feb 2003 11:42:12 -0500
Received: from newtradetech.com (h209-71-207-130.gtconnect.net [209.71.207.130]) by mail11.uunet.ca with ESMTP id <76034-16406>; Thu, 13 Feb 2003 11:38:33 -0500
Message-ID: <3E4BCBA9.7020607@newtradetech.com>
Date: Thu, 13 Feb 2003 11:45:29 -0500
From: Andre John Mas <ajmas@newtradetech.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <68BD77A8-3EE0-11D7-ABB3-000393751598@xythos.com>
In-Reply-To: <68BD77A8-3EE0-11D7-ABB3-000393751598@xythos.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: shares
X-Archived-At: http://www.w3.org/mid/3E4BCBA9.7020607@newtradetech.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7232
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


Brian Korver wrote:
> 
> On Wednesday, February 12, 2003, at 12:56 PM, Andre John Mas wrote:
> 
>> Hi,
>>
>> I would like to know whether with webdav there is any provision
>> to advertising the shares available on a given server? The idea,
>> with the, conjunction of a technology such as Rendezvous, would
>> be to list the servers with 'shares' in local area and then list
>> the webdav resources being made available by the server.
>>
>> regards
>>
>> Andre
> 
> 
> Ander,
> 
> No, there isn't.  It would be nice tho'.
> 

If this indeed the case, maybe this is something that should be
examined?  Maybe a simple solution to this (note - two second
analysis ;) would be an XML file at the root. The file would
have a standard name, maybe something such as webdav.xml and
would list the shares:

   <webdav version="x.x">
     <description text="my shares"/>
     <shares>
        <share name="music" description="my music for you to discover"
           guest="yes"/>
        <share name="docs" description="development docs" guest="no"/>
      </shares>
   </webdav>

The server would have the option of dynamically changing the published
xml file depending on whether the file was request with a user name or
without. With this in mind, any client should probably support a
redirection to another URL which provides the data - this is in order
to allow retrofitting of this functionality to existing servers, and
maybe even indicating that the server has been moved?

   <webdav version="x.x">
      <redirection path="/servlets/sharelist"/>
   </webdav>

   <webdav version="x.x">
      <moved url="http://myserver/" message="server has been moved"/>
   </webdav>

   <webdav version="x.x">
      <unavailable message="this server be taken out of service"/>
   </webdav>

Although there is probably a lot that could be done, hopefully
this should serve as a seed for future work?

Andre



From w3c-dist-auth-request@w3.org  Thu Feb 13 14:54:51 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23504
	for <webdav-archive@lists.ietf.org>; Thu, 13 Feb 2003 14:54:50 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1DJv4d18263;
	Thu, 13 Feb 2003 14:57:04 -0500 (EST)
Resent-Date: Thu, 13 Feb 2003 14:57:04 -0500 (EST)
Resent-Message-Id: <200302131957.h1DJv4d18263@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1DJv3R18231
	for <w3c-dist-auth@frink.w3.org>; Thu, 13 Feb 2003 14:57:03 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA15456
	for <w3c-dist-auth@w3.org>; Thu, 13 Feb 2003 14:57:02 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18jPTb-0006yB-00; Thu, 13 Feb 2003 19:56:55 +0000
Received: from [216.36.77.241] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18jPTa-0006y0-00; Thu, 13 Feb 2003 19:56:55 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Brian Korver'" <briank@xythos.com>,
        "'Andre John Mas'" <ajmas@newtradetech.com>
Cc: <w3c-dist-auth@w3.org>
Date: Thu, 13 Feb 2003 11:56:58 -0800
Message-ID: <00cc01c2d39a$117156e0$f8cb90c6@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.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <68BD77A8-3EE0-11D7-ABB3-000393751598@xythos.com>
Old-X-Envelope-To: ajmas@newtradetech.com,
 briank@xythos.com,
 w3c-dist-auth@w3.org
Subject: RE: shares
X-Archived-At: http://www.w3.org/mid/00cc01c2d39a$117156e0$f8cb90c6@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7233
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


There's another potential technology for this kind of thing besides
Rendezvous: the Service Location Protocol. It's not exactly the same,
but it's useful in its own way.
http://www.srvloc.org/

lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Brian Korver
> Sent: Wednesday, February 12, 2003 3:19 PM
> To: Andre John Mas
> Cc: w3c-dist-auth@w3.org
> Subject: Re: shares
> 
> 
> 
> On Wednesday, February 12, 2003, at 12:56 PM, Andre John Mas wrote:
> > Hi,
> >
> > I would like to know whether with webdav there is any provision
> > to advertising the shares available on a given server? The idea,
> > with the, conjunction of a technology such as Rendezvous, would
> > be to list the servers with 'shares' in local area and then list
> > the webdav resources being made available by the server.
> >
> > regards
> >
> > Andre
> 
> Ander,
> 
> No, there isn't.  It would be nice tho'.
> 
> -brian
> briank@xythos.com
> 
> 
> 




From w3c-dist-auth-request@w3.org  Thu Feb 13 15:23:18 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26059
	for <webdav-archive@lists.ietf.org>; Thu, 13 Feb 2003 15:23:17 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1DKQ4j23050;
	Thu, 13 Feb 2003 15:26:04 -0500 (EST)
Resent-Date: Thu, 13 Feb 2003 15:26:04 -0500 (EST)
Resent-Message-Id: <200302132026.h1DKQ4j23050@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1DKQ1R22931
	for <w3c-dist-auth@frink.w3.org>; Thu, 13 Feb 2003 15:26:01 -0500 (EST)
Received: from mail.gmx.net (mail.gmx.net [213.165.65.60])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA22781
	for <w3c-dist-auth@w3c.org>; Thu, 13 Feb 2003 15:25:49 -0500
Received: (qmail 17600 invoked by uid 0); 13 Feb 2003 20:25:16 -0000
Received: from p3EE2482F.dip.t-dialin.net (HELO lisa) (62.226.72.47)
  by mail.gmx.net (mp003-rz3) with SMTP; 13 Feb 2003 20:25:16 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Thu, 13 Feb 2003 21:25:14 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCGEIOGHAA.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.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <03e801c2cf99$e97eea70$f8cb90c6@xythoslap>
Subject: RE: Review of ordering draft, version 05
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEIOGHAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7234
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 have adressed some of Lisa's issues, in particular:

- how to interpret the DTD fragments [1]
- reference to RFC3253 pre/postcondition definition [2]

I've also tried to clarify the relation to versioned collection ([3]).

To those who revieved the 05 draft: please check out the current version
(all changes are highlighted) -- I intend to submit this draft as "last
call" version early next week.

Julian


[1]
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-latest
.html#rfc.section.1>
[2]
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-latest
.html#rfc.section.3>
[3]
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-latest
.html#rfc.section.9>

--
<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: Saturday, February 08, 2003 6:46 PM
> To: 'Julian Reschke'
> Cc: Webdav WG
> Subject: Review of ordering draft, version 05
>
>
>
>
> Since we're getting close to last call on the ordering draft, I reviewed
> it all again (it's been years since I did so before).  Here are all my
> comments.
>
> Section 3:
> "This document uses the terms "precondition" as "postcondition" as
>    defined in [RFC3253]. "
>
> Should be "and", not "as"
>
> I don't think it's sufficient to just import the definitions of
> precondition and postcondition. These are concepts that can clarify
> what's going on, but unless it's accompanied by really plain English,
> future readers of the specification won't be able to extract the
> information they need. Long-timer WG participants may know the meaning,
> but I'm learning more and more about people who never come to the
> working groups, who may only read little pieces of our specifications
> (e.g. a developer who doesn't usually do protocol implementation but is
> assigned to fix a bug).  Server implementors won't bother verifying
> whether some condition is one they have to enforce, or simply ignore it.
> I strongly recommend including the standard MUST/MAY/SHOULD language
> that specification readers are familiar with, particularly in the
> postconditions which are not just error code definitions but also
> specify behavior.
>
> As an example, I'll jump ahead to the first precondition and
> postcondition in section 5.1.  I'm not even sure what they mean, but
> I'll try to guess in order to restate them. Here's what I'd like to see:
>
>  Additional Preconditions:
>
>       (DAV:ordered-collections-supported): Error used when the client
> attempts to create an ordered collection, if the server does not support
> the creation of ordered collections in this namespace.
>
>   Additional Postconditions:
>
>       (DAV:ordering-type-set): The server MUST set the ordering-type
> property on the new resource to the value specified in the Ordering-Type
> header by the client. If it cannot, this error should be used.
>
> That's just a sample; all of the postconditions and preconditions need
> to be full sentences explaining what must or may happen.
>
> Section 5.1:
> "If the Ordering-Type header is not present, the collection will be
> unordered."
>
> "Will be" is ambiguous standards language.  It implies MUST but doesn't
> really require anything.  "... the server MUST create the collection as
> unordered" is one possibility. However, it's fine to say "... the
> collection MAY be created as unordered" if we want to give servers the
> freedom to make new collections ordered by default.
>
> Section 5.1: I don't see how the ordering-type-set postcondition can be
> implemented. How can the server tell the difference between an ordering
> type that it must support, or an ordering type that it's not supposed to
> know about but just advertise?
>   Or is the server just supposed to set the value, period?  If that's
> the case, then why isn't this simply a MUST requirement, rather than a
> postcondition?
> I suspect I don't really understand the ordering-type-set postcondition,
> thus it probably just has to be explained more in the specification.
>
>
> Section 6.1
> The "segment" definition in BNF is imported from RFC2396.  But that
> definition says that a segment can contain a "param":
> 	RFC2396
> 	  "segment       = *pchar *( ";" param )"
>
> What would the param be or mean?  I suspect we'll have to define our own
> here.
>
> " The server MUST insert the new member into the ordering at the
>       location specified in the Position header, if one is present (and
>       if the collection is ordered)."
>
> What does the "one" refer to in "if one is present"?  I think this means
> "If the collection is ordered and a new member is inserted with the
> Position header, the server MUST insert the new member into the ordering
> at the location specified in the header."
>
> " (DAV:collection-must-be-ordered): the target collection must be
>       ordered."
>
> Does this mean that the request to PUT a resource *fails* if the client
> includes a Position header and the collection isn't ordered?  That's
> expensive for a client to have fail.  I don't know if that's what client
> implementors are going to want to happen.
>
> "    (DAV:segment-must-identify-member): the referenced segment must
>       identify a resource that exists and is different from the affected
>       resource."
>
> Again, does this mean the server MUST fail the PUT request if the
> segment in the Position header doesn't exist?
>
> "     (DAV:position-set): the newly created collection member was
>       created at the specified position."
>
> Shouldn't the server always create the new member at the specified
> position (a MUST)? Under what circumstances would this ever not happen?
>
> Specification organization: how about putting the Position and
> Ordering-Type header definitions in their own sections, titled "Position
> Header" and "Ordering-Type Header". That makes it easier for people to
> use the specification as a reference.
>
>
> Section 7.
>
> "     <!ELEMENT orderpatch (ordering-type?, ordermember*) >"
>
> This definition makes the orderpatch element (thus the ORDERPATCH
> request body) non-extensible unless we say otherwise.  We could put in
> the "elements not understood by the server MUST be ignored" language, or
> redefine certain elements as
>
>       <!ELEMENT orderpatch (ordering-type?, ordermember*, ANY) >
>
> We need to say that the list of <ordermember> elements in the orderpatch
> body is itself order-dependent -- I believe the server must process them
> in the order they appear, first to last.  Actually, this is specified in
> section 7.1 under the example, but it should be said in section 7.
>
> "      (DAV:orderding-modified): if the request body contained
>       DAV:ordermember elements, the ordering of internal member URIs in
>       the collection identified by the request-URI has been changed
>       based on instructions in the DAV:ordermember elements."
>
> Isn't this a simple MUST rather than a postcondition?  "The server MUST
> order internal member URIs in the collection identified by the
> request-URI based on instructions in the DAV:ordermember elements in the
> ORDERPATCH request body." Under what conditions would this
> ordering-modified error be returned to the client?
>
> Section 7.2.
>
> This example shows what happens if the fourth <segment> element in the
> request body does not name a valid segment.  By analogy, I can see what
> would be returned if the second <segment> element were invalid. However,
> I'm not clear what would happen if the first or third <segment> element
> were invalid.  What would be returned in the <href> element in the error
> response?
>
> "Because ORDERPATCH is an atomic method, the request to
>    reposition nunavut.desc (which would otherwise have succeeded) failed
>    as well, but doesn't need to be expressed in the multistatus response
>    body."
>
> One of the things we've learned from RFC2518 interoperability is that's
> not necessarily true. When a server does a MOVE on a collection, the
> client has a hard time figuring out which things moved and which didn't.
> Some responses have the failed dependency error, others don't.  Should
> we consider being more specific here? The server could simply include a
> 424 Failed Dependency error for each ordering that failed because of the
> atomicity of the method.
>
> Section 9.1.
>
> "The property DAV:version-controlled-binding-set ([RFC3253], section
>    14.2.1) records the set of version-controlled bindings in the
>    collection. For ordered collections, the DAV:version-controlled-
>    binding elements MUST appear in the ordering defined for the checked-
>    in ordered collection."
>
> This is true only for working collections when versioned collections are
> supported. At a minimum, change to:
>
> "The property DAV:version-controlled-binding-set ([RFC3253], section
>    14.2.1) records the set of version-controlled bindings in a
>    working collection (part of the versioned collections feature).
>    For an ordered working collections, the
>    DAV:version-controlled-binding elements MUST appear in the ordering
>    defined for the associated checked-in ordered collection."
>
> Doesn't that mean that the user can't reorder a collection that they've
> checked out into a working collection?
>
> Section 10 (Discovery).
>
> "  Furthermore, RFC 3253 [RFC3253] introduces the live properties
>    DAV:supported-method-set (section 3.1.3) and DAV:supported-live-
>    property-set (section 3.1.4). Servers MUST support these properties
>    as defined in RFC 3253."
>
> Do you mean that any server that supports this specification must
> support these two RFC3253 properties as well? If so, that could be made
> a little more clear like this:
>
> "  Furthermore, RFC 3253 [RFC3253] introduces the live properties
>    DAV:supported-method-set (section 3.1.3) and DAV:supported-live-
>    property-set (section 3.1.4). Servers supporting ordered-collections
>    MUST support these properties as defined in RFC 3253 even if the
>    server does not support any RFC3253 features."
>
> Section 16. Acknowledgements
>
> "Lisa Lippert" was me, but my name is now "Lisa Dusseault" again...  I'd
> much prefer to be listed as Dusseault!
>
> Lisa
>
>



From w3c-dist-auth-request@w3.org  Thu Feb 13 16:20:38 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02055
	for <webdav-archive@lists.ietf.org>; Thu, 13 Feb 2003 16:20:38 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1DLMVp01767;
	Thu, 13 Feb 2003 16:22:31 -0500 (EST)
Resent-Date: Thu, 13 Feb 2003 16:22:31 -0500 (EST)
Resent-Message-Id: <200302132122.h1DLMVp01767@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1DLMPR01734
	for <w3c-dist-auth@frink.w3.org>; Thu, 13 Feb 2003 16:22:25 -0500 (EST)
Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA04722
	for <w3c-dist-auth@w3c.org>; Thu, 13 Feb 2003 16:22:25 -0500
Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196])
	by ucsc.edu (8.10.1/8.10.1) with SMTP id h1DLL0Y12340;
	Thu, 13 Feb 2003 13:21:01 -0800 (PST)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "Anil Bhandari" <anilb@newgen.co.in>, <w3c-dist-auth@w3c.org>
Date: Thu, 13 Feb 2003 13:16:29 -0800
Message-ID: <AMEPKEBLDJJCCDEJHAMIMEGNGGAA.ejw@cse.ucsc.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0064_01C2D362.1E69EF70"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <AMEPKEBLDJJCCDEJHAMIAEBBGGAA.ejw@cse.ucsc.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
X-UCSC-CATS-MailScanner: Found to be clean
Subject: RE: Versioning Clients
X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIMEGNGGAA.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7235
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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_0064_01C2D362.1E69EF70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

A new version of Cadaver (0.21.0) was released today
http://www.webdav.org/cadaver/ featuring DASL and DeltaV support.

- Jim
  -----Original Message-----
  From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Jim Whitehead
  Sent: Tuesday, February 11, 2003 9:54 AM
  To: Anil Bhandari; w3c-dist-auth@w3c.org
  Cc: joe@manyfish.co.uk
  Subject: RE: Versioning Clients


  We have incorporated basic versioning capability into the Cadaver client,
and have submitted the code patches to Joe Orton. He is in the process of
incorporating them into the mainline code base for Cadaver, and this should
be part of the next release.

  - Jim
    -----Original Message-----
    From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Anil Bhandari
    Sent: Monday, February 10, 2003 10:01 PM
    To: w3c-dist-auth@w3c.org
    Subject: Versioning Clients


    Hi

    Can anybody tell me about the WebDAV Versioning clients that are
available today?
    i have incorporated the versioning (rfc 3253) feature in my Webdav
server and now i want to test it through some standard versioning clients
available.

    Thanx

    Anil

------=_NextPart_000_0064_01C2D362.1E69EF70
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 =
class=3D868061121-13022003>A new=20
version of Cadaver (0.21.0) was released today <A=20
href=3D"http://www.webdav.org/cadaver/">http://www.webdav.org/cadaver/</A=
>&nbsp;featuring=20
DASL and DeltaV support.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D868061121-13022003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D868061121-13022003>-=20
Jim</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
w3c-dist-auth-request@w3.org=20
  [mailto:w3c-dist-auth-request@w3.org]<B>On Behalf Of </B>Jim=20
  Whitehead<BR><B>Sent:</B> Tuesday, February 11, 2003 9:54 =
AM<BR><B>To:</B>=20
  Anil Bhandari; w3c-dist-auth@w3c.org<BR><B>Cc:</B>=20
  joe@manyfish.co.uk<BR><B>Subject:</B> RE: Versioning=20
  Clients<BR><BR></DIV></FONT>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D473405217-11022003>We=20
  have incorporated basic versioning capability into the Cadaver client, =
and=20
  have submitted the code patches to Joe Orton. He is in the process of=20
  incorporating them into the mainline code base for Cadaver, and this =
should be=20
  part of the next release.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D473405217-11022003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D473405217-11022003>-=20
  Jim</SPAN></FONT></DIV>
  <BLOCKQUOTE=20
  style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B>=20
    w3c-dist-auth-request@w3.org =
[mailto:w3c-dist-auth-request@w3.org]<B>On=20
    Behalf Of </B>Anil Bhandari<BR><B>Sent:</B> Monday, February 10, =
2003 10:01=20
    PM<BR><B>To:</B> w3c-dist-auth@w3c.org<BR><B>Subject:</B> Versioning =

    Clients<BR><BR></DIV></FONT>
    <DIV><FONT face=3DArial size=3D2>Hi</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>Can anybody tell me about the =
WebDAV Versioning=20
    clients that are available today?</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>i have&nbsp;incorporated =
the&nbsp;versioning=20
    (rfc 3253) feature in my Webdav server&nbsp;and now i want to test =
it=20
    through some standard versioning clients available.</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>Thanx</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial=20
size=3D2>Anil</FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0064_01C2D362.1E69EF70--



From w3c-dist-auth-request@w3.org  Thu Feb 13 20:21:45 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25253
	for <webdav-archive@lists.ietf.org>; Thu, 13 Feb 2003 20:21:45 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1E1OJF25466;
	Thu, 13 Feb 2003 20:24:19 -0500 (EST)
Resent-Date: Thu, 13 Feb 2003 20:24:19 -0500 (EST)
Resent-Message-Id: <200302140124.h1E1OJF25466@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1E1OIR25432
	for <w3c-dist-auth@frink.w3.org>; Thu, 13 Feb 2003 20:24:18 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA01622
	for <w3c-dist-auth@w3c.org>; Thu, 13 Feb 2003 20:24:17 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18jUaM-0003lH-00; Fri, 14 Feb 2003 01:24:14 +0000
Received: from [216.36.77.241] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18jUaM-0003l6-00; Fri, 14 Feb 2003 01:24:14 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Thu, 13 Feb 2003 17:24:12 -0800
Message-ID: <001401c2d3c7$cb375930$b601a8c0@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.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <JIEGINCHMLABHJBIGKBCGEIOGHAA.julian.reschke@gmx.de>
Old-X-Envelope-To: julian.reschke@gmx.de,
 w3c-dist-auth@w3c.org
Subject: RE: Review of ordering draft, version 05
X-Archived-At: http://www.w3.org/mid/001401c2d3c7$cb375930$b601a8c0@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7236
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 feel strongly that postconditions (and ideally also
preconditions) should be explained as full English sentences

For example, replace

  "(DAV:ordering-type-set): the collection was created with the
specified ordering type. "

With

  "(DAV:ordering-type-set): The server MUST set the ordering-type
  property on the new resource to the value specified in the
Ordering-Type
  header by the client. If it cannot, this error should be used."

I will propose specific text for every postcondition if necessary.

Lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke
> Sent: Thursday, February 13, 2003 12:25 PM
> To: Webdav WG
> Subject: RE: Review of ordering draft, version 05
> 
> 
> 
> Hi.
> 
> I have adressed some of Lisa's issues, in particular:
> 
> - how to interpret the DTD fragments [1]
> - reference to RFC3253 pre/postcondition definition [2]
> 
> I've also tried to clarify the relation to versioned collection ([3]).
> 
> To those who revieved the 05 draft: please check out the 
> current version
> (all changes are highlighted) -- I intend to submit this 
> draft as "last
> call" version early next week.
> 
> Julian
> 
> 
> [1]
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-p
> rotocol-latest
> .html#rfc.section.1>
> [2]
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-p
> rotocol-latest
> .html#rfc.section.3>
> [3]
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-p
> rotocol-latest
> .html#rfc.section.9>
> 
> --
> <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: Saturday, February 08, 2003 6:46 PM
> > To: 'Julian Reschke'
> > Cc: Webdav WG
> > Subject: Review of ordering draft, version 05
> >
> >
> >
> >
> > Since we're getting close to last call on the ordering 
> draft, I reviewed
> > it all again (it's been years since I did so before).  Here 
> are all my
> > comments.
> >
> > Section 3:
> > "This document uses the terms "precondition" as "postcondition" as
> >    defined in [RFC3253]. "
> >
> > Should be "and", not "as"
> >
> > I don't think it's sufficient to just import the definitions of
> > precondition and postcondition. These are concepts that can clarify
> > what's going on, but unless it's accompanied by really 
> plain English,
> > future readers of the specification won't be able to extract the
> > information they need. Long-timer WG participants may know 
> the meaning,
> > but I'm learning more and more about people who never come to the
> > working groups, who may only read little pieces of our 
> specifications
> > (e.g. a developer who doesn't usually do protocol 
> implementation but is
> > assigned to fix a bug).  Server implementors won't bother verifying
> > whether some condition is one they have to enforce, or 
> simply ignore it.
> > I strongly recommend including the standard MUST/MAY/SHOULD language
> > that specification readers are familiar with, particularly in the
> > postconditions which are not just error code definitions but also
> > specify behavior.
> >
> > As an example, I'll jump ahead to the first precondition and
> > postcondition in section 5.1.  I'm not even sure what they mean, but
> > I'll try to guess in order to restate them. Here's what I'd 
> like to see:
> >
> >  Additional Preconditions:
> >
> >       (DAV:ordered-collections-supported): Error used when 
> the client
> > attempts to create an ordered collection, if the server 
> does not support
> > the creation of ordered collections in this namespace.
> >
> >   Additional Postconditions:
> >
> >       (DAV:ordering-type-set): The server MUST set the ordering-type
> > property on the new resource to the value specified in the 
> Ordering-Type
> > header by the client. If it cannot, this error should be used.
> >
> > That's just a sample; all of the postconditions and 
> preconditions need
> > to be full sentences explaining what must or may happen.
> >
> > Section 5.1:
> > "If the Ordering-Type header is not present, the collection will be
> > unordered."
> >
> > "Will be" is ambiguous standards language.  It implies MUST 
> but doesn't
> > really require anything.  "... the server MUST create the 
> collection as
> > unordered" is one possibility. However, it's fine to say "... the
> > collection MAY be created as unordered" if we want to give 
> servers the
> > freedom to make new collections ordered by default.
> >
> > Section 5.1: I don't see how the ordering-type-set 
> postcondition can be
> > implemented. How can the server tell the difference between 
> an ordering
> > type that it must support, or an ordering type that it's 
> not supposed to
> > know about but just advertise?
> >   Or is the server just supposed to set the value, period?  
> If that's
> > the case, then why isn't this simply a MUST requirement, 
> rather than a
> > postcondition?
> > I suspect I don't really understand the ordering-type-set 
> postcondition,
> > thus it probably just has to be explained more in the specification.
> >
> >
> > Section 6.1
> > The "segment" definition in BNF is imported from RFC2396.  But that
> > definition says that a segment can contain a "param":
> > 	RFC2396
> > 	  "segment       = *pchar *( ";" param )"
> >
> > What would the param be or mean?  I suspect we'll have to 
> define our own
> > here.
> >
> > " The server MUST insert the new member into the ordering at the
> >       location specified in the Position header, if one is 
> present (and
> >       if the collection is ordered)."
> >
> > What does the "one" refer to in "if one is present"?  I 
> think this means
> > "If the collection is ordered and a new member is inserted with the
> > Position header, the server MUST insert the new member into 
> the ordering
> > at the location specified in the header."
> >
> > " (DAV:collection-must-be-ordered): the target collection must be
> >       ordered."
> >
> > Does this mean that the request to PUT a resource *fails* 
> if the client
> > includes a Position header and the collection isn't ordered?  That's
> > expensive for a client to have fail.  I don't know if 
> that's what client
> > implementors are going to want to happen.
> >
> > "    (DAV:segment-must-identify-member): the referenced segment must
> >       identify a resource that exists and is different from 
> the affected
> >       resource."
> >
> > Again, does this mean the server MUST fail the PUT request if the
> > segment in the Position header doesn't exist?
> >
> > "     (DAV:position-set): the newly created collection member was
> >       created at the specified position."
> >
> > Shouldn't the server always create the new member at the specified
> > position (a MUST)? Under what circumstances would this ever 
> not happen?
> >
> > Specification organization: how about putting the Position and
> > Ordering-Type header definitions in their own sections, 
> titled "Position
> > Header" and "Ordering-Type Header". That makes it easier 
> for people to
> > use the specification as a reference.
> >
> >
> > Section 7.
> >
> > "     <!ELEMENT orderpatch (ordering-type?, ordermember*) >"
> >
> > This definition makes the orderpatch element (thus the ORDERPATCH
> > request body) non-extensible unless we say otherwise.  We 
> could put in
> > the "elements not understood by the server MUST be ignored" 
> language, or
> > redefine certain elements as
> >
> >       <!ELEMENT orderpatch (ordering-type?, ordermember*, ANY) >
> >
> > We need to say that the list of <ordermember> elements in 
> the orderpatch
> > body is itself order-dependent -- I believe the server must 
> process them
> > in the order they appear, first to last.  Actually, this is 
> specified in
> > section 7.1 under the example, but it should be said in section 7.
> >
> > "      (DAV:orderding-modified): if the request body contained
> >       DAV:ordermember elements, the ordering of internal 
> member URIs in
> >       the collection identified by the request-URI has been changed
> >       based on instructions in the DAV:ordermember elements."
> >
> > Isn't this a simple MUST rather than a postcondition?  "The 
> server MUST
> > order internal member URIs in the collection identified by the
> > request-URI based on instructions in the DAV:ordermember 
> elements in the
> > ORDERPATCH request body." Under what conditions would this
> > ordering-modified error be returned to the client?
> >
> > Section 7.2.
> >
> > This example shows what happens if the fourth <segment> 
> element in the
> > request body does not name a valid segment.  By analogy, I 
> can see what
> > would be returned if the second <segment> element were 
> invalid. However,
> > I'm not clear what would happen if the first or third 
> <segment> element
> > were invalid.  What would be returned in the <href> element 
> in the error
> > response?
> >
> > "Because ORDERPATCH is an atomic method, the request to
> >    reposition nunavut.desc (which would otherwise have 
> succeeded) failed
> >    as well, but doesn't need to be expressed in the 
> multistatus response
> >    body."
> >
> > One of the things we've learned from RFC2518 
> interoperability is that's
> > not necessarily true. When a server does a MOVE on a collection, the
> > client has a hard time figuring out which things moved and 
> which didn't.
> > Some responses have the failed dependency error, others 
> don't.  Should
> > we consider being more specific here? The server could 
> simply include a
> > 424 Failed Dependency error for each ordering that failed 
> because of the
> > atomicity of the method.
> >
> > Section 9.1.
> >
> > "The property DAV:version-controlled-binding-set ([RFC3253], section
> >    14.2.1) records the set of version-controlled bindings in the
> >    collection. For ordered collections, the DAV:version-controlled-
> >    binding elements MUST appear in the ordering defined for 
> the checked-
> >    in ordered collection."
> >
> > This is true only for working collections when versioned 
> collections are
> > supported. At a minimum, change to:
> >
> > "The property DAV:version-controlled-binding-set ([RFC3253], section
> >    14.2.1) records the set of version-controlled bindings in a
> >    working collection (part of the versioned collections feature).
> >    For an ordered working collections, the
> >    DAV:version-controlled-binding elements MUST appear in 
> the ordering
> >    defined for the associated checked-in ordered collection."
> >
> > Doesn't that mean that the user can't reorder a collection 
> that they've
> > checked out into a working collection?
> >
> > Section 10 (Discovery).
> >
> > "  Furthermore, RFC 3253 [RFC3253] introduces the live properties
> >    DAV:supported-method-set (section 3.1.3) and DAV:supported-live-
> >    property-set (section 3.1.4). Servers MUST support these 
> properties
> >    as defined in RFC 3253."
> >
> > Do you mean that any server that supports this specification must
> > support these two RFC3253 properties as well? If so, that 
> could be made
> > a little more clear like this:
> >
> > "  Furthermore, RFC 3253 [RFC3253] introduces the live properties
> >    DAV:supported-method-set (section 3.1.3) and DAV:supported-live-
> >    property-set (section 3.1.4). Servers supporting 
> ordered-collections
> >    MUST support these properties as defined in RFC 3253 even if the
> >    server does not support any RFC3253 features."
> >
> > Section 16. Acknowledgements
> >
> > "Lisa Lippert" was me, but my name is now "Lisa Dusseault" 
> again...  I'd
> > much prefer to be listed as Dusseault!
> >
> > Lisa
> >
> >
> 
> 




From w3c-dist-auth-request@w3.org  Fri Feb 14 04:28:42 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14596
	for <webdav-archive@lists.ietf.org>; Fri, 14 Feb 2003 04:28:42 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1E9Uqk02817;
	Fri, 14 Feb 2003 04:30:52 -0500 (EST)
Resent-Date: Fri, 14 Feb 2003 04:30:52 -0500 (EST)
Resent-Message-Id: <200302140930.h1E9Uqk02817@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1E9UoR02784
	for <w3c-dist-auth@frink.w3.org>; Fri, 14 Feb 2003 04:30:50 -0500 (EST)
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 EAA01761
	for <w3c-dist-auth@w3c.org>; Fri, 14 Feb 2003 04:30:50 -0500
Received: (qmail 29914 invoked by uid 0); 14 Feb 2003 09:30:18 -0000
Received: from p3EE2481E.dip.t-dialin.net (HELO lisa) (62.226.72.30)
  by mail.gmx.net (mp019-rz3) with SMTP; 14 Feb 2003 09:30:18 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Lisa Dusseault" <lisa@xythos.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Fri, 14 Feb 2003 10:30:17 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCMEKAGHAA.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.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <001401c2d3c7$cb375930$b601a8c0@xythoslap>
Subject: RE: Review of ordering draft, version 05
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEKAGHAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7237
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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: Friday, February 14, 2003 2:24 AM
> To: 'Julian Reschke'; 'Webdav WG'
> Subject: RE: Review of ordering draft, version 05
>
>
>
> I still feel strongly that postconditions (and ideally also
> preconditions) should be explained as full English sentences
>
> For example, replace
>
>   "(DAV:ordering-type-set): the collection was created with the
> specified ordering type. "

(that *is* a full sentence, isn't it?)

> With
>
>   "(DAV:ordering-type-set): The server MUST set the ordering-type
>   property on the new resource to the value specified in the
> Ordering-Type
>   header by the client. If it cannot, this error should be used."

I agree that the condition itself can be expressed in a more stringent
manner. However, I strongly disagree with the second sentence: all
pre/postconditions are MUSTs (by definition), and therefore the statement is
(a) redundant and (b) - for consistency - it would have to be repeated on
each an every condition.

> I will propose specific text for every postcondition if necessary.

Julian

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



From w3c-dist-auth-request@w3.org  Fri Feb 14 07:21:06 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19466
	for <webdav-archive@lists.ietf.org>; Fri, 14 Feb 2003 07:21:05 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1ECNXL14944;
	Fri, 14 Feb 2003 07:23:33 -0500 (EST)
Resent-Date: Fri, 14 Feb 2003 07:23:33 -0500 (EST)
Resent-Message-Id: <200302141223.h1ECNXL14944@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1ECNVR14907
	for <w3c-dist-auth@frink.w3.org>; Fri, 14 Feb 2003 07:23:31 -0500 (EST)
Received: from server8.software-ag.de (server8.software-ag.de [193.26.193.23])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA14455
	for <w3c-dist-auth@w3c.org>; Fri, 14 Feb 2003 07:23:31 -0500
Received: from daehub01.software-ag.de by server8.software-ag.de; (8.11.6/8.9.3)
	id h1ECMfk24923; Fri, 14 Feb 2003 13:22:50 +0100
Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2653.19)
	id <1AR469DX>; Fri, 14 Feb 2003 13:23:00 +0100
Message-ID: <DFF2AC9E3583D511A21F0008C7E6210605C47D99@daemsg02.software-ag.de>
From: "Nevermann, Dr., Peter" <Peter.Nevermann@softwareag.com>
To: "'Lisa Dusseault'" <lisa@xythos.com>
Cc: "'w3c-dist-auth@w3c.org'" <w3c-dist-auth@w3c.org>
Date: Fri, 14 Feb 2003 13:22:49 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Finding out who locked a resource
X-Archived-At: http://www.w3.org/mid/DFF2AC9E3583D511A21F0008C7E6210605C47D99@daemsg02.software-ag.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7238
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


Interoperability problems with some clients may arise when adding an
DAV:principal-URL element to the DAV:lockdiscovery property.

In the case of Microsoft Office2000 (e.g. Word), I noticed that it depends
on the *order* of the child elements inside the DAV:activelock element. If
the DAV:principal-URL element doesn't come *last*, as in the attached sample
PROPFIND response, Word doesn't seem to send correctly the Lock-Token:
header. This occurs,for example, when creating a new resource: the PUT
request following the LOCK request (which initially created a lock-null
resource) sends Lock-Token: <>.

Regards,
Peter

<?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:">
<D:response xmlns:D="DAV:">
    <D:href>/taminowebdavserver/mycoll/foo/Hello.doc</D:href>
    <D:propstat>
        <D:prop>
            <D:lockdiscovery>
                <D:activelock>
                    <D:locktype>
                        <D:write />
                    </D:locktype>
                    <D:lockscope>
                        <D:exclusive />
                    </D:lockscope>
                    <D:depth>infinity</D:depth>
                    <D:owner><![CDATA[pn]]></D:owner>
                    <D:principal-URL>
                        <D:href>/users/localhost/davuser</D:href>
                    </D:principal-URL>
                    <D:timeout>Second-60</D:timeout>
                    <D:locktoken>
 
<D:href>opaquelocktoken:a1c232a71a2bfa5f2008fb162ccaecdb</D:href>
                    </D:locktoken>
                </D:activelock>
            </D:lockdiscovery>
        </D:prop>
        <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
</D:response>

</D:multistatus>


Regards,
Peter Nevermann

Software AG, Research & Development
Uhlandstr. 12, D-64297 Darmstadt
+49-6151-92-1828
http://developer.softwareag.com/tamino/
 

> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Saturday, February 08, 2003 20:42
> To: Webdav WG
> Subject: Finding out who locked a resource
> 
> 
> 
> 
> One of the things that 2518 didn't try to do, because it had to finish
> in finite time, was to specify exactly how a lock owner is 
> shown. One of
> the problems was there was no way to identify users.
> 
> Now that Access control exists, there is a way to identify users, and
> the problem can be solved much more nicely.  I suggest we add 
> an element
> "principal-URL" to the lock properties. The element is defined in the
> Access control specification, but it would appear inside the 
> "lockinfo"
> element as part of the "lockdiscovery" property.  This wouldn't
> interfere with the "owner" element, which already is used by some
> clients.
> 
> My approach would be to add this to access control, since that will
> probably get this useful element standardized sooner.  "A server MUST
> include the principal-URL element inside the lockinfo element of a
> lockdiscovery property value, if the LOCK request that 
> created the lock
> successfully authenticated as a known principal."
> 
> Lisa
> 
> 



From w3c-dist-auth-request@w3.org  Fri Feb 14 18:56:02 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09789
	for <webdav-archive@lists.ietf.org>; Fri, 14 Feb 2003 18:56:01 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1ENwVL06761;
	Fri, 14 Feb 2003 18:58:31 -0500 (EST)
Resent-Date: Fri, 14 Feb 2003 18:58:31 -0500 (EST)
Resent-Message-Id: <200302142358.h1ENwVL06761@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1ENwUR06699
	for <w3c-dist-auth@frink.w3.org>; Fri, 14 Feb 2003 18:58:30 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA30049
	for <w3c-dist-auth@w3c.org>; Fri, 14 Feb 2003 18:58:29 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18jjaI-0001Eh-00; Fri, 14 Feb 2003 17:25:10 +0000
Received: from [216.36.77.241] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18jjaI-0001EW-00; Fri, 14 Feb 2003 17:25:10 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Fri, 14 Feb 2003 09:25:09 -0800
Message-ID: <00c501c2d44e$09a8f300$b601a8c0@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.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <JIEGINCHMLABHJBIGKBCMEKAGHAA.julian.reschke@gmx.de>
Old-X-Envelope-To: julian.reschke@gmx.de,
 w3c-dist-auth@w3c.org
Subject: RE: Review of ordering draft, version 05
X-Archived-At: http://www.w3.org/mid/00c501c2d44e$09a8f300$b601a8c0@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7239
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


> >   "(DAV:ordering-type-set): the collection was created with the
> > specified ordering type. "
> 
> (that *is* a full sentence, isn't it?)

My suggestion isn't really about grammar, it's about readability.  This
is a passive phrase, which requires the reader to have a lot of context
and experience to understand what behavior is required of whom.  

> I agree that the condition itself can be expressed in a more stringent
> manner. However, I strongly disagree with the second sentence: all
> pre/postconditions are MUSTs (by definition), and therefore 
> the statement is
> (a) redundant and (b) - for consistency - it would have to be 
> repeated on
> each an every condition.

Yes, I agree that consistency helps make a spec readable.  What I'm
proposing is to put a phrase such as "the server MUST..." on each and
every condition. I will propose specific sentences if necessary, but I'm
not sure I even understand each postcondition (which is itself clearly a
problem).

The reason I suggest this redundancy is because I talk to a lot of
people who implement WebDAV yet who haven't read every word of every
spec.  I remember my first job working on WebDAV in 1998 and I just
browsed through the WebDAV and HTTP specs lightly. Then when a developer
would ask me a specific question about something like how range headers
worked, I'd look up that specific section. Usually, I could find the
answer without having to integrate massive amounts of text from various
sources, because in fact RFC2616 and RFC2518 are fairly well-written. 

Since this is the way specifications are used, a well-written
specification *does* have a lot of redundancy. In writing essays,
students are told to say what you're going to say, say it, and then say
what you said. A specification is not a piece of code, to be executed by
a computer which can load every line into memory and compile before
executing. It's a puzzle that's too big to be seen at once, so instead
each reader picks up a small piece of the puzzle at a time and tries to
understand some of the picture just from that piece. A pragmatic
approach to writing a successful specification takes that into account
and provides enough context in each puzzle piece so that piece makes
sense.

Lisa




From w3c-dist-auth-request@w3.org  Fri Feb 14 19:03:19 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10019
	for <webdav-archive@lists.ietf.org>; Fri, 14 Feb 2003 19:03:18 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1F05t607703;
	Fri, 14 Feb 2003 19:05:55 -0500 (EST)
Resent-Date: Fri, 14 Feb 2003 19:05:55 -0500 (EST)
Resent-Message-Id: <200302150005.h1F05t607703@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1F05sR07671
	for <w3c-dist-auth@frink.w3.org>; Fri, 14 Feb 2003 19:05:54 -0500 (EST)
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 TAA31388
	for <w3c-dist-auth@w3c.org>; Fri, 14 Feb 2003 19:05:54 -0500
Received: (qmail 11166 invoked by uid 0); 15 Feb 2003 00:05:22 -0000
Received: from p3EE24824.dip.t-dialin.net (HELO lisa) (62.226.72.36)
  by mail.gmx.net (mp015-rz3) with SMTP; 15 Feb 2003 00:05:22 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Lisa Dusseault" <lisa@xythos.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Sat, 15 Feb 2003 01:05:21 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCGELNGHAA.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.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <00c501c2d44e$09a8f300$b601a8c0@xythoslap>
Subject: RE: Review of ordering draft, version 05
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGELNGHAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7240
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Friday, February 14, 2003 6:25 PM
> To: 'Julian Reschke'; 'Webdav WG'
> Subject: RE: Review of ordering draft, version 05
>
> ...
>
> > I agree that the condition itself can be expressed in a more stringent
> > manner. However, I strongly disagree with the second sentence: all
> > pre/postconditions are MUSTs (by definition), and therefore the
statement is
> > (a) redundant and (b) - for consistency - it would have to be repeated
on
> > each an every condition.
>
> Yes, I agree that consistency helps make a spec readable.  What I'm
> proposing is to put a phrase such as "the server MUST..." on each and
> every condition. I will propose specific sentences if necessary, but I'm
> not sure I even understand each postcondition (which is itself clearly a
> problem).

I will look into rewriting the condition explanations. If there's a specific
one which you currently don't understand (after having clarified that all of
them are MUSTs), I would be interested to hear which.

> The reason I suggest this redundancy is because I talk to a lot of
> people who implement WebDAV yet who haven't read every word of every
> spec.  I remember my first job working on WebDAV in 1998 and I just
> browsed through the WebDAV and HTTP specs lightly. Then when a developer
> would ask me a specific question about something like how range headers
> worked, I'd look up that specific section. Usually, I could find the
> answer without having to integrate massive amounts of text from various
> sources, because in fact RFC2616 and RFC2518 are fairly well-written.
>
> Since this is the way specifications are used, a well-written
> specification *does* have a lot of redundancy. In writing essays,
> students are told to say what you're going to say, say it, and then say
> what you said. A specification is not a piece of code, to be executed by
> a computer which can load every line into memory and compile before
> executing. It's a puzzle that's too big to be seen at once, so instead
> each reader picks up a small piece of the puzzle at a time and tries to
> understand some of the picture just from that piece. A pragmatic
> approach to writing a successful specification takes that into account
> and provides enough context in each puzzle piece so that piece makes
> sense.

All true, but...

On the other hand, a spec must be precise. RFC2518 currently is very
verbose, but neglects to precisely define everything. For example: the
various PROPFIND types are mainly documented by example. A similiar problem
exists for the definition of error handling. So I really don't accept the
current version of RFC2518 as good example.

RFC3253 on the other hand is very precise, but definitively lacks examples
(the price for adding examples would have been a much much bigger spec,
which is a problem in itself).

The current ordering draft tries to adopt the more precise approach of
RFC3253. In particular, by inheriting from RFC3253 it gets

- (IMHO) a better error marshalling as RFC2518,
- precise definitions of what must happen upon executing a method
(pre/postconditions).

In addition, the draft tries to give more examples than RFC3253 does. In
this particular case, this can easily be afforded because the spec is so
much smaller.

So, the ordering spec tries to use the same approach as RFC3253, ACL and the
bindings spec. If there's something fundamentelly wrong with this approach,
it also applies to these other RFCs and drafts, and I'd like to see a more
general discussion about that.

Julian

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



From w3c-dist-auth-request@w3.org  Fri Feb 14 19:25:38 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10406
	for <webdav-archive@lists.ietf.org>; Fri, 14 Feb 2003 19:25:37 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1F0SP909043;
	Fri, 14 Feb 2003 19:28:25 -0500 (EST)
Resent-Date: Fri, 14 Feb 2003 19:28:25 -0500 (EST)
Resent-Message-Id: <200302150028.h1F0SP909043@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1F0SOR09010
	for <w3c-dist-auth@frink.w3.org>; Fri, 14 Feb 2003 19:28:24 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA01752
	for <w3c-dist-auth@w3c.org>; Fri, 14 Feb 2003 19:28:24 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18jqBr-00070w-00; Sat, 15 Feb 2003 00:28:23 +0000
Received: from [216.36.77.241] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18jqBr-00070l-00; Sat, 15 Feb 2003 00:28:23 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Fri, 14 Feb 2003 16:28:26 -0800
Message-ID: <002601c2d489$2816dbf0$f8cb90c6@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.4024
In-Reply-To: <JIEGINCHMLABHJBIGKBCGELNGHAA.julian.reschke@gmx.de>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Old-X-Envelope-To: julian.reschke@gmx.de,
 w3c-dist-auth@w3c.org
Subject: RE: Review of ordering draft, version 05
X-Archived-At: http://www.w3.org/mid/002601c2d489$2816dbf0$f8cb90c6@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7241
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 current ordering draft tries to adopt the more precise approach of
> RFC3253. In particular, by inheriting from RFC3253 it gets
> 
> - (IMHO) a better error marshalling as RFC2518,
> - precise definitions of what must happen upon executing a method
> (pre/postconditions).

Actually, I agree that RFC2518 has a better error marshalling mechanism
*and* that precise definitions of what must happen upon executing a
method are all good things. I think the concept of preconditions and
postconditions is a good concept and helps make a specification more
complete.

But, here's what I definitely don't want to *lose* in the process.
 - the ability of a specification reader to digest a piece of the
specification, and basically "get it"
 - the clarity of the standard MUST, MAY, SHOULD language
I think we're in agreement on this now and I look forward to seeing your
revised language-- I will review it all to see if it all makes sense to
me then.

A couple more subtle topics now...

 1. I'm a little worried that we're starting to lose the richness of
having error codes from 100 to 999 available by using only 403/409.  For
example, when ordered collections aren't supported in a given location,
why aren't we using 501?  If a segment listed in the ordering is not
found, why would the server return 409 with
(DAV:segment-must-identify-member) rather than a 404 Not Found response
code (either on its own or in a body)?

 2. Are we possibly making things confusing by introducing a
postcondition "code" like (DAV:ordering-type-set) for something that
MUST be done?  It makes it seem like the server might choose not to set
the ordering type, create the collection anyway, and respond with 409
containing <DAV:ordering-type-set/>.  Wouldn't a total failure to do
some required behavior normally be defined as a 500 response?

Thanks,
Lisa




From w3c-dist-auth-request@w3.org  Sat Feb 15 04:29:02 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29239
	for <webdav-archive@lists.ietf.org>; Sat, 15 Feb 2003 04:29:02 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1F9Vir02898;
	Sat, 15 Feb 2003 04:31:44 -0500 (EST)
Resent-Date: Sat, 15 Feb 2003 04:31:44 -0500 (EST)
Resent-Message-Id: <200302150931.h1F9Vir02898@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1F9VfR02819
	for <w3c-dist-auth@frink.w3.org>; Sat, 15 Feb 2003 04:31:41 -0500 (EST)
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 EAA12782
	for <w3c-dist-auth@w3.org>; Sat, 15 Feb 2003 04:31:41 -0500
Received: (qmail 24189 invoked by uid 0); 15 Feb 2003 09:31:09 -0000
Received: from p3EE24824.dip.t-dialin.net (HELO lisa) (62.226.72.36)
  by mail.gmx.net (mp013-rz3) with SMTP; 15 Feb 2003 09:31:09 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: <w3c-dist-auth@w3.org>
Date: Sat, 15 Feb 2003 10:31:07 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCOEMHGHAA.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.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <3E4DF847.4040101@linkuistics.com.au>
Subject: RE: I-D ACTION:draft-ietf-webdav-bind-01.txt
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEMHGHAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7242
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


Geoff,

I think Anthony is correct.

Could you either fix that in a new edit, or add it to the issues list?

Julian

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

> -----Original Message-----
> From: Antony Blakey [mailto:antony.blakey@linkuistics.com.au]
> Sent: Saturday, February 15, 2003 9:20 AM
> To: Julian Reschke
> Cc: w3c-dist-auth@w3.org
> Subject: Re: I-D ACTION:draft-ietf-webdav-bind-01.txt
> 
> 
> The example in para 2 of section 3.2 incorrectly states:
> 
> For example, if collection C1 is mapped to both /CollX and /CollY, and 
> C1 contains a binding named "x.gif" to a resource R1, then either 
> [/CollX, x.gif] or [/CollY, y.gif] can appear in the DAV:parent-set of 
> R1, but not both.
> 
> That should be:
> 
> ... then either [/CollX, x.gif] or [/CollY, x.gif] can appear ...
> 
> Julian Reschke wrote:
> > this draft differs from the latest edits made in October in 
> that two open
> > issues have been resolved (both were raised by myself and resolved in
> > agreement between Geoff and me). I therefore the working group 
> to issue the
> > "last call" for this spec.
> 
> -------------------------
> Antony Blakey
> mailto:antony.blakey@linkuistics.com.au
> Linkuistics - The Language of the Web
> 
> All that is required for evil to triumph is that good men do nothing.
> 



From w3c-dist-auth-request@w3.org  Sat Feb 15 04:38:42 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29301
	for <webdav-archive@lists.ietf.org>; Sat, 15 Feb 2003 04:38:42 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1F9fUI06521;
	Sat, 15 Feb 2003 04:41:30 -0500 (EST)
Resent-Date: Sat, 15 Feb 2003 04:41:30 -0500 (EST)
Resent-Message-Id: <200302150941.h1F9fUI06521@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1F9fTR06489
	for <w3c-dist-auth@frink.w3.org>; Sat, 15 Feb 2003 04:41:29 -0500 (EST)
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 EAA15243
	for <w3c-dist-auth@w3c.org>; Sat, 15 Feb 2003 04:41:28 -0500
Received: (qmail 30722 invoked by uid 0); 15 Feb 2003 09:40:57 -0000
Received: from p3EE24824.dip.t-dialin.net (HELO lisa) (62.226.72.36)
  by mail.gmx.net (mp019-rz3) with SMTP; 15 Feb 2003 09:40:57 -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: Sat, 15 Feb 2003 10:40:54 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCIEMIGHAA.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.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <002601c2d489$2816dbf0$f8cb90c6@xythoslap>
Subject: RE: Review of ordering draft, version 05
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEMIGHAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7243
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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: Saturday, February 15, 2003 1:28 AM
> To: 'Julian Reschke'; 'Webdav WG'
> Subject: RE: Review of ordering draft, version 05
>
>
>
>
> > The current ordering draft tries to adopt the more precise approach of
> > RFC3253. In particular, by inheriting from RFC3253 it gets
> >
> > - (IMHO) a better error marshalling as RFC2518,
> > - precise definitions of what must happen upon executing a method
> > (pre/postconditions).
>
> Actually, I agree that RFC2518 has a better error marshalling mechanism

I assume that's a typo :-)

> *and* that precise definitions of what must happen upon executing a
> method are all good things. I think the concept of preconditions and
> postconditions is a good concept and helps make a specification more
> complete.
>
> But, here's what I definitely don't want to *lose* in the process.
>  - the ability of a specification reader to digest a piece of the
> specification, and basically "get it"
>  - the clarity of the standard MUST, MAY, SHOULD language
> I think we're in agreement on this now and I look forward to seeing your
> revised language-- I will review it all to see if it all makes sense to
> me then.

OK.

> A couple more subtle topics now...
>
>  1. I'm a little worried that we're starting to lose the richness of
> having error codes from 100 to 999 available by using only 403/409.  For
> example, when ordered collections aren't supported in a given location,
> why aren't we using 501?  If a segment listed in the ordering is not

Because 501 means:

	"The server does not support the functionality required to fulfill the
request. This is the appropriate response when the server does not recognize
the request method and is not capable of supporting it for any resource."

In general I'm sympathic to allow DAV:error response bodies for *any* failed
request (I think I actually proposed this a while back on this list).

> found, why would the server return 409 with
> (DAV:segment-must-identify-member) rather than a 404 Not Found response
> code (either on its own or in a body)?

We can't simple return a 404 because the Request-URI identified a collection
which in fact *does* exist. The request failed because we tried to
manipulate the state of the collection in a way that failed because one of
the bindings we tried to position did not exist. We did *not* try to
manipulate the resource identified by that internal member name at all.

>  2. Are we possibly making things confusing by introducing a
> postcondition "code" like (DAV:ordering-type-set) for something that
> MUST be done?  It makes it seem like the server might choose not to set
> the ordering type, create the collection anyway, and respond with 409
> containing <DAV:ordering-type-set/>.  Wouldn't a total failure to do
> some required behavior normally be defined as a 500 response?

Yes, and I think that's something that should be possibly fixed in RFC3253.
Failure to meet a postcondition (after all preconditions were verified)
always is a server bug and thus would belong into the 5xx range. The main
question is: which spec should fix that? I'd really like to see RFC2518bis
to pick up (and clarify) this kind of error typing (maybe in a way that
makes it optional?).

Julian

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



From w3c-dist-auth-request@w3.org  Sat Feb 15 13:07:25 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05660
	for <webdav-archive@lists.ietf.org>; Sat, 15 Feb 2003 13:07:24 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1FI9Pb11066;
	Sat, 15 Feb 2003 13:09:25 -0500 (EST)
Resent-Date: Sat, 15 Feb 2003 13:09:25 -0500 (EST)
Resent-Message-Id: <200302151809.h1FI9Pb11066@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1FI9NR11030
	for <w3c-dist-auth@frink.w3.org>; Sat, 15 Feb 2003 13:09:23 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA01240
	for <w3c-dist-auth@w3c.org>; Sat, 15 Feb 2003 13:09:23 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18k6kY-00035N-00; Sat, 15 Feb 2003 18:09:18 +0000
Received: from [198.144.203.248] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18k6kX-00035C-00; Sat, 15 Feb 2003 18:09:18 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>,
        "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Sat, 15 Feb 2003 10:09:18 -0800
Message-ID: <004501c2d51d$5c38a820$f8cb90c6@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.4024
In-Reply-To: <JIEGINCHMLABHJBIGKBCIEMIGHAA.julian.reschke@gmx.de>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Old-X-Envelope-To: julian.reschke@gmx.de,
 w3c-dist-auth@w3c.org
Subject: RE: Review of ordering draft, version 05
X-Archived-At: http://www.w3.org/mid/004501c2d51d$5c38a820$f8cb90c6@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7244
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 agree that RFC2518 has a better error 
> marshalling mechanism
> 
> I assume that's a typo :-)

Yeah, oops, that was a typo :)


> Yes, and I think that's something that should be possibly 
> fixed in RFC3253.
> Failure to meet a postcondition (after all preconditions were 
> verified)
> always is a server bug and thus would belong into the 5xx 
> range. The main
> question is: which spec should fix that? I'd really like to 
> see RFC2518bis
> to pick up (and clarify) this kind of error typing (maybe in 
> a way that
> makes it optional?).

Seems reasonable to me, as long as it is optional. Other opinions?




From w3c-dist-auth-request@w3.org  Mon Feb 17 08:00:17 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21523
	for <webdav-archive@lists.ietf.org>; Mon, 17 Feb 2003 08:00:17 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1HD2aZ08984;
	Mon, 17 Feb 2003 08:02:36 -0500 (EST)
Resent-Date: Mon, 17 Feb 2003 08:02:36 -0500 (EST)
Resent-Message-Id: <200302171302.h1HD2aZ08984@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1HD2YR08951
	for <w3c-dist-auth@frink.w3.org>; Mon, 17 Feb 2003 08:02:34 -0500 (EST)
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 IAA16223
	for <w3c-dist-auth@w3c.org>; Mon, 17 Feb 2003 08:02:34 -0500
Received: (qmail 28423 invoked by uid 0); 17 Feb 2003 13:02:02 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp017-rz3) with SMTP; 17 Feb 2003 13:02:02 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Mon, 17 Feb 2003 14:02:02 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCEEPEGHAA.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.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <004501c2d51d$5c38a820$f8cb90c6@xythoslap>
Subject: RE: Review of ordering draft, version 05
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEPEGHAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7245
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 have tried to clarify the postconditon descriptions in the current
"latest" draft ([1]). Those who already reviewed it and found them to be
inprecise may want to review the changes.

Julian


[1]
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-latest
.html>

--
<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: Saturday, February 15, 2003 7:09 PM
> To: 'Julian Reschke'; Webdav WG
> Subject: RE: Review of ordering draft, version 05
>
>
>
> > > Actually, I agree that RFC2518 has a better error
> > marshalling mechanism
> >
> > I assume that's a typo :-)
>
> Yeah, oops, that was a typo :)
>
>
> > Yes, and I think that's something that should be possibly
> > fixed in RFC3253.
> > Failure to meet a postcondition (after all preconditions were
> > verified)
> > always is a server bug and thus would belong into the 5xx
> > range. The main
> > question is: which spec should fix that? I'd really like to
> > see RFC2518bis
> > to pick up (and clarify) this kind of error typing (maybe in
> > a way that
> > makes it optional?).
>
> Seems reasonable to me, as long as it is optional. Other opinions?
>
>



From w3c-dist-auth-request@w3.org  Tue Feb 18 20:44:19 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14549
	for <webdav-archive@lists.ietf.org>; Tue, 18 Feb 2003 20:44:17 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1J1kpA08459;
	Tue, 18 Feb 2003 20:46:51 -0500 (EST)
Resent-Date: Tue, 18 Feb 2003 20:46:51 -0500 (EST)
Resent-Message-Id: <200302190146.h1J1kpA08459@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1J1koR08427
	for <w3c-dist-auth@frink.w3.org>; Tue, 18 Feb 2003 20:46:50 -0500 (EST)
Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA02222
	for <w3c-dist-auth@w3.org>; Tue, 18 Feb 2003 20:46:49 -0500
Received: from Tycho (dhcp-60-126.cse.ucsc.edu [128.114.60.126])
	by ucsc.edu (8.10.1/8.10.1) with SMTP id h1J1kPY09396
	for <w3c-dist-auth@w3.org>; Tue, 18 Feb 2003 17:46:25 -0800 (PST)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "WebDAV" <w3c-dist-auth@w3.org>
Date: Tue, 18 Feb 2003 17:43:43 -0800
Message-ID: <AMEPKEBLDJJCCDEJHAMIMEBDGHAA.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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-UCSC-CATS-MailScanner: Found to be clean
Subject: Re: I-D ACTION:draft-ietf-webdav-bind-01.txt
X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIMEBDGHAA.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7246
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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: Antony Blakey [mailto:antony.blakey@linkuistics.com.au]
Sent: Saturday, February 15, 2003 12:20 AM
To: Julian Reschke
Cc: w3c-dist-auth@w3.org
Subject: [Moderator Action] Re: I-D ACTION:draft-ietf-webdav-bind-01.txt




The example in para 2 of section 3.2 incorrectly states:

For example, if collection C1 is mapped to both /CollX and /CollY, and
C1 contains a binding named "x.gif" to a resource R1, then either
[/CollX, x.gif] or [/CollY, y.gif] can appear in the DAV:parent-set of
R1, but not both.

That should be:

... then either [/CollX, x.gif] or [/CollY, x.gif] can appear ...

Julian Reschke wrote:
> this draft differs from the latest edits made in October in that two open
> issues have been resolved (both were raised by myself and resolved in
> agreement between Geoff and me). I therefore the working group to issue
the
> "last call" for this spec.

-------------------------
Antony Blakey
mailto:antony.blakey@linkuistics.com.au
Linkuistics - The Language of the Web

All that is required for evil to triumph is that good men do nothing.



From w3c-dist-auth-request@w3.org  Wed Feb 19 16:48:27 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09882
	for <webdav-archive@lists.ietf.org>; Wed, 19 Feb 2003 16:48:26 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1JLmk124243;
	Wed, 19 Feb 2003 16:48:46 -0500 (EST)
Resent-Date: Wed, 19 Feb 2003 16:48:46 -0500 (EST)
Resent-Message-Id: <200302192148.h1JLmk124243@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1JLmjR24211
	for <w3c-dist-auth@frink.w3.org>; Wed, 19 Feb 2003 16:48:45 -0500 (EST)
Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA19476
	for <w3c-dist-auth@w3.org>; Wed, 19 Feb 2003 16:48:44 -0500
Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196])
	by ucsc.edu (8.10.1/8.10.1) with SMTP id h1JLiYs11690
	for <w3c-dist-auth@w3.org>; Wed, 19 Feb 2003 13:44:35 -0800 (PST)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "WebDAV" <w3c-dist-auth@w3.org>
Date: Wed, 19 Feb 2003 13:41:52 -0800
Message-ID: <AMEPKEBLDJJCCDEJHAMIAEDBGHAA.ejw@cse.ucsc.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0095_01C2D81C.A9002C80"
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: FW: Using WebDAV with IIS5.0
X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIAEDBGHAA.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7247
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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_0095_01C2D81C.A9002C80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Accidentally caught by the spam filter.

- Jim
-----Original Message-----
From: Atul Kandhari [mailto:atulk@newgen.co.in]
Sent: Wednesday, February 19, 2003 3:44 AM
To: w3c-dist-auth@w3.org
Subject: [Moderator Action] Using WebDAV with IIS5.0


Hi Greg,

I am using a CGI as the server for WebDAV. I want to know how should I
configure the virtual directory of my webdav folder so that when the WebDAV
folder is accessed through IE/MS-Office then the CGI gets invoked.
I've tried redirection to URL of the CGI, but that does not work.
Please advise

Regards

------=_NextPart_000_0095_01C2D81C.A9002C80
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=3D229354121-19022003>Accidentally caught by the spam=20
filter.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D229354121-19022003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229354121-19022003>-=20
Jim</SPAN></FONT></DIV>
<DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> Atul Kandhari=20
[mailto:atulk@newgen.co.in]<BR><B>Sent:</B> Wednesday, February 19, 2003 =
3:44=20
AM<BR><B>To:</B> w3c-dist-auth@w3.org<BR><B>Subject:</B> [Moderator =
Action]=20
Using WebDAV with IIS5.0<BR><BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>Hi Greg,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I am using a CGI as the server for =
WebDAV. I want=20
to know how should I configure the virtual directory of my webdav folder =
so that=20
when the WebDAV folder is accessed through IE/MS-Office then the CGI =
gets=20
invoked.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I've tried redirection to URL of the =
CGI, but that=20
does not work.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Please advise</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial =
size=3D2>Regards</FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_0095_01C2D81C.A9002C80--



From w3c-dist-auth-request@w3.org  Wed Feb 19 18:46:33 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13004
	for <webdav-archive@lists.ietf.org>; Wed, 19 Feb 2003 18:46:33 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1JNQuB10158;
	Wed, 19 Feb 2003 18:26:56 -0500 (EST)
Resent-Date: Wed, 19 Feb 2003 18:26:56 -0500 (EST)
Resent-Message-Id: <200302192326.h1JNQuB10158@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1JNQsR10104
	for <w3c-dist-auth@frink.w3.org>; Wed, 19 Feb 2003 18:26:54 -0500 (EST)
Received: from mac.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 SAA12029
	for <w3c-dist-auth@w3c.org>; Wed, 19 Feb 2003 18:26:54 -0500
Received: from apache.org (localhost [127.0.0.1])
	by mac.wakasoft.com (8.12.6/8.12.2) with ESMTP id h1JMq9kx000795
	for <w3c-dist-auth@w3c.org>; Wed, 19 Feb 2003 14:52:09 -0800 (PST)
Date: Wed, 19 Feb 2003 14:52:08 -0800
Mime-Version: 1.0 (Apple Message framework v551)
Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed
From: "Roy T. Fielding" <fielding@apache.org>
To: w3c-dist-auth@w3c.org
Content-Transfer-Encoding: 7bit
Message-Id: <C67A9E1A-445C-11D7-AFC1-000393753936@apache.org>
X-Mailer: Apple Mail (2.551)
Subject: Microsoft patent on Translate header field
X-Archived-At: http://www.w3.org/mid/C67A9E1A-445C-11D7-AFC1-000393753936@apache.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7248
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


US Patent 6,449,633.  Whatever.

http://patft.uspto.gov/netacgi/nph- 
Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/ 
srchnum.htm&r=1&f=G&l=50&s1=6,449,633.WKU.&OS=PN/6,449,633&RS=PN/ 
6,449,633

....Roy



From w3c-dist-auth-request@w3.org  Wed Feb 19 18:46:45 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13020
	for <webdav-archive@lists.ietf.org>; Wed, 19 Feb 2003 18:46:45 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1JNR4h10271;
	Wed, 19 Feb 2003 18:27:04 -0500 (EST)
Resent-Date: Wed, 19 Feb 2003 18:27:04 -0500 (EST)
Resent-Message-Id: <200302192327.h1JNR4h10271@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1JNQtR10130
	for <w3c-dist-auth@frink.w3.org>; Wed, 19 Feb 2003 18:26:55 -0500 (EST)
Received: from mac.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 SAA12033
	for <w3c-dist-auth@w3.org>; Wed, 19 Feb 2003 18:26:55 -0500
Received: from apache.org (localhost [127.0.0.1])
	by mac.wakasoft.com (8.12.6/8.12.2) with ESMTP id h1JNKfkx000797
	for <w3c-dist-auth@w3.org>; Wed, 19 Feb 2003 15:20:41 -0800 (PST)
Date: Wed, 19 Feb 2003 15:20:40 -0800
Mime-Version: 1.0 (Apple Message framework v551)
Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed
From: "Roy T. Fielding" <fielding@apache.org>
To: w3c-dist-auth@w3.org
Content-Transfer-Encoding: 7bit
Message-Id: <C2ED5E54-4460-11D7-AFC1-000393753936@apache.org>
X-Mailer: Apple Mail (2.551)
Subject: Microsoft patent on typing Webdav properties
X-Archived-At: http://www.w3.org/mid/C2ED5E54-4460-11D7-AFC1-000393753936@apache.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7249
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


Will someone please go over and slap Alex Hopmann for placing his
name on something as stupid as US patent 6,356,907

http://patft.uspto.gov/netacgi/nph- 
Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search- 
adv.htm&r=1&f=G&l=50&d=PALL&S1=6,356,907.WKU.&OS=pn/6,356,907&RS=PN/ 
6,356,907

....Roy



From w3c-dist-auth-request@w3.org  Wed Feb 19 19:06:36 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13468
	for <webdav-archive@lists.ietf.org>; Wed, 19 Feb 2003 19:06:35 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1JNkmQ12913;
	Wed, 19 Feb 2003 18:46:48 -0500 (EST)
Resent-Date: Wed, 19 Feb 2003 18:46:48 -0500 (EST)
Resent-Message-Id: <200302192346.h1JNkmQ12913@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1JNklR12881
	for <w3c-dist-auth@frink.w3.org>; Wed, 19 Feb 2003 18:46:47 -0500 (EST)
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 SAA16402
	for <w3c-dist-auth@w3.org>; Wed, 19 Feb 2003 18:46:46 -0500
Received: (qmail 18860 invoked by uid 0); 19 Feb 2003 23:46:45 -0000
Received: from p3EE24719.dip.t-dialin.net (HELO lisa) (62.226.71.25)
  by mail.gmx.net (mp018-rz3) with SMTP; 19 Feb 2003 23:46:45 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Roy T. Fielding" <fielding@apache.org>, <w3c-dist-auth@w3.org>
Date: Thu, 20 Feb 2003 00:46:44 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCIEGMGIAA.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.6604 (9.0.2911.0)
Importance: Normal
In-reply-to: <C2ED5E54-4460-11D7-AFC1-000393753936@apache.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: RE: Microsoft patent on typing Webdav properties
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEGMGIAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7250
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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,

looking for "webdav" I discovered some more, such as:

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=/netahtm
l/search-adv.htm&r=2&f=G&l=50&d=PTXT&p=1&p=1&S1=webdav&OS=webdav&RS=webdav:

"A method is described of converting a file system path corresponding to a
resource to a uniform resource locator (URL) corresponding to the resource.
After receiving the file system path, the following information is obtained
related to the resource located in the inputted file system path: the
protocol prefix, domain name, the port number if different than default, and
the URL fixed subdirectory structure if any. This information may be
obtained, for example, by reference to a URL provided to a conversion
module. The URL is then manufactured by first assigning the protocol prefix
as the left-most characters of the URL. Then, the domain name, a colon ":"
and port number if different than default, any subdirectory structure, and a
latter portion of the file system path are added to the protocol prefix.
Finally, any back slashes ".backslash." are converted to forward slashes "/"
to complete the conversion to the URL."

I guess any Web server running on a Windows system violates this one.

The search also turns up patent claims about ACLs, DASL (SQL) and storing
properties in property files. Needless to say, all filed by Microsoft in
1999.

Is this the reason why Microsoft went away from standards work back then?

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 Roy T. Fielding
> Sent: Thursday, February 20, 2003 12:21 AM
> To: w3c-dist-auth@w3.org
> Subject: Microsoft patent on typing Webdav properties
>
>
>
> Will someone please go over and slap Alex Hopmann for placing his
> name on something as stupid as US patent 6,356,907
>
> http://patft.uspto.gov/netacgi/nph-
> Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-
> adv.htm&r=1&f=G&l=50&d=PALL&S1=6,356,907.WKU.&OS=pn/6,356,907&RS=PN/
> 6,356,907
>
> ....Roy
>



From w3c-dist-auth-request@w3.org  Wed Feb 19 19:34:10 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13989
	for <webdav-archive@lists.ietf.org>; Wed, 19 Feb 2003 19:34:10 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1K0afX25250;
	Wed, 19 Feb 2003 19:36:41 -0500 (EST)
Resent-Date: Wed, 19 Feb 2003 19:36:41 -0500 (EST)
Resent-Message-Id: <200302200036.h1K0afX25250@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1K0aeR25177
	for <w3c-dist-auth@frink.w3.org>; Wed, 19 Feb 2003 19:36:40 -0500 (EST)
Received: from catbox.hotcat.org (adsl-67-115-128-170.dsl.snfc21.pacbell.net [67.115.128.170])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA27684
	for <w3c-dist-auth@w3.org>; Wed, 19 Feb 2003 19:36:38 -0500
Received: from nasa.gov (moonstone.aen.nasa.gov [198.123.13.108])
	by catbox.hotcat.org (8.12.1/8.11.6) with ESMTP id h1K0aPZH006008;
	Wed, 19 Feb 2003 16:36:34 -0800
Message-ID: <3E542044.6080902@nasa.gov>
Date: Wed, 19 Feb 2003 16:24:36 -0800
From: Chris Knight <Christopher.D.Knight@nasa.gov>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Roy T. Fielding" <fielding@apache.org>
CC: w3c-dist-auth@w3.org
References: <C2ED5E54-4460-11D7-AFC1-000393753936@apache.org>
In-Reply-To: <C2ED5E54-4460-11D7-AFC1-000393753936@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Microsoft patent on typing Webdav properties
X-Archived-At: http://www.w3.org/mid/3E542044.6080902@nasa.gov
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7251
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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:

> Will someone please go over and slap Alex Hopmann for placing his
> name on something as stupid as US patent 6,356,907
>
> http://patft.uspto.gov/netacgi/nph- 
> Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search- 
> adv.htm&r=1&f=G&l=50&d=PALL&S1=6,356,907.WKU.&OS=pn/6,356,907&RS=PN/ 
> 6,356,907

I assume there is prior art to these? It's a shame that it got through 
the patent review process. (Not a suprise, however.)



From w3c-dist-auth-request@w3.org  Wed Feb 19 20:43:15 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15224
	for <webdav-archive@lists.ietf.org>; Wed, 19 Feb 2003 20:43:15 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1K1k5x11583;
	Wed, 19 Feb 2003 20:46:05 -0500 (EST)
Resent-Date: Wed, 19 Feb 2003 20:46:05 -0500 (EST)
Resent-Message-Id: <200302200146.h1K1k5x11583@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1K1k2R11545
	for <w3c-dist-auth@frink.w3.org>; Wed, 19 Feb 2003 20:46:02 -0500 (EST)
Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA10933
	for <w3c-dist-auth@w3c.org>; Wed, 19 Feb 2003 20:46:01 -0500
Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196])
	by ucsc.edu (8.10.1/8.10.1) with SMTP id h1K1ass13346
	for <w3c-dist-auth@w3c.org>; Wed, 19 Feb 2003 17:36:55 -0800 (PST)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: <w3c-dist-auth@w3c.org>
Date: Wed, 19 Feb 2003 17:34:12 -0800
Message-ID: <AMEPKEBLDJJCCDEJHAMIOEDHGHAA.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)
In-Reply-To: <C67A9E1A-445C-11D7-AFC1-000393753936@apache.org>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
X-UCSC-CATS-MailScanner: Found to be clean
Subject: RE: Microsoft patent on Translate header field
X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIOEDHGHAA.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7252
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 pretty much settles the argument over the use of Translate. :-)

- Jim

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding
> Sent: Wednesday, February 19, 2003 2:52 PM
> To: w3c-dist-auth@w3c.org
> Subject: Microsoft patent on Translate header field
> 
> 
> 
> US Patent 6,449,633.  Whatever.
> 
> http://patft.uspto.gov/netacgi/nph- 
> Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/ 
> srchnum.htm&r=1&f=G&l=50&s1=6,449,633.WKU.&OS=PN/6,449,633&RS=PN/ 
> 6,449,633
> 
> ....Roy



From w3c-dist-auth-request@w3.org  Wed Feb 19 21:01:12 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15512
	for <webdav-archive@lists.ietf.org>; Wed, 19 Feb 2003 21:01:11 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1K245I16031;
	Wed, 19 Feb 2003 21:04:05 -0500 (EST)
Resent-Date: Wed, 19 Feb 2003 21:04:05 -0500 (EST)
Resent-Message-Id: <200302200204.h1K245I16031@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1K243R15979
	for <w3c-dist-auth@frink.w3.org>; Wed, 19 Feb 2003 21:04:03 -0500 (EST)
Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA15266
	for <w3c-dist-auth@w3.org>; Wed, 19 Feb 2003 21:04:03 -0500
Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196])
	by ucsc.edu (8.10.1/8.10.1) with SMTP id h1K23hs19622;
	Wed, 19 Feb 2003 18:03:43 -0800 (PST)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "Chris Knight" <Christopher.D.Knight@nasa.gov>
Cc: <w3c-dist-auth@w3.org>
Date: Wed, 19 Feb 2003 18:01:00 -0800
Message-ID: <AMEPKEBLDJJCCDEJHAMIEEDKGHAA.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)
In-Reply-To: <3E542044.6080902@nasa.gov>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
X-UCSC-CATS-MailScanner: Found to be clean
Subject: RE: Microsoft patent on typing Webdav properties
X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIEEDKGHAA.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7253
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


Chris Knight writes:
> I assume there is prior art to these? It's a shame that it got through
> the patent review process. (Not a suprise, however.)

IANAL.

Many of the claims in the Microsoft patents are very specific to HTTP,
specific methods, and use of XML. There is clear prior art for ACL (easy to
find drafts in Google that predate the application). DASL is a bit tricky --
the first draft did go our before the application, but only by a week.
Still, we can point to email messages that clearly indicate that people on
the patent application were working on the DASL specification. I'm also not
sure whether revealing the idea of SQL wrapped in XML over HTTP at the
public, open DASL working meetings also constitutes disclosure of the
invention.

- Jim



From w3c-dist-auth-request@w3.org  Thu Feb 20 03:05:05 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03582
	for <webdav-archive@lists.ietf.org>; Thu, 20 Feb 2003 03:05:05 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1K87j527651;
	Thu, 20 Feb 2003 03:07:45 -0500 (EST)
Resent-Date: Thu, 20 Feb 2003 03:07:45 -0500 (EST)
Resent-Message-Id: <200302200807.h1K87j527651@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1K87hR27615
	for <w3c-dist-auth@frink.w3.org>; Thu, 20 Feb 2003 03:07:43 -0500 (EST)
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 DAA19846
	for <w3c-dist-auth@w3.org>; Thu, 20 Feb 2003 03:07:43 -0500
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 h1K878H22647
	for <w3c-dist-auth@w3.org>; Thu, 20 Feb 2003 00:07:08 -0800 (PST)
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 h1K877v22637
	for <w3c-dist-auth@w3.org>; Thu, 20 Feb 2003 00:07:07 -0800 (PST)
Received: from rgmgw6.us.oracle.com (localhost [127.0.0.1])
	by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id h1K876f09169
	for <w3c-dist-auth@w3.org>; Thu, 20 Feb 2003 01:07:06 -0700 (MST)
Received: from rgmum3.us.oracle.com (rgmum3.us.oracle.com [138.1.191.24])
	by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id h1K875l09140
	for <w3c-dist-auth@w3.org>; Thu, 20 Feb 2003 01:07:05 -0700 (MST)
Received: from 152.68.17.155 by rgmum5.us.oracle.com
	with ESMTP id 19692151045728188; Thu, 20 Feb 2003 01:03:08 -0600
Message-ID: <08c501c2d8b6$70dfae30$9b114498@esedlar>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: "Chris Knight" <Christopher.D.Knight@nasa.gov>,
        "Roy T. Fielding" <fielding@apache.org>
Cc: <w3c-dist-auth@w3.org>
References: <C2ED5E54-4460-11D7-AFC1-000393753936@apache.org> <3E542044.6080902@nasa.gov>
Date: Thu, 20 Feb 2003 00:02:40 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: Re: Microsoft patent on typing Webdav properties
X-Archived-At: http://www.w3.org/mid/08c501c2d8b6$70dfae30$9b114498@esedlar
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7254
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 reason companies like Microsoft patent this kind of crap is as a
defensive measure--I don't think Microsoft typically uses these patents
offensively.  This is the same with IBM and Oracle as well.  Lots of random
crap gets patented, so if IBM (who started the patents war and has more
software patents on stupid stuff than any other company) were to come after
Microsoft, for example, Microsoft would come back with probably 20,000
patents that IBM has infringed and drown the problem in litigation (and vice
versa).

The value of that Microsoft patent is that demonstrating prior art on that
one patent would probably be half a million in litigation costs to
invalidate it.

These obvious patents are like nukes--the big players are afraid of the
consequences of launching them, and they don't use them.  The only people
who use this stuff are the little players who have not much in the way of
actual software product revenue, with no target for the big players to
retaliate against--kind of like terrorists with nukes.  That's why all of
the trouble is caused by random little startups with no products suing
everyone for patents on the likes of downloading music over the Internet.

I'd bet that you could get Microsoft to make the patent available at no cost
to implementors of WebDAV if the issue were raised.  If we actually wanted
to use the Translate header, for example, it would clearly be in MSFT's
interest to make the patent available freely.

--Eric

----- Original Message -----
From: "Chris Knight" <Christopher.D.Knight@nasa.gov>
To: "Roy T. Fielding" <fielding@apache.org>
Cc: <w3c-dist-auth@w3.org>
Sent: Wednesday, February 19, 2003 4:24 PM
Subject: Re: Microsoft patent on typing Webdav properties


>
> Roy T. Fielding wrote:
>
> > Will someone please go over and slap Alex Hopmann for placing his
> > name on something as stupid as US patent 6,356,907
> >
> > http://patft.uspto.gov/netacgi/nph-
> > Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-
> > adv.htm&r=1&f=G&l=50&d=PALL&S1=6,356,907.WKU.&OS=pn/6,356,907&RS=PN/
> > 6,356,907
>
> I assume there is prior art to these? It's a shame that it got through
> the patent review process. (Not a suprise, however.)
>
>



From w3c-dist-auth-request@w3.org  Thu Feb 20 03:26:54 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04150
	for <webdav-archive@lists.ietf.org>; Thu, 20 Feb 2003 03:26:53 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1K8To808039;
	Thu, 20 Feb 2003 03:29:50 -0500 (EST)
Resent-Date: Thu, 20 Feb 2003 03:29:50 -0500 (EST)
Resent-Message-Id: <200302200829.h1K8To808039@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1K8TlR08007
	for <w3c-dist-auth@frink.w3.org>; Thu, 20 Feb 2003 03:29:47 -0500 (EST)
Received: from mail12.atl.registeredsite.com (nobody@mail12.atl.registeredsite.com [64.224.219.86])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA27333
	for <w3c-dist-auth@w3.org>; Thu, 20 Feb 2003 03:29:47 -0500
Received: from infonuovo.com (infonuovo.com [216.122.10.142] (may be forged))
	by mail12.atl.registeredsite.com (8.12.2/8.12.6) with ESMTP id h1K8TiGK012308;
	Thu, 20 Feb 2003 03:29:44 -0500
Received: from centro (sttldslgw16poolA37.sttl.uswest.net [63.231.36.37])
	by infonuovo.com (8.8.7/8.8.5) with SMTP id AAA26527;
	Thu, 20 Feb 2003 00:29:42 -0800 (PST)
Reply-To: <dennis.hamilton@acm.org>
From: "Dennis E. Hamilton" <dennis.hamilton@acm.org>
To: "Jim Whitehead" <ejw@cse.ucsc.edu>,
        "Chris Knight" <Christopher.D.Knight@nasa.gov>
Cc: <w3c-dist-auth@w3.org>
Date: Thu, 20 Feb 2003 00:29:40 -0800
Message-ID: <CKEIJMODOBLAHAEKLLIKCEEEJDAA.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.2800.1106
Importance: Normal
In-Reply-To: <AMEPKEBLDJJCCDEJHAMIEEDKGHAA.ejw@cse.ucsc.edu>
Subject: RE: Microsoft patent on typing Webdav properties
X-Archived-At: http://www.w3.org/mid/CKEIJMODOBLAHAEKLLIKCEEEJDAA.dennis.hamilton@acm.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7255
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


There used to be a grace period of 1 year after public disclosure for
filing.

Don't know if it is still true, though I don't think the patent procedures
have been changed in that area unless it is part of international
normalization.

The big deal is going to be with regard to the IETF rules.  I don't know
when they were updated to require mandatory licensing of anything disclosed
or proposed for an IETF standard.

-- Dennis

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead
Sent: Wednesday, February 19, 2003 18:01
To: Chris Knight
Cc: w3c-dist-auth@w3.org
Subject: RE: Microsoft patent on typing Webdav properties



Chris Knight writes:
> I assume there is prior art to these? It's a shame that it got through
> the patent review process. (Not a suprise, however.)

IANAL.

Many of the claims in the Microsoft patents are very specific to HTTP,
specific methods, and use of XML. There is clear prior art for ACL (easy to
find drafts in Google that predate the application). DASL is a bit tricky --
the first draft did go our before the application, but only by a week.
Still, we can point to email messages that clearly indicate that people on
the patent application were working on the DASL specification. I'm also not
sure whether revealing the idea of SQL wrapped in XML over HTTP at the
public, open DASL working meetings also constitutes disclosure of the
invention.

- Jim





From w3c-dist-auth-request@w3.org  Thu Feb 20 04:57:43 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05861
	for <webdav-archive@lists.ietf.org>; Thu, 20 Feb 2003 04:57:42 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1KA0CM01458;
	Thu, 20 Feb 2003 05:00:12 -0500 (EST)
Resent-Date: Thu, 20 Feb 2003 05:00:12 -0500 (EST)
Resent-Message-Id: <200302201000.h1KA0CM01458@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1KA0BR01426
	for <w3c-dist-auth@frink.w3.org>; Thu, 20 Feb 2003 05:00:11 -0500 (EST)
Received: from stexchange1.simplytrading.ltd.uk ([217.150.101.83])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA14645
	for <w3c-dist-auth@w3c.org>; Thu, 20 Feb 2003 05:00:06 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 20 Feb 2003 09:48:14 -0000
Message-ID: <80580AC1CF583E4E87794E275D178991543B43@stexchange1.simplytrading.ltd.uk>
Thread-Topic: Microsoft patent on Translate header field
Thread-Index: AcLYgPjllgnvByCBTRysBJ9oUgkMOAAQ/pdA
From: "John Best" <john.best@simplytrading.com>
To: "Jim Whitehead" <ejw@cse.ucsc.edu>, <w3c-dist-auth@w3c.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h1KA0BR01426
Subject: RE: Microsoft patent on Translate header field
X-Archived-At: http://www.w3.org/mid/80580AC1CF583E4E87794E275D178991543B43@stexchange1.simplytrading.ltd.uk
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7256
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


They have a patent on including a specific header?

Blimey, I thought patents where for inventions, not a petty change to something.

John B.

---



Well, that pretty much settles the argument over the use of Translate. :-)

- Jim

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding
> Sent: Wednesday, February 19, 2003 2:52 PM
> To: w3c-dist-auth@w3c.org
> Subject: Microsoft patent on Translate header field
> 
> 
> 
> US Patent 6,449,633.  Whatever.
> 
> http://patft.uspto.gov/netacgi/nph- 
> Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/ 
> srchnum.htm&r=1&f=G&l=50&s1=6,449,633.WKU.&OS=PN/6,449,633&RS=PN/ 
> 6,449,633
> 
> ....Roy


--------------------------------------------------------

The contents of this e-mail are confidential to the ordinary user of the e-mail address to which it was addressed, or in the case of an incorrectly addressed e-mail message, the intended recipient. No-one else may copy, use, disseminate or forward all or any part of it in any form.

Although this email, including any attachments, is believed to be free of any virus, or other defect which might affect any computer or IT system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free, and no responsibility is accepted for any loss or damage arising in any way from its use.

The views expressed in this e-mail are those of the sender and not necessarily the employees company. 

If you receive this e-mail in error please accept our apology.  If this is the case we would be obliged if you would contact the sender and then delete the e-mail.

--------------------------------------------------------



From w3c-dist-auth-request@w3.org  Thu Feb 20 07:39:39 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09609
	for <webdav-archive@lists.ietf.org>; Thu, 20 Feb 2003 07:39:38 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1KCgJm06862;
	Thu, 20 Feb 2003 07:42:19 -0500 (EST)
Resent-Date: Thu, 20 Feb 2003 07:42:19 -0500 (EST)
Resent-Message-Id: <200302201242.h1KCgJm06862@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1KCgHR06829
	for <w3c-dist-auth@frink.w3.org>; Thu, 20 Feb 2003 07:42:17 -0500 (EST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA15616
	for <w3c-dist-auth@w3.org>; Thu, 20 Feb 2003 07:42:13 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09499;
	Thu, 20 Feb 2003 07:38:22 -0500 (EST)
Message-Id: <200302201238.HAA09499@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: Thu, 20 Feb 2003 07:38:22 -0500
Subject: I-D ACTION:draft-ietf-webdav-ordering-protocol-06.txt
X-Archived-At: http://www.w3.org/mid/200302201238.HAA09499@ietf.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7257
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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		: WebDAV Ordered Collections Protocol
	Author(s)	: J. Slein, E. Whitehead
	Filename	: draft-ietf-webdav-ordering-protocol-06.txt
	Pages		: 43
	Date		: 2003-2-19
	
This specification extends the WebDAV Distributed Authoring Protocol
to support server-side ordering of collection members. Of particular
interest are orderings that are not based on property values, and so
cannot be achieved using a search protocol's ordering option and
cannot be maintained automatically by the server. Protocol elements
are defined to let clients specify the position in the ordering of
each collection member, as well as the semantics governing the
ordering.
Distribution of this document is unlimited. Please send comments to
the Distributed Authoring and Versioning (WebDAV) working group at
w3c-dist-auth@w3.org, which may be joined by sending a message with
subject 'subscribe' to w3c-dist-auth-request@w3.org.
Discussions of the WEBDAV working group are archived at URL:
http://lists.w3.org/Archives/Public/w3c-dist-auth/.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-protocol-06.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-ordering-protocol-06.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-ordering-protocol-06.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:	<2003-2-19142333.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-webdav-ordering-protocol-06.txt

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

Content-Type: text/plain
Content-ID:	<2003-2-19142333.I-D@ietf.org>

--OtherAccess--

--NextPart--




From w3c-dist-auth-request@w3.org  Thu Feb 20 12:36:31 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22432
	for <webdav-archive@lists.ietf.org>; Thu, 20 Feb 2003 12:36:31 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1KHdEm21549;
	Thu, 20 Feb 2003 12:39:14 -0500 (EST)
Resent-Date: Thu, 20 Feb 2003 12:39:14 -0500 (EST)
Resent-Message-Id: <200302201739.h1KHdEm21549@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1KHdCR21513
	for <w3c-dist-auth@frink.w3.org>; Thu, 20 Feb 2003 12:39:12 -0500 (EST)
Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA12443
	for <w3c-dist-auth@w3.org>; Thu, 20 Feb 2003 12:39:12 -0500
Received: from Tycho (dhcp-60-152.cse.ucsc.edu [128.114.60.152])
	by ucsc.edu (8.10.1/8.10.1) with SMTP id h1KHcas00680
	for <w3c-dist-auth@w3.org>; Thu, 20 Feb 2003 09:38:36 -0800 (PST)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: <w3c-dist-auth@w3.org>
Date: Thu, 20 Feb 2003 09:35:53 -0800
Message-ID: <AMEPKEBLDJJCCDEJHAMICEFBGHAA.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: <CKEIJMODOBLAHAEKLLIKCEEEJDAA.dennis.hamilton@acm.org>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
X-UCSC-CATS-MailScanner: Found to be clean
Subject: RE: Microsoft patent on typing Webdav properties
X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMICEFBGHAA.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7258
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


> There used to be a grace period of 1 year after public disclosure for
> filing.

In this case, I still think we can demonstrate public disclosure. The
minutes from the August 25, 1998 DASL BOF at the Chicago IETF clearly show a
protocol that wraps SQL in XML and uses the SEARCH verb.

http://www.ietf.org/proceedings/98aug/98aug-36.htm#TopOfPage
(see the slides)

As well, there are minutes from the previous LA IETF that also show this
protocol, and these are from a year before filing.

Additionally, it seems like the VESA case applies here, since DASL was led,
and pushed by Microsoft at the time, and the IETF had/has clear IP
disclosure rules.

Again, IANAL.

- Jim




From w3c-dist-auth-request@w3.org  Thu Feb 20 22:21:31 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07684
	for <webdav-archive@lists.ietf.org>; Thu, 20 Feb 2003 22:21:31 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1L3Npa09399;
	Thu, 20 Feb 2003 22:23:51 -0500 (EST)
Resent-Date: Thu, 20 Feb 2003 22:23:51 -0500 (EST)
Resent-Message-Id: <200302210323.h1L3Npa09399@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1L3NmR09291
	for <w3c-dist-auth@frink.w3.org>; Thu, 20 Feb 2003 22:23:48 -0500 (EST)
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 WAA09344
	for <w3c-dist-auth@w3.org>; Thu, 20 Feb 2003 22:23:48 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 20 Feb 2003 22:07:37 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <FKKQCXXM>; Thu, 20 Feb 2003 22:23:13 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE201FC35C9@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Thu, 20 Feb 2003 22:23:12 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: I-D ACTION:draft-ietf-webdav-bind-01.txt
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE201FC35C9@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7259
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 can fix that in the final editing pass, if that is the only
problem with the 01 draft.

Cheers,
Geoff 

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Saturday, February 15, 2003 4:31 AM
To: w3c-dist-auth@w3.org
Subject: RE: I-D ACTION:draft-ietf-webdav-bind-01.txt



Geoff,

I think Anthony is correct.

Could you either fix that in a new edit, or add it to the issues list?

Julian

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

> -----Original Message-----
> From: Antony Blakey [mailto:antony.blakey@linkuistics.com.au]
> Sent: Saturday, February 15, 2003 9:20 AM
> To: Julian Reschke
> Cc: w3c-dist-auth@w3.org
> Subject: Re: I-D ACTION:draft-ietf-webdav-bind-01.txt
> 
> 
> The example in para 2 of section 3.2 incorrectly states:
> 
> For example, if collection C1 is mapped to both /CollX and /CollY, and 
> C1 contains a binding named "x.gif" to a resource R1, then either 
> [/CollX, x.gif] or [/CollY, y.gif] can appear in the DAV:parent-set of 
> R1, but not both.
> 
> That should be:
> 
> ... then either [/CollX, x.gif] or [/CollY, x.gif] can appear ...
> 
> Julian Reschke wrote:
> > this draft differs from the latest edits made in October in 
> that two open
> > issues have been resolved (both were raised by myself and resolved in
> > agreement between Geoff and me). I therefore the working group 
> to issue the
> > "last call" for this spec.
> 
> -------------------------
> Antony Blakey
> mailto:antony.blakey@linkuistics.com.au
> Linkuistics - The Language of the Web
> 
> All that is required for evil to triumph is that good men do nothing.
> 



From w3c-dist-auth-request@w3.org  Mon Feb 24 09:36:21 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15405
	for <webdav-archive@lists.ietf.org>; Mon, 24 Feb 2003 09:36:21 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1OEd0404208;
	Mon, 24 Feb 2003 09:39:00 -0500 (EST)
Resent-Date: Mon, 24 Feb 2003 09:39:00 -0500 (EST)
Resent-Message-Id: <200302241439.h1OEd0404208@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1OEcwL04139
	for <w3c-dist-auth@frink.w3.org>; Mon, 24 Feb 2003 09:38:58 -0500 (EST)
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 JAA06182
	for <w3c-dist-auth@w3c.org>; Mon, 24 Feb 2003 09:38:57 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 24 Feb 2003 09:22:37 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <FKKQJATY>; Mon, 24 Feb 2003 09:38:21 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE201FC383C@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Mon, 24 Feb 2003 09:38:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: Review of ordering draft, version 05
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE201FC383C@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7260
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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
   > Are we possibly making things confusing by introducing a
   > postcondition "code" like (DAV:ordering-type-set) for something that
   > MUST be done?  It makes it seem like the server might choose not to set
   > the ordering type, create the collection anyway, and respond with 409
   > containing <DAV:ordering-type-set/>.

Whether or not a particular request may "partially succeed" is up
to the definition of that request.  Most RFC3253 methods are defined
to be atomic, i.e. they either succeed or they have no effect on
the server state.  The reason that multiple postconditions are
defined for an atomic operation is to allow the server to give the
client a more precise idea about which of the semantics of the
request could not be achieved (the client can then use this
information to give the user a better error message).

WRT to the specific example mentioned here, I agree that this issue
should be addressed by the ordering protocol, by having it state
whether the methods it is defining/extending are atomic, or whether
they are allowed to partially succeed.  I recommend that they be
required to be atomic.

   > Wouldn't a total failure to do
   > some required behavior normally be defined as a 500 response?

The difference between 4xx and 5xx is whether or not it is considered
a "client error" (e.g. an operation was attempted on a resource that
was not in an appropriate state for that operation to succeed) or a
"server error" (e.g. something went wrong on the server such as
running out of virtual memory).  So whether or not this is a 4xx or
5xx depends on whether the method definition allows server state to be
changed when the operation does not fully succeed.

   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   Yes, and I think that's something that should be possibly fixed in
   RFC3253.  Failure to meet a postcondition (after all preconditions
   were verified) always is a server bug and thus would belong into
   the 5xx range.  The main question is: which spec should fix that?
   I'd really like to see RFC2518bis to pick up (and clarify) this
   kind of error typing (maybe in a way that makes it optional?).

Minimally, I agree that RFC3253 should be extended to allow error
tokens to be returned with any 4xx or 5xx response code.  I'll add
this to the issues list, and start a thread on the topic in the
versioning mailing list.  In particular, as Julian points out, this
would allow the more appropriate 5xx response code to be returned when
a postcondition is violated.

As for whether RFC2518bis picks this up, it probably is only useful to
do so if appropriate error tokens are defined.  I believe this would
not only improve interoperable error reporting for 2518, but would
help address some of the vagueness that remains in 2518.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Mon Feb 24 13:46:30 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22280
	for <webdav-archive@lists.ietf.org>; Mon, 24 Feb 2003 13:46:29 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1OInS526844;
	Mon, 24 Feb 2003 13:49:28 -0500 (EST)
Resent-Date: Mon, 24 Feb 2003 13:49:28 -0500 (EST)
Resent-Message-Id: <200302241849.h1OInS526844@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1OInQI26812
	for <w3c-dist-auth@frink.w3.org>; Mon, 24 Feb 2003 13:49:26 -0500 (EST)
Received: from mail.gmx.net (mail.gmx.net [213.165.65.60])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA11688
	for <w3c-dist-auth@w3c.org>; Mon, 24 Feb 2003 13:49:26 -0500
Received: (qmail 6677 invoked by uid 0); 24 Feb 2003 18:48:54 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp009-rz3) with SMTP; 24 Feb 2003 18:48:54 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Mon, 24 Feb 2003 19:48:54 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCAEBLGJAA.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.6604 (9.0.2911.0)
In-Reply-To: <E4F2D33B98DF7E4880884B9F0E6FDEE201FC383C@SUS-MA1IT01>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: Review of ordering draft, version 05
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEBLGJAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7261
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 Clemm, Geoff
> Sent: Monday, February 24, 2003 3:38 PM
> To: 'Webdav WG'
> Subject: RE: Review of ordering draft, version 05
>
>
>
>    > From:  Lisa Dusseault
>    > Are we possibly making things confusing by introducing a
>    > postcondition "code" like (DAV:ordering-type-set) for something that
>    > MUST be done?  It makes it seem like the server might choose
> not to set
>    > the ordering type, create the collection anyway, and respond with 409
>    > containing <DAV:ordering-type-set/>.
>
> Whether or not a particular request may "partially succeed" is up
> to the definition of that request.  Most RFC3253 methods are defined
> to be atomic, i.e. they either succeed or they have no effect on
> the server state.  The reason that multiple postconditions are
> defined for an atomic operation is to allow the server to give the
> client a more precise idea about which of the semantics of the
> request could not be achieved (the client can then use this
> information to give the user a better error message).
>
> WRT to the specific example mentioned here, I agree that this issue
> should be addressed by the ordering protocol, by having it state
> whether the methods it is defining/extending are atomic, or whether
> they are allowed to partially succeed.  I recommend that they be
> required to be atomic.
> ...

Of course they are meant to be atomic. In fact, I don't agree that this
needs to be clarified.

RFC3253 says:

	'A "postcondition" of a method describes the state of the server that must
be true after that method has been completed.'

Having a *set* of postconditions simply means that the state changes have
been broken down into separate items, it does *not* mean that some of them
are optional.

The ordering spec uses the same structure as RFC3253 here, and RFC3253
doesn't seem to use the term "atomic" anywhere when specifying multiple
postconditions. So if this really is an issue, I think it applies to all
specs using this terminology, not only the ordering spec.


Julian

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



From w3c-dist-auth-request@w3.org  Mon Feb 24 14:34:03 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23832
	for <webdav-archive@lists.ietf.org>; Mon, 24 Feb 2003 14:34:03 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1OJaH418172;
	Mon, 24 Feb 2003 14:36:17 -0500 (EST)
Resent-Date: Mon, 24 Feb 2003 14:36:17 -0500 (EST)
Resent-Message-Id: <200302241936.h1OJaH418172@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1OJaFI18136
	for <w3c-dist-auth@frink.w3.org>; Mon, 24 Feb 2003 14:36:15 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA28111
	for <w3c-dist-auth@w3c.org>; Mon, 24 Feb 2003 14:36:14 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18nOOb-0006uz-00
	for w3c-dist-auth@w3c.org; Mon, 24 Feb 2003 19:36:13 +0000
Received: from [216.36.77.241] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18nOOb-0006uo-00
	for w3c-dist-auth@w3c.org; Mon, 24 Feb 2003 19:36:13 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Mon, 24 Feb 2003 11:36:14 -0800
Message-ID: <000d01c2dc3b$fdf6b420$f8cb90c6@xythoslap>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_000E_01C2DBF8.EFD37420"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Subject: FW: I-D ACTION:draft-daigle-napstr-01.txt
X-Archived-At: http://www.w3.org/mid/000d01c2dc3b$fdf6b420$f8cb90c6@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7262
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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_01C2DBF8.EFD37420
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

FYI

I know this is a little late (published 3.5 months ago) but I only just
realized the relevance to the WebDAV-server-discovery emails (e.g. the
suggestion of using appletalk I think) on the list a couple weeks ago.  

Lisa

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] 
Sent: Thursday, November 07, 2002 3:22 AM
Subject: I-D ACTION:draft-daigle-napstr-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Domain-based Application Service Location
Using SRV 
                          RRs and the Dynamic Delegation Discovery
Service 
                          (DDDS)
	Author(s)	: L. Daigle, A. Newton
	Filename	: draft-daigle-napstr-01.txt
	Pages		: 13
	Date		: 2002-11-6
	
This memo defines a Dynamic Delegation Discovery System (DDDS) [3]
Application for domain name based discovery of application services.
Essentially, this uses DNS NAPTR resource records [4] to provide one
more layer of redirection for service lookup than is feasible with
SRV ([2]) records.  It is proposed because real-life use is
demonstrating a need for something slightly more substantial than
SRV, and alternatively SRV usage may become twisted out of its
intended shape.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daigle-napstr-01.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-daigle-napstr-01.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-daigle-napstr-01.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_000_000E_01C2DBF8.EFD37420
Content-Type: Message/External-body;
	name="draft-daigle-napstr-01.txt"
Content-Disposition: attachment;
	filename="draft-daigle-napstr-01.txt"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID:	<2002-11-6174051.I-D@ietf.org>


------=_NextPart_000_000E_01C2DBF8.EFD37420--




From w3c-dist-auth-request@w3.org  Tue Feb 25 04:48:58 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21887
	for <webdav-archive@lists.ietf.org>; Tue, 25 Feb 2003 04:48:57 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1P9oxa18946;
	Tue, 25 Feb 2003 04:50:59 -0500 (EST)
Resent-Date: Tue, 25 Feb 2003 04:50:59 -0500 (EST)
Resent-Message-Id: <200302250950.h1P9oxa18946@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1P9ouI18880
	for <w3c-dist-auth@frink.w3.org>; Tue, 25 Feb 2003 04:50:56 -0500 (EST)
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 EAA30295
	for <w3c-dist-auth@w3.org>; Tue, 25 Feb 2003 04:50:56 -0500
Received: from cs.bris.ac.uk (actually host lunaleka.cs.bris.ac.uk) 
          by dire.bris.ac.uk with SMTP-PRIV with ESMTP;
          Tue, 25 Feb 2003 09:50:42 +0000
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 JAA04224;	Tue, 25 Feb 2003 09:49:23 GMT
Received: from cs.bris.ac.uk by onokahi.cs.bris.ac.uk (8.9.3) id JAA09593;
          Tue, 25 Feb 2003 09:49:21 GMT
Message-ID: <3E5B3C20.7CF68A6@cs.bris.ac.uk>
Date: Tue, 25 Feb 2003 09:49:20 +0000
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: slide-user <slide-user@jakarta.apache.org>, WebDAV <w3c-dist-auth@w3.org>,
        JavaCC <javacc-interest@mack.eng.sun.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: Stop WW3- Sorry if it is out of the blue for the mailing list 
X-Archived-At: http://www.w3.org/mid/3E5B3C20.7CF68A6@cs.bris.ac.uk
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7263
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


STAND FOR PEACE. War is NOT the Answer. Today we are
at a point of
imbalance
in the world and are moving toward what may be the
beginning of a THIRD
WORLD WAR. If you are against this possibility, the UN
is gathering
signatures in an effort to avoid a tragic world event.
Your signing up
may
look a minor thing, but many names will help the UN to
direct much
energy in
a more peaceful direction. PLEASE COPY (rather than
forward) this
e-mail IN
A NEW MESSAGE, sign at the end of the list, and send
it to all the
people
whom you know. If you receive this list will more than
500 names
signed,
please send a copy of the message to :

unicwash@unicwash.org <mailto:unicwash@unicwash.org>
<<mailto:unicwash@unicwash.org>>
Even if you decide not to sign, please consider
forwarding the petition
on
instead of eliminating it.
Thank you.
-----------------------------------------------------------

Les Itats-Unis sont sur le point de diclarer la
guerre.
Aujourd'hui, nous nous trouvons dans une situation de
disiquilibre
mondial,
ce qui pourrait initier une TROISIHME GUERRE MONDIALE.
Si vous jtes
contre,
l'ONU est en train de compiler les signatures pour
iviter ce tragique
ivinement mondial. S'IL VOUS PLANT, FAITES UNE COPIE
de ce message
(pluttt
que de le transmettre) et placez-le DANS UN NOUVEAU
MESSAGE, icrivez
votre
nom ` la fin de la liste et envoyez- la ` toutes les
personnes que vous
connaissez. Si vous recevez cette liste et qu'elle
contient plus de 500
noms, s'il vous plant, envoyez une copie ` cette
adresse :
unicwash@unicwash.org <mailto:unicwash@unicwash.org>
<<mailto:unicwash@unicwash.org>>
De plus, si vous n'ajoutez pas votre nom ` la liste,
s'il vous plant,
n'effacez pas la pitition. Faites-la suivre `
quelqu'un d'autre. Merci.
-------------------------------------------------------

Estados Unidos esta a punto de declarar la guerra. Hoy
nos encontramos
en un
punto en desequilibrio mundial por lo que puede dar
inicio a una
TERCERA
GUERRA MUNDIAL. Si tu estas en contra, la ONU se
encuentra recopilando
firmas para evitar este tragico acontecimiento
mundial. POR FAVOR COPIA
este
e-mail en un mensaje nuevo, firma al final de la lista
que veras a
continuacisn, y mandalo a todas las personas que
conozcas. Si recibes
esta
lista con + de 500 nombres en ella, por favor envma
una copia del
mensaje a
:
unicwash@unicwash.org <mailto:unicwash@unicwash.org>
<<mailto:unicwash@unicwash.org>>
Incluso si decides no firmar, por favor se considerado
y no elimines la
peticisn. SSLO REENVMALO PARA JUNTOS HACER ALGO.
Gracias.
--------------------------------------------------------

1) Suzanne Dathe, Grenoble, France
2) Laurence Comparat, Grenoble, France
3) Philippe Motte, Grenoble, France
4) Jok Ferrand, Mont St Martin, France
5) Emmanuelle Pignol, St Martin d'Hhres, France
6) Marie Gauthier, Grenoble, France
7) Laurent Vescalo, Grenoble, France
8) Mathieu Moy, St Egreve, France
9) Bernard Blanchet, Mont St Martin, France
10) Tassadite Favrie, Grenoble, France
11) Loic Godard, St Ismier, France
12) Benedicte Pascal, Grenoble, France
13) Khedaidja Benatia, Grenoble, France
14) Marie-Therese Lloret, Grenoble, France
15) Benoit Theau, Poitiers, France
16) Bruno Constantin, Poitiers, France
17) Christian Cognard, Poitiers, France
18) Robert Gardette, Paris, France
19) Claude Chevillard, Montpellier, France
20) Gilles Freiss, Montpellier, France
21) Patrick Augereau, Montpellier, France
22) Jean Imbert, Marseille, France
23) Jean-Claude Murat, Toulouse, France
24) Anna Bassols, Barcelona, Catalonia
25) Mireia Dunach, Barcelona, Catalonia
26) Michel Villaz, Grenoble, France
27) Frederique Pages , Dijon, France
28) Rodolphe Fischmeister, Chatenay-Malabry, France
29) Francois Bouteau, Paris, France
30) Patrick Peter, Paris, France
31) Lorenza Radici, Paris, France
32) Monika Siegenthaler, Bern, Switzerland
33) Mark Philp, Glasgow, Scotland
34) Tomas Andersson, Stockholm, Sweden
35) Jonas Eriksson, Stockholm, Sweden
36) Karin Eriksson, Stockholm, Sweden
37) Ake Ljung, Stockholm, Sweden
38) Carina Sedlmayer, Stockholm, Sweden
39) Rebecca Uddman, Stockholm, Sweden
40) Lena Skog, Stockholm, Sweden
41) Micael Folke, Stockholm, Sweden
42) Britt-Marie Folke, Stockholm, Sweden
43) Birgitta Schuberth, Stockholm, Sweden
44) Lena Dahl, Stockholm, Sweden
45) Ebba Karlsson, Stockholm, Sweden
46) Jessica Carlsson, Vaxjo, Sweden
47) Sara Blomquist, Vaxjo, Sweden
48) Magdalena Fosseus, Vaxjo, Sweden
49) Charlotta Langner, Goteborg, Sweden
50) Andrea Egedal, Goteborg, Sweden
51) Lena Persson, Stockholm, Sweden
52) Magnus Linder, Umea , Sweden
53) Petra Olofsson, Umea, Sweden
54) Caroline Evenbom, Vaxjo, Sweden
55) Asa Pettersson, Grimsas, Sweden
56) Jessica Bjork, Grimsas, Sweden
57) Linda Ahlbom Goteborg, Sweden
58) Jenny Forsman, Boras, Sweden
59) Nina Gunnarson, Kinna, Sweden
60) Andrew Harrison, New Zealand
61) Bryre Murphy, New Zealand
62) Claire Lugton, New Zealand
63) Sarah Thornton, New Zealand
64) Rachel Eade, New Zealand
65) Magnus Hjert, London, UK
67) Madeleine Stamvik, Hurley, UK
68) Susanne Nowlan, Vermont, USA
69) Lotta Svenby, Malmoe, Sweden
70) Adina Giselsson, Malmoe, Sweden
71) Anders Kullman, Stockholm, Sweden
72) Rebecka Swane, Stockholm, Sweden
73) Jens Venge, Stockholm, Sweden
74) Catharina Ekdahl, Stockholm, Sweden
75) Nina Fylkegard, Stockholm, Sweden
76) Therese Stedman, Malmoe, Sweden
77) Jannica Lund, Stockholm, Sweden
78) Douglas Bratt
79) Mats Lofstrom, Stockholm, Sweden
80) Li Lindstrom, Sweden
81) Ursula Mueller, Sweden
82) Marianne Komstadius, Stockholm, Sweden
83) Peter Thyselius, Stockholm, Sweden
84) Gonzalo Oviedo, Quito, Ecuador
85) Amalia Romeo, Gland, Switzerland
86) Margarita Restrepo, Gland, Switzerland
87) Eliane Ruster, Crans p.C.Switzerland
88) Jennifer Bischoff-Elder, Hong Kong
89) Azita Lashgari, Beirut, Lebanon
90) Khashayar Ostovany, New York, USA
91) Lisa L Miller, Reno NV
92) Danielle Avazian, Los Angeles, CA
93) Sara Risher, Los Angeles,Ca.
94) Melanie London, New York, NY
95) Susan Brownstein , Los Angeles, CA
96) Steven Raspa, San Francisco, CA
97) Margot Duane, Ross, CA
98) Natasha Darnall, Los Angeles, CA
99) Candace Brower, Evanston, IL
100) James Kjelland, Evanston, IL
101) Michael Jampole, Beach Park, IL, USA
102) Diane Willis, Wilmette, IL, USA
103) Sharri Russell, Roanoke, VA, USA
104) Faye Cooley, Roanoke, VA, USA
105) Celeste Thompson, Round Rock, TX, USA
106) Sherry Stang, Pflugerville, TX, USA
107) Amy J. Singer, Pflugerville, TX USA
108) Milissa Bowen, Austin, TX USA
109) Michelle Jozwiak, Brenham, TX USA
110) Mary Orsted, College Station, TX USA
111) Janet Gardner, Dallas, TX USA
112) Marilyn Hollingsworth, Dallas, TX USA
113) Nancy Shamblin, Garland. TX USA
114) K. M. Mullen, Houston, TX - USA
115) Noreen Tolman, Houston, Texas - USA
116) Laurie Sobolewski, Warren, MI
117) Kellie Sisson Snider, Irving Texas
118) Carol Currie, Garland, Garland Texas
119) John Snyder, Garland, TX USA
120) Elaine Hannan, South Africa
121) Jayne Howes, South Africa
122) Diane Barnes, Akron, Ohio
123) Melanie Dass Moodley, Durban, South Africa
124) Imma Merino, Barcelona, Catalonia
125) Toni Vinas, Barcelona, Catalonia
126) Marc Alfaro, Barcelona, Catalonia
127) Manel Saperas, Barcelona, Catalonia
128) Jordi Ribas Izquierdo, Catalonia
129) Naiana Lacorte Rodes, Catalonia
130) Joan Vitoria i Codina, Barcelona, Catalonia
131) Jordi Paris i Romia, Barcelona, Catalonia
131) Marta Truno i Salvado, Barcelona, Catalonia
132) Jordi Lagares Roset, Barcelona, Catalonia
133) Josep Puig Vidal, Barcelona, Catalonia
134) Marta Juanola i Codina, Barcelona, Catalonia
135) Manel de la Fuente i Colino,Barcelona, Catalonia
136) Gemma Belluda i Ventura, Barcelona, Catalonia
137) Victor Belluda i Ventur, Barcelona, Catalonia
138) MaAntonia Balletbo, barcelona, Spain
139) Mireia Masdevall Llorens,Barcelona, Spain
140) Clara Planas, Barcelona, Spain
141) Fernando Labastida Gual, Barcelona, Spain
142) Cristina Vacarisas, Barcelona, Spain
143) Enric Llarch i Poyo, Barcelona, Catalonia
144) Rosa Escoriza Valencia, Barcelona, Catalonia
145) Silvia Jimenez, Barcelona, Catalonia
146) Maria Clarella, Barcelona, Catalonia
147) Angels Guimera, Barcelona, Catalonia
148) M.Carmen Ruiz Fernandez, Barcelona, Catalonia
149) Rufi Cerdan Heredia, Barcelona,Catalonia
150) M. Teresa Vilajeliu Roig, Barcelona, Catalonia
151) Rafel LLussa, Girona, Catalonia, Spain
152) Mariangels Gallego Ribo, Gelida, Catalonia
153) Jordi Cortadella, Gelida, Catalonia
154) Pere Botella, Barcelona, Catalonia (Spain)
155) Josefina Auladell Baulenas,Catalunya (Spain)
156) Empar Escoin Carceller, Catalunya (Spain)
157) Elisa Pla Soler, Catalunya (Spain)
158) Paz Morillo Bosch, catalunya (Spain)
159) Cristina Bosch Moreno, Madrid (Spain)
160) Marta Puertolas, Barcelona (Spain)
161) Elisa del Pino (Madrid) Spain
162) Joaquin Rivera (Madrid) Spain
163) Carmen Barral (Madrid) Spain
164) Carmen del Pino (Madrid) Spain
165) Asuncion del Pino (Madrid) Spain
166) Asuncion Cuesta (Madrid) Spain)
167) Ana Polo Mediavilla (Burgos) Spain
168) Mercedes Romero Laredo (Burgos) Espana
169) Oliva Mertinez Fernandez (Burgos) Espana
170) Silvia Leal Aparicio (Burgos) Espana
171) Claudia Elizabeth Larrauri (Bahia Blanca)
Argentina
172) Federico G. Pietrokovsky (C.F.) Argentina
173) Naschel Prina (Capital Federal) Argentina
174) Daniela Gozzi (Capital Federal) Argentina
175) Paula Elisa Kvedaras (Capital Federal) Argentina
176) Antonio Izquierdo (Valencia) Espana
177) Ana Belen Perez Solsona (Valencia) Espana
178) Paula Folques Diago (Valencia) Espana
179) Nestor Alis Pozo (Valencia) Espana
180) Rafael Alis Pozo (valencia) Spain
181) Isabel Maria Martinez (Valencia) Espana
182) Cristina Bernad Guerrero (Valencia) Espana
183) Iria Barcia Sanchez
184) Elena Barrios Barcia. Uppsala. Suecia
185) Illana Ortiz Martin. Munchen. Alemania
186) Santiago Rodriguez Rasero. M|nchen. Alemania
187) David Agss Dmaz. Pamplona. Espaqa
188) Juan Luis Ibarretxe. Galdakao. E.H.
189) Rubin Dmez Ealo. Galdakao. E.H.
190) Marcial Rodrmguez Garcma. Ermua.
191) Imanol Echave Calvo. San Sebastian. Spain
192) Begoqa Ortiz de Zarate Lazcano.Vitoria- Gasteiz.
Spain
193) David Sanchez Agirregomezkorta.Gasteiz. Euskadi.
194) Alberto Ruiz De Alda.Gasteiz. Euzkadi
195) Juan Carlos Garcia Obregon.Vitoria-Gasteiz.
Espaqa
196) Jon Aiarza Lotina. Santander. Spain
197) Teresa del Hoyo Rojo.Santander
198) Celia Nespral Gaztelumendi.Santander, Espaqa
199) Pedro Martmn Villamor, Valladolid, Espaqa.
200) Victoria Arratia Martmn,Valladolid, Espaqa
201) Javi Tajadura Martmn, Portugalete, Euskadi. Spain

202) Lourdes Palacios Martin, Bilbao, Spain
203) Jeszs Avila de Grado, Madrid, Espaqa
204) Eva Marma Cano Lspez. Madrid. Spain
205) Emilio Ruiz Olivar, Londres, UK
206) Maru Ortega Garcma del Moral,Calahorra, Espaqa
207) Juan Carlos Ayala Calvo, Logroqo,Spain
208) Rocmo Muqoz Pino, Logroqo, Espaqa
209) Ximena Pino Burgos, Santiago, Chile
210) Roberto Saldivia Quezada, Santiago,Chile
211) Paola Gonzalez Valderrama,Santiago, Chile
212) Cesar Morales Peqa y Lillo,Santiago
213) Denisse Labarca Abdala , Santiago,Chile
214) Marma Paz Gonzalez Garay
215) Daniela Millar Kaiser, Santiago,Chile
216) Alvaro Wigand Perales, Valdivia,Chile
217) Gladys Bustos Carrasco, Quilicura, Chile
218) Patricio Criado Rivera, Quilicura, Chile
219) Carolina Aguilar Monsalve,Valdivia, Chile
220) Carmen Silva Utrilla, Madrid, Espaqa
221) Martha Yolanda Rodriguez Aviles, Queretaro,
Mexico
222) Laura Rodriguez Aviles,Cozumel,Quintana Roo,
Mexico
223) Katia Hahn, Merida, YUCATAN
224) Sofia Gallego Mexicali, B.C. Mexico
225) Beatriz Castaqeda De Clariond, Monterrey, Mixico
226) Victor Kerber Palma, Monterrey, Mixico
227) Rocmo Sanchez Losada, Mixico D.F.
228) Lorenza Estandma Gonzalez Luna, Mixico D.F.
229) Gabriel Gallardo D'Aiuto, Mixico D.F.
230) Josh Antonio Salinas, Monterrey, N.L., Mexico
231) Laura Cantu, Mty N.L., Mexico
232) Jossie Garcia,Mty N.L Mexico
233) Martha Vazquez Gonzalez, Mty, N.L.; Mexico
234) Laura Rios Muqiz, Monterrey, N.L. Mexico
235) Dalith Flores Quinatana , Monterrey, N.L. Mexico
236) Armando Hernandez, Monterrey, NL Mexico
237)Cynthia Guzman, Monterrey, NL, Mexico
238) Berta Isabel Chapa Monterrey, NL Mexico
239) Nelly Cantz Orocio Monterrey,NL Mixico
240) Daniel Alejandro de la Rosa Mty.N.L. Mixico
241) Susana Cantz Orocio Mty. N.L. Mixico
242) Irving Jaime Cantz Baez Mty. N.L. Mixico
243) Josi Alfredo Rodrmguez Villa. Monterrey, Mex.
244) Marina Daniel Ayala, Monterrey, NL, Mexico
245) Andres Alberto Basaqez Gonzalez
246) Patty Torres R., Monterrey, NL, Mexico
247) Annet Abarca Arvide, Monterrey,NL, Mexico
248) Silvia Ruiz Mancera
249) Vanessa L. Hjerpe Ibarra Mixico, DF Mexico
250) Monica A. Guisa Sanchez, D.F. Mexico
251) Gabriel Alejandro Sanchez Leyva, Guadalajara,
Jalisco, Mexico
252) Lizette Oseguera Tinajero, Guadalajara, Jalisco,
Mexico
253) Dalia Zavala Acosta, Tijuana, B.C. Mixico
254) Celina N Contreras, Tijuana, B. C., Mexico
255) Octavio Moreno Hernandez, San Diego, CA., USA
256) Iliana Hernadez Torres, Tijuana, BC Mexico
257) Francisco Flores Flores, Tijuana, B.C. Mexico
258) Arlene Cordero Macias, Tijuana, B.C., Mixico
259) Jorge Barnetche Pous, Tijuana, Baja California,
Mixico
260) Pilar de la Fuente, Cd. Juarez, Chihuahua, Mixico

261) Esteban Beiza, Santiago, Chile
262) Paulo Frias, Santiago, Chile
263) Alejandra Lastra, Argentina
264) Patricio Manns, Chile.
265) Gaspar Glavich, Suiza
266) Helia Alvarado, Suiza
267) Luis Dmaz Alvayay, Alemania Federal
268) EvaVaras, Santiago, Chile.
269) Cecilia Riveros, Valparaiso, Chile
270) Marcelo Barahona Cornejo, Quilpui, Chile
271) Juan Claudio Tapia Rodrmguez, Chile
272) Oscar Parra A, Chile
273) Mauricio Muqoz V, Chile
274) Angelo Rojas, Chile
275) Alejandra Pirez G., Santiago, Chile
276) Javier Pirez Dmaz, Viqa del Mar, Chile
277) Oscar Espejo Briones; Viqa del Mar; Chile
278) Roberto Alejandro Guerra Esparza; Viqa del
Mar,Chile.
279) Patricia Navarro Hidalgo; Viqa del Mar; Chile
280) Pablo Francisco Ahumada Alvarado; Viqa del Mar;
Chile
281) Mauricio Vergara Ereche; Viqa del Mar; Chile
282) Natalia Marmn Vidal; Viqa del Mar; Chile.
283) Razl Rojas Gaete; Talca ; Chile.
284) Vmctor Guerrero Wolf, Talca ; Chile
285) Andres Ebensperguer Bravo, Viqa del mar; Chile
286) Mackarena Villarroel Fuentes, Puerto montt; chile

287) Gexa Javiera Villarroel Fuentes, Puerto mont;
Chile
288) Freddy Villarroel Fuentes, Puerto mont; Chile
289) Daniela Concha Gutierrez, Puerto mont; Chile
290) Hernan Jimenez Aguayo, Chuquicamata; Chile
291) Andris Lunas Farah, Chuquicamata; Chile
292) Katherine Velozo Nu> qez, Antofagasta; Chile
293) Victor Catalan Silva, Antofagasta; Chile
294) Luis Hernan Carvajal, Calama; Chile
295) Maria Arancibia Carvajal, Calama; Chile
296) Luis Carvajal Rojas, Calama; Chile
297) Jimmy Peqa Lobos, Calama; Chile
298) Jerardo Valenzuela, Antofagasta; Chile
299) Nathaly Kraljevich, Antofagasta; Chile
300) Juan Carvajal Carvajal, Antofagasta; Chile
301) Catherine Lesn Torres,Antofagasta; Chile
302) Cristian Csrdova Olivares, Antofagasta; Chile
303) Jorge Barra Flores, Antofagasta; Chile
304) Ricardo dmaz Cortis, Antofagasta, Chile
305) Claudia Tobar Lazcano, Antofagasta, Chile
306) Carmen Pacheco Rivera, Antofagasta, Chile
307) Raquel Saavedra Torres, Antofagasta, Chile
308) Jaime Alcala Carales, Calama, Chile
309) Versnica Barraza Aravena, Santiago, Chile
310) Myriam Muqoz M., Santiago,Chile
311) Cecilia Hernando R., Santiago, Chile
312) Andris Cuevas Saavedra, Santiago, Chile
313) Luis Millan Gonzalez, Santiago, Chile
314) Gonzalo Veliz G. Santiago, Chile
315) Alvaro Farrz B., Santiago de Chile
316) Constanza Celedsn B., Santiago de Chile
317) Daniel Jadue Jadue, santiago de Chile.
318) George Munir El Alam S., Iquique - Chile
319) Jineth Zuqiga G., Iquique - Chile
320) Geryes Amir El Alam Z., Iquique -Chile
321) Rodrigo Zapata Osorio, Iquique - Chile
322) Reni Rodrigo Rojas Martmnez, Chuquicamata - Chile

323) Msnica Cecilia Ponce Martmnez, Calama - Chile
324) Ricardo Andris Sepzlveda Rmos, Calama - Chile
325) Mauricio Santander Vega - Santiago - Chile
326) Ana-Maria Zabala Imperatore - Santiago - Chile
327) Carmen Imperatore Petersean. Santiago - Chile
328) Cristian Schiefelbein Grossi, Santiago Chile
329) Maria Clara Grossi Brunod, Santiago, Chile
330) Rosario Downey Alvarado, Santiago, Chile
331) Isabel Donoso Ureta, Santiago, Chile
332) Marma Josi Tapia Gr|zmacher, Chile
333) Ana Marma del Valle, Santiago, Chile
334) Rafael del Valle Vergara, Santiago, Chile
335) Maria Grazia Lagos Pola, Santiago, Chile
336) Luis Felipe Baraona Enrmquez, Santiago, Chile
337) Ricardo Polanco Menares, Santiago, Chile
338) Carolina Vargas Pavez, Santiago, Chile
339) Maria Angelica Pavez Garcma, Santiago, Chile
340) Claudia Frigerio Jeldres, Santiago, Chile
341) Alex Toro Monterrosa, Santiago, Chile
342) Pamela Andrea Vii Alarcsn, Santiago, Chile
343) Dlvaro Vergara Vargas, Santiago, Chile
344) Jacqueline Adela Bize Blumenberg, Santiago, Chile

345) Ana Maria Mira Olea, Santiago, Chile
346) Narciso Goiri Flores, Los Andes, Chile
347) Marma Angilica Borie, Los Andes, Chile
348) Carla De Lesn, Panama
349) Claudio Rmos, Argentina
350) Burrows Alicia B., Buenos Aires, Argentina.
351) Sigwald Pedro, Bs. As. - Argentina
352) Roberto Caturegli, CsrdobaArgentina
353) Maria Ines Abregu ,Cb Argentina
354) Ma. C. Di Iorio. Cdad. Bs. As. Argentina
355) Graciela Grosso, Cdad Bs As Argentina
356 ) Marisa Binaghi , Cdad.Bs.As. Argentina
357 ) Diana Feldman , Cdad,Bs,As. Argentina
358) Dianne Pitre, Pointe-`-la-Croix, Qc,Canada
359) Marie-Claire Martin, Pointe-`-la-Croix,Qc,Canada
360) Lambert Maltais, Val D'amour, N.-B., Canada
361) Flavie Lagaci, Val D'amour, N.-B., Canada
362) Ginette Cool, Moncton, NB, Canada
363) Robert Lusk, Moncton, NB, Canada
364) Raymonde Godin, Moncton,NB, Canada
365) Lucille Blaquihre, NB, Canada
366) Ginette Duguay,NB, Canada
367) Odette Larocque, Moncton, NB, Canada
368) Carole Bergeron, Moncton, NB, Canada
369) Bertin Savard, Rigaud,Quibec,Canada
370) Serge Pelletier, Mercier, QC, canada
371) Sylvie Dolbec, Quibec, Canada
372) Chantal Pelletier, Quibec, Canada
373) Martin Chinard, Quibec, Canada
374) Bernard Dubi, Montrial, QC, Canada
375) Karen C. Coombs, Montreal, QC, Canada
376) Yolande Hibert-Azar, Montrial, Qc, Canada
377) Madeleine Azar, Montrial, Qc, Canada
378) Diane Azar, Montr> ial, Qc, Canada
379) Jeannine Asselin, Montrial, Qc, Canada
380) Jean Boutin, Montrial, Qc, Canada
381) Nicole Pelletier, Montrial, Qc, Canada
382) Raymonde Hibert, Montrial, Qc, Canada
383) Christine Venne, Joliette, Qc, Canada
384) Micheline M. Turcotte, Montrial, Qc, Canada
385) Philippe Turcotte, Montrial, Qc, Canada
386) Andri Pelchat, Quibec, QC, Canada
387) Sylvie Houle, Repentigny, Qc, Canada
388) Ciline Turcotte, Montrial, QC, Canada
389) Pierrette Pearson, Montrial, Qc., Canada
390) Nathalie Paquin, Montrial, Qc., Canada
391) Genevihve Goupil, Montrial, Qc., Canada
392) Manon Turcotte, Montrial, Qc, Canada
393) Louise Richer, Montrial, QC, Canada
394) Yvon Lacasse, Montrial, Qc, Canada
395) Maurice Roger, Montrial,Qc.Canada
395) Hilhne Boisvert, Montrial, Qc Canada
396) Michhle Dupont, Montrial, Qui., Canada
397) Myriam Hivon, Montrial, QC, Canada
398) Claire Lorrain, Montrial, Qc, Canada
399) Pierre Demers, Montrial (Quibec)
400) Didier Blavette, Rouen, France
401) Maxime Blavette, Rouen, France
402) Emilie Dauriac, Paris, France
403) Melhem Khalaf, liban
405) Jean Rouquette (Joan Larzac) Montpellhier,
Occitania, France
406) Michhu Prat, Gap, Occit`nia, Estat francis
407) Marie-Hilhne Brawanski, Orange, Provence, France
408)Gilbert Brawanski, Orange, Provenga, France
409)Estelle Brawanski, Orange, Provence, France
410)Cidric COULOMB, Decazeville, France
411)Fabien Ronot, Cavaillon, France
412)Christelle BOREL, Marseille, France
413)Caroline MENAGER, Paris, France
414) Mailys Curan, Lamorlaye, France
415) Charlotte de Calonne, Paris, France
416) Samba Franck, Paris, France
417)Jerome Horvilleur, Paris, France
418)Thierry Bressant, Paris, France
419)Navarro Sebastien, Paris, France
420)Navarro Michel,Avignon, France
421)Navarro Maoti, Avignon,France
422) Kleinberg Sacha, Ivry/sur/Seine, France
423) Dethyre richard ivry- france
424) Blandino jean-paul /AJaccio-France
425) Vartabedian Marc Paris, France
426) Alexandre Damien, VLR, France
427) Etrillard Nathalie, Paris, France
428) Anne-Claire Gouret, Paris, France
429) Antoine Simon-Soundira, Paris, France
430) Marie-Caroline Saussier, Le Chesnay, France
431) Martine Caillon, Malakoff, France
432) Cinthya Tchoumbia, Paris, FRance
433) Guiomar Payo Peqa, Oviedo, Espaqa
434) Tania Maertmnez Vega, Oviedo, Espaqa
435) Carmen Lspez Alvarez, Oviedo, Espaqa
436) Patricia Roman Cerro, Caceres, Espaqa
437) Eva Brunner Csrdoba, Ciudad Real, Espaqa
438) Jaime Brunner Csrdoba, Ciudad Real, Espaqa.
439) Nuria Morales Lspez, Ciudad Real,Espaqa
440) Lioba Gonzalez Ayuso, Guadalajara, Espaqa
441) Marcos Coronado Romero, Cuidad Real, Espaqa
442) M* del Mar Ruiz Molina, Albacete, Espaqa
443) Gonzalo Peces Nicol`s, Toledo, Espaqa
444) Gonzalo Hernandez Muqoz, Toledo, la tierra
445)Irene Criado Castellanos, Toledo, Espaqa
446)Asun Navas Delgado, Madrid, Espaqa
447)Marma Cantarero G*-Sacedsn,Albacete, Espaqa
448) Almudena Pirez Martmn, Granada, Espaqa.
449) Marma Josi Muqoz Martmn, Madrid, Espaqa.
450) Gabriel Campos Salgado, Mexico D.F., Mexico.
451) Lorena Campos Salgado, Mixico, D.F., Mixico
452) Patricia Andrade Cantz gcs
453) Alice Nati, Roma Italia
454) Chiara Chirico, Roma Italia
455) Roger Tutusaus ,Brighton, England
466) Eduard Miquel Solsona, Catalunya
467) Ruth Arms , Catalunya, Spain
468)Carolina Sanchez Dommnguez, Spain
469) Esther Salgado Rodrmguez, Catalunya
470) Ana Gregorio Arnau, Spain
471) Almcia Pasqual i Agut, Catalonia,
472) Elizabeth Goncalves, Oporto, Portugal
473) Paul Cowham, Manchester, UK
478) John Cowham, Manchester, UK
479) Nadeem Bashir, Manchester, UK
450) Jessica Steiner, London, UK
451) Simon Blenkiron, London, UK
452) Martin Jones, London, UK
453) Lewis Rees, Swansea Valley, Wales, UK
454) David Rees, Rhondda, Wales, UK
455) Ann Rees, Rhondda, Wales, UK
456) Gareth Rees, Rhondda, Wales, UK
457) Steven Rees, Rhondda, Wales, UK
458) Nicholas Rees, Rhondda, Wales, UK
459) Katie Rees, Rhondda, Wales, UK
460) Maxine Jones, Rhondda, Wales, UK
461) Cheryl Rees, Swansea Valley, Wales,UK
462) Sibn Stone, Ammanford, Wales, UK
463) Silke Kuball, Bristol, UK
464) Bita Shadgar, Bristol, UK



From w3c-dist-auth-request@w3.org  Tue Feb 25 14:27:48 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11627
	for <webdav-archive@lists.ietf.org>; Tue, 25 Feb 2003 14:27:48 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1PJUPM24178;
	Tue, 25 Feb 2003 14:30:25 -0500 (EST)
Resent-Date: Tue, 25 Feb 2003 14:30:25 -0500 (EST)
Resent-Message-Id: <200302251930.h1PJUPM24178@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1PJUMI24142
	for <w3c-dist-auth@frink.w3.org>; Tue, 25 Feb 2003 14:30:22 -0500 (EST)
Received: from gremlin.ics.uci.edu (root@gremlin.ics.uci.edu [128.195.1.70])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA25241
	for <w3c-dist-auth@w3.org>; Tue, 25 Feb 2003 14:30:22 -0500
Received: from ics.uci.edu (doric.ics.uci.edu [128.195.20.215])
	by gremlin.ics.uci.edu (8.12.5/8.12.5) with ESMTP id h1PJTjkA010759;
	Tue, 25 Feb 2003 11:29:45 -0800 (PST)
Message-ID: <3E5BC422.20300@ics.uci.edu>
Date: Tue, 25 Feb 2003 11:29:38 -0800
From: Joachim Feise <jfeise@ics.uci.edu>
Reply-To: jfeise@ics.uci.edu
Organization: University of California, Irvine
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "B. Shadgar" <shadgar@cs.bris.ac.uk>
CC: slide-user <slide-user@jakarta.apache.org>, WebDAV <w3c-dist-auth@w3.org>,
        JavaCC <javacc-interest@mack.eng.sun.com>
References: <3E5B3C20.7CF68A6@cs.bris.ac.uk>
In-Reply-To: <3E5B3C20.7CF68A6@cs.bris.ac.uk>
X-Enigmail-Version: 0.71.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-MailScanner: Found to be clean
X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.4, required 5,
	IN_REP_TO, NOSPAM_INC, PGP_SIGNATURE, REFERENCES, SPAM_PHRASE_00_01,
	SUBJECT_IS_LIST, UPPERCASE_25_50, USER_AGENT, USER_AGENT_MOZILLA_UA,
	X_ACCEPT_LANG)
Subject: Re: Stop WW3- Sorry if it is out of the blue for the mailing list
X-Archived-At: http://www.w3.org/mid/3E5BC422.20300@ics.uci.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7264
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

B. Shadgar wrote:
[deleted]

Please check these things before you forward them
This is a variation of a known hoax.
See http://www.snopes.com/rumors/un.htm

- -Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)

iD8DBQE+W8QpKc8oZ1MoTeoRAlVBAKCejz3MkutwQh79ikHqzDYdm7m0lwCeMA/N
JDNBubpHnLi3vhrON0Bd2x4=
=fD1M
-----END PGP SIGNATURE-----



From w3c-dist-auth-request@w3.org  Tue Feb 25 18:48:47 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22676
	for <webdav-archive@lists.ietf.org>; Tue, 25 Feb 2003 18:48:47 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1PNpN917214;
	Tue, 25 Feb 2003 18:51:23 -0500 (EST)
Resent-Date: Tue, 25 Feb 2003 18:51:23 -0500 (EST)
Resent-Message-Id: <200302252351.h1PNpN917214@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1PNpLI17182
	for <w3c-dist-auth@frink.w3.org>; Tue, 25 Feb 2003 18:51:21 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA11667
	for <w3c-dist-auth@w3c.org>; Tue, 25 Feb 2003 18:51:20 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18nor1-0001qA-00
	for w3c-dist-auth@w3c.org; Tue, 25 Feb 2003 23:51:19 +0000
Received: from [216.36.77.241] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18nor1-0001pz-00
	for w3c-dist-auth@w3c.org; Tue, 25 Feb 2003 23:51:19 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Tue, 25 Feb 2003 15:51:19 -0800
Message-ID: <016001c2dd28$cacd07a0$f8cb90c6@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.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Subject: If header re-evaluation
X-Archived-At: http://www.w3.org/mid/016001c2dd28$cacd07a0$f8cb90c6@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7265
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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



RFC2518 says "The same URI MUST NOT appear more than once in a resource
production in an If header.".

Is there any reason for that? In my experience, it just makes more work
for the server to parse the header. It doesn't make things easier for
the client either -- just another restriction the client must be aware
of.

Should this be removed in 2518bis?

Lisa




From w3c-dist-auth-request@w3.org  Tue Feb 25 20:04:34 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23885
	for <webdav-archive@lists.ietf.org>; Tue, 25 Feb 2003 20:04:34 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1Q17EO25776;
	Tue, 25 Feb 2003 20:07:14 -0500 (EST)
Resent-Date: Tue, 25 Feb 2003 20:07:14 -0500 (EST)
Resent-Message-Id: <200302260107.h1Q17EO25776@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1Q17CI25744
	for <w3c-dist-auth@frink.w3.org>; Tue, 25 Feb 2003 20:07:12 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA30117
	for <w3c-dist-auth@w3c.org>; Tue, 25 Feb 2003 20:07:12 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18nq2R-0002fr-00; Wed, 26 Feb 2003 01:07:11 +0000
Received: from [216.36.77.241] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18nq2R-0002fg-00; Wed, 26 Feb 2003 01:07:11 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Clemm, Geoff'" <gclemm@rational.com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Tue, 25 Feb 2003 17:07:10 -0800
Message-ID: <016601c2dd33$63e1d3d0$f8cb90c6@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.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <E4F2D33B98DF7E4880884B9F0E6FDEE20129B366@SUS-MA1IT01>
Importance: Normal
Old-X-Envelope-To: gclemm@rational.com,
 w3c-dist-auth@w3c.org
Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
X-Archived-At: http://www.w3.org/mid/016601c2dd33$63e1d3d0$f8cb90c6@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7266
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


Geoff said:

"Just one comment on the statement "we've already discovered since
2518 was published that locks aren't the only tool required to
prevent lost updates".  I disagree ... locks are sufficient to
prevent lost updates.  If a client decides not to use the locking
protocol correctly (i.e. by updating a resource for which it does
not have a valid lock), then of course something additional is 
required, but for a client that uses the locking protocol properly,
locks are the only tool required to prevent lost updates."

This was back in November but I have so far failed to respond. 

Locks never did solve the "lost update" problem, precisely.  (Etags
alone are sufficient to prevent a user from overwriting another users
changes.) Locks solve the "aggravated user" problem, which is when I've
been working for six hours on a document, and when I try to save it to
the server the server tells me somebody else made changes and do I want
to overwrite those changes...

So I lock the file to prevent other people from making changes while I
work.  I get to reserve the file until I submit all my changes. I'm
never presented with a dialog saying "do you want to overwrite"...
Ideally, that is.

In reality, locks can be lost.  The most common situation is probably
when the client goes offline accidentally during an editing session.
Users and client applications have no control over wireless, routers,
power -- failures that can prevent the client from renewing a lock.

So let's say you've lost your lock.  The user has been editing while the
lock existed, and they already made changes. When the client manages to
reconnect to try to save, the lock is gone.  Well, there are two
situations:
 (1) The file changed while it was unlocked.  That sucks, there's no
choice but to prompt the user to find out what they want to do.
 (2) The file did *not* change while it was unlocked.  Cool. Without
bothering the user with difficult and annoying questions, the client can
simply relock the file and save changes. 

Since (2) is much more common than one, and much more pleasant, the
client would like to know when (2) is the case.  Etags would solve this.
That's why I claimed that locks alone did not entirely solve the
lost-update problem.

Lisa




From w3c-dist-auth-request@w3.org  Tue Feb 25 20:25:10 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24240
	for <webdav-archive@lists.ietf.org>; Tue, 25 Feb 2003 20:25:10 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1Q1RsV27608;
	Tue, 25 Feb 2003 20:27:54 -0500 (EST)
Resent-Date: Tue, 25 Feb 2003 20:27:54 -0500 (EST)
Resent-Message-Id: <200302260127.h1Q1RsV27608@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1Q1RpI27576
	for <w3c-dist-auth@frink.w3.org>; Tue, 25 Feb 2003 20:27:51 -0500 (EST)
Received: from mail.gmx.net (mail.gmx.net [213.165.65.60])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id UAA00649
	for <w3c-dist-auth@w3c.org>; Tue, 25 Feb 2003 20:27:51 -0500
Received: (qmail 19985 invoked by uid 0); 26 Feb 2003 01:27:20 -0000
Received: from p3EE2481F.dip.t-dialin.net (HELO lisa) (62.226.72.31)
  by mail.gmx.net (mp003-rz3) with SMTP; 26 Feb 2003 01:27:20 -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: Wed, 26 Feb 2003 02:27:14 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCGEGAGJAA.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.6604 (9.0.2911.0)
Importance: Normal
In-Reply-To: <016601c2dd33$63e1d3d0$f8cb90c6@xythoslap>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEGAGJAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7267
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 agree with the statement that etags are useful. Etags on their own are
useful. ETags in conjunction with locking are even more useful. I doubt
anybody disagrees.

The issue we've been debating recently whether this justifies to *require*
etags. My recent tests with IIS and Apache/Moddav show that upon a PUT, all
you get is a weak etag, which clearly demonstrates that it is non-trivial to
produce robust etags when your backend is a filesystem. So, IMHO, we really
*can't* require strong etags, and weak etags really do not help.

So yes, there must be a safe way for a client to discover the server's etag
support (supported live properties, allprop, propname and GET/HEAD behaviour
MUST match), but that's it.

If a client doesn't want to communicate with a resource that doesn't provide
strong etags, it certainly can (and should be able) to do so. I think that's
all RFC2518bis should say.

Julian

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



From w3c-dist-auth-request@w3.org  Tue Feb 25 21:34:55 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25583
	for <webdav-archive@lists.ietf.org>; Tue, 25 Feb 2003 21:34:55 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1Q2buY04166;
	Tue, 25 Feb 2003 21:37:56 -0500 (EST)
Resent-Date: Tue, 25 Feb 2003 21:37:56 -0500 (EST)
Resent-Message-Id: <200302260237.h1Q2buY04166@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1Q2bsI04130
	for <w3c-dist-auth@frink.w3.org>; Tue, 25 Feb 2003 21:37:54 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA13260
	for <w3c-dist-auth@w3c.org>; Tue, 25 Feb 2003 21:37:53 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18nrSC-0003qO-00; Wed, 26 Feb 2003 02:37:52 +0000
Received: from [216.36.77.241] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18nrSB-0003qD-00; Wed, 26 Feb 2003 02:37:51 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>,
        "'Clemm, Geoff'" <gclemm@rational.com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Tue, 25 Feb 2003 18:37:47 -0800
Message-ID: <016b01c2dd40$0e944a40$f8cb90c6@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.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <JIEGINCHMLABHJBIGKBCGEGAGJAA.julian.reschke@gmx.de>
Importance: Normal
Old-X-Envelope-To: gclemm@rational.com,
 julian.reschke@gmx.de,
 w3c-dist-auth@w3c.org
Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
X-Archived-At: http://www.w3.org/mid/016b01c2dd40$0e944a40$f8cb90c6@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7268
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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's still possible to make a stronger statement about Etag support in
2518bis.  Servers that are compliant with that, whatever RFC number it
will be (maybe '4???'? )  must support strong Etags. Servers that are
compliant with RFC2518 don't need to.

I'm guessing Some clients will interoperate against both RFC2518 servers
and RFC2518bis servers since they're very similar. But eventually,
clients will be written that want the guarantees of "bis", including
Etag support, and these clients will prefer to interoperate with servers
supporting "bis".

lisa

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de] 
> Sent: Tuesday, February 25, 2003 5:27 PM
> To: Lisa Dusseault; 'Clemm, Geoff'; 'Webdav WG'
> Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
> 
> 
> Lisa,
> 
> I agree with the statement that etags are useful. Etags on 
> their own are
> useful. ETags in conjunction with locking are even more 
> useful. I doubt
> anybody disagrees.
> 
> The issue we've been debating recently whether this justifies 
> to *require*
> etags. My recent tests with IIS and Apache/Moddav show that 
> upon a PUT, all
> you get is a weak etag, which clearly demonstrates that it is 
> non-trivial to
> produce robust etags when your backend is a filesystem. So, 
> IMHO, we really
> *can't* require strong etags, and weak etags really do not help.
> 
> So yes, there must be a safe way for a client to discover the 
> server's etag
> support (supported live properties, allprop, propname and 
> GET/HEAD behaviour
> MUST match), but that's it.
> 
> If a client doesn't want to communicate with a resource that 
> doesn't provide
> strong etags, it certainly can (and should be able) to do so. 
> I think that's
> all RFC2518bis should say.
> 
> Julian
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
> 




From w3c-dist-auth-request@w3.org  Wed Feb 26 03:21:45 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28008
	for <webdav-archive@lists.ietf.org>; Wed, 26 Feb 2003 03:21:40 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1Q8O4114050;
	Wed, 26 Feb 2003 03:24:04 -0500 (EST)
Resent-Date: Wed, 26 Feb 2003 03:24:04 -0500 (EST)
Resent-Message-Id: <200302260824.h1Q8O4114050@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1Q8O0I14016
	for <w3c-dist-auth@frink.w3.org>; Wed, 26 Feb 2003 03:24:00 -0500 (EST)
Received: from mail.gmx.net (mail.gmx.net [213.165.65.60])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA03187
	for <w3c-dist-auth@w3c.org>; Wed, 26 Feb 2003 03:23:59 -0500
Received: (qmail 32151 invoked by uid 0); 26 Feb 2003 08:23:28 -0000
Received: from p3EE2481F.dip.t-dialin.net (HELO lisa) (62.226.72.31)
  by mail.gmx.net (mp009-rz3) with SMTP; 26 Feb 2003 08:23:28 -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: Wed, 26 Feb 2003 09:23:22 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCAEGKGJAA.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.6604 (9.0.2911.0)
In-Reply-To: <016b01c2dd40$0e944a40$f8cb90c6@xythoslap>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEGKGJAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7269
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 still possible to make a stronger statement about Etag support in
> 2518bis.  Servers that are compliant with that, whatever RFC number it
> will be (maybe '4???'? )  must support strong Etags. Servers that are
> compliant with RFC2518 don't need to.
>
> I'm guessing Some clients will interoperate against both RFC2518 servers
> and RFC2518bis servers since they're very similar. But eventually,
> clients will be written that want the guarantees of "bis", including
> Etag support, and these clients will prefer to interoperate with servers
> supporting "bis".

that would only be an option if this would be the only difference between
RFC2518 and RFC2518bis, and then if there would be no other future
extensions.

Clients can detect the presence of etags right now. Clients are free not to
author (PUT/PROPPATCH) resources without etags right now. I really don't see
how this change will help anybody.

- it *will* make IIS and Apache/moddav (and a some others) non-conformant

- it *may* encourage server developers to claim strong etag support,
although their etags aren't really strong -- *this* will cause harm because
it may cause undetected lost updates

We really should restrict the changes to those for which we do have
consensus (and these really are clarifications):

- servers SHOULD support etags on authorable resources

- clients MUST be able to reliably detect etag support for a resource

- also add language that describes why locks may not prevent lost updates
(and therefore why strong etags are so desirable)

Julian

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



From w3c-dist-auth-request@w3.org  Wed Feb 26 09:25:44 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06718
	for <webdav-archive@lists.ietf.org>; Wed, 26 Feb 2003 09:25:44 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1QERif11024;
	Wed, 26 Feb 2003 09:27:44 -0500 (EST)
Resent-Date: Wed, 26 Feb 2003 09:27:44 -0500 (EST)
Resent-Message-Id: <200302261427.h1QERif11024@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1QERgI10987
	for <w3c-dist-auth@frink.w3.org>; Wed, 26 Feb 2003 09:27:42 -0500 (EST)
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 JAA02394
	for <w3c-dist-auth@w3c.org>; Wed, 26 Feb 2003 09:27:42 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 26 Feb 2003 09:11:19 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <FKKQNSX3>; Wed, 26 Feb 2003 09:27:09 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE201FC3BC5@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Wed, 26 Feb 2003 09:27:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE201FC3BC5@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7270
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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's points below.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Wednesday, February 26, 2003 3:23 AM
To: Lisa Dusseault; 'Clemm, Geoff'; 'Webdav WG'
Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)


Lisa,

> It's still possible to make a stronger statement about Etag support in
> 2518bis.  Servers that are compliant with that, whatever RFC number it
> will be (maybe '4???'? )  must support strong Etags. Servers that are
> compliant with RFC2518 don't need to.
>
> I'm guessing Some clients will interoperate against both RFC2518 servers
> and RFC2518bis servers since they're very similar. But eventually,
> clients will be written that want the guarantees of "bis", including
> Etag support, and these clients will prefer to interoperate with servers
> supporting "bis".

Clients can detect the presence of etags right now. Clients are free not to
author (PUT/PROPPATCH) resources without etags right now. I really don't see
how this change will help anybody.

- it *will* make IIS and Apache/moddav (and a some others) non-conformant

- it *may* encourage server developers to claim strong etag support,
although their etags aren't really strong -- *this* will cause harm because
it may cause undetected lost updates

We really should restrict the changes to those for which we do have
consensus (and these really are clarifications):

- servers SHOULD support etags on authorable resources

- clients MUST be able to reliably detect etag support for a resource

- also add language that describes why locks may not prevent lost updates
(and therefore why strong etags are so desirable)

Julian

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



From w3c-dist-auth-request@w3.org  Wed Feb 26 13:56:28 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19728
	for <webdav-archive@lists.ietf.org>; Wed, 26 Feb 2003 13:56:27 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1QIuYX21445;
	Wed, 26 Feb 2003 13:56:34 -0500 (EST)
Resent-Date: Wed, 26 Feb 2003 13:56:34 -0500 (EST)
Resent-Message-Id: <200302261856.h1QIuYX21445@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1QIuNI21412
	for <w3c-dist-auth@frink.w3.org>; Wed, 26 Feb 2003 13:56:23 -0500 (EST)
Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA07131
	for <w3c-dist-auth@w3c.org>; Wed, 26 Feb 2003 13:56:22 -0500
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id KAA03250 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Wed, 26 Feb 2003 10:56:02 -0800
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 KAA03230 sender obsfucated@us.ibm.com; Wed, 26 Feb 2003 10:55:45 -0800
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1QIsgXm013556; Wed, 26 Feb 2003 13:54:42 -0500
Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1QIsdsx076138; Wed, 26 Feb 2003 13:54:40 -0500
To: "Clemm, Geoff" <gclemm@Rational.Com>
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <OF109D51EE.13564C75-ON85256CD9.0067CB40@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Wed, 26 Feb 2003 13:54:23 -0500
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|February 24, 2003) at 02/26/2003 13:54:40
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
X-Archived-At: http://www.w3.org/mid/OF109D51EE.13564C75-ON85256CD9.0067CB40@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7271
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 so that you know you're not alone... what Julian suggests sounds
reasonable.

------------------------------------------
Phone: 914-784-7569,   ccjason@us.ibm.com
I do not check nn621779@smallcue.com



From w3c-dist-auth-request@w3.org  Wed Feb 26 14:34:47 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21045
	for <webdav-archive@lists.ietf.org>; Wed, 26 Feb 2003 14:34:47 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1QJaWX29763;
	Wed, 26 Feb 2003 14:36:32 -0500 (EST)
Resent-Date: Wed, 26 Feb 2003 14:36:32 -0500 (EST)
Resent-Message-Id: <200302261936.h1QJaWX29763@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1QJaUI29725
	for <w3c-dist-auth@frink.w3.org>; Wed, 26 Feb 2003 14:36:30 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA22020
	for <w3c-dist-auth@w3c.org>; Wed, 26 Feb 2003 14:36:29 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18o7Lw-0002Pe-00; Wed, 26 Feb 2003 19:36:28 +0000
Received: from [198.144.203.248] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18o7Lv-0002PT-00; Wed, 26 Feb 2003 19:36:27 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Jason Crawford'" <nn683849@smallcue.com>,
        "'Clemm, Geoff'" <gclemm@Rational.Com>
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Wed, 26 Feb 2003 11:36:27 -0800
Message-ID: <010801c2ddce$5b495810$f8cb90c6@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.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <OF109D51EE.13564C75-ON85256CD9.0067CB40@us.ibm.com>
Old-X-Envelope-To: gclemm@Rational.Com,
 nn683849@smallcue.com,
 w3c-dist-auth@w3c.org
Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
X-Archived-At: http://www.w3.org/mid/010801c2ddce$5b495810$f8cb90c6@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7272
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 so that you know you're not alone... what Julian suggests sounds
> reasonable.

OK, this is really starting to sound like consensus, but I want to make
sure we explore the options.  I don't want to accept a consensus based
on arguments that I don't think are valid, even if the consensus might
be right I'd like to know why by seeing valid arguments.

I've attempted to rebut the two arguments I believe to be invalid.
Please explain why I'm wrong if you think the arguments are in fact
valid (perhaps I haven't understood the arguments).  Or, please explain
what other arguments remain for making Etags optional.

1.  The argument that "Etags are too difficult to support".  Is the
problem with strong etags that they're hard to implement for all
resources? Or only for PUTtable resources? The requirement could be that
servers supporting "bis" MUST support strong Etags in response to
successful PUT requests.   Given this, I think it's easy.
 
RFC2616 only says:
   A "strong entity tag" MAY be shared by two entities of a resource
   only if they are equivalent by octet equality...

   An entity tag MUST be unique across all versions of all entities
   associated with a particular resource. A given entity tag value MAY
   be used for entities obtained by requests on different URIs. The use
   of the same entity tag value in conjunction with entities obtained by
   requests on different URIs does not imply the equivalence of those
   entities.

That means that Etags could be almost as simple as a sequence number
plus possibly some file/url string.  A digest of the contents would also
work. Supporting strong etags is actually easier than supporting weak
etags.  It may be slightly time-consuming to generate etags depending on
what algorithm you choose, but the time is insignificant compared to the
time it takes to receive a PUT request, check access controls and store
the body. 

Next, no WebDAV server should have any problem storing the ETag. Any
server capable of storing dead properties is capable of storing an etag
generated on PUT.  A server that cannot store ETags is already likely to
be massively non-compliant.

I might consider a cost-benefit argument to be a valid argument --
although I believe the benefits are high and thus the cost would have to
be even higher to outweight.  However, I don't consider "too difficult
to support regardless of the benefits" to be a valid argument.

2. If 2518bis requires support for Etags, this doesn't retroactively
make servers like IIS5.0 non-compliant with 2518.  That's a historical
standard and we can't change that even if we wanted to. 

On the other hand, there will be several requirements 2518bis which will
make servers compliant with 2518 have to do some work to be compliant
with 2518bis:
 - Making LOCK on an unmapped resource create a regular empty locked
resource (not a lock-null resource)
 - Supporting commas in if header syntax
 - Evaluating all clauses in an if header even if they are tagged with a
URL to which the request does not "apply"
 - etc...

Given that we are already making more requirements on servers in 2518bis
than we did in 2518,  I do not see the "making servers non-compliant"
argument as a valid argument.

Lisa




From w3c-dist-auth-request@w3.org  Wed Feb 26 15:08:24 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22291
	for <webdav-archive@lists.ietf.org>; Wed, 26 Feb 2003 15:08:23 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1QKAus05963;
	Wed, 26 Feb 2003 15:10:56 -0500 (EST)
Resent-Date: Wed, 26 Feb 2003 15:10:56 -0500 (EST)
Resent-Message-Id: <200302262010.h1QKAus05963@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1QKAsI05930
	for <w3c-dist-auth@frink.w3.org>; Wed, 26 Feb 2003 15:10:54 -0500 (EST)
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 PAA01747
	for <w3c-dist-auth@w3c.org>; Wed, 26 Feb 2003 15:10:53 -0500
Received: (qmail 31417 invoked by uid 0); 26 Feb 2003 20:10:22 -0000
Received: from p3EE2473A.dip.t-dialin.net (HELO lisa) (62.226.71.58)
  by mail.gmx.net (mp018-rz3) with SMTP; 26 Feb 2003 20:10:22 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Lisa Dusseault" <lisa@xythos.com>,
        "'Jason Crawford'" <nn683849@smallcue.com>,
        "'Clemm, Geoff'" <gclemm@Rational.Com>
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Wed, 26 Feb 2003 21:10:18 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCEEIOGJAA.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.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <010801c2ddce$5b495810$f8cb90c6@xythoslap>
Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEIOGJAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7273
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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, February 26, 2003 8:36 PM
> To: 'Jason Crawford'; 'Clemm, Geoff'
> Cc: 'Webdav WG'
> Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
>
>
>
>
> > Just so that you know you're not alone... what Julian suggests sounds
> > reasonable.
>
> OK, this is really starting to sound like consensus, but I want to make
> sure we explore the options.  I don't want to accept a consensus based
> on arguments that I don't think are valid, even if the consensus might
> be right I'd like to know why by seeing valid arguments.
>
> I've attempted to rebut the two arguments I believe to be invalid.
> Please explain why I'm wrong if you think the arguments are in fact
> valid (perhaps I haven't understood the arguments).  Or, please explain
> what other arguments remain for making Etags optional.
>
> 1.  The argument that "Etags are too difficult to support".  Is the
> problem with strong etags that they're hard to implement for all
> resources? Or only for PUTtable resources? The requirement could be that
> servers supporting "bis" MUST support strong Etags in response to
> successful PUT requests.   Given this, I think it's easy.
>
> RFC2616 only says:
>    A "strong entity tag" MAY be shared by two entities of a resource
>    only if they are equivalent by octet equality...
>
>    An entity tag MUST be unique across all versions of all entities
>    associated with a particular resource. A given entity tag value MAY
>    be used for entities obtained by requests on different URIs. The use
>    of the same entity tag value in conjunction with entities obtained by
>    requests on different URIs does not imply the equivalence of those
>    entities.
>
> That means that Etags could be almost as simple as a sequence number
> plus possibly some file/url string.  A digest of the contents would also
> work. Supporting strong etags is actually easier than supporting weak
> etags.  It may be slightly time-consuming to generate etags depending on
> what algorithm you choose, but the time is insignificant compared to the
> time it takes to receive a PUT request, check access controls and store
> the body.

Can we agree that the fact that both IIS and moddav only return weak etags
upon PUT indicates a problem?

All you say is correct, yet the two most widely used HTTP/WebDAV servers
just don't do that. Why is that? As far as I understand it's because they
try to be very efficient HTTP servers while also supporting WebDAV. Thus,
their etag handling is completely independant of their WebDAV code (and
property persistence). So, there's no way just to store it somewhere -- it
needs to be computed out of the file's attributes (for those backends which
are file based). Computing a digest upon every GET and HEAD is clearly not
an option due to performance reasons.

Maybe Greg Stein can say more about why moddav works the way it does, but
that's my understanding.

> Next, no WebDAV server should have any problem storing the ETag. Any
> server capable of storing dead properties is capable of storing an etag
> generated on PUT.  A server that cannot store ETags is already likely to
> be massively non-compliant.

See above.

> I might consider a cost-benefit argument to be a valid argument --
> although I believe the benefits are high and thus the cost would have to
> be even higher to outweight.  However, I don't consider "too difficult
> to support regardless of the benefits" to be a valid argument.

I think the problem here is that for both moddav and IIS, it's simply
infeasable to provide strong etags upon PUT and be an efficient HTTP server
at the same time. If you can think of a way to fix this, I'd be interested
to hear how.

The other problem that I see is that if we require strong etags, server
implementors may

1) try harder and possibly come up with strong etags,

2) just ignore the requirement or

3) claim that their etags are strong when in fact they aren't.

1) would be nice, 2) means that clients haven't won anything at all, 3)
would really be a disaster.

If our goal is to get implementors to provide strong etags, we should try to
*convince*, instead of trying to *force*.

> 2. If 2518bis requires support for Etags, this doesn't retroactively
> make servers like IIS5.0 non-compliant with 2518.  That's a historical
> standard and we can't change that even if we wanted to.

For obvious reasons I'll not argue about IIS. But if RFC2518bis mandates
behaviour that Apache/moddav simply can't provide, I think there's something
fundamentally wrong with the requirement.

> On the other hand, there will be several requirements 2518bis which will
> make servers compliant with 2518 have to do some work to be compliant
> with 2518bis:
>  - Making LOCK on an unmapped resource create a regular empty locked
> resource (not a lock-null resource)
>  - Supporting commas in if header syntax

Both are likely simple fixes to the moddav code.

>  - Evaluating all clauses in an if header even if they are tagged with a
> URL to which the request does not "apply"

...can you point me to the relevant discussion about this change...?

>  - etc...
>
> Given that we are already making more requirements on servers in 2518bis
> than we did in 2518,  I do not see the "making servers non-compliant"
> argument as a valid argument.

As I said, it depends on the nature of the change.

Julian

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



From w3c-dist-auth-request@w3.org  Wed Feb 26 15:34:07 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23935
	for <webdav-archive@lists.ietf.org>; Wed, 26 Feb 2003 15:34:06 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1QKb7x09747;
	Wed, 26 Feb 2003 15:37:07 -0500 (EST)
Resent-Date: Wed, 26 Feb 2003 15:37:07 -0500 (EST)
Resent-Message-Id: <200302262037.h1QKb7x09747@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1QKb5I09711
	for <w3c-dist-auth@frink.w3.org>; Wed, 26 Feb 2003 15:37:05 -0500 (EST)
Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA10261
	for <w3c-dist-auth@w3c.org>; Wed, 26 Feb 2003 15:37:03 -0500
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id MAA11486 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Wed, 26 Feb 2003 12:36:56 -0800
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 MAA11454 sender obsfucated@us.ibm.com; Wed, 26 Feb 2003 12:36:51 -0800
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1QKaJab035846; Wed, 26 Feb 2003 15:36:19 -0500
Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1QKaHlv019386; Wed, 26 Feb 2003 15:36:17 -0500
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "'Clemm, Geoff'" <gclemm@Rational.Com>, "Lisa Dusseault" <lisa@xythos.com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <OF1B715D34.19E10086-ON85256CD9.00705E8B@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Wed, 26 Feb 2003 15:34:29 -0500
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|February 24, 2003) at 02/26/2003 15:36:17
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
X-Archived-At: http://www.w3.org/mid/OF1B715D34.19E10086-ON85256CD9.00705E8B@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7274
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 again tend to agree with Julian.

What Lisa has said seems true, but it's not compelling as much as it simply
weakens Julian's position.

Let's use the SHOULD and let implementers understand why they SHOULD
implement strong Etags.  Let the implementers weigh the "difficulty" case
against the benefit case themselves.   And let's let the implementors that
don't follow through on the SHOULD know if they are impacting us as users
and if we're tempted to use a different product.  I know that user feedback
is a strong motivator for most software developers.

J.

------------------------------------------
Phone: 914-784-7569,   ccjason@us.ibm.com
I do not check nn621779@smallcue.com



From w3c-dist-auth-request@w3.org  Wed Feb 26 17:07:51 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28522
	for <webdav-archive@lists.ietf.org>; Wed, 26 Feb 2003 17:07:51 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1QM9xk04725;
	Wed, 26 Feb 2003 17:09:59 -0500 (EST)
Resent-Date: Wed, 26 Feb 2003 17:09:59 -0500 (EST)
Resent-Message-Id: <200302262209.h1QM9xk04725@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1QM9qI04659
	for <w3c-dist-auth@frink.w3.org>; Wed, 26 Feb 2003 17:09:52 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA19618
	for <w3c-dist-auth@w3c.org>; Wed, 26 Feb 2003 17:09:47 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18o9kI-0004cy-00; Wed, 26 Feb 2003 22:09:46 +0000
Received: from [198.144.203.248] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18o9kH-0004cn-00; Wed, 26 Feb 2003 22:09:46 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Jason Crawford'" <nn683849@smallcue.com>,
        "'Julian Reschke'" <julian.reschke@gmx.de>
Cc: "'Clemm, Geoff'" <gclemm@Rational.Com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Wed, 26 Feb 2003 14:09:45 -0800
Message-ID: <012101c2dde3$c5c14e90$f8cb90c6@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.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <OF1B715D34.19E10086-ON85256CD9.00705E8B@us.ibm.com>
Old-X-Envelope-To: gclemm@Rational.Com,
 julian.reschke@gmx.de,
 nn683849@smallcue.com,
 w3c-dist-auth@w3c.org
Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
X-Archived-At: http://www.w3.org/mid/012101c2dde3$c5c14e90$f8cb90c6@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7275
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


> Let's use the SHOULD and let implementers understand why they SHOULD
> implement strong Etags.  Let the implementers weigh the 
> "difficulty" case
> against the benefit case themselves.   And let's let the 
> implementors that
> don't follow through on the SHOULD know if they are impacting 
> us as users
> and if we're tempted to use a different product.  I know that 
> user feedback
> is a strong motivator for most software developers.

OK, this is actually very related to an argument in favour of "MUST
support strong ETags".  Unless it is a requirement of servers, clients
simply won't implement it. And if clients (and client libraries) don't
implement it, users and even many developers don't have the choice. 

It's a chicken/egg problem, too.  Server implementors won't take the
pains to implement ETags because they know most existing clients ignore
ETags.  How do we exit from this vicious circle?

Lisa




From w3c-dist-auth-request@w3.org  Wed Feb 26 17:26:21 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29817
	for <webdav-archive@lists.ietf.org>; Wed, 26 Feb 2003 17:26:21 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1QMT7n08874;
	Wed, 26 Feb 2003 17:29:07 -0500 (EST)
Resent-Date: Wed, 26 Feb 2003 17:29:07 -0500 (EST)
Resent-Message-Id: <200302262229.h1QMT7n08874@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1QMT5I08840
	for <w3c-dist-auth@frink.w3.org>; Wed, 26 Feb 2003 17:29:05 -0500 (EST)
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 RAA27967
	for <w3c-dist-auth@w3c.org>; Wed, 26 Feb 2003 17:29:04 -0500
Received: (qmail 25279 invoked by uid 0); 26 Feb 2003 22:28:33 -0000
Received: from p3EE2473A.dip.t-dialin.net (HELO lisa) (62.226.71.58)
  by mail.gmx.net (mp022-rz3) with SMTP; 26 Feb 2003 22:28:33 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Lisa Dusseault" <lisa@xythos.com>,
        "'Jason Crawford'" <nn683849@smallcue.com>,
        "'Julian Reschke'" <julian.reschke@gmx.de>
Cc: "'Clemm, Geoff'" <gclemm@Rational.Com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Wed, 26 Feb 2003 23:28:30 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCAEJIGJAA.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.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <012101c2dde3$c5c14e90$f8cb90c6@xythoslap>
Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEJIGJAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7276
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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, February 26, 2003 11:10 PM
> To: 'Jason Crawford'; 'Julian Reschke'
> Cc: 'Clemm, Geoff'; 'Webdav WG'
> Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
>
>
>
> > Let's use the SHOULD and let implementers understand why they SHOULD
> > implement strong Etags.  Let the implementers weigh the  "difficulty"
case
> > against the benefit case themselves.   And let's let the  implementors
that
> > don't follow through on the SHOULD know if they are impacting  us as
users
> > and if we're tempted to use a different product.  I know that  user
feedback
> > is a strong motivator for most software developers.
>
> OK, this is actually very related to an argument in favour of "MUST
> support strong ETags".  Unless it is a requirement of servers, clients
> simply won't implement it. And if clients (and client libraries) don't
> implement it, users and even many developers don't have the choice.

I really really have little sympathy for this statement. Clients can *right
now* detect whether the remote server has strong etags. Some servers do not
have them, some offer them after a delay after PUT (IIS, Apache), others
support them always for specific backends (let's assume this applies to
Slide/Tamino, SAP and Xythos).

If a client decides *not* to take advantage of the strong etag just because
it will have to take into account the case that the strong etag  *isn't*
available, then it's really not the spec's or the server implementor's
fault. Handling a GET/modify/PUT sequence well in both cases really isn't
rocket science:

1) LOCK the resource.
2) GET the resource. If it comes with a strong etag, remember it.
3) Let the user modify the resource.
4) Do a PUT with If header, supplying lock token and optionally the etag
when it was present in step 1.
5) UNLOCK.

If this really is too complicated, I don't see how we can help the client
programmer. Note that the only conditional code appears in step 4 and may be
a single line statement such as:

if (etag != null)  addEntityTagCondition(ifheader, uri, etag);

> It's a chicken/egg problem, too.  Server implementors won't take the
> pains to implement ETags because they know most existing clients ignore
> ETags.  How do we exit from this vicious circle?

That's really an interesting claim. Can you prove it?

As far as I can tell, servers really do their best to come up with strong
etags, but if they can't do it reliably, they don't (which clearly is better
than claiming strong etag support when it doesn't work). I suggest you get
the source code for moddav and try to appreciate how much effort was put
into creating strong etags when feasible, and to fallback to weak ones when
it isn't.

Speaking of clients: does the Xythos WebDAV client take advantage of entitiy
tags?

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



From w3c-dist-auth-request@w3.org  Wed Feb 26 17:48:41 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00449
	for <webdav-archive@lists.ietf.org>; Wed, 26 Feb 2003 17:48:40 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1QMpLS13558;
	Wed, 26 Feb 2003 17:51:21 -0500 (EST)
Resent-Date: Wed, 26 Feb 2003 17:51:21 -0500 (EST)
Resent-Message-Id: <200302262251.h1QMpLS13558@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1QMpKI13525
	for <w3c-dist-auth@frink.w3.org>; Wed, 26 Feb 2003 17:51:20 -0500 (EST)
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 RAA04154
	for <w3c-dist-auth@w3c.org>; Wed, 26 Feb 2003 17:51:19 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 26 Feb 2003 17:34:58 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <FKKQ3YK9>; Wed, 26 Feb 2003 17:50:47 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED6B5@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Wed, 26 Feb 2003 17:50:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Review of ordering draft, version 05
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6B5@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7277
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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:  Clemm, Geoff

   > > From:  Lisa Dusseault
   > > Are we possibly making things confusing by introducing a
   > > postcondition "code" like (DAV:ordering-type-set) for
   > > something that MUST be done?  It makes it seem like the
   > > server might choose not to set the ordering type, create the
   > > collection anyway, and respond with 409 containing
   > > <DAV:ordering-type-set/>.
   >
   > Whether or not a particular request may "partially succeed" is up
   > to the definition of that request.  Most RFC3253 methods are
   > defined to be atomic, i.e. they either succeed or they have no
   > effect on the server state.  The reason that multiple
   > postconditions are defined for an atomic operation is to allow
   > the server to give the client a more precise idea about which of
   > the semantics of the request could not be achieved (the client
   > can then use this information to give the user a better error
   > message).
   >
   > WRT to the specific example mentioned here, I agree that this
   > issue should be addressed by the ordering protocol, by having it
   > state whether the methods it is defining/extending are atomic, or
   > whether they are allowed to partially succeed.  I recommend that
   > they be required to be atomic.  ...

   Of course they are meant to be atomic. In fact, I don't agree that
   this needs to be clarified.

   RFC3253 says:

	   'A "postcondition" of a method describes the state of the
   server that must be true after that method has been completed.'

This implicitly meant "completed successfully".  If the method fails,
all bets are off.  By "partially succeed", I meant "made only some of
the changes that the postconditions require" (and therefore returns a
"failure" status).  An example of such a method is MOVE or DELETE on a
collection, which is allowed to move or delete some of the members
even if it fails (i.e. only "partially succeeds").

   Having a *set* of postconditions simply means that the state
   changes have been broken down into separate items, it does *not*
   mean that some of them are optional.

But without an explicit declaration of atomicity, a failure might
indicate "partial success" (i.e. some of the postconditions were
produced).

   The ordering spec uses the same structure as RFC3253 here, and
   RFC3253 doesn't seem to use the term "atomic" anywhere when
   specifying multiple postconditions. So if this really is an issue,
   I think it applies to all specs using this terminology, not only
   the ordering spec.

There were various debates about what "atomic" means, so the terminology
used in RFC3253 to indicate atomicity is:

"If an XXX request fails, the server state preceding the request MUST
 be restored."

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Wed Feb 26 18:37:21 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02808
	for <webdav-archive@lists.ietf.org>; Wed, 26 Feb 2003 18:37:21 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1QNeQe19186;
	Wed, 26 Feb 2003 18:40:26 -0500 (EST)
Resent-Date: Wed, 26 Feb 2003 18:40:26 -0500 (EST)
Resent-Message-Id: <200302262340.h1QNeQe19186@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1QNeOI19150
	for <w3c-dist-auth@frink.w3.org>; Wed, 26 Feb 2003 18:40:24 -0500 (EST)
Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA20499
	for <w3c-dist-auth@w3c.org>; Wed, 26 Feb 2003 18:40:23 -0500
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id PAA23013 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Wed, 26 Feb 2003 15:40:20 -0800
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 PAA22997 sender obsfucated@us.ibm.com; Wed, 26 Feb 2003 15:40:18 -0800
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1QNdhJn035624; Wed, 26 Feb 2003 18:39:43 -0500
Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1QNdelv051174; Wed, 26 Feb 2003 18:39:41 -0500
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <OF6A6396CB.3234DAC8-ON85256CD9.007FB739@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Wed, 26 Feb 2003 18:36:26 -0500
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|February 24, 2003) at 02/26/2003 18:39:40
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
X-Archived-At: http://www.w3.org/mid/OF6A6396CB.3234DAC8-ON85256CD9.007FB739@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7278
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>





Again, I agree with Julian.  This doesn't look like chicken/egg problem to
me.   The check doesn't appear to be difficult/expensive for most clients
and it's definitely valuable.

If there is no reason for a client to believe that checking the etag will
create a breakage or incompatibility, clients will implement etag checking.



------------------------------------------
Phone: 914-784-7569,   ccjason@us.ibm.com
I do not check nn621779@smallcue.com



From w3c-dist-auth-request@w3.org  Wed Feb 26 18:47:19 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03010
	for <webdav-archive@lists.ietf.org>; Wed, 26 Feb 2003 18:47:18 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1QNjYd19706;
	Wed, 26 Feb 2003 18:45:34 -0500 (EST)
Resent-Date: Wed, 26 Feb 2003 18:45:34 -0500 (EST)
Resent-Message-Id: <200302262345.h1QNjYd19706@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1QNjXI19674
	for <w3c-dist-auth@frink.w3.org>; Wed, 26 Feb 2003 18:45:33 -0500 (EST)
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 SAA21884
	for <w3c-dist-auth@w3c.org>; Wed, 26 Feb 2003 18:45:33 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 26 Feb 2003 18:29:09 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <FKKQ35WP>; Wed, 26 Feb 2003 18:44:44 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED6B6@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Wed, 26 Feb 2003 18:44:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6B6@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7279
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 I agree with both Jason and Julian.

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:nn683849@smallcue.com]


Again, I agree with Julian.  This doesn't look like chicken/egg problem to
me.   The check doesn't appear to be difficult/expensive for most clients
and it's definitely valuable.

If there is no reason for a client to believe that checking the etag will
create a breakage or incompatibility, clients will implement etag checking.



From w3c-dist-auth-request@w3.org  Thu Feb 27 02:49:46 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21912
	for <webdav-archive@lists.ietf.org>; Thu, 27 Feb 2003 02:49:46 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1R7qmB09085;
	Thu, 27 Feb 2003 02:52:48 -0500 (EST)
Resent-Date: Thu, 27 Feb 2003 02:52:48 -0500 (EST)
Resent-Message-Id: <200302270752.h1R7qmB09085@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1R7qkI09051
	for <w3c-dist-auth@frink.w3.org>; Thu, 27 Feb 2003 02:52:46 -0500 (EST)
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 CAA32661
	for <w3c-dist-auth@w3c.org>; Thu, 27 Feb 2003 02:52:46 -0500
Received: (qmail 3313 invoked by uid 0); 27 Feb 2003 07:52:05 -0000
Received: from p3EE2473A.dip.t-dialin.net (HELO lisa) (62.226.71.58)
  by mail.gmx.net (mp017-rz3) with SMTP; 27 Feb 2003 07:52:05 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Clemm, Geoff" <gclemm@rational.com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Thu, 27 Feb 2003 08:51:39 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCIEKIGJAA.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.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED6B5@SUS-MA1IT01>
Subject: RE: Review of ordering draft, version 05
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEKIGJAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7280
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 Clemm, Geoff
> Sent: Wednesday, February 26, 2003 11:51 PM
> To: 'Webdav WG'
> Subject: RE: Review of ordering draft, version 05
>
>
>
> ...
>
>    Of course they are meant to be atomic. In fact, I don't agree that
>    this needs to be clarified.
>
>    RFC3253 says:
>
> 	   'A "postcondition" of a method describes the state of the
>    server that must be true after that method has been completed.'
>
> This implicitly meant "completed successfully".  If the method fails,
> all bets are off.  By "partially succeed", I meant "made only some of
> the changes that the postconditions require" (and therefore returns a
> "failure" status).  An example of such a method is MOVE or DELETE on a
> collection, which is allowed to move or delete some of the members
> even if it fails (i.e. only "partially succeeds").
>
>    Having a *set* of postconditions simply means that the state
>    changes have been broken down into separate items, it does *not*
>    mean that some of them are optional.
>
> But without an explicit declaration of atomicity, a failure might
> indicate "partial success" (i.e. some of the postconditions were
> produced).

Well, in the case of an internal server error, obviously this may happen.
There are simply kinds of errors that are outside the control of the WebDAV
code handler, such as database connections going down, file system
corruption, manual operator intervention and so on... So even if the spec
mandates atomicity, a client really can't reliably assume what specifically
went wrong when he gets a 500 status, right?

>    The ordering spec uses the same structure as RFC3253 here, and
>    RFC3253 doesn't seem to use the term "atomic" anywhere when
>    specifying multiple postconditions. So if this really is an issue,
>    I think it applies to all specs using this terminology, not only
>    the ordering spec.
>
> There were various debates about what "atomic" means, so the terminology
> used in RFC3253 to indicate atomicity is:
>
> "If an XXX request fails, the server state preceding the request MUST
>  be restored."

I see. So I'd propose to simply add this very sentence to the ORDERPATCH
method description in the final editing pass.

Are we done now? :-)

Julian

P.S.: why doesn't the BIND spec include this magic sentence? Just because
there's only a single postcondition defined for BIND?

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



From w3c-dist-auth-request@w3.org  Thu Feb 27 04:01:30 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23242
	for <webdav-archive@lists.ietf.org>; Thu, 27 Feb 2003 04:01:30 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1R94dj20549;
	Thu, 27 Feb 2003 04:04:39 -0500 (EST)
Resent-Date: Thu, 27 Feb 2003 04:04:39 -0500 (EST)
Resent-Message-Id: <200302270904.h1R94dj20549@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1R94aI20515
	for <w3c-dist-auth@frink.w3.org>; Thu, 27 Feb 2003 04:04:36 -0500 (EST)
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 EAA13304
	for <w3c-dist-auth@w3c.org>; Thu, 27 Feb 2003 04:04:34 -0500
Received: from greenbytes.de ([192.168.1.23])
	by greenbytes.de ([217.5.201.11])
	with SMTP (MDaemon.PRO.v6.7.0.R)
	for <w3c-dist-auth@w3c.org>; Thu, 27 Feb 2003 10:04:14 +0100
Date: Thu, 27 Feb 2003 10:04:27 +0100
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
From: Stefan Eissing <stefan.eissing@greenbytes.de>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Content-Transfer-Encoding: 7bit
In-Reply-To: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED6B6@SUS-MA1IT01>
Message-Id: <7970DBE8-4A32-11D7-AB35-00039384827E@greenbytes.de>
X-Mailer: Apple Mail (2.551)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: RFC2518 issue: requiring ETags (Atlanta wg mtg)
X-Archived-At: http://www.w3.org/mid/7970DBE8-4A32-11D7-AB35-00039384827E@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7281
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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, again, agree with Geoff, Jason and Julian.

//Stefan

Am Donnerstag, 27.02.03, um 00:44 Uhr (Europe/Berlin) schrieb Clemm, 
Geoff:

>
> And I agree with both Jason and Julian.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Jason Crawford [mailto:nn683849@smallcue.com]
>
>
> Again, I agree with Julian.  This doesn't look like chicken/egg 
> problem to
> me.   The check doesn't appear to be difficult/expensive for most 
> clients
> and it's definitely valuable.
>
> If there is no reason for a client to believe that checking the etag 
> will
> create a breakage or incompatibility, clients will implement etag 
> checking.
>




From w3c-dist-auth-request@w3.org  Thu Feb 27 08:33:57 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01397
	for <webdav-archive@lists.ietf.org>; Thu, 27 Feb 2003 08:33:57 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1RDTSo01848;
	Thu, 27 Feb 2003 08:29:28 -0500 (EST)
Resent-Date: Thu, 27 Feb 2003 08:29:28 -0500 (EST)
Resent-Message-Id: <200302271329.h1RDTSo01848@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1RDTOI01812
	for <w3c-dist-auth@frink.w3.org>; Thu, 27 Feb 2003 08:29:24 -0500 (EST)
Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA19742
	for <w3c-dist-auth@w3c.org>; Thu, 27 Feb 2003 08:29:24 -0500
Received: from user-1120irj.dsl.mindspring.com ([66.32.75.115] helo=[192.168.1.7])
	by grebe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 18oO6B-00074t-00
	for w3c-dist-auth@w3c.org; Thu, 27 Feb 2003 05:29:19 -0800
Mime-Version: 1.0
X-Sender: desoi@icx.net@mailhub.icx.net
Message-Id: <p05200f03ba83c141c084@[192.168.1.7]>
In-Reply-To: <OF1B715D34.19E10086-ON85256CD9.00705E8B@us.ibm.com>
References: <OF1B715D34.19E10086-ON85256CD9.00705E8B@us.ibm.com>
Date: Thu, 27 Feb 2003 08:26:09 -0500
To: w3c-dist-auth@w3c.org
From: John DeSoi <desoi@icx.net>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
X-Archived-At: http://www.w3.org/mid/p05200f03ba83c141c084@[192.168.1.7]
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7282
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 3:34 PM -0500 2/26/03, Jason Crawford wrote:
>Let's use the SHOULD and let implementers understand why they SHOULD
>implement strong Etags.  Let the implementers weigh the "difficulty" case
>against the benefit case themselves.   And let's let the implementors that
>don't follow through on the SHOULD know if they are impacting us as users
>and if we're tempted to use a different product.  I know that user feedback
>is a strong motivator for most software developers.

Further: There is more than one way to implement locking. My server 
already had a locking mechanism, so I had no desire to implement 
WebDAV locking at all. I just wanted a few features to make it easier 
for users to upload files. But then I got sucked into it because OS X 
refused to allow writes without locking. I found the locking part of 
WebDAV to be the most complex and problematic part to implement. At 
times it made me wish I had taken another approach.

Best,

John DeSoi, Ph.D.



From w3c-dist-auth-request@w3.org  Thu Feb 27 08:51:38 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02754
	for <webdav-archive@lists.ietf.org>; Thu, 27 Feb 2003 08:51:37 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1RDl3d05969;
	Thu, 27 Feb 2003 08:47:03 -0500 (EST)
Resent-Date: Thu, 27 Feb 2003 08:47:03 -0500 (EST)
Resent-Message-Id: <200302271347.h1RDl3d05969@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1RDl1I05936
	for <w3c-dist-auth@frink.w3.org>; Thu, 27 Feb 2003 08:47:01 -0500 (EST)
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 IAA27553
	for <w3c-dist-auth@w3c.org>; Thu, 27 Feb 2003 08:47:01 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 27 Feb 2003 08:30:31 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <FKKQPW00>; Thu, 27 Feb 2003 08:45:28 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE201FC3DA2@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Thu, 27 Feb 2003 08:45:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Review of ordering draft, version 05
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE201FC3DA2@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7283
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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: Clemm, Geoff
   > But without an explicit declaration of atomicity, a failure might
   > indicate "partial success" (i.e. some of the postconditions were
   > produced).

   Well, in the case of an internal server error, obviously this may
   happen.  There are simply kinds of errors that are outside the
   control of the WebDAV code handler, such as database connections
   going down, file system corruption, manual operator intervention
   and so on... So even if the spec mandates atomicity, a client
   really can't reliably assume what specifically went wrong when he
   gets a 500 status, right?

That's where the separate post-conditions come in handy.  A server
can return all the post-conditions that failed in the DAV:error node,
which gives the client an indication of what kind of things failed.

   >    The ordering spec uses the same structure as RFC3253 here, and
   >    RFC3253 doesn't seem to use the term "atomic" anywhere when
   >    specifying multiple postconditions. So if this really is an issue,
   >    I think it applies to all specs using this terminology, not only
   >    the ordering spec.
   >
   > There were various debates about what "atomic" means, so the
terminology
   > used in RFC3253 to indicate atomicity is:
   >
   > "If an XXX request fails, the server state preceding the request MUST
   >  be restored."

   I see. So I'd propose to simply add this very sentence to the ORDERPATCH
   method description in the final editing pass.

Works for me.

   Are we done now? :-)

I hope so (:-).

   P.S.: why doesn't the BIND spec include this magic sentence? Just because
   there's only a single postcondition defined for BIND?

Yup.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Thu Feb 27 13:56:53 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16923
	for <webdav-archive@lists.ietf.org>; Thu, 27 Feb 2003 13:56:53 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1RIxrn15697;
	Thu, 27 Feb 2003 13:59:53 -0500 (EST)
Resent-Date: Thu, 27 Feb 2003 13:59:53 -0500 (EST)
Resent-Message-Id: <200302271859.h1RIxrn15697@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1RIxnI15661
	for <w3c-dist-auth@frink.w3.org>; Thu, 27 Feb 2003 13:59:49 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA07220
	for <w3c-dist-auth@w3c.org>; Thu, 27 Feb 2003 13:59:49 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18oTFz-00058P-00; Thu, 27 Feb 2003 18:59:47 +0000
Received: from [216.36.77.241] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18oTFz-00058E-00; Thu, 27 Feb 2003 18:59:47 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Stefan Eissing'" <stefan.eissing@greenbytes.de>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Thu, 27 Feb 2003 10:59:48 -0800
Message-ID: <025d01c2de92$6659ae20$f8cb90c6@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.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <7970DBE8-4A32-11D7-AB35-00039384827E@greenbytes.de>
Old-X-Envelope-To: stefan.eissing@greenbytes.de,
 w3c-dist-auth@w3c.org
Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
X-Archived-At: http://www.w3.org/mid/025d01c2de92$6659ae20$f8cb90c6@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7284
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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, thanks all for the input.  This will be in rfc2518 bis as SHOULD
support strong Etags, with arguments supporting.

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Stefan Eissing
> Sent: Thursday, February 27, 2003 1:04 AM
> To: 'Webdav WG'
> Subject: Re: RFC2518 issue: requiring ETags (Atlanta wg mtg)
> 
> 
> 
> I, again, agree with Geoff, Jason and Julian.
> 
> //Stefan
> 
> Am Donnerstag, 27.02.03, um 00:44 Uhr (Europe/Berlin) schrieb Clemm, 
> Geoff:
> 
> >
> > And I agree with both Jason and Julian.
> >
> > Cheers,
> > Geoff
> >
> > -----Original Message-----
> > From: Jason Crawford [mailto:nn683849@smallcue.com]
> >
> >
> > Again, I agree with Julian.  This doesn't look like chicken/egg 
> > problem to
> > me.   The check doesn't appear to be difficult/expensive for most 
> > clients
> > and it's definitely valuable.
> >
> > If there is no reason for a client to believe that checking 
> the etag 
> > will
> > create a breakage or incompatibility, clients will implement etag 
> > checking.
> >
> 
> 
> 




From w3c-dist-auth-request@w3.org  Fri Feb 28 15:11:39 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12052
	for <webdav-archive@lists.ietf.org>; Fri, 28 Feb 2003 15:11:39 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1SKDKE09464;
	Fri, 28 Feb 2003 15:13:20 -0500 (EST)
Resent-Date: Fri, 28 Feb 2003 15:13:20 -0500 (EST)
Resent-Message-Id: <200302282013.h1SKDKE09464@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1SKDGI09384
	for <w3c-dist-auth@frink.w3.org>; Fri, 28 Feb 2003 15:13:16 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA23251
	for <w3c-dist-auth@w3c.org>; Fri, 28 Feb 2003 15:13:16 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18oqsZ-0005SK-00; Fri, 28 Feb 2003 20:13:11 +0000
Received: from [216.36.77.241] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18oqsZ-0005S9-00; Fri, 28 Feb 2003 20:13:11 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Lisa Dusseault'" <lisa@xythos.com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Fri, 28 Feb 2003 12:13:12 -0800
Message-ID: <03a801c2df65$d1cc3ff0$f8cb90c6@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.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <013301c25f44$905f3a50$b701a8c0@xythoslap>
Old-X-Envelope-To: lisa@xythos.com,
 w3c-dist-auth@w3c.org
Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
X-Archived-At: http://www.w3.org/mid/03a801c2df65$d1cc3ff0$f8cb90c6@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7285
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 issue of whether it's OK to define RFC2518bis such that servers that
were compliant with 2518 have to make changes to become compliant with
2518bis came up again last week. Therefore, I thought I'd repost this
message from last year.

We are already putting requirements in 2518bis such that servers that
were compliant with 2518 must upgrade to be compliant with 2518bis.
That's OK, particularly when the spec becomes more stringent, not less.
Greater stringency should increase the number of features and behaviors
that clients can rely on and use interoperably without so many if-elses.


Lisa

> -----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 11:53 AM
> 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
> 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  Fri Feb 28 17:03:46 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14741
	for <webdav-archive@lists.ietf.org>; Fri, 28 Feb 2003 17:03:46 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1SM3tV27833;
	Fri, 28 Feb 2003 17:03:55 -0500 (EST)
Resent-Date: Fri, 28 Feb 2003 17:03:55 -0500 (EST)
Resent-Message-Id: <200302282203.h1SM3tV27833@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1SM3sI27801
	for <w3c-dist-auth@frink.w3.org>; Fri, 28 Feb 2003 17:03:54 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA28218
	for <w3c-dist-auth@w3.org>; Fri, 28 Feb 2003 17:03:53 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18osbg-0007dP-00; Fri, 28 Feb 2003 22:03:52 +0000
Received: from [216.36.77.241] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18osbg-0007dE-00; Fri, 28 Feb 2003 22:03:52 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Jim Luther'" <luther.j@apple.com>, <w3c-dist-auth@w3.org>
Date: Fri, 28 Feb 2003 14:03:53 -0800
Message-ID: <03b101c2df75$4842f2f0$f8cb90c6@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.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <5C84BAA8-C02A-11D6-B386-0003934B6A22@apple.com>
Old-X-Envelope-To: luther.j@apple.com,
 w3c-dist-auth@w3.org
Subject: RE: Interoperability for DAV:ishidden?
X-Archived-At: http://www.w3.org/mid/03b101c2df75$4842f2f0$f8cb90c6@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7286
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


Since this discussion last year, I haven't heard of anybody supporting
"ishidden" and show interop. At a minimum, only one other organization
needs to do so, and then show that both their server and IIS 5.0 work
with Web Folders to hide resources (if Web Folders in fact does this).
I'd take a trace and a screenshot as "proof" and put this into
RFC2518bis.  In the absence of proof, I'm not planning to add more
properties.

Lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Jim Luther
> Sent: Wednesday, September 04, 2002 10:19 AM
> To: w3c-dist-auth@w3.org
> 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  Fri Feb 28 17:38:29 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15505
	for <webdav-archive@lists.ietf.org>; Fri, 28 Feb 2003 17:38:28 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1SMdZY05981;
	Fri, 28 Feb 2003 17:39:35 -0500 (EST)
Resent-Date: Fri, 28 Feb 2003 17:39:35 -0500 (EST)
Resent-Message-Id: <200302282239.h1SMdZY05981@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1SMdXI05949
	for <w3c-dist-auth@frink.w3.org>; Fri, 28 Feb 2003 17:39:33 -0500 (EST)
Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA07207
	for <w3c-dist-auth@w3.org>; Fri, 28 Feb 2003 17:39:32 -0500
Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196])
	by ucsc.edu (8.10.1/8.10.1) with SMTP id h1SMdAY00395
	for <w3c-dist-auth@w3.org>; Fri, 28 Feb 2003 14:39:10 -0800 (PST)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "WebDAV" <w3c-dist-auth@w3.org>
Date: Fri, 28 Feb 2003 14:36:23 -0800
Message-ID: <AMEPKEBLDJJCCDEJHAMIEEIOGIAA.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
X-UCSC-CATS-MailScanner: Found to be clean
Subject: FW: ETags again - basic question
X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIEEIOGIAA.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7287
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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: news [mailto:news@main.gmane.org]On Behalf Of Oliver Geisser
Sent: Friday, February 28, 2003 8:31 AM
To: w3c-dist-auth@w3.org
Subject: [Moderator Action] ETags again - basic question




Hi,

I think I know the answer but to make me sure:

When does an (strong) etag of a resource change?

1) when the content of a resource has changed (e.g. after a PUT)
2) when one of the properties has changed (e.g. after a PROPPATCH)
3) in both cases 1) and 2)

Thanks, Olli

-og



From w3c-dist-auth-request@w3.org  Fri Feb 28 17:47:31 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15681
	for <webdav-archive@lists.ietf.org>; Fri, 28 Feb 2003 17:47:31 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1SMmVw08491;
	Fri, 28 Feb 2003 17:48:31 -0500 (EST)
Resent-Date: Fri, 28 Feb 2003 17:48:31 -0500 (EST)
Resent-Message-Id: <200302282248.h1SMmVw08491@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1SMmTI08432
	for <w3c-dist-auth@frink.w3.org>; Fri, 28 Feb 2003 17:48:29 -0500 (EST)
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 RAA10461
	for <w3c-dist-auth@w3.org>; Fri, 28 Feb 2003 17:48:28 -0500
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225])
	by mail-out1.apple.com (8.12.3/8.12.3) with ESMTP id h1SMmRg7021871
	for <w3c-dist-auth@w3.org>; Fri, 28 Feb 2003 14:48:27 -0800 (PST)
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T60b1506024118064e155c@mailgate1.apple.com> for <w3c-dist-auth@w3.org>;
 Fri, 28 Feb 2003 14:48:15 -0800
Received: from apple.com (luthji.apple.com [17.202.43.76])
	by scv1.apple.com (8.11.3/8.11.3) with ESMTP id h1SMmGs24836
	for <w3c-dist-auth@w3.org>; Fri, 28 Feb 2003 14:48:16 -0800 (PST)
Date: Fri, 28 Feb 2003 14:48:13 -0800
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
From: Jim Luther <luther.j@apple.com>
To: w3c-dist-auth@w3.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <03b101c2df75$4842f2f0$f8cb90c6@xythoslap>
Message-Id: <B8184F32-4B6E-11D7-BB1F-0003934B6A22@apple.com>
X-Mailer: Apple Mail (2.551)
Subject: Re: Interoperability for DAV:ishidden?
X-Archived-At: http://www.w3.org/mid/B8184F32-4B6E-11D7-BB1F-0003934B6A22@apple.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7288
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 doubt that we'll end up doing anything with the ishidden property 
based on our experience with other network file systems Apple ships. 
We've found that setting the hidden attribute on files our OS thinks 
should be hidden, but that other operating systems do not think should 
be hidden, creates some new user interface interoperability problems 
while solving others.

So, we won't be supplying your proof.

- Jim

On Friday, February 28, 2003, at 02:03  PM, Lisa Dusseault wrote:

> Since this discussion last year, I haven't heard of anybody supporting
> "ishidden" and show interop. At a minimum, only one other organization
> needs to do so, and then show that both their server and IIS 5.0 work
> with Web Folders to hide resources (if Web Folders in fact does this).
> I'd take a trace and a screenshot as "proof" and put this into
> RFC2518bis.  In the absence of proof, I'm not planning to add more
> properties.
>
> Lisa
>
>> -----Original Message-----
>> From: w3c-dist-auth-request@w3.org
>> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Jim Luther
>> Sent: Wednesday, September 04, 2002 10:19 AM
>> To: w3c-dist-auth@w3.org
>> 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  Fri Feb 28 18:31:07 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17124
	for <webdav-archive@lists.ietf.org>; Fri, 28 Feb 2003 18:31:07 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1SNW6M14666;
	Fri, 28 Feb 2003 18:32:06 -0500 (EST)
Resent-Date: Fri, 28 Feb 2003 18:32:06 -0500 (EST)
Resent-Message-Id: <200302282332.h1SNW6M14666@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1SNW4I14634
	for <w3c-dist-auth@frink.w3.org>; Fri, 28 Feb 2003 18:32:04 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA19065
	for <w3c-dist-auth@w3.org>; Fri, 28 Feb 2003 18:32:04 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18otz1-0000g1-00
	for w3c-dist-auth@w3.org; Fri, 28 Feb 2003 23:32:03 +0000
Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18otz0-0000fq-00
	for w3c-dist-auth@w3.org; Fri, 28 Feb 2003 23:32:02 +0000
Date: Fri, 28 Feb 2003 15:32:02 -0800
Mime-Version: 1.0 (Apple Message framework v551)
Content-Type: text/plain; charset=US-ASCII; format=flowed
From: Brian Korver <briank@xythos.com>
To: w3c-dist-auth@w3.org
Content-Transfer-Encoding: 7bit
Message-Id: <D6E0A2A8-4B74-11D7-96F5-000393751598@xythos.com>
X-Mailer: Apple Mail (2.551)
Old-X-Envelope-To: w3c-dist-auth@w3.org
Subject: bind draft: loops
X-Archived-At: http://www.w3.org/mid/D6E0A2A8-4B74-11D7-96F5-000393751598@xythos.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7289
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 wondering about the justification for permitting loops.
I looked in the archive, but except for the statement
that loops are required for versioning, I didn't notice
any reasons presented, although I may have missed
that.

-brian
briank@xythos.com




From w3c-dist-auth-request@w3.org  Fri Feb 28 18:40:21 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17288
	for <webdav-archive@lists.ietf.org>; Fri, 28 Feb 2003 18:40:20 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1SNfRa16206;
	Fri, 28 Feb 2003 18:41:27 -0500 (EST)
Resent-Date: Fri, 28 Feb 2003 18:41:27 -0500 (EST)
Resent-Message-Id: <200302282341.h1SNfRa16206@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1SNfPI16174
	for <w3c-dist-auth@frink.w3.org>; Fri, 28 Feb 2003 18:41:25 -0500 (EST)
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 SAA21154
	for <w3c-dist-auth@w3.org>; Fri, 28 Feb 2003 18:41:25 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 28 Feb 2003 18:24:53 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <FKKQS962>; Fri, 28 Feb 2003 18:40:48 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED6C0@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Fri, 28 Feb 2003 18:40:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: bind draft: loops
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6C0@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7290
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 versioning protocol ended up not using bindings for much,
so the real problem is that can be expensive to check whether or
not a loop has been created.  So we don't require it.

Cheers,
Geoff

-----Original Message-----
From: Brian Korver [mailto:briank@xythos.com]
Sent: Friday, February 28, 2003 6:32 PM
To: w3c-dist-auth@w3.org
Subject: bind draft: loops



I'm wondering about the justification for permitting loops.
I looked in the archive, but except for the statement
that loops are required for versioning, I didn't notice
any reasons presented, although I may have missed
that.

-brian
briank@xythos.com



From w3c-dist-auth-request@w3.org  Fri Feb 28 18:54:31 2003
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17462
	for <webdav-archive@lists.ietf.org>; Fri, 28 Feb 2003 18:54:31 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h1SNteu17900;
	Fri, 28 Feb 2003 18:55:40 -0500 (EST)
Resent-Date: Fri, 28 Feb 2003 18:55:40 -0500 (EST)
Resent-Message-Id: <200302282355.h1SNteu17900@frink.w3.org>
Received: from tux.w3.org (tux [18.29.0.27])
	by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h1SNtdI17867
	for <w3c-dist-auth@frink.w3.org>; Fri, 28 Feb 2003 18:55:39 -0500 (EST)
Received: from mail.xythos.com (ip-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA23248
	for <w3c-dist-auth@w3.org>; Fri, 28 Feb 2003 18:55:38 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18ouLp-00013J-00
	for w3c-dist-auth@w3.org; Fri, 28 Feb 2003 23:55:37 +0000
Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18ouLp-000137-00
	for w3c-dist-auth@w3.org; Fri, 28 Feb 2003 23:55:37 +0000
Date: Fri, 28 Feb 2003 15:55:36 -0800
Mime-Version: 1.0 (Apple Message framework v551)
Content-Type: text/plain; charset=US-ASCII; format=flowed
From: Brian Korver <briank@xythos.com>
To: WebDAV <w3c-dist-auth@w3.org>
Content-Transfer-Encoding: 7bit
Message-Id: <21D82D59-4B78-11D7-8A8F-000393751598@xythos.com>
X-Mailer: Apple Mail (2.551)
Old-X-Envelope-To: w3c-dist-auth@w3.org
Subject: bind draft issues
X-Archived-At: http://www.w3.org/mid/21D82D59-4B78-11D7-8A8F-000393751598@xythos.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7291
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 to bring up a couple of issues that I've found
with the bind draft.  I'll post more comprehensive comments
on the draft in a subsequent email.

Define "Resource"

The term "resource" should be defined in the draft.  I
imagine the definition is something along the lines of
"all content and all properties associated with that
content (including live and dead properties), but which
does not include properties associated with URIs."

Bindings and Locks

The relationship between bindings and locks is missing
from the draft.  I think the behavior of locks and the
lock methods should be fully specified in this draft.

URL Properties

The behavior of other URL properties (in addition to
locks) should be fully specified, for instance the
display-name property.

Move and Delete

The spec states that move and delete are merely operations
on bindings.  At the very least, this is inconsistent with
2518, but I also think that the draft doesn't adequately
address any of the issues that come up when the server
goes to "reclaim system resources."  I would expect most
servers to reclaim said resources during move and delete.

Operations not Atomic

None of the operations specified should be required
to be atomic.  I'd prefer SHOULD NOT myself.  This is
especially true for any operation that involves deleting
collections.

-brian
briank@xythos.com