From w3c-dist-auth-request@w3.org  Wed Jan  8 12:19: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 MAA26126
	for <webdav-archive@lists.ietf.org>; Wed, 8 Jan 2003 12:19:10 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h08HKN218573;
	Wed, 8 Jan 2003 12:20:23 -0500 (EST)
Resent-Date: Wed, 8 Jan 2003 12:20:23 -0500 (EST)
Resent-Message-Id: <200301081720.h08HKN218573@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 h08HKMD18509
	for <w3c-dist-auth@frink.w3.org>; Wed, 8 Jan 2003 12:20:22 -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 MAA31081
	for <w3c-dist-auth@w3.org>; Wed, 8 Jan 2003 12:20:20 -0500
Received: (qmail 27020 invoked by uid 0); 8 Jan 2003 17:19:48 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp010-rz3) with SMTP; 8 Jan 2003 17:19:48 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "WebDAV" <w3c-dist-auth@w3.org>
Date: Wed, 8 Jan 2003 18:19:48 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCKEBLGCAA.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
In-Reply-To: <AMEPKEBLDJJCCDEJHAMIAEPGGAAA.ejw@cse.ucsc.edu>
Importance: Normal
Subject: draft-ietf-webdav-ordering-protocol-04
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEBLGCAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7091
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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'm in the process of finishing my edits on the ordered collections draft
([1]). The main changes are clarifications, rewriting of marshalling
sections DeltaV-style, and a new section on the relation between ordered
collections and version-controlled collections.

Feedback appreciated.

BTW: is anybody except ourselves currently implementing this protocol
extension?

Regards, Julian


[1]
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-latest
.html>
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Mon Jan 13 10:48: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 KAA14246
	for <webdav-archive@lists.ietf.org>; Mon, 13 Jan 2003 10:48:35 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0DFnTf11828;
	Mon, 13 Jan 2003 10:49:29 -0500 (EST)
Resent-Date: Mon, 13 Jan 2003 10:49:29 -0500 (EST)
Resent-Message-Id: <200301131549.h0DFnTf11828@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 h0DFnSD11792
	for <w3c-dist-auth@frink.w3.org>; Mon, 13 Jan 2003 10:49:28 -0500 (EST)
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA15132
	for <w3c-dist-auth@w3.org>; Mon, 13 Jan 2003 10:49:06 -0500
Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225])
	by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id h0DFn5I14611
	for <w3c-dist-auth@w3.org>; Mon, 13 Jan 2003 07:49:05 -0800 (PST)
Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5fc2ec1730118164e13c0@mailgate2.apple.com> for <w3c-dist-auth@w3.org>;
 Mon, 13 Jan 2003 07:49:05 -0800
Received: from apple.com (luthji.apple.com [17.202.43.76])
	by scv3.apple.com (8.11.3/8.11.3) with ESMTP id h0DFn5f15535
	for <w3c-dist-auth@w3.org>; Mon, 13 Jan 2003 07:49:05 -0800 (PST)
Date: Mon, 13 Jan 2003 07:48:24 -0800
Content-Type: multipart/mixed; boundary=Apple-Mail-10--258805288
Mime-Version: 1.0 (Apple Message framework v551)
From: Jim Luther <luther.j@apple.com>
To: w3c-dist-auth@w3.org
In-Reply-To: <A1DC71A2-13B7-11D7-926B-0003934B6A22@apple.com>
Message-Id: <72E2905A-270E-11D7-A492-0003934B6A22@apple.com>
X-Mailer: Apple Mail (2.551)
Subject: Last reminder to RSVP for the Interim WEBDAV WG meeting
X-Archived-At: http://www.w3.org/mid/72E2905A-270E-11D7-A492-0003934B6A22@apple.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7092
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>



--Apple-Mail-10--258805288
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed
Content-Transfer-Encoding: quoted-printable

Hello,

This is the last reminder to people planning to attend Interim WEBDAV=20
WG meeting in January to RSVP so visitor badges can be printed, and=20
refreshments and meals can be planned.

I've copied the details concerning the meeting and how to RSVP below.

- Jim

----------

WebDAV Working Group Interim Meeting

Dates
Monday, January 20 and Tuesday, January 21, 2003

Location
Apple Computer, Inc.
Singapore conference room
R&D Building 1, 1st floor
One Infinite Loop
Cupertino, CA 95014
The building is open to the conference room from 8:00 AM to 5:00 PM=20
Pacific time.

How to get to Apple's R&D campus
The Apple Computer R&D campus is located in Cupertino, California=20
immediately south of Interstate 280 on the east side of De Anza=20
Boulevard. Cupertino is 5 minutes west of San Jose and 45 minutes=20
southeast of San Francisco in the heart of Silicon Valley.

 =46rom Interstate 280, take De Anza Blvd south to Mariani Avenue (the=20=

first stoplight). Turn left onto Mariani Ave and then turn left again=20
onto Infinite Loop. Free parking will be on your left (park in either=20
of the large lots). R&D Building 1 is the building directly across from=20=

the parking lot.

(A map is attached to this message as a jpeg image)

FAQ

* Do I need to RSVP?

Yes, please RSVP at least 1 week before the meeting so visitor badges=20
can be printed, and refreshments and meals can be planned. To RSVP,=20
send email to Nora Mosqueda <mosqueda@apple.com> and let Nora know that=20=

you plan to attend the IETF WebDAV Working Group Interim Meeting=20
(include "WebDAV WG Interim Meeting" in the title of your email), what=20=

day(s) you will be attending, and if you have any dietary requirements=20=

we should be aware of.

* What food is being provided for attendees?

Refreshments will be provided during the morning and afternoon in the=20
meeting room. Lunches will be provided at Apple=92s cafeteria, Caff=E9=20=

Macs. Caff=E9 Macs provides restaurant-quality full-service menus with=20=

daily specials (including vegan and vegetarian menu choices). Apple is=20=

providing refreshments and lunches at no charge to attendees.

* What kind of network access will be available?

AirPort (IEEE 802.11b) wireless networking is available in the=20
conference room. If Ethernet access is required, please note that=20
requirement when you RSVP.

* Will my cell phone work at Apple?

Yes. There is good coverage from several major cell phone networks.

* Are there hotels close to the Apple campus?

Cypress Hotel - walking distance from the Apple campus.
10050 South DeAnza Boulevard
Cupertino, CA 950124
(408) 253-8900

Cupertino Inn - walking distance from the Apple campus.
10889 North DeAnza Blvd
Cupertino, CA 95014
(408) 996-7700

Courtyard by Marriott - requires car to get to the Apple campus
10605 N. Wolfe Road
Cupertino, CA 95014
(408) 252-9100

Hilton Garden Inn Cupertino - requires car to get to the Apple campus
10741 North Wolfe Road
Cupertino CA 95014
(408) 777-8787

WoodCrest Hotel - requires car to get to the Apple campus
5415 Stevens Creek Blvd.
Santa Clara, CA
(408) 446-9636

Moorpark Hotel - requ  ires car to get to the Apple campus
4241 Moorpark Avenue
San Jose CA 95129
(408) 864-0300

Wild Palms Hotel - requires car to get to the Apple campus
910 East Fremont Avenue
Sunnyvale, CA 94087
(408) 738-0500

Other area hotels within a short drive:
Wellesley Inn Santa Clara, Santa Clara, CA
Oakwood San Jose South, San Jose, CA
Best Western Inn & Suites, Sunnyvale, CA	=A0
Woodfin Suites Hotel Sunnyvale, Sunnyvale, CA
Corporate Inn Sunnyvale, Sunnyvale, CA	=A0
St. Francis Arms, Sunnyvale, CA	=A0
Maple Tree Inn, Sunnyvale, CA	=A0
Comfort Inn, Sunnyvale, CA	=A0
Quality Inn Civic Center, Sunnyvale, CA	=A0
Grand Hotel, Sunnyvale, CA


--Apple-Mail-10--258805288
Content-Disposition: inline;
	filename=applemap.jpg
Content-Type: image/jpeg;
	x-mac-creator=70727677;
	x-unix-mode=0644;
	x-mac-type=4A504547;
	name="applemap.jpg"
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEASABIAAD//gAMQXBwbGVNYXJrCv/bAIQABwUFBgUFBwYGBggHBwgKEQsK
CQkKFA8PDBEYFRkZFxUXFxodJSAaHCMcFxchLCEjJygqKioZHy4xLSkxJSkqKAEHCAgKCQoTCwsT
KBsXGygoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgo/8QB
ogAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoLAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJ
CgsQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJ
ChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeI
iYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq
8fLz9PX29/j5+hEAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMz
UvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3
eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna
4uPk5ebn6Onq8vP09fb3+Pn6/8AAEQgB3AGUAwEiAAIRAQMRAf/aAAwDAQACEQMRAD8A+ba3vDfg
zW/Fd59i0fTri9uMbjHCo+QHoXYkKgPqx/DmjwZ4buvFfiGx0ey2/aLyYRRlhkJwS0hHcIoLH8K+
iL6+vvhjqFx4Z8M3QtLC2EZ5giaSV2iQs7sVJZiSTz06DAAFAHBxfsueN7mNZBcaPZEjmK4vHdh+
KREfrT/+GVPHH/QV8P8A/gRP/wDGa+tqKAPkn/hlTxx/0FfD/wD4ET//ABmj/hlTxx/0FfD/AP4E
T/8AxmvraigD5J/4ZU8cf9BXw/8A+BE//wAZo/4ZU8cf9BXw/wD+BE//AMZr62ooA+Sf+GVPHH/Q
V8P/APgRP/8AGaP+GVPHH/QV8P8A/gRP/wDGa+tqKAPkn/hlTxx/0FfD/wD4ET//ABmj/hlTxx/0
FfD/AP4ET/8AxmvraigD5J/4ZU8cf9BXw/8A+BE//wAZo/4ZU8cf9BXw/wD+BE//AMZr62ooA+Sf
+GVPHH/QV8P/APgRP/8AGaP+GVPHH/QV8P8A/gRP/wDGa+tqKAPkn/hlTxx/0FfD/wD4ET//ABmj
/hlTxx/0FfD/AP4ET/8AxmvraigD5J/4ZU8cf9BXw/8A+BE//wAZo/4ZU8cf9BXw/wD+BE//AMZr
62ooA+Sf+GVPHH/QV8P/APgRP/8AGaP+GVPHH/QV8P8A/gRP/wDGa+tqKAPkn/hlTxx/0FfD/wD4
ET//ABmj/hlTxx/0FfD/AP4ET/8AxmvraigD5J/4ZU8cf9BXw/8A+BE//wAZo/4ZU8cf9BXw/wD+
BE//AMZr62ooA+Sf+GVPHH/QV8P/APgRP/8AGaP+GVPHH/QV8P8A/gRP/wDGa+tqKAPkn/hlTxx/
0FfD/wD4ET//ABmj/hlTxx/0FfD/AP4ET/8AxmvraigD5J/4ZU8cf9BXw/8A+BE//wAZo/4ZU8cf
9BXw/wD+BE//AMZr62ooA+Sf+GVPHH/QV8P/APgRP/8AGaP+GVPHH/QV8P8A/gRP/wDGa+tqKAPk
aX9lzxvbRtIbjR70gcRW946MfxeID9a8z8SeDNb8KXn2LWNOuLK4xuEcyj5wOpRgSrgeqn8OK/QW
sTxb4S0nxros+kavbiWGQZjkHEkD9nQ9mH/1jwTQB+e9Fb3jPw3deFPEN9o97t+0WcxikKjAfgFZ
AOwdSGH41g0AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHtX7LkSXPxBnEigm00yeeM+jM8K
H9Cfzrtvif8A8jxqf/bL/wBFJXGfsqf8lD1L/sDS/wDo+CvQvi9beR4t83H/AB8WscmfoSv/ALLQ
B7Xp1z9s0+0us58+FJPzUH+tWa5/wJc/a/B+kSZzttxH/wB8Er/7LXQUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHyN+1HElt8
QYBGoBu9MgnkPqyvMg/QD8q8Vr239qv/AJKHpv8A2Bov/R89eJUAFFFFABRRRQAUUUUAFFFFABRR
RQAUUUUAFFFFAHtv7Kn/ACUPUv8AsDS/+j4K9R+NO3+2tO/vfZTn6bzj+teXfsqf8lD1L/sDS/8A
o+CvRPjDP5viuOPP+ptEX82Y/wBaAPR/hkCPA+l5GP8AW/8Ao166usHwNB9n8IaQmMZtlf8A76+b
+tb1ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU
UUUAFFFFABRRRQB8k/tV/wDJQ9N/7A0X/o+evEq9t/ar/wCSh6b/ANgaL/0fPXiVABRRRQAUUUUA
FFFFABRRRQAUUUUAFFFFABRRRQB7b+yp/wAlD1L/ALA0v/o+Cux+JdyLrxpqRU5WMpGP+AooP65r
jv2VP+Sh6l/2Bpf/AEfBW9eMdd8UTFTk31+QuP8Abk4/nQB9F6LB9l0ewt8Y8q2jTH0UCrtAAAAA
wB0ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC
iiigAooooAKKKKAPkn9qv/koem/9gaL/ANHz14lXtv7Vf/JQ9N/7A0X/AKPnrxKgAooooAKKKKAC
iiigAooooAKKKKACiiigAooooA9f/ZvujY+KvEV2vWDw5cyD/gMkJ/pXdfD2z+2+MtKjIyElMp9t
ilh+oFee/s//APIb8V/9itef+hxV638HYVl8VzOw5isndfruRf5E0Ae40UUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHyT+1X
/wAlD03/ALA0X/o+evEq9t/ar/5KHpv/AGBov/R89eJUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFAHq/wCz/wD8hvxX/wBitef+hxV6/wDBj/kaLv8A68H/APRkdeQ/s/AnXPFYAyT4XvP/AEOK
vVfhFP5Xi9Uz/rraRP5N/wCy0Ae7UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHyT+1X/wAlD03/ALA0X/o+evEq9t/ar/5K
Hpv/AGBov/R89eJUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHsn7MsH2rxnrlvjPm+H7hM
fWWEV1fg/Vl0PxLp9+5AjSXbIT2RgVY/gCT+Fc7+yp/yUPUv+wNL/wCj4K6fxxo39heJ760VdsLP
5sPpsbkAfTkfhQB9H0VzPw/11de8M2khfdcW6iCcHruUYBP1GD+JrpqACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD5J/ar/AOSh
6b/2Bov/AEfPXiVe2/tV/wDJQ9N/7A0X/o+evEqACiiigAooooAKKKKACiiigAooooAKKKKACiii
gD239lT/AJKHqX/YGl/9HwV7b8YPDrXunwa3AuZLP93OAOTGTwfwJ/8AHj6V4l+yp/yUPUv+wNL/
AOj4K+sriCK6glt50EkUqFHQ9GUjBFAHgnw28Tf8I9r6RTvtsr3EU2Twp/hb8CcfQmvf6+avFfh2
fwzrM9jKrGLJaCQj/WRnofr2PuK9G+Gfj/7WsWhatL/pCjbazuf9YOyMf73oe/Tr1APT6KKKACiu
cvte1G91GfSfDltBLPbELd392T9ntWIBCbVw0smCDtBUAEZYEgHHljtW1Q6brXjTV5rvKq8dqhs7
aNiu4J5kSDaxXkK0pbGD3oA7uivPUj8HvaSXkWu+JVCGMY/tTUzK5kz5ZSJmJcNg4KqQcHGcGtSy
0/V3sodQ8OeK5b+2lXfHDq0KzRsPTeoSRT2+Ytg/w9qAOuorx7XPil4r0jUpdNu9IsrC5iAJRt0o
ZTnDo2QGU4ODgdCCAQQMaX4s+KZPu3FvF/uQL/XNAHvVFfPh+J/i8n/kLY/7dof/AIij/hZ3i/8A
6C//AJLQ/wDxFAH0HRXz5/ws/wAX/wDQX/8AJaH/AOIqeP4reK0+9eQyf71un9AKAPfKK8LX4v8A
iUdVsm+sJ/8Aiqa/xd8Tt0azT6Qf4mgD3aivA3+K3itul5Cn0t0/qKhb4oeLieNVC/S2i/8AiaAP
oKivn+P4o+LkOW1NZPZraL+iirkXxf8AE0f3hZS/78J/owoA90oryjTvjX0XU9J+slrJ/wCyt/8A
FV1enfEzwvqOB/aH2Vz/AAXSFMf8C+7+tAHVuwRGdmChQSWY8D3NeYeHNQ1aw1LRD4gv9Xt7u8JS
ad3iudM1JjE7DyWQ/uem9chchSDuzmvS4Z7e8hEkEsc8Ljho2DK34jisKy8CaBYyQtFbTyR2+fs9
tPeTSwW+VKny4mYovyswGBwCQMCgDmE+Kl19nvZP7LgndLJb228iaTy5FMqRlPMaMKx+dTuQsvX2
J6vw/rd/fXuq6fqtrbW11pzx5NrM0kbpIm5TllUgjkHjtnviq0Xw78NxBR9luZAsH2ZfNv7iTEQZ
WWMbnPygopA7Y9zndg020tr27vYottxebPPfcTv2DC8E4GAe1AHHeJPF0uj+IILm0f7dZy6MZYLe
OUCKeWS5giibcMgD9597nAJPNOvPG2taat5aXWjwyX9nNCs0tq0s1vHFKjsJWCxmTAZCpAU43KxI
BONS0+H3huyt7q2isZGhubcWrJLdTSCOEHIjj3MfKUHkBMYIGOgw9fAuiLa+QFvfM+0i6+1nUJzc
+aE2BvO37/uErjOMEjFAHM3vxSukESafpUF9MmnpfXCwSzSo+9nURwtHE2WPlPy+0dAe+3V+Ivju
TwP4Wt/EUVkbmM3MCS27gq5jfqB6MPfuMVfuPh/4cuI4ozaTRpHCYGEN5NH58RYsUl2uPNBZmJ35
yWb+8c7V3pllfpBHdWsUyW8qzRI65VHX7rAdMjt6UAPsbtb+yt7tI5YlniWQRzIUkUMM4ZTyCM8i
p6KKACiiigD5J/ar/wCSh6b/ANgaL/0fPXiVe2/tV/8AJQ9N/wCwNF/6PnrxKgAooooAKKKKACii
igAooooAKKKKACiiigAooooA9t/ZU/5KHqX/AGBpf/R8FfWFxeW1qM3FzFCPWRwv86+T/wBlT/ko
epf9gaX/ANHwV6p478CeI9Z8VX9/Yad51tN5eyTz41ziNQeCwPUGgDsvFbeE/FGmvZXWuaZHMmTD
N9rj3RN+fT1Hf8q8JvLWTTrySAyxu8TcSwSB0b0ZWHUV1Ufwp8VuuWtIYz6NcJn9Caif4XeLkbC6
Wrj1W5ix+rCgDsPDHxbs4tJ8rXvOa8gwqvEm4zj1PYN6569ah1H419V0zSfpJdSf+yr/APFV5de2
Vzp13LaXcLQ3ELbXjbqDXbfD3wZofiqKZry+uBdQNl7WPavy9myc5HY9MflQB0Pwx8eae6XGkarN
FZ6hcX09zC7nalyZpGkKqT/EpYqFJyVC4zzjodT0LXdR16aZ4tPOmqwazIumVon8raZpIfJIlkBJ
ADPtCheAeauWfw+8K2cTRDRbW4Vhtb7Uvnbh7h8ikHgaxtuNK1LV9IXtHaXztEv+7HJvRfoFAoA5
vRvAGq6KILq3hs1ns5LWSK0e/mmSVooponYyum5AUmG1ApVSgxjccdjoVmfD+hLHqE8EbI0txcOH
xFG0kjSMAzY+VS5AJxwBwOlU/wDhFdSPD+NvEDJ/d22S/qtuD+tLF4F0QypPfpc6xMjBlbVLl7lV
I6FY2JRT7hRQBkLpum/EDxFFrEtmLnRdPtXt7WeQMq3kjujM6DjdGgjwGPDF2xkDJ6eHwzoVuAId
GsEx3FsmfzxWn04FFAEMVnawf6q2hj/3EA/lU1FFAEclvDN/rYY5P95QaqSaFpE3+t0qyk/3rdD/
AEq/RQBk/wDCK+Hv+gDpn/gHH/hUieHNDT7mjaev0tUH9K0qyvE+qSaLoN7qEKhpYU+QEZAYkKD+
BOaunB1JqEd27EVJxpwc5bJX+4sppGmp9zT7VfpCo/pUws7UDAtoQPQIK+fP+Ej1n7X9s/tS68/d
u3+af5dMe3SvdPDGqSa1oNlqEyhZZk+cAYBYEqT+JGa9PH5XUwUIzlJNPT5nk5fm1PHTlCMWmtfk
WZdH0yf/AFunWkn+/Ap/mKydQ8BeGNSBEuj28Z/vW48oj/vnGfxroqK8k9k8z1H4LWEuW07U57c9
knQSD6ZGCP1rkNV+FfiXTsvDBFfxjvbPlv8Avk4P5Zr3uigD5gjn1bw/dEI95ptwOoBaJvxHFdbo
3xc16wZVvxFqMI671CSY9mHH5g17VeWFpqMJhvbWG5iP8EqBh+tcB4g+D+nXm6bRpzYynnyZMvEf
oeq/r9KAN/w/8QtA8QbY47r7LdNx9nucIxPseh/A59q6ivmbXvDWq+G7gQalbGPd9yRfmR/o39Ot
dN4P+J9/oXl2ep776wHAJOZYh7E9R7H8CKAPc6KpaVq9hrdmt5p9ylxC3dTyp9COoPsau0AFFFFA
BRRRQAUUUUAfJP7Vf/JQ9N/7A0X/AKPnrxKvbf2q/wDkoem/9gaL/wBHz14lQAUUUUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAe2/sqf8lD1L/sDS/+j4K+tq+Sf2VP+Sh6l/2Bpf8A0fBX1tQAUUUU
AcR8RvBK+IrE31lEP7Ttl+XA5mQfwH39Py714vo2r3nh/VIb+0YpNC3Know7qw9DX0/XkHxV8Fi2
d/EOnx4ikYfa41/hYnAcexPX357mgD03w/rtp4j0uHUbNvkkGHQnmNh1U+4/wNaVeJfB/WDZ69Np
ruRFfRHaM8eYvI/8d3fpXttABRRRQAUUUUAFFFFABRRRQBzni7xla+EEsGuLeW4F3PsfyyB5EI/1
k7Z/gTK5/wB4VNrmueG0aTRdX1OzhkuEVGt5ZgrYc4U47ZPQ+uKzNc8C/wDCUa5e3Wq3k0di1h9g
tobOcoxRyTP5nGPmIjGBniMetcpB4a8V3MmvaFKunTTXmiWenXepSSyLtwJ0MqDyz5jbTu2krhiO
SOaabTuhNKSs9hkfgfw1Nrf9mR+L4HuPOaP7GFUzZXJKZ3feABPTsTjiuz0Lxf4bt9C0ISXlrpX9
oWscltaXE6hwrYAz9ScZ7n3rA0XQtav7u7t/JtbfTYfE0t+100r/AGh/LfIUJswdxAG/f90kY9c5
fhbrUFktlvtbqO70m20+7zqNxDHEYlZWOxFHnIQ5IBKEHPPzZHViMbiMSkqsr29P0OTDYHDYVt0Y
Wb9f1PW6KQDAA9PWlrkOwKKKKACiiigCtf6daapavaX1ulxBIPmRxkfX2PvXj3jD4VXel+Ze6Jvv
LQctB1ljHt/eH6/XrXtVFAHzFouval4dvBdadcNDIOHXqrj0YdxXtvg34h2HigLazhbPUgOYSflk
90P9Ov161H4x+HGn+I1ku7MJZ6l18wDCSn/bA/8AQhz9a8S1HTdQ0G/a1vIZLW6iOR2+jKR1HoRQ
B9Q0V5V4I+KYfy9N8QyANwsd8eh9pP8A4r8/WvVFYOoZSGUjIIPBFAC0UUUAFFFFAHyT+1X/AMlD
03/sDRf+j568Sr239qv/AJKHpv8A2Bov/R89eJUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF
AHtv7Kn/ACUPUv8AsDS/+j4K+tq+Sf2VP+Sh6l/2Bpf/AEfBX1tQAUUUUAFVNW0+PVtMu7CX7lzE
0ZPpkcH8OtW6KAPmCxubjQNahuNpW4sbgFk91blf0Ir6bt547q3iuIW3RSoHRvUEZBrwf4p6R/Zn
iuaZFxFfIJ19Nx4b9QT+NemfC7UzqPhC1V23PaO1ux9hyv8A46yj8KAOwooooAKKKKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooAKyPEfhjTfE9kba/iyy58qZeHiPqD/Toa16KAPnDxV4
N1LwpdbLlfNtXOIrpB8r+x9D7fzrW8FfEa88NFLO833emZxsz88PuhPb/Z/lXuV7ZW2o2slreQJP
BKMPG4yDXjXjP4X3WkeZf6MHu7EfM8PWSEf+zL79R39aAPYNL1Wx1qzS80+4S4gfoynofQjqD7Gr
lfMvh/xJqXhq8F1p05TP+siblJB6MP69RXufhHx1pviqIRoRbX6jL2rtyfdT/EP1HegDp6KKKAPk
n9qv/koem/8AYGi/9Hz14lXtv7Vf/JQ9N/7A0X/o+evEqACiiigAooooAKKKKACiiigAooooAKKK
KACiiigD239lT/koepf9gaX/ANHwV9bV8k/sqf8AJQ9S/wCwNL/6Pgr62oAKKKKACiiigDzf4z6d
52jWN+q5a2nMbH0Vx/io/Os34KahiXVNNZvvKk6D6fK381ro/H9xDqAl0S5keDTbazbVNWnjXMiQ
IcoiejOyPz2WNsckEYgs/AVvZJ5Xg5herefYNqtAt4knlCXP2kzD+AqciUnLAdeKAPUqK5fw5d32
n6pJ4f1Gae4BtheWE1yytP5WQrxSMpIZ42K/MCch1ySQSeooAKKKKACiiigAqlqWtaXo0Yk1TUrO
wjPRrqdIgfxYiuG8WeLNc1rxE/gjwQ8cOoRIsmq6vKm+PTY26KB0aVh0Hb8ys2kfBbwhZObrVbN/
EepyczX2sSG4eQ/7rfKB+H4mgDc/4WP4I/6HLw//AODSD/4qj/hY/gf/AKHLw/8A+DSD/wCKo/4V
x4H/AOhN8P8A/grg/wDiaP8AhXHgf/oTfD//AIK4P/iaAD/hY/gf/ocvD/8A4NIP/iqP+Fj+B/8A
ocvD/wD4NIP/AIqj/hXHgf8A6E3w/wD+CuD/AOJo/wCFceB/+hN8P/8Agrg/+JoAP+Fj+B/+hy8P
/wDg0g/+Ko/4WP4H/wChy8P/APg0g/8AiqP+FceB/wDoTfD/AP4K4P8A4mj/AIVx4H/6E3w//wCC
uD/4mgA/4WP4H/6HLw//AODSD/4qj/hY/gf/AKHLw/8A+DSD/wCKo/4Vx4H/AOhN8P8A/grg/wDi
aP8AhXHgf/oTfD//AIK4P/iaAD/hY/gf/ocvD/8A4NIP/iqP+Fj+B/8AocvD/wD4NIP/AIqj/hXH
gf8A6E3w/wD+CuD/AOJo/wCFceB/+hN8P/8Agrg/+JoAP+Fj+B/+hy8P/wDg0g/+Ko/4WP4H/wCh
y8P/APg0g/8AiqP+FceB/wDoTfD/AP4K4P8A4mj/AIVx4H/6E3w//wCCuD/4mgA/4WP4H/6HLw//
AODSD/4qj/hY/gf/AKHLw/8A+DSD/wCKrhdQ1P4Vabf3VjN4CsGltpnhcpo9oVJUkHGT04rstP8A
AvgPUrC1vofBehLFcwpMgfSoAwDAEZwvXmgCx/wsfwP/ANDl4f8A/BpB/wDFUf8ACx/A/wD0OXh/
/wAGkH/xVH/CuPA//Qm+H/8AwVwf/E0f8K48D/8AQm+H/wDwVwf/ABNAHAeNIPh7rfmX2k+MfDlp
fn5mT+1IBHMff5vlPv8An615UNe0+xud0es2Uc0L/LJDeIcEdwyt+oNfSn/CuPA//Qm+H/8AwVwf
/E0f8K48D/8AQm+H/wDwVwf/ABNAHFeAvjPpGoh7DX9c0qCSGLel5LeRRrJggbTkgbuc8dQD6V2v
/Cx/A/8A0OXh/wD8GkH/AMVR/wAK48D/APQm+H//AAVwf/E0f8K48D/9Cb4f/wDBXB/8TQB8v/tK
63pWveOtPutI1Oz1K3TSY42ls7hJkVhNMSpKkjOCDj3FeQV9/wD/AArjwP8A9Cb4f/8ABXB/8TR/
wrjwP/0Jvh//AMFcH/xNAHwBRX3/AP8ACuPA/wD0Jvh//wAFcH/xNH/CuPA//Qm+H/8AwVwf/E0A
fAFFff8A/wAK48D/APQm+H//AAVwf/E0f8K48D/9Cb4f/wDBXB/8TQB8AUV9/wD/AArjwP8A9Cb4
f/8ABXB/8TR/wrjwP/0Jvh//AMFcH/xNAHwBRX3/AP8ACuPA/wD0Jvh//wAFcH/xNH/CuPA//Qm+
H/8AwVwf/E0AfAFFff8A/wAK48D/APQm+H//AAVwf/E0f8K48D/9Cb4f/wDBXB/8TQB8BvBNGiu8
TorfdZlIB+lMr7c8R/AnwLr0Egt9KXRrplIW40391j2KfcYeoI/EV8r/ABH+HGq/D/WWsb5VkR1M
lvcxLiO5QdWUfwsONyds5HGKAOLooooA9t/ZU/5KHqX/AGBpf/R8FfW1fJP7Kn/JQ9S/7A0v/o+C
vragAooooAKKKKAOG8XWkcGsXL3ly1np/iDTF0qS9HS2mR5Gi3dMK/nSDJIGQq5ywqS18APZ2rxw
SaMjSXTTm3/scG0QGIRkRxeZlCdu4kNySwI5rsbi3hu4JLe4hjmhlUrJHIoZXB6gg8EV4B8RtJOg
+IJtNtLi8h0qWFJIrAXcv2dVIwQIt2zGQ3GKAPTfCttDca1bPYTNdaZ4e0v+yIbxjn7TKzRmXB/i
2iCMEjjczD+E121c38PbyO98HaU0YVRDD5BVRjbsO3p9AD+NdJQAUUUUAFUta1JNG0fUNUkG5LK2
kuGHqEUsf5Vdrm/iP/yT3xX/ANga8/8ARD0AYfwW0hrLwNa6rdHzNT1921S9nI5keU7l/ALt4+vr
XoFc38OP+SeeFP8AsDWf/ohK6SgAooooAKKKKACiiigAooooAKKKKACiiigD5m8Vf8jRrX/X/P8A
+jGr6D8K/wDIr6L/ANeEH/ota+fPFX/I0a1/1/z/APoxq+g/Cv8AyK+i/wDXhB/6LWgDWooooAKK
KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArzj47eHIde+HWpXBjVrrSV+327sM42ffB9i
m4EfT0r0eub+I/8AyTzxX/2Brz/0Q9AHwHOixzyIjblVyFb1APWmUUUAe2/sqf8AJQ9S/wCwNL/6
Pgr62r5J/ZU/5KHqX/YGl/8AR8FfW1ABRRRQAUUUUAFeU/GrTSU0zVFXgFreQ/X5l/k9erVzvjzS
DrXhW/to0LzInnRADncnOB7kAj8aAOO+C2q7oNR0l25RhcRj2Pyt/Jfzr1Ovmnwpr0nhvXbXUVyY
0bbMo/ijPDD+o9wK+k4pY54kmicPHIoZGHRgeQaAH0UUUAFc38R/+SeeK/8AsDXn/oh66Sub+I//
ACTzxX/2Brz/ANEPQAfDj/knnhT/ALA1n/6ISukrm/hx/wAk88Kf9gaz/wDRCV0lABRRRQAUUUUA
FFFFABRRRQAUUUUAFFFFAHzN4q/5GjWv+v8An/8ARjV9B+Ff+RX0X/rwg/8ARa18+eKv+Ro1r/r/
AJ//AEY1fQfhX/kV9F/68IP/AEWtAGtRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABXN/Ef/knniv8A7A15/wCiHrpK5v4j/wDJPPFf/YGvP/RD0AfAFFFFAHtv7Kn/ACUPUv8AsDS/
+j4K+tq+Sf2VP+Sh6l/2Bpf/AEfBX1tQAUUUUAFFFFABRRRQB8+fEbw5/wAI94il8pNtpd5ngwOB
k/Mv4H9CK9F+EmvnUtBbTZnzPp7bVyeTGeV/I5H0Aq58T9B/trw1JNEm65sD56YHJX+Mflz/AMBF
eP8AhDxHL4X1uG+XLQn93cRj+OM9fxHBHuKAPpKio7e4iu4I7iCQSQyqHR16MpGQakoAK5v4j/8A
JPPFf/YGvP8A0Q9dJXN/Ef8A5J54r/7A15/6IegA+HH/ACTzwp/2BrP/ANEJXSVzfw4/5J54U/7A
1n/6ISukoAKKKKACiiigAooooAKKKKACiiigAooooA+ZvFX/ACNGtf8AX/P/AOjGr6D8K/8AIr6L
/wBeEH/ota+fPFX/ACNGtf8AX/P/AOjGr6D8K/8AIr6L/wBeEH/otaANaiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACub+I/8AyTzxX/2Brz/0Q9dJXN/Ef/knniv/ALA15/6IegD4
AooooA9t/ZU/5KHqX/YGl/8AR8FfW1fJP7Kn/JQ9S/7A0v8A6Pgr62oAKKKKACiiigAooooACMjB
6V8//EXwofDWtGS3TFheEyQYHCH+JPw7exFfQFZHifw/b+JtHn06fCsw3RSY5jcdG/x9iaAPP/hJ
4u/5l29k9Ws2Y/iyfzI/H2r1evly4t73Q9TeGTdb3lnL1B5VlPBB/UGvoLwX4oi8VaLHdZVbqL93
cxj+F/Uex6j8u1AHQ1zfxH/5J54r/wCwNef+iHrpK5v4j/8AJPPFf/YGvP8A0Q9AB8OP+SeeFP8A
sDWf/ohK6SvOtM8Vf8Ij8KPB9/8AY/tnmabZQ+X5vl4zbBs5wf7v61m/8Lv/AOpf/wDJ3/7XQB6v
RXlH/C7/APqX/wDyd/8AtdH/AAu//qX/APyd/wDtdAHq9NlljhjaSV1jjUZZnOAB7mvM9M+KGp+K
tQj0TRtIhs724Rn+1T3BlS3jXG6QoFXdjKgDIyzLnjNaWveFLHT7KPULyS11O6WZfP1LxHm5jgXB
+ZIAVQMW2qFj28tnnGCAb0/jvwhbOY5/FWiRODgrJqMKn8i1XtO1/R9X/wCQbq1jff8AXtcpJ/6C
TXC2njS/tdQ0ywbR7exjlFolzEtlIFRp3ZfmkBCwEAKRG4LMXC9TVjR1tPF1zZ/2/oOj3EGq2Daj
YlbT97boroNruScviVDuXbg7hjjNAHoVFcTrEeo+ALCfV9LuJ9S0i1Qvc6be3DO0KDrJFM2WAXqU
bcNoO3aRg89/wu//AKl//wAnf/tdAHq9FeUf8Lv/AOpf/wDJ3/7XR/wu/wD6l/8A8nf/ALXQB6vR
XlH/AAu//qX/APyd/wDtdH/C7/8AqX//ACd/+10Aee+Kv+Ro1r/r/n/9GNX0H4V/5FfRf+vCD/0W
tfOOq339p6pe3/l+V9quJJvL3btu5i2M8ZxmvQtK+MP9maXZWH9h+b9lt44fM+17d21QucbDjOKA
PYqK8o/4Xf8A9S//AOTv/wBro/4Xf/1L/wD5O/8A2ugD1eivKP8Ahd//AFL/AP5O/wD2uj/hd/8A
1L//AJO//a6APV6K8o/4Xf8A9S//AOTv/wBro/4Xf/1L/wD5O/8A2ugD1eivKP8Ahd//AFL/AP5O
/wD2uj/hd/8A1L//AJO//a6APV6K8o/4Xf8A9S//AOTv/wBro/4Xf/1L/wD5O/8A2ugD1eivKP8A
hd//AFL/AP5O/wD2uj/hd/8A1L//AJO//a6APV6K8o/4Xf8A9S//AOTv/wBro/4Xf/1L/wD5O/8A
2ugD1eivKP8Ahd//AFL/AP5O/wD2uj/hd/8A1L//AJO//a6APV6K8o/4Xf8A9S//AOTv/wBro/4X
f/1L/wD5O/8A2ugD1eub+I//ACTzxX/2Brz/ANEPXGf8Lv8A+pf/APJ3/wC11pan4q/4S74UeML/
AOx/Y/L029h8vzfMzi2LZzgf3v0oA+IaKKKAPbf2VP8Akoepf9gaX/0fBX1tXyT+yp/yUPUv+wNL
/wCj4K+tqACiiigAooooAKKKKACiiigDzf4reDzqNr/btjFuurZcXCKOZIx/F9V/l9K8z8KeJrrw
tqqXtvl4m+WeHPEien19DX0p1rxD4l+Bv7DuW1bTov8AiXTt+8RRxA5/9lPb0PHpQB7Jpep2usWE
N/ZSiWCZdyt3HqD6EdCKxviP/wAk88V/9ga8/wDRD15P8O/GjeGdQFrdyE6ZdMBID/yyboHH9fb6
V6t8RHWT4deKXRgytot2QwOQR5D80AYGmeFf+Eu+FHg+w+2fY/L02ym8zyvMzi2C4xkf3v0rN/4U
h/1MH/kl/wDbK7P4cf8AJPPCn/YGs/8A0QldJQB5R/wpD/qYP/JL/wC2Uf8ACkP+pg/8kv8A7ZXq
9FAHmOmfC/U/CuoR63o2rw3l7boyfZZ7cxJcRtjdGXDNtzhSDg4ZVzxmtnUde8L62LW08StdaFd2
84mihvriSxZZdrLlJkdVk4Zh8jsOfWu1pssUc0bRyoskbDDK4yCPcUAYFv4b8PXMsN7C8lyY/Lbc
dQmlWQxtujaQFyJGU8hmyRgegxWSTwb4PuJbh9TtLKaUbAlxfliqli2yJGY7QSSdqAduOBi5P4D8
IXLmSfwrokzk5LSadCx/MrV7TtA0fSP+QbpNjY/9e1skf/oIFAHM6xJqPj+wn0jS7efTdIukKXOp
XtuyNMh6xxQthiG6F22jaTt3E5HPf8KQ/wCpg/8AJL/7ZXq9FAHlH/CkP+pg/wDJL/7ZR/wpD/qY
P/JL/wC2V6vRQB5R/wAKQ/6mD/yS/wDtlH/CkP8AqYP/ACS/+2V6vRQB8t6rY/2Zql7YeZ5v2W4k
h8zbt3bWK5xzjOK9C0r4Pf2npdlf/wBueV9qt45vL+ybtu5Q2M7xnGa4jxV/yNGtf9f8/wD6Mavo
Pwr/AMivov8A14Qf+i1oA8+/4Uh/1MH/AJJf/bKP+FIf9TB/5Jf/AGyvV6KAPKP+FIf9TB/5Jf8A
2yj/AIUh/wBTB/5Jf/bK9XooA8o/4Uh/1MH/AJJf/bKP+FIf9TB/5Jf/AGyvV6KAPKP+FIf9TB/5
Jf8A2yj/AIUh/wBTB/5Jf/bK9XooA8o/4Uh/1MH/AJJf/bKP+FIf9TB/5Jf/AGyvV6KAPKP+FIf9
TB/5Jf8A2yj/AIUh/wBTB/5Jf/bK9XooA8o/4Uh/1MH/AJJf/bKP+FIf9TB/5Jf/AGyvV6KAPKP+
FIf9TB/5Jf8A2yj/AIUh/wBTB/5Jf/bK9XooA8o/4Uh/1MH/AJJf/bKP+FIf9TB/5Jf/AGyvV6KA
PKP+FIf9TB/5Jf8A2ytLU/Cv/CI/CjxhYfbPtnmabezeZ5Xl4zbFcYyf7v616LXN/Ef/AJJ54r/7
A15/6IegD4AooooA9q/ZclS2+IM5kYA3emTwRj1ZXhc/oD+VfXNfn14M8SXXhTxDY6xZbftFnMJY
wxwH4IaMnsHUlT+FfdXhLxbpPjXRYNX0i4EsMgxJGeJIH7o47MP/AK44IoA26KKKACiiigAooooA
KKKKACobu1gvraW1uYllgmUo6N0YGpqKAPCtZ+FPiC21GaPTLT7ZZ7sxS+dGp2nsQzA5FegeJ7Wa
x+D2sWlwmyeDw1NHIuQdrLasCMjg8iu1rm/iP/yTzxX/ANga8/8ARD0AHw4/5J54U/7A1n/6ISuk
rm/hx/yTzwp/2BrP/wBEJXSUAFFFFABRRRQAUUUUAFFFFABRRRQAUUVHbyvMhZ4JICHddkhUkgMQ
G+UkYYAMOc4IyAcgAHzV4q/5GjWv+v8An/8ARjV9B+Ff+RX0X/rwg/8ARa18+eKv+Ro1r/r/AJ//
AEY1fQfhX/kV9F/68IP/AEWtAGtRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABX
N/Ef/knniv8A7A15/wCiHrpK5v4j/wDJPPFf/YGvP/RD0AfAFFFFABW94b8Z634UvPtmj6jcWVxj
aZIWHzgdA6kFXA9GH48Vg0UAe1RftR+N7aNYxb6PeEDmW4s3Rj+CSgfpT/8Ahqvxx/0CvD//AIDz
/wDx6vEqKAPbf+Gq/HH/AECvD/8A4Dz/APx6j/hqvxx/0CvD/wD4Dz//AB6vEqKAPbf+Gq/HH/QK
8P8A/gPP/wDHqP8Ahqvxx/0CvD//AIDz/wDx6vEqKAPbf+Gq/HH/AECvD/8A4Dz/APx6j/hqvxx/
0CvD/wD4Dz//AB6vEqKAPbf+Gq/HH/QK8P8A/gPP/wDHqP8Ahqvxx/0CvD//AIDz/wDx6vEqKAPb
f+Gq/HH/AECvD/8A4Dz/APx6qOt/tK+Mde0bUNIutN0NLfULWS1laKCYOqupUlSZSM4PGQa8gooA
+/8A4cf8k88Kf9gaz/8ARCV0lc38OP8AknnhT/sDWf8A6ISukoAKKKKACiiigAooooAKKKKACiii
gDzv4geEdKn1S010eHbO6uikkV3dzaCmpx7T5YUywo6Tu4KKqMgfYpk3AA7h0ngax0rTvDFpb6Le
2d9Yl5pUnsNgtyzyu8giCkhUV2ZVXJ2gAEkgk8b44ub7VtebTo47fU7WCYWsVjLpjTQzXLQrO0Ei
tfQxzMIh5waSPYoGFbzOD3fhfUp9W0SC6upo5brfLFP5dsYAkkcjI6bDJJgoylSQ7KSpKkgigD59
8Vf8jRrX/X/P/wCjGr6D8K/8ivov/XhB/wCi1r588Vf8jRrX/X/P/wCjGr6D8K/8ivov/XhB/wCi
1oA1qKKKACiimu6RI0kjKiKMszHAA9SaAHUVw+pfFPSoLk2mlWtzrE4/59l+Q/Q9T+AIqt/wsXxA
engHUyPXMn/xqgD0GivPv+FieIf+hB1P85P/AI1R/wALF8QDr4B1MD1zJ/8AGqAPQaK4fTfinpU9
yLTVbW50ec/8/K/IPqeo/EAV2yOkqLJGyujDKspyCPUGgB1FFFABRRRQAUUUUAFFFFABXN/Ef/kn
niv/ALA15/6Ieukrm/iP/wAk88V/9ga8/wDRD0AfAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQB9/8Aw4/5J54U/wCwNZ/+iErpK5v4cf8AJPPCn/YGs/8A0QldJQAUUUUAFFFFABRRRQAU
UUUAFFFFAHCeL9J8E6Zfpq2tyapBeXl0ssa6fe3+9ptiW4kWG2fg7WjiLhR/rFUnLgHoPB66Wmgw
jR4biGy86cqt1K0kxczOZGcuzOGL7iVc71JKsFYFRkeM7C71LWdJhi0WPUbWG1uridgZIpsq0AWK
KdXVY3O4yqH4L28ZBjKCVNLwRIZPDsbfYJLBBdXSxRTQyxSNGLiQRySCX94XkQLIzP8AMzOWPWgD
wbxV/wAjRrX/AF/z/wDoxq+g/Cv/ACK+i/8AXhB/6LWvnzxV/wAjRrX/AF/z/wDoxq+g/Cv/ACK+
i/8AXhB/6LWgDWooooAK838S3F5438THwpYTtBptn8+oTJ/ER/D+BwAPXJ7V6RXnnwhUXOnatqj8
z3d8wdu5wob+bmgDtNH0PTtBtVtdOtUgjA5IHzOfVj1Jq/RRQAUUUUAUNY0PTtetWtdRtUnjI4JH
zIfVT1BrhvDVxeeCPEw8KX87T6befPp8z/wk/wAP4nII9cHvXpFeefF5RbadpOqJxPaXyhG7jKlv
5oKAPQ6KKKACiiigAooooAKKKKACub+I/wDyTzxX/wBga8/9EPXSVzfxH/5J54r/AOwNef8Aoh6A
PgCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA+//AIcf8k88Kf8AYGs//RCV0lc38OP+
SeeFP+wNZ/8AohK6SgAooooAKKKKACiiigAooooAKKKKAPO/ircWVk+k3mowaHqFnbpcvNpmszOV
mUKhMsUCQSs7x4yZNp8uNpcjDlk6nwdHNF4cs0n8N2/hiUb92k20kckdv87dGjAU7vvcDqxzzms3
xf4W8M6jFP8A2he/2Hc61/oEl3a3K28l6ZEMYiYNlJ2KblUOrlQSU2nmt/RpZ7jS7ae4v7PUXmTz
Bd2MRjgmVuUZFLvxtI53HPXvgAHzp4q/5GjWv+v+f/0Y1fQfhX/kV9F/68IP/Ra18+eKv+Ro1r/r
/n/9GNX0H4V/5FfRf+vCD/0WtAGtRRRQAV598GP+RXu/+v8Af/0XHXoNeffBj/kV7v8A6/3/APRc
dAHoNFFFABRRRQAV598Z/wDkV7T/AK/0/wDRcleg1598Z/8AkV7T/r/T/wBFyUAeg0UUUAFFFFAB
RRRQAUUUUAFc38R/+SeeK/8AsDXn/oh66Sub+I//ACTzxX/2Brz/ANEPQB8AUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFAH3/wDDj/knnhT/ALA1n/6ISukrm/hx/wAk88Kf9gaz/wDRCV0l
ABRRRQAUUUUAFFFFABRRRQAUUUUAcJ44tLbX723gs7PXLzUNLdGkuNFe0U237yKdY3N0wjJLwwSb
VBYBEztWQB+k8LxadFokA0ueS4t3eWV5phiR5nkZpjIuF2P5pfcm1drZXauNopTeEZ/7T1G/sPE+
saZ/aMyzzwWyWjx71ijiyPNgdhlYk43YzmtLQNFj8P6YthHdXF3++mnee52eZI8sryuTsVVHzO3A
UADFAHzx4q/5GjWv+v8An/8ARjV9B+Ff+RX0X/rwg/8ARa18+eKv+Ro1r/r/AJ//AEY1elaJ4D12
80bT7mHxvqNtFNaxyJAgk2xAqCFGJRwM46DpQB6fRXn3/Cu/EP8A0P2p/lJ/8do/4V34h/6H7U/y
k/8AjtAHoNeI+C/HMfhbw5Lax2pubqW8eTDNtRV2IAc9zkHiut/4V34h/wCh+1P8pP8A47XmOleH
9U1HSft9lZy3UKztAwhUuysArcqOcfN19q9PLKVCriFGu9Lel2eVmtbEUcM5Yde9f1su57B4P8ew
+Jp3s57f7LeKu9QG3LIB1x6H2rr68p+HHhPU7fWV1S9tZrOG3VgqzIUZ2Ix0POME816tRmdKhSxD
jQelvWzDKq2IrYZSxC96/pddwooorzD1Qrz74z/8ivaf9f6f+i5K9Brz74z/APIr2n/X+n/ouSgD
0GiiigAooooAKKKKACiiigArm/iP/wAk88V/9ga8/wDRD10lc38R/wDknniv/sDXn/oh6APgCiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooA+/wD4cf8AJPPCn/YGs/8A0QldJXN/Dj/knnhT
/sDWf/ohK6SgAooooAKKKKACiiigAooooAKKKKACiiigD5m8Vf8AI0a1/wBf8/8A6MavoPwr/wAi
vov/AF4Qf+i1r588Vf8AI0a1/wBf8/8A6MavoPwr/wAivov/AF4Qf+i1oA1qKKKACvPvgx/yK93/
ANf7/wDouOvQa89+DXHhq8Q8Mt++R6fu4/8ACgDtdY1jT9A06bU9Vu47Oygx5k0pwq5IUfmSB+NX
QQwBBBB5BHeuL8b6bqfiLVNK0eztYXsoRJe3j3kbm3kIHlxxEr1OXZ8Z48tT3rjLaW4gudH0bxTF
rkn9naVd2jpp6XP+kvFNEkMwEXzMGTBDHgM3JyBQB7PVezvrbUI5JLWZZUjleFyvZ0Yq6/gwI/Cv
G4ZNale+gvhrU/imG200WiwNO0EVyYUMm8ofLX5sl9+ARnGeak1Ox1qK48u5j1G30p7zVZFEFtdu
TO12xjYi3ZX5Qkox+Xk9ytAHtFeffGf/AJFe0/6/0/8ARcldh4eS9j0HTE1GSSW9W0iFxJKgR2k2
DcWAJAOc5AJGe5rjvjLz4as0HLNfpgev7uT/ABoA9CooooAKKKKACiiigAooooAK5v4j/wDJPPFf
/YGvP/RD10lc38R/+SeeK/8AsDXn/oh6APgCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo
oA+//hx/yTzwp/2BrP8A9EJXSVzfw4/5J54U/wCwNZ/+iErpKACiiigAooooAKKKKACiiigAoorh
tQ+LWhabf3VjNaai0ttM8LlI4ypKkg4y/TigDuaK8+/4XN4e/wCfPU/+/Uf/AMco/wCFzeHv+fPU
/wDv1H/8coA8n8Vf8jRrX/X/AD/+jGr6D8K/8ivov/XhB/6LWvnTW72PUtZ1C+hVliubqSZA4AYB
mJGcd+a9S0T4taFpujafYzWmotLbWscLlI4ypKqAcZfpxQB6fRXn3/C5vD3/AD56n/36j/8AjlH/
AAubw9/z56n/AN+o/wD45QB6DXmuhXC+CfG+o6NeHyrDVX8+0lbhQxJwv6lfqB61Z/4XN4e/589T
/wC/Uf8A8crF8T+P/B/iqw+yXtjqiunzQzpFHuib1Hz9PUd/yoA9bqA2Vs16t8YVN0kRhWXuEJBK
/TKg/hXiehfE7WdHQWxkj1S0ThPtR8uVVHT5sn8vm+tbn/C7iOvh/n2vf/tdAHqENlbW9xcXMUKp
NdFTM46uVG0Z+gGKnry21+MlxfTrb2nheW4nfO2KK6Ls2Bk4AjyeATWj/wALE8RHgeAdTz7mT/41
QB6DXmuu3C+NvG+naNZnzbDSn8+7lXlSwIyv6BfqT6U6aXx/4uBthaJ4esX4kkYnzSO4/vfkF+td
f4Y8L2HhWw+yWSlnf5pp3+9K3qfb0Hb86ANmiiigAooooAKKKKACiiigArm/iP8A8k88V/8AYGvP
/RD10lc38R/+SeeK/wDsDXn/AKIegD4AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPv
/wCHH/JPPCn/AGBrP/0QldJXN/Dj/knnhT/sDWf/AKISukoAKKKKACiiigAooooAKKKKACiiigAo
oooA+ZvFX/I0a1/1/wA//oxq+g/Cv/Ir6L/14Qf+i1r588Vf8jRrX/X/AD/+jGr2PU3kj+Em6GaW
CT+xY9ssLlHT90vKsOQfcUAdtRXjtx4q1WC/sLye7mQaHDcadcghjHPdpE5kkdNyhl+WFwSQAHbk
cmr0PjvWtWhvLaG4ssWkGoSTyeXlpUhjt2QAxykKT57AsrEfLkc0AeqUV5RffE3UbOa7itZLR/Ls
7kxRyoAUlhh3jP70uQSG+8q5GCpIBJ6PSNb1OXxs+i6hJBObWG6HnwxvEHAWycZTewyPOYZOTgDG
MtkA7SivLzruvSeJ7jVbRLlNP1F7jSrCa4dGsxIi/uJNgfdlpo5wTtG5ZE54FOu/iPqsunwanbRQ
WVjevIsE9yifuzHGm9X8yWMbjKZVxnOIWwMnIAPTqKoaLqQ1TT4Z2MS3IjT7VDG+7yJWRXKHuCAw
PPOCD3q/QAUUUUAFFFFABRRRQAUUUUAFFFFABXN/Ef8A5J54r/7A15/6Ieukrm/iP/yTzxX/ANga
8/8ARD0AfAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB9//AA4/5J54U/7A1n/6ISuk
rm/hx/yTzwp/2BrP/wBEJXSUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfM3ir/kaNa/6/5//RjV
9B+Ff+RX0X/rwg/9FrXz54q/5GjWv+v+f/0Y1fQfhX/kV9F/68IP/Ra0Aa1AAHQAUUUAJgZzgZpa
KKACkIDDBAI96WigAooooAKKKKACiiigAooooAKKKKACiiigArm/iP8A8k88V/8AYGvP/RD10lc3
8R/+SeeK/wDsDXn/AKIegD4AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPv/wCHH/JP
PCn/AGBrP/0QldJXN/Dj/knnhT/sDWf/AKISukoAKKKKACiiigAooooAKKKKACiiigAooooA+ZvF
X/I0a1/1/wA//oxq+g/Cv/Ir6L/14Qf+i1r588Vf8jRrX/X/AD/+jGr6D8K/8ivov/XhB/6LWgDW
ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArm/iP/yTzxX/ANga8/8ARD10lc38
R/8Aknniv/sDXn/oh6APgCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA+/8A4cf8k88K
f9gaz/8ARCV0lc38OP8AknnhT/sDWf8A6ISukoAKKKKACiiigAooooAKKKKACiiigAooooA+ZvFX
/I0a1/1/z/8Aoxq+g/Cv/Ir6L/14Qf8Aota+fPFX/I0a1/1/z/8Aoxq+g/Cv/Ir6L/14Qf8AotaA
NaiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACub+I//ACTzxX/2Brz/ANEPXSVz
fxH/AOSeeK/+wNef+iHoA+AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiinwOsc8buu5VcF
l9QD0oA+/Phx/wAk88Kf9gaz/wDRCV0lecfAnxHDr3w6023EitdaSv2C4RTnGzhCPYptIP19K9Ho
AKKKKACiiigAooooAKKKKACiiigAooooA+ZvFX/I0a1/1/z/APoxq+g/Cv8AyK+i/wDXhB/6LWvn
zxV/yNGtf9f8/wD6MavoPwr/AMivov8A14Qf+i1oA1qKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAK5v4j/APJPPFf/AGBrz/0Q9dJXnHx28Rw6D8OtStzIq3WrL9gt0Y4zv++T7BNx
J+nrQB8R0U+d1knkdF2qzkqvoCelMoAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAO0+HHxH1
X4f6yt9YssiOojuLaVsR3KDorH+FhztftnB4zX1R4c+O3gXXoIzcaqujXTKC1vqX7rHuH+4w9CD+
Ar4jp6TzRoyJK6K33lViAfrQB9+f8LH8D/8AQ5eH/wDwaQf/ABVH/Cx/A/8A0OXh/wD8GkH/AMVX
wBRQB9//APCx/A//AEOXh/8A8GkH/wAVR/wsfwP/ANDl4f8A/BpB/wDFV8AUUAff/wDwsfwP/wBD
l4f/APBpB/8AFUf8LH8D/wDQ5eH/APwaQf8AxVfAFFAH3/8A8LH8D/8AQ5eH/wDwaQf/ABVH/Cx/
A/8A0OXh/wD8GkH/AMVXwBRQB9//APCx/A//AEOXh/8A8GkH/wAVR/wsfwP/ANDl4f8A/BpB/wDF
V8AUUAff/wDwsfwP/wBDl4f/APBpB/8AFUf8LH8D/wDQ5eH/APwaQf8AxVfAFFAH2LqGmfCrUr+6
vpvHtgstzM8zhNYtAoLEk4yOnNdlp/jrwHptha2MPjTQmitoUhQvqsBYhQAM4brxXwRRQB9//wDC
x/A//Q5eH/8AwaQf/FUf8LH8D/8AQ5eH/wDwaQf/ABVfAFFAH3//AMLH8D/9Dl4f/wDBpB/8VR/w
sfwP/wBDl4f/APBpB/8AFV8AUUAff/8AwsfwP/0OXh//AMGkH/xVH/Cx/A//AEOXh/8A8GkH/wAV
XwBRQB9//wDCx/A//Q5eH/8AwaQf/FUf8LH8D/8AQ5eH/wDwaQf/ABVfAFFAH3//AMLH8D/9Dl4f
/wDBpB/8VR/wsfwP/wBDl4f/APBpB/8AFV8AUUAff/8AwsfwP/0OXh//AMGkH/xVH/Cx/A//AEOX
h/8A8GkH/wAVXwBRQB9//wDCx/A//Q5eH/8AwaQf/FUf8LH8D/8AQ5eH/wDwaQf/ABVfAFFAH3//
AMLH8D/9Dl4f/wDBpB/8VR/wsfwP/wBDl4f/APBpB/8AFV8AUUAff/8AwsfwP/0OXh//AMGkH/xV
H/Cx/A//AEOXh/8A8GkH/wAVXwBRQB9ueI/jt4F0GCQ2+qrrN0qkrb6b+9z7l/uKPUk/ga+V/iP8
R9V+IGstfXzLGiKY7e2ibMdsh6qp/iY8bn74wOMVxzzzSIqPK7qv3VZiQPpTKACiiigD/9k=

--Apple-Mail-10--258805288--



From w3c-dist-auth-request@w3.org  Tue Jan 14 05:12: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 FAA20325
	for <webdav-archive@lists.ietf.org>; Tue, 14 Jan 2003 05:12:43 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0EAEkA01946;
	Tue, 14 Jan 2003 05:14:46 -0500 (EST)
Resent-Date: Tue, 14 Jan 2003 05:14:46 -0500 (EST)
Resent-Message-Id: <200301141014.h0EAEkA01946@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 h0EAEkD01914
	for <w3c-dist-auth@frink.w3.org>; Tue, 14 Jan 2003 05:14: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 FAA25550
	for <w3c-dist-auth@w3.org>; Tue, 14 Jan 2003 05:14:45 -0500
Received: (qmail 6427 invoked by uid 0); 14 Jan 2003 10:14:14 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp016-rz3) with SMTP; 14 Jan 2003 10:14:14 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "WebDAV" <w3c-dist-auth@w3.org>
Date: Tue, 14 Jan 2003 11:14:13 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCMEPCGCAA.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: <JIEGINCHMLABHJBIGKBCKEBLGCAA.julian.reschke@gmx.de>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: RE: draft-ietf-webdav-ordering-protocol-04
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEPCGCAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7093
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 04 has been submitted to the IETF and is available from [1] and
[2] (annotated html). I will continue my edits on the "latest" version [3].

Julian

[1]
<http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-protocol-04>
[2]
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-04.htm
l>
[3]
<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 Julian Reschke
> Sent: Wednesday, January 08, 2003 6:20 PM
> To: WebDAV
> Subject: draft-ietf-webdav-ordering-protocol-04
>
>
>
> Hi,
>
> I'm in the process of finishing my edits on the ordered collections draft
> ([1]). The main changes are clarifications, rewriting of marshalling
> sections DeltaV-style, and a new section on the relation between ordered
> collections and version-controlled collections.
>
> Feedback appreciated.
>
> BTW: is anybody except ourselves currently implementing this protocol
> extension?
>
> Regards, Julian
>
>
> [1]
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-proto
> col-latest
> .html>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Tue Jan 14 10:15: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 KAA26876
	for <webdav-archive@lists.ietf.org>; Tue, 14 Jan 2003 10:15:34 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0EFHjk21067;
	Tue, 14 Jan 2003 10:17:45 -0500 (EST)
Resent-Date: Tue, 14 Jan 2003 10:17:45 -0500 (EST)
Resent-Message-Id: <200301141517.h0EFHjk21067@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 h0EFHhD21011
	for <w3c-dist-auth@frink.w3.org>; Tue, 14 Jan 2003 10:17:43 -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 KAA16866
	for <w3c-dist-auth@w3.org>; Tue, 14 Jan 2003 10:17:39 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26749;
	Tue, 14 Jan 2003 10:14:18 -0500 (EST)
Message-Id: <200301141514.KAA26749@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, 14 Jan 2003 10:14:18 -0500
Subject: I-D ACTION:draft-ietf-webdav-ordering-protocol-04.txt
X-Archived-At: http://www.w3.org/mid/200301141514.KAA26749@ietf.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7094
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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-04.txt
	Pages		: 40
	Date		: 2003-1-13
	
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-04.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-04.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-04.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-1-13142210.I-D@ietf.org>

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

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

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

--OtherAccess--

--NextPart--




From w3c-dist-auth-request@w3.org  Tue Jan 14 11:09:13 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 LAA00086
	for <webdav-archive@lists.ietf.org>; Tue, 14 Jan 2003 11:09:13 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0EGB5G03684;
	Tue, 14 Jan 2003 11:11:05 -0500 (EST)
Resent-Date: Tue, 14 Jan 2003 11:11:05 -0500 (EST)
Resent-Message-Id: <200301141611.h0EGB5G03684@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 h0EGB4D03652
	for <w3c-dist-auth@frink.w3.org>; Tue, 14 Jan 2003 11:11:04 -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 LAA19253
	for <w3c-dist-auth@w3c.org>; Tue, 14 Jan 2003 11:11:02 -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>; Tue, 14 Jan 2003 17:10:40 +0100
Date: Tue, 14 Jan 2003 17:10:39 +0100
Mime-Version: 1.0 (Apple Message framework v551)
Content-Type: text/plain; charset=US-ASCII; format=flowed
From: Stefan Eissing <stefan.eissing@greenbytes.de>
To: w3c-dist-auth@w3c.org
Content-Transfer-Encoding: 7bit
Message-Id: <B91C95E5-27DA-11D7-8272-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: bind feature in DAV header
X-Archived-At: http://www.w3.org/mid/B91C95E5-27DA-11D7-8272-00039384827E@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7095
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 seems to me that the BIND spec does not introduce a "bind" feature
to be reported in the DAV header of an OPTIONS response.

I think this should be added for the following reasons:

The feature list in the DAV header is useful for clients in deciding
which PROPFINDs need to be done in order to discover all that
is to know (= live properties) of a resource.

The nice thing about the DAV header is that a client can expect
this header to be rather static during the lifetime of a session.
In contrast, the supported-live-property-set can change quite
dramatically during the lifetime of a resource.

If a PROPFIND on DAV:resource-id will yield a meaningful response
cannot be deducted from the Allow header, since on non-collection
resources the BIND method will not be reported there.

//Stefan





From w3c-dist-auth-request@w3.org  Tue Jan 14 12:32: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 MAA04173
	for <webdav-archive@lists.ietf.org>; Tue, 14 Jan 2003 12:32:20 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0EHYBV22466;
	Tue, 14 Jan 2003 12:34:11 -0500 (EST)
Resent-Date: Tue, 14 Jan 2003 12:34:11 -0500 (EST)
Resent-Message-Id: <200301141734.h0EHYBV22466@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 h0EHYAD22422
	for <w3c-dist-auth@frink.w3.org>; Tue, 14 Jan 2003 12:34:10 -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 MAA23846
	for <w3c-dist-auth@w3c.org>; Tue, 14 Jan 2003 12:34:04 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 14 Jan 2003 12:19:11 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <C8Q5R75S>; Tue, 14 Jan 2003 12:33:27 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED5F0@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3c.org
Date: Tue, 14 Jan 2003 12:33:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: bind feature in DAV header
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED5F0@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7096
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


I don't find this use case very compelling.  You can just 
ask for all the properties you care about, and then let 
each resource return it if it supports it.

But I don't violently object, so if the consensus is to add
"bind" feature to the DAV header, that's OK with me.

Cheers,
Geoff
 

-----Original Message-----
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
Sent: Tuesday, January 14, 2003 11:11 AM
To: w3c-dist-auth@w3c.org
Subject: bind feature in DAV header



It seems to me that the BIND spec does not introduce a "bind" feature
to be reported in the DAV header of an OPTIONS response.

I think this should be added for the following reasons:

The feature list in the DAV header is useful for clients in deciding
which PROPFINDs need to be done in order to discover all that
is to know (= live properties) of a resource.

The nice thing about the DAV header is that a client can expect
this header to be rather static during the lifetime of a session.
In contrast, the supported-live-property-set can change quite
dramatically during the lifetime of a resource.

If a PROPFIND on DAV:resource-id will yield a meaningful response
cannot be deducted from the Allow header, since on non-collection
resources the BIND method will not be reported there.

//Stefan




From w3c-dist-auth-request@w3.org  Tue Jan 14 12:43: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 MAA04440
	for <webdav-archive@lists.ietf.org>; Tue, 14 Jan 2003 12:43:29 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0EHjSS24127;
	Tue, 14 Jan 2003 12:45:28 -0500 (EST)
Resent-Date: Tue, 14 Jan 2003 12:45:28 -0500 (EST)
Resent-Message-Id: <200301141745.h0EHjSS24127@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 h0EHjRD24095
	for <w3c-dist-auth@frink.w3.org>; Tue, 14 Jan 2003 12:45:27 -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 MAA27719
	for <w3c-dist-auth@w3c.org>; Tue, 14 Jan 2003 12:45:26 -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 h0EHiZs22835
	for <w3c-dist-auth@w3c.org>; Tue, 14 Jan 2003 09:44:36 -0800 (PST)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: <w3c-dist-auth@w3c.org>
Date: Tue, 14 Jan 2003 09:40:55 -0800
Message-ID: <AMEPKEBLDJJCCDEJHAMIGEPLGCAA.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
In-Reply-To: <B91C95E5-27DA-11D7-8272-00039384827E@greenbytes.de>
Importance: Normal
X-UCSC-CATS-MailScanner: Found to be clean
Subject: RE: bind feature in DAV header
X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIGEPLGCAA.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7097
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 fine with adding a "bind" feature to the DAV header.

- Jim

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing
> Sent: Tuesday, January 14, 2003 8:11 AM
> To: w3c-dist-auth@w3c.org
> Subject: bind feature in DAV header
> 
> 
> 
> It seems to me that the BIND spec does not introduce a "bind" feature
> to be reported in the DAV header of an OPTIONS response.
> 
> I think this should be added for the following reasons:
> 
> The feature list in the DAV header is useful for clients in deciding
> which PROPFINDs need to be done in order to discover all that
> is to know (= live properties) of a resource.
> 
> The nice thing about the DAV header is that a client can expect
> this header to be rather static during the lifetime of a session.
> In contrast, the supported-live-property-set can change quite
> dramatically during the lifetime of a resource.
> 
> If a PROPFIND on DAV:resource-id will yield a meaningful response
> cannot be deducted from the Allow header, since on non-collection
> resources the BIND method will not be reported there.
> 
> //Stefan
> 
> 



From w3c-dist-auth-request@w3.org  Thu Jan 16 11:20: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 LAA15072
	for <webdav-archive@lists.ietf.org>; Thu, 16 Jan 2003 11:20:40 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0GGLCd20786;
	Thu, 16 Jan 2003 11:21:12 -0500 (EST)
Resent-Date: Thu, 16 Jan 2003 11:21:12 -0500 (EST)
Resent-Message-Id: <200301161621.h0GGLCd20786@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 h0GGLBD20747
	for <w3c-dist-auth@frink.w3.org>; Thu, 16 Jan 2003 11:21:11 -0500 (EST)
Received: from dest-as20-002.int.bauer-partner.com ([80.146.226.66])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA32635
	for <w3c-dist-auth@w3.org>; Thu, 16 Jan 2003 11:21:10 -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, 16 Jan 2003 17:21:06 +0100
Message-ID: <2C5637A6A7CE844EA3C0A94565479F520FFF95@dest-as20-002.int.bauer-partner.com>
Thread-Topic: WebDAV and 404-handling
Thread-Index: AcK9e0U7+uJY7sknQhe8zNGNDrFM1A==
From: "Eriksson, Michael" <Michael.Eriksson@bauer-partner.com>
To: <w3c-dist-auth@w3.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h0GGLBD20747
Subject: WebDAV and 404-handling
X-Archived-At: http://www.w3.org/mid/2C5637A6A7CE844EA3C0A94565479F520FFF95@dest-as20-002.int.bauer-partner.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7098
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


Hi,

I have a problem with the integration of a pre-existing
WebDAV component in a web-application.  (As in Suns
servlet specification.)

This problem, outlined below, leads to the following
questions:

1) Is the body of a 404ed response ever relevant for WebDAV?
2) What about other error codes (as opposed to status
   codes indicating non-errors)?
3) Do you see any other potential problems from the
   discussion below?

The only interesting cases are status codes in the
normal HTTP header. A status code wrapped in an XML-tag
in the body is not relevant for my problem. Further
status codes not explicitly defined in the
HTTP-specification are (probably) irrelevant.

Background:
Web-applications allow for defining error pages
(normally JSPs) which on e.g. a 404 override the normal
server output. This gives an easily configurable and
central handling of what the end users actually sees.

In the specific case of WebDAV this is, however,
somewhat problematic.  For instance, consider the
following (client side) upload procedure:

HEAD
if already present then check with user
    if user allows
        PUT
    endif
else
    PUT
endif

(This is what happens with my version of Internet
Explorer judging by the output of an http sniffer.)

Since the recent addition of the above mentioned error
pages I have the problem that HEAD will no longer yield
a 404. The error pages come in between, and thus the
user is queried even if no previous entry is present.

As an experimental workaround I have altered the
corresponding error page to explicitly send a 404 if the
request was directed to the WebDAV-component.  This
takes care of the problem above, but is still
potententially dangerous, since the body/content of the
original response is lost. (In the case of WebDAV any
XML-tags specifying details.) Additionally, this might
not work for other status codes.

As a side-note, to prevent misunderstandings: The
behaviour of the server, tomcat, is correct. The
problems originate in a principal clash between
user-oriented (HTML through HTTP) and software-oriented
(WebDAV) output.

Regards,

Michael Eriksson



From w3c-dist-auth-request@w3.org  Thu Jan 16 11:50: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 LAA15888
	for <webdav-archive@lists.ietf.org>; Thu, 16 Jan 2003 11:50:41 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0GGq9E27553;
	Thu, 16 Jan 2003 11:52:09 -0500 (EST)
Resent-Date: Thu, 16 Jan 2003 11:52:09 -0500 (EST)
Resent-Message-Id: <200301161652.h0GGq9E27553@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 h0GGq8D27521
	for <w3c-dist-auth@frink.w3.org>; Thu, 16 Jan 2003 11:52:08 -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 LAA10100
	for <w3c-dist-auth@w3.org>; Thu, 16 Jan 2003 11:52:07 -0500
Received: (qmail 26928 invoked by uid 0); 16 Jan 2003 16:51:35 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp018-rz3) with SMTP; 16 Jan 2003 16:51:35 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Eriksson, Michael" <Michael.Eriksson@bauer-partner.com>,
        <w3c-dist-auth@w3.org>
Date: Thu, 16 Jan 2003 17:51:32 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCKEGLGDAA.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: <2C5637A6A7CE844EA3C0A94565479F520FFF95@dest-as20-002.int.bauer-partner.com>
Subject: RE: WebDAV and 404-handling
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEGLGDAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7099
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


Michael,

I think the assumption that there's a difference between "user-oriented
(HTML through HTTP)" and "software-oriented (WebDAV)" output is wrong in the
first place.

GET on a non-mapped URL should *always* return a 404 status (no matter what
the "type" of the user agent is). And it's perfectly legal to return a
response body for a 404.

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 Eriksson, Michael
> Sent: Thursday, January 16, 2003 5:21 PM
> To: w3c-dist-auth@w3.org
> Subject: WebDAV and 404-handling
>
>
>
> Hi,
>
> I have a problem with the integration of a pre-existing
> WebDAV component in a web-application.  (As in Suns
> servlet specification.)
>
> This problem, outlined below, leads to the following
> questions:
>
> 1) Is the body of a 404ed response ever relevant for WebDAV?
> 2) What about other error codes (as opposed to status
>    codes indicating non-errors)?
> 3) Do you see any other potential problems from the
>    discussion below?
>
> The only interesting cases are status codes in the
> normal HTTP header. A status code wrapped in an XML-tag
> in the body is not relevant for my problem. Further
> status codes not explicitly defined in the
> HTTP-specification are (probably) irrelevant.
>
> Background:
> Web-applications allow for defining error pages
> (normally JSPs) which on e.g. a 404 override the normal
> server output. This gives an easily configurable and
> central handling of what the end users actually sees.
>
> In the specific case of WebDAV this is, however,
> somewhat problematic.  For instance, consider the
> following (client side) upload procedure:
>
> HEAD
> if already present then check with user
>     if user allows
>         PUT
>     endif
> else
>     PUT
> endif
>
> (This is what happens with my version of Internet
> Explorer judging by the output of an http sniffer.)
>
> Since the recent addition of the above mentioned error
> pages I have the problem that HEAD will no longer yield
> a 404. The error pages come in between, and thus the
> user is queried even if no previous entry is present.
>
> As an experimental workaround I have altered the
> corresponding error page to explicitly send a 404 if the
> request was directed to the WebDAV-component.  This
> takes care of the problem above, but is still
> potententially dangerous, since the body/content of the
> original response is lost. (In the case of WebDAV any
> XML-tags specifying details.) Additionally, this might
> not work for other status codes.
>
> As a side-note, to prevent misunderstandings: The
> behaviour of the server, tomcat, is correct. The
> problems originate in a principal clash between
> user-oriented (HTML through HTTP) and software-oriented
> (WebDAV) output.
>
> Regards,
>
> Michael Eriksson
>



From w3c-dist-auth-request@w3.org  Thu Jan 16 12:39:59 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 MAA17420
	for <webdav-archive@lists.ietf.org>; Thu, 16 Jan 2003 12:39:58 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0GHf6q09355;
	Thu, 16 Jan 2003 12:41:06 -0500 (EST)
Resent-Date: Thu, 16 Jan 2003 12:41:06 -0500 (EST)
Resent-Message-Id: <200301161741.h0GHf6q09355@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 h0GHf0D09096
	for <w3c-dist-auth@frink.w3.org>; Thu, 16 Jan 2003 12:41:00 -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 MAA24274
	for <w3c-dist-auth@w3.org>; Thu, 16 Jan 2003 12:40:59 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18ZE0a-0007qt-00; Thu, 16 Jan 2003 17:40:52 +0000
Received: from [216.36.77.241] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18ZE0a-0007qi-00; Thu, 16 Jan 2003 17:40:52 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Eriksson, Michael'" <Michael.Eriksson@bauer-partner.com>,
        <w3c-dist-auth@w3.org>
Date: Thu, 16 Jan 2003 09:40:50 -0800
Message-ID: <000501c2bd86$68dee2a0$620afea9@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: <2C5637A6A7CE844EA3C0A94565479F520FFF95@dest-as20-002.int.bauer-partner.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Old-X-Envelope-To: Michael.Eriksson@bauer-partner.com,
 w3c-dist-auth@w3.org
Subject: RE: WebDAV and 404-handling
X-Archived-At: http://www.w3.org/mid/000501c2bd86$68dee2a0$620afea9@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7100
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 IE method of doing HEAD then PUT is a timing-dependent solution to
preventing unintended overwrites.  As such, it's about as dependable as
the rhythm method in preventing unintended pregnancies.

The recommended way to prevent overwrite on PUT is to put the header
"If-None-Match: *" on the request.   See for example
http://www.w3.org/1999/04/Editing/.

This may not solve your problem because it sounds like you have control
over the server but not the client.  I'm confused by your statement that
the server is "correct" in this. I would think the server ought to use a
404 Not Found response, with or without a body containing more detail,
in response to a HEAD.  

I know Tomcat can be extended with a servlet to respond with a 404 to a
HEAD to a non-existent file (with or without a body).  Xythos WebFile
Server does this for example.

lisa

> -----Original Message-----
> From: Eriksson, Michael [mailto:Michael.Eriksson@bauer-partner.com]
> Sent: Thursday, January 16, 2003 8:21 AM
> To: w3c-dist-auth@w3.org
> Subject: WebDAV and 404-handling
> 
> 
> Hi,
> 
> I have a problem with the integration of a pre-existing
> WebDAV component in a web-application.  (As in Suns
> servlet specification.)
> 
> This problem, outlined below, leads to the following
> questions:
> 
> 1) Is the body of a 404ed response ever relevant for WebDAV?
> 2) What about other error codes (as opposed to status
>    codes indicating non-errors)?
> 3) Do you see any other potential problems from the
>    discussion below?
> 
> The only interesting cases are status codes in the
> normal HTTP header. A status code wrapped in an XML-tag
> in the body is not relevant for my problem. Further
> status codes not explicitly defined in the
> HTTP-specification are (probably) irrelevant.
> 
> Background:
> Web-applications allow for defining error pages
> (normally JSPs) which on e.g. a 404 override the normal
> server output. This gives an easily configurable and
> central handling of what the end users actually sees.
> 
> In the specific case of WebDAV this is, however,
> somewhat problematic.  For instance, consider the
> following (client side) upload procedure:
> 
> HEAD
> if already present then check with user
>     if user allows
>         PUT
>     endif
> else
>     PUT
> endif
> 
> (This is what happens with my version of Internet
> Explorer judging by the output of an http sniffer.)
> 
> Since the recent addition of the above mentioned error
> pages I have the problem that HEAD will no longer yield
> a 404. The error pages come in between, and thus the
> user is queried even if no previous entry is present.
> 
> As an experimental workaround I have altered the
> corresponding error page to explicitly send a 404 if the
> request was directed to the WebDAV-component.  This
> takes care of the problem above, but is still
> potententially dangerous, since the body/content of the
> original response is lost. (In the case of WebDAV any
> XML-tags specifying details.) Additionally, this might
> not work for other status codes.
> 
> As a side-note, to prevent misunderstandings: The
> behaviour of the server, tomcat, is correct. The
> problems originate in a principal clash between
> user-oriented (HTML through HTTP) and software-oriented
> (WebDAV) output.
> 
> Regards,
> 
> Michael Eriksson
> 





From w3c-dist-auth-request@w3.org  Thu Jan 16 12:53: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 MAA18004
	for <webdav-archive@lists.ietf.org>; Thu, 16 Jan 2003 12:53:53 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0GHt6M16915;
	Thu, 16 Jan 2003 12:55:06 -0500 (EST)
Resent-Date: Thu, 16 Jan 2003 12:55:06 -0500 (EST)
Resent-Message-Id: <200301161755.h0GHt6M16915@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 h0GHt3D16854
	for <w3c-dist-auth@frink.w3.org>; Thu, 16 Jan 2003 12:55:03 -0500 (EST)
Received: from dest-as20-002.int.bauer-partner.com ([80.146.226.66])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA29590
	for <w3c-dist-auth@w3.org>; Thu, 16 Jan 2003 12:55:00 -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, 16 Jan 2003 18:54:59 +0100
Message-ID: <2C5637A6A7CE844EA3C0A94565479F529B0599@dest-as20-002.int.bauer-partner.com>
Thread-Topic: WebDAV and 404-handling
Thread-Index: AcK9f4snet3SqiBHRcCZ71mx1xi5KAAB3eVAAABRHMA=
From: "Eriksson, Michael" <Michael.Eriksson@bauer-partner.com>
To: <w3c-dist-auth@w3.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h0GHt3D16854
Subject: FW: WebDAV and 404-handling
X-Archived-At: http://www.w3.org/mid/2C5637A6A7CE844EA3C0A94565479F529B0599@dest-as20-002.int.bauer-partner.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7101
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


Accidentally dropped the list from response.

> -----Original Message-----
> From: Eriksson, Michael 
> Sent: Thursday, January 16, 2003 6:46 PM
> To: 'Julian Reschke'
> Subject: RE: WebDAV and 404-handling
> 
> 
> Julian,
> 
> > Michael,
> > 
> > I think the assumption that there's a difference between 
> "user-oriented
> > (HTML through HTTP)" and "software-oriented (WebDAV)" 
> output is wrong in the
> > first place.
> 
> You are absolutely right. This is also not my assumption,
> but an assumption that is most often present in a "normal"
> HTML/HTTP context.  The error page mechanism, in combination
> with an error page that has a nice message like:
> 
> Oops, we screwed up.
> Please contact us per email at ........
> 
> also adhers to this assumption.
> 
> > 
> > GET on a non-mapped URL should *always* return a 404 status 
> (no matter what
> > the "type" of the user agent is).
> 
> I tend to agree (if we take "non-mapped URL" to exclude e.g.
> permanently moved items) and I will have to check if we
> should generally change our error pages to pass the status
> on.
> 
> However, the correct behaviour of the error page mechanism
> is (judging from the answers to several bug reports that I
> have seen in the tomcat archives) _not_ to pass the status
> on.  The individual error pages can (should?) then set the
> status as appropriate.  Thus your statement is probably
> compatible with the fact that the error pages mechanism
> changes the original status.
> If you see a problem here, e.g. that status codes (or 404s)
> should never ever be changed, you might want to discuss it
> with the tomcat people (s. jakarta.apache.org/tomcat) or in
> the extension with the servlet specification people.
> 
> >And it's perfectly legal to return a response body for a 404.
> 
> It is. However, if WebDAV sends one body and the error page
> overwrites it then the "wrong" contents reach the
> WebDAV-client.  This is exactly the problem that provoked my
> questions.  I.e does WebDAV ever use 404-bodies for
> "important" data?  (Defining "important" as something that
> has a non-neglectable impact on the client behaviour.)
> 
> Michael
> 



From w3c-dist-auth-request@w3.org  Thu Jan 16 12:57: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 MAA18279
	for <webdav-archive@lists.ietf.org>; Thu, 16 Jan 2003 12:57:27 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0GHxBH18258;
	Thu, 16 Jan 2003 12:59:11 -0500 (EST)
Resent-Date: Thu, 16 Jan 2003 12:59:11 -0500 (EST)
Resent-Message-Id: <200301161759.h0GHxBH18258@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 h0GHxAD18223
	for <w3c-dist-auth@frink.w3.org>; Thu, 16 Jan 2003 12:59:10 -0500 (EST)
Received: from dest-as20-002.int.bauer-partner.com ([80.146.226.66])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA31076
	for <w3c-dist-auth@w3.org>; Thu, 16 Jan 2003 12:59:10 -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, 16 Jan 2003 18:59:06 +0100
Message-ID: <2C5637A6A7CE844EA3C0A94565479F529B059A@dest-as20-002.int.bauer-partner.com>
Thread-Topic: WebDAV and 404-handling
Thread-Index: AcK9hm/Jm6Kd50gvTLG+nw1voMUMbgAAnBpA
From: "Eriksson, Michael" <Michael.Eriksson@bauer-partner.com>
To: "Lisa Dusseault" <lisa@xythos.com>, <w3c-dist-auth@w3.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h0GHxAD18223
Subject: RE: WebDAV and 404-handling
X-Archived-At: http://www.w3.org/mid/2C5637A6A7CE844EA3C0A94565479F529B059A@dest-as20-002.int.bauer-partner.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7102
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 8bit


Lisa,

> 
> The IE method of doing HEAD then PUT is a timing-dependent solution to
> preventing unintended overwrites.

Well, I usually just assume that Microsoft does it the wrong
way. This is a good, time-saving heuristic :-)

> As such, it's about as dependable as
> the rhythm method in preventing unintended pregnancies.
I am not familiar with that one...

> The recommended way to prevent overwrite on PUT is to put the header
> "If-None-Match: *" on the request.   See for example
> http://www.w3.org/1999/04/Editing/.
> 
> This may not solve your problem because it sounds like you have control
> over the server but not the client.

Partially true, because I could change the server side.
Doing so would however bring other disadvantages. (Such as
having to maintain an extra version of a third party
component.) IE is over course completely out of my hands.
Also, there is no guarantee that the end user actually uses
IE and not e.g Cadaver.

> I'm confused by your statement that
> the server is "correct" in this. I would think the server ought to use a
> 404 Not Found response, with or without a body containing more detail,
> in response to a HEAD.  
See my previous response to Julian, which clarifies this
statement.

> I know Tomcat can be extended with a servlet to respond with a 404 to a
> HEAD to a non-existent file (with or without a body).  Xythos WebFile
> Server does this for example.

Tomcat per se handles non-existant files in the usual
maner. The problem is in the error pages, which are a part
of the servlet specification. (S. my email to Julian again.)


Michael



From w3c-dist-auth-request@w3.org  Thu Jan 16 13:11: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 NAA18648
	for <webdav-archive@lists.ietf.org>; Thu, 16 Jan 2003 13:11:23 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0GICNO22497;
	Thu, 16 Jan 2003 13:12:23 -0500 (EST)
Resent-Date: Thu, 16 Jan 2003 13:12:23 -0500 (EST)
Resent-Message-Id: <200301161812.h0GICNO22497@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 h0GICMD22464
	for <w3c-dist-auth@frink.w3.org>; Thu, 16 Jan 2003 13:12:22 -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 NAA03543
	for <w3c-dist-auth@w3.org>; Thu, 16 Jan 2003 13:12:19 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 16 Jan 2003 12:57:22 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <C8Q5WL0N>; Thu, 16 Jan 2003 13:11:43 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED612@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Thu, 16 Jan 2003 13:11:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV and 404-handling
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED612@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7103
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


Currently, there is no standard WebDAV content for a 404
body, so you can replace that body without violating
the WebDAV standard.  Probably the safest thing to do is to
only substitute the error page if the 404-body is
empty.

I do see a tension here between what the server would
want to do for a "dumb" client (that just knows how to
render html, and does nothing interesting with status
codes) and what it would do for a "smart" client.  I
personally agree with Julian and Lisa that in these cases,
the needs of the smart client should take precedence, and
the correct error code (404) should be returned.  

Cheers,
Geoff
 

-----Original Message-----
From: Eriksson, Michael [mailto:Michael.Eriksson@bauer-partner.com]
Sent: Thursday, January 16, 2003 12:55 PM
To: w3c-dist-auth@w3.org
Subject: FW: WebDAV and 404-handling



Accidentally dropped the list from response.

> -----Original Message-----
> From: Eriksson, Michael 
> Sent: Thursday, January 16, 2003 6:46 PM
> To: 'Julian Reschke'
> Subject: RE: WebDAV and 404-handling
> 
> 
> Julian,
> 
> > Michael,
> > 
> > I think the assumption that there's a difference between 
> "user-oriented
> > (HTML through HTTP)" and "software-oriented (WebDAV)" 
> output is wrong in the
> > first place.
> 
> You are absolutely right. This is also not my assumption,
> but an assumption that is most often present in a "normal"
> HTML/HTTP context.  The error page mechanism, in combination
> with an error page that has a nice message like:
> 
> Oops, we screwed up.
> Please contact us per email at ........
> 
> also adhers to this assumption.
> 
> > 
> > GET on a non-mapped URL should *always* return a 404 status 
> (no matter what
> > the "type" of the user agent is).
> 
> I tend to agree (if we take "non-mapped URL" to exclude e.g.
> permanently moved items) and I will have to check if we
> should generally change our error pages to pass the status
> on.
> 
> However, the correct behaviour of the error page mechanism
> is (judging from the answers to several bug reports that I
> have seen in the tomcat archives) _not_ to pass the status
> on.  The individual error pages can (should?) then set the
> status as appropriate.  Thus your statement is probably
> compatible with the fact that the error pages mechanism
> changes the original status.
> If you see a problem here, e.g. that status codes (or 404s)
> should never ever be changed, you might want to discuss it
> with the tomcat people (s. jakarta.apache.org/tomcat) or in
> the extension with the servlet specification people.
> 
> >And it's perfectly legal to return a response body for a 404.
> 
> It is. However, if WebDAV sends one body and the error page
> overwrites it then the "wrong" contents reach the
> WebDAV-client.  This is exactly the problem that provoked my
> questions.  I.e does WebDAV ever use 404-bodies for
> "important" data?  (Defining "important" as something that
> has a non-neglectable impact on the client behaviour.)
> 
> Michael
> 



From w3c-dist-auth-request@w3.org  Thu Jan 16 14:43: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 OAA21959
	for <webdav-archive@lists.ietf.org>; Thu, 16 Jan 2003 14:43:41 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0GJiP524189;
	Thu, 16 Jan 2003 14:44:25 -0500 (EST)
Resent-Date: Thu, 16 Jan 2003 14:44:25 -0500 (EST)
Resent-Message-Id: <200301161944.h0GJiP524189@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 h0GJiND24142
	for <w3c-dist-auth@frink.w3.org>; Thu, 16 Jan 2003 14:44:23 -0500 (EST)
Received: from mail.arc.nasa.gov (pony1.arc.nasa.gov [128.102.31.31])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA08640
	for <w3c-dist-auth@w3.org>; Thu, 16 Jan 2003 14:44:21 -0500
Received: from nasa.gov (counterweight.aen.nasa.gov [198.123.13.109])
	by mail.arc.nasa.gov (8.9.3/8.9.3) with ESMTP id LAA08245
	for <w3c-dist-auth@w3.org>; Thu, 16 Jan 2003 11:43:49 -0800 (PST)
Message-ID: <3E270B73.5090905@nasa.gov>
Date: Thu, 16 Jan 2003 11:43:47 -0800
From: Chris Knight <Christopher.D.Knight@nasa.gov>
Organization: NASA Ames Research Center
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021212
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: PROPFIND returning *more* than expected, and other questions
X-Archived-At: http://www.w3.org/mid/3E270B73.5090905@nasa.gov
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7104
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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'd like to discuss these questions (hopefully not at length, they 
should be fairly easy to answer) at the Interim WG meeting...But I 
thought I'd throw out the e-mail so people could ponder it first.

I'm working on a project that is providing rich searching capabilities 
to DAV properties. One feature we'd like to provide is keyword searching 
behaviors for properties. Say, for example, you requested <foo:author> 
and the resource had <foo:author>, <foo:author_name>, and <foo:authors> 
the server's response would contain all of these properties.

It appears that clients should expect to get fewer properties than they 
request and I would assume they'd accept more but I'd like to get the 
opinion of the community to ensure that we aren't doing something to 
break the protocol.

Second question, can a server respond to a PROPFIND for a particular 
property with multiple values for that property?

Thirdly, if a property has a rich XML structure as it's value, we'd like 
to return any matching XML tag in that structure.  (So if the 
<foo:authors> tag contained <foo:author>Chris</foo:author> 
<foo:author>David</foo:author> it would return all the <foo:authors> and 
each of the <foo:author> values separately.)

Anyways, see many of you next Monday!



From w3c-dist-auth-request@w3.org  Thu Jan 16 16:02: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 QAA23822
	for <webdav-archive@lists.ietf.org>; Thu, 16 Jan 2003 16:02:19 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0GL27U06618;
	Thu, 16 Jan 2003 16:02:07 -0500 (EST)
Resent-Date: Thu, 16 Jan 2003 16:02:07 -0500 (EST)
Resent-Message-Id: <200301162102.h0GL27U06618@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 h0GL26D06586
	for <w3c-dist-auth@frink.w3.org>; Thu, 16 Jan 2003 16:02:06 -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 QAA05084
	for <w3c-dist-auth@w3.org>; Thu, 16 Jan 2003 16:02:04 -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 h0GL1RH03561
	for <w3c-dist-auth@w3.org>; Thu, 16 Jan 2003 13:01:27 -0800 (PST)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "WebDAV" <w3c-dist-auth@w3.org>
Date: Thu, 16 Jan 2003 12:57:20 -0800
Message-ID: <AMEPKEBLDJJCCDEJHAMIGEEPGDAA.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: WebDAV permissions
X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIGEEPGDAA.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7105
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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: Boris Bauer [mailto:boris.bauer@verizon.net]
Sent: Thursday, January 16, 2003 11:07 AM
To: w3c-dist-auth@w3.org
Subject: [Moderator Action] WebDAV permissions




I am setting up a OS X Server and enabling WebDAV was no problem.

In my WebDAV directory I want to configure about a dozen different realms
with assigned usernames and passwords.

The OS X server manual does not come with any documentation to that matter
and I am unable to find literature.

Any hints?


Thanks,
Boris Bauer



From w3c-dist-auth-request@w3.org  Thu Jan 16 17:09: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 RAA25186
	for <webdav-archive@lists.ietf.org>; Thu, 16 Jan 2003 17:09:32 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0GMBgW15383;
	Thu, 16 Jan 2003 17:11:42 -0500 (EST)
Resent-Date: Thu, 16 Jan 2003 17:11:42 -0500 (EST)
Resent-Message-Id: <200301162211.h0GMBgW15383@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 h0GMBfD15332
	for <w3c-dist-auth@frink.w3.org>; Thu, 16 Jan 2003 17:11:41 -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 RAA18953
	for <w3c-dist-auth@w3.org>; Thu, 16 Jan 2003 17:11:40 -0500
Received: (qmail 16498 invoked by uid 0); 16 Jan 2003 22:11:07 -0000
Received: from pd950c244.dip.t-dialin.net (HELO lisa) (217.80.194.68)
  by mail.gmx.net (mp010-rz3) with SMTP; 16 Jan 2003 22:11:07 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Eriksson, Michael" <Michael.Eriksson@bauer-partner.com>,
        <w3c-dist-auth@w3.org>
Date: Thu, 16 Jan 2003 23:11:02 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCGEHNGDAA.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: <2C5637A6A7CE844EA3C0A94565479F529B0598@dest-as20-002.int.bauer-partner.com>
Subject: RE: WebDAV and 404-handling
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEHNGDAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7106
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


Michael,

> ..
>
> > I think the assumption that there's a difference between "user-oriented
> > (HTML through HTTP)" and "software-oriented (WebDAV)" output is
> wrong in the
> > first place.
>
> You are absolutely right. This is also not my assumption,
> but an assumption that is most often present in a "normal"
> HTML/HTTP context.  The error page mechanism, in combination
> with an error page that has a nice message like:
>
> Oops, we screwed up.
> Please contact us per email at ........
>
> also adhers to this assumption.

No, it doesn't. As long as the error page isn't sent out with a 2xx status.
You can and should send out a message body (explaining the error condition)
upon errors (check RFC2616). However this doesn't mean that the status
itself should be hidden.

> > GET on a non-mapped URL should *always* return a 404 status (no matter
what
> > the "type" of the user agent is).
>
> I tend to agree (if we take "non-mapped URL" to exclude e.g.
> permanently moved items) and I will have to check if we

In which case it would be a mapped URL (in WebDAV-speak) which identifies a
"redirect resource".

> should generally change our error pages to pass the status
> on.
>
> However, the correct behaviour of the error page mechanism
> is (judging from the answers to several bug reports that I
> have seen in the tomcat archives) _not_ to pass the status
> on.  The individual error pages can (should?) then set the

That's plain wrong. I just checked with Apache/moddav (www.apache.org) and
Tomcat 4.x (greenbytes.de:81), and both return both a 404 status *and* a
message body for unmapped URLs.

> status as appropriate.  Thus your statement is probably
> compatible with the fact that the error pages mechanism
> changes the original status.

If it does, it's broken. As far as I can tell, it doesn't.

> If you see a problem here, e.g. that status codes (or 404s)
> should never ever be changed, you might want to discuss it
> with the tomcat people (s. jakarta.apache.org/tomcat) or in
> the extension with the servlet specification people.

I might if you can point me more precisely to that discussion.

> >And it's perfectly legal to return a response body for a 404.
>
> It is. However, if WebDAV sends one body and the error page
> overwrites it then the "wrong" contents reach the
> WebDAV-client.  This is exactly the problem that provoked my
> questions.  I.e does WebDAV ever use 404-bodies for
> "important" data?  (Defining "important" as something that
> has a non-neglectable impact on the client behaviour.)

In general, the response body that was produced upon error never should be
replaced. If there's a mechanism with canned, multi-lingual error pages, it
should only be used if the real server code didn't produce it's own response
body.

For instance, replacing the response body for 403 or 409 responses almost
certainly will break WebDAV/deltaV interoperability.

Julian

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



From w3c-dist-auth-request@w3.org  Thu Jan 16 17:14: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 RAA25278
	for <webdav-archive@lists.ietf.org>; Thu, 16 Jan 2003 17:14:24 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0GMGmr15950;
	Thu, 16 Jan 2003 17:16:48 -0500 (EST)
Resent-Date: Thu, 16 Jan 2003 17:16:48 -0500 (EST)
Resent-Message-Id: <200301162216.h0GMGmr15950@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 h0GMGlD15918
	for <w3c-dist-auth@frink.w3.org>; Thu, 16 Jan 2003 17:16:47 -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 RAA20097
	for <w3c-dist-auth@w3.org>; Thu, 16 Jan 2003 17:16:47 -0500
Received: (qmail 14201 invoked by uid 0); 16 Jan 2003 22:16:10 -0000
Received: from pd950c244.dip.t-dialin.net (HELO lisa) (217.80.194.68)
  by mail.gmx.net (mp011-rz3) with SMTP; 16 Jan 2003 22:16:10 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Chris Knight" <Christopher.D.Knight@nasa.gov>, <w3c-dist-auth@w3.org>
Date: Thu, 16 Jan 2003 23:15:58 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCAEHOGDAA.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: <3E270B73.5090905@nasa.gov>
Subject: RE: PROPFIND returning *more* than expected, and other questions
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEHOGDAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7107
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 Chris Knight
> Sent: Thursday, January 16, 2003 8:44 PM
> To: w3c-dist-auth@w3.org
> Subject: PROPFIND returning *more* than expected, and other questions
>
>
>
> I'd like to discuss these questions (hopefully not at length, they
> should be fairly easy to answer) at the Interim WG meeting...But I
> thought I'd throw out the e-mail so people could ponder it first.
>
> I'm working on a project that is providing rich searching capabilities
> to DAV properties. One feature we'd like to provide is keyword searching

Did you consider

a) a new DASL grammar or
b) a new REPORT?

> behaviors for properties. Say, for example, you requested <foo:author>
> and the resource had <foo:author>, <foo:author_name>, and <foo:authors>
> the server's response would contain all of these properties.

If you do this upon PROPFIND/prop, that's illegal.

> It appears that clients should expect to get fewer properties than they
> request and I would assume they'd accept more but I'd like to get the
> opinion of the community to ensure that we aren't doing something to
> break the protocol.

Upon PROPFIND/prop, clients should expect to get entries for all properties
that were requested (not more, not less), possibly with non-200 status codes
(such as 404 for property not found).

> Second question, can a server respond to a PROPFIND for a particular
> property with multiple values for that property?

No. A property has exactly one value.

> Thirdly, if a property has a rich XML structure as it's value, we'd like
> to return any matching XML tag in that structure.  (So if the
> <foo:authors> tag contained <foo:author>Chris</foo:author>
> <foo:author>David</foo:author> it would return all the <foo:authors> and
> each of the <foo:author> values separately.)

I don't understand what this is good for. It's certainly not-compliant
behaviour.

> Anyways, see many of you next Monday!

See you!


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



From w3c-dist-auth-request@w3.org  Thu Jan 16 17:16: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 RAA25386
	for <webdav-archive@lists.ietf.org>; Thu, 16 Jan 2003 17:16:48 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0GMItR16364;
	Thu, 16 Jan 2003 17:18:55 -0500 (EST)
Resent-Date: Thu, 16 Jan 2003 17:18:55 -0500 (EST)
Resent-Message-Id: <200301162218.h0GMItR16364@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 h0GMIsD16329
	for <w3c-dist-auth@frink.w3.org>; Thu, 16 Jan 2003 17:18:54 -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 RAA20722
	for <w3c-dist-auth@w3.org>; Thu, 16 Jan 2003 17:18:53 -0500
Received: (qmail 9887 invoked by uid 0); 16 Jan 2003 22:18:17 -0000
Received: from pd950c244.dip.t-dialin.net (HELO lisa) (217.80.194.68)
  by mail.gmx.net (mp001-rz3) with SMTP; 16 Jan 2003 22:18:17 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Clemm, Geoff" <gclemm@rational.com>, <w3c-dist-auth@w3.org>
Date: Thu, 16 Jan 2003 23:18:08 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCEEHOGDAA.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: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED612@SUS-MA1IT01>
Subject: RE: WebDAV and 404-handling
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEHOGDAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7108
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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: Thursday, January 16, 2003 7:12 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: WebDAV and 404-handling
>
>
>
> Currently, there is no standard WebDAV content for a 404
> body, so you can replace that body without violating
> the WebDAV standard.  Probably the safest thing to do is to
> only substitute the error page if the 404-body is
> empty.
>
> I do see a tension here between what the server would
> want to do for a "dumb" client (that just knows how to
> render html, and does nothing interesting with status
> codes) and what it would do for a "smart" client.  I
> personally agree with Julian and Lisa that in these cases,
> the needs of the smart client should take precedence, and
> the correct error code (404) should be returned.

I don't understand this statement.

If  the resource was not found, return HTTP status 404. If you want to send
descriptive text, do so, but do *not* change the status code. That would be
a bug, and I really don't understand what it's good for.

Julian

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



From w3c-dist-auth-request@w3.org  Thu Jan 16 17:53: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 RAA26016
	for <webdav-archive@lists.ietf.org>; Thu, 16 Jan 2003 17:53:56 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0GMuKk21528;
	Thu, 16 Jan 2003 17:56:20 -0500 (EST)
Resent-Date: Thu, 16 Jan 2003 17:56:20 -0500 (EST)
Resent-Message-Id: <200301162256.h0GMuKk21528@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 h0GMuJD21496
	for <w3c-dist-auth@frink.w3.org>; Thu, 16 Jan 2003 17:56:19 -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 RAA29215
	for <w3c-dist-auth@w3.org>; Thu, 16 Jan 2003 17:56:19 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 16 Jan 2003 17:41:27 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <C8Q5XD2X>; Thu, 16 Jan 2003 17:55:48 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED616@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Thu, 16 Jan 2003 17:55:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV and 404-handling
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED616@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7109
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


If you knew that all of your clients will just display
the literal string "404- Not Found" whenever they receive
a 404 status (and they don't try to display the response
body), then you'd be tempted to compose a nice error message
page, and return 200 to avoid the poor 404 behavior of
your clients.  This is the "dumb client workaround" approach.

Note that I do not advocate this approach, since that makes
your web site perform poorly with smart clients, but I
think we should acknowledge that there are situations where
violating the protocol in this way produces a better user
experience.

To repeat though, this is not something I advocate, and it
violates the protocol.

Cheers,
Geoff



-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Thursday, January 16, 2003 5:18 PM
To: Clemm, Geoff; w3c-dist-auth@w3.org
Subject: RE: WebDAV and 404-handling


> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Thursday, January 16, 2003 7:12 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: WebDAV and 404-handling
>
>
>
> Currently, there is no standard WebDAV content for a 404
> body, so you can replace that body without violating
> the WebDAV standard.  Probably the safest thing to do is to
> only substitute the error page if the 404-body is
> empty.
>
> I do see a tension here between what the server would
> want to do for a "dumb" client (that just knows how to
> render html, and does nothing interesting with status
> codes) and what it would do for a "smart" client.  I
> personally agree with Julian and Lisa that in these cases,
> the needs of the smart client should take precedence, and
> the correct error code (404) should be returned.

I don't understand this statement.

If  the resource was not found, return HTTP status 404. If you want to send
descriptive text, do so, but do *not* change the status code. That would be
a bug, and I really don't understand what it's good for.

Julian

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



From w3c-dist-auth-request@w3.org  Thu Jan 16 18:02: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 SAA26137
	for <webdav-archive@lists.ietf.org>; Thu, 16 Jan 2003 18:02:28 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0GN44023405;
	Thu, 16 Jan 2003 18:04:04 -0500 (EST)
Resent-Date: Thu, 16 Jan 2003 18:04:04 -0500 (EST)
Resent-Message-Id: <200301162304.h0GN44023405@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 h0GN43D23331
	for <w3c-dist-auth@frink.w3.org>; Thu, 16 Jan 2003 18:04:03 -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 SAA30949
	for <w3c-dist-auth@w3.org>; Thu, 16 Jan 2003 18:03:50 -0500
Received: (qmail 26670 invoked by uid 0); 16 Jan 2003 23:03:39 -0000
Received: from pd950c244.dip.t-dialin.net (HELO lisa) (217.80.194.68)
  by mail.gmx.net (mp011-rz3) with SMTP; 16 Jan 2003 23:03:39 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Clemm, Geoff" <gclemm@rational.com>, <w3c-dist-auth@w3.org>
Date: Fri, 17 Jan 2003 00:03:37 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCEEIBGDAA.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: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED616@SUS-MA1IT01>
Subject: RE: WebDAV and 404-handling
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEIBGDAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7110
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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: Thursday, January 16, 2003 11:56 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: WebDAV and 404-handling
>
>
>
> If you knew that all of your clients will just display
> the literal string "404- Not Found" whenever they receive
> a 404 status (and they don't try to display the response
> body), then you'd be tempted to compose a nice error message
> page, and return 200 to avoid the poor 404 behavior of
> your clients.  This is the "dumb client workaround" approach.

I see. Is this just theoretical reasoning, or *are there* actually broken
clients like these?

> Note that I do not advocate this approach, since that makes
> your web site perform poorly with smart clients, but I
> think we should acknowledge that there are situations where
> violating the protocol in this way produces a better user
> experience.
>
> To repeat though, this is not something I advocate, and it
> violates the protocol.

Yes.

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



From w3c-dist-auth-request@w3.org  Thu Jan 16 19:43: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 TAA27865
	for <webdav-archive@lists.ietf.org>; Thu, 16 Jan 2003 19:43:36 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0H0gso10841;
	Thu, 16 Jan 2003 19:42:54 -0500 (EST)
Resent-Date: Thu, 16 Jan 2003 19:42:54 -0500 (EST)
Resent-Message-Id: <200301170042.h0H0gso10841@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 h0H0gqD10809
	for <w3c-dist-auth@frink.w3.org>; Thu, 16 Jan 2003 19:42:52 -0500 (EST)
Received: from mail.arc.nasa.gov (pony1.arc.nasa.gov [128.102.31.31])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA19677
	for <w3c-dist-auth@w3.org>; Thu, 16 Jan 2003 19:42:52 -0500
Received: from nasa.gov (counterweight.aen.nasa.gov [198.123.13.109])
	by mail.arc.nasa.gov (8.9.3/8.9.3) with ESMTP id QAA23821;
	Thu, 16 Jan 2003 16:42:14 -0800 (PST)
Message-ID: <3E275165.4070200@nasa.gov>
Date: Thu, 16 Jan 2003 16:42:13 -0800
From: Chris Knight <Christopher.D.Knight@nasa.gov>
Organization: NASA Ames Research Center
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021212
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
CC: w3c-dist-auth@w3.org
References: <JIEGINCHMLABHJBIGKBCAEHOGDAA.julian.reschke@gmx.de>
In-Reply-To: <JIEGINCHMLABHJBIGKBCAEHOGDAA.julian.reschke@gmx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: PROPFIND returning *more* than expected, and other questions
X-Archived-At: http://www.w3.org/mid/3E275165.4070200@nasa.gov
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7111
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


Julian Reschke wrote:
 > Chris Knight wrote:
>>I'd like to discuss these questions (hopefully not at length, they
>>should be fairly easy to answer) at the Interim WG meeting...But I
>>thought I'd throw out the e-mail so people could ponder it first.
>>
>>I'm working on a project that is providing rich searching capabilities
>>to DAV properties. One feature we'd like to provide is keyword searching
> 
> 
> Did you consider
> 
> a) a new DASL grammar or
> b) a new REPORT?

Point taken.

>>behaviors for properties. Say, for example, you requested <foo:author>
>>and the resource had <foo:author>, <foo:author_name>, and <foo:authors>
>>the server's response would contain all of these properties.
> 
> 
> If you do this upon PROPFIND/prop, that's illegal.

I thought this too but I didn't find anything in the RFC that would make 
such behavior illegal. I don't think it's worthy of inclusion in the RFC 
but a clarification of this would be worthwhile.  (Clarification being 
must the server only respond with the values requested?)

>>It appears that clients should expect to get fewer properties than they
>>request and I would assume they'd accept more but I'd like to get the
>>opinion of the community to ensure that we aren't doing something to
>>break the protocol.
> 
> Upon PROPFIND/prop, clients should expect to get entries for all properties
> that were requested (not more, not less), possibly with non-200 status codes
> (such as 404 for property not found).

Ah yeah I mis-read the RFC on this one. Ok. I reverse my assumption 
(assuming, instead, that requesting property foo should only return 
property foo's value, not property foobar's as well.)

>>Second question, can a server respond to a PROPFIND for a particular
>>property with multiple values for that property?
> 
> 
> No. A property has exactly one value.

I should have known this one, yeah that's true.

>>Thirdly, if a property has a rich XML structure as it's value, we'd like
>>to return any matching XML tag in that structure.  (So if the
>><foo:authors> tag contained <foo:author>Chris</foo:author>
>><foo:author>David</foo:author> it would return all the <foo:authors> and
>>each of the <foo:author> values separately.)
> 
> 
> I don't understand what this is good for. It's certainly not-compliant
> behaviour.

Agreed.



From w3c-dist-auth-request@w3.org  Fri Jan 17 03:26: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 DAA15538
	for <webdav-archive@lists.ietf.org>; Fri, 17 Jan 2003 03:26:26 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0H8Sss14501;
	Fri, 17 Jan 2003 03:28:54 -0500 (EST)
Resent-Date: Fri, 17 Jan 2003 03:28:54 -0500 (EST)
Resent-Message-Id: <200301170828.h0H8Sss14501@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 h0H8SqD14465
	for <w3c-dist-auth@frink.w3.org>; Fri, 17 Jan 2003 03:28:52 -0500 (EST)
Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA32111
	for <w3c-dist-auth@w3.org>; Fri, 17 Jan 2003 03:28:52 -0500
Received: from manyfish.co.uk ([62.253.142.244]) by mta03-svc.ntlworld.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20030117082851.PQYP4699.mta03-svc.ntlworld.com@manyfish.co.uk>
          for <w3c-dist-auth@w3.org>; Fri, 17 Jan 2003 08:28:51 +0000
Received: from monolith.fishnet (localhost.localdomain [127.0.0.1])
	by manyfish.co.uk (8.12.5/8.12.5) with ESMTP id h0H8WKW9002453
	for <w3c-dist-auth@w3.org>; Fri, 17 Jan 2003 08:32:20 GMT
Received: (from joe@localhost)
	by monolith.fishnet (8.12.5/8.12.5/Submit) id h0H8WJ0a002452
	for w3c-dist-auth@w3.org; Fri, 17 Jan 2003 08:32:19 GMT
Date: Fri, 17 Jan 2003 08:32:19 +0000
From: Joe Orton <joe@manyfish.co.uk>
To: w3c-dist-auth@w3.org
Message-ID: <20030117083219.GA2284@manyfish.co.uk>
Mail-Followup-To: w3c-dist-auth@w3.org
References: <JIEGINCHMLABHJBIGKBCAEHOGDAA.julian.reschke@gmx.de> <3E275165.4070200@nasa.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3E275165.4070200@nasa.gov>
User-Agent: Mutt/1.4i
Subject: Re: PROPFIND returning *more* than expected, and other questions
X-Archived-At: http://www.w3.org/mid/20030117083219.GA2284@manyfish.co.uk
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7112
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 Thu, Jan 16, 2003 at 04:42:13PM -0800, Chris Knight wrote:
> 
> Julian Reschke wrote:
> >>behaviors for properties. Say, for example, you requested <foo:author>
> >>and the resource had <foo:author>, <foo:author_name>, and <foo:authors>
> >>the server's response would contain all of these properties.
> >
> >
> >If you do this upon PROPFIND/prop, that's illegal.
> 
> I thought this too but I didn't find anything in the RFC that would make 
> such behavior illegal. I don't think it's worthy of inclusion in the RFC 
> but a clarification of this would be worthwhile.  (Clarification being 
> must the server only respond with the values requested?)

I asked this very same question a few years ago - Yaron said it's
perfectly legal for the server to return extra properties since the
client must ignore unknown/unexpected elements.

http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0196.html

Regards,

joe



From w3c-dist-auth-request@w3.org  Fri Jan 17 05:36:00 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 FAA17637
	for <webdav-archive@lists.ietf.org>; Fri, 17 Jan 2003 05:36:00 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0HAcHM06896;
	Fri, 17 Jan 2003 05:38:17 -0500 (EST)
Resent-Date: Fri, 17 Jan 2003 05:38:17 -0500 (EST)
Resent-Message-Id: <200301171038.h0HAcHM06896@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 h0HAcGD06863
	for <w3c-dist-auth@frink.w3.org>; Fri, 17 Jan 2003 05:38:16 -0500 (EST)
Received: from dest-as20-002.int.bauer-partner.com ([80.146.226.66])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA27521
	for <w3c-dist-auth@w3.org>; Fri, 17 Jan 2003 05:38:15 -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: Fri, 17 Jan 2003 11:38:11 +0100
Message-ID: <2C5637A6A7CE844EA3C0A94565479F529B059C@dest-as20-002.int.bauer-partner.com>
Thread-Topic: WebDAV and 404-handling
Thread-Index: AcK9rC2ngpD1tYL/RhaLskChxXkpOAAaCh6Q
From: "Eriksson, Michael" <Michael.Eriksson@bauer-partner.com>
To: "Julian Reschke" <julian.reschke@gmx.de>, <w3c-dist-auth@w3.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h0HAcGD06863
Subject: RE: WebDAV and 404-handling
X-Archived-At: http://www.w3.org/mid/2C5637A6A7CE844EA3C0A94565479F529B059C@dest-as20-002.int.bauer-partner.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7113
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


Julian,

there seems to be a couple of misunderstandings, due to the
fact that I have not explained the error pages mechanism
with enough detail.  This seemed reasonable, since I had not
counted on a discussion of the background part of my
original email.

Anyway (to my current understanding):
Tomcat _does_ handle e.g. 404 in a spec compliant maner per
default.  However, to simplify and centralize error handling
Tomcat (or probably the Catalina sub-component) supports an
error page mechanism defined by Suns servlet specification.

This mechanism allows for defining certain resources
(normally JSPs that provide dynamic content) that are
_always_ returned in case a certain status code (e.g. 404)
occurs. They thus effectively replace the default error
pages sent by the server.

The Tomcat implementation, which is claimed to be correct,
automatically removes the status code. The correctness of
this step depends on the servlet specification, _not_ the
HTTP specification.

The error page (error resource might be a more appropriate
name) can however explicitly change the status code to a
suitable value.  Here there might be a clash with the HTTP
specification, if the original status code is not reset.

The body of the original response (as generated by e.g. the
WebDAV component) is however lost.

Also note that I am using the term "error page" in the very
specific sense of the above discussion. I have probably not
emphasized that I do not mean "error page" in a general
sense clearly enough.

> > ..
> >
> > > I think the assumption that there's a difference between "user-oriented
> > > (HTML through HTTP)" and "software-oriented (WebDAV)" output is
> > wrong in the
> > > first place.
> >
> > You are absolutely right. This is also not my assumption,
> > but an assumption that is most often present in a "normal"
> > HTML/HTTP context.  The error page mechanism, in combination
> > with an error page that has a nice message like:
> >
> > Oops, we screwed up.
> > Please contact us per email at ........
> >
> > also adhers to this assumption.
> 
> No, it doesn't. As long as the error page isn't sent out with a 2xx status.

This is what happens per default with error pages. I.e. the
error page has to explicitly set the status to 404.

Even if the status _is_ set a client that relies on the
content of the original body is in difficulties -- because
somewhere along the line the assumption was made that it was
safe to send a user oriented body.

> You can and should send out a message body (explaining the error condition)
> upon errors (check RFC2616). However this doesn't mean that the status
> itself should be hidden.
> 
> > > GET on a non-mapped URL should *always* return a 404 status (no matter
> what
> > > the "type" of the user agent is).
> >
> > I tend to agree (if we take "non-mapped URL" to exclude e.g.
> > permanently moved items) and I will have to check if we
> 
> In which case it would be a mapped URL (in WebDAV-speak) which identifies a
> "redirect resource".
> 
> > should generally change our error pages to pass the status
> > on.
> >
> > However, the correct behaviour of the error page mechanism
> > is (judging from the answers to several bug reports that I
> > have seen in the tomcat archives) _not_ to pass the status
> > on.  The individual error pages can (should?) then set the
> 
> That's plain wrong. I just checked with Apache/moddav (www.apache.org) and
> Tomcat 4.x (greenbytes.de:81), and both return both a 404 status *and* a
> message body for unmapped URLs.

See above. (But Apache/moddav is completely separate from
Tomcat.)

> > status as appropriate.  Thus your statement is probably
> > compatible with the fact that the error pages mechanism
> > changes the original status.
> 
> If it does, it's broken. As far as I can tell, it doesn't.

See above.

> > If you see a problem here, e.g. that status codes (or 404s)
> > should never ever be changed, you might want to discuss it
> > with the tomcat people (s. jakarta.apache.org/tomcat) or in
> > the extension with the servlet specification people.
> 
> I might if you can point me more precisely to that discussion.

http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg38700.html
(Jump to the most interesting part of the somewhat heated thread.)

http://issues.apache.org/bugzilla/show_bug.cgi?id=15406
(Bug report.)

[snip]

Michael



From w3c-dist-auth-request@w3.org  Fri Jan 17 05:36: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 FAA17656
	for <webdav-archive@lists.ietf.org>; Fri, 17 Jan 2003 05:36:50 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0HAd9E07028;
	Fri, 17 Jan 2003 05:39:09 -0500 (EST)
Resent-Date: Fri, 17 Jan 2003 05:39:09 -0500 (EST)
Resent-Message-Id: <200301171039.h0HAd9E07028@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 h0HAd7D06993
	for <w3c-dist-auth@frink.w3.org>; Fri, 17 Jan 2003 05:39:07 -0500 (EST)
Received: from dest-as20-002.int.bauer-partner.com ([80.146.226.66])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA27652
	for <w3c-dist-auth@w3.org>; Fri, 17 Jan 2003 05:39:07 -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: Fri, 17 Jan 2003 11:39:06 +0100
Message-ID: <2C5637A6A7CE844EA3C0A94565479F529B059D@dest-as20-002.int.bauer-partner.com>
Thread-Topic: WebDAV and 404-handling
Thread-Index: AcK9i8Ht+O1U6SgQTZK5Vw+niva7PgAiNB4Q
From: "Eriksson, Michael" <Michael.Eriksson@bauer-partner.com>
To: "Clemm, Geoff" <gclemm@rational.com>, <w3c-dist-auth@w3.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h0HAd7D06993
Subject: RE: WebDAV and 404-handling
X-Archived-At: http://www.w3.org/mid/2C5637A6A7CE844EA3C0A94565479F529B059D@dest-as20-002.int.bauer-partner.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7114
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


Thank you Geoff.  With the information from you and Julian,
I can procede with simply re-resetting the status to 404.
(For the time being at least.)

> 
> Currently, there is no standard WebDAV content for a 404
> body, so you can replace that body without violating
> the WebDAV standard.  Probably the safest thing to do is to
> only substitute the error page if the 404-body is
> empty.

[snip]

Michael



From w3c-dist-auth-request@w3.org  Fri Jan 17 06:16:52 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 GAA18141
	for <webdav-archive@lists.ietf.org>; Fri, 17 Jan 2003 06:16:52 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0HBJ2q11387;
	Fri, 17 Jan 2003 06:19:02 -0500 (EST)
Resent-Date: Fri, 17 Jan 2003 06:19:02 -0500 (EST)
Resent-Message-Id: <200301171119.h0HBJ2q11387@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 h0HBJ1D11354
	for <w3c-dist-auth@frink.w3.org>; Fri, 17 Jan 2003 06:19:01 -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 GAA01895
	for <w3c-dist-auth@w3.org>; Fri, 17 Jan 2003 06:19:01 -0500
Received: (qmail 12656 invoked by uid 0); 17 Jan 2003 11:18:30 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp015-rz3) with SMTP; 17 Jan 2003 11:18:30 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Eriksson, Michael" <Michael.Eriksson@bauer-partner.com>,
        "Julian Reschke" <julian.reschke@gmx.de>, <w3c-dist-auth@w3.org>
Date: Fri, 17 Jan 2003 12:18:29 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCOEJAGDAA.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: <2C5637A6A7CE844EA3C0A94565479F529B059C@dest-as20-002.int.bauer-partner.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: WebDAV and 404-handling
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEJAGDAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7115
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


Michael,

I've been looking at the servlet spec (2.4) and the bug reports you cited.
As far as I understand the topic, the servlet engine allows you to specify
specfic URIs for error pages, but as you do so, it's your own job to ensure
that the proper HTTP status is sent. So if you map 404 response to an error
page, that error page should send out an HTTP status of 404 as well:

"If you point at a webapp resource that *itself* returns a 200 status
(which is the default behavior for static resources served by the
file-serving servlet, and which is what JSP pages will return unless you
do something different inside them), a 200 is what you should see in the
final response to the client.

If you want something different, map your error page handlers to a servlet
that does something different."

I agree though that this mechanism makes it ridicoulously easy to produce
broken HTTP responses.

> ...
> Even if the status _is_ set a client that relies on the
> content of the original body is in difficulties -- because
> somewhere along the line the assumption was made that it was
> safe to send a user oriented body.
> ...

In which case you shouldn't use the mapping.

> ...
> > > However, the correct behaviour of the error page mechanism
> > > is (judging from the answers to several bug reports that I
> > > have seen in the tomcat archives) _not_ to pass the status
> > > on.  The individual error pages can (should?) then set the
> >
> > That's plain wrong. I just checked with Apache/moddav  (www.apache.org)
and
> > Tomcat 4.x (greenbytes.de:81), and both return both a 404 status *and* a
> > message body for unmapped URLs.
>
> See above. (But Apache/moddav is completely separate from
> Tomcat.)
> ...

Yes, that's why I tested *both*.

Julian

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



From w3c-dist-auth-request@w3.org  Fri Jan 17 06:45: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 GAA18533
	for <webdav-archive@lists.ietf.org>; Fri, 17 Jan 2003 06:45:39 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0HBlvb15247;
	Fri, 17 Jan 2003 06:47:57 -0500 (EST)
Resent-Date: Fri, 17 Jan 2003 06:47:57 -0500 (EST)
Resent-Message-Id: <200301171147.h0HBlvb15247@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 h0HBltD15212
	for <w3c-dist-auth@frink.w3.org>; Fri, 17 Jan 2003 06:47:55 -0500 (EST)
Received: from dest-as20-002.int.bauer-partner.com ([80.146.226.66])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA06931
	for <w3c-dist-auth@w3.org>; Fri, 17 Jan 2003 06:47:54 -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: Fri, 17 Jan 2003 12:47:53 +0100
Message-ID: <2C5637A6A7CE844EA3C0A94565479F529B05A0@dest-as20-002.int.bauer-partner.com>
Thread-Topic: WebDAV and 404-handling
Thread-Index: AcK+GiqSYAKoYyd5R8ms4MOlmackSgAA+WVg
From: "Eriksson, Michael" <Michael.Eriksson@bauer-partner.com>
To: "Julian Reschke" <julian.reschke@gmx.de>, <w3c-dist-auth@w3.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h0HBltD15212
Subject: RE: WebDAV and 404-handling
X-Archived-At: http://www.w3.org/mid/2C5637A6A7CE844EA3C0A94565479F529B05A0@dest-as20-002.int.bauer-partner.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7116
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


Julian,

> I've been looking at the servlet spec (2.4) and the bug reports you cited.
> As far as I understand the topic, the servlet engine allows you to specify
> specfic URIs for error pages, but as you do so, it's your own job to ensure
> that the proper HTTP status is sent.

Correct.

>So if you map 404 response to an error
> page, that error page should send out an HTTP status of 404 as well:

Theoretically, yes. Their might however be pragmatic reasons not do so.
Specifically, Internet Explorer has a configurable setting
("friendly error messages" or similar) that ensures that most users
never see the body sent by the server for a 404. Instead a standard message
builtin in Internet Explorer is displayed.

(Yes, I know what this list thinks about breaking server-side behaviour
to accomodate client-side behaviour, but thats life.)

> "If you point at a webapp resource that *itself* returns a 200 status
> (which is the default behavior for static resources served by the
> file-serving servlet, and which is what JSP pages will return unless you
> do something different inside them), a 200 is what you should see in the
> final response to the client.
> 
> If you want something different, map your error page handlers to a servlet
> that does something different."
> 
> I agree though that this mechanism makes it ridicoulously easy to produce
> broken HTTP responses.

Indeed, until stumpling upon the problem with IE that I mentioned in
my original email, I had no idea about this behaviour.

> > ...
> > Even if the status _is_ set a client that relies on the
> > content of the original body is in difficulties -- because
> > somewhere along the line the assumption was made that it was
> > safe to send a user oriented body.
> > ...
> 
> In which case you shouldn't use the mapping.

If this is an option. But remember that this part relates to the
discussion about the existance of a "user vs. software oriented
assumption". In other words, by using the mapping one effectively
assumes that the output is user oriented.
(That this is, at least potentially, a bad thing is indisputable.)
Cf. my original mail.

[snip]

Thank you for time and help,

Michael



From w3c-dist-auth-request@w3.org  Fri Jan 17 07:11: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 HAA19113
	for <webdav-archive@lists.ietf.org>; Fri, 17 Jan 2003 07:11:46 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0HCE3020006;
	Fri, 17 Jan 2003 07:14:03 -0500 (EST)
Resent-Date: Fri, 17 Jan 2003 07:14:03 -0500 (EST)
Resent-Message-Id: <200301171214.h0HCE3020006@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 h0HCE2D19974
	for <w3c-dist-auth@frink.w3.org>; Fri, 17 Jan 2003 07:14:02 -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 HAA11818
	for <w3c-dist-auth@w3.org>; Fri, 17 Jan 2003 07:14:00 -0500
Received: (qmail 2152 invoked by uid 0); 17 Jan 2003 12:13:29 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp022-rz3) with SMTP; 17 Jan 2003 12:13:29 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Eriksson, Michael" <Michael.Eriksson@bauer-partner.com>,
        "Julian Reschke" <julian.reschke@gmx.de>, <w3c-dist-auth@w3.org>
Date: Fri, 17 Jan 2003 13:13:27 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCGEJDGDAA.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: <2C5637A6A7CE844EA3C0A94565479F529B05A0@dest-as20-002.int.bauer-partner.com>
Subject: RE: WebDAV and 404-handling
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEJDGDAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7117
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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



> ...
> >So if you map 404 response to an error
> > page, that error page should send out an HTTP status of 404 as well:
>
> Theoretically, yes. Their might however be pragmatic reasons not do so.
> Specifically, Internet Explorer has a configurable setting
> ("friendly error messages" or similar) that ensures that most users
> never see the body sent by the server for a 404. Instead a
> standard message
> builtin in Internet Explorer is displayed.
>
> (Yes, I know what this list thinks about breaking server-side behaviour
> to accomodate client-side behaviour, but thats life.)

One could argue that if this is what is configured in IE, this is what the
user should get. One the other hand, there seems to be an easy workaround (I
think sending a response body with more than 500 bytes length).

>
> > > ...
> > > Even if the status _is_ set a client that relies on the
> > > content of the original body is in difficulties -- because
> > > somewhere along the line the assumption was made that it was
> > > safe to send a user oriented body.
> > > ...
> >
> > In which case you shouldn't use the mapping.
>
> If this is an option. But remember that this part relates to the
> discussion about the existance of a "user vs. software oriented
> assumption". In other words, by using the mapping one effectively
> assumes that the output is user oriented.
> (That this is, at least potentially, a bad thing is indisputable.)
> Cf. my original mail.

IMHO: no. If the process that originally produced the non-2xx status has
supplied a response body, it *always* seems to be wrong to replace it with
something else.

Now GET and 404 is a very simple case because WebDAV doesn't require a
specific response body (how could it?). We may want to dicuss a specific
mime type that a client could stick into the HTTP Accept header to specify
the response body type.

Julian

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



From w3c-dist-auth-request@w3.org  Fri Jan 17 07:13: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 HAA19136
	for <webdav-archive@lists.ietf.org>; Fri, 17 Jan 2003 07:13:02 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0HCFF220222;
	Fri, 17 Jan 2003 07:15:15 -0500 (EST)
Resent-Date: Fri, 17 Jan 2003 07:15:15 -0500 (EST)
Resent-Message-Id: <200301171215.h0HCFF220222@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 h0HCFED20186
	for <w3c-dist-auth@frink.w3.org>; Fri, 17 Jan 2003 07:15:15 -0500 (EST)
Received: from dest-as20-002.int.bauer-partner.com ([80.146.226.66])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA12021
	for <w3c-dist-auth@w3.org>; Fri, 17 Jan 2003 07:15:14 -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: Fri, 17 Jan 2003 13:15:13 +0100
Message-ID: <2C5637A6A7CE844EA3C0A94565479F529B05A1@dest-as20-002.int.bauer-partner.com>
Thread-Topic: WebDAV and 404-handling
Thread-Index: AcK+ITVVjA48gmLgQ6SP5tJaB67jzgAAFiMQ
From: "Eriksson, Michael" <Michael.Eriksson@bauer-partner.com>
To: <w3c-dist-auth@w3.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h0HCFED20186
Subject: Another user who is involuntarily stuck on the list
X-Archived-At: http://www.w3.org/mid/2C5637A6A7CE844EA3C0A94565479F529B05A1@dest-as20-002.int.bauer-partner.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7118
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


Hi,

could someone give Mark a hand?
See below.

Michael

> -----Original Message-----
> From: Mark Kline [mailto:mkline@markklineskarate.com]
> Sent: Friday, January 17, 2003 1:08 PM
> To: Eriksson, Michael
> Subject: Re: WebDAV and 404-handling
> 
> 
> Michael,
> 
> The message was for anyone who could send it to the sys admin since I 
> cannot access the list, but am somehow on it.  I have sent emails 
> before and you are the only one who has replied...Thanks!
> 
> this email address is somehow on your list.  Please have it removed.
> 
> Mark
> On Friday, January 17, 2003, at 05:49 AM, Eriksson, Michael wrote:
> 
> > Mark,
> >
> > was this message actually intended for me or the list?
> > If it _is_ for me, I will need more details to take any
> > kind of action.
> > If not you will have to resend it to the list.
> >
> > Michael
> >> -----Original Message-----
> >> From: Mark Kline [mailto:mkline@markklineskarate.com]
> >> Sent: Friday, January 17, 2003 11:44 AM
> >> To: Eriksson, Michael
> >> Subject: Re: WebDAV and 404-handling
> >>
> >>
> >> How about explaining the lawsuit that I am going to bring to your
> >> company for putting me on this list.  THIS IS NO JOKE!  I 
> WANT TO BE
> >> REMOVED IMMEDIATELY FROM THIS LIST.   I DO NOT WORK FOR 
> YOUR COMPANY.
> >>
> >> PLEASE CONTACT YOUR SYSTEM ADMINISTRATOR AND FIX THIS NOW! 
>  THIS HAS
> >> BEEN GOING ON FOR A FEW MONTHS NOW!!
> >>
> >> MARK KLINE
> >> On Friday, January 17, 2003, at 05:38 AM, Eriksson, Michael wrote:
> >>
> >>>
> >>> Julian,
> >>>
> >>> there seems to be a couple of misunderstandings, due to the
> >>> fact that I have not explained the error pages mechanism
> >>> with enough detail.  This seemed reasonable, since I had not
> >>> counted on a discussion of the background part of my
> >>> original email.
> >>>
> >>> Anyway (to my current understanding):
> >>> Tomcat _does_ handle e.g. 404 in a spec compliant maner per
> >>> default.  However, to simplify and centralize error handling
> >>> Tomcat (or probably the Catalina sub-component) supports an
> >>> error page mechanism defined by Suns servlet specification.
> >>>
> >>> This mechanism allows for defining certain resources
> >>> (normally JSPs that provide dynamic content) that are
> >>> _always_ returned in case a certain status code (e.g. 404)
> >>> occurs. They thus effectively replace the default error
> >>> pages sent by the server.
> >>>
> >>> The Tomcat implementation, which is claimed to be correct,
> >>> automatically removes the status code. The correctness of
> >>> this step depends on the servlet specification, _not_ the
> >>> HTTP specification.
> >>>
> >>> The error page (error resource might be a more appropriate
> >>> name) can however explicitly change the status code to a
> >>> suitable value.  Here there might be a clash with the HTTP
> >>> specification, if the original status code is not reset.
> >>>
> >>> The body of the original response (as generated by e.g. the
> >>> WebDAV component) is however lost.
> >>>
> >>> Also note that I am using the term "error page" in the very
> >>> specific sense of the above discussion. I have probably not
> >>> emphasized that I do not mean "error page" in a general
> >>> sense clearly enough.
> >>>
> >>>>> ..
> >>>>>
> >>>>>> I think the assumption that there's a difference between
> >>>>>> "user-oriented
> >>>>>> (HTML through HTTP)" and "software-oriented (WebDAV)" output is
> >>>>> wrong in the
> >>>>>> first place.
> >>>>>
> >>>>> You are absolutely right. This is also not my assumption,
> >>>>> but an assumption that is most often present in a "normal"
> >>>>> HTML/HTTP context.  The error page mechanism, in combination
> >>>>> with an error page that has a nice message like:
> >>>>>
> >>>>> Oops, we screwed up.
> >>>>> Please contact us per email at ........
> >>>>>
> >>>>> also adhers to this assumption.
> >>>>
> >>>> No, it doesn't. As long as the error page isn't sent out
> >> with a 2xx
> >>>> status.
> >>>
> >>> This is what happens per default with error pages. I.e. the
> >>> error page has to explicitly set the status to 404.
> >>>
> >>> Even if the status _is_ set a client that relies on the
> >>> content of the original body is in difficulties -- because
> >>> somewhere along the line the assumption was made that it was
> >>> safe to send a user oriented body.
> >>>
> >>>> You can and should send out a message body (explaining the error
> >>>> condition)
> >>>> upon errors (check RFC2616). However this doesn't mean
> >> that the status
> >>>> itself should be hidden.
> >>>>
> >>>>>> GET on a non-mapped URL should *always* return a 404 status (no
> >>>>>> matter
> >>>> what
> >>>>>> the "type" of the user agent is).
> >>>>>
> >>>>> I tend to agree (if we take "non-mapped URL" to exclude e.g.
> >>>>> permanently moved items) and I will have to check if we
> >>>>
> >>>> In which case it would be a mapped URL (in WebDAV-speak) which
> >>>> identifies a
> >>>> "redirect resource".
> >>>>
> >>>>> should generally change our error pages to pass the status
> >>>>> on.
> >>>>>
> >>>>> However, the correct behaviour of the error page mechanism
> >>>>> is (judging from the answers to several bug reports that I
> >>>>> have seen in the tomcat archives) _not_ to pass the status
> >>>>> on.  The individual error pages can (should?) then set the
> >>>>
> >>>> That's plain wrong. I just checked with Apache/moddav
> >>>> (www.apache.org) and
> >>>> Tomcat 4.x (greenbytes.de:81), and both return both a 404 status
> >>>> *and* a
> >>>> message body for unmapped URLs.
> >>>
> >>> See above. (But Apache/moddav is completely separate from
> >>> Tomcat.)
> >>>
> >>>>> status as appropriate.  Thus your statement is probably
> >>>>> compatible with the fact that the error pages mechanism
> >>>>> changes the original status.
> >>>>
> >>>> If it does, it's broken. As far as I can tell, it doesn't.
> >>>
> >>> See above.
> >>>
> >>>>> If you see a problem here, e.g. that status codes (or 404s)
> >>>>> should never ever be changed, you might want to discuss it
> >>>>> with the tomcat people (s. jakarta.apache.org/tomcat) or in
> >>>>> the extension with the servlet specification people.
> >>>>
> >>>> I might if you can point me more precisely to that discussion.
> >>>
> >>>
> > 
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg38700.html
>> (Jump to the most interesting part of the somewhat heated thread.)
>>
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=15406
>> (Bug report.)
>>
>> [snip]
>>
>> Michael
>>
>>
>
>



From w3c-dist-auth-request@w3.org  Fri Jan 17 07:19:22 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 HAA19253
	for <webdav-archive@lists.ietf.org>; Fri, 17 Jan 2003 07:19:21 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0HCLke22145;
	Fri, 17 Jan 2003 07:21:46 -0500 (EST)
Resent-Date: Fri, 17 Jan 2003 07:21:46 -0500 (EST)
Resent-Message-Id: <200301171221.h0HCLke22145@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 h0HCLjD22113
	for <w3c-dist-auth@frink.w3.org>; Fri, 17 Jan 2003 07:21:45 -0500 (EST)
Received: from tarantula.inria.fr (tarantula.inria.fr [138.96.10.3])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA13471
	for <w3c-dist-auth@w3.org>; Fri, 17 Jan 2003 07:21:45 -0500
Received: (from ylafon@localhost)
	by tarantula.inria.fr (8.12.5/8.12.5) id h0HCLhfi009460;
	Fri, 17 Jan 2003 13:21:43 +0100 (MET)
Date: Fri, 17 Jan 2003 13:21:43 +0100 (MET)
From: Yves Lafon <ylafon@w3.org>
X-X-Sender: ylafon@tarantula.inria.fr
To: "Eriksson, Michael" <Michael.Eriksson@bauer-partner.com>
cc: w3c-dist-auth@w3.org
In-Reply-To: <2C5637A6A7CE844EA3C0A94565479F529B05A1@dest-as20-002.int.bauer-partner.com>
Message-ID: <Pine.GSO.4.53.0301171321270.8439@tarantula.inria.fr>
References: <2C5637A6A7CE844EA3C0A94565479F529B05A1@dest-as20-002.int.bauer-partner.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by frink.w3.org id h0HCLjD22113
Subject: Re: Another user who is involuntarily stuck on the list
X-Archived-At: http://www.w3.org/mid/Pine.GSO.4.53.0301171321270.8439@tarantula.inria.fr
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7119
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


On Fri, 17 Jan 2003, Eriksson, Michael wrote:

>
> Hi,
>
> could someone give Mark a hand?

I took care of it.
Thanks,

> See below.
>
> Michael
>
> > -----Original Message-----
> > From: Mark Kline [mailto:mkline@markklineskarate.com]
> > Sent: Friday, January 17, 2003 1:08 PM
> > To: Eriksson, Michael
> > Subject: Re: WebDAV and 404-handling
> >
> >
> > Michael,
> >
> > The message was for anyone who could send it to the sys admin since I
> > cannot access the list, but am somehow on it.  I have sent emails
> > before and you are the only one who has replied...Thanks!
> >
> > this email address is somehow on your list.  Please have it removed.
> >
> > Mark
> > On Friday, January 17, 2003, at 05:49 AM, Eriksson, Michael wrote:
> >
> > > Mark,
> > >
> > > was this message actually intended for me or the list?
> > > If it _is_ for me, I will need more details to take any
> > > kind of action.
> > > If not you will have to resend it to the list.
> > >
> > > Michael
> > >> -----Original Message-----
> > >> From: Mark Kline [mailto:mkline@markklineskarate.com]
> > >> Sent: Friday, January 17, 2003 11:44 AM
> > >> To: Eriksson, Michael
> > >> Subject: Re: WebDAV and 404-handling
> > >>
> > >>
> > >> How about explaining the lawsuit that I am going to bring to your
> > >> company for putting me on this list.  THIS IS NO JOKE!  I
> > WANT TO BE
> > >> REMOVED IMMEDIATELY FROM THIS LIST.   I DO NOT WORK FOR
> > YOUR COMPANY.
> > >>
> > >> PLEASE CONTACT YOUR SYSTEM ADMINISTRATOR AND FIX THIS NOW!
> >  THIS HAS
> > >> BEEN GOING ON FOR A FEW MONTHS NOW!!
> > >>
> > >> MARK KLINE
> > >> On Friday, January 17, 2003, at 05:38 AM, Eriksson, Michael wrote:
> > >>
> > >>>
> > >>> Julian,
> > >>>
> > >>> there seems to be a couple of misunderstandings, due to the
> > >>> fact that I have not explained the error pages mechanism
> > >>> with enough detail.  This seemed reasonable, since I had not
> > >>> counted on a discussion of the background part of my
> > >>> original email.
> > >>>
> > >>> Anyway (to my current understanding):
> > >>> Tomcat _does_ handle e.g. 404 in a spec compliant maner per
> > >>> default.  However, to simplify and centralize error handling
> > >>> Tomcat (or probably the Catalina sub-component) supports an
> > >>> error page mechanism defined by Suns servlet specification.
> > >>>
> > >>> This mechanism allows for defining certain resources
> > >>> (normally JSPs that provide dynamic content) that are
> > >>> _always_ returned in case a certain status code (e.g. 404)
> > >>> occurs. They thus effectively replace the default error
> > >>> pages sent by the server.
> > >>>
> > >>> The Tomcat implementation, which is claimed to be correct,
> > >>> automatically removes the status code. The correctness of
> > >>> this step depends on the servlet specification, _not_ the
> > >>> HTTP specification.
> > >>>
> > >>> The error page (error resource might be a more appropriate
> > >>> name) can however explicitly change the status code to a
> > >>> suitable value.  Here there might be a clash with the HTTP
> > >>> specification, if the original status code is not reset.
> > >>>
> > >>> The body of the original response (as generated by e.g. the
> > >>> WebDAV component) is however lost.
> > >>>
> > >>> Also note that I am using the term "error page" in the very
> > >>> specific sense of the above discussion. I have probably not
> > >>> emphasized that I do not mean "error page" in a general
> > >>> sense clearly enough.
> > >>>
> > >>>>> ..
> > >>>>>
> > >>>>>> I think the assumption that there's a difference between
> > >>>>>> "user-oriented
> > >>>>>> (HTML through HTTP)" and "software-oriented (WebDAV)" output is
> > >>>>> wrong in the
> > >>>>>> first place.
> > >>>>>
> > >>>>> You are absolutely right. This is also not my assumption,
> > >>>>> but an assumption that is most often present in a "normal"
> > >>>>> HTML/HTTP context.  The error page mechanism, in combination
> > >>>>> with an error page that has a nice message like:
> > >>>>>
> > >>>>> Oops, we screwed up.
> > >>>>> Please contact us per email at ........
> > >>>>>
> > >>>>> also adhers to this assumption.
> > >>>>
> > >>>> No, it doesn't. As long as the error page isn't sent out
> > >> with a 2xx
> > >>>> status.
> > >>>
> > >>> This is what happens per default with error pages. I.e. the
> > >>> error page has to explicitly set the status to 404.
> > >>>
> > >>> Even if the status _is_ set a client that relies on the
> > >>> content of the original body is in difficulties -- because
> > >>> somewhere along the line the assumption was made that it was
> > >>> safe to send a user oriented body.
> > >>>
> > >>>> You can and should send out a message body (explaining the error
> > >>>> condition)
> > >>>> upon errors (check RFC2616). However this doesn't mean
> > >> that the status
> > >>>> itself should be hidden.
> > >>>>
> > >>>>>> GET on a non-mapped URL should *always* return a 404 status (no
> > >>>>>> matter
> > >>>> what
> > >>>>>> the "type" of the user agent is).
> > >>>>>
> > >>>>> I tend to agree (if we take "non-mapped URL" to exclude e.g.
> > >>>>> permanently moved items) and I will have to check if we
> > >>>>
> > >>>> In which case it would be a mapped URL (in WebDAV-speak) which
> > >>>> identifies a
> > >>>> "redirect resource".
> > >>>>
> > >>>>> should generally change our error pages to pass the status
> > >>>>> on.
> > >>>>>
> > >>>>> However, the correct behaviour of the error page mechanism
> > >>>>> is (judging from the answers to several bug reports that I
> > >>>>> have seen in the tomcat archives) _not_ to pass the status
> > >>>>> on.  The individual error pages can (should?) then set the
> > >>>>
> > >>>> That's plain wrong. I just checked with Apache/moddav
> > >>>> (www.apache.org) and
> > >>>> Tomcat 4.x (greenbytes.de:81), and both return both a 404 status
> > >>>> *and* a
> > >>>> message body for unmapped URLs.
> > >>>
> > >>> See above. (But Apache/moddav is completely separate from
> > >>> Tomcat.)
> > >>>
> > >>>>> status as appropriate.  Thus your statement is probably
> > >>>>> compatible with the fact that the error pages mechanism
> > >>>>> changes the original status.
> > >>>>
> > >>>> If it does, it's broken. As far as I can tell, it doesn't.
> > >>>
> > >>> See above.
> > >>>
> > >>>>> If you see a problem here, e.g. that status codes (or 404s)
> > >>>>> should never ever be changed, you might want to discuss it
> > >>>>> with the tomcat people (s. jakarta.apache.org/tomcat) or in
> > >>>>> the extension with the servlet specification people.
> > >>>>
> > >>>> I might if you can point me more precisely to that discussion.
> > >>>
> > >>>
> > >
> http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg38700.html
> >> (Jump to the most interesting part of the somewhat heated thread.)
> >>
> >> http://issues.apache.org/bugzilla/show_bug.cgi?id=15406
> >> (Bug report.)
> >>
> >> [snip]
> >>
> >> Michael
> >>
> >>
> >
> >
>

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."



From w3c-dist-auth-request@w3.org  Fri Jan 17 07:34: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 HAA19785
	for <webdav-archive@lists.ietf.org>; Fri, 17 Jan 2003 07:34:09 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0HCaLI25073;
	Fri, 17 Jan 2003 07:36:21 -0500 (EST)
Resent-Date: Fri, 17 Jan 2003 07:36:21 -0500 (EST)
Resent-Message-Id: <200301171236.h0HCaLI25073@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 h0HCaKD25041
	for <w3c-dist-auth@frink.w3.org>; Fri, 17 Jan 2003 07:36:20 -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 HAA16439
	for <w3c-dist-auth@w3.org>; Fri, 17 Jan 2003 07:36:19 -0500
Received: (qmail 31601 invoked by uid 0); 17 Jan 2003 12:35:48 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp015-rz3) with SMTP; 17 Jan 2003 12:35:48 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Joe Orton" <joe@manyfish.co.uk>, <w3c-dist-auth@w3.org>
Date: Fri, 17 Jan 2003 13:35:46 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCIEJEGDAA.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: <20030117083219.GA2284@manyfish.co.uk>
Subject: RE: PROPFIND returning *more* than expected, and other questions
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEJEGDAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7120
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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: Friday, January 17, 2003 9:32 AM
> To: w3c-dist-auth@w3.org
> Subject: Re: PROPFIND returning *more* than expected, and other
> questions
>
>
>
> On Thu, Jan 16, 2003 at 04:42:13PM -0800, Chris Knight wrote:
> >
> > Julian Reschke wrote:
> > >>behaviors for properties. Say, for example, you requested <foo:author>
> > >>and the resource had <foo:author>, <foo:author_name>, and
> <foo:authors>
> > >>the server's response would contain all of these properties.
> > >
> > >
> > >If you do this upon PROPFIND/prop, that's illegal.
> >
> > I thought this too but I didn't find anything in the RFC that
> would make
> > such behavior illegal. I don't think it's worthy of inclusion
> in the RFC
> > but a clarification of this would be worthwhile.  (Clarification being
> > must the server only respond with the values requested?)
>
> I asked this very same question a few years ago - Yaron said it's
> perfectly legal for the server to return extra properties since the
> client must ignore unknown/unexpected elements.
>
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0196.html

I have to say that I disagree. It's correct that unknown protocol elements
should be ignored, but the contents of DAV:prop is one of the few places
where there *cannot* be unknown elements. Each child element of DAV:prop
identifies a property, so this has nothing to do with the extensibility
rules defined in the RFC2518 appendices.

Currently section 8.1 says:

"A client may submit a propfind XML element in the body of the request
method describing what information is being requested. It is possible to
request particular property values, all property values, or a list of the
names of the resource's properties. A client may choose not to submit a
request body. An empty PROPFIND request body MUST be treated as a request
for the names and values of all properties.

All servers MUST support returning a response of content type text/xml or
application/xml that contains a multistatus XML element that describes the
results of the attempts to retrieve the various properties."

I agree that this is a bit inprecise and should be clarified (right now,
most of the wording is in the examples which isn't a good thing).

However:

1) If a server returns more properties than requested, I'd really like to
understand why. In the example you posted back then, it certainly seems to
be a bug in the server. Does anybody really have a use case?

2) I'd claim that a conforming client may reject the response because it
does contain properties that weren't requested. So for the sake of
interoperability, servers MUST NOT return properties that weren't requested.

Julian


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



From w3c-dist-auth-request@w3.org  Fri Jan 17 08:52:04 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 IAA22361
	for <webdav-archive@lists.ietf.org>; Fri, 17 Jan 2003 08:52:03 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0HDs2Q12394;
	Fri, 17 Jan 2003 08:54:02 -0500 (EST)
Resent-Date: Fri, 17 Jan 2003 08:54:02 -0500 (EST)
Resent-Message-Id: <200301171354.h0HDs2Q12394@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 h0HDs0D12362
	for <w3c-dist-auth@frink.w3.org>; Fri, 17 Jan 2003 08:54:00 -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 IAA04925
	for <w3c-dist-auth@w3.org>; Fri, 17 Jan 2003 08:54:00 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 17 Jan 2003 08:39:06 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <C8Q5YCDC>; Fri, 17 Jan 2003 08:53:29 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE201A11F37@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Fri, 17 Jan 2003 08:53:28 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: PROPFIND returning *more* than expected, and other questions
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE201A11F37@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7121
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 need to be a bit careful here.  This is not a case of the XML
processing rule in section 14, i.e. that the client MUST ignore
unknown XML elements. This rule does not apply to properties returned
by PROPFIND, since PROPFIND is defined to allow an arbitrary XML
element in that position.  Note that this is actually a bug in RFC
2518, since in section 14, it correctly states that the "ignore" rule
does not apply to setting DAV properties (i.e. PROPPATCH) but neglects
to mention that this rule also does not apply to fetching DAV
properties (i.e. PROPFIND).

But Yaron wasn't arguing that there is anything in the spec that says
it is legal for PROPFIND to return extra properties, rather that:
- it is not explicitly forbidden
- it is semantically harmless to return extra properties (since a client
can ignore the ones its not interested in)
- a client should handle this case to be prepared for buggy servers.

Although I agree with these points, I disagree with the conclusion,
i.e. that a server should therefore feel free to send back extra
properties.  This just wastes bandwidth and processing resources, and
wastes it in a way that cannot be controlled by the client.  If a
client wants the properties, it can ask for them.  I believe whatever
slight benefit one might imagine getting from these unrequested
properties is significantly outweighed by the wasted bandwidth and
client/server processing required to pass information that will, with a
high degree of probability, be ignored by an interoperable client
(i.e. a client not hardwired to the behavior of a particular server).

Cheers,
Geoff

-----Original Message-----
From: Joe Orton [mailto:joe@manyfish.co.uk]
Sent: Friday, January 17, 2003 3:32 AM
To: w3c-dist-auth@w3.org
Subject: Re: PROPFIND returning *more* than expected, and other
questions



On Thu, Jan 16, 2003 at 04:42:13PM -0800, Chris Knight wrote:
> 
> Julian Reschke wrote:
> >>behaviors for properties. Say, for example, you requested <foo:author>
> >>and the resource had <foo:author>, <foo:author_name>, and <foo:authors>
> >>the server's response would contain all of these properties.
> >
> >
> >If you do this upon PROPFIND/prop, that's illegal.
> 
> I thought this too but I didn't find anything in the RFC that would make 
> such behavior illegal. I don't think it's worthy of inclusion in the RFC 
> but a clarification of this would be worthwhile.  (Clarification being 
> must the server only respond with the values requested?)

I asked this very same question a few years ago - Yaron said it's
perfectly legal for the server to return extra properties since the
client must ignore unknown/unexpected elements.

http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0196.html

Regards,

joe



From w3c-dist-auth-request@w3.org  Fri Jan 17 17:35: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 RAA06497
	for <webdav-archive@lists.ietf.org>; Fri, 17 Jan 2003 17:35:48 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0HMc2H16317;
	Fri, 17 Jan 2003 17:38:02 -0500 (EST)
Resent-Date: Fri, 17 Jan 2003 17:38:02 -0500 (EST)
Resent-Message-Id: <200301172238.h0HMc2H16317@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 h0HMc0D16282
	for <w3c-dist-auth@frink.w3.org>; Fri, 17 Jan 2003 17:38:00 -0500 (EST)
Received: from sunbelt.seagull.net (user32.net540.or.sprint-hsd.net [65.40.225.32])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA30334
	for <w3c-dist-auth@w3.org>; Fri, 17 Jan 2003 17:37:59 -0500
Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id OAA19203 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Fri, 17 Jan 2003 14:37:58 -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 OAA19180 sender obsfucated@us.ibm.com; Fri, 17 Jan 2003 14:37:56 -0800
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0HMbCI8167480; Fri, 17 Jan 2003 17:37:22 -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.4) with ESMTP id h0HMb7hU033186; Fri, 17 Jan 2003 17:37:09 -0500
To: "Clemm, Geoff" <gclemm@Rational.Com>
Cc: w3c-dist-auth-request@w3.org, w3c-dist-auth@w3.org
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <OFE07867DA.5857DA68-ON05256CB1.007BF3D2@us.ibm.com>
From: Jason Crawford <nn683849@smallcue.com>
Date: Fri, 17 Jan 2003 17:34:44 -0500
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V601_01122003|January 12, 2003) at 01/17/2003 17:37:09
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Subject: RE: PROPFIND returning *more* than expected, and other questions
X-Archived-At: http://www.w3.org/mid/OFE07867DA.5857DA68-ON05256CB1.007BF3D2@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7122
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>





Do we think we need to enhance the spec in any way?  Or is it clear enough
now?

J.  (Yes, I'm alive... at least for the next 45 minutes. :-))

------------------------------------------
Phone: 914-784-7569,   ccjason@us.ibm.com



From w3c-dist-auth-request@w3.org  Fri Jan 17 17:48: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 RAA06750
	for <webdav-archive@lists.ietf.org>; Fri, 17 Jan 2003 17:48:37 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0HMoxW17962;
	Fri, 17 Jan 2003 17:50:59 -0500 (EST)
Resent-Date: Fri, 17 Jan 2003 17:50:59 -0500 (EST)
Resent-Message-Id: <200301172250.h0HMoxW17962@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 h0HMowD17930
	for <w3c-dist-auth@frink.w3.org>; Fri, 17 Jan 2003 17:50: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 RAA01085
	for <w3c-dist-auth@w3.org>; Fri, 17 Jan 2003 17:50:58 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 17 Jan 2003 17:36:03 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <C8Q5ZQXX>; Fri, 17 Jan 2003 17:50:27 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED622@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Fri, 17 Jan 2003 17:50:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: PROPFIND returning *more* than expected, and other questions
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED622@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7123
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


Minimally, we should indicate that PROPFIND MUST NOT ignore
unknown XML elements.

I personally would prefer us to state that PROPFIND SHOULD
(or even MUST) only return requested properties, unless
someone can come up with a compelling reason for not adding
this constraint.

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:nn683849@smallcue.com]
Sent: Friday, January 17, 2003 5:35 PM
To: Clemm, Geoff
Cc: w3c-dist-auth-request@w3.org; w3c-dist-auth@w3.org
Subject: RE: PROPFIND returning *more* than expected, and other
questions





Do we think we need to enhance the spec in any way?  Or is it clear enough
now?

J.  (Yes, I'm alive... at least for the next 45 minutes. :-))

------------------------------------------
Phone: 914-784-7569,   ccjason@us.ibm.com



From w3c-dist-auth-request@w3.org  Fri Jan 17 19:53: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 TAA08367
	for <webdav-archive@lists.ietf.org>; Fri, 17 Jan 2003 19:53:09 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0I0tgv12529;
	Fri, 17 Jan 2003 19:55:42 -0500 (EST)
Resent-Date: Fri, 17 Jan 2003 19:55:42 -0500 (EST)
Resent-Message-Id: <200301180055.h0I0tgv12529@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 h0I0teD12492
	for <w3c-dist-auth@frink.w3.org>; Fri, 17 Jan 2003 19:55:40 -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 TAA27180
	for <w3c-dist-auth@w3.org>; Fri, 17 Jan 2003 19:55:39 -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 h0I0tTH10292
	for <w3c-dist-auth@w3.org>; Fri, 17 Jan 2003 16:55:29 -0800 (PST)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: <w3c-dist-auth@w3.org>
Date: Fri, 17 Jan 2003 16:51:16 -0800
Message-ID: <AMEPKEBLDJJCCDEJHAMIMEHKGDAA.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: <JIEGINCHMLABHJBIGKBCAEHOGDAA.julian.reschke@gmx.de>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-UCSC-CATS-MailScanner: Found to be clean
Subject: RE: PROPFIND returning *more* than expected, and other questions
X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIMEHKGDAA.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7124
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


> > Second question, can a server respond to a PROPFIND for a particular
> > property with multiple values for that property?
>
> No. A property has exactly one value.
>
> > Thirdly, if a property has a rich XML structure as it's value, we'd like
> > to return any matching XML tag in that structure.  (So if the
> > <foo:authors> tag contained <foo:author>Chris</foo:author>
> > <foo:author>David</foo:author> it would return all the <foo:authors> and
> > each of the <foo:author> values separately.)
>
> I don't understand what this is good for. It's certainly not-compliant
> behaviour.

While a WebDAV property's "value" is marshalled as a sequence of well-formed
XML. If a property contains a list of authors, it would be OK to marshall
this as

<foo:authors>
 <foo:author>Chris</foo:author>
 <foo:author>Julian</foo:author>
</foo:authors>

In this way WebDAV handles "multi-valued" properties.

- Jim



From w3c-dist-auth-request@w3.org  Fri Jan 17 23:48:32 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 XAA11190
	for <webdav-archive@lists.ietf.org>; Fri, 17 Jan 2003 23:48:29 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0I4onV15852;
	Fri, 17 Jan 2003 23:50:49 -0500 (EST)
Resent-Date: Fri, 17 Jan 2003 23:50:49 -0500 (EST)
Resent-Message-Id: <200301180450.h0I4onV15852@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 h0I4oiD15806
	for <w3c-dist-auth@frink.w3.org>; Fri, 17 Jan 2003 23:50:44 -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 XAA00978
	for <w3c-dist-auth@w3.org>; Fri, 17 Jan 2003 23:50:44 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18ZkwN-0008T1-00; Sat, 18 Jan 2003 04:50:43 +0000
Received: from [198.144.203.248] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18ZkwM-0008Sq-00; Sat, 18 Jan 2003 04:50:43 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Clemm, Geoff'" <gclemm@rational.com>, <w3c-dist-auth@w3.org>
Date: Fri, 17 Jan 2003 20:50:40 -0800
Message-ID: <000c01c2bead$2712d340$620afea9@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.2600.0000
In-Reply-To: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED622@SUS-MA1IT01>
Old-X-Envelope-To: gclemm@rational.com,
 w3c-dist-auth@w3.org
Subject: RE: PROPFIND returning *more* than expected, and other questions
X-Archived-At: http://www.w3.org/mid/000c01c2bead$2712d340$620afea9@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7125
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


Sorry, what's the rationale for PROPFIND not ignoring unknown XML
elements?  Does this mean anywhere in the propfind body or just in
certain places? I assume it's supposed to fail when it sees unknown
elements?

This would make some existing client/server interactions fail -- e.g.
clients that have already shipped extending the PROPFIND request in ways
that ordinary WebDAV servers ignore, but special WebDAV servers know the
extension & behave smarter.

lisa

> -----Original Message-----
> From: Clemm, Geoff [mailto:gclemm@rational.com]
> Sent: Friday, January 17, 2003 2:50 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: PROPFIND returning *more* than expected, and other
questions
> 
> 
> Minimally, we should indicate that PROPFIND MUST NOT ignore
> unknown XML elements.
> 
> I personally would prefer us to state that PROPFIND SHOULD
> (or even MUST) only return requested properties, unless
> someone can come up with a compelling reason for not adding
> this constraint.
> 
> Cheers,
> Geoff





From w3c-dist-auth-request@w3.org  Sat Jan 18 03:20: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 DAA23590
	for <webdav-archive@lists.ietf.org>; Sat, 18 Jan 2003 03:20:47 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0I8NIa13843;
	Sat, 18 Jan 2003 03:23:18 -0500 (EST)
Resent-Date: Sat, 18 Jan 2003 03:23:18 -0500 (EST)
Resent-Message-Id: <200301180823.h0I8NIa13843@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 h0I8NHD13811
	for <w3c-dist-auth@frink.w3.org>; Sat, 18 Jan 2003 03:23:17 -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 DAA32592
	for <w3c-dist-auth@w3.org>; Sat, 18 Jan 2003 03:23:16 -0500
Received: (qmail 19229 invoked by uid 0); 18 Jan 2003 08:22:40 -0000
Received: from p3ee24826.dip.t-dialin.net (HELO lisa) (62.226.72.38)
  by mail.gmx.net (mp021-rz3) with SMTP; 18 Jan 2003 08:22:40 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Lisa Dusseault" <lisa@xythos.com>, "'Clemm, Geoff'" <gclemm@rational.com>,
        <w3c-dist-auth@w3.org>
Date: Sat, 18 Jan 2003 09:22:23 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCEELIGDAA.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: <000c01c2bead$2712d340$620afea9@xythoslap>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: RE: PROPFIND returning *more* than expected, and other questions
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEELIGDAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7126
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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, January 18, 2003 5:51 AM
> To: 'Clemm, Geoff'; w3c-dist-auth@w3.org
> Subject: RE: PROPFIND returning *more* than expected, and other
> questions
>
>
>
> Sorry, what's the rationale for PROPFIND not ignoring unknown XML
> elements?  Does this mean anywhere in the propfind body or just in
> certain places? I assume it's supposed to fail when it sees unknown
> elements?
> ...

Nope. PROPFIND must ignore unknown elements (hint: some servers don't...),
*except* when child of a DAV:prop or DAV:propname element.

Right, Geoff?

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



From w3c-dist-auth-request@w3.org  Sat Jan 18 04:11: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 EAA24250
	for <webdav-archive@lists.ietf.org>; Sat, 18 Jan 2003 04:11:33 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0I9EAL16759;
	Sat, 18 Jan 2003 04:14:10 -0500 (EST)
Resent-Date: Sat, 18 Jan 2003 04:14:10 -0500 (EST)
Resent-Message-Id: <200301180914.h0I9EAL16759@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 h0I9E8D16727
	for <w3c-dist-auth@frink.w3.org>; Sat, 18 Jan 2003 04:14:08 -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 EAA06015
	for <w3c-dist-auth@w3.org>; Sat, 18 Jan 2003 04:14:07 -0500
Received: (qmail 30614 invoked by uid 0); 18 Jan 2003 09:13:34 -0000
Received: from p3ee24826.dip.t-dialin.net (HELO lisa) (62.226.72.38)
  by mail.gmx.net (mp023-rz3) with SMTP; 18 Jan 2003 09:13:34 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Julian Reschke" <julian.reschke@gmx.de>,
        "Lisa Dusseault" <lisa@xythos.com>,
        "'Clemm, Geoff'" <gclemm@rational.com>, <w3c-dist-auth@w3.org>
Date: Sat, 18 Jan 2003 10:13:22 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCKELIGDAA.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: <JIEGINCHMLABHJBIGKBCEELIGDAA.julian.reschke@gmx.de>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: RE: PROPFIND returning *more* than expected, and other questions
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKELIGDAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7127
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 Julian Reschke
> Sent: Saturday, January 18, 2003 9:22 AM
> To: Lisa Dusseault; 'Clemm, Geoff'; w3c-dist-auth@w3.org
> Subject: RE: PROPFIND returning *more* than expected, and other
> questions
>
>
>
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> > Sent: Saturday, January 18, 2003 5:51 AM
> > To: 'Clemm, Geoff'; w3c-dist-auth@w3.org
> > Subject: RE: PROPFIND returning *more* than expected, and other
> > questions
> >
> >
> >
> > Sorry, what's the rationale for PROPFIND not ignoring unknown XML
> > elements?  Does this mean anywhere in the propfind body or just in
> > certain places? I assume it's supposed to fail when it sees unknown
> > elements?
> > ...
>
> Nope. PROPFIND must ignore unknown elements (hint: some servers don't...),
> *except* when child of a DAV:prop or DAV:propname element.

(after the morning coffee...):

...*except* when child of a DAV:prop element.


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



From w3c-dist-auth-request@w3.org  Sat Jan 18 20:04: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 UAA03691
	for <webdav-archive@lists.ietf.org>; Sat, 18 Jan 2003 20:04:40 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0J16MG26340;
	Sat, 18 Jan 2003 20:06:22 -0500 (EST)
Resent-Date: Sat, 18 Jan 2003 20:06:22 -0500 (EST)
Resent-Message-Id: <200301190106.h0J16MG26340@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 h0J16KD26304
	for <w3c-dist-auth@frink.w3.org>; Sat, 18 Jan 2003 20:06: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 UAA10818
	for <w3c-dist-auth@w3.org>; Sat, 18 Jan 2003 20:06:20 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Sat, 18 Jan 2003 19:51:17 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <C8Q553RH>; Sat, 18 Jan 2003 20:05:44 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE201A12159@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Sat, 18 Jan 2003 20:05:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: PROPFIND returning *more* than expected, and other questions
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE201A12159@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7128
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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, as Julian's (revised :-) message states, the revision
should state that the exception to the ignore unknown
element rule applies only to the children of the DAV:prop element.

Cheers,
Geoff

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

> From: Julian Reschke
>
> > From: Lisa Dusseault
> >
> > Sorry, what's the rationale for PROPFIND not ignoring unknown XML
> > elements?  Does this mean anywhere in the propfind body or just in
> > certain places? I assume it's supposed to fail when it sees unknown
> > elements?
> > ...
>
> Nope. PROPFIND must ignore unknown elements (hint: some servers don't...),
> *except* when child of a DAV:prop or DAV:propname element.

(after the morning coffee...):

...*except* when child of a DAV:prop element.



From w3c-dist-auth-request@w3.org  Sun Jan 19 17:36: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 RAA26503
	for <webdav-archive@lists.ietf.org>; Sun, 19 Jan 2003 17:36:45 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0JMcU019331;
	Sun, 19 Jan 2003 17:38:30 -0500 (EST)
Resent-Date: Sun, 19 Jan 2003 17:38:30 -0500 (EST)
Resent-Message-Id: <200301192238.h0JMcU019331@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 h0JMcTD19299
	for <w3c-dist-auth@frink.w3.org>; Sun, 19 Jan 2003 17:38:29 -0500 (EST)
Received: from emfe2.iup.edu (emfe2.cc.iup.edu [144.80.130.20])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA30549
	for <w3c-dist-auth@w3.org>; Sun, 19 Jan 2003 17:38:28 -0500
X-IUP-Tag1: emfe2.cc.iup.edu
Received: from [192.168.30.120] (HELO embe2.iup.edu)
  by emfe2.iup.edu (CommuniGate Pro SMTP 3.5.7)
  with ESMTP id 7527302 for w3c-dist-auth@w3.org; Sun, 19 Jan 2003 17:38:28 -0500
X-IUP-Tag1: embe2.cc.iup.edu
Received: from [128.230.13.199] (account <nndj@iup.edu>)
  by embe2.iup.edu (CommuniGate Pro WebUser 3.5.7)
  with HTTP id 1046217; Sun, 19 Jan 2003 17:38:28 -0500
From: "Baiyan   Huang" <nndj@iup.edu>
To: w3c-dist-auth@w3.org
Cc: nndj@iup.edu
X-Mailer: CommuniGate Pro Web Mailer v.3.5.7
Date: Sun, 19 Jan 2003 17:38:28 -0500
Message-ID: <web-1046217@embe2.iup.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: new to WebDAV
X-Archived-At: http://www.w3.org/mid/web-1046217@embe2.iup.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7129
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 8bit


Hello, 

My name is Baiyan Huang, a college student majored in computer 
science.  Currently, I have a project assignment using WebDAV 
technology to manage serveral websites (those websites are on 
different servers), so that whenever one website updates their own 
news portion, the other websites will be notified by email or 
something else.  The system administrators of the other websites can 
then decide if they want this piece of news to be included in their 
own websites or not.

Since I don't know too much about webdav, please give me some advice. 
Any suggestion is appreciated.

Thank you very much!

Baiyan Huang

***************************************
Baiyan Huang
nndj@iup.edu
baiyanh@hotmail.com
***************************************



From w3c-dist-auth-request@w3.org  Mon Jan 20 12:30: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 MAA24920
	for <webdav-archive@lists.ietf.org>; Mon, 20 Jan 2003 12:30:57 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0KHX3Z02481;
	Mon, 20 Jan 2003 12:33:03 -0500 (EST)
Resent-Date: Mon, 20 Jan 2003 12:33:03 -0500 (EST)
Resent-Message-Id: <200301201733.h0KHX3Z02481@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 h0KHX2D02449
	for <w3c-dist-auth@frink.w3.org>; Mon, 20 Jan 2003 12:33:02 -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 MAA25273
	for <w3c-dist-auth@w3.org>; Mon, 20 Jan 2003 12:33:00 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18afn9-0005n5-00
	for w3c-dist-auth@w3.org; Mon, 20 Jan 2003 17:32:59 +0000
Received: from [216.36.77.241] (helo=mdunn)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18afn8-0005mt-00
	for w3c-dist-auth@w3.org; Mon, 20 Jan 2003 17:32:59 +0000
Reply-To: <mdunn@xythos.com>
From: "Max Dunn" <mdunn@xythos.com>
To: <w3c-dist-auth@w3.org>
Date: Mon, 20 Jan 2003 09:33:04 -0800
Message-ID: <000e01c2c0a9$fd0d0490$7701a8c0@mdunn>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000F_01C2C066.EEE9C490"
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@w3.org
Subject: Jabber chat room
X-Archived-At: http://www.w3.org/mid/000e01c2c0a9$fd0d0490$7701a8c0@mdunn
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7130
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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_000F_01C2C066.EEE9C490
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

 Lisa set up an online chat room for back-channel discussions, so that
people who couldn't be at the Interim WebDAV WG meeting in person can
join in.  
   
 If you've already got a Jabber client, the conference address is: 
  <mailto:webdav@conference.jabber.org> webdav@conference.jabber.org 
   
 How to get and use Jabber: 
  <http://www.jabber.org/user/userguide/>
http://www.jabber.org/user/userguide/ 
   
 There *may* be a gateway still open from a few months ago that MSN
Messenger can use: 
  <http://www.iptel.org/ietf55/> http://www.iptel.org/ietf55/ 
   
 --Max
 

------=_NextPart_000_000F_01C2C066.EEE9C490
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>&nbsp;<SPAN=20
class=3D320113017-20012003>Lisa&nbsp;</SPAN>set up an online chat room =
for=20
back-channel discussions, so that people who couldn't be&nbsp;<SPAN=20
class=3D320113017-20012003>at the&nbsp;Interim WebDAV WG =
meeting</SPAN>&nbsp;in=20
person can join in.&nbsp; <BR>&nbsp;&nbsp; <BR>&nbsp;If you've already =
got a=20
Jabber client, the conference address is: <BR>&nbsp;</FONT><A=20
href=3D"mailto:webdav@conference.jabber.org"><FONT face=3DArial=20
size=3D2>webdav@conference.jabber.org</FONT></A><FONT face=3DArial =
size=3D2>=20
<BR>&nbsp;&nbsp; <BR>&nbsp;How to get and use Jabber: =
<BR>&nbsp;</FONT><A=20
href=3D"http://www.jabber.org/user/userguide/"><FONT face=3DArial=20
size=3D2>http://www.jabber.org/user/userguide/</FONT></A><FONT =
face=3DArial size=3D2>=20
<BR>&nbsp;&nbsp; <BR>&nbsp;There *may* be a gateway still open from a =
few months=20
ago that MSN Messenger can use: <BR>&nbsp;</FONT><A=20
href=3D"http://www.iptel.org/ietf55/"><FONT face=3DArial=20
size=3D2>http://www.iptel.org/ietf55/</FONT></A><FONT face=3DArial=20
size=3D2>&nbsp;<BR>&nbsp;&nbsp;&nbsp;<BR>&nbsp;<SPAN=20
class=3D320113017-20012003>--Max</SPAN><BR>&nbsp;</FONT></DIV></BODY></HT=
ML>

------=_NextPart_000_000F_01C2C066.EEE9C490--




From w3c-dist-auth-request@w3.org  Mon Jan 20 22:52: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 WAA09008
	for <webdav-archive@lists.ietf.org>; Mon, 20 Jan 2003 22:52:11 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0L3rxZ27373;
	Mon, 20 Jan 2003 22:53:59 -0500 (EST)
Resent-Date: Mon, 20 Jan 2003 22:53:59 -0500 (EST)
Resent-Message-Id: <200301210353.h0L3rxZ27373@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 h0L3rwD27341
	for <w3c-dist-auth@frink.w3.org>; Mon, 20 Jan 2003 22:53:58 -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 WAA22281
	for <w3c-dist-auth@w3c.org>; Mon, 20 Jan 2003 22:53:57 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18apU4-0006Sn-00
	for w3c-dist-auth@w3c.org; Tue, 21 Jan 2003 03:53:56 +0000
Received: from [198.144.203.248] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18apU3-0006OI-00
	for w3c-dist-auth@w3c.org; Tue, 21 Jan 2003 03:53:55 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Mon, 20 Jan 2003 19:53:12 -0800
Message-ID: <002101c2c100$b83b25c0$620afea9@xythoslap>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0022_01C2C0BD.AA17E5C0"
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.2600.0000
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Subject: Online Chat Room to augment WG meeting
X-Archived-At: http://www.w3.org/mid/002101c2c100$b83b25c0$620afea9@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7131
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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_0022_01C2C0BD.AA17E5C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I've set up an online chat room for back-channel discussions, and so
that people who couldn't be here in person can join in. 

 

If you've already got a Jabber client, the conference address is:

webdav@conference.jabber.org

 

How to get and use Jabber:

http://www.jabber.org/user/userguide/

 

There *may* be a gateway still open from a few months ago that MSN
Messenger can use:

http://www.iptel.org/ietf55/

 

Lisa


------=_NextPart_000_0022_01C2C0BD.AA17E5C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

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


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

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

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I&#8217;ve set up an online chat room for =
back-channel
discussions, and so that people who couldn&#8217;t be here in person can =
join
in. </span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>If you&#8217;ve already got a Jabber client, the =
conference
address is:</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>webdav@conference.jabber.org</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>How to get and use Jabber:</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>http://www.jabber.org/user/userguide/</span></font></p=
>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>There *<b><span =
style=3D'font-weight:bold'>may</span></b>* be
a gateway still open from a few months ago that MSN Messenger can =
use:</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>http://www.iptel.org/ietf55/</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Lisa</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0022_01C2C0BD.AA17E5C0--




From w3c-dist-auth-request@w3.org  Tue Jan 21 23:02: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 XAA20772
	for <webdav-archive@lists.ietf.org>; Tue, 21 Jan 2003 23:02:27 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0M44le01143;
	Tue, 21 Jan 2003 23:04:47 -0500 (EST)
Resent-Date: Tue, 21 Jan 2003 23:04:47 -0500 (EST)
Resent-Message-Id: <200301220404.h0M44le01143@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 h0M44kD01108
	for <w3c-dist-auth@frink.w3.org>; Tue, 21 Jan 2003 23:04:46 -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 XAA17378
	for <w3c-dist-auth@w3c.org>; Tue, 21 Jan 2003 23:04:45 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18bC84-00061G-00
	for w3c-dist-auth@w3c.org; Wed, 22 Jan 2003 04:04:44 +0000
Received: from [198.144.203.248] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18bC83-000608-00
	for w3c-dist-auth@w3c.org; Wed, 22 Jan 2003 04:04:43 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Tue, 21 Jan 2003 20:04:37 -0800
Message-ID: <000601c2c1cb$6464e190$620afea9@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.2600.0000
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Subject: RSync proposal for synchronization, may support partial PUT
X-Archived-At: http://www.w3.org/mid/000601c2c1cb$6464e190$620afea9@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7132
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


 

In the WG meeting I mentioned this proposal & promised to send the link:

 

http://www.sharemation.com/~milele/public/rsync-specification.htm

 

The RSync stuff can also be used to do partial uploads very securely, by
uploading just a chunk of the original file, waiting for a success, then
start to upload XDeltas until it's done.

 

lisa





From w3c-dist-auth-request@w3.org  Tue Jan 21 23:31: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 XAA21166
	for <webdav-archive@lists.ietf.org>; Tue, 21 Jan 2003 23:31:43 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0M4YGh05278;
	Tue, 21 Jan 2003 23:34:16 -0500 (EST)
Resent-Date: Tue, 21 Jan 2003 23:34:16 -0500 (EST)
Resent-Message-Id: <200301220434.h0M4YGh05278@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 h0M4YFD05245
	for <w3c-dist-auth@frink.w3.org>; Tue, 21 Jan 2003 23:34: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 XAA21922
	for <w3c-dist-auth@w3c.org>; Tue, 21 Jan 2003 23:34:14 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18bCab-0006Eo-00
	for w3c-dist-auth@w3c.org; Wed, 22 Jan 2003 04:34:13 +0000
Received: from [198.144.203.248] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18bCaa-0006Ed-00
	for w3c-dist-auth@w3c.org; Wed, 22 Jan 2003 04:34:13 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Tue, 21 Jan 2003 20:34:10 -0800
Message-ID: <000001c2c1cf$82d98640$620afea9@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.2600.0000
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Subject: Collections ending in slashes: consensus reversal?
X-Archived-At: http://www.w3.org/mid/000001c2c1cf$82d98640$620afea9@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7133
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit



At the Interop working group meeting several months ago, the consensus
of those attendees was that servers should be more strongly encouraged
to consistently end collection URLs with trailing slashes (TS).
Presumably this would replace some instances of SHOULD with MUST etc.

Today however, a different group of WG attendees came to the opposite
conclusion: that servers aren't going to get better at this (they
already have their reasons if they're not using TS consistently, e.g.
performance concerns of finding out if an internal resource is a
collection).  If servers won't get any better, then it's more pragmatic
to encourage clients to check for the TS all the time. Under this view,
clients should be easily capable of examining the TS before
concatenating the name of a new resource they're about to create.
Resource type is the correct way to determine whether a resource is a
collection.

There is some fallout if we move to the model of saying that it doesn't
matter whether the server uses a TS ending or not.  For example, if a
client creates a collection without a TS, and the server prefers to use
TS the server should respond with Content-Location and the "normal" name
for the collection. Also, vice versa. This means that the client knows
what to expect if it then does a PROPFIND on the resource. 

In other words, this puts the onus for handling TS on the client. 

I'd like to see some discussion if people have anything to add, or
summary of advantages & such. I'm thinking probably a straw poll shortly
if Jim concurs.

Lisa




From w3c-dist-auth-request@w3.org  Tue Jan 21 23:58: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 XAA21642
	for <webdav-archive@lists.ietf.org>; Tue, 21 Jan 2003 23:58:34 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0M518i08139;
	Wed, 22 Jan 2003 00:01:08 -0500 (EST)
Resent-Date: Wed, 22 Jan 2003 00:01:08 -0500 (EST)
Resent-Message-Id: <200301220501.h0M518i08139@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 h0M517D08085
	for <w3c-dist-auth@frink.w3.org>; Wed, 22 Jan 2003 00:01:07 -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 AAA25713
	for <w3c-dist-auth@w3c.org>; Wed, 22 Jan 2003 00:01:06 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18bD0b-0006YD-00
	for w3c-dist-auth@w3c.org; Wed, 22 Jan 2003 05:01:05 +0000
Received: from [198.144.203.248] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18bD0b-0006Y2-00
	for w3c-dist-auth@w3c.org; Wed, 22 Jan 2003 05:01:05 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Tue, 21 Jan 2003 21:01:03 -0800
Message-ID: <000c01c2c1d3$441aea30$620afea9@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.2600.0000
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Subject: Issue OVERLAP_5.3_AND_8.7.2 can be closed "Irrelevant"
X-Archived-At: http://www.w3.org/mid/000c01c2c1d3$441aea30$620afea9@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7134
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 don't see any more overlap in wording in these sections, probably
because 5.3 has been rewritten. I think this issue can be resolved
somehow now or when RFC2518bis-03 comes out.

 

Lisa





From w3c-dist-auth-request@w3.org  Wed Jan 22 00:03: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 AAA21714
	for <webdav-archive@lists.ietf.org>; Wed, 22 Jan 2003 00:03:56 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0M56V508874;
	Wed, 22 Jan 2003 00:06:31 -0500 (EST)
Resent-Date: Wed, 22 Jan 2003 00:06:31 -0500 (EST)
Resent-Message-Id: <200301220506.h0M56V508874@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 h0M56UD08840
	for <w3c-dist-auth@frink.w3.org>; Wed, 22 Jan 2003 00:06: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 AAA26552
	for <w3c-dist-auth@w3c.org>; Wed, 22 Jan 2003 00:06:30 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18bD5p-0006by-00
	for w3c-dist-auth@w3c.org; Wed, 22 Jan 2003 05:06:29 +0000
Received: from [198.144.203.248] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18bD5o-0006bn-00
	for w3c-dist-auth@w3c.org; Wed, 22 Jan 2003 05:06:28 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Tue, 21 Jan 2003 21:06:26 -0800
Message-ID: <000d01c2c1d4$04b259e0$620afea9@xythoslap>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000E_01C2C190.F68F19E0"
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.2600.0000
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Subject: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and INTEROP_DELETE_AND_MULTISTATUS
X-Archived-At: http://www.w3.org/mid/000d01c2c1d4$04b259e0$620afea9@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7135
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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_01C2C190.F68F19E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Issue PUT_AND_INTERMEDIATE_COLLECTIONS: this issue was a request to
allow PUT to create intermediate collections. I believe there is no
consensus to do this and we should resolve this wont' fix.

 

Issue INTEROP_DELETE_AND_MULTISTATUS: this issue is a request for DELETE
errors to be 4xx so that HTTP clients don't think 207 is a success.
That's no longer really an issue - few HTTP clients do authoring, and
those that do are at least aware that 207 is a multistatus response and
not a complete success. We should resolve this won't fix.

 

Considering only the meeting attendees today, there's consensus so far.

 

lisa


------=_NextPart_000_000E_01C2C190.F68F19E0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

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


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

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

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Issue PUT_AND_INTERMEDIATE_COLLECTIONS: this issue =
was a
request to allow PUT to create intermediate collections. I believe there =
is no
consensus to do this and we should resolve this wont&#8217; =
fix.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Issue INTEROP_DELETE_AND_MULTISTATUS: this issue is a
request for DELETE errors to be 4xx so that HTTP clients don&#8217;t =
think 207
is a success. That&#8217;s no longer really an issue &#8211; few HTTP =
clients do
authoring, and those that do are at least aware that 207 is a =
multistatus
response and not a complete success. We should resolve this won&#8217;t =
fix.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Considering only the meeting attendees today, =
there&#8217;s
consensus so far.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>lisa</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_000E_01C2C190.F68F19E0--




From w3c-dist-auth-request@w3.org  Wed Jan 22 04:30: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 EAA20207
	for <webdav-archive@lists.ietf.org>; Wed, 22 Jan 2003 04:30:03 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0M9WPW24851;
	Wed, 22 Jan 2003 04:32:25 -0500 (EST)
Resent-Date: Wed, 22 Jan 2003 04:32:25 -0500 (EST)
Resent-Message-Id: <200301220932.h0M9WPW24851@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 h0M9WND24802
	for <w3c-dist-auth@frink.w3.org>; Wed, 22 Jan 2003 04:32:23 -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 EAA11540
	for <w3c-dist-auth@w3c.org>; Wed, 22 Jan 2003 04:32:22 -0500
Received: from apache.org (localhost [127.0.0.1])
	by mac.wakasoft.com (8.12.2/8.12.2) with ESMTP id h0M7lt4v007792;
	Tue, 21 Jan 2003 23:47:55 -0800 (PST)
Date: Tue, 21 Jan 2003 23:47:54 -0800
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
To: "Lisa Dusseault" <lisa@xythos.com>
From: "Roy T. Fielding" <fielding@apache.org>
In-Reply-To: <000d01c2c1d4$04b259e0$620afea9@xythoslap>
Message-Id: <D0F13C3A-2DDD-11D7-9535-000393753936@apache.org>
X-Mailer: Apple Mail (2.551)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h0M9WND24802
Subject: Re: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and INTEROP_DELETE_AND_MULTISTATUS
X-Archived-At: http://www.w3.org/mid/D0F13C3A-2DDD-11D7-9535-000393753936@apache.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7137
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


> Issue INTEROP_DELETE_AND_MULTISTATUS: this issue is a request for 
> DELETE errors to be 4xx so that HTTP clients don’t think 207 is a 
> success. That’s no longer really an issue – few HTTP clients do 
> authoring, and those that do are at least aware that 207 is a 
> multistatus response and not a complete success. We should resolve 
> this won’t fix.

Doing that violates the HTTP protocol, not WebDAV.

....Roy



From w3c-dist-auth-request@w3.org  Wed Jan 22 04:30: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 EAA20221
	for <webdav-archive@lists.ietf.org>; Wed, 22 Jan 2003 04:30:06 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0M9WN224796;
	Wed, 22 Jan 2003 04:32:23 -0500 (EST)
Resent-Date: Wed, 22 Jan 2003 04:32:23 -0500 (EST)
Resent-Message-Id: <200301220932.h0M9WN224796@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 h0M9WMD24764
	for <w3c-dist-auth@frink.w3.org>; Wed, 22 Jan 2003 04:32:22 -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 EAA11538
	for <w3c-dist-auth@w3c.org>; Wed, 22 Jan 2003 04:32:21 -0500
Received: from apache.org (localhost [127.0.0.1])
	by mac.wakasoft.com (8.12.2/8.12.2) with ESMTP id h0M7Yb4v007790;
	Tue, 21 Jan 2003 23:34:37 -0800 (PST)
Date: Tue, 21 Jan 2003 23:34:36 -0800
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
To: "Lisa Dusseault" <lisa@xythos.com>
From: "Roy T. Fielding" <fielding@apache.org>
In-Reply-To: <000001c2c1cf$82d98640$620afea9@xythoslap>
Message-Id: <F54DAEDC-2DDB-11D7-9535-000393753936@apache.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Subject: Re: Collections ending in slashes: consensus reversal?
X-Archived-At: http://www.w3.org/mid/F54DAEDC-2DDB-11D7-9535-000393753936@apache.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7136
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


What is a resource type?

....Roy

p.s. it is impossible to reach WG consensus at a face-to-face meeting,
even a regular one.



From w3c-dist-auth-request@w3.org  Wed Jan 22 09:01: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 JAA25095
	for <webdav-archive@lists.ietf.org>; Wed, 22 Jan 2003 09:01:37 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0ME3xp09966;
	Wed, 22 Jan 2003 09:03:59 -0500 (EST)
Resent-Date: Wed, 22 Jan 2003 09:03:59 -0500 (EST)
Resent-Message-Id: <200301221403.h0ME3xp09966@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 h0ME3uD09892
	for <w3c-dist-auth@frink.w3.org>; Wed, 22 Jan 2003 09:03:56 -0500 (EST)
Received: from smtp-server1.tampabay.rr.com (smtp-server1.tampabay.rr.com [65.32.1.34])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA06236
	for <w3c-dist-auth@w3c.org>; Wed, 22 Jan 2003 09:03:54 -0500
Received: from [192.168.123.112] (rrcs-se-24-73-169-210.biz.rr.com [24.73.169.210])
	by smtp-server1.tampabay.rr.com (8.12.2/8.12.2) with ESMTP id h0ME3f48016286;
	Wed, 22 Jan 2003 09:03:41 -0500 (EST)
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.0.5
Date: Wed, 22 Jan 2003 09:03:26 -0500
From: Matthew Wiseman <matt@potatopub.com>
To: "Roy T. Fielding" <fielding@apache.org>, Lisa Dusseault <lisa@xythos.com>
CC: Webdav WG <w3c-dist-auth@w3c.org>
Message-ID: <BA540EDE.11C0%matt@potatopub.com>
In-Reply-To: <F54DAEDC-2DDB-11D7-9535-000393753936@apache.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: Collections ending in slashes: consensus reversal?
X-Archived-At: http://www.w3.org/mid/BA540EDE.11C0%matt@potatopub.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7138
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


Can someone tell me how to get off this list? I've tried a couple of times.
I'm sure you are all fine people, but this is not information I need. Thanks
for your kind help and generosity.
-- 
Matthew Wiseman, President
Potato Communications, Inc.



From w3c-dist-auth-request@w3.org  Wed Jan 22 10:14: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 KAA27230
	for <webdav-archive@lists.ietf.org>; Wed, 22 Jan 2003 10:14:20 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0MFGnd01528;
	Wed, 22 Jan 2003 10:16:49 -0500 (EST)
Resent-Date: Wed, 22 Jan 2003 10:16:49 -0500 (EST)
Resent-Message-Id: <200301221516.h0MFGnd01528@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 h0MFGmD01496
	for <w3c-dist-auth@frink.w3.org>; Wed, 22 Jan 2003 10:16:48 -0500 (EST)
Received: from mailhost.lowell.edu (pluto.lowell.edu [65.121.24.71])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA02101
	for <w3c-dist-auth@w3c.org>; Wed, 22 Jan 2003 10:16:47 -0500
Received: from mailhub.public.lowellnet (mailhub.public.lowellnet [192.168.100.7])
	by mailhost.lowell.edu (8.12.5/8.12.5) with ESMTP id h0MFEIbp024516
	for <w3c-dist-auth@w3c.org>; Wed, 22 Jan 2003 08:14:19 -0700 (MST)
Received: from dc3.com ([192.168.1.174])
	by mailhub.public.lowellnet (8.12.2/8.12.5) with ESMTP id h0MFGCbl001315
	for <w3c-dist-auth@w3c.org>; Wed, 22 Jan 2003 08:16:12 -0700 (MST)
Message-ID: <3E2EB5DD.2030509@dc3.com>
Date: Wed, 22 Jan 2003 08:16:45 -0700
From: Bob Denny <rdenny@dc3.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: w3c-dist-auth@w3c.org
References: <D0F13C3A-2DDD-11D7-9535-000393753936@apache.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and INTEROP_DELETE_AND_MULTISTATUS
X-Archived-At: http://www.w3.org/mid/3E2EB5DD.2030509@dc3.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7139
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


Lisa Dusseault:
> few HTTP clients do authoring, and those that do are at least aware that
> 207 is a multistatus response

Netscape/Mozilla Composer is an HTTP authoring tool that is not aware of 207.

Roy T. Fielding:
> Doing that violates the HTTP protocol, not WebDAV.

Yes, and let's not.

  -- Bob





From w3c-dist-auth-request@w3.org  Wed Jan 22 10:37: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 KAA28212
	for <webdav-archive@lists.ietf.org>; Wed, 22 Jan 2003 10:37:23 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0MFdtR05703;
	Wed, 22 Jan 2003 10:39:55 -0500 (EST)
Resent-Date: Wed, 22 Jan 2003 10:39:55 -0500 (EST)
Resent-Message-Id: <200301221539.h0MFdtR05703@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 h0MFdsD05671
	for <w3c-dist-auth@frink.w3.org>; Wed, 22 Jan 2003 10:39: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 KAA07812
	for <w3c-dist-auth@w3c.org>; Wed, 22 Jan 2003 10:39:53 -0500
Received: (qmail 7491 invoked by uid 0); 22 Jan 2003 15:39:22 -0000
Received: from unknown (HELO lisa) (12.36.113.53)
  by mail.gmx.net (mp023-rz3) with SMTP; 22 Jan 2003 15:39:22 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Roy T. Fielding" <fielding@apache.org>,
        "Lisa Dusseault" <lisa@xythos.com>
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Wed, 22 Jan 2003 16:39:09 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCOEELGEAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <D0F13C3A-2DDD-11D7-9535-000393753936@apache.org>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and INTEROP_DELETE_AND_MULTISTATUS
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEELGEAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7140
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


But then, HTTP does not define the concept of collections and deep deletes.
WebDAV is an extension of HTTP, so when it introduces these new concepts,
isn't it allowed also to define error handling for it?

Yes, there's an issue with using a 2xx status for errors, but it doesn't
seem to have negatively affected any existing client I'm aware of.
RFC2518bis is supposed to clarify RFC2518, not to reinvent it.

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: Wednesday, January 22, 2003 8:48 AM
> To: Lisa Dusseault
> Cc: 'Webdav WG'
> Subject: Re: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and
> INTEROP_DELETE_AND_MULTISTATUS
>
>
>
> > Issue INTEROP_DELETE_AND_MULTISTATUS: this issue is a request for
> > DELETE errors to be 4xx so that HTTP clients don’t think 207 is a
> > success. That’s no longer really an issue – few HTTP clients do
> > authoring, and those that do are at least aware that 207 is a
> > multistatus response and not a complete success. We should resolve
> > this won’t fix.
>
> Doing that violates the HTTP protocol, not WebDAV.
>
> ....Roy
>



From w3c-dist-auth-request@w3.org  Wed Jan 22 10:42: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 KAA28320
	for <webdav-archive@lists.ietf.org>; Wed, 22 Jan 2003 10:42:01 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0MFicP06860;
	Wed, 22 Jan 2003 10:44:38 -0500 (EST)
Resent-Date: Wed, 22 Jan 2003 10:44:38 -0500 (EST)
Resent-Message-Id: <200301221544.h0MFicP06860@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 h0MFibD06828
	for <w3c-dist-auth@frink.w3.org>; Wed, 22 Jan 2003 10:44:37 -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 KAA09782
	for <w3c-dist-auth@w3c.org>; Wed, 22 Jan 2003 10:44:37 -0500
Received: (qmail 29400 invoked by uid 0); 22 Jan 2003 15:44:04 -0000
Received: from unknown (HELO lisa) (12.36.113.53)
  by mail.gmx.net (mp016-rz3) with SMTP; 22 Jan 2003 15:44:04 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Roy T. Fielding" <fielding@apache.org>,
        "Lisa Dusseault" <lisa@xythos.com>
Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Wed, 22 Jan 2003 16:43:47 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCEEEMGEAA.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: <F54DAEDC-2DDB-11D7-9535-000393753936@apache.org>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: RE: Collections ending in slashes: consensus reversal?
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEEMGEAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7141
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 Roy T. Fielding
> Sent: Wednesday, January 22, 2003 8:35 AM
> To: Lisa Dusseault
> Cc: Webdav WG
> Subject: Re: Collections ending in slashes: consensus reversal?
>
>
>
> What is a resource type?

The concept defined by RFC2518, section 13.9. Specifically, a resource with
type DAV:collection is a WebDAV (something where when you apply PROPFIND
depth 1, internal members are going to be enumerated).

> ....Roy
>
> p.s. it is impossible to reach WG consensus at a face-to-face meeting,
> even a regular one.

So do you have any guidance how a working group is supposed to resolve open
issues, if not by face-to-face and on-the-mailing list discussions?



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



From w3c-dist-auth-request@w3.org  Wed Jan 22 10:48: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 KAA28524
	for <webdav-archive@lists.ietf.org>; Wed, 22 Jan 2003 10:48:07 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0MFoU308265;
	Wed, 22 Jan 2003 10:50:30 -0500 (EST)
Resent-Date: Wed, 22 Jan 2003 10:50:30 -0500 (EST)
Resent-Message-Id: <200301221550.h0MFoU308265@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 h0MFoTD08230
	for <w3c-dist-auth@frink.w3.org>; Wed, 22 Jan 2003 10:50: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 KAA11472
	for <w3c-dist-auth@w3c.org>; Wed, 22 Jan 2003 10:50:22 -0500
Received: (qmail 24279 invoked by uid 0); 22 Jan 2003 15:49:50 -0000
Received: from unknown (HELO lisa) (12.36.113.53)
  by mail.gmx.net (mp018-rz3) with SMTP; 22 Jan 2003 15:49:50 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Bob Denny" <rdenny@dc3.com>, <w3c-dist-auth@w3c.org>
Date: Wed, 22 Jan 2003 16:49:41 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCMEEMGEAA.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: <3E2EB5DD.2030509@dc3.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and INTEROP_DELETE_AND_MULTISTATUS
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEEMGEAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7142
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 Bob Denny
> Sent: Wednesday, January 22, 2003 4:17 PM
> To: w3c-dist-auth@w3c.org
> Subject: Re: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and
> INTEROP_DELETE_AND_MULTISTATUS
>
>
>
> Lisa Dusseault:
> > few HTTP clients do authoring, and those that do are at least aware that
> > 207 is a multistatus response
>
> Netscape/Mozilla Composer is an HTTP authoring tool that is not
> aware of 207.

Yes. But as far as I understand it's abandoned as well. The solution here is
to make sure that when/if Mozilla 1.x starts supporting authoring again, it
will pay attention to RFC2518 semantics.

I think your comments show a misunderstanding of the RFC process here.
RFC2518 is being revised. Things that don't work or haven't been
interoperably supported are thrown out. Things that need to be clarified are
clarified. That's it.


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



From w3c-dist-auth-request@w3.org  Wed Jan 22 15:19: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 PAA05900
	for <webdav-archive@lists.ietf.org>; Wed, 22 Jan 2003 15:19:44 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0MKLB200958;
	Wed, 22 Jan 2003 15:21:11 -0500 (EST)
Resent-Date: Wed, 22 Jan 2003 15:21:11 -0500 (EST)
Resent-Message-Id: <200301222021.h0MKLB200958@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 h0MKLAD00926
	for <w3c-dist-auth@frink.w3.org>; Wed, 22 Jan 2003 15:21:10 -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 PAA06934
	for <w3c-dist-auth@w3c.org>; Wed, 22 Jan 2003 15:21:10 -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 h0MKKwH14661;
	Wed, 22 Jan 2003 12:20:58 -0800 (PST)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "Roy T. Fielding" <fielding@apache.org>
Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Wed, 22 Jan 2003 12:16:46 -0800
Message-ID: <AMEPKEBLDJJCCDEJHAMIMEOFGDAA.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
In-Reply-To: <F54DAEDC-2DDB-11D7-9535-000393753936@apache.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-UCSC-CATS-MailScanner: Found to be clean
Subject: RE: Collections ending in slashes: consensus reversal?
X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIMEOFGDAA.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7143
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit



> What is a resource type?

RFC 2518, Sections 13.9 and 12.2.

> p.s. it is impossible to reach WG consensus at a face-to-face meeting,
> even a regular one.

Lisa was very careful to state that it was meeting attendees, not the WG,
reaching consensus.

- Jim



From w3c-dist-auth-request@w3.org  Wed Jan 22 16:32: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 QAA07979
	for <webdav-archive@lists.ietf.org>; Wed, 22 Jan 2003 16:32:20 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0MLYq313404;
	Wed, 22 Jan 2003 16:34:52 -0500 (EST)
Resent-Date: Wed, 22 Jan 2003 16:34:52 -0500 (EST)
Resent-Message-Id: <200301222134.h0MLYq313404@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 h0MLYoD13368
	for <w3c-dist-auth@frink.w3.org>; Wed, 22 Jan 2003 16:34:50 -0500 (EST)
Received: from mac.wakasoft.com (ip68-4-74-14.oc.oc.cox.net [68.4.74.14])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA27152
	for <w3c-dist-auth@w3c.org>; Wed, 22 Jan 2003 16:34:49 -0500
Received: from apache.org (localhost [127.0.0.1])
	by mac.wakasoft.com (8.12.2/8.12.2) with ESMTP id h0MKEM4v007879;
	Wed, 22 Jan 2003 12:14:23 -0800 (PST)
Date: Wed, 22 Jan 2003 12:14:22 -0800
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: "Lisa Dusseault" <lisa@xythos.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
To: "Julian Reschke" <julian.reschke@gmx.de>
From: "Roy T. Fielding" <fielding@apache.org>
In-Reply-To: <JIEGINCHMLABHJBIGKBCOEELGEAA.julian.reschke@gmx.de>
Message-Id: <189AB0C3-2E46-11D7-BEAC-000393753936@apache.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Subject: Re: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and INTEROP_DELETE_AND_MULTISTATUS
X-Archived-At: http://www.w3.org/mid/189AB0C3-2E46-11D7-BEAC-000393753936@apache.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7144
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


> But then, HTTP does not define the concept of collections and deep 
> deletes.
> WebDAV is an extension of HTTP, so when it introduces these new 
> concepts,
> isn't it allowed also to define error handling for it?
>
> Yes, there's an issue with using a 2xx status for errors, but it 
> doesn't
> seem to have negatively affected any existing client I'm aware of.
> RFC2518bis is supposed to clarify RFC2518, not to reinvent it.

WebDAV can add new status codes.  It cannot redifine the meaning of 2xx
status codes.  Doing so destroys one of the main extensibility
mechanisms of HTTP.

It negatively affects any client that proceeds with later actions
based on the status being successful.  WebDAV hasn't seen it yet
because it is still working on first-generation systems and performance
is not yet a deciding factor between implementations.

....Roy



From w3c-dist-auth-request@w3.org  Wed Jan 22 17:01: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 RAA09155
	for <webdav-archive@lists.ietf.org>; Wed, 22 Jan 2003 17:01:26 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0MM45L21073;
	Wed, 22 Jan 2003 17:04:05 -0500 (EST)
Resent-Date: Wed, 22 Jan 2003 17:04:05 -0500 (EST)
Resent-Message-Id: <200301222204.h0MM45L21073@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 h0MM44D21025
	for <w3c-dist-auth@frink.w3.org>; Wed, 22 Jan 2003 17:04:04 -0500 (EST)
Received: from mac.wakasoft.com (ip68-4-74-14.oc.oc.cox.net [68.4.74.14])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA03514
	for <w3c-dist-auth@w3c.org>; Wed, 22 Jan 2003 17:04:03 -0500
Received: from apache.org (localhost [127.0.0.1])
	by mac.wakasoft.com (8.12.2/8.12.2) with ESMTP id h0MK9l4v007878;
	Wed, 22 Jan 2003 12:09:48 -0800 (PST)
Date: Wed, 22 Jan 2003 12:09:47 -0800
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: "Lisa Dusseault" <lisa@xythos.com>, "Webdav WG" <w3c-dist-auth@w3c.org>
To: "Julian Reschke" <julian.reschke@gmx.de>
From: "Roy T. Fielding" <fielding@apache.org>
In-Reply-To: <JIEGINCHMLABHJBIGKBCEEEMGEAA.julian.reschke@gmx.de>
Message-Id: <74647F0A-2E45-11D7-BEAC-000393753936@apache.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Subject: Re: Collections ending in slashes: consensus reversal?
X-Archived-At: http://www.w3.org/mid/74647F0A-2E45-11D7-BEAC-000393753936@apache.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7145
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


>> What is a resource type?
>
> The concept defined by RFC2518, section 13.9. Specifically, a resource 
> with
> type DAV:collection is a WebDAV (something where when you apply 
> PROPFIND
> depth 1, internal members are going to be enumerated).

Then the issue should state that, not "resource type".  It has to be 
something
that the server has specifically told the client.

>> p.s. it is impossible to reach WG consensus at a face-to-face meeting,
>> even a regular one.
>
> So do you have any guidance how a working group is supposed to resolve 
> open
> issues, if not by face-to-face and on-the-mailing list discussions?

We discuss them in both places (and in the hallways), and only poll for
consensus on the mailing list.  Otherwise, you'll just piss off the 
people
who don't have enough money to attend F2F meetings.

....Roy



From w3c-dist-auth-request@w3.org  Wed Jan 22 17:10: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 RAA09376
	for <webdav-archive@lists.ietf.org>; Wed, 22 Jan 2003 17:10:15 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0MMCqs22317;
	Wed, 22 Jan 2003 17:12:52 -0500 (EST)
Resent-Date: Wed, 22 Jan 2003 17:12:52 -0500 (EST)
Resent-Message-Id: <200301222212.h0MMCqs22317@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 h0MMCpD22285
	for <w3c-dist-auth@frink.w3.org>; Wed, 22 Jan 2003 17:12:51 -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 RAA05553
	for <w3c-dist-auth@w3c.org>; Wed, 22 Jan 2003 17:12:51 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 22 Jan 2003 16:57:39 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <C8Q6BJWK>; Wed, 22 Jan 2003 17:12:15 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE201A1271A@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: Webdav WG <w3c-dist-auth@w3c.org>
Date: Wed, 22 Jan 2003 17:12:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: Collections ending in slashes
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE201A1271A@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7146
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


As probably comes as no surprise to those who have heard me
rant about this in the past, I strongly support this proposal
to allow servers to decide whether or not a collection URL is
slash terminated.

   From: Roy T. Fielding [mailto:fielding@apache.org]

   What is a resource type?

The value of the DAV:resourcetype property of a resource.

   p.s. it is impossible to reach WG consensus at a face-to-face
   meeting, even a regular one.

True.  In the body of her note, Lisa did not make any claim to
working group consensus (only "the consensus of those attendees
was ..."), but I agree that the subject line gave the impression
that it was referring to working group consensus.  (I removed the
offending phrase from the subject line of my response).

Cheers,
Geoff


-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Subject: Re: Collections ending in slashes: consensus reversal?

At the Interop working group meeting several months ago, the consensus
of those attendees was that servers should be more strongly encouraged
to consistently end collection URLs with trailing slashes (TS).
Presumably this would replace some instances of SHOULD with MUST etc.

Today however, a different group of WG attendees came to the opposite
conclusion: that servers aren't going to get better at this (they
already have their reasons if they're not using TS consistently, e.g.
performance concerns of finding out if an internal resource is a
collection).  If servers won't get any better, then it's more pragmatic
to encourage clients to check for the TS all the time. Under this view,
clients should be easily capable of examining the TS before
concatenating the name of a new resource they're about to create.
Resource type is the correct way to determine whether a resource is a
collection.

There is some fallout if we move to the model of saying that it doesn't
matter whether the server uses a TS ending or not.  For example, if a
client creates a collection without a TS, and the server prefers to use
TS the server should respond with Content-Location and the "normal" name
for the collection. Also, vice versa. This means that the client knows
what to expect if it then does a PROPFIND on the resource. 

In other words, this puts the onus for handling TS on the client. 

I'd like to see some discussion if people have anything to add, or
summary of advantages & such. I'm thinking probably a straw poll shortly
if Jim concurs.

Lisa



From w3c-dist-auth-request@w3.org  Thu Jan 23 09:37: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 JAA08866
	for <webdav-archive@lists.ietf.org>; Thu, 23 Jan 2003 09:37:37 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0NEdwE14287;
	Thu, 23 Jan 2003 09:39:58 -0500 (EST)
Resent-Date: Thu, 23 Jan 2003 09:39:58 -0500 (EST)
Resent-Message-Id: <200301231439.h0NEdwE14287@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 h0NEduD14252
	for <w3c-dist-auth@frink.w3.org>; Thu, 23 Jan 2003 09:39:56 -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 JAA09940
	for <w3c-dist-auth@w3c.org>; Thu, 23 Jan 2003 09:39:56 -0500
Received: (qmail 10053 invoked by uid 0); 23 Jan 2003 14:39:24 -0000
Received: from p3EE2483D.dip.t-dialin.net (HELO lisa) (62.226.72.61)
  by mail.gmx.net (mp013-rz3) with SMTP; 23 Jan 2003 14:39:24 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Roy T. Fielding" <fielding@apache.org>,
        "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Lisa Dusseault" <lisa@xythos.com>, "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Thu, 23 Jan 2003 15:39:20 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCCEJIGEAA.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: <74647F0A-2E45-11D7-BEAC-000393753936@apache.org>
Importance: Normal
Subject: RE: Collections ending in slashes: consensus reversal?
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEJIGEAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7147
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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: Roy T. Fielding [mailto:fielding@apache.org]
> Sent: Wednesday, January 22, 2003 9:10 PM
> To: Julian Reschke
> Cc: Lisa Dusseault; Webdav WG
> Subject: Re: Collections ending in slashes: consensus reversal?
>
> ...
>
> We discuss them in both places (and in the hallways), and only poll for
> consensus on the mailing list.  Otherwise, you'll just piss off the
people

I think this is what we are doing.

> who don't have enough money to attend F2F meetings.

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



From w3c-dist-auth-request@w3.org  Thu Jan 23 10:41: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 KAA10510
	for <webdav-archive@lists.ietf.org>; Thu, 23 Jan 2003 10:41:16 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0NFhkn25246;
	Thu, 23 Jan 2003 10:43:46 -0500 (EST)
Resent-Date: Thu, 23 Jan 2003 10:43:46 -0500 (EST)
Resent-Message-Id: <200301231543.h0NFhkn25246@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 h0NFhiD25192
	for <w3c-dist-auth@frink.w3.org>; Thu, 23 Jan 2003 10:43:44 -0500 (EST)
Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA26517
	for <w3c-dist-auth@w3c.org>; Thu, 23 Jan 2003 10:43:44 -0500
Received: from user-1120j5p.dsl.mindspring.com ([66.32.76.185] helo=[192.168.1.6])
	by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 18bjW2-0005us-00
	for w3c-dist-auth@w3c.org; Thu, 23 Jan 2003 07:43:42 -0800
Mime-Version: 1.0
X-Sender: desoi@icx.net@mailhub.icx.net
Message-Id: <p05200f00ba559bb472db@[192.168.1.7]>
In-Reply-To: <JIEGINCHMLABHJBIGKBCMEEMGEAA.julian.reschke@gmx.de>
References: <JIEGINCHMLABHJBIGKBCMEEMGEAA.julian.reschke@gmx.de>
Date: Thu, 23 Jan 2003 08:24:47 -0500
To: <w3c-dist-auth@w3c.org>
From: John DeSoi <desoi@icx.net>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and  INTEROP_DELETE_AND_MULTISTATUS
X-Archived-At: http://www.w3.org/mid/p05200f00ba559bb472db@[192.168.1.7]
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7148
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 4:49 PM +0100 1/22/03, Julian Reschke wrote:
>  > Lisa Dusseault:
>>  > few HTTP clients do authoring, and those that do are at least aware that
>>  > 207 is a multistatus response
>>
>>  Netscape/Mozilla Composer is an HTTP authoring tool that is not
>>  aware of 207.
>
>Yes. But as far as I understand it's abandoned as well. The solution here is
>to make sure that when/if Mozilla 1.x starts supporting authoring again, it
>will pay attention to RFC2518 semantics.

Netscape/Mozilla still supports editing with Composer and works fine 
with my WebDAV server (using HTTP PUT). I don't believe it supports a 
DELETE method; but since HTTP does define a DELETE method, I don't 
see how WebDAV can justify redefining the meaning of 2xx status codes.

Best,

John DeSoi, Ph.D.



From w3c-dist-auth-request@w3.org  Thu Jan 23 12:36: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 MAA14293
	for <webdav-archive@lists.ietf.org>; Thu, 23 Jan 2003 12:36:34 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0NHcmj15436;
	Thu, 23 Jan 2003 12:38:48 -0500 (EST)
Resent-Date: Thu, 23 Jan 2003 12:38:48 -0500 (EST)
Resent-Message-Id: <200301231738.h0NHcmj15436@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 h0NHckD15403
	for <w3c-dist-auth@frink.w3.org>; Thu, 23 Jan 2003 12:38:46 -0500 (EST)
Received: from server1.minnesota ([216.17.81.67])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA28908
	for <w3c-dist-auth@w3.org>; Thu, 23 Jan 2003 12:38:46 -0500
Received: by SERVER1 with Internet Mail Service (5.5.2653.19)
	id <475GW8PC>; Thu, 23 Jan 2003 11:31:56 -0600
Message-ID: <E1311B24AA00D511971D00E081107CD4792EF9@SERVER1>
From: Sue Applebaum <sapplebaum@rzsolutions.com>
To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
Date: Thu, 23 Jan 2003 11:31:55 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: WebDav and Dreamweaver
X-Archived-At: http://www.w3.org/mid/E1311B24AA00D511971D00E081107CD4792EF9@SERVER1
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7149
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 am a parent volunteer who develops the website for my son's school.  The
district administrator tells me I need to use Webdav protocol to connect to
the Zope server.  My problem is I cannot determine the correct syntax that
DreamWeaver wants for the URL.   Is anyone out there using that and could
help me?  I am using the newest version of DreamWeaver MX.

I have tried this - http://sitename.org/directory name/:port number

Thanks,

Sue Applebaum
Manager, Technical and Training Services
RZ Solutions
Phone:  763-923-2330
Fax:  763-923-2301
Email:  sapplebaum@rzsolutions.com <sapplebaum@rzsolutions.com> 



From w3c-dist-auth-request@w3.org  Thu Jan 23 13:16:22 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 NAA15528
	for <webdav-archive@lists.ietf.org>; Thu, 23 Jan 2003 13:16:21 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0NIIkl24393;
	Thu, 23 Jan 2003 13:18:46 -0500 (EST)
Resent-Date: Thu, 23 Jan 2003 13:18:46 -0500 (EST)
Resent-Message-Id: <200301231818.h0NIIkl24393@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 h0NIIjD24361
	for <w3c-dist-auth@frink.w3.org>; Thu, 23 Jan 2003 13:18:45 -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 NAA07463
	for <w3c-dist-auth@w3.org>; Thu, 23 Jan 2003 13:18:44 -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 h0NIID812390
	for <w3c-dist-auth@w3.org>; Thu, 23 Jan 2003 10:18:13 -0800 (PST)
Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10])
	by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id h0NIIAl12289
	for <w3c-dist-auth@w3.org>; Thu, 23 Jan 2003 10:18:10 -0800 (PST)
Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id h0NII9421688
	for <w3c-dist-auth@w3.org>; Thu, 23 Jan 2003 11:18:09 -0700 (MST)
Received: from rgmum3.us.oracle.com (rgmum3.us.oracle.com [138.1.191.24])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id h0NII4a21458
	for <w3c-dist-auth@w3.org>; Thu, 23 Jan 2003 11:18:04 -0700 (MST)
Received: from 152.68.17.155 by rgmum5.us.oracle.com
	with ESMTP id 36428961043345815; Thu, 23 Jan 2003 11:16:55 -0600
Message-ID: <02ae01c2c30a$b5970da0$9b114498@esedlar>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: <w3c-dist-auth@w3.org>
References: <E1311B24AA00D511971D00E081107CD4792EF9@SERVER1>
Date: Thu, 23 Jan 2003 10:10:20 -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: WebDav and Dreamweaver
X-Archived-At: http://www.w3.org/mid/02ae01c2c30a$b5970da0$9b114498@esedlar
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7150
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


Try http://sitename.org:<port number>/directory name


----- Original Message -----
From: "Sue Applebaum" <sapplebaum@rzsolutions.com>
To: <w3c-dist-auth@w3.org>
Sent: Thursday, January 23, 2003 9:31 AM
Subject: WebDav and Dreamweaver


>
> I am a parent volunteer who develops the website for my son's school.  The
> district administrator tells me I need to use Webdav protocol to connect
to
> the Zope server.  My problem is I cannot determine the correct syntax that
> DreamWeaver wants for the URL.   Is anyone out there using that and could
> help me?  I am using the newest version of DreamWeaver MX.
>
> I have tried this - http://sitename.org/directory name/:port number
>
> Thanks,
>
> Sue Applebaum
> Manager, Technical and Training Services
> RZ Solutions
> Phone:  763-923-2330
> Fax:  763-923-2301
> Email:  sapplebaum@rzsolutions.com <sapplebaum@rzsolutions.com>
>
>



From w3c-dist-auth-request@w3.org  Thu Jan 23 14:45: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 OAA18302
	for <webdav-archive@lists.ietf.org>; Thu, 23 Jan 2003 14:45:33 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0NJis507438;
	Thu, 23 Jan 2003 14:44:54 -0500 (EST)
Resent-Date: Thu, 23 Jan 2003 14:44:54 -0500 (EST)
Resent-Message-Id: <200301231944.h0NJis507438@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 h0NJirD07406
	for <w3c-dist-auth@frink.w3.org>; Thu, 23 Jan 2003 14:44:53 -0500 (EST)
Received: from mail.arc.nasa.gov (pony1.arc.nasa.gov [128.102.31.31])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA30649
	for <w3c-dist-auth@w3.org>; Thu, 23 Jan 2003 14:44:52 -0500
Received: from nasa.gov (counterweight.aen.nasa.gov [198.123.13.109])
	by mail.arc.nasa.gov (8.9.3/8.9.3) with ESMTP id LAA05212;
	Thu, 23 Jan 2003 11:44:04 -0800 (PST)
Message-ID: <3E304604.10908@nasa.gov>
Date: Thu, 23 Jan 2003 11:44:04 -0800
From: Chris Knight <Christopher.D.Knight@nasa.gov>
Organization: NASA Ames Research Center
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021212
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@xythos.com>
CC: "'Eriksson, Michael'" <Michael.Eriksson@bauer-partner.com>,
        w3c-dist-auth@w3.org
References: <000501c2bd86$68dee2a0$620afea9@xythoslap>
In-Reply-To: <000501c2bd86$68dee2a0$620afea9@xythoslap>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: WebDAV and 404-handling
X-Archived-At: http://www.w3.org/mid/3E304604.10908@nasa.gov
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7151
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:
> The IE method of doing HEAD then PUT is a timing-dependent solution to
> preventing unintended overwrites.  As such, it's about as dependable as
> the rhythm method in preventing unintended pregnancies.

:^)

> The recommended way to prevent overwrite on PUT is to put the header
> "If-None-Match: *" on the request.   See for example
> http://www.w3.org/1999/04/Editing/.

And, as we discussed at the WG Interim Mtg, the use of the "Expect" HTTP 
header, something we should be actively encouraging development of as 
it's in the HTTP/1.1 as it would report an unintended overwrite before 
the body of the message is sent. Correct?



From w3c-dist-auth-request@w3.org  Thu Jan 23 15:17: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 PAA19057
	for <webdav-archive@lists.ietf.org>; Thu, 23 Jan 2003 15:17:30 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0NKJuX11487;
	Thu, 23 Jan 2003 15:19:56 -0500 (EST)
Resent-Date: Thu, 23 Jan 2003 15:19:56 -0500 (EST)
Resent-Message-Id: <200301232019.h0NKJuX11487@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 h0NKJtD11451
	for <w3c-dist-auth@frink.w3.org>; Thu, 23 Jan 2003 15:19: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 PAA07871
	for <w3c-dist-auth@w3c.org>; Thu, 23 Jan 2003 15:19:55 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18bnpG-00088P-00
	for w3c-dist-auth@w3c.org; Thu, 23 Jan 2003 20:19:50 +0000
Received: from [216.36.77.241] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18bnpC-00088E-00
	for w3c-dist-auth@w3c.org; Thu, 23 Jan 2003 20:19:50 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Thu, 23 Jan 2003 12:19:45 -0800
Message-ID: <000001c2c31c$c7866710$b701a8c0@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Subject: Using If and not failing
X-Archived-At: http://www.w3.org/mid/000001c2c31c$c7866710$b701a8c0@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7152
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


 
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  Thu Jan 23 15:58: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 PAA19855
	for <webdav-archive@lists.ietf.org>; Thu, 23 Jan 2003 15:58:30 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0NL0LX14198;
	Thu, 23 Jan 2003 16:00:21 -0500 (EST)
Resent-Date: Thu, 23 Jan 2003 16:00:21 -0500 (EST)
Resent-Message-Id: <200301232100.h0NL0LX14198@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 h0NL0KD14164
	for <w3c-dist-auth@frink.w3.org>; Thu, 23 Jan 2003 16:00: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 QAA16512
	for <w3c-dist-auth@w3c.org>; Thu, 23 Jan 2003 16:00:19 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18boSQ-0000Mb-00; Thu, 23 Jan 2003 21:00:18 +0000
Received: from [216.36.77.241] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18boSQ-0000MQ-00; Thu, 23 Jan 2003 21:00:18 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>,
        "'Roy T. Fielding'" <fielding@apache.org>
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Thu, 23 Jan 2003 13:00:17 -0800
Message-ID: <000c01c2c322$6ee7e1f0$b701a8c0@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <JIEGINCHMLABHJBIGKBCCEJIGEAA.julian.reschke@gmx.de>
Old-X-Envelope-To: fielding@apache.org,
 julian.reschke@gmx.de,
 w3c-dist-auth@w3c.org
Subject: RE: Collections ending in slashes: consensus reversal?
X-Archived-At: http://www.w3.org/mid/000c01c2c322$6ee7e1f0$b701a8c0@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7153
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


> > We discuss them in both places (and in the hallways), and only poll
for
> > consensus on the mailing list.  Otherwise, you'll just piss off the
> people
> 
> I think this is what we are doing.

To be clear, we do poll for consensus in person, but that's a common
IETF practice (sometimes implemented as a hum in large meetings).  We
have always brought in-person discussions and "conclusions" (to avoid
the word "decisions" to the list for finality.  That's why I mentioned
having a straw poll on the list shortly if discussion points that way.

Lisa




From w3c-dist-auth-request@w3.org  Fri Jan 24 13:19: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 NAA27343
	for <webdav-archive@lists.ietf.org>; Fri, 24 Jan 2003 13:19:24 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0OIL2019366;
	Fri, 24 Jan 2003 13:21:02 -0500 (EST)
Resent-Date: Fri, 24 Jan 2003 13:21:02 -0500 (EST)
Resent-Message-Id: <200301241821.h0OIL2019366@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 h0OIJPD19232
	for <w3c-dist-auth@frink.w3.org>; Fri, 24 Jan 2003 13:19:25 -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 NAA30792
	for <w3c-dist-auth@w3c.org>; Fri, 24 Jan 2003 13:19:24 -0500
Received: (qmail 29797 invoked by uid 0); 24 Jan 2003 18:18:53 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp015-rz3) with SMTP; 24 Jan 2003 18:18:53 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "John DeSoi" <desoi@icx.net>, <w3c-dist-auth@w3c.org>
Date: Fri, 24 Jan 2003 19:18:52 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCCEOCGEAA.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: <p05200f00ba559bb472db@[192.168.1.7]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and  INTEROP_DELETE_AND_MULTISTATUS
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEOCGEAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7154
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 John DeSoi
> Sent: Thursday, January 23, 2003 2:25 PM
> To: w3c-dist-auth@w3c.org
> Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and
> INTEROP_DELETE_AND_MULTISTATUS
>
>
>
>
> At 4:49 PM +0100 1/22/03, Julian Reschke wrote:
> >  > Lisa Dusseault:
> >>  > few HTTP clients do authoring, and those that do are at
> least aware that
> >>  > 207 is a multistatus response
> >>
> >>  Netscape/Mozilla Composer is an HTTP authoring tool that is not
> >>  aware of 207.
> >
> >Yes. But as far as I understand it's abandoned as well. The
> solution here is
> >to make sure that when/if Mozilla 1.x starts supporting
> authoring again, it
> >will pay attention to RFC2518 semantics.
>
> Netscape/Mozilla still supports editing with Composer and works fine
> with my WebDAV server (using HTTP PUT). I don't believe it supports a

You are right. For some reason I thought that this was supposed to work
using "save", which was greyed out when a web resource was opened. In fact,
it's "Publish". You learn something new every day.

> DELETE method; but since HTTP does define a DELETE method, I don't
> see how WebDAV can justify redefining the meaning of 2xx status codes.

Well. The main justification is that it has been doing this for almost 4
years now, and

- there wasn't a big outcry, and
- it doesn't seem to negatively affect anybody.

That being said, from a consistency p.o.v. I agree. I'll assume for a moment
that few WebDAV clients indeed *do* evaluate a 207 on DELETE (and other
candidates such as LOCK/COPY...), and those probably would be easy to
upgrade. If this is true, all we'd need to do is

- deprecate status of 207 for failures
- introduce a new 4xx code such as INCOMPLETE OPERATION which would carry
the same multistatus body

Feedback appreciated.

Julian

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



From w3c-dist-auth-request@w3.org  Fri Jan 24 13:25:52 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 NAA27636
	for <webdav-archive@lists.ietf.org>; Fri, 24 Jan 2003 13:25:51 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0OISBq20841;
	Fri, 24 Jan 2003 13:28:11 -0500 (EST)
Resent-Date: Fri, 24 Jan 2003 13:28:11 -0500 (EST)
Resent-Message-Id: <200301241828.h0OISBq20841@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 h0OISAD20807
	for <w3c-dist-auth@frink.w3.org>; Fri, 24 Jan 2003 13:28:10 -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 NAA01516
	for <w3c-dist-auth@w3c.org>; Fri, 24 Jan 2003 13:28:02 -0500
Received: (qmail 20174 invoked by uid 0); 24 Jan 2003 18:27:31 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp018-rz3) with SMTP; 24 Jan 2003 18:27:31 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Fri, 24 Jan 2003 19:27:30 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCOEOCGEAA.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
Subject: WebDAV WG meeting vs bindings vs GULP
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEOCGEAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7155
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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,

during the meeting we shortly discussed the bindings spec. As far as I
remember, one of the bigger outstanding issues was the clarification of how
locks work in presence of multiple bindings of a resource (NOTE: a resource
may have multiple bindings even in the absense of a specific BIND method).

I thought the agreement was to update GULP, the "Grand Unified Lock
Proposal" ([1]), and to have that incorporated into RFC2518bis.

However, during the meeting this was questioned, as

1) some think the latest proposal is innacurate and
2) some think an explanation of the model doesn't belong into the spec (it
should just define behaviour).

My take is that if there are inaccuracies in the proposal, we SHOULD resolve
them. Having that done, either GULP itself (or something based on it) should
go into the RFC.

So, those who actually think that 1) or 2) apply, please speak up.

Julian


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

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



From w3c-dist-auth-request@w3.org  Fri Jan 24 13:49: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 NAA28445
	for <webdav-archive@lists.ietf.org>; Fri, 24 Jan 2003 13:49:41 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0OIpgX28122;
	Fri, 24 Jan 2003 13:51:43 -0500 (EST)
Resent-Date: Fri, 24 Jan 2003 13:51:43 -0500 (EST)
Resent-Message-Id: <200301241851.h0OIpgX28122@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 h0OIpfD28090
	for <w3c-dist-auth@frink.w3.org>; Fri, 24 Jan 2003 13:51:41 -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 NAA09355
	for <w3c-dist-auth@w3c.org>; Fri, 24 Jan 2003 13:51:41 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 24 Jan 2003 13:36:26 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <C8Q6F391>; Fri, 24 Jan 2003 13:51:05 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED631@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3c.org
Date: Fri, 24 Jan 2003 13:51:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and  INTEROP_DELETE_A 	ND_MULTISTATUS
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED631@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7156
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


If widely deployed clients (e.g. MS office) would not choke on this change,
I would support doing as Julian suggests.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Friday, January 24, 2003 1:19 PM
To: John DeSoi; w3c-dist-auth@w3c.org
Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and
INTEROP_DELETE_AND_MULTISTATUS



> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of John DeSoi
> Sent: Thursday, January 23, 2003 2:25 PM
> To: w3c-dist-auth@w3c.org
> Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and
> INTEROP_DELETE_AND_MULTISTATUS
>
>
>
>
> At 4:49 PM +0100 1/22/03, Julian Reschke wrote:
> >  > Lisa Dusseault:
> >>  > few HTTP clients do authoring, and those that do are at
> least aware that
> >>  > 207 is a multistatus response
> >>
> >>  Netscape/Mozilla Composer is an HTTP authoring tool that is not
> >>  aware of 207.
> >
> >Yes. But as far as I understand it's abandoned as well. The
> solution here is
> >to make sure that when/if Mozilla 1.x starts supporting
> authoring again, it
> >will pay attention to RFC2518 semantics.
>
> Netscape/Mozilla still supports editing with Composer and works fine
> with my WebDAV server (using HTTP PUT). I don't believe it supports a

You are right. For some reason I thought that this was supposed to work
using "save", which was greyed out when a web resource was opened. In fact,
it's "Publish". You learn something new every day.

> DELETE method; but since HTTP does define a DELETE method, I don't
> see how WebDAV can justify redefining the meaning of 2xx status codes.

Well. The main justification is that it has been doing this for almost 4
years now, and

- there wasn't a big outcry, and
- it doesn't seem to negatively affect anybody.

That being said, from a consistency p.o.v. I agree. I'll assume for a moment
that few WebDAV clients indeed *do* evaluate a 207 on DELETE (and other
candidates such as LOCK/COPY...), and those probably would be easy to
upgrade. If this is true, all we'd need to do is

- deprecate status of 207 for failures
- introduce a new 4xx code such as INCOMPLETE OPERATION which would carry
the same multistatus body

Feedback appreciated.

Julian

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



From w3c-dist-auth-request@w3.org  Fri Jan 24 14: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 OAA29596
	for <webdav-archive@lists.ietf.org>; Fri, 24 Jan 2003 14:25:10 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0OJKiu02980;
	Fri, 24 Jan 2003 14:20:44 -0500 (EST)
Resent-Date: Fri, 24 Jan 2003 14:20:44 -0500 (EST)
Resent-Message-Id: <200301241920.h0OJKiu02980@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 h0OJKgD02948
	for <w3c-dist-auth@frink.w3.org>; Fri, 24 Jan 2003 14:20: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 OAA16599
	for <w3c-dist-auth@w3c.org>; Fri, 24 Jan 2003 14:20:42 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 24 Jan 2003 14:05:31 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <C8Q6FQZA>; Fri, 24 Jan 2003 14:20:11 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED635@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Fri, 24 Jan 2003 14:20:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV WG meeting vs bindings vs GULP
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED635@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7157
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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.  The vague and incompletely defined locking
semantics of 2518 desperately needs to be fixed.  I'm happy to work
on improving GULP 5.2, either in wording or semantics (to my knowledge,
no semantic inaccuracies in GULP 5.2 have been reported to the mailing
list).

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Friday, January 24, 2003 1:28 PM
To: 'Webdav WG'
Subject: WebDAV WG meeting vs bindings vs GULP



Hi,

during the meeting we shortly discussed the bindings spec. As far as I
remember, one of the bigger outstanding issues was the clarification of how
locks work in presence of multiple bindings of a resource (NOTE: a resource
may have multiple bindings even in the absense of a specific BIND method).

I thought the agreement was to update GULP, the "Grand Unified Lock
Proposal" ([1]), and to have that incorporated into RFC2518bis.

However, during the meeting this was questioned, as

1) some think the latest proposal is innacurate and
2) some think an explanation of the model doesn't belong into the spec (it
should just define behaviour).

My take is that if there are inaccuracies in the proposal, we SHOULD resolve
them. Having that done, either GULP itself (or something based on it) should
go into the RFC.

So, those who actually think that 1) or 2) apply, please speak up.

Julian


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

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



From w3c-dist-auth-request@w3.org  Fri Jan 24 14:37:59 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 OAA00149
	for <webdav-archive@lists.ietf.org>; Fri, 24 Jan 2003 14:37:58 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0OJeMI07580;
	Fri, 24 Jan 2003 14:40:22 -0500 (EST)
Resent-Date: Fri, 24 Jan 2003 14:40:22 -0500 (EST)
Resent-Message-Id: <200301241940.h0OJeMI07580@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 h0OJeKD07539
	for <w3c-dist-auth@frink.w3.org>; Fri, 24 Jan 2003 14:40:20 -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 OAA22492
	for <w3c-dist-auth@w3c.org>; Fri, 24 Jan 2003 14:40:20 -0500
Received: (qmail 3472 invoked by uid 0); 24 Jan 2003 19:40:12 -0000
Received: from pD950C395.dip.t-dialin.net (HELO lisa) (217.80.195.149)
  by mail.gmx.net (mp019-rz3) with SMTP; 24 Jan 2003 19:40:12 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Clemm, Geoff" <gclemm@rational.com>, <w3c-dist-auth@w3c.org>
Date: Fri, 24 Jan 2003 20:40:03 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCMEOIGEAA.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: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED631@SUS-MA1IT01>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and  INTEROP_DELETE_A 	ND_MULTISTATUS
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEOIGEAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7158
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 never seen the MS webfolder client actually parsing a 207 response --
all it does is display the fact that something whent wrong.

I guess we'll just experimentally implement that and see how clients
behave...

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Friday, January 24, 2003 7:51 PM
> To: w3c-dist-auth@w3c.org
> Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and
> INTEROP_DELETE_A ND_MULTISTATUS
>
>
>
> If widely deployed clients (e.g. MS office) would not choke on
> this change,
> I would support doing as Julian suggests.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Friday, January 24, 2003 1:19 PM
> To: John DeSoi; w3c-dist-auth@w3c.org
> Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and
> INTEROP_DELETE_AND_MULTISTATUS
>
>
>
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of John DeSoi
> > Sent: Thursday, January 23, 2003 2:25 PM
> > To: w3c-dist-auth@w3c.org
> > Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and
> > INTEROP_DELETE_AND_MULTISTATUS
> >
> >
> >
> >
> > At 4:49 PM +0100 1/22/03, Julian Reschke wrote:
> > >  > Lisa Dusseault:
> > >>  > few HTTP clients do authoring, and those that do are at
> > least aware that
> > >>  > 207 is a multistatus response
> > >>
> > >>  Netscape/Mozilla Composer is an HTTP authoring tool that is not
> > >>  aware of 207.
> > >
> > >Yes. But as far as I understand it's abandoned as well. The
> > solution here is
> > >to make sure that when/if Mozilla 1.x starts supporting
> > authoring again, it
> > >will pay attention to RFC2518 semantics.
> >
> > Netscape/Mozilla still supports editing with Composer and works fine
> > with my WebDAV server (using HTTP PUT). I don't believe it supports a
>
> You are right. For some reason I thought that this was supposed to work
> using "save", which was greyed out when a web resource was
> opened. In fact,
> it's "Publish". You learn something new every day.
>
> > DELETE method; but since HTTP does define a DELETE method, I don't
> > see how WebDAV can justify redefining the meaning of 2xx status codes.
>
> Well. The main justification is that it has been doing this for almost 4
> years now, and
>
> - there wasn't a big outcry, and
> - it doesn't seem to negatively affect anybody.
>
> That being said, from a consistency p.o.v. I agree. I'll assume
> for a moment
> that few WebDAV clients indeed *do* evaluate a 207 on DELETE (and other
> candidates such as LOCK/COPY...), and those probably would be easy to
> upgrade. If this is true, all we'd need to do is
>
> - deprecate status of 207 for failures
> - introduce a new 4xx code such as INCOMPLETE OPERATION which would carry
> the same multistatus body
>
> Feedback appreciated.
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Fri Jan 24 16: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 QAA02430
	for <webdav-archive@lists.ietf.org>; Fri, 24 Jan 2003 16:03:19 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0OL5I419711;
	Fri, 24 Jan 2003 16:05:18 -0500 (EST)
Resent-Date: Fri, 24 Jan 2003 16:05:18 -0500 (EST)
Resent-Message-Id: <200301242105.h0OL5I419711@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 h0OL5HD19679
	for <w3c-dist-auth@frink.w3.org>; Fri, 24 Jan 2003 16:05:17 -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 QAA11169
	for <w3c-dist-auth@w3c.org>; Fri, 24 Jan 2003 16:05:17 -0500
Received: (qmail 9585 invoked by uid 0); 24 Jan 2003 21:04:42 -0000
Received: from pD950C395.dip.t-dialin.net (HELO lisa) (217.80.195.149)
  by mail.gmx.net (mp018-rz3) with SMTP; 24 Jan 2003 21:04:42 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: <w3c-dist-auth@w3c.org>
Date: Fri, 24 Jan 2003 22:04:37 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCEEOOGEAA.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: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED631@SUS-MA1IT01>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and  INTEROP_DELETE_A 	ND_MULTISTATUS
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEOOGEAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7159
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


Speaking of which...

Assuming WebDAV would want to define a new 4xx status code -- how do I find
out about which codes have been "taken"? Roy?

Julian

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Friday, January 24, 2003 7:51 PM
> To: w3c-dist-auth@w3c.org
> Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and
> INTEROP_DELETE_A ND_MULTISTATUS
>
>
>
> If widely deployed clients (e.g. MS office) would not choke on
> this change,
> I would support doing as Julian suggests.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Friday, January 24, 2003 1:19 PM
> To: John DeSoi; w3c-dist-auth@w3c.org
> Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and
> INTEROP_DELETE_AND_MULTISTATUS
>
>
>
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of John DeSoi
> > Sent: Thursday, January 23, 2003 2:25 PM
> > To: w3c-dist-auth@w3c.org
> > Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and
> > INTEROP_DELETE_AND_MULTISTATUS
> >
> >
> >
> >
> > At 4:49 PM +0100 1/22/03, Julian Reschke wrote:
> > >  > Lisa Dusseault:
> > >>  > few HTTP clients do authoring, and those that do are at
> > least aware that
> > >>  > 207 is a multistatus response
> > >>
> > >>  Netscape/Mozilla Composer is an HTTP authoring tool that is not
> > >>  aware of 207.
> > >
> > >Yes. But as far as I understand it's abandoned as well. The
> > solution here is
> > >to make sure that when/if Mozilla 1.x starts supporting
> > authoring again, it
> > >will pay attention to RFC2518 semantics.
> >
> > Netscape/Mozilla still supports editing with Composer and works fine
> > with my WebDAV server (using HTTP PUT). I don't believe it supports a
>
> You are right. For some reason I thought that this was supposed to work
> using "save", which was greyed out when a web resource was
> opened. In fact,
> it's "Publish". You learn something new every day.
>
> > DELETE method; but since HTTP does define a DELETE method, I don't
> > see how WebDAV can justify redefining the meaning of 2xx status codes.
>
> Well. The main justification is that it has been doing this for almost 4
> years now, and
>
> - there wasn't a big outcry, and
> - it doesn't seem to negatively affect anybody.
>
> That being said, from a consistency p.o.v. I agree. I'll assume
> for a moment
> that few WebDAV clients indeed *do* evaluate a 207 on DELETE (and other
> candidates such as LOCK/COPY...), and those probably would be easy to
> upgrade. If this is true, all we'd need to do is
>
> - deprecate status of 207 for failures
> - introduce a new 4xx code such as INCOMPLETE OPERATION which would carry
> the same multistatus body
>
> Feedback appreciated.
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Fri Jan 24 16:47: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 QAA03401
	for <webdav-archive@lists.ietf.org>; Fri, 24 Jan 2003 16:47:01 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0OLn8a25842;
	Fri, 24 Jan 2003 16:49:08 -0500 (EST)
Resent-Date: Fri, 24 Jan 2003 16:49:08 -0500 (EST)
Resent-Message-Id: <200301242149.h0OLn8a25842@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 h0OLn7D25796
	for <w3c-dist-auth@frink.w3.org>; Fri, 24 Jan 2003 16:49:07 -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 QAA22264
	for <w3c-dist-auth@w3c.org>; Fri, 24 Jan 2003 16:49:06 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18cBh5-00026a-00; Fri, 24 Jan 2003 21:48:59 +0000
Received: from [216.36.77.241] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18cBh5-00026P-00; Fri, 24 Jan 2003 21:48:59 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>, "'John DeSoi'" <desoi@icx.net>,
        <w3c-dist-auth@w3c.org>
Date: Fri, 24 Jan 2003 13:49:01 -0800
Message-ID: <000901c2c3f2$67ea5e70$b701a8c0@xythoslap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <JIEGINCHMLABHJBIGKBCCEOCGEAA.julian.reschke@gmx.de>
Old-X-Envelope-To: desoi@icx.net,
 julian.reschke@gmx.de,
 w3c-dist-auth@w3c.org
Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and  INTEROP_DELETE_AND_MULTISTATUS
X-Archived-At: http://www.w3.org/mid/000901c2c3f2$67ea5e70$b701a8c0@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7160
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit



> That being said, from a consistency p.o.v. I agree. I'll 
> assume for a moment
> that few WebDAV clients indeed *do* evaluate a 207 on DELETE 
> (and other
> candidates such as LOCK/COPY...), and those probably would be easy to
> upgrade. If this is true, all we'd need to do is
> 
> - deprecate status of 207 for failures
> - introduce a new 4xx code such as INCOMPLETE OPERATION which 
> would carry
> the same multistatus body
> 
It doesn't seem nearly that big a change is necessary. The biggest
change I'd consider given what I currently know, is that the spec would
require that HTTP 1.1 method requests to non-collections should not
result in 207. This would only affect the definition for DELETE, since
that's the only HTTP 1.1 method that is defined defined as returning
207. DELETE could still return 207 in response to a Depth: infinity
request to a collection.

My reasoning is that HTTP clients address individual pages with DELETE
requests, not collections.

lisa




From w3c-dist-auth-request@w3.org  Fri Jan 24 17:02:23 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 RAA03692
	for <webdav-archive@lists.ietf.org>; Fri, 24 Jan 2003 17:02:22 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0OM4VY26853;
	Fri, 24 Jan 2003 17:04:31 -0500 (EST)
Resent-Date: Fri, 24 Jan 2003 17:04:31 -0500 (EST)
Resent-Message-Id: <200301242204.h0OM4VY26853@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 h0OM4UD26820
	for <w3c-dist-auth@frink.w3.org>; Fri, 24 Jan 2003 17:04:30 -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 RAA25510
	for <w3c-dist-auth@w3c.org>; Fri, 24 Jan 2003 17:04:29 -0500
Received: (qmail 19205 invoked by uid 0); 24 Jan 2003 22:03:52 -0000
Received: from pD950C395.dip.t-dialin.net (HELO lisa) (217.80.195.149)
  by mail.gmx.net (mp018-rz3) with SMTP; 24 Jan 2003 22:03:52 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: <w3c-dist-auth@w3c.org>
Date: Fri, 24 Jan 2003 23:03:43 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCGEPBGEAA.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: <000901c2c3f2$67ea5e70$b701a8c0@xythoslap>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and  INTEROP_DELETE_AND_MULTISTATUS
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEPBGEAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7161
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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,

if we're trying to achieve consistency, we should try do it consistently.
Returning a multistatus with a non-207 status in just one specific case
seems like a workaround, not a fix. BTW: DELETE is always "depth
infinity" -- there is no shallow DELETE.

As far as I can tell, this would affect all namespace operations, such as
COPY, MOVE, DELETE and possibly LOCK. In general, this would enable clients
to do the HTTP-sanctioned range checks (status >= 200 && status <= 299).

Julian

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

> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Friday, January 24, 2003 10:49 PM
> To: 'Julian Reschke'; 'John DeSoi'; w3c-dist-auth@w3c.org
> Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and
> INTEROP_DELETE_AND_MULTISTATUS
>
>
>
> > That being said, from a consistency p.o.v. I agree. I'll
> > assume for a moment
> > that few WebDAV clients indeed *do* evaluate a 207 on DELETE
> > (and other
> > candidates such as LOCK/COPY...), and those probably would be easy to
> > upgrade. If this is true, all we'd need to do is
> >
> > - deprecate status of 207 for failures
> > - introduce a new 4xx code such as INCOMPLETE OPERATION which
> > would carry
> > the same multistatus body
> >
> It doesn't seem nearly that big a change is necessary. The biggest
> change I'd consider given what I currently know, is that the spec would
> require that HTTP 1.1 method requests to non-collections should not
> result in 207. This would only affect the definition for DELETE, since
> that's the only HTTP 1.1 method that is defined defined as returning
> 207. DELETE could still return 207 in response to a Depth: infinity
> request to a collection.
>
> My reasoning is that HTTP clients address individual pages with DELETE
> requests, not collections.
>
> lisa
>
>



From w3c-dist-auth-request@w3.org  Fri Jan 24 17:11: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 RAA03862
	for <webdav-archive@lists.ietf.org>; Fri, 24 Jan 2003 17:11:57 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0OME3T27690;
	Fri, 24 Jan 2003 17:14:03 -0500 (EST)
Resent-Date: Fri, 24 Jan 2003 17:14:03 -0500 (EST)
Resent-Message-Id: <200301242214.h0OME3T27690@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 h0OME1D27631
	for <w3c-dist-auth@frink.w3.org>; Fri, 24 Jan 2003 17:14:01 -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 RAA27567
	for <w3c-dist-auth@w3c.org>; Fri, 24 Jan 2003 17:14:00 -0500
Received: (qmail 20984 invoked by uid 0); 24 Jan 2003 22:13:33 -0000
Received: from pD950C395.dip.t-dialin.net (HELO lisa) (217.80.195.149)
  by mail.gmx.net (mp023-rz3) with SMTP; 24 Jan 2003 22:13:33 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: <w3c-dist-auth@w3c.org>
Date: Fri, 24 Jan 2003 23:13:25 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCMEPBGEAA.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: <000901c2c3f2$67ea5e70$b701a8c0@xythoslap>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and  INTEROP_DELETE_AND_MULTISTATUS
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEPBGEAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7162
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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,

here's my proposal then:


1) define:

425 Incomplete Operation
The 425 (Incomplete Operation) status code means that the method could not
be performed completely because it wasn't executed atomically and the
request could not be applied to all affected child resources.

2) deprecate marshalling of multistatus with 207 on failures or incomplete
operations

3) allow multistatus response body for 424 (failed dependancy) and 425.

Note that 424 could be used when the whole operations was rejected because
of an error on a child resource (such as deep locks that are in conflict
with child lock -- another open issue for error marshalling), while 425
would be returned when the method "partly" succeeded (like a DELETE that
couldn't remove one specifc child, but many others).

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: Friday, January 24, 2003 10:49 PM
> To: 'Julian Reschke'; 'John DeSoi'; w3c-dist-auth@w3c.org
> Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and
> INTEROP_DELETE_AND_MULTISTATUS
>
>
>
>
> > That being said, from a consistency p.o.v. I agree. I'll
> > assume for a moment
> > that few WebDAV clients indeed *do* evaluate a 207 on DELETE
> > (and other
> > candidates such as LOCK/COPY...), and those probably would be easy to
> > upgrade. If this is true, all we'd need to do is
> >
> > - deprecate status of 207 for failures
> > - introduce a new 4xx code such as INCOMPLETE OPERATION which
> > would carry
> > the same multistatus body
> >
> It doesn't seem nearly that big a change is necessary. The biggest
> change I'd consider given what I currently know, is that the spec would
> require that HTTP 1.1 method requests to non-collections should not
> result in 207. This would only affect the definition for DELETE, since
> that's the only HTTP 1.1 method that is defined defined as returning
> 207. DELETE could still return 207 in response to a Depth: infinity
> request to a collection.
>
> My reasoning is that HTTP clients address individual pages with DELETE
> requests, not collections.
>
> lisa
>
>



From w3c-dist-auth-request@w3.org  Fri Jan 24 17:27: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 RAA04177
	for <webdav-archive@lists.ietf.org>; Fri, 24 Jan 2003 17:27:19 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0OMTVY29696;
	Fri, 24 Jan 2003 17:29:31 -0500 (EST)
Resent-Date: Fri, 24 Jan 2003 17:29:31 -0500 (EST)
Resent-Message-Id: <200301242229.h0OMTVY29696@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 h0OMTTD29664
	for <w3c-dist-auth@frink.w3.org>; Fri, 24 Jan 2003 17:29:29 -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 RAA31527
	for <w3c-dist-auth@w3c.org>; Fri, 24 Jan 2003 17:29:29 -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 h0OMLxH04878;
	Fri, 24 Jan 2003 14:21:59 -0800 (PST)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "Julian Reschke" <julian.reschke@gmx.de>, <w3c-dist-auth@w3c.org>
Date: Fri, 24 Jan 2003 14:17:44 -0800
Message-ID: <AMEPKEBLDJJCCDEJHAMIIECBGEAA.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: <JIEGINCHMLABHJBIGKBCEEOOGEAA.julian.reschke@gmx.de>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
X-UCSC-CATS-MailScanner: Found to be clean
Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and  INTEROP_DELETE_AND_MULTISTATUS
X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIIECBGEAA.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7163
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


> Assuming WebDAV would want to define a new 4xx status code -- how
> do I find out about which codes have been "taken"? Roy?

In the past, when we defined new status codes I looked at the latest HTTP
specification, and then all HTTP-related RFCs (of any status, be they
Informational, Experimental, Proposed, Draft, etc.) and drafts likely to
become RFCs (such as drafts of the Draft standard HTTP as it was being
defined), composing the union of all status codes. I then selected the
number one above the highest number yet assigned.

- Jim



From w3c-dist-auth-request@w3.org  Fri Jan 24 17:57: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 RAA04759
	for <webdav-archive@lists.ietf.org>; Fri, 24 Jan 2003 17:57:55 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0ON0C409054;
	Fri, 24 Jan 2003 18:00:12 -0500 (EST)
Resent-Date: Fri, 24 Jan 2003 18:00:12 -0500 (EST)
Resent-Message-Id: <200301242300.h0ON0C409054@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 h0ON0BD09017
	for <w3c-dist-auth@frink.w3.org>; Fri, 24 Jan 2003 18:00: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 SAA08005
	for <w3c-dist-auth@w3c.org>; Fri, 24 Jan 2003 18:00:10 -0500
Received: (qmail 9352 invoked by uid 0); 24 Jan 2003 22:59:36 -0000
Received: from pD950C395.dip.t-dialin.net (HELO lisa) (217.80.195.149)
  by mail.gmx.net (mp016-rz3) with SMTP; 24 Jan 2003 22:59:36 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: <w3c-dist-auth@w3c.org>
Date: Fri, 24 Jan 2003 23:59:30 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCMEPDGEAA.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
Subject: Status of allprop/include proposal
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEPDGEAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7164
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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,

during the WG meeting, we briefly discussed our allprop/include proposal
(see [1] for latest draft). Among the attendees (:-)), there was consensus
that a feature like this is useful and should be incorporated into
RFC2518bis.

A slight change was applied to the syntax -- instead of using DAV:allprop
with a specific include extension, the logic was reversed, such as:

<propfind xmlns="DAV:">
  <prop>
     ... named properties...
  </prop>
  <dead-props />
</propfind>

The updated DTD for propfind thus would be:

<!ELEMENT propfind (allprop | propname | (prop, dead-props+)) >
<!ELEMENT dead-props EMPTY >

(one advantage being that we're not extending DAV:allprop which is already
increasingly misnamed).


Lisa,

a) I assume this is what we agreed upon?

b) How do we proceed? Should I update our draft, or can this go directly
into RFC2518bis?


Julian


[1]
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-allprop-include-lates
t.html>
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Fri Jan 24 18:14: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 SAA05145
	for <webdav-archive@lists.ietf.org>; Fri, 24 Jan 2003 18:14:16 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0ONG2r11206;
	Fri, 24 Jan 2003 18:16:02 -0500 (EST)
Resent-Date: Fri, 24 Jan 2003 18:16:02 -0500 (EST)
Resent-Message-Id: <200301242316.h0ONG2r11206@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 h0ONG1D11174
	for <w3c-dist-auth@frink.w3.org>; Fri, 24 Jan 2003 18:16:01 -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 SAA11393
	for <w3c-dist-auth@w3c.org>; Fri, 24 Jan 2003 18:16:00 -0500
Received: from apache.org (localhost [127.0.0.1])
	by mac.wakasoft.com (8.12.2/8.12.2) with ESMTP id h0OLpN4v008144;
	Fri, 24 Jan 2003 13:51:23 -0800 (PST)
Date: Fri, 24 Jan 2003 13:51:22 -0800
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: <w3c-dist-auth@w3c.org>
To: "Julian Reschke" <julian.reschke@gmx.de>
From: "Roy T. Fielding" <fielding@apache.org>
In-Reply-To: <JIEGINCHMLABHJBIGKBCEEOOGEAA.julian.reschke@gmx.de>
Message-Id: <FAA4294C-2FE5-11D7-ACF9-000393753936@apache.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Subject: Re: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and  INTEROP_DELETE_A 	ND_MULTISTATUS
X-Archived-At: http://www.w3.org/mid/FAA4294C-2FE5-11D7-ACF9-000393753936@apache.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7165
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


> Assuming WebDAV would want to define a new 4xx status code -- how do I 
> find
> out about which codes have been "taken"? Roy?

I don't know what the status of the registry is now, but it was supposed
to be IANA.  The holdback was the lack of a registration process 
[meaning
the lack of a volunteer with enough free time to write that boring 
task].
Larry might know the current state.

Why don't you just respond with the status code of the first error,
since otherwise you will need a 5xx as well.

207 is completely lame (and yes I did make a stink of it at the time).
HTTP doesn't specify the contents of the message body -- a 
multi-response
could have just as easily been done as 200/201 with a special media type
specific to webdav.  The client already knows it is performing a webdav
action and intermediaries know it isn't cacheable (because of the 
method),
so a parallel set of status codes isn't necessary.

....Roy



From w3c-dist-auth-request@w3.org  Sat Jan 25 21: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 VAA01335
	for <webdav-archive@lists.ietf.org>; Sat, 25 Jan 2003 21:08:05 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0Q21Ug12619;
	Sat, 25 Jan 2003 21:01:30 -0500 (EST)
Resent-Date: Sat, 25 Jan 2003 21:01:30 -0500 (EST)
Resent-Message-Id: <200301260201.h0Q21Ug12619@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 h0Q21TD12587
	for <w3c-dist-auth@frink.w3.org>; Sat, 25 Jan 2003 21:01:29 -0500 (EST)
Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA31423
	for <w3c-dist-auth@w3c.org>; Sat, 25 Jan 2003 21:01:28 -0500
Received: from cse.ucsc.edu ([63.194.88.161])
 by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18
 2002)) with ESMTP id <0H9A00GHBTMFFW@mta6.snfc21.pbi.net> for
 w3c-dist-auth@w3c.org; Sat, 25 Jan 2003 18:01:28 -0800 (PST)
Date: Sat, 25 Jan 2003 18:05:23 -0800
From: Elias Sinderson <elias@cse.ucsc.edu>
To: w3c-dist-auth@w3c.org
Message-id: <3E334263.9070800@cse.ucsc.edu>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20021120
 Netscape/7.01
Subject: Interim WebDAV WG mtg notes - 1/20/03
X-Archived-At: http://www.w3.org/mid/3E334263.9070800@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7166
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 following notes were taken on the first day of the interim WebDAV 
working group meeting held 20 Jan, 2003. There are undoubtedly portions 
of the discussion that were not recorded, my apologies for the 
occasional ommision. If anyone recalls things that I have missed, please 
mention them.

Elias
_____________________________

Julian Reshke led the following discussion on datatypes for WebDAV 
properties

The basic idea is that a PROPFIND would provide type information for 
dead and non-RFC2518 live properties. PROPATCH would similarly allow one 
to specify data types in conjunction with setting property values.

The approach uses the W3C XML schema type library and instance type 
attribute to indicate types. This has the advantage of using a standard 
and extensible type library (also used in many other vocabularies).

(Lisa Dusseault) It would be desirable to add information the the 
OPTIONS response to indicate whether the server supports this. Further, 
a PROPATCH response should indicate whether or not the type attribute 
was recognized by the server.

Additional property information to be considered includes:
* 'hidden' flag
* 'protected' flag
* 'display name' attribute

Open issues to be resolved:
* marshaling of display name
* relationship to document types and schema definitions of required 
property sets

Are we ready to think about schema definitions of property sets? of 
resources allowed in collections?

There was a general acknowledgment that this would primarily affect 
DASL, but would likely have some impact on othe WebDAV specs as well.

Two types of questions this proposal would address are "I want to create 
a resource, what properties do I need to set?" and "I have a resource, 
how do I treat the values of properties?"

As an example of a possible approach to server implementation, it was 
noted that Sharepoint allows any resource to be put into a typed 
collection and then  checks the type constraints when a CHECKIN is done. 
Another option would be to do type checking upon an UNLOCK...

General discussion brought up the following concerns (paraphrased):

Is the proposal sufficient fo DASL?
How does this work with PROPFIND allprop?
What are the driving requirements?
Should this be a WG item then? (general approval)
Should we then link its progress to the DASL spec?
Should it also be connected with schema discovery?
Another related topic is schema registration.

General discussion on how best to proceed lead to a concensus on 
initially developing the high-level requirements, then move further 
discussion to a separate (new) mailing list.
---
ACL discussion led by Lisa Dusseault and Eric Sedlar

Lisa Dusseault presented feedback received from the IESG on ACL:
* Basic authenticaiont over SSL/TLS is a MUST level requirement
* Methods should be mapped to specific permissions (in a table)
* Flexibility in te secification is a source of risk. Humans will err 
and poorly written clients will help them.

Eric Sedlar then led further discussion on the spec.

The semantics of ordering wrt granting/denying permissions needs to be 
worked out. Proposal to use the NFSv4 approach. Also need to specify how 
custom priveleges are expressed.

The spec will be clearer and easier to implement correctly if the 
language is stronger - use MUST level requirements wherever possible.

<I missed recording some of the discussion at this point>

(Lisa Dusseault) Can we make it explicit in the spec that we are making 
no attempt to map ACL to *nix permissions. Also moved to drop the 
informational RFC from the WG milestones.

(Jim Whitehead) Should we specify what is returned when tere is an ACL 
problem? We should constrain what is possible.

(Lisa Dusseault) 404 MUST be returned if the client doesn't have read 
permission, and 401/403 otherwise.
---

Dennis Hamilton led the following discussion on property registration.

There is a recognized need to record authoratative info on properties 
and namespaces such as where to go (spec., company, etc.) for more 
detail. There is also a desire to reduce the complexity of the spec as 
much as possible.

The focus of this effort is not machine-readable discovery of 
properties, but future work may address this.

On namespace registration and authority:
* Namespaces SHOULD be registered and
* namespaces SHOULD be resolvable.
* Just anyone should not be able to register a property within a given 
namespace.

(Julian Reschke) This problem exists across all XML efforts...

(Dennis Hamilton) We can likely refer to oter docs or source of 
information on this issue and make sensible recommendations where 
appropriate.

(Jim Whitehead) Someone needs to make a list of questions that we want 
to know the answers to about WebDAV properties. Host this example 
documet on webav.org after its complete.
---

DASL discussion led by Julian Reschke.

Current issue list:
* Error marshaling
    - proposal to align the sepc with RFC3253
* 'next n' results
* type handling in query literals
    - proposal to add DAV:typed-literal operad carrying xsi:type attribute
* language handling for queries on txt props
    - proposal not to do this
* Collation sequence for text comparisons

On 'next-n' results:
(Julian Reschke) Previous discussion on list about persisting search 
results to a URL.

(Jim Whitehead) How is this currently done with DBs?

(Erc Sedlar) Depends on the DB, some save state, some redo te query and 
throw away the first n results.

<some discussion on implementation> Summary: Next n results is something 
we want in the spec, no clear agreement on how best to implement it. 
There are issues related to authentication and caching search resiults 
to be explored as well.

(EricSedlar) Caching is crucial in large repositories, just getting the 
first results back can be expensive.

General agreement that servers should be allowed to generate static 
results at some URL, but should not be required to do so.

(Lisa Dusseault) It is possible to use the range header for getting m-n 
results..


On type handling:

QSD needs to handle DAV:typed-literal.

(Jim Whitehead) Would making QSD a MUST help this issue?

Concensus reached among those attending to add DAV:typed-literal and 
make QSD a MUST level requirement.


On language handling: (Summary)
If a user wants a language sensitive comparison, then they should 
specify that with a language operator. Spoec. should be silent on this 
when discussing other operators. Those in attendance agreed this is the 
case.


On collation sequence:

(Jim Whitehead) The Unicode documet that generaaly covers this issue is 
not complete. It may not be a valuable use of time to try and do better.

(Eris Sedlar) Collation in DBs can be set with lang+territory but has 
impact on performance, and one may need multiple indices.

(Lisa Dusseault) Java allows a collation to be specified, shouldn't be 
dificult to implement [in java].

(Julian Reschke) Intend to use language from XPath/XQery, allowing lang 
to be passed in and a URL to refer to collation info.

Proposal to change nae of casesensitive comparison operator to 
caseinsensitive, which describes the behavior more accurately. No 
objections from those present.

On dates:
(Julian Reschke) Would support using only ISO dates in DASL spec.

(Lisa Dusseault) RFC2518 only supported other format for compatibility 
with RFC2616.

There was an extended discussion on typing of operands vs. typing of 
operators - further discussion pushed back to list as no concensus could 
be reached. We need a thorough comparison to make any decision.

On error marshaling:
General concensus to follow RFC3253 approach/definitions.

Other items:
(Jim Whitehead) What does lte mean? can we be more specific in te spec?

Why is the use of "_ _" prohibited in a query? It shouldn't be a problem 
to implement. The like syntax should conform to SQL'92 definition.

Discussion and agreement among those present that ordering on 
mixed-content is undefined.

(Eric Sedlar) The contains operator should work on properties... it is 
the most frequently used search.

(Julian Reschke) To support that we would need to relax wording in the 
definition of 'contains'.

Maybe extending basicsearch is the correct way to accomplish this?

Julian will be submitting another draft of the DASL spec.



From w3c-dist-auth-request@w3.org  Mon Jan 27 07:20: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 HAA13620
	for <webdav-archive@lists.ietf.org>; Mon, 27 Jan 2003 07:20:39 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0RCLht10038;
	Mon, 27 Jan 2003 07:21:43 -0500 (EST)
Resent-Date: Mon, 27 Jan 2003 07:21:43 -0500 (EST)
Resent-Message-Id: <200301271221.h0RCLht10038@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 h0RCLgD10006
	for <w3c-dist-auth@frink.w3.org>; Mon, 27 Jan 2003 07:21:42 -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 HAA15898
	for <w3c-dist-auth@w3c.org>; Mon, 27 Jan 2003 07:21:41 -0500
Received: (qmail 23140 invoked by uid 0); 27 Jan 2003 12:21:10 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp017-rz3) with SMTP; 27 Jan 2003 12:21:10 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Roy T. Fielding" <fielding@apache.org>,
        "Julian Reschke" <julian.reschke@gmx.de>
Cc: <w3c-dist-auth@w3c.org>
Date: Mon, 27 Jan 2003 13:21:09 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCKEDBGFAA.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: <FAA4294C-2FE5-11D7-ACF9-000393753936@apache.org>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and  INTEROP_DELETE_A 	ND_MULTISTATUS
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEDBGFAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7167
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding
> Sent: Friday, January 24, 2003 10:51 PM
> To: Julian Reschke
> Cc: w3c-dist-auth@w3c.org
> Subject: Re: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and
> INTEROP_DELETE_A ND_MULTISTATUS
> 
> 
> 
> > Assuming WebDAV would want to define a new 4xx status code -- how do I 
> > find
> > out about which codes have been "taken"? Roy?
> 
> I don't know what the status of the registry is now, but it was supposed
> to be IANA.  The holdback was the lack of a registration process 
> [meaning
> the lack of a volunteer with enough free time to write that boring 
> task].
> Larry might know the current state.
> 
> Why don't you just respond with the status code of the first error,
> since otherwise you will need a 5xx as well.
> 
> 207 is completely lame (and yes I did make a stink of it at the time).
> HTTP doesn't specify the contents of the message body -- a 
> multi-response
> could have just as easily been done as 200/201 with a special media type
> specific to webdav.  The client already knows it is performing a webdav
> action and intermediaries know it isn't cacheable (because of the 
> method),
> so a parallel set of status codes isn't necessary.
> 
> ....Roy
> 




From w3c-dist-auth-request@w3.org  Mon Jan 27 07:51:00 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 HAA14678
	for <webdav-archive@lists.ietf.org>; Mon, 27 Jan 2003 07:51:00 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0RCr5n13261;
	Mon, 27 Jan 2003 07:53:05 -0500 (EST)
Resent-Date: Mon, 27 Jan 2003 07:53:05 -0500 (EST)
Resent-Message-Id: <200301271253.h0RCr5n13261@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 h0RCr4D13225
	for <w3c-dist-auth@frink.w3.org>; Mon, 27 Jan 2003 07:53:04 -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 HAA20585
	for <w3c-dist-auth@w3c.org>; Mon, 27 Jan 2003 07:53:03 -0500
Received: (qmail 29842 invoked by uid 0); 27 Jan 2003 12:53:02 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp014-rz3) with SMTP; 27 Jan 2003 12:53:02 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Roy T. Fielding" <fielding@apache.org>
Cc: <w3c-dist-auth@w3c.org>
Date: Mon, 27 Jan 2003 13:53:01 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCGEDDGFAA.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: <FAA4294C-2FE5-11D7-ACF9-000393753936@apache.org>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and  INTEROP_DELETE_A 	ND_MULTISTATUS
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEDDGFAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7168
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


(sorry for my previous empty mail)

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding
> Sent: Friday, January 24, 2003 10:51 PM
> To: Julian Reschke
> Cc: w3c-dist-auth@w3c.org
> Subject: Re: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and
> INTEROP_DELETE_A ND_MULTISTATUS
> ...
>
> Why don't you just respond with the status code of the first error,
> since otherwise you will need a 5xx as well.
>
> 207 is completely lame (and yes I did make a stink of it at the time).
> HTTP doesn't specify the contents of the message body -- a multi-response
> could have just as easily been done as 200/201 with a special media type
> specific to webdav.  The client already knows it is performing a webdav
> action and intermediaries know it isn't cacheable (because of the method),
> so a parallel set of status codes isn't necessary.

I absolutely agree that 207 is lame -- for a successful response, 200 should
have been just fine. However, this doesn't seem to be a real issue, as long
as we use 207 only as a status for successfull requests, such as a typical
PROPFIND.

The suggestion not to specify any new error code is interesting, and we
should really discuss how far we can go this path.

Proposal: define that servers may send a DAV:multistatus or a DAV:error
(RFC3253) body with any 4xx and 5xx response. Use DAV:multistatus for
failures that affected resources other than the one identified by the
request URI, and DAV:error (optionally) otherwise. Clients would then
initiate the DAV:multistatus / DAV:error evalutations independantly of the
response code (do we need a new content type? I don't think so).

Let's try some examples:

1) A collection delete fails because the server couldn't delete one of it's
children (privileges missing):

HTTP/1.1 403 Forbidden

<multistatus xmlns='DAV:'>
  <response>
    <href>foobar/xyz</hre>
    <status>HTTP/1.1 403 Forbidden</status>
  </response>
</multistatus>

(note that we wouldn't include a response for the parent collection(s) as
per result minimization rules)


2) A collection delete fails because the server couldn't delete one of it's
children (I/O error because some other process on the server has the actual
file in the filesystem opened):

HTTP/1.1 500 Internal Server Error

<multistatus xmlns='DAV:'>
  <response>
    <href>foobar/xyz</hre>
    <status>HTTP/1.1 500 Internal Server Error</status>
  </response>
</multistatus>


3) PROPPATCH on a protected property

HTTP/1.1 403 Forbidden

<multistatus xmlns='DAV:'>
  <response>
    <href>foobar</hre>
    <propstat>
      <prop><checked-in/></prop>
      <status>HTTP/1.1 403 Forbidden</status>
    </propstat>
    <propstat>
      <prop><comment/></prop>
      <status>HTTP/1.1 424 Dep. Failed</status>
    </propstat>
  </response>
</multistatus>


This really seems to work quite well. So can anybody think of a reason why
we would need a new return code?


Julian

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



From w3c-dist-auth-request@w3.org  Mon Jan 27 09:56: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 JAA16957
	for <webdav-archive@lists.ietf.org>; Mon, 27 Jan 2003 09:56:29 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0REwQl06798;
	Mon, 27 Jan 2003 09:58:26 -0500 (EST)
Resent-Date: Mon, 27 Jan 2003 09:58:26 -0500 (EST)
Resent-Message-Id: <200301271458.h0REwQl06798@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 h0REwPD06766
	for <w3c-dist-auth@frink.w3.org>; Mon, 27 Jan 2003 09:58:25 -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 JAA22137
	for <w3c-dist-auth@w3c.org>; Mon, 27 Jan 2003 09:58:24 -0500
Received: (qmail 3412 invoked by uid 0); 27 Jan 2003 14:57:53 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp022-rz3) with SMTP; 27 Jan 2003 14:57:53 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: <w3c-dist-auth@w3c.org>
Date: Mon, 27 Jan 2003 15:57:53 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCMEDHGFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0000_01C2C61C.D9C11990"
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
Subject: Summary of If header eval tests
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEDHGFAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7169
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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_0000_01C2C61C.D9C11990
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

during the WG meeting I volunteered to do some tests with the If header
syntax that Geoff, Stefan and myself have been proposing to do conditional
PUTs (where both a lock-token and an entity tag is known, and the request
should succeed if the etag still matches, and the lock-token either matches
or the lock is gone).

A possible syntax for this is:

(<opaquelocktoken:14ba870e-f200-0010-d0b9-e8c4edb33ec7:17289> ["89657"])
(Not<DAV:no-lock> ["89657"])

where:

opaquelocktoken:14ba870e-f200-0010-d0b9-e8c4edb33ec7:17289 is a valid
lock-token,
DAV:no-lock is a known-to-be-invalid lock token and
"89657" is the etag obtained from the previous PUT.


Here are the test results:

1) Moddav in Apache 2.0.44

Found (and reported) two bugs:

a) etags in If header validation do not seem to work [1]
b) lock tokens are only accepted in the specific syntax that moddav
internally uses [2]


2) IIS 5.0

Identified bug similar to [1]. Does anybody know how to report bugs in IIS
with an actual chance that they get fixed? (:-)


3) SAP Enterprise Portal

Tests pass (admittingly after we fixed to bugs in the If header validation).


The tests are written in JScript and require MSXML and the Windows Scripting
Host (zip file attached). Syntax is:

	cscript update-test.js URL (username) (passwd)

Joe (Orton), in case you read this: it would be nice if Litmus could add
some are all of these tests.


Julian


[1] <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16451>
[2] <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16452>

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

------=_NextPart_000_0000_01C2C61C.D9C11990
Content-Type: application/x-zip-compressed;
	name="update-test.zip"
Content-Disposition: attachment;
	filename="update-test.zip"
Content-Transfer-Encoding: base64

UEsDBBQAAAAIAMp9Oy6C4awfsAQAABkUAAAOAAAAdXBkYXRlLXRlc3QuanPVV+tP40YQ/1wk/oeR
Tzqc5kla9QOESKicRFXujhbaIp3ug2NPEhdnN7e7zkM9/vfO7DqxnQeQHiBqKQ/P7s7jNzO/sSeB
AoVf4AQETuE0NPEEbz72/sbQgO+9v7p5f9FuXKGaoKK/59fXl17leH9vf29CB2MxCZI4SmR4a+Qt
CtLinZ3+eSRknWUebWw2YdtOOQ6+pLgUHbWyq77ha3F5S9upiknJX1ehisemcaoG6QiF0X6L3bMb
NCoOK02STDKeRrlgfy/ug792vpGgGJghdOGwAv/s78FCz7qlQ7Z09whNbavpO2d+XU97qaefCkqA
FDBAgyYY+JSZzAvCsR8rbSAcYnhLKdNjKTTCEIMIFe/gCPkQ2aBjDVLxe7bp3O7xPV612QPgD3vt
DjhQ4OtXWNx7XmaXP043KW3vWiZ8ljyXZohqGpO7Rs3h/N3pmVtilQ05RuF7LPRqnNUa9INEY80C
X+OkLTTZ7RpF5OdBuDDciglMqqED7VaLYykKuyfwQ6uVxcTXIg3vwqH0vVTgbEyxYATZgZSQs54e
gQdVi6hbWTiTq/gtjY1LIkvvcs/ybLQfSMcjk7HuOHsIURyBkIYMmVQJKOm9182lr2Wl1m6sXeR8
k8NdMHHMknLZGtQmDDRyPmoUxqhGcbkKrYFDOIvE4smQEANos0BkVh8oRNGbkyIqBu+XflbfVvMb
6w9ppW9adSvOyYUVt+IsOe+d0ePtNuO+l3vpNpbQ2CBa8QvefItfFkHqkXFKvS2FIUrY32NXXV9c
/nF9X1u4mKgjvL6UvUBl5Jz1xKaW2NgRj+oGcmW1GTiupWjBSdc4M2XU8tK7W9B31htForOe55Ff
fPz514dDX03nGY7NkGun5W3fdB2PUKaGt10hgR7VfypuZzg7Z0c8mWLRlzAbJUIfnZ0c8Gw76GZL
OiQ/+QZnYZJqIsRmt9NcWbPTbe7+T1VsCnucuJnb6RYma3FQbmFz3lK3ewpJL5zLeaQkXJJJOefa
cvcqlfBJsEdrTN2xGOSTpyejubehOzaXQlFKE4KTcqkIJGXmPiUhQcsgF4EYpMEAOTM3lwFl0p1e
haOsiQ9fkW8JfpAR+l6z+f0nOhEkdRGM0K+cHAwV9g8+e5WGIYdcGSJVlAOiqHz5v6HTnjaKtPqH
tYI4G+p1KE//QksQxuvdZoWHG5HPH4BsJy1vK6t+lo8RBDJVIdp08SGMalm7Pl2XhsIQKK3j7HEv
Y7PjjLJ4mBMpaJgO4wQzJ8pN/AB9LfmR6tLvlMJnp7sVft4rT5VqlZwqzhVvHGhNdQLrbNiOdKTX
rqxdnokltSWUncnSQr6NFJ8QUfjkVVl51fu8C7gbsH3OUWOGsXpNGPJbTV1I+1Lzn2DsB3GyC4xd
RyJv3xZj72yF8UeiJAoK9FCmSQRsDXr0QKHTMESMMNqREjaDePfEtVgB/wORV8errr4eVndr/Reu
ztfa3LMM0W8A9Jnr9MVqlKfTMNb0FkO/CJqyGAcJcOg0rVAhzGUK04Dmm5ELF/gljBrJKh4Fht60
tdUUEJ/TdvdUxiq1ienJyiIMUsFACnwmir4nn/8PJn/9c3D2SJRnr4LpX6yD/gVQSwECFAAUAAAA
CADKfTsuguGsH7AEAAAZFAAADgAAAAAAAAABACAAtoEAAAAAdXBkYXRlLXRlc3QuanNQSwUGAAAA
AAEAAQA8AAAA3AQAAAAA

------=_NextPart_000_0000_01C2C61C.D9C11990--



From w3c-dist-auth-request@w3.org  Mon Jan 27 10:08: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 KAA17227
	for <webdav-archive@lists.ietf.org>; Mon, 27 Jan 2003 10:08:45 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0RFAj807848;
	Mon, 27 Jan 2003 10:10:45 -0500 (EST)
Resent-Date: Mon, 27 Jan 2003 10:10:45 -0500 (EST)
Resent-Message-Id: <200301271510.h0RFAj807848@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 h0RFAiD07816
	for <w3c-dist-auth@frink.w3.org>; Mon, 27 Jan 2003 10:10:44 -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 KAA26202
	for <w3c-dist-auth@w3c.org>; Mon, 27 Jan 2003 10:10:44 -0500
Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 27 Jan 2003 09:55:22 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59)
	id <C8Q6HWZJ>; Mon, 27 Jan 2003 10:10:08 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE201BC7E0D@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3c.org
Date: Mon, 27 Jan 2003 10:10:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and  INTEROP_DELETE_A 	 	ND_MULTISTATUS
X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE201BC7E0D@SUS-MA1IT01
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7170
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 only reason I can think of for having a new 4xx and 5xx
response code would be to warn the client that it is getting
a DAV:multistatus body for the error message.  But until
someone makes a good case for why it is hard for
a client to just scan the response body to figure this out,
I'd go with Julian's suggestion, and just allow arbitrary
4xx and 5xx response codes (or a specific set of existing
4xx and 5xx response codes) to take a DAV:multistatus body.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Monday, January 27, 2003 7:53 AM
To: Roy T. Fielding
Cc: w3c-dist-auth@w3c.org
Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and
INTEROP_DELETE_A ND_MULTISTATUS



(sorry for my previous empty mail)

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding
> Sent: Friday, January 24, 2003 10:51 PM
> To: Julian Reschke
> Cc: w3c-dist-auth@w3c.org
> Subject: Re: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and
> INTEROP_DELETE_A ND_MULTISTATUS
> ...
>
> Why don't you just respond with the status code of the first error,
> since otherwise you will need a 5xx as well.
>
> 207 is completely lame (and yes I did make a stink of it at the time).
> HTTP doesn't specify the contents of the message body -- a multi-response
> could have just as easily been done as 200/201 with a special media type
> specific to webdav.  The client already knows it is performing a webdav
> action and intermediaries know it isn't cacheable (because of the method),
> so a parallel set of status codes isn't necessary.

I absolutely agree that 207 is lame -- for a successful response, 200 should
have been just fine. However, this doesn't seem to be a real issue, as long
as we use 207 only as a status for successfull requests, such as a typical
PROPFIND.

The suggestion not to specify any new error code is interesting, and we
should really discuss how far we can go this path.

Proposal: define that servers may send a DAV:multistatus or a DAV:error
(RFC3253) body with any 4xx and 5xx response. Use DAV:multistatus for
failures that affected resources other than the one identified by the
request URI, and DAV:error (optionally) otherwise. Clients would then
initiate the DAV:multistatus / DAV:error evalutations independantly of the
response code (do we need a new content type? I don't think so).

Let's try some examples:

1) A collection delete fails because the server couldn't delete one of it's
children (privileges missing):

HTTP/1.1 403 Forbidden

<multistatus xmlns='DAV:'>
  <response>
    <href>foobar/xyz</hre>
    <status>HTTP/1.1 403 Forbidden</status>
  </response>
</multistatus>

(note that we wouldn't include a response for the parent collection(s) as
per result minimization rules)


2) A collection delete fails because the server couldn't delete one of it's
children (I/O error because some other process on the server has the actual
file in the filesystem opened):

HTTP/1.1 500 Internal Server Error

<multistatus xmlns='DAV:'>
  <response>
    <href>foobar/xyz</hre>
    <status>HTTP/1.1 500 Internal Server Error</status>
  </response>
</multistatus>


3) PROPPATCH on a protected property

HTTP/1.1 403 Forbidden

<multistatus xmlns='DAV:'>
  <response>
    <href>foobar</hre>
    <propstat>
      <prop><checked-in/></prop>
      <status>HTTP/1.1 403 Forbidden</status>
    </propstat>
    <propstat>
      <prop><comment/></prop>
      <status>HTTP/1.1 424 Dep. Failed</status>
    </propstat>
  </response>
</multistatus>


This really seems to work quite well. So can anybody think of a reason why
we would need a new return code?


Julian

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



From w3c-dist-auth-request@w3.org  Tue Jan 28 05:32: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 FAA20467
	for <webdav-archive@lists.ietf.org>; Tue, 28 Jan 2003 05:32:28 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0SAQkK20572;
	Tue, 28 Jan 2003 05:26:46 -0500 (EST)
Resent-Date: Tue, 28 Jan 2003 05:26:46 -0500 (EST)
Resent-Message-Id: <200301281026.h0SAQkK20572@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 h0SAQjD20538
	for <w3c-dist-auth@frink.w3.org>; Tue, 28 Jan 2003 05:26:45 -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 FAA03429
	for <w3c-dist-auth@w3c.org>; Tue, 28 Jan 2003 05:26:45 -0500
Received: (qmail 7347 invoked by uid 0); 28 Jan 2003 10:26:07 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp019-rz3) with SMTP; 28 Jan 2003 10:26:07 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: <w3c-dist-auth@w3c.org>
Date: Tue, 28 Jan 2003 11:26:06 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCKEFLGFAA.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
In-Reply-To: <JIEGINCHMLABHJBIGKBCMEDHGFAA.julian.reschke@gmx.de>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: RE: Summary of If header eval tests
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEFLGFAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7171
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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,

what I forgot to mention: of the three servers tested (Apache/moddav, IIS
5.0, SAP Enterprise Portal), only one is supplying strong entity tags
(ours).

Julian

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



From w3c-dist-auth-request@w3.org  Wed Jan 29 13:42: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 NAA25726
	for <webdav-archive@lists.ietf.org>; Wed, 29 Jan 2003 13:42:01 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0TIbQw13373;
	Wed, 29 Jan 2003 13:37:26 -0500 (EST)
Resent-Date: Wed, 29 Jan 2003 13:37:26 -0500 (EST)
Resent-Message-Id: <200301291837.h0TIbQw13373@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 h0TIbND13338
	for <w3c-dist-auth@frink.w3.org>; Wed, 29 Jan 2003 13:37:23 -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 NAA10895
	for <w3c-dist-auth@w3c.org>; Wed, 29 Jan 2003 13:37:22 -0500
Received: (qmail 21169 invoked by uid 0); 29 Jan 2003 18:36:48 -0000
Received: from p3EE24813.dip.t-dialin.net (HELO lisa) (62.226.72.19)
  by mail.gmx.net (mp022-rz3) with SMTP; 29 Jan 2003 18:36:48 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: <w3c-dist-auth@w3c.org>
Date: Wed, 29 Jan 2003 19:36:41 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCKEJCGFAA.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
In-Reply-To: <JIEGINCHMLABHJBIGKBCMEDHGFAA.julian.reschke@gmx.de>
Importance: Normal
Subject: RE: Summary of If header eval tests
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEJCGFAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7172
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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,

two updates regarding the situation on Apache/moddav:

Issue 1b) has been fixed (not tested yet).

Issue 1a) is a bit more complicated. The problem here is that my test case
was obtaining it's entity tags from PUT operations. Apache/moddav (when
using the filesystem backend) returns weak entity tags which turn into
strong tags once a certain time has elapsed. Rearranging the code to wait
after the PUT and only then retrieve the etag using HEAD indeed provides
strong etags, and the test failures disappear. So the issue here really has
nothing to do with the If header evaluation.

The issue with IIS may indeed be related -- I'll have to check that
tomorrow.

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 Julian Reschke
> Sent: Monday, January 27, 2003 3:58 PM
> To: w3c-dist-auth@w3c.org
> Subject: Summary of If header eval tests
>
>
> Hi,
>
> during the WG meeting I volunteered to do some tests with the If header
> syntax that Geoff, Stefan and myself have been proposing to do conditional
> PUTs (where both a lock-token and an entity tag is known, and the request
> should succeed if the etag still matches, and the lock-token
> either matches
> or the lock is gone).
>
> A possible syntax for this is:
>
> (<opaquelocktoken:14ba870e-f200-0010-d0b9-e8c4edb33ec7:17289> ["89657"])
> (Not<DAV:no-lock> ["89657"])
>
> where:
>
> opaquelocktoken:14ba870e-f200-0010-d0b9-e8c4edb33ec7:17289 is a valid
> lock-token,
> DAV:no-lock is a known-to-be-invalid lock token and
> "89657" is the etag obtained from the previous PUT.
>
>
> Here are the test results:
>
> 1) Moddav in Apache 2.0.44
>
> Found (and reported) two bugs:
>
> a) etags in If header validation do not seem to work [1]
> b) lock tokens are only accepted in the specific syntax that moddav
> internally uses [2]
>
>
> 2) IIS 5.0
>
> Identified bug similar to [1]. Does anybody know how to report bugs in IIS
> with an actual chance that they get fixed? (:-)
>
>
> 3) SAP Enterprise Portal
>
> Tests pass (admittingly after we fixed to bugs in the If header
> validation).
>
>
> The tests are written in JScript and require MSXML and the
> Windows Scripting
> Host (zip file attached). Syntax is:
>
> 	cscript update-test.js URL (username) (passwd)
>
> Joe (Orton), in case you read this: it would be nice if Litmus could add
> some are all of these tests.
>
>
> Julian
>
>
> [1] <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16451>
> [2] <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16452>
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Thu Jan 30 10:17: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 KAA00745
	for <webdav-archive@lists.ietf.org>; Thu, 30 Jan 2003 10:17:34 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0UFJMb07073;
	Thu, 30 Jan 2003 10:19:22 -0500 (EST)
Resent-Date: Thu, 30 Jan 2003 10:19:22 -0500 (EST)
Resent-Message-Id: <200301301519.h0UFJMb07073@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 h0UFJKD06998
	for <w3c-dist-auth@frink.w3.org>; Thu, 30 Jan 2003 10:19:20 -0500 (EST)
Received: from mail.gmx.net (mail.gmx.de [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA30541
	for <w3c-dist-auth@w3c.org>; Thu, 30 Jan 2003 10:19:11 -0500
Received: (qmail 9783 invoked by uid 0); 30 Jan 2003 13:31:54 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp013-rz3) with SMTP; 30 Jan 2003 13:31:54 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: <w3c-dist-auth@w3c.org>
Date: Thu, 30 Jan 2003 14:31:54 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCCEKJGFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_000A_01C2C86C.55C5BA40"
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: <JIEGINCHMLABHJBIGKBCKEJCGFAA.julian.reschke@gmx.de>
Importance: Normal
Subject: RE: Summary of If header eval tests
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEKJGFAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7173
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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_000A_01C2C86C.55C5BA40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

another update...:

1) "forcing" IIS to use strong etags (by obtaining the etag delayed after
the PUT) does not fix the IIS issue.

2) I've also added a few test cases that test putting the etag into the
"If-Match" header rather than the If header, such as

	if: (<opaquelocktoken:14ba870e-f200-0010-d0b9-e8c4edb33ec7:20681>)
(Not<DAV:no-lock>)
	if-match: "110969"

rather than:

	if: (<opaquelocktoken:14ba870e-f200-0010-d0b9-e8c4edb33ec7:20681>
["110969"]) (Not<DAV:no-lock> ["110969"])

This should be equivalent but fails in Apache/moddav ([1]).

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?

Julian


[1] <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16593>
--
<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 Julian Reschke
> Sent: Wednesday, January 29, 2003 7:37 PM
> To: w3c-dist-auth@w3c.org
> Subject: RE: Summary of If header eval tests
>
>
>
> Hi,
>
> two updates regarding the situation on Apache/moddav:
>
> Issue 1b) has been fixed (not tested yet).
>
> Issue 1a) is a bit more complicated. The problem here is that my test case
> was obtaining it's entity tags from PUT operations. Apache/moddav (when
> using the filesystem backend) returns weak entity tags which turn into
> strong tags once a certain time has elapsed. Rearranging the code to wait
> after the PUT and only then retrieve the etag using HEAD indeed provides
> strong etags, and the test failures disappear. So the issue here
> really has
> nothing to do with the If header evaluation.
>
> The issue with IIS may indeed be related -- I'll have to check that
> tomorrow.
>
> 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 Julian Reschke
> > Sent: Monday, January 27, 2003 3:58 PM
> > To: w3c-dist-auth@w3c.org
> > Subject: Summary of If header eval tests
> >
> >
> > Hi,
> >
> > during the WG meeting I volunteered to do some tests with the If header
> > syntax that Geoff, Stefan and myself have been proposing to do
> conditional
> > PUTs (where both a lock-token and an entity tag is known, and
> the request
> > should succeed if the etag still matches, and the lock-token
> > either matches
> > or the lock is gone).
> >
> > A possible syntax for this is:
> >
> > (<opaquelocktoken:14ba870e-f200-0010-d0b9-e8c4edb33ec7:17289> ["89657"])
> > (Not<DAV:no-lock> ["89657"])
> >
> > where:
> >
> > opaquelocktoken:14ba870e-f200-0010-d0b9-e8c4edb33ec7:17289 is a valid
> > lock-token,
> > DAV:no-lock is a known-to-be-invalid lock token and
> > "89657" is the etag obtained from the previous PUT.
> >
> >
> > Here are the test results:
> >
> > 1) Moddav in Apache 2.0.44
> >
> > Found (and reported) two bugs:
> >
> > a) etags in If header validation do not seem to work [1]
> > b) lock tokens are only accepted in the specific syntax that moddav
> > internally uses [2]
> >
> >
> > 2) IIS 5.0
> >
> > Identified bug similar to [1]. Does anybody know how to report
> bugs in IIS
> > with an actual chance that they get fixed? (:-)
> >
> >
> > 3) SAP Enterprise Portal
> >
> > Tests pass (admittingly after we fixed to bugs in the If header
> > validation).
> >
> >
> > The tests are written in JScript and require MSXML and the
> > Windows Scripting
> > Host (zip file attached). Syntax is:
> >
> > 	cscript update-test.js URL (username) (passwd)
> >
> > Joe (Orton), in case you read this: it would be nice if Litmus could add
> > some are all of these tests.
> >
> >
> > Julian
> >
> >
> > [1] <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16451>
> > [2] <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16452>
> >
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >
>

------=_NextPart_000_000A_01C2C86C.55C5BA40
Content-Type: application/x-zip-compressed;
	name="update-test.zip"
Content-Disposition: attachment;
	filename="update-test.zip"
Content-Transfer-Encoding: base64

UEsDBBQAAAAIAO9rPi7+33rtzAUAAPEeAAAOAAAAdXBkYXRlLXRlc3QuanPlWVlv20YQfq4B/4fJ
Foip6rQaFIgPAUZtNEFzuJXTBAjyQJMjiTXFVbhLHWj83zuzS0qkRNmKrbhGI1gC95jZmW9Orsdu
DDF+hmOIcAInng7G+OHt5d/oaXDE6+6H16/ajS7GY4zp8cXFxbmoHO7u7O6MiTCIxm4Y+KH0rrS8
woi4iNOTvw4iWec5QRubTVi3U47czwnOpw5a6ade8pN9xPzsJA6IyfuuFwcj3TiJ+8kQI62cFotn
NiiMWa0kDNOZ0cRfTOzuBD1wVugbIUZ9PYAO7Ffgn90dyPisnrTPJ11vwKltOP1gj1/l057z6SUR
GUBG0EeN2u07ZJlUCsKxF8RKgzdA74pMpkYyUggDdH2Sz418FhSYCkicQO8pcEHpWEZ9kBEyD8bA
bDhmkzfokD9TNi8MF0fwqrEvAH9ZL0tgYYMvXyAbC5GNGiq5pIOcVo0g45X3wgjNHIzgPobuDHoy
hpcvu0bUofR9dwxawiiWQ6kRJuheGW6KZ1O57Rgsowy4bog4cn4mZ7COyGtj68Xtr3XjVECpBxhP
AsJPxzN4cXZyapeYZUOOMHIET4oae10Nem6osGYco8ZOlXEy2xVGvrOA0IJoV7SrEwVH0G61GLv8
ZOcYSKPU1nltz7yBdEQS4XREuqAPKUFCdjOSHoCAqrGnXcmEWbD4Iwm0dTKevV5ItvCF9i3OcJsr
rBWcJQQ/8CGSmg7SSRxBge+NYpqfIkPr4MpqzYMF1PzNHXHIM8Ww0qi05ypke9RIjWGN9LIRxE9D
V3sDfogoYNKBxT3Vj92M8hgnrwti9aMRgtgcZsGScYMnFqWK2V6l/czWCp3tyRGZs8pp6mYtozSD
HOFc0DXEvF7kMKc4tHCR27DlKRErnRl+Wu/HiNHljPAiPsSxcoOG5TyCnliAW1mv6zpqK7WYm6Vy
s9Zr2SwQEAXLWn4F3yqZSlU3XkR5YpRQ/pWRprS9u8NH2txw/u7iptRgZaOsIHpSXrpxWkDTvFCW
FkqzwkYZgURZTgg0EPOprG5c4FQX9V2E33VWYtP8kC9GRvKF5q/e/vr77aovm+UUR5rNIVpi/aaL
YIgy0bytiwS6X/8lv53hPDo94O4hiHoSpsMwUgenx3vcf+x10iXlkZw8wKkXJoqKQrNz1FxaMx3I
zD5P4kDn9tjp5uKcTq77yTcza+opb6mbPTmj5+gWubQwOU+oRZsrU7+W0ylTgiGtcfkKqG7Ou4NL
6c9EiV+Xu0J+lqokG+U8JpBiPXPICCGaLPrKjfqJ20e2zIdzlyxpqZfhKHJi4i7JFuIb6aMjms2f
PhKFG9Yjd4hO5XhvEGNv75OoNDQJZN0QyaMsEHnm8+e08SCuzn4tN502XnUodmi5kCCMV6PNTO6X
Ir9oUk0kzYeVZTmLZASBTGIPjbmYCP1aGq7bi1Iv0gRK6zBtyRfVxaQsbmgoKSiYDIIQUyGKQXxL
+ppnfPJL56igPgvdqXBPXqys1SoJla+t7OXZrxi5SpHPwGpmbPvKVyufNHQeScY0uK/LjFuEFT6K
KjOvik93RbgE4MdUex4KyU3g48O/U/hKkbFI3AuVjs2xT5/mFSKonj//tg1NOSTXFpV7udXKJcZ9
47TnBuEWIF3naM+oCJKSoAYyCX3g0+CSWliVeB6ij/42kd1euILzhsrlkagu4129e7F54Fh+rLlw
mqK7JXC/sf8+mO9ynzQIFNCfHiAosmhAr9EMA/VNGCPMZAITlzotvpyyIvDLKO82nM07JSrDii+4
aL99QWCeSgfU5Bu4QcbQN9dxW4uXfAK6wbjfeT+x5fR09wD6jjuNzT15uqErTx9dzX2gnPWo3NlU
FvF/rApJZHJ49h6fx/3dm7tdfuWuhAirEossvRpnUcb/R6HaI4dorrEVUCBb8Si6ywT8j9r+R537
fzvb4KZ22WI6diMVutrcePXE/cD7hpiRcl+P2QOjk8doU3SeMBLP7onEXOF/AVBLAQIUABQAAAAI
AO9rPi7+33rtzAUAAPEeAAAOAAAAAAAAAAEAIAC2gQAAAAB1cGRhdGUtdGVzdC5qc1BLBQYAAAAA
AQABADwAAAD4BQAAAAA=

------=_NextPart_000_000A_01C2C86C.55C5BA40--



From w3c-dist-auth-request@w3.org  Fri Jan 31 11:48: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 LAA11768
	for <webdav-archive@lists.ietf.org>; Fri, 31 Jan 2003 11:48:17 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0VGoBF05420;
	Fri, 31 Jan 2003 11:50:11 -0500 (EST)
Resent-Date: Fri, 31 Jan 2003 11:50:11 -0500 (EST)
Resent-Message-Id: <200301311650.h0VGoBF05420@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 h0VGo8D05368
	for <w3c-dist-auth@frink.w3.org>; Fri, 31 Jan 2003 11:50:08 -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 LAA00535
	for <w3c-dist-auth@w3.org>; Fri, 31 Jan 2003 11:50:08 -0500
Received: (qmail 32268 invoked by uid 0); 31 Jan 2003 16:50:07 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp018-rz3) with SMTP; 31 Jan 2003 16:50:07 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "WebDAV" <w3c-dist-auth@w3.org>
Date: Fri, 31 Jan 2003 17:50:06 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCKENCGFAA.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: <JIEGINCHMLABHJBIGKBCMEPCGCAA.julian.reschke@gmx.de>
Subject: RE: draft-ietf-webdav-ordering-protocol-04
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKENCGFAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7174
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 (think I) have finished my edits on the current draft (see [1]), and plan
to submit it as -05 early next week.

Jim: when submitting, do I need to do something special for the "last call"
status?

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: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Tuesday, January 14, 2003 11:14 AM
> To: WebDAV
> Subject: RE: draft-ietf-webdav-ordering-protocol-04
>
>
> Hi.
>
> The draft 04 has been submitted to the IETF and is available from
> [1] and [2] (annotated html). I will continue my edits on the
> "latest" version [3].
>
> Julian
>
> [1]
> <http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-pr
> otocol-04>
> [2]
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-proto
> col-04.html>
> [3]
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-proto
> col-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 Julian Reschke
> > Sent: Wednesday, January 08, 2003 6:20 PM
> > To: WebDAV
> > Subject: draft-ietf-webdav-ordering-protocol-04
> >
> >
> >
> > Hi,
> >
> > I'm in the process of finishing my edits on the ordered
> collections draft
> > ([1]). The main changes are clarifications, rewriting of marshalling
> > sections DeltaV-style, and a new section on the relation between ordered
> > collections and version-controlled collections.
> >
> > Feedback appreciated.
> >
> > BTW: is anybody except ourselves currently implementing this protocol
> > extension?
> >
> > Regards, Julian
> >
> >
> > [1]
> > <http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-proto
> > col-latest
> > .html>
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >



From w3c-dist-auth-request@w3.org  Fri Jan 31 12:26:23 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 MAA12885
	for <webdav-archive@lists.ietf.org>; Fri, 31 Jan 2003 12:26:23 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0VHT1Y11556;
	Fri, 31 Jan 2003 12:29:01 -0500 (EST)
Resent-Date: Fri, 31 Jan 2003 12:29:01 -0500 (EST)
Resent-Message-Id: <200301311729.h0VHT1Y11556@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 h0VHT0D11524
	for <w3c-dist-auth@frink.w3.org>; Fri, 31 Jan 2003 12:29:00 -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 MAA10663
	for <w3c-dist-auth@w3.org>; Fri, 31 Jan 2003 12:28:59 -0500
Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225])
	by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id h0VHSww28407
	for <w3c-dist-auth@w3.org>; Fri, 31 Jan 2003 09:28:58 -0800 (PST)
Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T601ffa0035118164e13d4@mailgate2.apple.com> for <w3c-dist-auth@w3.org>;
 Fri, 31 Jan 2003 09:28:58 -0800
Received: from apple.com (luthji.apple.com [17.202.43.76])
	by scv2.apple.com (8.11.3/8.11.3) with ESMTP id h0VHSvQ28513
	for <w3c-dist-auth@w3.org>; Fri, 31 Jan 2003 09:28:57 -0800 (PST)
Date: Fri, 31 Jan 2003 09:28:40 -0800
Mime-Version: 1.0 (Apple Message framework v551)
Content-Type: text/plain; charset=US-ASCII; format=flowed
From: Jim Luther <luther.j@apple.com>
To: w3c-dist-auth@w3.org
Content-Transfer-Encoding: 7bit
Message-Id: <7014771D-3541-11D7-B386-0003934B6A22@apple.com>
X-Mailer: Apple Mail (2.551)
Subject: Is HTTP/1.1 required for WebDAV?
X-Archived-At: http://www.w3.org/mid/7014771D-3541-11D7-B386-0003934B6A22@apple.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7175
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 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."

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.

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

If yes, should rfc2518 bis make HTTP/1.1 (or later) a MUST?

Jim Luther
Mac OS X File Systems group
Apple Computer, Inc.



From w3c-dist-auth-request@w3.org  Fri Jan 31 13:24: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 NAA14596
	for <webdav-archive@lists.ietf.org>; Fri, 31 Jan 2003 13:24:29 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0VIQjg23882;
	Fri, 31 Jan 2003 13:26:45 -0500 (EST)
Resent-Date: Fri, 31 Jan 2003 13:26:45 -0500 (EST)
Resent-Message-Id: <200301311826.h0VIQjg23882@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 h0VIQiD23850
	for <w3c-dist-auth@frink.w3.org>; Fri, 31 Jan 2003 13:26:44 -0500 (EST)
Received: from mail2.gmhwh.org (mail2.gmhwh.org [12.110.19.38])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA24057
	for <w3c-dist-auth@w3.org>; Fri, 31 Jan 2003 13:26:43 -0500
X-Server-Uuid: 1ea73c7c-c7d8-11d5-bae0-0002a564cf8c
Message-ID: <se3a5cfd.082@mail2.gmhwh.org>
Date: Fri, 31 Jan 2003 11:24:43 -0700
From: "Charlie Smith" <SmithCW@ldschurch.org>
To: luther.j@apple.com, w3c-dist-auth@w3.org
MIME-Version: 1.0
X-WSS-ID: 122460DD818702-01-02
Content-Type: multipart/alternative; 
 boundary="=_AEF1A77D.80E190AE"
Subject: Re: Is HTTP/1.1 required for WebDAV?
X-Archived-At: http://www.w3.org/mid/se3a5cfd.082@mail2.gmhwh.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7176
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_AEF1A77D.80E190AE
Content-Type: text/plain; 
 charset=us-ascii
Content-Transfer-Encoding: 7bit

Great question.  I also would like to know if WebDAV works over https (SSL).

>>> "Jim Luther" <luther.j@apple.com> 01/31/03 10:28AM >>>

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

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.

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

If yes, should rfc2518 bis make HTTP/1.1 (or later) a MUST?

Jim Luther
Mac OS X File Systems group
Apple Computer, Inc.



------------------------------------------------------------------------------
This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed.


==============================================================================

--=_AEF1A77D.80E190AE
Content-Type: text/html; 
 charset=iso-8859-1
Content-Description: HTML
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2719.2200" name=GENERATOR></HEAD>
<BODY style="MARGIN-TOP: 2px; FONT: 10pt Arial; MARGIN-LEFT: 2px">Great 
question.&nbsp; I also would like to know if WebDAV works over https 
(SSL).<BR><BR>&gt;&gt;&gt; "Jim Luther" &lt;luther.j@apple.com&gt; 01/31/03 
10:28AM &gt;&gt;&gt;<BR><BR>I thought it was pretty clear in rfc2518 (and 
rfc2518 bis) that WebDAV <BR>servers and clients are HTTP/1.1 servers and 
clients because the <BR>introduction section of the rfc starts off, "This 
document describes an <BR>extension to the HTTP/1.1 protocol that allows clients 
to perform <BR>remote web content authoring operations."<BR><BR>However, during 
interoperability testing I've found several servers <BR>which return HTTP/1.0 in 
the Status-Line of their response message and <BR>behave as HTTP/1.0 servers 
(i.e., they do not handle HTTP/1.1 <BR>persistent connections correctly, there 
are no Content-Length headers <BR>in a response with a message-body, etc.). For 
the most part, the Mac OS <BR>X WebDAV file system client works with these 
servers but it works much <BR>slower because of transaction aborts and 
retries.<BR><BR>Should WebDAV clients refuse to use HTTP/1.0 servers and should 
WebDAV <BR>servers refuse to work with HTTP/1.0 clients?<BR><BR>If yes, should 
rfc2518 bis make HTTP/1.1 (or later) a MUST?<BR><BR>Jim Luther<BR>Mac OS X File 
Systems group<BR>Apple Computer, Inc.<BR><BR><BR></BODY></HTML>

<P>------------------------------------------------------------------------------<br>
This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed.<br>
<br>
<br>
==============================================================================<br>
</P>
--=_AEF1A77D.80E190AE--



From w3c-dist-auth-request@w3.org  Fri Jan 31 13:28:23 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 NAA14680
	for <webdav-archive@lists.ietf.org>; Fri, 31 Jan 2003 13:28:23 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0VIUZH24272;
	Fri, 31 Jan 2003 13:30:36 -0500 (EST)
Resent-Date: Fri, 31 Jan 2003 13:30:36 -0500 (EST)
Resent-Message-Id: <200301311830.h0VIUZH24272@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 h0VIUXD24240
	for <w3c-dist-auth@frink.w3.org>; Fri, 31 Jan 2003 13:30:33 -0500 (EST)
Received: from mail2.gmhwh.org (mail2.gmhwh.org [12.110.19.38])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA24589
	for <w3c-dist-auth@w3.org>; Fri, 31 Jan 2003 13:30:33 -0500
X-Server-Uuid: 1ea73c7c-c7d8-11d5-bae0-0002a564cf8c
Message-ID: <se3a5e06.098@mail2.gmhwh.org>
Date: Fri, 31 Jan 2003 11:29:04 -0700
From: "Charlie Smith" <SmithCW@ldschurch.org>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-WSS-ID: 12241FD5820367-01-02
Content-Type: multipart/alternative; 
 boundary="=_CA95C366.9FFE8FB6"
Subject: Is WebDAV https compliant?
X-Archived-At: http://www.w3.org/mid/se3a5e06.098@mail2.gmhwh.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7177
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_CA95C366.9FFE8FB6
Content-Type: text/plain; 
 charset=us-ascii
Content-Transfer-Encoding: 7bit

Is WebDAV https compliant.   If so which versions of https are 
supported both on the client and server.
 
And which Browsers are able to work with WebDAV
over https, if WebDAV is SSL compliant?
 
Security minded,
Charlie Smith
1/31/03



------------------------------------------------------------------------------
This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed.


==============================================================================

--=_CA95C366.9FFE8FB6
Content-Type: text/html; 
 charset=iso-8859-1
Content-Description: HTML
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2719.2200" name=GENERATOR></HEAD>
<BODY style="MARGIN-TOP: 2px; FONT: 10pt Arial; MARGIN-LEFT: 2px">
<DIV>Is WebDAV https compliant.&nbsp;&nbsp; If so which versions of https are 
</DIV>
<DIV>supported both on the client and server.</DIV>
<DIV>&nbsp;</DIV>
<DIV>And which Browsers are able to work with WebDAV</DIV>
<DIV>over https, if WebDAV is SSL compliant?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Security minded,</DIV>
<DIV>Charlie Smith</DIV>
<DIV>1/31/03<BR><BR></DIV></BODY></HTML>

<P>------------------------------------------------------------------------------<br>
This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed.<br>
<br>
<br>
==============================================================================<br>
</P>
--=_CA95C366.9FFE8FB6--



From w3c-dist-auth-request@w3.org  Fri Jan 31 13:31:52 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 NAA14817
	for <webdav-archive@lists.ietf.org>; Fri, 31 Jan 2003 13:31:52 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0VIYBM24849;
	Fri, 31 Jan 2003 13:34:11 -0500 (EST)
Resent-Date: Fri, 31 Jan 2003 13:34:11 -0500 (EST)
Resent-Message-Id: <200301311834.h0VIYBM24849@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 h0VIY8D24813
	for <w3c-dist-auth@frink.w3.org>; Fri, 31 Jan 2003 13:34:08 -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 NAA25263
	for <w3c-dist-auth@w3.org>; Fri, 31 Jan 2003 13:34:07 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18efzJ-0008Kb-00; Fri, 31 Jan 2003 18:34:05 +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 18efzJ-0008KP-00; Fri, 31 Jan 2003 18:34:05 +0000
Date: Fri, 31 Jan 2003 10:34:04 -0800
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: WebDAV <w3c-dist-auth@w3.org>
To: "Charlie Smith" <SmithCW@ldschurch.org>
From: Brian Korver <briank@xythos.com>
In-Reply-To: <se3a5cfd.082@mail2.gmhwh.org>
Message-Id: <93584D27-354A-11D7-BE1C-000393751598@xythos.com>
X-Mailer: Apple Mail (2.551)
Old-X-Envelope-To: w3c-dist-auth@w3.org,
 SmithCW@ldschurch.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h0VIY8D24813
Subject: Re: Is HTTP/1.1 required for WebDAV?
X-Archived-At: http://www.w3.org/mid/93584D27-354A-11D7-BE1C-000393751598@xythos.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7178
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


On Friday, January 31, 2003, at 10:24 AM, Charlie Smith wrote:
> Great question.  I also would like to know if WebDAV works over https 
> (SSL).

WebDAV works over SSL.  It works, by definition, over anything
that HTTP works over.

-brian
briank@xythos.com




From w3c-dist-auth-request@w3.org  Fri Jan 31 13:39: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 NAA15092
	for <webdav-archive@lists.ietf.org>; Fri, 31 Jan 2003 13:39:29 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0VIfcu26123;
	Fri, 31 Jan 2003 13:41:38 -0500 (EST)
Resent-Date: Fri, 31 Jan 2003 13:41:38 -0500 (EST)
Resent-Message-Id: <200301311841.h0VIfcu26123@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 h0VIfaD26091
	for <w3c-dist-auth@frink.w3.org>; Fri, 31 Jan 2003 13:41:36 -0500 (EST)
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA26952
	for <w3c-dist-auth@w3.org>; Fri, 31 Jan 2003 13:41:35 -0500
Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225])
	by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id h0VIfWI28012
	for <w3c-dist-auth@w3.org>; Fri, 31 Jan 2003 10:41:32 -0800 (PST)
Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T60203c6f9b118164e13d4@mailgate2.apple.com>;
 Fri, 31 Jan 2003 10:41:32 -0800
Received: from apple.com (luthji.apple.com [17.202.43.76])
	by scv3.apple.com (8.11.3/8.11.3) with ESMTP id h0VIfVf21110;
	Fri, 31 Jan 2003 10:41:31 -0800 (PST)
Date: Fri, 31 Jan 2003 10:41:13 -0800
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
From: Jim Luther <luther.j@apple.com>
To: Charlie Smith <SmithCW@ldschurch.org>, WebDAV <w3c-dist-auth@w3.org>
In-Reply-To: <93584D27-354A-11D7-BE1C-000393751598@xythos.com>
Message-Id: <9305B52D-354B-11D7-B386-0003934B6A22@apple.com>
X-Mailer: Apple Mail (2.551)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h0VIfaD26091
Subject: Re: Does WebDAV work over https (SSL)
X-Archived-At: http://www.w3.org/mid/9305B52D-354B-11D7-B386-0003934B6A22@apple.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7179
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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


On Friday, January 31, 2003, at 10:34  AM, Brian Korver wrote:

> On Friday, January 31, 2003, at 10:24 AM, Charlie Smith wrote:
>> Great question.  I also would like to know if WebDAV works over https 
>> (SSL).
>
> WebDAV works over SSL.  It works, by definition, over anything
> that HTTP works over.
>
> -brian

However, not all clients try to use SSL connections even if the server 
is using it. For example, Mac OS X's WebDAV file system client does not 
support SSL yet.

- Jim Luther



From w3c-dist-auth-request@w3.org  Fri Jan 31 13:54: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 NAA15422
	for <webdav-archive@lists.ietf.org>; Fri, 31 Jan 2003 13:54:19 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0VIuVK27933;
	Fri, 31 Jan 2003 13:56:31 -0500 (EST)
Resent-Date: Fri, 31 Jan 2003 13:56:31 -0500 (EST)
Resent-Message-Id: <200301311856.h0VIuVK27933@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 h0VIuTD27901
	for <w3c-dist-auth@frink.w3.org>; Fri, 31 Jan 2003 13:56:29 -0500 (EST)
Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA29488
	for <w3c-dist-auth@w3.org>; Fri, 31 Jan 2003 13:56:29 -0500
Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27])
	by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id h0VIteh20836;
	Fri, 31 Jan 2003 10:55:42 -0800 (PST)
Message-ID: <3E3AC6AC.6060009@cse.ucsc.edu>
Date: Fri, 31 Jan 2003 10:55:40 -0800
From: Elias Sinderson <elias@cse.ucsc.edu>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Charlie Smith <SmithCW@ldschurch.org>
CC: w3c-dist-auth@w3.org
References: <se3a5e06.098@mail2.gmhwh.org>
Content-Type: multipart/alternative;
 boundary="------------020009000107050902040000"
Subject: Re: Is WebDAV https compliant?
X-Archived-At: http://www.w3.org/mid/3E3AC6AC.6060009@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7180
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>



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

Hi Charlie,

Yes, WebDAV works with SSL. Provided, of course, that both the client 
and the server are configured to speak SSL. Think of SSL as a layer 
around the HTTP request, so whether you use SSL or not has no bearing 
upon the underlying HTTP/WebDAV protocol.

I haven't had any problems using a standard web browser (Netscape, 
Mozilla, IE) to browse our dav repository (based on Apache) using https.


Elias


Charlie Smith wrote:

> Is WebDAV https compliant.   If so which versions of https are
> supported both on the client and server.
>  
> And which Browsers are able to work with WebDAV
> over https, if WebDAV is SSL compliant?



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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Hi Charlie,<br>
<br>
Yes, WebDAV works with SSL. Provided, of course, that both the client and
the server are configured to speak SSL. Think of SSL as a layer around the
HTTP request, so whether you use SSL or not has no bearing upon the underlying
HTTP/WebDAV protocol.<br>
<br>
I haven't had any problems using a standard web browser (Netscape, Mozilla,
IE) to browse our dav repository (based on Apache) using https.<br>
<br>
<br>
Elias<br>
<br>
<br>
Charlie Smith wrote:<br>
<blockquote type="cite" cite="midse3a5e06.098@mail2.gmhwh.org">  
  <meta http-equiv="Content-Type" content="text/html; ">
 
  <meta content="MSHTML 6.00.2719.2200" name="GENERATOR">
 
  <div>Is WebDAV https compliant.&nbsp;&nbsp; If so which versions of https are  </div>
 
  <div>supported both on the client and server.</div>
 
  <div>&nbsp;</div>
 
  <div>And which Browsers are able to work with WebDAV</div>
 
  <div>over https, if WebDAV is SSL compliant?</div>
</blockquote>
<br>
</body>
</html>

--------------020009000107050902040000--



From w3c-dist-auth-request@w3.org  Fri Jan 31 14:02: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 OAA15640
	for <webdav-archive@lists.ietf.org>; Fri, 31 Jan 2003 14:02:55 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0VJ5Qn29114;
	Fri, 31 Jan 2003 14:05:26 -0500 (EST)
Resent-Date: Fri, 31 Jan 2003 14:05:26 -0500 (EST)
Resent-Message-Id: <200301311905.h0VJ5Qn29114@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 h0VJ5PD29082
	for <w3c-dist-auth@frink.w3.org>; Fri, 31 Jan 2003 14:05:25 -0500 (EST)
Received: from mail2.gmhwh.org (mail2.gmhwh.org [12.110.19.38])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA31582
	for <w3c-dist-auth@w3.org>; Fri, 31 Jan 2003 14:05:24 -0500
X-Server-Uuid: 1ea73c7c-c7d8-11d5-bae0-0002a564cf8c
Message-ID: <se3a6669.036@mail2.gmhwh.org>
Date: Fri, 31 Jan 2003 12:04:54 -0700
From: "Charlie Smith" <SmithCW@ldschurch.org>
To: luther.j@apple.com, w3c-dist-auth@w3.org
MIME-Version: 1.0
X-WSS-ID: 12241749830058-01-02
Content-Type: multipart/alternative; 
 boundary="=_6D3264C9.A4C5B4B2"
Subject: Re: Does WebDAV work over https (SSL)
X-Archived-At: http://www.w3.org/mid/se3a6669.036@mail2.gmhwh.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7181
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

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

What about following clients?
 
linux
 
On win 95 and up
netscape    6.0 +
IE              5.0 +
AOL           7.0 +
 
On Mac
Netscape    6.0 +
IE               5.0 +
 
Apple Sahara
 
 
 
BTW: Great response time.  
 
Thanks,
Charlie
1/31/03
 

>>> "Jim Luther" <luther.j@apple.com> 01/31/03 11:41AM >>>

On Friday, January 31, 2003, at 10:34  AM, Brian Korver wrote:

> On Friday, January 31, 2003, at 10:24 AM, Charlie Smith wrote:
>> Great question.  I also would like to know if WebDAV works over https 
>> (SSL).
>
> WebDAV works over SSL.  It works, by definition, over anything
> that HTTP works over.
>
> -brian

However, not all clients try to use SSL connections even if the server 
is using it. For example, Mac OS X's WebDAV file system client does not 
support SSL yet.

- Jim Luther




------------------------------------------------------------------------------
This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed.


==============================================================================

--=_6D3264C9.A4C5B4B2
Content-Type: text/html; 
 charset=iso-8859-1
Content-Description: HTML
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2719.2200" name=GENERATOR></HEAD>
<BODY style="MARGIN-TOP: 2px; FONT: 10pt Arial; MARGIN-LEFT: 2px">
<DIV>What about following clients?</DIV>
<DIV>&nbsp;</DIV>
<DIV>linux</DIV>
<DIV>&nbsp;</DIV>
<DIV>On win 95 and up<BR>netscape&nbsp;&nbsp;&nbsp; 6.0 
+<BR>IE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
5.0 +<BR>AOL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 7.0 
+</DIV>
<DIV>&nbsp;</DIV>
<DIV>On Mac<BR>Netscape&nbsp;&nbsp;&nbsp; 6.0 
+<BR>IE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
5.0 +</DIV>
<DIV>&nbsp;</DIV>
<DIV>Apple Sahara</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>BTW: Great response time.&nbsp; </DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks,</DIV>
<DIV>Charlie<BR>1/31/03</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR>&gt;&gt;&gt; "Jim Luther" &lt;luther.j@apple.com&gt; 01/31/03 11:41AM 
&gt;&gt;&gt;<BR><BR>On Friday, January 31, 2003, at 10:34&nbsp; AM, Brian Korver 
wrote:<BR><BR>&gt; On Friday, January 31, 2003, at 10:24 AM, Charlie Smith 
wrote:<BR>&gt;&gt; Great question.&nbsp; I also would like to know if WebDAV 
works over https <BR>&gt;&gt; (SSL).<BR>&gt;<BR>&gt; WebDAV works over 
SSL.&nbsp; It works, by definition, over anything<BR>&gt; that HTTP works 
over.<BR>&gt;<BR>&gt; -brian<BR><BR>However, not all clients try to use SSL 
connections even if the server <BR>is using it. For example, Mac OS X's WebDAV 
file system client does not <BR>support SSL yet.<BR><BR>- Jim 
Luther<BR><BR><BR></DIV></BODY></HTML>

<P>------------------------------------------------------------------------------<br>
This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed.<br>
<br>
<br>
==============================================================================<br>
</P>
--=_6D3264C9.A4C5B4B2--



From w3c-dist-auth-request@w3.org  Fri Jan 31 16:46: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 QAA19846
	for <webdav-archive@lists.ietf.org>; Fri, 31 Jan 2003 16:46:44 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h0VLmbx28144;
	Fri, 31 Jan 2003 16:48:37 -0500 (EST)
Resent-Date: Fri, 31 Jan 2003 16:48:37 -0500 (EST)
Resent-Message-Id: <200301312148.h0VLmbx28144@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 h0VLmTD27948
	for <w3c-dist-auth@frink.w3.org>; Fri, 31 Jan 2003 16:48: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 QAA04302
	for <w3c-dist-auth@w3.org>; Fri, 31 Jan 2003 16:48:28 -0500
Received: (qmail 6885 invoked by uid 0); 31 Jan 2003 21:47:57 -0000
Received: from pD950C241.dip.t-dialin.net (HELO lisa) (217.80.194.65)
  by mail.gmx.net (mp020-rz3) with SMTP; 31 Jan 2003 21:47:57 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Charlie Smith" <SmithCW@ldschurch.org>, <luther.j@apple.com>,
        <w3c-dist-auth@w3.org>
Date: Fri, 31 Jan 2003 22:47:54 +0100
Message-ID: <JIEGINCHMLABHJBIGKBCMEOCGFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0004_01C2C97A.CAFBAE00"
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: <se3a6669.036@mail2.gmhwh.org>
Subject: RE: Does WebDAV work over https (SSL)
X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEOCGFAA.julian.reschke@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7182
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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_0004_01C2C97A.CAFBAE00
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

These are browsers, not WebDAV clients.

(well, except IE which does come with a built-in WebDAV client)
--
<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 Charlie Smith
  Sent: Friday, January 31, 2003 8:05 PM
  To: luther.j@apple.com; w3c-dist-auth@w3.org
  Subject: Re: Does WebDAV work over https (SSL)


  What about following clients?

  linux

  On win 95 and up
  netscape    6.0 +
  IE              5.0 +
  AOL           7.0 +

  On Mac
  Netscape    6.0 +
  IE               5.0 +

  Apple Sahara



  BTW: Great response time.

  Thanks,
  Charlie
  1/31/03


  >>> "Jim Luther" <luther.j@apple.com> 01/31/03 11:41AM >>>

  On Friday, January 31, 2003, at 10:34  AM, Brian Korver wrote:

  > On Friday, January 31, 2003, at 10:24 AM, Charlie Smith wrote:
  >> Great question.  I also would like to know if WebDAV works over https
  >> (SSL).
  >
  > WebDAV works over SSL.  It works, by definition, over anything
  > that HTTP works over.
  >
  > -brian

  However, not all clients try to use SSL connections even if the server
  is using it. For example, Mac OS X's WebDAV file system client does not
  support SSL yet.

  - Jim Luther



  --------------------------------------------------------------------------
----
  This message may contain confidential information, and is intended only
for the use of the individual(s) to whom it is addressed.



============================================================================
==


------=_NextPart_000_0004_01C2C97A.CAFBAE00
Content-Type: text/html;
	charset="US-ASCII"
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=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN-TOP: 2px; FONT: 10pt Arial; MARGIN-LEFT: 2px">
<DIV><SPAN class=3D594174721-31012003>These are browsers, not WebDAV=20
clients.</SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV><SPAN class=3D594174721-31012003>(well, except IE which does come =
with a=20
built-in WebDAV client)</SPAN></DIV>
<P>--<BR>&lt;green/&gt;bytes GmbH -- <A =
href=3D"http://www.greenbytes.de/"=20
target=3D_blank>http://www.greenbytes.de</A> -- tel:+492512807760 </P>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
  face=3DTahoma>-----Original Message-----<BR><B>From:</B>=20
  w3c-dist-auth-request@w3.org =
[mailto:w3c-dist-auth-request@w3.org]<B>On Behalf=20
  Of </B>Charlie Smith<BR><B>Sent:</B> Friday, January 31, 2003 8:05=20
  PM<BR><B>To:</B> luther.j@apple.com; =
w3c-dist-auth@w3.org<BR><B>Subject:</B>=20
  Re: Does WebDAV work over https (SSL)<BR><BR></FONT></DIV>
  <DIV>What about following clients?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>linux</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>On win 95 and up<BR>netscape&nbsp;&nbsp;&nbsp; 6.0=20
  =
+<BR>IE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
  5.0 =
+<BR>AOL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 7.0 =

  +</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>On Mac<BR>Netscape&nbsp;&nbsp;&nbsp; 6.0=20
  =
+<BR>IE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;=20
  5.0 +</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Apple Sahara</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>BTW: Great response time.&nbsp; </DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Thanks,</DIV>
  <DIV>Charlie<BR>1/31/03</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><BR>&gt;&gt;&gt; "Jim Luther" &lt;luther.j@apple.com&gt; 01/31/03 =
11:41AM=20
  &gt;&gt;&gt;<BR><BR>On Friday, January 31, 2003, at 10:34&nbsp; AM, =
Brian=20
  Korver wrote:<BR><BR>&gt; On Friday, January 31, 2003, at 10:24 AM, =
Charlie=20
  Smith wrote:<BR>&gt;&gt; Great question.&nbsp; I also would like to =
know if=20
  WebDAV works over https <BR>&gt;&gt; (SSL).<BR>&gt;<BR>&gt; WebDAV =
works over=20
  SSL.&nbsp; It works, by definition, over anything<BR>&gt; that HTTP =
works=20
  over.<BR>&gt;<BR>&gt; -brian<BR><BR>However, not all clients try to =
use SSL=20
  connections even if the server <BR>is using it. For example, Mac OS =
X's WebDAV=20
  file system client does not <BR>support SSL yet.<BR><BR>- Jim=20
  Luther<BR><BR><BR></DIV>
  =
<P>----------------------------------------------------------------------=
--------<BR>This=20
  message may contain confidential information, and is intended only for =
the use=20
  of the individual(s) to whom it is=20
  =
addressed.<BR><BR><BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0004_01C2C97A.CAFBAE00--



From w3c-dist-auth-request@w3.org  Fri Jan 31 19:29: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 TAA23292
	for <webdav-archive@lists.ietf.org>; Fri, 31 Jan 2003 19:29:05 -0500 (EST)
Received: (from lists@localhost)
	by frink.w3.org (8.11.6+Sun/8.11.6) id h110VEK21295;
	Fri, 31 Jan 2003 19:31:14 -0500 (EST)
Resent-Date: Fri, 31 Jan 2003 19:31:14 -0500 (EST)
Resent-Message-Id: <200302010031.h110VEK21295@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 h110VDD21263
	for <w3c-dist-auth@frink.w3.org>; Fri, 31 Jan 2003 19:31:13 -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 TAA05377
	for <w3c-dist-auth@w3c.org>; Fri, 31 Jan 2003 19:31:12 -0500
Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3)
	id 18elYt-0005To-00
	for w3c-dist-auth@w3c.org; Sat, 01 Feb 2003 00:31:11 +0000
Received: from [216.36.77.241] (helo=xythoslap)
	by mail.xythos.com with asmtp (Exim 3.36 #3)
	id 18elYs-0005Td-00
	for w3c-dist-auth@w3c.org; Sat, 01 Feb 2003 00:31:10 +0000
From: "Lisa Dusseault" <lisa@xythos.com>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Fri, 31 Jan 2003 16:31:14 -0800
Message-ID: <002a01c2c989$3a96a950$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: Minutes and presentation links
X-Archived-At: http://www.w3.org/mid/002a01c2c989$3a96a950$f876fea9@xythoslap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/7183
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 put together official minutes and uploaded the slides used from the
WG meeting this month:

http://www.sharemation.com/~milele/public/dav/minutes/wg-notes-jan-2003.
txt
http://www.sharemation.com/~milele/public/dav/presentations/webdav-wg-ja
n03.ppt

I assume we're going to meet at the San Francisco IETF in March?  We'll
probably ask for a slot on the agenda shortly.

Lisa