From w3c-dist-auth-request@w3.org  Mon Apr  1 11:18:00 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03432
	for <webdav-archive@odin.ietf.org>; Mon, 1 Apr 2002 11:18:00 -0500 (EST)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id B626D22CD8; Mon,  1 Apr 2002 11:17:59 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA14009;
	Mon, 1 Apr 2002 11:17:45 -0500 (EST)
Resent-Date: Mon, 1 Apr 2002 11:17:45 -0500 (EST)
Resent-Message-Id: <200204011617.LAA14009@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA13985
	for <w3c-dist-auth@www19.w3.org>; Mon, 1 Apr 2002 11:17:37 -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 LAA23509
	for <w3c-dist-auth@w3.org>; Mon, 1 Apr 2002 11:17:37 -0500
Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Mon, 01 Apr 2002 11:14:23 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19)
	id <FJQGXAMT>; Mon, 1 Apr 2002 11:17:06 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B0C7@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3.org
Date: Mon, 1 Apr 2002 11:17:05 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: RE: Authoring Web Service
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6108
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 WebDAV family of protocols (RFC 2616, RFC 2518, RFC 3253)
have been carefully designed to provide for interoperability.
This means for example, that an RFC2616 client will work against
RFC 2616, RFC 2518, and RFC 3253 servers, and an RFC 2518 client
will work against an RFC 2518 and RFC 3253 server.

In contrast, a Web Services interface provides no particular
mechanism to support this kind of interoperability.  You certainly
could define a Web Service interface for each of these protocols
if you didn't care about interoperability between them, but it is
unclear what would be the point (other than market-hype compatibility :-).
For example, the "service lookup" feature of Web Services
is rather pointless in any even moderately successful authoring protocol,
since you'd end up with thousands (if not hundred's of thousands) 
of registered "authoring web services".

Cheers,
Geoff

-----Original Message-----
From: hugh [mailto:hugh0123@yahoo.com]
Sent: Tuesday, March 26, 2002 9:41 PM
To: w3c-dist-auth@w3.org
Subject: Authoring Web Service


I have just started learning about WebDAV and have
a few thoughts/questions that someone on this group
may be able to help with.

I understand WebDAV to be a HTTP-extension-based
protocol that enables functionality that is important
to distributed authoring.  When I looked at the draft
specs, it appears that the method extensions seem to
map to operations performed on authored resources and
the payload of the message seems to be arguments of
sorts to the WebDAV server for the method being
invoked.

I was wondering if the WebDAV specs (and sub-specs)
would be amenable to extrapolation to a
general-purpose
Web-Services interface definition and whether there
would be any point in thinking this way.  As a 
newbie to this technology, it seems like an obvious
connection to me.  In fact I suspect that I will find
a whole bunch of other initiatives to define WSDL
interfaces for "content managerment" or "distributed
authoring" or..

Thank you for any pointers to discussions or
links to related topics!



__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards(r)
http://movies.yahoo.com/



From w3c-dist-auth-request@w3.org  Tue Apr  2 03:30:40 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09803
	for <webdav-archive@odin.ietf.org>; Tue, 2 Apr 2002 03:30:40 -0500 (EST)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 1DF4022BF3; Tue,  2 Apr 2002 03:30:41 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id DAA23302;
	Tue, 2 Apr 2002 03:30:30 -0500 (EST)
Resent-Date: Tue, 2 Apr 2002 03:30:30 -0500 (EST)
Resent-Message-Id: <200204020830.DAA23302@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA23280
	for <w3c-dist-auth@www19.w3.org>; Tue, 2 Apr 2002 03:30:22 -0500 (EST)
Received: from inet-mail2.oracle.com (inet-mail2.oracle.com [148.87.2.202])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA04847
	for <w3c-dist-auth@w3.org>; Tue, 2 Apr 2002 03:30:21 -0500
Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14])
	by inet-mail2.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g328UJw08658;
	Tue, 2 Apr 2002 00:30:19 -0800 (PST)
Received: from esedlarlaptop (dhcp-4op7-4op8-east-130-35-171-59.us.oracle.com [130.35.171.59])
	by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g328UDB29339;
	Tue, 2 Apr 2002 01:30:13 -0700 (MST)
Message-ID: <01a101c1da20$9b913d00$3bab2382@us.oracle.com>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "DAV" <w3c-dist-auth@w3.org>
Date: Tue, 2 Apr 2002 00:30:12 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_019E_01C1D9DD.8D2DBFB0"
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: WebDAV property schema lookup
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6109
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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_019E_01C1D9DD.8D2DBFB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Julian--

  I recall that you had a proposal for getting the schema of the =
properties on a particular resource via DAV.  Does this proposal also =
allow for a generic property editor client?  It seems like we need a way =
for the server to indicate to a client:

* what properties are editable by end-users
* what properties are displayable=20
* what are the localized displaynames for those properties (taking into =
account the Accept-Language header as PROPFIND would for property =
values).

Does your proposal cover those issues?  Can you give me a pointer to =
your draft?

Thanks,

  Eric



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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Julian--</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; I recall that you had a proposal =
for getting=20
the schema of the properties on a particular resource via DAV.&nbsp; =
Does this=20
proposal also allow for a generic property editor client?&nbsp; It seems =
like we=20
need a way for the server to indicate to a client:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>* what properties are editable by=20
end-users</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>* what properties are displayable =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>* what are the localized displaynames =
for those=20
properties (taking into account the&nbsp;Accept-Language header as =
PROPFIND=20
would for property values).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Does your proposal cover those =
issues?&nbsp; Can=20
you give me a pointer to your draft?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; Eric</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_019E_01C1D9DD.8D2DBFB0--



From w3c-dist-auth-request@w3.org  Tue Apr  2 03:44:48 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10104
	for <webdav-archive@odin.ietf.org>; Tue, 2 Apr 2002 03:44:48 -0500 (EST)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id DD11422B78; Tue,  2 Apr 2002 03:44:49 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id DAA24711;
	Tue, 2 Apr 2002 03:44:44 -0500 (EST)
Resent-Date: Tue, 2 Apr 2002 03:44:44 -0500 (EST)
Resent-Message-Id: <200204020844.DAA24711@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA24690
	for <w3c-dist-auth@www19.w3.org>; Tue, 2 Apr 2002 03:44:34 -0500 (EST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA06121
	for <w3c-dist-auth@w3.org>; Tue, 2 Apr 2002 03:44:33 -0500
Received: (qmail 14612 invoked by uid 0); 2 Apr 2002 08:43:58 -0000
Received: from pd950c3ce.dip.t-dialin.net (HELO lisa) (217.80.195.206)
  by mail.gmx.net (mp014-rz3) with SMTP; 2 Apr 2002 08:43:58 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Eric Sedlar" <eric.sedlar@oracle.com>
Cc: "DAV" <w3c-dist-auth@w3.org>
Date: Tue, 2 Apr 2002 10:43:53 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCIECFEFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <01a101c1da20$9b913d00$3bab2382@us.oracle.com>
Importance: Normal
Subject: RE: WebDAV property schema lookup
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6110
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit

Eric,

the current proposal ist at:

<http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-datatypes-la
test.html>

The format should allow "almost" generic editing (it will require that the
editor recognizes the reported data types).

The current proposal does not cover your three requirements. However I agree
that discovery of these properties makes a lot of sense -- the main question
being, how to marshall this information. Also, servers may not *have* this
information about dead properties (unless we define a protocol that
specificies how to send this information *to* the server). The least
intrusive way to provide additional information about properties the server
is aware of seems to be a special REPORT...

Julian

-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Eric Sedlar
Sent: Tuesday, April 02, 2002 10:30 AM
To: Julian Reschke
Cc: DAV
Subject: WebDAV property schema lookup


Julian--

  I recall that you had a proposal for getting the schema of the properties
on a particular resource via DAV.  Does this proposal also allow for a
generic property editor client?  It seems like we need a way for the server
to indicate to a client:

* what properties are editable by end-users
* what properties are displayable
* what are the localized displaynames for those properties (taking into
account the Accept-Language header as PROPFIND would for property values).

Does your proposal cover those issues?  Can you give me a pointer to your
draft?

Thanks,

  Eric



From w3c-dist-auth-request@w3.org  Tue Apr  2 03:52:25 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10213
	for <webdav-archive@odin.ietf.org>; Tue, 2 Apr 2002 03:52:25 -0500 (EST)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id BF1A922B80; Tue,  2 Apr 2002 03:52:26 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id DAA26554;
	Tue, 2 Apr 2002 03:52:24 -0500 (EST)
Resent-Date: Tue, 2 Apr 2002 03:52:24 -0500 (EST)
Resent-Message-Id: <200204020852.DAA26554@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA26520
	for <w3c-dist-auth@www19.w3.org>; Tue, 2 Apr 2002 03:52:16 -0500 (EST)
Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA07242
	for <w3c-dist-auth@w3.org>; Tue, 2 Apr 2002 03:52:16 -0500
Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10])
	by inet-mail1.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g328qFh01175;
	Tue, 2 Apr 2002 00:52:15 -0800 (PST)
Received: from esedlarlaptop (dhcp-4op7-4op8-east-130-35-171-59.us.oracle.com [130.35.171.59])
	by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g328qRK21705;
	Tue, 2 Apr 2002 01:52:27 -0700 (MST)
Message-ID: <01e301c1da23$af380840$3bab2382@us.oracle.com>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "DAV" <w3c-dist-auth@w3.org>
References: <JIEGINCHMLABHJBIGKBCIECFEFAA.julian.reschke@gmx.de>
Date: Tue, 2 Apr 2002 00:52:13 -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 property schema lookup
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6111
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.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 think that deciding which dead properties are editable will be done
on the client, but rather via some server-specific mechanism.  For example,
we would probably say that all dead properties not in the DAV or Oracle
namespaces are editable by default, and possibly allow some configuration in
a parameter file to list uneditable ones.

--Eric

----- Original Message -----
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Eric Sedlar" <eric.sedlar@oracle.com>
Cc: "DAV" <w3c-dist-auth@w3.org>
Sent: Tuesday, April 02, 2002 12:43 AM
Subject: RE: WebDAV property schema lookup


> Eric,
>
> the current proposal ist at:
>
>
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-datatypes-la
> test.html>
>
> The format should allow "almost" generic editing (it will require that the
> editor recognizes the reported data types).
>
> The current proposal does not cover your three requirements. However I
agree
> that discovery of these properties makes a lot of sense -- the main
question
> being, how to marshall this information. Also, servers may not *have* this
> information about dead properties (unless we define a protocol that
> specificies how to send this information *to* the server). The least
> intrusive way to provide additional information about properties the
server
> is aware of seems to be a special REPORT...
>
> Julian
>
> -----Original Message-----
> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
> Behalf Of Eric Sedlar
> Sent: Tuesday, April 02, 2002 10:30 AM
> To: Julian Reschke
> Cc: DAV
> Subject: WebDAV property schema lookup
>
>
> Julian--
>
>   I recall that you had a proposal for getting the schema of the
properties
> on a particular resource via DAV.  Does this proposal also allow for a
> generic property editor client?  It seems like we need a way for the
server
> to indicate to a client:
>
> * what properties are editable by end-users
> * what properties are displayable
> * what are the localized displaynames for those properties (taking into
> account the Accept-Language header as PROPFIND would for property values).
>
> Does your proposal cover those issues?  Can you give me a pointer to your
> draft?
>
> Thanks,
>
>   Eric
>
>



From w3c-dist-auth-request@w3.org  Sat Apr  6 10:56:08 2002
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12004
	for <webdav-archive@lists.ietf.org>; Sat, 6 Apr 2002 10:56:08 -0500 (EST)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA25122;
	Sat, 6 Apr 2002 10:55:41 -0500
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id KAA13585;
	Sat, 6 Apr 2002 10:51:39 -0500 (EST)
Resent-Date: Sat, 6 Apr 2002 10:51:39 -0500 (EST)
Resent-Message-Id: <200204061551.KAA13585@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA13558
	for <w3c-dist-auth@www19.w3.org>; Sat, 6 Apr 2002 10:51:32 -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 KAA24300
	for <w3c-dist-auth@w3.org>; Sat, 6 Apr 2002 10:51:31 -0500
Received: (qmail 17509 invoked by uid 0); 6 Apr 2002 15:50:59 -0000
Received: from pd950c386.dip.t-dialin.net (HELO lisa) (217.80.195.134)
  by mail.gmx.net (mp011-rz3) with SMTP; 6 Apr 2002 15:50:59 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Eric Sedlar" <eric.sedlar@oracle.com>
Cc: "DAV" <w3c-dist-auth@w3.org>
Date: Sat, 6 Apr 2002 17:51:08 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCOEJCEFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <01e301c1da23$af380840$3bab2382@us.oracle.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Subject: RE: WebDAV property schema lookup
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6112
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-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

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> Sent: Tuesday, April 02, 2002 10:52 AM
> To: Julian Reschke
> Cc: DAV
> Subject: Re: WebDAV property schema lookup
>
>
> I don't think that deciding which dead properties are editable
> will be done
> on the client, but rather via some server-specific mechanism.

I agree. The question being, how a server decides this for a given dead
property (it may not be able to do it).

> For example,
> we would probably say that all dead properties not in the DAV or Oracle
> namespaces are editable by default, and possibly allow some
> configuration in
> a parameter file to list uneditable ones.

That's certainly something that *can* be done.

So how do we proceed?

- I think that what our current draft says is needed as a basis anyway
- One possible approach would be to get into the schema / model business, à
la Exchange 2000 and Sharepoint
- A simpler approach would be to define marshalling for the additional
information you asked for as extensions to PROPFIND/PROPPATCH

For instance, the first two things you asked for (editability and
visibility) can trivially be marshalled in new property attributes (this
could be easily added to our existing datatype marshalling):

Proppatch request:

<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:Z="http://www.w3.com/standards/z39.50"
   xmlns:x="http://webdav.org/property-attribute">
  <D:set>
    <D:prop>
      <Z:released xsi:type="xs:boolean" x:hidden="true"
x:editable="false">false</Z:released>
    </D:prop>
  </D:set>
</D:propertyupdate>

..

Propfind response:

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"
   xmlns:Z="http://www.w3.com/standards/z39.50"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:x="http://webdav.org/property-attribute">
  <D:response>
    <D:href>http://www.foo.com/bar.html</D:href>
    <D:propstat>
      <D:prop>
        <D:getcontenttype>text/html</D:getcontenttype>
        <Z:released xsi:type="xs:boolean" x:hidden="true"
x:editable="false">1</Z:released>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>


Note that this is compatible with RFC2518 as

- old clients will never send the new attributes upon PROPPATCH
- servers can add the two attributes two the existing property values
transparently (because they sit in a new namespace which should be ignored
by old clients)


Adding textual descriptions is a bit harder, because it's not as easy to
marshall them in attribute values (we need to make sure that we properly
treat language negotation/xml:lang). I wouldn't want to send this
information with every PROPFIND reply, so we probably would require that a
client specifically asks for them:

Propfind request:

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
  xmlns:Z="http://www.w3.com/standards/z39.50"
   xmlns:x="http://webdav.org/property-attribute">
  <D:prop x:include-descriptions="true">
    <D:getcontenttype/>
    <Z:released/>
  </D:prop>
</D:propfind>


Propfind response:

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"
   xmlns:Z="http://www.w3.com/standards/z39.50"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:x="http://webdav.org/property-attribute">
  <D:response>
    <D:href>http://www.foo.com/bar.html</D:href>
    <D:propstat>
      <D:prop>
        <D:getcontenttype>text/html</D:getcontenttype>
        <Z:released xsi:type="xs:boolean" x:hidden="true"
x:editable="false"><x:description
xml:lang="en">released?</x:description>1</Z:released>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>


Feedback appreciated.

Julian




From w3c-dist-auth-request@w3.org  Sat Apr  6 15:58:53 2002
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15431
	for <webdav-archive@odin.ietf.org>; Sat, 6 Apr 2002 15:58:53 -0500 (EST)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA26506;
	Sat, 6 Apr 2002 15:58:41 -0500
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA27478;
	Sat, 6 Apr 2002 15:54:55 -0500 (EST)
Resent-Date: Sat, 6 Apr 2002 15:54:55 -0500 (EST)
Resent-Message-Id: <200204062054.PAA27478@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA27458
	for <w3c-dist-auth@www19.w3.org>; Sat, 6 Apr 2002 15:54:52 -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 PAA26086
	for <w3c-dist-auth@w3.org>; Sat, 6 Apr 2002 15:54:52 -0500
Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Sat, 06 Apr 2002 15:51:22 -0500
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19)
	id <FJQG9QPC>; Sat, 6 Apr 2002 15:54:17 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B1066908FC@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: DAV <w3c-dist-auth@w3.org>
Date: Sat, 6 Apr 2002 15:54:16 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id PAA27458
Subject: RE: WebDAV property schema lookup
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6113
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 8bit

I agree that property "metadata" should only be returned
if the client specifically asks for it.  Along the same lines,
I would provide a mechanism for the client to ask for specific
metadata, since it doesn't make any sense to send back to
the client metadata information that it doesn't understand.
Finally, I would marshall all of this as XML elements, not as
attributes.  XML element values are significantly more extensible
that attribute values, and given the relative infrequency of
asking for this metadata, the additional bytes required by
XML elements shouldn't be an issue.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Saturday, April 06, 2002 10:51 AM
To: Eric Sedlar
Cc: DAV
Subject: RE: WebDAV property schema lookup


> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> Sent: Tuesday, April 02, 2002 10:52 AM
> To: Julian Reschke
> Cc: DAV
> Subject: Re: WebDAV property schema lookup
>
>
> I don't think that deciding which dead properties are editable
> will be done
> on the client, but rather via some server-specific mechanism.

I agree. The question being, how a server decides this for a given dead
property (it may not be able to do it).

> For example,
> we would probably say that all dead properties not in the DAV or Oracle
> namespaces are editable by default, and possibly allow some
> configuration in
> a parameter file to list uneditable ones.

That's certainly something that *can* be done.

So how do we proceed?

- I think that what our current draft says is needed as a basis anyway
- One possible approach would be to get into the schema / model business, à
la Exchange 2000 and Sharepoint
- A simpler approach would be to define marshalling for the additional
information you asked for as extensions to PROPFIND/PROPPATCH

For instance, the first two things you asked for (editability and
visibility) can trivially be marshalled in new property attributes (this
could be easily added to our existing datatype marshalling):

Proppatch request:

<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:Z="http://www.w3.com/standards/z39.50"
   xmlns:x="http://webdav.org/property-attribute">
  <D:set>
    <D:prop>
      <Z:released xsi:type="xs:boolean" x:hidden="true"
x:editable="false">false</Z:released>
    </D:prop>
  </D:set>
</D:propertyupdate>

..

Propfind response:

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"
   xmlns:Z="http://www.w3.com/standards/z39.50"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:x="http://webdav.org/property-attribute">
  <D:response>
    <D:href>http://www.foo.com/bar.html</D:href>
    <D:propstat>
      <D:prop>
        <D:getcontenttype>text/html</D:getcontenttype>
        <Z:released xsi:type="xs:boolean" x:hidden="true"
x:editable="false">1</Z:released>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>


Note that this is compatible with RFC2518 as

- old clients will never send the new attributes upon PROPPATCH
- servers can add the two attributes two the existing property values
transparently (because they sit in a new namespace which should be ignored
by old clients)


Adding textual descriptions is a bit harder, because it's not as easy to
marshall them in attribute values (we need to make sure that we properly
treat language negotation/xml:lang). I wouldn't want to send this
information with every PROPFIND reply, so we probably would require that a
client specifically asks for them:

Propfind request:

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
  xmlns:Z="http://www.w3.com/standards/z39.50"
   xmlns:x="http://webdav.org/property-attribute">
  <D:prop x:include-descriptions="true">
    <D:getcontenttype/>
    <Z:released/>
  </D:prop>
</D:propfind>


Propfind response:

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"
   xmlns:Z="http://www.w3.com/standards/z39.50"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:x="http://webdav.org/property-attribute">
  <D:response>
    <D:href>http://www.foo.com/bar.html</D:href>
    <D:propstat>
      <D:prop>
        <D:getcontenttype>text/html</D:getcontenttype>
        <Z:released xsi:type="xs:boolean" x:hidden="true"
x:editable="false"><x:description
xml:lang="en">released?</x:description>1</Z:released>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>


Feedback appreciated.

Julian



From w3c-dist-auth-request@w3.org  Sat Apr  6 22:37:27 2002
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20728
	for <webdav-archive@odin.ietf.org>; Sat, 6 Apr 2002 22:37:27 -0500 (EST)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA24808;
	Sat, 6 Apr 2002 22:36:55 -0500
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id WAA19355;
	Sat, 6 Apr 2002 22:33:28 -0500 (EST)
Resent-Date: Sat, 6 Apr 2002 22:33:28 -0500 (EST)
Resent-Message-Id: <200204070333.WAA19355@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA19259
	for <w3c-dist-auth@www19.w3.org>; Sat, 6 Apr 2002 22:33:23 -0500 (EST)
Received: from exchimc.pcdocs.com ([208.255.196.152])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA24525
	for <w3c-dist-auth@w3.org>; Sat, 6 Apr 2002 22:33:23 -0500
Received: by EXCHANGE_IMC with Internet Mail Service (5.5.2650.21)
	id <HWXJCJRS>; Sat, 6 Apr 2002 22:32:58 -0500
Message-ID: <39FB3B2B1509CE43A251C50896C9BA95089375@tallyx1>
From: Gary Cowan <Gary.Cowan@Tally.Hummingbird.com>
To: DAV <w3c-dist-auth@w3.org>, "'Clemm, Geoff'" <gclemm@rational.com>
Date: Sat, 6 Apr 2002 22:32:44 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id WAA19259
Subject: RE: WebDAV property schema lookup
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6114
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-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

This situation illustrates a fundamental weakness with WebDAV in respect to
enterprise document management systems. The WebDAV philosophy assumes that
the client is controlling the properties of a resource/document and the
server mearly acts as a store for the property information. Wheras a DM
server maintains extensive metadata for a given resource especially when
vertical market applications have been built on top of the DM system. WebDAV
does not provide a methodology by which this metadata can be exposed. As
such DM systems must still construct proprietary client applications causing
users to perform authoring in the authoring tool while performing DM
specific actions in the DM client. 

At this point in time it still makes more sense for DM systems to construct
tight integration mechanisms within the context of the authoring
application. This gives the DM system the ability expose its own metadata to
the user during document creation/editing.

WebDAV is a very attractive protocol but this one limitation is inhibiting
its extensive use within the enterprise DM community. 

> ----------
> From: 	Clemm, Geoff[SMTP:gclemm@rational.com]
> Sent: 	Saturday, April 06, 2002 3:54 PM
> To: 	DAV
> Subject: 	RE: WebDAV property schema lookup
> 
> I agree that property "metadata" should only be returned
> if the client specifically asks for it.  Along the same lines,
> I would provide a mechanism for the client to ask for specific
> metadata, since it doesn't make any sense to send back to
> the client metadata information that it doesn't understand.
> Finally, I would marshall all of this as XML elements, not as
> attributes.  XML element values are significantly more extensible
> that attribute values, and given the relative infrequency of
> asking for this metadata, the additional bytes required by
> XML elements shouldn't be an issue.
> 
> Cheers,
> Geoff
> 
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Saturday, April 06, 2002 10:51 AM
> To: Eric Sedlar
> Cc: DAV
> Subject: RE: WebDAV property schema lookup
> 
> 
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> > Sent: Tuesday, April 02, 2002 10:52 AM
> > To: Julian Reschke
> > Cc: DAV
> > Subject: Re: WebDAV property schema lookup
> >
> >
> > I don't think that deciding which dead properties are editable
> > will be done
> > on the client, but rather via some server-specific mechanism.
> 
> I agree. The question being, how a server decides this for a given dead
> property (it may not be able to do it).
> 
> > For example,
> > we would probably say that all dead properties not in the DAV or Oracle
> > namespaces are editable by default, and possibly allow some
> > configuration in
> > a parameter file to list uneditable ones.
> 
> That's certainly something that *can* be done.
> 
> So how do we proceed?
> 
> - I think that what our current draft says is needed as a basis anyway
> - One possible approach would be to get into the schema / model business,
> à
> la Exchange 2000 and Sharepoint
> - A simpler approach would be to define marshalling for the additional
> information you asked for as extensions to PROPFIND/PROPPATCH
> 
> For instance, the first two things you asked for (editability and
> visibility) can trivially be marshalled in new property attributes (this
> could be easily added to our existing datatype marshalling):
> 
> Proppatch request:
> 
> <?xml version="1.0" encoding="utf-8" ?>
> <D:propertyupdate xmlns:D="DAV:"
>    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xmlns:xs="http://www.w3.org/2001/XMLSchema"
>    xmlns:Z="http://www.w3.com/standards/z39.50"
>    xmlns:x="http://webdav.org/property-attribute">
>   <D:set>
>     <D:prop>
>       <Z:released xsi:type="xs:boolean" x:hidden="true"
> x:editable="false">false</Z:released>
>     </D:prop>
>   </D:set>
> </D:propertyupdate>
> 
> ..
> 
> Propfind response:
> 
> <?xml version="1.0" encoding="utf-8" ?>
> <D:multistatus xmlns:D="DAV:"
>    xmlns:Z="http://www.w3.com/standards/z39.50"
>    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xmlns:xs="http://www.w3.org/2001/XMLSchema"
>    xmlns:x="http://webdav.org/property-attribute">
>   <D:response>
>     <D:href>http://www.foo.com/bar.html</D:href>
>     <D:propstat>
>       <D:prop>
>         <D:getcontenttype>text/html</D:getcontenttype>
>         <Z:released xsi:type="xs:boolean" x:hidden="true"
> x:editable="false">1</Z:released>
>       </D:prop>
>       <D:status>HTTP/1.1 200 OK</D:status>
>     </D:propstat>
>   </D:response>
> </D:multistatus>
> 
> 
> Note that this is compatible with RFC2518 as
> 
> - old clients will never send the new attributes upon PROPPATCH
> - servers can add the two attributes two the existing property values
> transparently (because they sit in a new namespace which should be ignored
> by old clients)
> 
> 
> Adding textual descriptions is a bit harder, because it's not as easy to
> marshall them in attribute values (we need to make sure that we properly
> treat language negotation/xml:lang). I wouldn't want to send this
> information with every PROPFIND reply, so we probably would require that a
> client specifically asks for them:
> 
> Propfind request:
> 
> <?xml version="1.0" encoding="utf-8" ?>
> <D:propfind xmlns:D="DAV:"
>   xmlns:Z="http://www.w3.com/standards/z39.50"
>    xmlns:x="http://webdav.org/property-attribute">
>   <D:prop x:include-descriptions="true">
>     <D:getcontenttype/>
>     <Z:released/>
>   </D:prop>
> </D:propfind>
> 
> 
> Propfind response:
> 
> <?xml version="1.0" encoding="utf-8" ?>
> <D:multistatus xmlns:D="DAV:"
>    xmlns:Z="http://www.w3.com/standards/z39.50"
>    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xmlns:xs="http://www.w3.org/2001/XMLSchema"
>    xmlns:x="http://webdav.org/property-attribute">
>   <D:response>
>     <D:href>http://www.foo.com/bar.html</D:href>
>     <D:propstat>
>       <D:prop>
>         <D:getcontenttype>text/html</D:getcontenttype>
>         <Z:released xsi:type="xs:boolean" x:hidden="true"
> x:editable="false"><x:description
> xml:lang="en">released?</x:description>1</Z:released>
>       </D:prop>
>       <D:status>HTTP/1.1 200 OK</D:status>
>     </D:propstat>
>   </D:response>
> </D:multistatus>
> 
> 
> Feedback appreciated.
> 
> Julian
> 



From w3c-dist-auth-request@w3.org  Sun Apr  7 05:38:49 2002
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23909
	for <webdav-archive@odin.ietf.org>; Sun, 7 Apr 2002 05:38:49 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA26102;
	Sun, 7 Apr 2002 05:38:30 -0400
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id FAA04941;
	Sun, 7 Apr 2002 05:34:52 -0400 (EDT)
Resent-Date: Sun, 7 Apr 2002 05:34:52 -0400 (EDT)
Resent-Message-Id: <200204070934.FAA04941@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA04921
	for <w3c-dist-auth@www19.w3.org>; Sun, 7 Apr 2002 05:34:44 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA25804
	for <w3c-dist-auth@w3.org>; Sun, 7 Apr 2002 05:34:43 -0400
Received: (qmail 22412 invoked by uid 0); 7 Apr 2002 09:34:12 -0000
Received: from pd950c3da.dip.t-dialin.net (HELO lisa) (217.80.195.218)
  by mail.gmx.net (mp006-rz3) with SMTP; 7 Apr 2002 09:34:12 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Clemm, Geoff" <gclemm@rational.com>, "DAV" <w3c-dist-auth@w3.org>
Date: Sun, 7 Apr 2002 11:34:05 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCOEJKEFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1066908FC@SUS-MA1IT01>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Subject: RE: WebDAV property schema lookup
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6115
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-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

Geoff,

in general agree that when defining marshalling formats, extensibility
should be planned in and thus attributes can be problematic.

In this particular case however:

- Marshalling data type information using the xsi:type attribute is defined
in XML Schema (datatypes) and already is done in other protocols (like
SOAP). So here I think we should benefit from existing infrastructure (for
instance existing libraries that support XML Schema datatypes)

- WebDAV's multistatus format isn't very extensible itself (although it uses
elements). To be extensible, the actual propery values would need one
additional wrapper, such as:

<response>
  <href>...</href>
  <propstat>
    <prop>
      <wrapper>
        <one-dead-property>...</one-dead-property>
      </wrapper>
      <wrapper>
        <one-dead-property2>...</one-dead-property2>
      </wrapper>
   </prop>
  </propstat>
  ...

or

<response>
  <href>...</href>
  <propstat>
    <prop>
      <one-dead-property>...</one-dead-property>
   </prop>
    <prop>
      <one-dead-property2>...</one-dead-property2>
   </prop>
  </propstat>
  ...


However we don't have that, which makes extending property values using
elements harder than using attributes.

Julian

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Saturday, April 06, 2002 10:54 PM
> To: DAV
> Subject: RE: WebDAV property schema lookup
>
>
> I agree that property "metadata" should only be returned
> if the client specifically asks for it.  Along the same lines,
> I would provide a mechanism for the client to ask for specific
> metadata, since it doesn't make any sense to send back to
> the client metadata information that it doesn't understand.
> Finally, I would marshall all of this as XML elements, not as
> attributes.  XML element values are significantly more extensible
> that attribute values, and given the relative infrequency of
> asking for this metadata, the additional bytes required by
> XML elements shouldn't be an issue.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Saturday, April 06, 2002 10:51 AM
> To: Eric Sedlar
> Cc: DAV
> Subject: RE: WebDAV property schema lookup
>
>
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> > Sent: Tuesday, April 02, 2002 10:52 AM
> > To: Julian Reschke
> > Cc: DAV
> > Subject: Re: WebDAV property schema lookup
> >
> >
> > I don't think that deciding which dead properties are editable
> > will be done
> > on the client, but rather via some server-specific mechanism.
>
> I agree. The question being, how a server decides this for a given dead
> property (it may not be able to do it).
>
> > For example,
> > we would probably say that all dead properties not in the DAV or Oracle
> > namespaces are editable by default, and possibly allow some
> > configuration in
> > a parameter file to list uneditable ones.
>
> That's certainly something that *can* be done.
>
> So how do we proceed?
>
> - I think that what our current draft says is needed as a basis anyway
> - One possible approach would be to get into the schema / model
> business, à
> la Exchange 2000 and Sharepoint
> - A simpler approach would be to define marshalling for the additional
> information you asked for as extensions to PROPFIND/PROPPATCH
>
> For instance, the first two things you asked for (editability and
> visibility) can trivially be marshalled in new property attributes (this
> could be easily added to our existing datatype marshalling):
>
> Proppatch request:
>
> <?xml version="1.0" encoding="utf-8" ?>
> <D:propertyupdate xmlns:D="DAV:"
>    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xmlns:xs="http://www.w3.org/2001/XMLSchema"
>    xmlns:Z="http://www.w3.com/standards/z39.50"
>    xmlns:x="http://webdav.org/property-attribute">
>   <D:set>
>     <D:prop>
>       <Z:released xsi:type="xs:boolean" x:hidden="true"
> x:editable="false">false</Z:released>
>     </D:prop>
>   </D:set>
> </D:propertyupdate>
>
> ..
>
> Propfind response:
>
> <?xml version="1.0" encoding="utf-8" ?>
> <D:multistatus xmlns:D="DAV:"
>    xmlns:Z="http://www.w3.com/standards/z39.50"
>    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xmlns:xs="http://www.w3.org/2001/XMLSchema"
>    xmlns:x="http://webdav.org/property-attribute">
>   <D:response>
>     <D:href>http://www.foo.com/bar.html</D:href>
>     <D:propstat>
>       <D:prop>
>         <D:getcontenttype>text/html</D:getcontenttype>
>         <Z:released xsi:type="xs:boolean" x:hidden="true"
> x:editable="false">1</Z:released>
>       </D:prop>
>       <D:status>HTTP/1.1 200 OK</D:status>
>     </D:propstat>
>   </D:response>
> </D:multistatus>
>
>
> Note that this is compatible with RFC2518 as
>
> - old clients will never send the new attributes upon PROPPATCH
> - servers can add the two attributes two the existing property values
> transparently (because they sit in a new namespace which should be ignored
> by old clients)
>
>
> Adding textual descriptions is a bit harder, because it's not as easy to
> marshall them in attribute values (we need to make sure that we properly
> treat language negotation/xml:lang). I wouldn't want to send this
> information with every PROPFIND reply, so we probably would require that a
> client specifically asks for them:
>
> Propfind request:
>
> <?xml version="1.0" encoding="utf-8" ?>
> <D:propfind xmlns:D="DAV:"
>   xmlns:Z="http://www.w3.com/standards/z39.50"
>    xmlns:x="http://webdav.org/property-attribute">
>   <D:prop x:include-descriptions="true">
>     <D:getcontenttype/>
>     <Z:released/>
>   </D:prop>
> </D:propfind>
>
>
> Propfind response:
>
> <?xml version="1.0" encoding="utf-8" ?>
> <D:multistatus xmlns:D="DAV:"
>    xmlns:Z="http://www.w3.com/standards/z39.50"
>    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xmlns:xs="http://www.w3.org/2001/XMLSchema"
>    xmlns:x="http://webdav.org/property-attribute">
>   <D:response>
>     <D:href>http://www.foo.com/bar.html</D:href>
>     <D:propstat>
>       <D:prop>
>         <D:getcontenttype>text/html</D:getcontenttype>
>         <Z:released xsi:type="xs:boolean" x:hidden="true"
> x:editable="false"><x:description
> xml:lang="en">released?</x:description>1</Z:released>
>       </D:prop>
>       <D:status>HTTP/1.1 200 OK</D:status>
>     </D:propstat>
>   </D:response>
> </D:multistatus>
>
>
> Feedback appreciated.
>
> Julian
>



From w3c-dist-auth-request@w3.org  Sun Apr  7 06:02:28 2002
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24158
	for <webdav-archive@odin.ietf.org>; Sun, 7 Apr 2002 06:02:28 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA28020;
	Sun, 7 Apr 2002 06:02:21 -0400
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id FAA06677;
	Sun, 7 Apr 2002 05:59:01 -0400 (EDT)
Resent-Date: Sun, 7 Apr 2002 05:59:01 -0400 (EDT)
Resent-Message-Id: <200204070959.FAA06677@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA06647
	for <w3c-dist-auth@www19.w3.org>; Sun, 7 Apr 2002 05:58:52 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA27751
	for <w3c-dist-auth@w3.org>; Sun, 7 Apr 2002 05:58:52 -0400
Received: (qmail 785 invoked by uid 0); 7 Apr 2002 09:58:20 -0000
Received: from pd950c3da.dip.t-dialin.net (HELO lisa) (217.80.195.218)
  by mail.gmx.net (mp007-rz3) with SMTP; 7 Apr 2002 09:58:20 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Gary Cowan" <Gary.Cowan@Tally.Hummingbird.com>,
        "DAV" <w3c-dist-auth@w3.org>, "'Clemm, Geoff'" <gclemm@rational.com>
Date: Sun, 7 Apr 2002 11:58:14 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCIEJLEFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <39FB3B2B1509CE43A251C50896C9BA95089375@tallyx1>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Subject: RE: WebDAV property schema lookup
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6116
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-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

Gary,

I'm not sure I understand this statement...

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Gary Cowan
> Sent: Sunday, April 07, 2002 5:33 AM
> To: DAV; 'Clemm, Geoff'
> Subject: RE: WebDAV property schema lookup
>
>
> This situation illustrates a fundamental weakness with WebDAV in
> respect to
> enterprise document management systems. The WebDAV philosophy assumes that
> the client is controlling the properties of a resource/document and the
> server mearly acts as a store for the property information. Wheras a DM

I don't think that RFC2518 says this. The protocol certainly allows servers
to implement a rich set of server-defined properties. For instance:

- RFC3253 implements a whole set of server-defined properties that model
versioning properties,

- Microsoft Sharepoint (although breaking WebDAV in some other aspects)
nicely exposes document metadata as WebDAV properties (for instance, it
supports document classes with inheritence, their discovery and
manipulation, mandatory typed properties...)

> server maintains extensive metadata for a given resource especially when
> vertical market applications have been built on top of the DM
> system. WebDAV
> does not provide a methodology by which this metadata can be exposed. As

I think this isn't true. Could you please explain this in more detail?

> such DM systems must still construct proprietary client
> applications causing
> users to perform authoring in the authoring tool while performing DM
> specific actions in the DM client.

That sounds a bit like "existing clients do not support manipulation of our
server's properties, thus the protocol is broken". I'd say, we just need
better clients.

> At this point in time it still makes more sense for DM systems to
> construct
> tight integration mechanisms within the context of the authoring
> application. This gives the DM system the ability expose its own
> metadata to
> the user during document creation/editing.
>
> WebDAV is a very attractive protocol but this one limitation is inhibiting
> its extensive use within the enterprise DM community.
>
> > ----------
> > From: 	Clemm, Geoff[SMTP:gclemm@rational.com]
> > Sent: 	Saturday, April 06, 2002 3:54 PM
> > To: 	DAV
> > Subject: 	RE: WebDAV property schema lookup
> >
> > I agree that property "metadata" should only be returned
> > if the client specifically asks for it.  Along the same lines,
> > I would provide a mechanism for the client to ask for specific
> > metadata, since it doesn't make any sense to send back to
> > the client metadata information that it doesn't understand.
> > Finally, I would marshall all of this as XML elements, not as
> > attributes.  XML element values are significantly more extensible
> > that attribute values, and given the relative infrequency of
> > asking for this metadata, the additional bytes required by
> > XML elements shouldn't be an issue.
> >
> > Cheers,
> > Geoff
> >
> > -----Original Message-----
> > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > Sent: Saturday, April 06, 2002 10:51 AM
> > To: Eric Sedlar
> > Cc: DAV
> > Subject: RE: WebDAV property schema lookup
> >
> >
> > > From: w3c-dist-auth-request@w3.org
> > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> > > Sent: Tuesday, April 02, 2002 10:52 AM
> > > To: Julian Reschke
> > > Cc: DAV
> > > Subject: Re: WebDAV property schema lookup
> > >
> > >
> > > I don't think that deciding which dead properties are editable
> > > will be done
> > > on the client, but rather via some server-specific mechanism.
> >
> > I agree. The question being, how a server decides this for a given dead
> > property (it may not be able to do it).
> >
> > > For example,
> > > we would probably say that all dead properties not in the DAV
> or Oracle
> > > namespaces are editable by default, and possibly allow some
> > > configuration in
> > > a parameter file to list uneditable ones.
> >
> > That's certainly something that *can* be done.
> >
> > So how do we proceed?
> >
> > - I think that what our current draft says is needed as a basis anyway
> > - One possible approach would be to get into the schema / model
> business,
> > à
> > la Exchange 2000 and Sharepoint
> > - A simpler approach would be to define marshalling for the additional
> > information you asked for as extensions to PROPFIND/PROPPATCH
> >
> > For instance, the first two things you asked for (editability and
> > visibility) can trivially be marshalled in new property attributes (this
> > could be easily added to our existing datatype marshalling):
> >
> > Proppatch request:
> >
> > <?xml version="1.0" encoding="utf-8" ?>
> > <D:propertyupdate xmlns:D="DAV:"
> >    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >    xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >    xmlns:Z="http://www.w3.com/standards/z39.50"
> >    xmlns:x="http://webdav.org/property-attribute">
> >   <D:set>
> >     <D:prop>
> >       <Z:released xsi:type="xs:boolean" x:hidden="true"
> > x:editable="false">false</Z:released>
> >     </D:prop>
> >   </D:set>
> > </D:propertyupdate>
> >
> > ..
> >
> > Propfind response:
> >
> > <?xml version="1.0" encoding="utf-8" ?>
> > <D:multistatus xmlns:D="DAV:"
> >    xmlns:Z="http://www.w3.com/standards/z39.50"
> >    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >    xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >    xmlns:x="http://webdav.org/property-attribute">
> >   <D:response>
> >     <D:href>http://www.foo.com/bar.html</D:href>
> >     <D:propstat>
> >       <D:prop>
> >         <D:getcontenttype>text/html</D:getcontenttype>
> >         <Z:released xsi:type="xs:boolean" x:hidden="true"
> > x:editable="false">1</Z:released>
> >       </D:prop>
> >       <D:status>HTTP/1.1 200 OK</D:status>
> >     </D:propstat>
> >   </D:response>
> > </D:multistatus>
> >
> >
> > Note that this is compatible with RFC2518 as
> >
> > - old clients will never send the new attributes upon PROPPATCH
> > - servers can add the two attributes two the existing property values
> > transparently (because they sit in a new namespace which should
> be ignored
> > by old clients)
> >
> >
> > Adding textual descriptions is a bit harder, because it's not as easy to
> > marshall them in attribute values (we need to make sure that we properly
> > treat language negotation/xml:lang). I wouldn't want to send this
> > information with every PROPFIND reply, so we probably would
> require that a
> > client specifically asks for them:
> >
> > Propfind request:
> >
> > <?xml version="1.0" encoding="utf-8" ?>
> > <D:propfind xmlns:D="DAV:"
> >   xmlns:Z="http://www.w3.com/standards/z39.50"
> >    xmlns:x="http://webdav.org/property-attribute">
> >   <D:prop x:include-descriptions="true">
> >     <D:getcontenttype/>
> >     <Z:released/>
> >   </D:prop>
> > </D:propfind>
> >
> >
> > Propfind response:
> >
> > <?xml version="1.0" encoding="utf-8" ?>
> > <D:multistatus xmlns:D="DAV:"
> >    xmlns:Z="http://www.w3.com/standards/z39.50"
> >    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >    xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >    xmlns:x="http://webdav.org/property-attribute">
> >   <D:response>
> >     <D:href>http://www.foo.com/bar.html</D:href>
> >     <D:propstat>
> >       <D:prop>
> >         <D:getcontenttype>text/html</D:getcontenttype>
> >         <Z:released xsi:type="xs:boolean" x:hidden="true"
> > x:editable="false"><x:description
> > xml:lang="en">released?</x:description>1</Z:released>
> >       </D:prop>
> >       <D:status>HTTP/1.1 200 OK</D:status>
> >     </D:propstat>
> >   </D:response>
> > </D:multistatus>
> >
> >
> > Feedback appreciated.
> >
> > Julian
> >
>



From w3c-dist-auth-request@w3.org  Sun Apr  7 18:01:56 2002
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01302
	for <webdav-archive@odin.ietf.org>; Sun, 7 Apr 2002 18:01:56 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA28940;
	Sun, 7 Apr 2002 18:01:41 -0400
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id RAA16125;
	Sun, 7 Apr 2002 17:30:23 -0400 (EDT)
Resent-Date: Sun, 7 Apr 2002 17:30:23 -0400 (EDT)
Resent-Message-Id: <200204072130.RAA16125@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA15879
	for <w3c-dist-auth@www19.w3.org>; Sun, 7 Apr 2002 17:29:33 -0400 (EDT)
Received: from opentext.com (drawbridge.opentext.com [204.138.115.3])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA26113
	for <w3c-dist-auth@w3.org>; Sun, 7 Apr 2002 17:29:32 -0400
Received: from vectorsvc.wl.opentext.com (ava.wl.opentext.com [172.21.5.96])
	by opentext.com (8.9.3/8.9.3) with ESMTP id RAA08231;
	Sun, 7 Apr 2002 17:28:53 -0400
Received: (from root@localhost)
	by vectorsvc.wl.opentext.com (8.9.3/8.9.3) id RAA08221;
	Sun, 7 Apr 2002 17:28:53 -0400
Received: from 085.dhcp11.opentext.com(172.21.11.85) by krusty.wl.opentext.com via smap (V2.1)
	id xma008205; Sun, 7 Apr 02 17:28:46 -0400
From: "Dylan Barrell" <dbarrell@opentext.com>
To: "Gary Cowan" <Gary.Cowan@Tally.Hummingbird.com>,
        "DAV" <w3c-dist-auth@w3.org>, "'Clemm, Geoff'" <gclemm@rational.com>
Date: Sun, 7 Apr 2002 17:27:55 -0400
Message-ID: <NEBBIBDBCLDPAGPIKGMCEEAAEPAA.dbarrell@opentext.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <39FB3B2B1509CE43A251C50896C9BA95089375@tallyx1>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Subject: RE: WebDAV property schema lookup
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6117
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-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

Absolutely agree - I brought this issue up a couple of months ago.

From my perspective we need two things

1) We need the ability for the server to enforce schema on documents when
they are created (we talked about a multi-put a couple of months back).
Schema descovery is also an issue as the client needs to know what the
mandatory properties are before it can issue the multi-put.

2) We need to have a way for the server to tell the client where to redirect
the user if the user want to manipulate the object in a way that is out of
scope for WebDAV - e.g. initiate a chat with the author of the document. In
fact, the server should be able to tell the client what URL to go to for
these actions as well as what client side application to spawn should it be
available.

--Dylan

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Gary Cowan
> Sent: Saturday, April 06, 2002 10:33 PM
> To: DAV; 'Clemm, Geoff'
> Subject: RE: WebDAV property schema lookup
>
>
> This situation illustrates a fundamental weakness with WebDAV in
> respect to
> enterprise document management systems. The WebDAV philosophy assumes that
> the client is controlling the properties of a resource/document and the
> server mearly acts as a store for the property information. Wheras a DM
> server maintains extensive metadata for a given resource especially when
> vertical market applications have been built on top of the DM
> system. WebDAV
> does not provide a methodology by which this metadata can be exposed. As
> such DM systems must still construct proprietary client
> applications causing
> users to perform authoring in the authoring tool while performing DM
> specific actions in the DM client.
>
> At this point in time it still makes more sense for DM systems to
> construct
> tight integration mechanisms within the context of the authoring
> application. This gives the DM system the ability expose its own
> metadata to
> the user during document creation/editing.
>
> WebDAV is a very attractive protocol but this one limitation is inhibiting
> its extensive use within the enterprise DM community.
>
> > ----------
> > From: 	Clemm, Geoff[SMTP:gclemm@rational.com]
> > Sent: 	Saturday, April 06, 2002 3:54 PM
> > To: 	DAV
> > Subject: 	RE: WebDAV property schema lookup
> >
> > I agree that property "metadata" should only be returned
> > if the client specifically asks for it.  Along the same lines,
> > I would provide a mechanism for the client to ask for specific
> > metadata, since it doesn't make any sense to send back to
> > the client metadata information that it doesn't understand.
> > Finally, I would marshall all of this as XML elements, not as
> > attributes.  XML element values are significantly more extensible
> > that attribute values, and given the relative infrequency of
> > asking for this metadata, the additional bytes required by
> > XML elements shouldn't be an issue.
> >
> > Cheers,
> > Geoff
> >
> > -----Original Message-----
> > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > Sent: Saturday, April 06, 2002 10:51 AM
> > To: Eric Sedlar
> > Cc: DAV
> > Subject: RE: WebDAV property schema lookup
> >
> >
> > > From: w3c-dist-auth-request@w3.org
> > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> > > Sent: Tuesday, April 02, 2002 10:52 AM
> > > To: Julian Reschke
> > > Cc: DAV
> > > Subject: Re: WebDAV property schema lookup
> > >
> > >
> > > I don't think that deciding which dead properties are editable
> > > will be done
> > > on the client, but rather via some server-specific mechanism.
> >
> > I agree. The question being, how a server decides this for a given dead
> > property (it may not be able to do it).
> >
> > > For example,
> > > we would probably say that all dead properties not in the DAV
> or Oracle
> > > namespaces are editable by default, and possibly allow some
> > > configuration in
> > > a parameter file to list uneditable ones.
> >
> > That's certainly something that *can* be done.
> >
> > So how do we proceed?
> >
> > - I think that what our current draft says is needed as a basis anyway
> > - One possible approach would be to get into the schema / model
> business,
> > à
> > la Exchange 2000 and Sharepoint
> > - A simpler approach would be to define marshalling for the additional
> > information you asked for as extensions to PROPFIND/PROPPATCH
> >
> > For instance, the first two things you asked for (editability and
> > visibility) can trivially be marshalled in new property attributes (this
> > could be easily added to our existing datatype marshalling):
> >
> > Proppatch request:
> >
> > <?xml version="1.0" encoding="utf-8" ?>
> > <D:propertyupdate xmlns:D="DAV:"
> >    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >    xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >    xmlns:Z="http://www.w3.com/standards/z39.50"
> >    xmlns:x="http://webdav.org/property-attribute">
> >   <D:set>
> >     <D:prop>
> >       <Z:released xsi:type="xs:boolean" x:hidden="true"
> > x:editable="false">false</Z:released>
> >     </D:prop>
> >   </D:set>
> > </D:propertyupdate>
> >
> > ..
> >
> > Propfind response:
> >
> > <?xml version="1.0" encoding="utf-8" ?>
> > <D:multistatus xmlns:D="DAV:"
> >    xmlns:Z="http://www.w3.com/standards/z39.50"
> >    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >    xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >    xmlns:x="http://webdav.org/property-attribute">
> >   <D:response>
> >     <D:href>http://www.foo.com/bar.html</D:href>
> >     <D:propstat>
> >       <D:prop>
> >         <D:getcontenttype>text/html</D:getcontenttype>
> >         <Z:released xsi:type="xs:boolean" x:hidden="true"
> > x:editable="false">1</Z:released>
> >       </D:prop>
> >       <D:status>HTTP/1.1 200 OK</D:status>
> >     </D:propstat>
> >   </D:response>
> > </D:multistatus>
> >
> >
> > Note that this is compatible with RFC2518 as
> >
> > - old clients will never send the new attributes upon PROPPATCH
> > - servers can add the two attributes two the existing property values
> > transparently (because they sit in a new namespace which should
> be ignored
> > by old clients)
> >
> >
> > Adding textual descriptions is a bit harder, because it's not as easy to
> > marshall them in attribute values (we need to make sure that we properly
> > treat language negotation/xml:lang). I wouldn't want to send this
> > information with every PROPFIND reply, so we probably would
> require that a
> > client specifically asks for them:
> >
> > Propfind request:
> >
> > <?xml version="1.0" encoding="utf-8" ?>
> > <D:propfind xmlns:D="DAV:"
> >   xmlns:Z="http://www.w3.com/standards/z39.50"
> >    xmlns:x="http://webdav.org/property-attribute">
> >   <D:prop x:include-descriptions="true">
> >     <D:getcontenttype/>
> >     <Z:released/>
> >   </D:prop>
> > </D:propfind>
> >
> >
> > Propfind response:
> >
> > <?xml version="1.0" encoding="utf-8" ?>
> > <D:multistatus xmlns:D="DAV:"
> >    xmlns:Z="http://www.w3.com/standards/z39.50"
> >    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >    xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >    xmlns:x="http://webdav.org/property-attribute">
> >   <D:response>
> >     <D:href>http://www.foo.com/bar.html</D:href>
> >     <D:propstat>
> >       <D:prop>
> >         <D:getcontenttype>text/html</D:getcontenttype>
> >         <Z:released xsi:type="xs:boolean" x:hidden="true"
> > x:editable="false"><x:description
> > xml:lang="en">released?</x:description>1</Z:released>
> >       </D:prop>
> >       <D:status>HTTP/1.1 200 OK</D:status>
> >     </D:propstat>
> >   </D:response>
> > </D:multistatus>
> >
> >
> > Feedback appreciated.
> >
> > Julian
> >



From w3c-dist-auth-request@w3.org  Sun Apr  7 22:03:27 2002
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04382
	for <webdav-archive@odin.ietf.org>; Sun, 7 Apr 2002 22:03:27 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA17329;
	Sun, 7 Apr 2002 22:03:15 -0400
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id VAA25720;
	Sun, 7 Apr 2002 21:59:52 -0400 (EDT)
Resent-Date: Sun, 7 Apr 2002 21:59:52 -0400 (EDT)
Resent-Message-Id: <200204080159.VAA25720@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA25696
	for <w3c-dist-auth@www19.w3.org>; Sun, 7 Apr 2002 21:59:42 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA16860
	for <w3c-dist-auth@w3.org>; Sun, 7 Apr 2002 21:59:43 -0400
Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Sun, 07 Apr 2002 21:56:13 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19)
	id <FJQG9990>; Sun, 7 Apr 2002 21:59:10 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10669099B@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: DAV <w3c-dist-auth@w3.org>
Date: Sun, 7 Apr 2002 21:59:05 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV property schema lookup
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6118
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>

   From: Gary Cowan [mailto:Gary.Cowan@Tally.Hummingbird.com]

   This situation illustrates a fundamental weakness with WebDAV in
   respect to enterprise document management systems. The WebDAV
   philosophy assumes that the client is controlling the properties of
   a resource/document and the server mearly acts as a store for the
   property information.

That is incorrect.  WebDAV explicitly supports both "dead" (client-defined)
and "live" (server-defined) properties.

   Wheras a DM server maintains extensive metadata for a given
   resource especially when vertical market applications have been
   built on top of the DM system.

Yes, WebDAV was designed with this in mind.

   WebDAV does not provide a methodology by which this metadata can be
   exposed.

Perhaps you could explain what you have in mind as "a methodology
by which this metadata can be exposed"?

   As such DM systems must still construct proprietary client
   applications causing users to perform authoring in the authoring
   tool while performing DM specific actions in the DM client.

As is the case for versioning systems.  To deal with this problem, we
defined an interoperable set of live properties (and a few new
methods) to provide authoring tools with a mechanism for interacting
with a wide range of versioning systems.  The WebDAV protocol proved
to be very amenable to this kind of extension.

   At this point in time it still makes more sense for DM systems to
   construct tight integration mechanisms within the context of the
   authoring application. This gives the DM system the ability expose
   its own metadata to the user during document creation/editing.

Yes, until you agreed on an interoperable set of DM live properties,
each client will need a custom integration with each server.

   WebDAV is a very attractive protocol but this one limitation is
inhibiting
   its extensive use within the enterprise DM community. 

The only group that could define an interoperable set of properties
for enterprise DM is the enterprise DM community itself.  I encourage
you to do so.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Mon Apr  8 03:51:29 2002
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17254
	for <webdav-archive@odin.ietf.org>; Mon, 8 Apr 2002 03:51:29 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA23171;
	Mon, 8 Apr 2002 03:51:09 -0400
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id DAA17240;
	Mon, 8 Apr 2002 03:47:41 -0400 (EDT)
Resent-Date: Mon, 8 Apr 2002 03:47:41 -0400 (EDT)
Resent-Message-Id: <200204080747.DAA17240@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA17217
	for <w3c-dist-auth@www19.w3.org>; Mon, 8 Apr 2002 03:47:32 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA22783
	for <w3c-dist-auth@w3.org>; Mon, 8 Apr 2002 03:47:32 -0400
Received: (qmail 24666 invoked by uid 0); 8 Apr 2002 07:47:05 -0000
Received: from p3ee24706.dip.t-dialin.net (HELO lisa) (62.226.71.6)
  by mail.gmx.net (mp010-rz3) with SMTP; 8 Apr 2002 07:47:05 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Dylan Barrell" <dbarrell@opentext.com>,
        "Gary Cowan" <Gary.Cowan@Tally.Hummingbird.com>,
        "DAV" <w3c-dist-auth@w3.org>, "'Clemm, Geoff'" <gclemm@rational.com>
Date: Mon, 8 Apr 2002 09:46:51 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCOEKGEFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <NEBBIBDBCLDPAGPIKGMCEEAAEPAA.dbarrell@opentext.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Subject: RE: WebDAV property schema lookup
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6119
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.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 Dylan Barrell
> Sent: Sunday, April 07, 2002 11:28 PM
> To: Gary Cowan; DAV; 'Clemm, Geoff'
> Subject: RE: WebDAV property schema lookup
>
>
> Absolutely agree - I brought this issue up a couple of months ago.
>
> >From my perspective we need two things
>
> 1) We need the ability for the server to enforce schema on documents when
> they are created (we talked about a multi-put a couple of months back).

Two thoughts:

a) MS Sharepoint works around this by enforcing schema compliance not on
creation, but upon CHECKIN. This may or may not be sufficient (checking in
pops up a dialogue where the user must fill all required fields).

b) Instead of inventing MULTIPUT, we may be able to use the HTTP Extension
Framework (RFC2774), defining mandatory headers for M-PUT (marshalling would
be a bit tricky, though).

> Schema descovery is also an issue as the client needs to know what the
> mandatory properties are before it can issue the multi-put.

Sure. But we won't get that unless a group of peope sits down and develops a
proposal.

> 2) We need to have a way for the server to tell the client where
> to redirect
> the user if the user want to manipulate the object in a way that is out of
> scope for WebDAV - e.g. initiate a chat with the author of the
> document. In
> fact, the server should be able to tell the client what URL to go to for
> these actions as well as what client side application to spawn
> should it be
> available.

In the general case, wouldn't that be just a link to a (dynamically
generated) HTML document (may be a new property or another use for
DAV:source :-).



From w3c-dist-auth-request@w3.org  Mon Apr  8 04:18:08 2002
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17584
	for <webdav-archive@odin.ietf.org>; Mon, 8 Apr 2002 04:18:08 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA26854;
	Mon, 8 Apr 2002 04:17:23 -0400
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id EAA20345;
	Mon, 8 Apr 2002 04:13:58 -0400 (EDT)
Resent-Date: Mon, 8 Apr 2002 04:13:58 -0400 (EDT)
Resent-Message-Id: <200204080813.EAA20345@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA20323
	for <w3c-dist-auth@www19.w3.org>; Mon, 8 Apr 2002 04:13:44 -0400 (EDT)
Received: from bslnt.india.birlasoft.com ([203.190.136.162])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA26086
	for <w3c-dist-auth@w3.org>; Mon, 8 Apr 2002 04:13:42 -0400
Received: by bslnt.india.birlasoft.com with Internet Mail Service (5.5.2650.21)
	id <2CT7LFD7>; Mon, 8 Apr 2002 13:54:20 +0530
Message-ID: <323429523770D411BF8F009027E78DFB01BE5DB5@bslnt.india.birlasoft.com>
From: Nupur Bhasin <nupur.bhasin@india.birlasoft.com>
To: Julian Reschke <julian.reschke@gmx.de>,
        Dylan Barrell
	 <dbarrell@opentext.com>,
        Gary Cowan <Gary.Cowan@Tally.Hummingbird.com>,
        DAV <w3c-dist-auth@w3.org>, "'Clemm, Geoff'" <gclemm@rational.com>
Date: Mon, 8 Apr 2002 13:54:14 +0530 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV property schema lookup
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6120
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>

How do we unsubscribe from this list.Any clues please?

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Monday, April 08, 2002 1:17 PM
To: Dylan Barrell; Gary Cowan; DAV; 'Clemm, Geoff'
Subject: RE: WebDAV property schema lookup


> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dylan Barrell
> Sent: Sunday, April 07, 2002 11:28 PM
> To: Gary Cowan; DAV; 'Clemm, Geoff'
> Subject: RE: WebDAV property schema lookup
>
>
> Absolutely agree - I brought this issue up a couple of months ago.
>
> >From my perspective we need two things
>
> 1) We need the ability for the server to enforce schema on documents when
> they are created (we talked about a multi-put a couple of months back).

Two thoughts:

a) MS Sharepoint works around this by enforcing schema compliance not on
creation, but upon CHECKIN. This may or may not be sufficient (checking in
pops up a dialogue where the user must fill all required fields).

b) Instead of inventing MULTIPUT, we may be able to use the HTTP Extension
Framework (RFC2774), defining mandatory headers for M-PUT (marshalling would
be a bit tricky, though).

> Schema descovery is also an issue as the client needs to know what the
> mandatory properties are before it can issue the multi-put.

Sure. But we won't get that unless a group of peope sits down and develops a
proposal.

> 2) We need to have a way for the server to tell the client where
> to redirect
> the user if the user want to manipulate the object in a way that is out of
> scope for WebDAV - e.g. initiate a chat with the author of the
> document. In
> fact, the server should be able to tell the client what URL to go to for
> these actions as well as what client side application to spawn
> should it be
> available.

In the general case, wouldn't that be just a link to a (dynamically
generated) HTML document (may be a new property or another use for
DAV:source :-).



From w3c-dist-auth-request@w3.org  Mon Apr  8 12:55:03 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29756
	for <webdav-archive@odin.ietf.org>; Mon, 8 Apr 2002 12:55:02 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id D99C522D64; Mon,  8 Apr 2002 11:55:03 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA13257;
	Mon, 8 Apr 2002 12:54:05 -0400 (EDT)
Resent-Date: Mon, 8 Apr 2002 12:54:05 -0400 (EDT)
Resent-Message-Id: <200204081654.MAA13257@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA13194
	for <w3c-dist-auth@www19.w3.org>; Mon, 8 Apr 2002 12:53:57 -0400 (EDT)
Received: from exchimc.pcdocs.com ([208.255.196.152])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA12461
	for <w3c-dist-auth@w3.org>; Mon, 8 Apr 2002 12:53:57 -0400
Received: by EXCHANGE_IMC with Internet Mail Service (5.5.2650.21)
	id <HWXJCLFP>; Mon, 8 Apr 2002 12:53:31 -0400
Message-ID: <39FB3B2B1509CE43A251C50896C9BA95089376@tallyx1>
From: Gary Cowan <Gary.Cowan@Tally.Hummingbird.com>
To: "'Clemm, Geoff'" <gclemm@rational.com>, DAV <w3c-dist-auth@w3.org>
Date: Mon, 8 Apr 2002 12:53:25 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV property schema lookup
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6121
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>

Server defined(live) properties are supported in that they can be queried,
but there is no methodology that allows users to manipulate these properties
from disparate WebDAV clients. 

One of the characteristics of most if not all enterprise DM systems is that
they are highly customizable. Thus the metadata properties for documents
managed by the system can and quite often due change from site to site, and
obviously change from industry to industry. For instance a law firm requires
different metadata properties than a manufacturing firm. 

I suppose the holy grail would be to have WebDAV clients construct a dynamic
properties dialog. This may not be practical in which case a redirection
mechanism or a UI container such as a browser window could possibly be used.
I am just thinking off the top of my head right now. I understand this is
not an easy issue to resolve. If it can be resolved then WebDAV could
potentially completely replace hardwired integration with desktop
applications.
   
-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@rational.com]
Sent: Sunday, April 07, 2002 9:59 PM
To: DAV
Subject: RE: WebDAV property schema lookup


   From: Gary Cowan [mailto:Gary.Cowan@Tally.Hummingbird.com]

   This situation illustrates a fundamental weakness with WebDAV in
   respect to enterprise document management systems. The WebDAV
   philosophy assumes that the client is controlling the properties of
   a resource/document and the server mearly acts as a store for the
   property information.

That is incorrect.  WebDAV explicitly supports both "dead" (client-defined)
and "live" (server-defined) properties.

   Wheras a DM server maintains extensive metadata for a given
   resource especially when vertical market applications have been
   built on top of the DM system.

Yes, WebDAV was designed with this in mind.

   WebDAV does not provide a methodology by which this metadata can be
   exposed.

Perhaps you could explain what you have in mind as "a methodology
by which this metadata can be exposed"?

   As such DM systems must still construct proprietary client
   applications causing users to perform authoring in the authoring
   tool while performing DM specific actions in the DM client.

As is the case for versioning systems.  To deal with this problem, we
defined an interoperable set of live properties (and a few new
methods) to provide authoring tools with a mechanism for interacting
with a wide range of versioning systems.  The WebDAV protocol proved
to be very amenable to this kind of extension.

   At this point in time it still makes more sense for DM systems to
   construct tight integration mechanisms within the context of the
   authoring application. This gives the DM system the ability expose
   its own metadata to the user during document creation/editing.

Yes, until you agreed on an interoperable set of DM live properties,
each client will need a custom integration with each server.

   WebDAV is a very attractive protocol but this one limitation is
inhibiting
   its extensive use within the enterprise DM community. 

The only group that could define an interoperable set of properties
for enterprise DM is the enterprise DM community itself.  I encourage
you to do so.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Mon Apr  8 13:14:51 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00191
	for <webdav-archive@odin.ietf.org>; Mon, 8 Apr 2002 13:14:50 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 97FD522E9B; Mon,  8 Apr 2002 12:14:50 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA15839;
	Mon, 8 Apr 2002 13:14:43 -0400 (EDT)
Resent-Date: Mon, 8 Apr 2002 13:14:43 -0400 (EDT)
Resent-Message-Id: <200204081714.NAA15839@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA15814
	for <w3c-dist-auth@www19.w3.org>; Mon, 8 Apr 2002 13:14:38 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA17029
	for <w3c-dist-auth@w3.org>; Mon, 8 Apr 2002 13:14:36 -0400
Received: (qmail 26508 invoked by uid 0); 8 Apr 2002 17:14:04 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp001-rz3) with SMTP; 8 Apr 2002 17:14:04 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Gary Cowan" <Gary.Cowan@Tally.Hummingbird.com>,
        "DAV" <w3c-dist-auth@w3.org>
Date: Mon, 8 Apr 2002 19:14:03 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCAELIEFAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <39FB3B2B1509CE43A251C50896C9BA95089376@tallyx1>
Subject: RE: WebDAV property schema lookup
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6122
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.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 Gary Cowan
> Sent: Monday, April 08, 2002 6:53 PM
> To: 'Clemm, Geoff'; DAV
> Subject: RE: WebDAV property schema lookup
>
>
> Server defined(live) properties are supported in that they can be queried,
> but there is no methodology that allows users to manipulate these
> properties
> >from disparate WebDAV clients.

Well, there is. What you don't have is an interoperable  way to *discover*
them (and their datatypes, descriptions).

> One of the characteristics of most if not all enterprise DM
> systems is that
> they are highly customizable. Thus the metadata properties for documents
> managed by the system can and quite often due change from site to
> site, and
> obviously change from industry to industry. For instance a law
> firm requires
> different metadata properties than a manufacturing firm.

Thus one needs a generic schema-based protocol that allows discovery of
mandatory properties and their types. This is what Microsoft Sharepoint
already implements.

> I suppose the holy grail would be to have WebDAV clients
> construct a dynamic
> properties dialog. This may not be practical in which case a redirection
> mechanism or a UI container such as a browser window could
> possibly be used.
> I am just thinking off the top of my head right now. I understand this is
> not an easy issue to resolve. If it can be resolved then WebDAV could
> potentially completely replace hardwired integration with desktop
> applications.

It certainly can be solved (without changing WebDAV), but it requires a lot
of work.


> -----Original Message-----
> From: Clemm, Geoff [mailto:gclemm@rational.com]
> Sent: Sunday, April 07, 2002 9:59 PM
> To: DAV
> Subject: RE: WebDAV property schema lookup
>
>
>    From: Gary Cowan [mailto:Gary.Cowan@Tally.Hummingbird.com]
>
>    This situation illustrates a fundamental weakness with WebDAV in
>    respect to enterprise document management systems. The WebDAV
>    philosophy assumes that the client is controlling the properties of
>    a resource/document and the server mearly acts as a store for the
>    property information.
>
> That is incorrect.  WebDAV explicitly supports both "dead"
> (client-defined)
> and "live" (server-defined) properties.
>
>    Wheras a DM server maintains extensive metadata for a given
>    resource especially when vertical market applications have been
>    built on top of the DM system.
>
> Yes, WebDAV was designed with this in mind.
>
>    WebDAV does not provide a methodology by which this metadata can be
>    exposed.
>
> Perhaps you could explain what you have in mind as "a methodology
> by which this metadata can be exposed"?
>
>    As such DM systems must still construct proprietary client
>    applications causing users to perform authoring in the authoring
>    tool while performing DM specific actions in the DM client.
>
> As is the case for versioning systems.  To deal with this problem, we
> defined an interoperable set of live properties (and a few new
> methods) to provide authoring tools with a mechanism for interacting
> with a wide range of versioning systems.  The WebDAV protocol proved
> to be very amenable to this kind of extension.
>
>    At this point in time it still makes more sense for DM systems to
>    construct tight integration mechanisms within the context of the
>    authoring application. This gives the DM system the ability expose
>    its own metadata to the user during document creation/editing.
>
> Yes, until you agreed on an interoperable set of DM live properties,
> each client will need a custom integration with each server.
>
>    WebDAV is a very attractive protocol but this one limitation is
> inhibiting
>    its extensive use within the enterprise DM community.
>
> The only group that could define an interoperable set of properties
> for enterprise DM is the enterprise DM community itself.  I encourage
> you to do so.
>
> Cheers,
> Geoff
>



From w3c-dist-auth-request@w3.org  Mon Apr  8 13:25:20 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00452
	for <webdav-archive@odin.ietf.org>; Mon, 8 Apr 2002 13:25:19 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 7912122EAA; Mon,  8 Apr 2002 12:25:16 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA16956;
	Mon, 8 Apr 2002 13:25:10 -0400 (EDT)
Resent-Date: Mon, 8 Apr 2002 13:25:10 -0400 (EDT)
Resent-Message-Id: <200204081725.NAA16956@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA16935
	for <w3c-dist-auth@www19.w3.org>; Mon, 8 Apr 2002 13:25:04 -0400 (EDT)
Received: from exchimc.pcdocs.com ([208.255.196.152])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA18744
	for <w3c-dist-auth@w3.org>; Mon, 8 Apr 2002 13:25:02 -0400
Received: by EXCHANGE_IMC with Internet Mail Service (5.5.2650.21)
	id <HWXJCLHW>; Mon, 8 Apr 2002 13:24:37 -0400
Message-ID: <39FB3B2B1509CE43A251C50896C9BA95089377@tallyx1>
From: Gary Cowan <Gary.Cowan@Tally.Hummingbird.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>,
        Gary Cowan <Gary.Cowan@Tally.Hummingbird.com>,
        DAV <w3c-dist-auth@w3.org>
Date: Mon, 8 Apr 2002 13:24:30 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: WebDAV property schema lookup
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6123
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>

Fair enough

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Monday, April 08, 2002 1:14 PM
To: Gary Cowan; DAV
Subject: RE: WebDAV property schema lookup


> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Gary Cowan
> Sent: Monday, April 08, 2002 6:53 PM
> To: 'Clemm, Geoff'; DAV
> Subject: RE: WebDAV property schema lookup
>
>
> Server defined(live) properties are supported in that they can be queried,
> but there is no methodology that allows users to manipulate these
> properties
> >from disparate WebDAV clients.

Well, there is. What you don't have is an interoperable  way to *discover*
them (and their datatypes, descriptions).

> One of the characteristics of most if not all enterprise DM
> systems is that
> they are highly customizable. Thus the metadata properties for documents
> managed by the system can and quite often due change from site to
> site, and
> obviously change from industry to industry. For instance a law
> firm requires
> different metadata properties than a manufacturing firm.

Thus one needs a generic schema-based protocol that allows discovery of
mandatory properties and their types. This is what Microsoft Sharepoint
already implements.

> I suppose the holy grail would be to have WebDAV clients
> construct a dynamic
> properties dialog. This may not be practical in which case a redirection
> mechanism or a UI container such as a browser window could
> possibly be used.
> I am just thinking off the top of my head right now. I understand this is
> not an easy issue to resolve. If it can be resolved then WebDAV could
> potentially completely replace hardwired integration with desktop
> applications.

It certainly can be solved (without changing WebDAV), but it requires a lot
of work.


> -----Original Message-----
> From: Clemm, Geoff [mailto:gclemm@rational.com]
> Sent: Sunday, April 07, 2002 9:59 PM
> To: DAV
> Subject: RE: WebDAV property schema lookup
>
>
>    From: Gary Cowan [mailto:Gary.Cowan@Tally.Hummingbird.com]
>
>    This situation illustrates a fundamental weakness with WebDAV in
>    respect to enterprise document management systems. The WebDAV
>    philosophy assumes that the client is controlling the properties of
>    a resource/document and the server mearly acts as a store for the
>    property information.
>
> That is incorrect.  WebDAV explicitly supports both "dead"
> (client-defined)
> and "live" (server-defined) properties.
>
>    Wheras a DM server maintains extensive metadata for a given
>    resource especially when vertical market applications have been
>    built on top of the DM system.
>
> Yes, WebDAV was designed with this in mind.
>
>    WebDAV does not provide a methodology by which this metadata can be
>    exposed.
>
> Perhaps you could explain what you have in mind as "a methodology
> by which this metadata can be exposed"?
>
>    As such DM systems must still construct proprietary client
>    applications causing users to perform authoring in the authoring
>    tool while performing DM specific actions in the DM client.
>
> As is the case for versioning systems.  To deal with this problem, we
> defined an interoperable set of live properties (and a few new
> methods) to provide authoring tools with a mechanism for interacting
> with a wide range of versioning systems.  The WebDAV protocol proved
> to be very amenable to this kind of extension.
>
>    At this point in time it still makes more sense for DM systems to
>    construct tight integration mechanisms within the context of the
>    authoring application. This gives the DM system the ability expose
>    its own metadata to the user during document creation/editing.
>
> Yes, until you agreed on an interoperable set of DM live properties,
> each client will need a custom integration with each server.
>
>    WebDAV is a very attractive protocol but this one limitation is
> inhibiting
>    its extensive use within the enterprise DM community.
>
> The only group that could define an interoperable set of properties
> for enterprise DM is the enterprise DM community itself.  I encourage
> you to do so.
>
> Cheers,
> Geoff
>



From w3c-dist-auth-request@w3.org  Fri Apr 12 03:41:26 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16773
	for <webdav-archive@odin.ietf.org>; Fri, 12 Apr 2002 03:41:26 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id EF88422D88; Fri, 12 Apr 2002 02:41:21 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id DAA28992;
	Fri, 12 Apr 2002 03:40:38 -0400 (EDT)
Resent-Date: Fri, 12 Apr 2002 03:40:38 -0400 (EDT)
Resent-Message-Id: <200204120740.DAA28992@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA28969
	for <w3c-dist-auth@www19.w3.org>; Fri, 12 Apr 2002 03:40:31 -0400 (EDT)
Received: from hvwww10.hotvoice.com ([209.191.29.26])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA08986
	for <w3c-dist-auth@w3.org>; Fri, 12 Apr 2002 03:40:30 -0400
Message-ID: <5856205.1018608021640.JavaMail.admin@hvwww10>
Date: Fri, 12 Apr 2002 03:40:21 -0700 (PDT)
From: ganesh krishnamurthi <ganeshu@Hotvoice.com>
To: w3c-dist-auth@w3.org
Mime-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_6009_1466745.1018608021625"
Subject: Clients for Class 1 servers
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6124
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>

------=_Part_6009_1466745.1018608021625
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi
I have a question on Dreamweavers support for class 1 server.
Dreamweaver always does a lock null resource and then PUTs a file.
But the point is, class 1 servers know nothing about locks.
So, does this mean that dreamweaver can work properly ONLY with 
class 2 servers?

Are there any clients specific to class 1 Webdav servers?

Thanks in advance

Regards
Ganesh




--------------------------------------------------------------------------
Global Internet phone calls, voicemail, fax, e-mail and instant messaging.
Sign-up today at http://www.hotvoice.com
------=_Part_6009_1466745.1018608021625--



From w3c-dist-auth-request@w3.org  Mon Apr 15 18:02:06 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07648
	for <webdav-archive@odin.ietf.org>; Mon, 15 Apr 2002 18:02:06 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id B8B4D22F24; Mon, 15 Apr 2002 17:02:06 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id SAA21971;
	Mon, 15 Apr 2002 18:01:29 -0400 (EDT)
Resent-Date: Mon, 15 Apr 2002 18:01:29 -0400 (EDT)
Resent-Message-Id: <200204152201.SAA21971@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA21939
	for <w3c-dist-auth@www19.w3.org>; Mon, 15 Apr 2002 18:01:22 -0400 (EDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA16384
	for <w3c-dist-auth@w3.org>; Mon, 15 Apr 2002 18:01:22 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3FM0oms333764;
	Mon, 15 Apr 2002 18:00:50 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77])
	by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3FM0lh58158;
	Mon, 15 Apr 2002 18:00:47 -0400
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "WebDAV" <w3c-dist-auth@w3.org>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFAA34094A.3AE6AE43-ON85256B9C.0078A877@pok.ibm.com>
From: "Jason Crawford" <ccjason@us.ibm.com>
Date: Mon, 15 Apr 2002 17:59:33 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at
 04/15/2002 06:00:46 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: Re: need clarification about COPY to locked resource response code
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6125
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0098.html

I don't think the above comment was resolved.

Do we want to make a change to the spec?

Are we clear on what URL we need to point reference in the multi-status
response for various lock problems?

J.

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




From w3c-dist-auth-request@w3.org  Tue Apr 16 03:09:33 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25366
	for <webdav-archive@odin.ietf.org>; Tue, 16 Apr 2002 03:09:33 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 7737322F47; Tue, 16 Apr 2002 02:09:35 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id CAA17870;
	Tue, 16 Apr 2002 02:56:45 -0400 (EDT)
Resent-Date: Tue, 16 Apr 2002 02:56:45 -0400 (EDT)
Resent-Message-Id: <200204160656.CAA17870@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA17824
	for <w3c-dist-auth@www19.w3.org>; Tue, 16 Apr 2002 02:56:23 -0400 (EDT)
Received: from linux3.localdomain (pD955B8D4.dip.t-dialin.net [217.85.184.212])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA27646
	for <w3c-dist-auth@w3.org>; Tue, 16 Apr 2002 02:56:22 -0400
Received: from K-20 (k-20.localdomain [192.168.0.134])
	by linux3.localdomain (8.11.6/8.11.6) with ESMTP id g3G6toj32263
	for <w3c-dist-auth@w3.org>; Tue, 16 Apr 2002 08:55:50 +0200
Message-Id: <200204160655.g3G6toj32263@linux3.localdomain>
From: "Michael Michalowski" <michael.michalowski@interred.de>
To: "w3c-dist-auth@w3.org" <w3c-dist-auth@w3.org>
Date: Tue, 16 Apr 2002 08:57:35 +0200
Reply-To: "Michael Michalowski" <michael.michalowski@interred.de>
Priority: Normal
X-Mailer: PMMail 2000 Professional (2.20.2475) For Windows 2000 (5.0.2195)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Open a WebDav Document with IE by URL
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6126
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.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 want to open a link to a webdav document (for example
http://www.example.com/this.doc). But if this URL is opened by
Internet Explorer and then MS Word launched, the document opens
a local copy and so no webdav support is given.
If I open this document directly with MS Word by URL it is
opened as a webdav document and it can directly be saved back on the server.

My question:
How can I tell the Internet Explorer that a link to a document
points to a webdav source and that the full doucument path must be
passed to MS Word?

The only method of resolution I found is an JScript workaround:
http://support.microsoft.com/default.aspx?scid=kb;DE;q178222
But that's not what I might prefer. Isn't there another
solution?

(I'm not sure whether this is the right mailinglist for my topic)

regards,
Michael






From w3c-dist-auth-request@w3.org  Tue Apr 16 08:18:25 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00525
	for <webdav-archive@odin.ietf.org>; Tue, 16 Apr 2002 08:18:25 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 9CDB922E91; Tue, 16 Apr 2002 07:18:27 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id IAA00757;
	Tue, 16 Apr 2002 08:18:19 -0400 (EDT)
Resent-Date: Tue, 16 Apr 2002 08:18:19 -0400 (EDT)
Resent-Message-Id: <200204161218.IAA00757@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA00714
	for <w3c-dist-auth@www19.w3.org>; Tue, 16 Apr 2002 08:18:12 -0400 (EDT)
Received: from bhh5.na.pg.com (bhh5.na.pg.com [192.44.184.129])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA06986;
	Tue, 16 Apr 2002 08:18:12 -0400
From: hanna.ji@pg.com
X-ExtMailInfo:  <hanna.ji@pg.com> bdc-notes041.na.pg.com [155.125.116.41]
Received: from bdc-notes041.na.pg.com (bdc-notes041.na.pg.com [155.125.116.41])
    by bhh5.na.pg.com (8.8.8/8.11.1/v2r6) with ESMTP id g3GCI8H00715; Tue, 16 Apr 2002 08:18:08 -0400 (EDT)
To: "Michael Michalowski" <michael.michalowski@interred.de>
Cc: w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <OF4A0B2C40.A5FA1245-ON85256B9D.004231CF@na.pg.com>
Date: Tue, 16 Apr 2002 08:16:43 -0400
X-MIMETrack: Serialize by Router on BDC-NOTES041.NA.PG.COM/PGI(Release 5.0.3 (Intl)|21
 March 2000) at 04/16/2002 08:18:08 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: Re: Open a WebDav Document with IE by URL
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6127
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


Michael,

This is a problem with the Microsoft implementation  of Office and WebDAV.  Many
months ago I had an open problem ticket with Microsoft about this; however,
based on the discussions with Microsoft there are no clean solutions.   The
script you cite is one option, another option from Microsoft is what they term a
plugable protocol (which is very similar to the script solution) -- either way
the solution is to launch the application and pass the URL as a parameter.

Interestingly, in one of the earlier releases of Office  2000 (before SP1) this
functionality worked.  That is, if a link pointed to a file that had WebDAV
support it would open in edit mode.  Microsoft removed this functionality
because of errors generated when opening files that were not on WebDAV (or
FrontPage/Office extensions) supported servers.

My suggestion is to continue to push Microsoft to fix this problem at the
application level.   By the way, Office XP does not fix this problem, either.

Regards,

Jim


                                                                
 Internet Mail Message                                          
 Received from host:                                            
                                                                


                                                                                                
                  w3c-dist-auth@w3.org                                                          
                                  Sent                To:  "w3c-dist-auth@w3.org"               
                                   by:        <w3c-dist-auth@w3.org>                            
          w3c-dist-auth-request@w3.org        cc:     (bcc: Jim Hanna-JI/PGI)                   
                                              Subject:     Open a WebDav Document with IE by    
                   04/16/2002 02:56 AM        URL                                               
            Please respond to "Michael                                                          
                          Michalowski"                                                          
                                                                                                
                                                                                                




Hi!

I want to open a link to a webdav document (for example
http://www.example.com/this.doc). But if this URL is opened by
Internet Explorer and then MS Word launched, the document opens
a local copy and so no webdav support is given.
If I open this document directly with MS Word by URL it is
opened as a webdav document and it can directly be saved back on the server.

My question:
How can I tell the Internet Explorer that a link to a document
points to a webdav source and that the full doucument path must be
passed to MS Word?

The only method of resolution I found is an JScript workaround:
http://support.microsoft.com/default.aspx?scid=kb;DE;q178222
But that's not what I might prefer. Isn't there another
solution?

(I'm not sure whether this is the right mailinglist for my topic)

regards,
Michael









From w3c-dist-auth-request@w3.org  Wed Apr 17 15:06:55 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02240
	for <webdav-archive@lists.ietf.org>; Wed, 17 Apr 2002 15:06:54 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 728E523043; Wed, 17 Apr 2002 14:06:57 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA07820;
	Wed, 17 Apr 2002 15:06:04 -0400 (EDT)
Resent-Date: Wed, 17 Apr 2002 15:06:04 -0400 (EDT)
Resent-Message-Id: <200204171906.PAA07820@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA07797
	for <w3c-dist-auth@www19.w3.org>; Wed, 17 Apr 2002 15:05:57 -0400 (EDT)
Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA15328
	for <w3c-dist-auth@w3.org>; Wed, 17 Apr 2002 15:05:57 -0400
Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177])
          by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP
	  id MAA29274 for <w3c-dist-auth@w3.org>; Wed, 17 Apr 2002 12:05:45 -0700 (PDT)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "WebDAV" <w3c-dist-auth@w3.org>
Date: Wed, 17 Apr 2002 12:05:36 -0700
Message-ID: <AMEPKEBLDJJCCDEJHAMIKEABEKAA.ejw@cse.ucsc.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000D_01C1E608.2F02E410"
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
Subject: FW: Web Folders Simple Authentication
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6128
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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_000D_01C1E608.2F02E410
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Accidentally caught by the spam filter.

- Jim
-----Original Message-----
From: Kamran Kashanian [mailto:kamrankash@mindspring.com]
Sent: Tuesday, April 16, 2002 9:20 PM
To: w3c-dist-auth@w3.org
Subject: [Moderator Action] Web Folders Simple Authentication


I am implementing a WebDAV server and trying to get it to work with
Microsoft Web Folders with simple authentication.

My question is:

In order to use simple authentication, I issue an http challenge from my
server by using the 401 error response and the www-Authenticate header in
the http response.

Web Folders (explorer) correctly prompts the user to login and sends a
base64 Authentication string with the next request.

Is Web Folders supposed to send the same Authentication string header with
all subsequent requests for resources? It looks like it does not do this. It
only sends the authentication header once. My server looks for the
authentication header to determine if the user has already been
authenticated. If the authentication header is missing, the server issues
the 401 error again forcing the user to login again.

I tested my server with DAV Explorer, and it sends the authentication string
with all requests after the user has logged in.

Is this behavior a bug in Web folders.

Regards

Kamran


------=_NextPart_000_000D_01C1E608.2F02E410
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3207.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D891250419-17042002>Accidentally caught by the spam=20
filter.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D891250419-17042002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D891250419-17042002>-=20
Jim</SPAN></FONT></DIV>
<DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> Kamran Kashanian=20
[mailto:kamrankash@mindspring.com]<BR><B>Sent:</B> Tuesday, April 16, =
2002 9:20=20
PM<BR><B>To:</B> w3c-dist-auth@w3.org<BR><B>Subject:</B> [Moderator =
Action] Web=20
Folders Simple Authentication<BR><BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>I am implementing a WebDAV server and =
trying to get=20
it to work with Microsoft Web Folders with&nbsp;simple authentication.=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>My question is:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In order to use simple authentication, =
I issue an=20
http&nbsp;challenge from my server by using the 401 error response and =
the=20
www-Authenticate header in the http response.&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Web Folders (explorer) correctly =
prompts the user=20
to login and sends a base64&nbsp;Authentication string with the next =
request.=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Is Web Folders supposed to send the =
same=20
Authentication string header with all subsequent requests for resources? =

</FONT><FONT face=3DArial size=3D2>It looks like it does not do this. It =
only sends=20
the authentication header once. My server looks for the authentication =
header to=20
determine&nbsp;if the user has already been authenticated. If the =
authentication=20
header is missing, the server issues the 401 error again forcing the =
user to=20
login again.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>I tested my server with DAV Explorer, and it sends the =
authentication=20
string with all requests after the user has logged in.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Is this behavior a bug in Web folders.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards</DIV>
<DIV>&nbsp;</DIV>
<DIV>Kamran</DIV>
<DIV>&nbsp;</DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_000D_01C1E608.2F02E410--



From w3c-dist-auth-request@w3.org  Thu Apr 18 11:57:51 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11973
	for <webdav-archive@lists.ietf.org>; Thu, 18 Apr 2002 11:57:51 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id CE26A230CE; Thu, 18 Apr 2002 10:55:53 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA29953;
	Thu, 18 Apr 2002 11:55:27 -0400 (EDT)
Resent-Date: Thu, 18 Apr 2002 11:55:27 -0400 (EDT)
Resent-Message-Id: <200204181555.LAA29953@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA29879
	for <w3c-dist-auth@www19.w3.org>; Thu, 18 Apr 2002 11:55:19 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA13337
	for <w3c-dist-auth@w3.org>; Thu, 18 Apr 2002 11:55:18 -0400
Received: from lisa [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3.org>; Thu, 18 Apr 2002 17:55:16 +0200
From: "Julian Reschke" <julian.reschke@greenbytes.de>
To: "Ben Evans" <ben.evans@parasolsolutions.com>, <w3c-dist-auth@w3.org>
Date: Thu, 18 Apr 2002 17:55:14 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCOENPEGAA.julian.reschke@greenbytes.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-reply-to: <20020418154110.GA5780@parasolsolutions.com>
Importance: Normal
X-MDRemoteIP: 192.168.1.23
X-Return-Path: julian.reschke@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3.org
Subject: RE: Typo in RFC 2518?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6129
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.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 first one is a typo  (which I think is already on the issues list [1]),
the second one is irrelevant because this section will be removed anyway.

[1] <http://www.webdav.org/wg/rfcdev/issues.htm>

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Ben Evans
> Sent: Thursday, April 18, 2002 5:41 PM
> To: Deltav WG
> Cc: w3c-dist-auth@w3.org
> Subject: Typo in RFC 2518?
>
>
>
> Hi,
>
> I think I've found a couple of typos in RFC 2518.
>
> Specifically:
>
> Page 24, Section 8.1.1, RFC 2518:
>
> ----
>
>  >>Response
>
>    HTTP/1.1 207 Multi-Status
>    Content-Type: text/xml; charset="utf-8"
>    Content-Length: xxxx
>
>    <?xml version="1.0" encoding="utf-8" ?>
> 	 <D:multistatus xmlns:D="DAV:">
> 		<D:response>
> 			<D:href>http://www.foo.bar/file</D:href>
> 			<D:propstat>
> 				<D:prop
> xmlns:R="http://www.foo.bar/boxschema/">
> 					<R:bigbox>
> 						<R:BoxType>Box type
> A</R:BoxType>
> 					</R:bigbox>
> 					<R:author>
> 						<R:Name>J.J.
> Johnson</R:Name>
> 					</R:author>
> 				</D:prop>
> 				<D:status>HTTP/1.1 200 OK</D:status>
> 			</D:propstat>
> 			<D:propstat>
> 				<D:prop><R:DingALing/><R:Random/></D:prop>
> [snip]
> ----------
>
> Here, this should read:
>
>    <?xml version="1.0" encoding="utf-8" ?>
> 	 <D:multistatus xmlns:D="DAV:">
> 		<D:response xmlns:R="http://www.foo.bar/boxschema/">
> 			<D:href>http://www.foo.bar/file</D:href>
> 			<D:propstat>
> 				<D:prop>
> 					<R:bigbox>
> 						<R:BoxType>Box type
> A</R:BoxType>
> 					</R:bigbox>
> 					<R:author>
> 						<R:Name>J.J.
> Johnson</R:Name>
> 					</R:author>
> 				</D:prop>
> 				<D:status>HTTP/1.1 200 OK</D:status>
> 			</D:propstat>
> 			<D:propstat>
> 				<D:prop><R:DingALing/><R:Random/></D:prop>
> ...
> -----
>
> as otherwise, the namespace definition of R: will be out of scope by
> the time the <R:DingALing/> tag is encountered.
>
> And, on page 91:
>
> -------
> [snip]
>
> 23.4.2 Meaning of Qualified Names
>
>    [Note to the reader: This section does not appear in
>    [REC-XML-NAMES],
>    but is necessary to avoid ambiguity for WebDAV XML processors.]
>
>    WebDAV compliant XML processors MUST interpret a qualified name as
>    a
>    URI constructed by appending the LocalPart to the namespace name
>    URI.
>
>    Example
>
>    <del:glider xmlns:del="http://www.del.jensen.org/">
> <del:glidername>
> Johnny Updraft
>      </del:glidername>
> <del:glideraccidents/>
> </del:glider>
>
> In this example, the qualified element name "del:glider" is
>    interpreted as the URL "http://www.del.jensen.org/glider".
>
>    <bar:glider xmlns:del="http://www.del.jensen.org/">
> <bar:glidername>
> Johnny Updraft
>      </bar:glidername>
> <bar:glideraccidents/>
> </bar:glider>
>
> [snip]
>
> ----------------
>
> In the second example, the line:
>
> <bar:glider xmlns:del="http://www.del.jensen.org/">
>
> should read:
>
> <bar:glider xmlns:bar="http://www.del.jensen.org/">
>
> as otherwise the XML namespace bar is undefined, and a namespace
> validating parser will barf.
>
> Can someone shed some light on these. Are they typos or have I
> missed something?
>
> Ben
>
>




From w3c-dist-auth-request@w3.org  Fri Apr 19 03:41:19 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12643
	for <webdav-archive@lists.ietf.org>; Fri, 19 Apr 2002 03:41:18 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id A535022F43; Fri, 19 Apr 2002 02:41:20 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id DAA14143;
	Fri, 19 Apr 2002 03:40:35 -0400 (EDT)
Resent-Date: Fri, 19 Apr 2002 03:40:35 -0400 (EDT)
Resent-Message-Id: <200204190740.DAA14143@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA13982
	for <w3c-dist-auth@www19.w3.org>; Fri, 19 Apr 2002 03:40:23 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA27178
	for <w3c-dist-auth@w3.org>; Fri, 19 Apr 2002 03:30:44 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3.org>; Fri, 19 Apr 2002 09:29:40 +0200
Date: Fri, 19 Apr 2002 09:29:39 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
From: Stefan Eissing <stefan.eissing@greenbytes.de>
To: "WebDAV" <w3c-dist-auth@w3.org>
Content-Transfer-Encoding: 7bit
In-Reply-To: <OFAA34094A.3AE6AE43-ON85256B9C.0078A877@pok.ibm.com>
Message-Id: <356248E2-5367-11D6-8B11-00039384827E@greenbytes.de>
X-Mailer: Apple Mail (2.481)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3.org
Subject: Re: need clarification about COPY to locked resource response code
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6130
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit

Having waited three days for someone smarter than me to
say something...

Am Montag den, 15. April 2002, um 23:59, schrieb Jason Crawford:

>
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0098.html
>
> I don't think the above comment was resolved.
>
> Do we want to make a change to the spec?

I don't feel strongly about it. If, then I would list 207 as
possible status code of COPY/MOVE (where there are completely
absent now) and explain that 423 LOCKED will only map to locked
request-uri. If any other uri (destination included) makes trouble,
clients should be able to deal with a 207.

> Are we clear on what URL we need to point reference in the multi-status
> response for various lock problems?

I don't understand that question. Can you elaborate?

//Stefan

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





From w3c-dist-auth-request@w3.org  Fri Apr 19 04:01:04 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13020
	for <webdav-archive@lists.ietf.org>; Fri, 19 Apr 2002 04:01:03 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 8FB3D22FF6; Fri, 19 Apr 2002 03:01:05 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id EAA17844;
	Fri, 19 Apr 2002 04:00:55 -0400 (EDT)
Resent-Date: Fri, 19 Apr 2002 04:00:55 -0400 (EDT)
Resent-Message-Id: <200204190800.EAA17844@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA17754
	for <w3c-dist-auth@www19.w3.org>; Fri, 19 Apr 2002 04:00:46 -0400 (EDT)
Received: from d06lmsgate-4.uk.ibm.COM (d06lmsgate-4.uk.ibm.com [195.212.29.4])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA31000;
	Fri, 19 Apr 2002 04:00:45 -0400
Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147])
	by d06lmsgate-4.uk.ibm.COM (1.0.0) with ESMTP id IAA115982;
	Fri, 19 Apr 2002 08:45:46 +0100
Received: from d06ml034.portsmouth.uk.ibm.com (d06ml034_cs0 [9.180.35.31])
	by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3J80QX158994;
	Fri, 19 Apr 2002 09:00:26 +0100
To: Deltav WG <ietf-dav-versioning@w3.org>, w3c-dist-auth@w3.org
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <OF8F015BF9.697A83B2-ON80256BA0.002B5AAE@portsmouth.uk.ibm.com>
From: "Tim Ellison" <Tim_Ellison@uk.ibm.com>
Date: Fri, 19 Apr 2002 09:00:12 +0100
X-MIMETrack: Serialize by Router on D06ML034/06/M/IBM(Release 5.0.9a |January 7, 2002) at
 19/04/2002 09:00:25
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: Re: Typo in RFC 2518?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6131
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


Ben,

These are already known issues (the first is "MISSING_NS_SPEC" and the
second is "NS_BOOBOO") in the RFC2518 issues list
(http://www.webdav.org/wg/rfcdev/issues.htm).

All RFC2518 readers should (and, I suggest, all implementers 'must') read
the list of issues and their resolutions.

Regards,
Tim


                                                                                                                                                
                      Ben Evans                                                                                                                 
                      <ben.evans@parasolsolut        To:       Deltav WG <ietf-dav-versioning@w3.org>                                           
                      ions.com>                      cc:       w3c-dist-auth@w3.org                                                             
                      Sent by:                       Subject:  Typo in RFC 2518?                                                                
                      ietf-dav-versioning-req                                                                                                   
                      uest@w3.org                                                                                                               
                                                                                                                                                
                                                                                                                                                
                      18/04/2002 16:41                                                                                                          
                      Please respond to Ben                                                                                                     
                      Evans                                                                                                                     
                                                                                                                                                
                                                                                                                                                




Hi,

I think I've found a couple of typos in RFC 2518.

Specifically:

Page 24, Section 8.1.1, RFC 2518:

----

 >>Response

   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
              <D:multistatus xmlns:D="DAV:">
                         <D:response>

<D:href>http://www.foo.bar/file</D:href>
                                     <D:propstat>
                                                 <D:prop xmlns:R="
http://www.foo.bar/boxschema/">
                                                             <R:bigbox>

<R:BoxType>Box type A</R:BoxType>
                                                             </R:bigbox>
                                                             <R:author>

<R:Name>J.J. Johnson</R:Name>
                                                             </R:author>
                                                 </D:prop>
                                                 <D:status>HTTP/1.1 200
OK</D:status>
                                     </D:propstat>
                                     <D:propstat>

<D:prop><R:DingALing/><R:Random/></D:prop>
[snip]
----------

Here, this should read:

   <?xml version="1.0" encoding="utf-8" ?>
              <D:multistatus xmlns:D="DAV:">
                         <D:response xmlns:R="http://www.foo.bar/boxschema/
">

<D:href>http://www.foo.bar/file</D:href>
                                     <D:propstat>
                                                 <D:prop>
                                                             <R:bigbox>

<R:BoxType>Box type A</R:BoxType>
                                                             </R:bigbox>
                                                             <R:author>

<R:Name>J.J. Johnson</R:Name>
                                                             </R:author>
                                                 </D:prop>
                                                 <D:status>HTTP/1.1 200
OK</D:status>
                                     </D:propstat>
                                     <D:propstat>

<D:prop><R:DingALing/><R:Random/></D:prop>
...
-----

as otherwise, the namespace definition of R: will be out of scope by
the time the <R:DingALing/> tag is encountered.

And, on page 91:

-------
[snip]

23.4.2 Meaning of Qualified Names

   [Note to the reader: This section does not appear in
   [REC-XML-NAMES],
   but is necessary to avoid ambiguity for WebDAV XML processors.]

   WebDAV compliant XML processors MUST interpret a qualified name as
   a
   URI constructed by appending the LocalPart to the namespace name
   URI.

   Example

   <del:glider xmlns:del="http://www.del.jensen.org/">
<del:glidername>
Johnny Updraft
     </del:glidername>
<del:glideraccidents/>
</del:glider>

In this example, the qualified element name "del:glider" is
   interpreted as the URL "http://www.del.jensen.org/glider".

   <bar:glider xmlns:del="http://www.del.jensen.org/">
<bar:glidername>
Johnny Updraft
     </bar:glidername>
<bar:glideraccidents/>
</bar:glider>

[snip]

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

In the second example, the line:

<bar:glider xmlns:del="http://www.del.jensen.org/">

should read:

<bar:glider xmlns:bar="http://www.del.jensen.org/">

as otherwise the XML namespace bar is undefined, and a namespace
validating parser will barf.

Can someone shed some light on these. Are they typos or have I
missed something?

Ben










From w3c-dist-auth-request@w3.org  Fri Apr 19 04:13:14 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13183
	for <webdav-archive@lists.ietf.org>; Fri, 19 Apr 2002 04:13:13 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 70E1322FBF; Fri, 19 Apr 2002 03:13:15 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id EAA19849;
	Fri, 19 Apr 2002 04:13:08 -0400 (EDT)
Resent-Date: Fri, 19 Apr 2002 04:13:08 -0400 (EDT)
Resent-Message-Id: <200204190813.EAA19849@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA19756
	for <w3c-dist-auth@www19.w3.org>; Fri, 19 Apr 2002 04:12:51 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA32599
	for <w3c-dist-auth@w3.org>; Fri, 19 Apr 2002 04:12:51 -0400
Received: (qmail 6093 invoked by uid 0); 19 Apr 2002 08:12:16 -0000
Received: from p3ee24716.dip.t-dialin.net (HELO lisa) (62.226.71.22)
  by mail.gmx.net (mp001-rz3) with SMTP; 19 Apr 2002 08:12:16 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Stefan Eissing" <stefan.eissing@greenbytes.de>,
        "WebDAV" <w3c-dist-auth@w3.org>
Date: Fri, 19 Apr 2002 10:12:14 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCCEPBEGAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-reply-to: <356248E2-5367-11D6-8B11-00039384827E@greenbytes.de>
Subject: RE: need clarification about COPY to locked resource response code
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6132
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.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 Stefan Eissing
> Sent: Friday, April 19, 2002 9:30 AM
> To: WebDAV
> Subject: Re: need clarification about COPY to locked resource response
> code
>
> ...
>
> Am Montag den, 15. April 2002, um 23:59, schrieb Jason Crawford:
>
> >
> > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0098.html
> >
> > I don't think the above comment was resolved.
> >
> > Do we want to make a change to the spec?
>
> I don't feel strongly about it. If, then I would list 207 as
> possible status code of COPY/MOVE (where there are completely
> absent now) and explain that 423 LOCKED will only map to locked

They are missing from the status tables, but they are mentioned in
descriptions and examples.

> request-uri. If any other uri (destination included) makes trouble,
> clients should be able to deal with a 207.

I think the issue is that

- 423 is used both for LOCK problems on source and destination URIs,

- there doesn't seem to be any prior usage of multistatus to describe
information about destination URIs.

The cleanest "solution" (although not backward-compatible) would be to have
a separate status code for the condition "destination locked". However, we
are currently talking about RFC2518, so we're probably stuck with the
ambiguity.

In a future WebDAV protocol that supports enhanced error reporting a la
RFC3253, I'd probably suggest:

409 CONFLICT
...

<error xmlns='DAV:'><destination-URI-is-locked/></error>


> > Are we clear on what URL we need to point reference in the multi-status
> > response for various lock problems?
>
> I don't understand that question. Can you elaborate?

I understand that as: is it actually allowed (in copy/move/delete) to use
multistatus to report problems on destination resources?



From w3c-dist-auth-request@w3.org  Fri Apr 19 04:32:54 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13438
	for <webdav-archive@lists.ietf.org>; Fri, 19 Apr 2002 04:32:53 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 92CCE22F68; Fri, 19 Apr 2002 03:32:55 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id EAA21405;
	Fri, 19 Apr 2002 04:32:52 -0400 (EDT)
Resent-Date: Fri, 19 Apr 2002 04:32:52 -0400 (EDT)
Resent-Message-Id: <200204190832.EAA21405@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA21384
	for <w3c-dist-auth@www19.w3.org>; Fri, 19 Apr 2002 04:32:40 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA02618
	for <w3c-dist-auth@w3.org>; Fri, 19 Apr 2002 04:32:39 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3.org>; Fri, 19 Apr 2002 10:32:11 +0200
Date: Fri, 19 Apr 2002 10:32:09 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
Cc: "WebDAV" <w3c-dist-auth@w3.org>
To: "Julian Reschke" <julian.reschke@gmx.de>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <JIEGINCHMLABHJBIGKBCCEPBEGAA.julian.reschke@gmx.de>
Message-Id: <F091B118-536F-11D6-8B11-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.481)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3.org
Subject: Re: need clarification about COPY to locked resource response code
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6133
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


Am Freitag den, 19. April 2002, um 10:12, schrieb Julian Reschke:

>> From: w3c-dist-auth-request@w3.org
>> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing
>> Sent: Friday, April 19, 2002 9:30 AM
>> To: WebDAV
>> Subject: Re: need clarification about COPY to locked resource response
>> code
>>
>> ...
>>
>> Am Montag den, 15. April 2002, um 23:59, schrieb Jason Crawford:
>>
>>>
>>> http://lists.w3.org/Archives/Public/w3c-dist-
>>> auth/2002JanMar/0098.html
>>>
>>> I don't think the above comment was resolved.
>>>
>>> Do we want to make a change to the spec?
>>
>> I don't feel strongly about it. If, then I would list 207 as
>> possible status code of COPY/MOVE (where there are completely
>> absent now) and explain that 423 LOCKED will only map to locked
>
> They are missing from the status tables, but they are mentioned in
> descriptions and examples.

I think that's why I wrote that they are missing from the status 
codes. ;)

>> request-uri. If any other uri (destination included) makes trouble,
>> clients should be able to deal with a 207.
>
> I think the issue is that
>
> - 423 is used both for LOCK problems on source and destination URIs,

Yes.

> - there doesn't seem to be any prior usage of multistatus to describe
> information about destination URIs.

The examples cover children of destination uris in 207. But, for 
example,
with access control you can get 403 on the destination uri and that is
not defined either. I would expect a server to report this 403 on the
destination inside a 207 multistatus.

> The cleanest "solution" (although not backward-compatible) would 
> be to have
> a separate status code for the condition "destination locked". 
> However, we
> are currently talking about RFC2518, so we're probably stuck with the
> ambiguity.
>
> In a future WebDAV protocol that supports enhanced error reporting a la
> RFC3253, I'd probably suggest:
>
> 409 CONFLICT
> ....
>
> <error xmlns='DAV:'><destination-URI-is-locked/></error>

I don't like this for the simple reason that clients need hardcoded
information about each DAV:error _and_ they need to know how to handle
HTTP status codes. So I would prefer to use existing HTTP status 
codes over
new DAV:errors.

Otherwise you need to define also DAV:destination-is-not-accesible,
DAV:destination-parent-is-locked, etc.

//Stefan

>
>>> Are we clear on what URL we need to point reference in the 
>>> multi-status
>>> response for various lock problems?
>>
>> I don't understand that question. Can you elaborate?
>
> I understand that as: is it actually allowed (in copy/move/delete) 
> to use
> multistatus to report problems on destination resources?
>





From w3c-dist-auth-request@w3.org  Fri Apr 19 04:48:14 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13706
	for <webdav-archive@lists.ietf.org>; Fri, 19 Apr 2002 04:48:13 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id F34A122FE9; Fri, 19 Apr 2002 03:48:15 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id EAA25750;
	Fri, 19 Apr 2002 04:48:12 -0400 (EDT)
Resent-Date: Fri, 19 Apr 2002 04:48:12 -0400 (EDT)
Resent-Message-Id: <200204190848.EAA25750@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA25663
	for <w3c-dist-auth@www19.w3.org>; Fri, 19 Apr 2002 04:48:00 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA04898
	for <w3c-dist-auth@w3.org>; Fri, 19 Apr 2002 04:47:59 -0400
Received: (qmail 7138 invoked by uid 0); 19 Apr 2002 08:47:28 -0000
Received: from p3ee24716.dip.t-dialin.net (HELO lisa) (62.226.71.22)
  by mail.gmx.net (mp014-rz3) with SMTP; 19 Apr 2002 08:47:28 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "WebDAV" <w3c-dist-auth@w3.org>
Date: Fri, 19 Apr 2002 10:47:29 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCAEPDEGAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-reply-to: <F091B118-536F-11D6-8B11-00039384827E@greenbytes.de>
Subject: RE: need clarification about COPY to locked resource response code
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6134
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.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 Stefan Eissing
> Sent: Friday, April 19, 2002 10:32 AM
> To: Julian Reschke
> Cc: WebDAV
> Subject: Re: need clarification about COPY to locked resource response
> code
>
> ...
>
> > - there doesn't seem to be any prior usage of multistatus to describe
> > information about destination URIs.
>
> The examples cover children of destination uris in 207. But, for
> example,

Indeed. So I'll have to take this back.

But how well will this interoperate? If the href in multistatus only lists
the destination URI, it will be non-trivial to find out which source could
not be copied/moved, right? So to make this fly, I'd expect the response
element *also* to tell me which source resource was affected by the problem
on the destination.

> with access control you can get 403 on the destination uri and that is
> not defined either. I would expect a server to report this 403 on the
> destination inside a 207 multistatus.
>
> > The cleanest "solution" (although not backward-compatible) would
> > be to have
> > a separate status code for the condition "destination locked".
> > However, we
> > are currently talking about RFC2518, so we're probably stuck with the
> > ambiguity.
> >
> > In a future WebDAV protocol that supports enhanced error reporting a la
> > RFC3253, I'd probably suggest:
> >
> > 409 CONFLICT
> > ....
> >
> > <error xmlns='DAV:'><destination-URI-is-locked/></error>
>
> I don't like this for the simple reason that clients need hardcoded
> information about each DAV:error _and_ they need to know how to handle
> HTTP status codes. So I would prefer to use existing HTTP status
> codes over
> new DAV:errors.

RFC3253 already goes this way, simply for the reason that it's hard to
define new HTTP status codes, but it's simple to define new error elements
(because this solves the issue of namespacing the new codes automatically).
"Simple" clients will just see 403 (won't work no matter how hard you try)
or 409 (it failed, but there's something you can do about it).

> Otherwise you need to define also DAV:destination-is-not-accesible,
> DAV:destination-parent-is-locked, etc.

Maybe.




From w3c-dist-auth-request@w3.org  Fri Apr 19 16:00:02 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26483
	for <webdav-archive@lists.ietf.org>; Fri, 19 Apr 2002 16:00:02 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 2271F22E76; Fri, 19 Apr 2002 15:00:04 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA21011;
	Fri, 19 Apr 2002 15:59:18 -0400 (EDT)
Resent-Date: Fri, 19 Apr 2002 15:59:18 -0400 (EDT)
Resent-Message-Id: <200204191959.PAA21011@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA20991
	for <w3c-dist-auth@www19.w3.org>; Fri, 19 Apr 2002 15:59:11 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA25610
	for <w3c-dist-auth@w3.org>; Fri, 19 Apr 2002 15:59:11 -0400
Received: (qmail 8772 invoked by uid 0); 19 Apr 2002 19:58:39 -0000
Received: from pd950c3de.dip.t-dialin.net (HELO lisa) (217.80.195.222)
  by mail.gmx.net (mp011-rz3) with SMTP; 19 Apr 2002 19:58:39 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "WebDAV" <w3c-dist-auth@w3.org>
Date: Fri, 19 Apr 2002 21:58:39 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCCEAOEHAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <JIEGINCHMLABHJBIGKBCAEPDEGAA.julian.reschke@gmx.de>
x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Subject: DAV:displayname vs. Microsoft webfolders
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6135
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.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,

we just noticed the following bug in Microsoft's web folder implementation:
when displaying the contents of a collection, it will use (when present) the
DAV:displayname property as internal member name. Furthermore, the URI
displayed in the "tabular view" will use the collection's URI + the
displayname to build the member's URI.

This is obviously wrong, because there's no guarantee that the individual
DAV.displayname values in a property are distinct.

IMHO, the RFC2518 revision should say:

"User agents MUST not use the DAV:displayname to identify the individual
collection members (because the value may not be unique across the members
of a collection). However, they MAY use it to display additional information
about a collection member".





From w3c-dist-auth-request@w3.org  Fri Apr 19 16:14:10 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27865
	for <webdav-archive@lists.ietf.org>; Fri, 19 Apr 2002 16:14:10 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id C542822E5B; Fri, 19 Apr 2002 15:14:12 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id QAA22413;
	Fri, 19 Apr 2002 16:14:01 -0400 (EDT)
Resent-Date: Fri, 19 Apr 2002 16:14:01 -0400 (EDT)
Resent-Message-Id: <200204192014.QAA22413@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA22362
	for <w3c-dist-auth@www19.w3.org>; Fri, 19 Apr 2002 16:13:48 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA28036
	for <w3c-dist-auth@w3.org>; Fri, 19 Apr 2002 16:13:48 -0400
Received: (qmail 19201 invoked by uid 0); 19 Apr 2002 20:13:17 -0000
Received: from pd950c3de.dip.t-dialin.net (HELO lisa) (217.80.195.222)
  by mail.gmx.net (mp016-rz3) with SMTP; 19 Apr 2002 20:13:17 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Julian Reschke" <julian.reschke@gmx.de>, "WebDAV" <w3c-dist-auth@w3.org>
Date: Fri, 19 Apr 2002 22:13:17 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCKEAPEHAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <JIEGINCHMLABHJBIGKBCCEAOEHAA.julian.reschke@gmx.de>
x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Subject: Microsoft HOWTO: Launch Word from Internet Explorer (Q178222)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6136
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.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 recently tested this ([1]). After changing the explorer options, Word
indeed launches when selecting a link to a .doc file, however a trace shows
that Word

a) GETs the resource (ok) and displays it as "read only" (wrong), then

b) does an OPTION on the root collection (wrong, it may not be DAV enabled),
then

c) does an OPTION on the resource itself, which responds with a 401 (Auth
required). However, the authentication dialog does not pop up until Word's
document window is closed.

Has anybody used this setup successfully?

And yes,

d) the file can be successfully opened and edited when opened from
Microsoft's webfolder client.

Julian



[1] <http://support.microsoft.com/default.aspx?scid=kb;DE;q178222>




From w3c-dist-auth-request@w3.org  Sat Apr 20 16:17:01 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07084
	for <webdav-archive@odin.ietf.org>; Sat, 20 Apr 2002 16:17:01 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 35CD122DAB; Sat, 20 Apr 2002 15:17:04 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id QAA01199;
	Sat, 20 Apr 2002 16:16:42 -0400 (EDT)
Resent-Date: Sat, 20 Apr 2002 16:16:42 -0400 (EDT)
Resent-Message-Id: <200204202016.QAA01199@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA01135
	for <w3c-dist-auth@www19.w3.org>; Sat, 20 Apr 2002 16:16:29 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA23860
	for <w3c-dist-auth@w3c.org>; Sat, 20 Apr 2002 16:16:30 -0400
Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Sat, 20 Apr 2002 16:12:25 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19)
	id <26NA6RGH>; Sat, 20 Apr 2002 16:15:53 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B106979528@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: Webdav WG <w3c-dist-auth@w3c.org>
Date: Sat, 20 Apr 2002 16:15:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: RFC2518bis: allprop deprecated (4.1)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6137
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>

Just to follow up on this thread from a couple of months ago:

I would be happy to see allprop defined as being:
"all 2518 props and all dead props".  I also support the
allprop-include extension, but that would have to be
specified in a different standard track, since it is 
new functionality (unless we can get some interoperable 
implementations out there fast).

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Thursday, February 28, 2002 12:22 PM
To: Webdav WG
Subject: RE: RFC2518bis: allprop deprecated (4.1)


Following up to my own post:

the last WG meeting minutes (at
<http://www.ietf.org/proceedings/01dec/127.htm>) say:

"What 'allprop' means....

MUST include all 2518 props and all dead props to maintain interrop. However
new live props in ACL DASL etc are being defined as NOT returned by allprop.
Property dead on one server may not be dead on another server. allprop is
historical. Promote using propname. Is it legal for Xythos to use the adobe
namespace? You could have a property that is defined dead on one server be
live on another!

allprop must return all properties required for interrop.

Eric - property should be defined dead or non-nead...you can't mix and
match.

Should we deprecate allprop?
Perhaps use allprop-include or other mechanism to save roundtrip and
deprecate allprop. Sitecopy properties would not be the same. Is deprecate
something we can do in IETF? Take it out and reference them back to the old
draft. Geoff - Short description plus reference back to old spec. We took a
vote and 3 people would like it to become a info note, nobody objected."


I'm not sure I understand what the last paragraph says. I certainly do *not*
agree to remove allprop without replacing it with something which is as
efficient. See remarks in my previous mail.

Julian

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke
> Sent: Thursday, February 21, 2002 9:52 AM
> To: Lisa Dusseault; Webdav WG
> Subject: RFC2518bis: allprop deprecated (4.1)
>
>
> Lisa,
>
> I don't agree at all with the deprecation, and I don't think that
> there was
> consensus about this.
>
> The draft says:
>
> Clients MUST not send allprop requests in any form (either the empty body
> PROPFIND or the specific allprop element), because allprop is
> being removed.
> WebDAV servers increasingly have expensively-calculated or lengthy
> properties (see DeltaV and ACL specifications [TODO: ref RFC when
> available]) and do not return all properties already.  Instead, WebDAV
> clients can use propname requests to discover what properties exist, and
> request named properties when retrieving values.  A WebDAV server MAY omit
> certain live properties from other specifications when responding to an
> allprop request from an older client, and MAY return only custom (dead)
> properties and those defined in this specification.
>
> In particular:
>
> "WebDAV servers increasingly have expensively-calculated or lengthy
> properties (see DeltaV and ACL specifications [TODO: ref RFC when
> available]) and do not return all properties already."
>
> -> This is an argument for *restricting* the set of properties returned on
> allprop, not for removing the feature (and that's what deltaV does).
>
> "Instead, WebDAV clients can use propname requests to discover what
> properties exist, and request named properties when retrieving values."
>
> -> And the benefit is? The client will issue two calls: first it will use
> propname to find the list of properties. Computing whether a live property
> exists maybe as expensive as computing it (for instance, to find
> out whether
> something is checked in/out). *Then* it will submit PROPFIND /
> prop will all
> these properties. So as compared to the current situation, the server may
> have to compute things twice which wouldn't have been computed at
> all before
> (since asking for allprop wouldn't require computing live deltaV
> properties).
>
> -> Even leaving the propname vs live properties issue out, this
> doesn't make
> sense. You are removing a working and interoperable protocol
> feature without
> sound reason. As a fallback you offer a workaround which requires at least
> one additional trip to the server, possibly heavy computation on
> the client
> (computing the set of all property names on the members of a
> collection) and
> then additional marshalling (when I do a PROPFIND/prop with a long list of
> (dead) property names on a collection with depth 1, the server
> will have to
> 404-status them for many collection members).
>
> -> I agree that PROPFIND needs to be cleaned up, but this is not
> the way to
> go. The draft continues with:
>
> "A WebDAV server MAY omit certain live properties from other
> specifications
> when responding to an allprop request from an older client, and MAY return
> only custom (dead) properties and those defined in this specification."
>
> -> I think this may make sense. We will however need a way to get all dead
> properties and a set of named properties with a single request
> (see [1]). We
> may also have to find a way for a client to discover that something is a
> live property.
>
>
> [1]
> <http://www.greenbytes.de/tech/webdav/draft-reschke-webdav-allprop
-include-l
atest.html>



From w3c-dist-auth-request@w3.org  Sat Apr 20 21:11:25 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09186
	for <webdav-archive@odin.ietf.org>; Sat, 20 Apr 2002 21:11:24 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id F24DB22D70; Sat, 20 Apr 2002 20:11:26 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id VAA15095;
	Sat, 20 Apr 2002 21:11:04 -0400 (EDT)
Resent-Date: Sat, 20 Apr 2002 21:11:04 -0400 (EDT)
Resent-Message-Id: <200204210111.VAA15095@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA15055
	for <w3c-dist-auth@www19.w3.org>; Sat, 20 Apr 2002 21:10:54 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA11927
	for <w3c-dist-auth@w3.org>; Sat, 20 Apr 2002 21:10:54 -0400
Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Sat, 20 Apr 2002 21:06:54 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19)
	id <26NA64QZ>; Sat, 20 Apr 2002 21:10:23 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B106979542@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: WebDAV <w3c-dist-auth@w3.org>
Date: Sat, 20 Apr 2002 21:10:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: RE: need clarification about COPY to locked resource response cod 	e
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6138
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>

   From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]

   Am Freitag den, 19. April 2002, um 10:12, schrieb Julian Reschke:

   > In a future WebDAV protocol that supports enhanced error reporting a la
   > RFC3253, I'd probably suggest:
   >
   > 409 CONFLICT
   > ....
   > <error xmlns='DAV:'><destination-URI-is-locked/></error>

   I don't like this for the simple reason that clients need hardcoded
   information about each DAV:error _and_ they need to know how to
   handle HTTP status codes.

I don't see the problem.  Either the client does not care about
the reason for the error (in which case it just ignores the
DAV:error value), or it does care, in which case it needs the
explanation provided by the DAV:error value.  The advantage of
having both is that you have a simple error code for simple clients,
and a more comprehensive error code for more sophisticated clients.

   So I would prefer to use existing HTTP
   status codes over new DAV:errors.

You can't pack sufficient information into the few bits provided
by the HTTP status codes, without having the error codes mean subtly
different things for different methods (the unfortunate path
initiated by 2518, but avoided by 3253).

   Otherwise you need to define also DAV:destination-is-not-accesible,
   DAV:destination-parent-is-locked, etc.

You define errors at whatever
is the appropriate level of detail that is useful for
interoperable implementations.  If the distinction between
"destination is not accessible" and "destination parent is locked"
is sufficiently important to merit separate error codes, then separate
error codes should be defined.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Sun Apr 21 05:20:38 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22790
	for <webdav-archive@odin.ietf.org>; Sun, 21 Apr 2002 05:20:38 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 3813822BE2; Sun, 21 Apr 2002 04:20:40 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id FAA14256;
	Sun, 21 Apr 2002 05:20:33 -0400 (EDT)
Resent-Date: Sun, 21 Apr 2002 05:20:33 -0400 (EDT)
Resent-Message-Id: <200204210920.FAA14256@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA14235
	for <w3c-dist-auth@www19.w3.org>; Sun, 21 Apr 2002 05:20:16 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA20261
	for <w3c-dist-auth@w3c.org>; Sun, 21 Apr 2002 05:20:15 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3c.org>; Sun, 21 Apr 2002 11:19:30 +0200
Date: Sun, 21 Apr 2002 11:19:29 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
Cc: Webdav WG <w3c-dist-auth@w3c.org>
To: "Clemm, Geoff" <gclemm@rational.com>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B106979528@SUS-MA1IT01>
Message-Id: <E226E178-5508-11D6-8B11-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.481)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: RFC2518bis: allprop deprecated (4.1)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6139
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit

Am Samstag den, 20. April 2002, um 22:15, schrieb Clemm, Geoff:

> Just to follow up on this thread from a couple of months ago:
>
> I would be happy to see allprop defined as being:
> "all 2518 props and all dead props".  I also support the
> allprop-include extension, but that would have to be
> specified in a different standard track, since it is
> new functionality (unless we can get some interoperable
> implementations out there fast).

I had an implementation of allprop-include at the last
webdav interop in my webdav-proxy. It did not break
any present servers (nor IIS/Sharepoint).

So, I would encourage (especially Deltav/ACL
capable client) developers to have a look at:
http://www.greenbytes.de/tech/webdav/

//Stefan

> Cheers,
> Geoff
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Thursday, February 28, 2002 12:22 PM
> To: Webdav WG
> Subject: RE: RFC2518bis: allprop deprecated (4.1)
>
>
> Following up to my own post:
>
> the last WG meeting minutes (at
> <http://www.ietf.org/proceedings/01dec/127.htm>) say:
>
> "What 'allprop' means....
>
> MUST include all 2518 props and all dead props to maintain 
> interrop. However
> new live props in ACL DASL etc are being defined as NOT returned 
> by allprop.
> Property dead on one server may not be dead on another server. 
> allprop is
> historical. Promote using propname. Is it legal for Xythos to use 
> the adobe
> namespace? You could have a property that is defined dead on one 
> server be
> live on another!
>
> allprop must return all properties required for interrop.
>
> Eric - property should be defined dead or non-nead...you can't mix and
> match.
>
> Should we deprecate allprop?
> Perhaps use allprop-include or other mechanism to save roundtrip and
> deprecate allprop. Sitecopy properties would not be the same. Is 
> deprecate
> something we can do in IETF? Take it out and reference them back 
> to the old
> draft. Geoff - Short description plus reference back to old spec. 
> We took a
> vote and 3 people would like it to become a info note, nobody 
> objected."
>
>
> I'm not sure I understand what the last paragraph says. I 
> certainly do *not*
> agree to remove allprop without replacing it with something which is as
> efficient. See remarks in my previous mail.
>
> Julian
>
>> -----Original Message-----
>> From: w3c-dist-auth-request@w3.org
>> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke
>> Sent: Thursday, February 21, 2002 9:52 AM
>> To: Lisa Dusseault; Webdav WG
>> Subject: RFC2518bis: allprop deprecated (4.1)
>>
>>
>> Lisa,
>>
>> I don't agree at all with the deprecation, and I don't think that
>> there was
>> consensus about this.
>>
>> The draft says:
>>
>> Clients MUST not send allprop requests in any form (either the 
>> empty body
>> PROPFIND or the specific allprop element), because allprop is
>> being removed.
>> WebDAV servers increasingly have expensively-calculated or lengthy
>> properties (see DeltaV and ACL specifications [TODO: ref RFC when
>> available]) and do not return all properties already.  Instead, WebDAV
>> clients can use propname requests to discover what properties 
>> exist, and
>> request named properties when retrieving values.  A WebDAV server 
>> MAY omit
>> certain live properties from other specifications when responding 
>> to an
>> allprop request from an older client, and MAY return only custom 
>> (dead)
>> properties and those defined in this specification.
>>
>> In particular:
>>
>> "WebDAV servers increasingly have expensively-calculated or lengthy
>> properties (see DeltaV and ACL specifications [TODO: ref RFC when
>> available]) and do not return all properties already."
>>
>> -> This is an argument for *restricting* the set of properties 
>> returned on
>> allprop, not for removing the feature (and that's what deltaV does).
>>
>> "Instead, WebDAV clients can use propname requests to discover what
>> properties exist, and request named properties when retrieving 
>> values."
>>
>> -> And the benefit is? The client will issue two calls: first it 
>> will use
>> propname to find the list of properties. Computing whether a live 
>> property
>> exists maybe as expensive as computing it (for instance, to find
>> out whether
>> something is checked in/out). *Then* it will submit PROPFIND /
>> prop will all
>> these properties. So as compared to the current situation, the 
>> server may
>> have to compute things twice which wouldn't have been computed at
>> all before
>> (since asking for allprop wouldn't require computing live deltaV
>> properties).
>>
>> -> Even leaving the propname vs live properties issue out, this
>> doesn't make
>> sense. You are removing a working and interoperable protocol
>> feature without
>> sound reason. As a fallback you offer a workaround which requires 
>> at least
>> one additional trip to the server, possibly heavy computation on
>> the client
>> (computing the set of all property names on the members of a
>> collection) and
>> then additional marshalling (when I do a PROPFIND/prop with a 
>> long list of
>> (dead) property names on a collection with depth 1, the server
>> will have to
>> 404-status them for many collection members).
>>
>> -> I agree that PROPFIND needs to be cleaned up, but this is not
>> the way to
>> go. The draft continues with:
>>
>> "A WebDAV server MAY omit certain live properties from other
>> specifications
>> when responding to an allprop request from an older client, and 
>> MAY return
>> only custom (dead) properties and those defined in this 
>> specification."
>>
>> -> I think this may make sense. We will however need a way to get 
>> all dead
>> properties and a set of named properties with a single request
>> (see [1]). We
>> may also have to find a way for a client to discover that 
>> something is a
>> live property.
>>
>>
>> [1]
>> <http://www.greenbytes.de/tech/webdav/draft-reschke-webdav-allprop
> -include-l
> atest.html>
>




From w3c-dist-auth-request@w3.org  Sun Apr 21 05:36:43 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22892
	for <webdav-archive@odin.ietf.org>; Sun, 21 Apr 2002 05:36:43 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 390BC22C83; Sun, 21 Apr 2002 04:36:45 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id FAA15126;
	Sun, 21 Apr 2002 05:36:41 -0400 (EDT)
Resent-Date: Sun, 21 Apr 2002 05:36:41 -0400 (EDT)
Resent-Message-Id: <200204210936.FAA15126@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA15106
	for <w3c-dist-auth@www19.w3.org>; Sun, 21 Apr 2002 05:36:29 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA21223
	for <w3c-dist-auth@w3.org>; Sun, 21 Apr 2002 05:36:28 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3.org>; Sun, 21 Apr 2002 11:36:16 +0200
Date: Sun, 21 Apr 2002 11:36:15 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
Cc: WebDAV <w3c-dist-auth@w3.org>
To: "Clemm, Geoff" <gclemm@rational.com>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B106979542@SUS-MA1IT01>
Message-Id: <39FEE6DB-550B-11D6-8B11-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.481)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3.org
Subject: Re: need clarification about COPY to locked resource response cod 	e
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6140
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


Am Sonntag den, 21. April 2002, um 03:10, schrieb Clemm, Geoff:

>    From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
>
>    Am Freitag den, 19. April 2002, um 10:12, schrieb Julian Reschke:
>
>> In a future WebDAV protocol that supports enhanced error 
>> reporting a la
>> RFC3253, I'd probably suggest:
>>
>> 409 CONFLICT
>> ....
>> <error xmlns='DAV:'><destination-URI-is-locked/></error>
>
>    I don't like this for the simple reason that clients need hardcoded
>    information about each DAV:error _and_ they need to know how to
>    handle HTTP status codes.
>
> I don't see the problem.  Either the client does not care about
> the reason for the error (in which case it just ignores the
> DAV:error value), or it does care, in which case it needs the
> explanation provided by the DAV:error value.  The advantage of
> having both is that you have a simple error code for simple clients,
> and a more comprehensive error code for more sophisticated clients.

One cannot not disagree with this. However, in Julian's example
error responses like 403 and others are replaced with a general
409 and some DAV:error in the response body.

What you are talking about is keeping a 403 response and _adding_
a response body with a more detailed explanation in DAV:error. That
is perfectly fine with me.

>    So I would prefer to use existing HTTP
>    status codes over new DAV:errors.
>
> You can't pack sufficient information into the few bits provided
> by the HTTP status codes, without having the error codes mean subtly
> different things for different methods (the unfortunate path
> initiated by 2518, but avoided by 3253).

I have to elaborate. Instead of a response plain vanilla
HTTP/1.1 403 LOCKED

or Julian's
HTTP/1.1 409 CONFLICT
<DAV:error><DAV:destination-parent-locked/></DAV:error>

I would prefer
HTTP/1.1 207 MultiStatus
<DAV:multistatus>
   <DAV:response><DAV:href>http://host/destination/parent</DAV:href>
   <DAV:status>HTTP/1.1 403 LOCKED</DAV:status>
   </DAV:response>
   ...
</DAV:multistatus>

The problem with this is that for COPY/MOVE, a server would have
to list all non-copied resources as well in the multistatus. Something
to be avoided when a precondition for a operation failed.

So, the best of both worlds would maybe be:
HTTP/1.1 403 LOCKED
<DAV:error>
   <DAV:href>http://host/destination/parent</DAV:href>
   <DAV:status>HTTP/1.1 403 LOCKED</DAV:status>
</DAV:error>

//Stefan


>    Otherwise you need to define also DAV:destination-is-not-accesible,
>    DAV:destination-parent-is-locked, etc.
>
> You define errors at whatever
> is the appropriate level of detail that is useful for
> interoperable implementations.  If the distinction between
> "destination is not accessible" and "destination parent is locked"
> is sufficiently important to merit separate error codes, then separate
> error codes should be defined.
>
> Cheers,
> Geoff
>





From w3c-dist-auth-request@w3.org  Sun Apr 21 06:04:49 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23158
	for <webdav-archive@odin.ietf.org>; Sun, 21 Apr 2002 06:04:48 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id D0ED322D33; Sun, 21 Apr 2002 05:04:50 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id GAA16237;
	Sun, 21 Apr 2002 06:04:46 -0400 (EDT)
Resent-Date: Sun, 21 Apr 2002 06:04:46 -0400 (EDT)
Resent-Message-Id: <200204211004.GAA16237@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA16217
	for <w3c-dist-auth@www19.w3.org>; Sun, 21 Apr 2002 06:04:34 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id GAA22855
	for <w3c-dist-auth@w3.org>; Sun, 21 Apr 2002 06:04:34 -0400
Received: (qmail 7181 invoked by uid 0); 21 Apr 2002 10:04:02 -0000
Received: from pd950c3da.dip.t-dialin.net (HELO lisa) (217.80.195.218)
  by mail.gmx.net (mp014-rz3) with SMTP; 21 Apr 2002 10:04:02 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Stefan Eissing" <stefan.eissing@greenbytes.de>,
        "Clemm, Geoff" <gclemm@rational.com>
Cc: "WebDAV" <w3c-dist-auth@w3.org>
Date: Sun, 21 Apr 2002 12:03:57 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCKEBOEHAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <39FEE6DB-550B-11D6-8B11-00039384827E@greenbytes.de>
x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Subject: RE: need clarification about COPY to locked resource response cod 	e
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6141
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.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 Stefan Eissing
> Sent: Sunday, April 21, 2002 11:36 AM
> To: Clemm, Geoff
> Cc: WebDAV
> Subject: Re: need clarification about COPY to locked resource response
> cod e
>
>
>
> Am Sonntag den, 21. April 2002, um 03:10, schrieb Clemm, Geoff:
>
> >    From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
> >
> >    Am Freitag den, 19. April 2002, um 10:12, schrieb Julian Reschke:
> >
> >> In a future WebDAV protocol that supports enhanced error
> >> reporting a la
> >> RFC3253, I'd probably suggest:
> >>
> >> 409 CONFLICT
> >> ....
> >> <error xmlns='DAV:'><destination-URI-is-locked/></error>
> >
> >    I don't like this for the simple reason that clients need hardcoded
> >    information about each DAV:error _and_ they need to know how to
> >    handle HTTP status codes.
> >
> > I don't see the problem.  Either the client does not care about
> > the reason for the error (in which case it just ignores the
> > DAV:error value), or it does care, in which case it needs the
> > explanation provided by the DAV:error value.  The advantage of
> > having both is that you have a simple error code for simple clients,
> > and a more comprehensive error code for more sophisticated clients.
>
> One cannot not disagree with this. However, in Julian's example
> error responses like 403 and others are replaced with a general
> 409 and some DAV:error in the response body.

Nope :-) Status codes *other* than 403 *or* 409 are replaces.

> What you are talking about is keeping a 403 response and _adding_
> a response body with a more detailed explanation in DAV:error. That
> is perfectly fine with me.
>
> >    So I would prefer to use existing HTTP
> >    status codes over new DAV:errors.
> >
> > You can't pack sufficient information into the few bits provided
> > by the HTTP status codes, without having the error codes mean subtly
> > different things for different methods (the unfortunate path
> > initiated by 2518, but avoided by 3253).
>
> I have to elaborate. Instead of a response plain vanilla
> HTTP/1.1 403 LOCKED

That would be 423 LOCKED or 403 FORBIDDEN.

> or Julian's
> HTTP/1.1 409 CONFLICT
> <DAV:error><DAV:destination-parent-locked/></DAV:error>
>
> I would prefer
> HTTP/1.1 207 MultiStatus
> <DAV:multistatus>
>    <DAV:response><DAV:href>http://host/destination/parent</DAV:href>
>    <DAV:status>HTTP/1.1 403 LOCKED</DAV:status>
>    </DAV:response>
>    ...
> </DAV:multistatus>
>
> The problem with this is that for COPY/MOVE, a server would have
> to list all non-copied resources as well in the multistatus. Something
> to be avoided when a precondition for a operation failed.
>
> So, the best of both worlds would maybe be:
> HTTP/1.1 403 LOCKED
> <DAV:error>
>    <DAV:href>http://host/destination/parent</DAV:href>
>    <DAV:status>HTTP/1.1 403 LOCKED</DAV:status>
> </DAV:error>

Actually, I'd prefer to change/clarify multistatus error reporting to:

- MUST contain response elements for each source resource that wasn't
moved/copied/deleted as specified (however keeping the current optimization
for 424 on ancestors)

- MAY contain response elements for targets that caused the failure.

So we would get something like:

<multistatus xmlns="DAV:">
   <response>
      <href>source</href>
      <status>HTTP/1.1 403 Conflict</status>

<responsedescription><error><destination-locked/></error></responsedescripti
on>
   </response>
   <response>
      <href>http://host/destination/parent</href>
      <status>HTTP/1.1 423 LOCKED</status>
   </response>
   ...
</multistatus>

The benefit being that a client that "blindly" searches for source URIs will
find something. However, a smarter client can extract the additional piece
of information that's available after all.


It might be woth thinking to also add some kind of linkage between the two
response elements.



From w3c-dist-auth-request@w3.org  Sun Apr 21 12:23:06 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27987
	for <webdav-archive@odin.ietf.org>; Sun, 21 Apr 2002 12:23:05 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id DA47222BDD; Sun, 21 Apr 2002 11:23:07 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA19380;
	Sun, 21 Apr 2002 12:22:59 -0400 (EDT)
Resent-Date: Sun, 21 Apr 2002 12:22:59 -0400 (EDT)
Resent-Message-Id: <200204211622.MAA19380@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA19356
	for <w3c-dist-auth@www19.w3.org>; Sun, 21 Apr 2002 12:22:49 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA01596
	for <w3c-dist-auth@w3.org>; Sun, 21 Apr 2002 12:22:50 -0400
Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Sun, 21 Apr 2002 12:18:48 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19)
	id <26NA67JH>; Sun, 21 Apr 2002 12:22:18 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10697957E@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: WebDAV <w3c-dist-auth@w3.org>
Date: Sun, 21 Apr 2002 12:22:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: RE: displayname vs. Microsoft webfolders
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6142
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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.

Cheers,
Geoff

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

we just noticed the following bug in Microsoft's web folder implementation:
when displaying the contents of a collection, it will use (when present) the
DAV:displayname property as internal member name. Furthermore, the URI
displayed in the "tabular view" will use the collection's URI + the
displayname to build the member's URI.

This is obviously wrong, because there's no guarantee that the individual
DAV.displayname values in a property are distinct.

IMHO, the RFC2518 revision should say:

"User agents MUST not use the DAV:displayname to identify the individual
collection members (because the value may not be unique across the members
of a collection). However, they MAY use it to display additional information
about a collection member".




From w3c-dist-auth-request@w3.org  Sun Apr 21 17:07:25 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01804
	for <webdav-archive@odin.ietf.org>; Sun, 21 Apr 2002 17:07:25 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 97D4722D5C; Sun, 21 Apr 2002 16:07:27 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id RAA08515;
	Sun, 21 Apr 2002 17:06:32 -0400 (EDT)
Resent-Date: Sun, 21 Apr 2002 17:06:32 -0400 (EDT)
Resent-Message-Id: <200204212106.RAA08515@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA08489
	for <w3c-dist-auth@www19.w3.org>; Sun, 21 Apr 2002 17:06:23 -0400 (EDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA24367
	for <w3c-dist-auth@w3.org>; Sun, 21 Apr 2002 17:06:23 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3LL5ims392382;
	Sun, 21 Apr 2002 17:05:44 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77])
	by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3LL5ga70224;
	Sun, 21 Apr 2002 17:05:43 -0400
To: "Clemm, Geoff" <gclemm@Rational.Com>
Cc: WebDAV <w3c-dist-auth@w3.org>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF243A9F6B.FA8E94EF-ON85256BA2.0072CDDC@pok.ibm.com>
From: "Jason Crawford" <ccjason@us.ibm.com>
Date: Sun, 21 Apr 2002 17:04:59 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at
 04/21/2002 05:05:42 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: RE: displayname vs. Microsoft webfolders
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6143
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


Actually, I tend to be of the other camp.  I feel the spec should avoid UI
imperatives if possible, the spec is clear enough about what the possible
negative repercusions of this UI approach are, and if a client wants to
experiment at the UI level, let them... as long as they comply at the
protocol level.  (I assume Msft complies at the protocol level, but I
haven't verified that.)

I don't feel strongly though and will go with the flow.

J

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



                                                                                                                                       
                      "Clemm, Geoff"                                                                                                   
                      <gclemm@Rational.        To:       WebDAV <w3c-dist-auth@w3.org>                                                 
                      Com>                     cc:                                                                                     
                      Sent by:                 Subject:  RE: displayname vs. Microsoft webfolders                                      
                      w3c-dist-auth-req                                                                                                
                      uest@w3.org                                                                                                      
                                                                                                                                       
                                                                                                                                       
                      04/21/2002 12:22                                                                                                 
                      PM                                                                                                               
                                                                                                                                       
                                                                                                                                       



I agree.

Cheers,
Geoff

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

we just noticed the following bug in Microsoft's web folder implementation:
when displaying the contents of a collection, it will use (when present)
the
DAV:displayname property as internal member name. Furthermore, the URI
displayed in the "tabular view" will use the collection's URI + the
displayname to build the member's URI.

This is obviously wrong, because there's no guarantee that the individual
DAV.displayname values in a property are distinct.

IMHO, the RFC2518 revision should say:

"User agents MUST not use the DAV:displayname to identify the individual
collection members (because the value may not be unique across the members
of a collection). However, they MAY use it to display additional
information
about a collection member".









From w3c-dist-auth-request@w3.org  Sun Apr 21 19:00:44 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02624
	for <webdav-archive@odin.ietf.org>; Sun, 21 Apr 2002 19:00:43 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id A6D8B22DF6; Sun, 21 Apr 2002 18:00:43 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id TAA13573;
	Sun, 21 Apr 2002 19:00:38 -0400 (EDT)
Resent-Date: Sun, 21 Apr 2002 19:00:38 -0400 (EDT)
Resent-Message-Id: <200204212300.TAA13573@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA13524
	for <w3c-dist-auth@www19.w3.org>; Sun, 21 Apr 2002 19:00:33 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA02714
	for <w3c-dist-auth@w3.org>; Sun, 21 Apr 2002 19:00:32 -0400
Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Sun, 21 Apr 2002 18:56:30 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19)
	id <26NA7CAG>; Sun, 21 Apr 2002 19:00:01 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1069795C0@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: WebDAV <w3c-dist-auth@w3.org>
Date: Sun, 21 Apr 2002 18:59:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: RE: displayname vs. Microsoft webfolders
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6144
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>

There are two possible issues here:

The first is a UI issue, namely whether a client displays the URI segment
(which is guaranteed to be unique) or the DAV:displayname (which is not
guaranteed to be unique, but is likely to be more human meaningful).
I agree with Jason that we should make no statement about what the client
does wrt display to the user (in particular, I think a sensible GUI may
well chose the DAV:displayname over the segment name as the value to display
to the user).

The second is a protocol issue, namely, does a client assume it can use
the DAV:displayname as an "alternative segment name" to identify the
resource
(i.e. it can use that display name to compose a URL for that resource).
This is blatantly wrong.  I assumed Julian was encountering the latter
situation, and that is what I agreed with disallowing ... Julian?

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:ccjason@us.ibm.com]
Sent: Sunday, April 21, 2002 5:05 PM
To: Clemm, Geoff
Cc: WebDAV
Subject: RE: displayname vs. Microsoft webfolders



Actually, I tend to be of the other camp.  I feel the spec should avoid UI
imperatives if possible, the spec is clear enough about what the possible
negative repercusions of this UI approach are, and if a client wants to
experiment at the UI level, let them... as long as they comply at the
protocol level.  (I assume Msft complies at the protocol level, but I
haven't verified that.)

I don't feel strongly though and will go with the flow.

J

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



 

                      "Clemm, Geoff"

                      <gclemm@Rational.        To:       WebDAV
<w3c-dist-auth@w3.org>                                                 
                      Com>                     cc:

                      Sent by:                 Subject:  RE: displayname vs.
Microsoft webfolders                                      
                      w3c-dist-auth-req

                      uest@w3.org

 

 

                      04/21/2002 12:22

                      PM

 

 




I agree.

Cheers,
Geoff

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

we just noticed the following bug in Microsoft's web folder implementation:
when displaying the contents of a collection, it will use (when present)
the
DAV:displayname property as internal member name. Furthermore, the URI
displayed in the "tabular view" will use the collection's URI + the
displayname to build the member's URI.

This is obviously wrong, because there's no guarantee that the individual
DAV.displayname values in a property are distinct.

IMHO, the RFC2518 revision should say:

"User agents MUST not use the DAV:displayname to identify the individual
collection members (because the value may not be unique across the members
of a collection). However, they MAY use it to display additional
information
about a collection member".








From w3c-dist-auth-request@w3.org  Sun Apr 21 20:41:35 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03440
	for <webdav-archive@odin.ietf.org>; Sun, 21 Apr 2002 20:41:35 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 1D28722CBE; Sun, 21 Apr 2002 19:41:35 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA16970;
	Sun, 21 Apr 2002 20:41:26 -0400 (EDT)
Resent-Date: Sun, 21 Apr 2002 20:41:26 -0400 (EDT)
Resent-Message-Id: <200204220041.UAA16970@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA16932
	for <w3c-dist-auth@www19.w3.org>; Sun, 21 Apr 2002 20:41:21 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA13813
	for <w3c-dist-auth@w3.org>; Sun, 21 Apr 2002 20:41:20 -0400
Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Sun, 21 Apr 2002 20:37:18 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19)
	id <26NA71AR>; Sun, 21 Apr 2002 20:40:49 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1069795D2@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: WebDAV <w3c-dist-auth@w3.org>
Date: Sun, 21 Apr 2002 20:40:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: RE: need clarification about COPY to locked resource response cod 	 	e
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6145
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>

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

   Actually, I'd prefer to change/clarify multistatus error reporting to:

   - MUST contain response elements for each source resource that wasn't
   moved/copied/deleted as specified (however keeping the current
optimization
   for 424 on ancestors)

I agree.

   - MAY contain response elements for targets that caused the failure.

That would be OK with me but I'd prefer to nest the information
about targets that caused the failure in the response element for the
source resource that wasn't moved/copied/deleted.  This is a change
from RFC 2518, but I think it is warranted.

   It might be woth thinking to also add some kind of linkage between the
two
   response elements.

I agree.  That is the purpose for nesting the information about the
targets that caused the failure in the response for the target that
was not copied.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Sun Apr 21 21:41:03 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03451
	for <webdav-archive@odin.ietf.org>; Sun, 21 Apr 2002 20:41:41 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 4ABEA22E17; Sun, 21 Apr 2002 19:41:41 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA17003;
	Sun, 21 Apr 2002 20:41:36 -0400 (EDT)
Resent-Date: Sun, 21 Apr 2002 20:41:36 -0400 (EDT)
Resent-Message-Id: <200204220041.UAA17003@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA16950
	for <w3c-dist-auth@www19.w3.org>; Sun, 21 Apr 2002 20:41:23 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id UAA13815
	for <w3c-dist-auth@w3.org>; Sun, 21 Apr 2002 20:41:23 -0400
Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Sun, 21 Apr 2002 20:37:18 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19)
	id <26NA71AS>; Sun, 21 Apr 2002 20:40:49 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1069795D1@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: Stefan Eissing <stefan.eissing@greenbytes.de>,
        "Clemm, Geoff" <gclemm@rational.com>
Cc: WebDAV <w3c-dist-auth@w3.org>
Date: Sun, 21 Apr 2002 20:40:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: RE: need clarification about COPY to locked resource response cod 	 	e
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6146
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>

   From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]

   Instead of a response plain vanilla
   HTTP/1.1 403 LOCKED

   or Julian's
   HTTP/1.1 409 CONFLICT
   <DAV:error><DAV:destination-parent-locked/></DAV:error>

   I would prefer
   HTTP/1.1 207 MultiStatus
   <DAV:multistatus>
      <DAV:response><DAV:href>http://host/destination/parent</DAV:href>
      <DAV:status>HTTP/1.1 403 LOCKED</DAV:status>
      </DAV:response>
      ...
   </DAV:multistatus>

   The problem with this is that for COPY/MOVE, a server would have to
   list all non-copied resources as well in the multistatus. Something
   to be avoided when a precondition for a operation failed.

Section 8.8.3 of RFC 2518 has "error minimization rules" that
require/encourage a server to only return the error once for
a given lock.  So only one such error message would be included.

   So, the best of both worlds would maybe be:
   HTTP/1.1 403 LOCKED
   <DAV:error>
      <DAV:href>http://host/destination/parent</DAV:href>
      <DAV:status>HTTP/1.1 403 LOCKED</DAV:status>
   </DAV:error>

I don't think this degree of divergence from RFC 2518 is warranted/required.
The error minimization rules handle this case reasonably well.

Note: I am neutral as to whether the server returns a 423 LOCKED or a
409 CONFLICT in case an error token is being returned by the server.
One can make reasonable arguments for either behavior (but I
personally would do the latter, i.e. 409 CONLICT).

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Mon Apr 22 03:23:08 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18269
	for <webdav-archive@odin.ietf.org>; Mon, 22 Apr 2002 03:23:07 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id BB2B322D39; Mon, 22 Apr 2002 02:23:09 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id DAA19914;
	Mon, 22 Apr 2002 03:22:57 -0400 (EDT)
Resent-Date: Mon, 22 Apr 2002 03:22:57 -0400 (EDT)
Resent-Message-Id: <200204220722.DAA19914@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA19891
	for <w3c-dist-auth@www19.w3.org>; Mon, 22 Apr 2002 03:22:43 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA00588
	for <w3c-dist-auth@w3.org>; Mon, 22 Apr 2002 03:22:43 -0400
Received: (qmail 24809 invoked by uid 0); 22 Apr 2002 07:22:12 -0000
Received: from p3ee2470b.dip.t-dialin.net (HELO lisa) (62.226.71.11)
  by mail.gmx.net (mp011-rz3) with SMTP; 22 Apr 2002 07:22:12 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Clemm, Geoff" <gclemm@rational.com>, "WebDAV" <w3c-dist-auth@w3.org>
Date: Mon, 22 Apr 2002 09:22:09 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCIECKEHAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1069795C0@SUS-MA1IT01>
Subject: RE: displayname vs. Microsoft webfolders
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6147
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Monday, April 22, 2002 1:00 AM
> To: WebDAV
> Subject: RE: displayname vs. Microsoft webfolders
>
>
> There are two possible issues here:
>
> The first is a UI issue, namely whether a client displays the URI segment
> (which is guaranteed to be unique) or the DAV:displayname (which is not
> guaranteed to be unique, but is likely to be more human meaningful).
> I agree with Jason that we should make no statement about what the client
> does wrt display to the user (in particular, I think a sensible GUI may
> well chose the DAV:displayname over the segment name as the value
> to display
> to the user).

MS Webfolder does that. The result being that if you rename an internal
member and then do a refresh of the window, you see the old name again
(because DAV:displayname does not change as well). I'd call this a client
problem that could have been avoided with a better description of
DAV:displayname.

> The second is a protocol issue, namely, does a client assume it can use
> the DAV:displayname as an "alternative segment name" to identify the
> resource
> (i.e. it can use that display name to compose a URL for that resource).
> This is blatantly wrong.  I assumed Julian was encountering the latter
> situation, and that is what I agreed with disallowing ... Julian?

MS Webfolder seems to *internally* keep the right URL, yet it displays the
wrong one (both as member name and in the "href" column).



From w3c-dist-auth-request@w3.org  Mon Apr 22 04:48:19 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19385
	for <webdav-archive@odin.ietf.org>; Mon, 22 Apr 2002 04:48:18 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id C4DBF22BE9; Mon, 22 Apr 2002 03:48:21 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id EAA26392;
	Mon, 22 Apr 2002 04:06:43 -0400 (EDT)
Resent-Date: Mon, 22 Apr 2002 04:06:43 -0400 (EDT)
Resent-Message-Id: <200204220806.EAA26392@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA26222
	for <w3c-dist-auth@www19.w3.org>; Mon, 22 Apr 2002 04:06:25 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA06243
	for <w3c-dist-auth@w3.org>; Mon, 22 Apr 2002 04:06:24 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3.org>; Mon, 22 Apr 2002 10:05:39 +0200
Date: Mon, 22 Apr 2002 10:05:43 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
From: Stefan Eissing <stefan.eissing@greenbytes.de>
To: WebDAV <w3c-dist-auth@w3.org>
Content-Transfer-Encoding: 7bit
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1069795D2@SUS-MA1IT01>
Message-Id: <BE1F0AFE-55C7-11D6-9959-00039384827E@greenbytes.de>
X-Mailer: Apple Mail (2.481)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3.org
Subject: Re: need clarification about COPY to locked resource response cod 	 	e
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6148
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


Am Montag den, 22. April 2002, um 02:40, schrieb Clemm, Geoff:

>    From: Julian Reschke [mailto:julian.reschke@gmx.de]
>
[...]
>    - MAY contain response elements for targets that caused the failure.
>
> That would be OK with me but I'd prefer to nest the information
> about targets that caused the failure in the response element for the
> source resource that wasn't moved/copied/deleted.  This is a change
> from RFC 2518, but I think it is warranted.
>
>    It might be woth thinking to also add some kind of linkage 
> between the
> two
>    response elements.
>
> I agree.  That is the purpose for nesting the information about the
> targets that caused the failure in the response for the target that
> was not copied.

So, as usual I propose a format which will make everyone scream and
come up with a much better one.

...
<D:response>
   <D:href>/bla/...</D:href>
   <D:status>HTTP/1.1 409 CONFLICT</D:status>
   <D:cause>
     <D:href>/other/...</D:href>
     <D:status>HTTP/1.1 423 LOCKED</D:status>
   </D:cause>
</D:response>

//Stefan




From w3c-dist-auth-request@w3.org  Mon Apr 22 08:55:15 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24058
	for <webdav-archive@lists.ietf.org>; Mon, 22 Apr 2002 08:55:14 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id EACF822F58; Mon, 22 Apr 2002 07:55:16 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id IAA14586;
	Mon, 22 Apr 2002 08:55:00 -0400 (EDT)
Resent-Date: Mon, 22 Apr 2002 08:55:00 -0400 (EDT)
Resent-Message-Id: <200204221255.IAA14586@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA14556
	for <w3c-dist-auth@www19.w3.org>; Mon, 22 Apr 2002 08:54:55 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA20560
	for <w3c-dist-auth@w3.org>; Mon, 22 Apr 2002 08:54:55 -0400
Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Mon, 22 Apr 2002 08:50:51 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19)
	id <26NA7STF>; Mon, 22 Apr 2002 08:54:23 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B106979645@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: WebDAV <w3c-dist-auth@w3.org>
Date: Mon, 22 Apr 2002 08:54:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: RE: need clarification about COPY to locked resource response cod 	 	 	e
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6149
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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'd just do:
...
<D:response>
   <D:href>/bla/...</D:href>
   <D:status>HTTP/1.1 409 CONFLICT</D:status>
   <D:responsedescription>
     <D:error>
        <D:locked-source>
          <D:href>/other/...</D:href>
        </D:locked-source>
     </D:error>
   </D:responsedescription>
</D:response>

This is assuming the MOVE failed because the source was locked.
If it failed because the destination was locked, then it would
just be:

...
<D:response>
   <D:href>/bla/...</D:href>
   <D:status>HTTP/1.1 423 LOCKED</D:status>
</D:response>

Cheers,
Geoff

-----Original Message-----
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
Sent: Monday, April 22, 2002 4:06 AM
To: WebDAV
Subject: Re: need clarification about COPY to locked resource response
cod e



Am Montag den, 22. April 2002, um 02:40, schrieb Clemm, Geoff:

>    From: Julian Reschke [mailto:julian.reschke@gmx.de]
>
[...]
>    - MAY contain response elements for targets that caused the failure.
>
> That would be OK with me but I'd prefer to nest the information
> about targets that caused the failure in the response element for the
> source resource that wasn't moved/copied/deleted.  This is a change
> from RFC 2518, but I think it is warranted.
>
>    It might be woth thinking to also add some kind of linkage 
> between the
> two
>    response elements.
>
> I agree.  That is the purpose for nesting the information about the
> targets that caused the failure in the response for the target that
> was not copied.

So, as usual I propose a format which will make everyone scream and
come up with a much better one.

...
<D:response>
   <D:href>/bla/...</D:href>
   <D:status>HTTP/1.1 409 CONFLICT</D:status>
   <D:cause>
     <D:href>/other/...</D:href>
     <D:status>HTTP/1.1 423 LOCKED</D:status>
   </D:cause>
</D:response>

//Stefan



From w3c-dist-auth-request@w3.org  Mon Apr 22 08:59:51 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24140
	for <webdav-archive@lists.ietf.org>; Mon, 22 Apr 2002 08:59:51 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 9C5C222EC9; Mon, 22 Apr 2002 07:59:53 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id IAA15741;
	Mon, 22 Apr 2002 08:59:50 -0400 (EDT)
Resent-Date: Mon, 22 Apr 2002 08:59:50 -0400 (EDT)
Resent-Message-Id: <200204221259.IAA15741@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA15709
	for <w3c-dist-auth@www19.w3.org>; Mon, 22 Apr 2002 08:59:46 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA21693
	for <w3c-dist-auth@w3.org>; Mon, 22 Apr 2002 08:59:45 -0400
Received: (qmail 8298 invoked by uid 0); 22 Apr 2002 12:59:31 -0000
Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10)
  by mail.gmx.net (mp002-rz3) with SMTP; 22 Apr 2002 12:59:31 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Clemm, Geoff" <gclemm@rational.com>, "WebDAV" <w3c-dist-auth@w3.org>
Date: Mon, 22 Apr 2002 14:59:30 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCIEDEEHAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B106979645@SUS-MA1IT01>
Subject: RE: need clarification about COPY to locked resource response cod 	 	 	e
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6150
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit

Geoff,

I think it sould be the other way around:

- when the source was locked, just report 423 on the source,

- when the source wasn't copied because it's destination was locked, report
409 for the source and throw in a pointer to the locked destination.

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Monday, April 22, 2002 2:54 PM
> To: WebDAV
> Subject: RE: need clarification about COPY to locked resource response
> cod e
>
>
> I'd just do:
> ...
> <D:response>
>    <D:href>/bla/...</D:href>
>    <D:status>HTTP/1.1 409 CONFLICT</D:status>
>    <D:responsedescription>
>      <D:error>
>         <D:locked-source>
>           <D:href>/other/...</D:href>
>         </D:locked-source>
>      </D:error>
>    </D:responsedescription>
> </D:response>
>
> This is assuming the MOVE failed because the source was locked.
> If it failed because the destination was locked, then it would
> just be:
>
> ...
> <D:response>
>    <D:href>/bla/...</D:href>
>    <D:status>HTTP/1.1 423 LOCKED</D:status>
> </D:response>
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
> Sent: Monday, April 22, 2002 4:06 AM
> To: WebDAV
> Subject: Re: need clarification about COPY to locked resource response
> cod e
>
>
>
> Am Montag den, 22. April 2002, um 02:40, schrieb Clemm, Geoff:
>
> >    From: Julian Reschke [mailto:julian.reschke@gmx.de]
> >
> [...]
> >    - MAY contain response elements for targets that caused the failure.
> >
> > That would be OK with me but I'd prefer to nest the information
> > about targets that caused the failure in the response element for the
> > source resource that wasn't moved/copied/deleted.  This is a change
> > from RFC 2518, but I think it is warranted.
> >
> >    It might be woth thinking to also add some kind of linkage
> > between the
> > two
> >    response elements.
> >
> > I agree.  That is the purpose for nesting the information about the
> > targets that caused the failure in the response for the target that
> > was not copied.
>
> So, as usual I propose a format which will make everyone scream and
> come up with a much better one.
>
> ...
> <D:response>
>    <D:href>/bla/...</D:href>
>    <D:status>HTTP/1.1 409 CONFLICT</D:status>
>    <D:cause>
>      <D:href>/other/...</D:href>
>      <D:status>HTTP/1.1 423 LOCKED</D:status>
>    </D:cause>
> </D:response>
>
> //Stefan
>



From w3c-dist-auth-request@w3.org  Mon Apr 22 09:16:00 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24669
	for <webdav-archive@lists.ietf.org>; Mon, 22 Apr 2002 09:16:00 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 5C00022F32; Mon, 22 Apr 2002 08:16:02 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id JAA19260;
	Mon, 22 Apr 2002 09:15:52 -0400 (EDT)
Resent-Date: Mon, 22 Apr 2002 09:15:52 -0400 (EDT)
Resent-Message-Id: <200204221315.JAA19260@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA19092
	for <w3c-dist-auth@www19.w3.org>; Mon, 22 Apr 2002 09:15:31 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA26146
	for <w3c-dist-auth@w3.org>; Mon, 22 Apr 2002 09:15:32 -0400
Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Mon, 22 Apr 2002 09:11:28 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19)
	id <26NA7TJK>; Mon, 22 Apr 2002 09:15:00 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B106979660@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: WebDAV <w3c-dist-auth@w3.org>
Date: Mon, 22 Apr 2002 09:14:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: need clarification about COPY to locked resource response cod 	e
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6151
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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, that was what I meant ... even though I know
that COPY is applied to the object that is not being changed, and
has a header identifying the object that is being changed,
my subconscious keeps wanting it to be the other way (:-).

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Monday, April 22, 2002 9:00 AM
To: Clemm, Geoff; WebDAV
Subject: RE: need clarification about COPY to locked resource response
cod e


Geoff,

I think it sould be the other way around:

- when the source was locked, just report 423 on the source,

- when the source wasn't copied because it's destination was locked, report
409 for the source and throw in a pointer to the locked destination.

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Monday, April 22, 2002 2:54 PM
> To: WebDAV
> Subject: RE: need clarification about COPY to locked resource response
> cod e
>
>
> I'd just do:
> ...
> <D:response>
>    <D:href>/bla/...</D:href>
>    <D:status>HTTP/1.1 409 CONFLICT</D:status>
>    <D:responsedescription>
>      <D:error>
>         <D:locked-source>
>           <D:href>/other/...</D:href>
>         </D:locked-source>
>      </D:error>
>    </D:responsedescription>
> </D:response>
>
> This is assuming the MOVE failed because the source was locked.
> If it failed because the destination was locked, then it would
> just be:
>
> ...
> <D:response>
>    <D:href>/bla/...</D:href>
>    <D:status>HTTP/1.1 423 LOCKED</D:status>
> </D:response>
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
> Sent: Monday, April 22, 2002 4:06 AM
> To: WebDAV
> Subject: Re: need clarification about COPY to locked resource response
> cod e
>
>
>
> Am Montag den, 22. April 2002, um 02:40, schrieb Clemm, Geoff:
>
> >    From: Julian Reschke [mailto:julian.reschke@gmx.de]
> >
> [...]
> >    - MAY contain response elements for targets that caused the failure.
> >
> > That would be OK with me but I'd prefer to nest the information
> > about targets that caused the failure in the response element for the
> > source resource that wasn't moved/copied/deleted.  This is a change
> > from RFC 2518, but I think it is warranted.
> >
> >    It might be woth thinking to also add some kind of linkage
> > between the
> > two
> >    response elements.
> >
> > I agree.  That is the purpose for nesting the information about the
> > targets that caused the failure in the response for the target that
> > was not copied.
>
> So, as usual I propose a format which will make everyone scream and
> come up with a much better one.
>
> ...
> <D:response>
>    <D:href>/bla/...</D:href>
>    <D:status>HTTP/1.1 409 CONFLICT</D:status>
>    <D:cause>
>      <D:href>/other/...</D:href>
>      <D:status>HTTP/1.1 423 LOCKED</D:status>
>    </D:cause>
> </D:response>
>
> //Stefan
>



From w3c-dist-auth-request@w3.org  Mon Apr 22 12:36:14 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01620
	for <webdav-archive@odin.ietf.org>; Mon, 22 Apr 2002 12:36:14 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 6C46622B4A; Mon, 22 Apr 2002 11:36:09 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA18129;
	Mon, 22 Apr 2002 12:36:02 -0400 (EDT)
Resent-Date: Mon, 22 Apr 2002 12:36:02 -0400 (EDT)
Resent-Message-Id: <200204221636.MAA18129@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA18066
	for <w3c-dist-auth@www19.w3.org>; Mon, 22 Apr 2002 12:35:52 -0400 (EDT)
Received: from LIILMTLSSM01.mailtask.com (liilmtlssm01.mailtask.com [208.203.59.25])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA12349
	for <w3c-dist-auth@w3c.org>; Mon, 22 Apr 2002 12:35:51 -0400
Received: from LIILMTLSFE02.mailtask.com ([208.203.59.43]) by LIILMTLSSM01.mailtask.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Mon, 22 Apr 2002 11:35:09 -0500
Received: from moose ([216.36.77.241]) by LIILMTLSFE02.mailtask.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 22 Apr 2002 11:35:11 -0500
From: "Lisa Dusseault" <ldusseault@xythos.com>
To: "Webdav WG (E-mail)" <w3c-dist-auth@w3c.org>
Date: Mon, 22 Apr 2002 09:36:03 -0700
Message-ID: <001101c1ea1b$cb09acb0$f8cb90c6@moose>
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 CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
X-OriginalArrivalTime: 22 Apr 2002 16:35:11.0300 (UTC) FILETIME=[ABF41040:01C1EA1B]
Subject: 54th IETF Meeting Information, and RFC2518 open issues
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6152
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit

If you're not on the IETF-Announce list, you might not have seen this
announcement about the upcoming meeting in Yokohama.

To bring our "agenda" up-to-date, here's what I think the largest and
hardest issues are for RFC2518 bis:
 - Whether/how to change the If header rules and syntax
 - Whether/how to change the source property definition

Although the If header has been shown to be interoperable in its simplest
form with locktokens, it hasn't been shown to be interoperable in its more
advanced forms or with ETags.  The source property has not had any
demonstrated interoperability to my knowledge.

I'd like to encourage anybody with ideas on what to do with either of these
two features to make concrete proposals to the list.  If your proposal is
"leave things the way they are", I'd like to see some discussion on how to
meet the requirements for going to proposed standard (how to demonstrate
interoperability, and how much interoperability is enough).

Another ACL draft is expected before the Yokohama cut-off, therefore ACLs
will probably also be discussed in Yokohama.  I'll be asking for a meeting
slot.

Lisa

-----Original Message-----
From: dinaras@cnri.reston.va.us [mailto:dinaras@cnri.reston.va.us]On
Behalf Of ietf-secretariat@ietf.org
Sent: Thursday, April 18, 2002 8:42 AM
To: IETF-Announce:
Subject: 54th IETF Meeting Information


Registration for the 54th IETF is now open.
Information can be found on the IETF web site at:
http://www.ietf.org/meetings/IETF-54.html

MEETING SITE:
Pacifico Yokohama Convention Center
1-1-1 Minato Mirai, Nishi-ku, Yokohama 220-0012 Japan
Tel: + 81 (45) 221-2112
Fax: + 81 (45) 221-2136

HOTEL ACCOMMODATIONS:
Information is available on
http://www.e-side.co.jp/ietf54/accommodation.html.
Please be advised that ONLINE RESERVATIONS will be available after April
22nd.



From w3c-dist-auth-request@w3.org  Mon Apr 22 12:54:20 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02298
	for <webdav-archive@odin.ietf.org>; Mon, 22 Apr 2002 12:54:08 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 59E5622EF0; Mon, 22 Apr 2002 11:54:07 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA21215;
	Mon, 22 Apr 2002 12:54:03 -0400 (EDT)
Resent-Date: Mon, 22 Apr 2002 12:54:03 -0400 (EDT)
Resent-Message-Id: <200204221654.MAA21215@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA21189
	for <w3c-dist-auth@www19.w3.org>; Mon, 22 Apr 2002 12:53:57 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA15742
	for <w3c-dist-auth@w3c.org>; Mon, 22 Apr 2002 12:53:56 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3c.org>; Mon, 22 Apr 2002 18:53:35 +0200
Date: Mon, 22 Apr 2002 18:53:34 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
Cc: "Webdav WG (E-mail)" <w3c-dist-auth@w3c.org>
To: "Lisa Dusseault" <ldusseault@xythos.com>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <001101c1ea1b$cb09acb0$f8cb90c6@moose>
Message-Id: <7BBFC815-5611-11D6-9959-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.481)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: 54th IETF Meeting Information, and RFC2518 open issues
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6153
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


Am Montag den, 22. April 2002, um 18:36, schrieb Lisa Dusseault:

> [...]
>
> To bring our "agenda" up-to-date, here's what I think the largest and
> hardest issues are for RFC2518 bis:
>  - Whether/how to change the If header rules and syntax
>  - Whether/how to change the source property definition
>
> Although the If header has been shown to be interoperable in its 
> simplest
> form with locktokens, it hasn't been shown to be interoperable in 
> its more
> advanced forms or with ETags.  The source property has not had any
> demonstrated interoperability to my knowledge.

If headers with ETags do not add any value to the protocol. For
GET rfc2616 already defines If-Match and friends. Since the ETag
only captures content changes (property changes have undefined
effect on ETags), IF headers for ETag lack a use case.

Having never encountered a client using them, I propose to
drop ETags in IF headers.

The remaining "more advanced" features of IF I can think of are:
- not
- use of URIs with locktokens

URIs with locktokens are in use by us (both server and client).

Does anyone have a use case for "Not"?

//Stefan




From w3c-dist-auth-request@w3.org  Mon Apr 22 14:02:00 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05566
	for <webdav-archive@odin.ietf.org>; Mon, 22 Apr 2002 14:01:59 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 1F7A12301A; Mon, 22 Apr 2002 13:02:01 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA01007;
	Mon, 22 Apr 2002 14:01:29 -0400 (EDT)
Resent-Date: Mon, 22 Apr 2002 14:01:29 -0400 (EDT)
Resent-Message-Id: <200204221801.OAA01007@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA00980
	for <w3c-dist-auth@www19.w3.org>; Mon, 22 Apr 2002 14:01:23 -0400 (EDT)
Received: from LIILMTLSSM01.mailtask.com (liilmtlssm01.mailtask.com [208.203.59.25])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA27322
	for <w3c-dist-auth@w3c.org>; Mon, 22 Apr 2002 14:01:23 -0400
Received: from LIILMTLSFE02.mailtask.com ([208.203.59.43]) by LIILMTLSSM01.mailtask.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Mon, 22 Apr 2002 13:00:52 -0500
Received: from moose ([216.36.77.241]) by LIILMTLSFE02.mailtask.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 22 Apr 2002 13:00:52 -0500
From: "Lisa Dusseault" <ldusseault@xythos.com>
To: "'Stefan Eissing'" <stefan.eissing@greenbytes.de>
Cc: "'Webdav WG (E-mail)'" <w3c-dist-auth@w3c.org>
Date: Mon, 22 Apr 2002 11:01:42 -0700
Message-ID: <005401c1ea27$c300fad0$f8cb90c6@moose>
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 CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <7BBFC815-5611-11D6-9959-00039384827E@greenbytes.de>
X-OriginalArrivalTime: 22 Apr 2002 18:00:52.0835 (UTC) FILETIME=[A48C0B30:01C1EA27]
Subject: RE: 54th IETF Meeting Information, and RFC2518 open issues
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6154
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit

> Having never encountered a client using them, I propose to
> drop ETags in IF headers.

OK; if we drop ETags in If headers how are servers intended to handle
requests using the old syntax, or do you believe that is not an issue (if
so, why)?

lisa



From w3c-dist-auth-request@w3.org  Tue Apr 23 04:06:47 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08884
	for <webdav-archive@odin.ietf.org>; Tue, 23 Apr 2002 04:06:46 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id C4E4822F91; Tue, 23 Apr 2002 03:06:49 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id EAA13633;
	Tue, 23 Apr 2002 04:06:34 -0400 (EDT)
Resent-Date: Tue, 23 Apr 2002 04:06:34 -0400 (EDT)
Resent-Message-Id: <200204230806.EAA13633@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA13609
	for <w3c-dist-auth@www19.w3.org>; Tue, 23 Apr 2002 04:06:24 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA24873
	for <w3c-dist-auth@w3c.org>; Tue, 23 Apr 2002 04:06:24 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3c.org>; Tue, 23 Apr 2002 10:06:04 +0200
Date: Tue, 23 Apr 2002 10:06:08 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
Cc: "'Webdav WG (E-mail)'" <w3c-dist-auth@w3c.org>
To: "Lisa Dusseault" <ldusseault@xythos.com>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <005401c1ea27$c300fad0$f8cb90c6@moose>
Message-Id: <F7881661-5690-11D6-9959-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.481)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: 54th IETF Meeting Information, and RFC2518 open issues
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6155
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


Am Montag den, 22. April 2002, um 20:01, schrieb Lisa Dusseault:

>> Having never encountered a client using them, I propose to
>> drop ETags in IF headers.
>
> OK; if we drop ETags in If headers how are servers intended to handle
> requests using the old syntax, or do you believe that is not an 
> issue (if
> so, why)?

We can handle this similar to the "keepalive" body for COPY requests.

Do we know a client using IF headers with ETags? If it is a feature
not used by anyone, it has not proven interoperability and we should
change/discard it.

If we discover that it is used, or if someone can explain the use
case and benefits, that is a completely different matter.

Our server is able to handle the current IF header syntax, so I
have no problem with the current specification. I just think that
cutting away unused features will increase interoperable
implementations.

//Stefan




From w3c-dist-auth-request@w3.org  Tue Apr 23 20:55:55 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10677
	for <webdav-archive@lists.ietf.org>; Tue, 23 Apr 2002 20:55:54 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id D9E4222D65; Tue, 23 Apr 2002 19:55:57 -0500 (EST)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA02037;
	Tue, 23 Apr 2002 20:55:38 -0400 (EDT)
Resent-Date: Tue, 23 Apr 2002 20:55:38 -0400 (EDT)
Resent-Message-Id: <200204240055.UAA02037@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA02003
	for <w3c-dist-auth@www19.w3.org>; Tue, 23 Apr 2002 20:55:26 -0400 (EDT)
Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA08662
	for <w3c-dist-auth@w3.org>; Tue, 23 Apr 2002 20:55:26 -0400
Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177])
          by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP
	  id RAA10492 for <w3c-dist-auth@w3.org>; Tue, 23 Apr 2002 17:55:13 -0700 (PDT)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "WebDAV" <w3c-dist-auth@w3.org>
Date: Tue, 23 Apr 2002 17:54:59 -0700
Message-ID: <AMEPKEBLDJJCCDEJHAMIAEKJEKAA.ejw@cse.ucsc.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0016_01C1EAEF.FC3464E0"
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
Subject: FW: Webdav through Internet Caching System
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6156
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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_0016_01C1EAEF.FC3464E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Webdav through Internet Caching SystemAccidentally caught by the spam
filter.

- Jim
-----Original Message-----
From: Clive Redington [mailto:Clive.Redington@westking.ac.uk]
Sent: Tuesday, April 23, 2002 4:40 AM
To: w3c-dist-auth@w3.org
Subject: [Moderator Action] Webdav through Internet Caching System


Good afternoon

I was reading your interesting article on webdav.org regarding various
caches/proxies that support webdav. Do you have any more info on whether
Novell's Internet Caching System is webdav compliant? I have not been able
to find anything about this on the web.

Many thanks.

Clive Redington

Network Administrator



Clive Redington

Network Administrator


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Webdav through Internet Caching System</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3207.2500" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D245445400-24042002>Accidentally caught by the spam=20
filter.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D245445400-24042002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D245445400-24042002>-=20
Jim</SPAN></FONT></DIV>
<DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> Clive Redington=20
[mailto:Clive.Redington@westking.ac.uk]<BR><B>Sent:</B> Tuesday, April =
23, 2002=20
4:40 AM<BR><B>To:</B> w3c-dist-auth@w3.org<BR><B>Subject:</B> [Moderator =
Action]=20
Webdav through Internet Caching System<BR><BR></FONT></DIV><!-- =
Converted from text/rtf format -->
<P><FONT face=3DArial size=3D2>Good afternoon</FONT> </P>
<P><FONT face=3DArial size=3D2>I was reading your interesting article on =
webdav.org=20
regarding various caches/proxies that support webdav. Do you have any =
more info=20
on whether Novell's Internet Caching System is webdav compliant? I have =
not been=20
able to find anything about this on the web.</FONT></P>
<P><FONT face=3DArial size=3D2>Many thanks. </FONT></P>
<P><FONT face=3DArial size=3D2>Clive Redington</FONT> </P>
<P><FONT face=3DArial size=3D2>Network Administrator</FONT> </P><BR>
<P><FONT face=3DArial size=3D2>Clive Redington</FONT> </P>
<P><FONT face=3DArial size=3D2>Network Administrator</FONT> =
</P></BODY></HTML>

------=_NextPart_000_0016_01C1EAEF.FC3464E0--



From w3c-dist-auth-request@w3.org  Thu Apr 25 02:39:27 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27741
	for <webdav-archive@lists.ietf.org>; Thu, 25 Apr 2002 02:39:26 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 902D022F69; Thu, 25 Apr 2002 02:39:28 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id CAA00948;
	Thu, 25 Apr 2002 02:38:45 -0400 (EDT)
Resent-Date: Thu, 25 Apr 2002 02:38:45 -0400 (EDT)
Resent-Message-Id: <200204250638.CAA00948@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA00928
	for <w3c-dist-auth@www19.w3.org>; Thu, 25 Apr 2002 02:38:38 -0400 (EDT)
Received: from kurgan.lyra.org (kurgan.lyra.org [198.144.203.198])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA16657
	for <w3c-dist-auth@w3c.org>; Thu, 25 Apr 2002 02:38:37 -0400
Received: (from gstein@localhost)
	by kurgan.lyra.org (8.9.3/8.9.3) id XAA06139
	for w3c-dist-auth@w3c.org; Wed, 24 Apr 2002 23:39:45 -0700
X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f
Date: Wed, 24 Apr 2002 23:39:45 -0700
From: Greg Stein <gstein@lyra.org>
To: "Webdav WG (E-mail)" <w3c-dist-auth@w3c.org>
Message-ID: <20020424233944.A6025@lyra.org>
Mail-Followup-To: "Webdav WG (E-mail)" <w3c-dist-auth@w3c.org>
References: <001101c1ea1b$cb09acb0$f8cb90c6@moose> <7BBFC815-5611-11D6-9959-00039384827E@greenbytes.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <7BBFC815-5611-11D6-9959-00039384827E@greenbytes.de>; from stefan.eissing@greenbytes.de on Mon, Apr 22, 2002 at 06:53:34PM +0200
X-URL: http://www.lyra.org/greg/
Subject: etags in If: headers (was: 54th IETF Meeting Information, and RFC2518 open issues)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6157
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>

On Mon, Apr 22, 2002 at 06:53:34PM +0200, Stefan Eissing wrote:
> Am Montag den, 22. April 2002, um 18:36, schrieb Lisa Dusseault:
>...
> If headers with ETags do not add any value to the protocol. For
> GET rfc2616 already defines If-Match and friends. Since the ETag
> only captures content changes (property changes have undefined
> effect on ETags), IF headers for ETag lack a use case.

An etag in an If: header can be used to assert that a file has been
unchanged since you last fetched it. Specifically, that you still have the
locktoken *or* (you lost it and) it is unchanged.

This is to cover the case where lock a file, fetch it, and then attempt to
PUT the file back. The PUT should succeed if you have the locktoken *or* if
you lost your lock but the etag matches what you GET'd (thus: nobody else
changed it).

Arguably, the semantic could be manufactured with other combinations, but
I'd suggest that is your use case.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From w3c-dist-auth-request@w3.org  Thu Apr 25 02:40:57 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27782
	for <webdav-archive@lists.ietf.org>; Thu, 25 Apr 2002 02:40:57 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 51C9623040; Thu, 25 Apr 2002 02:40:59 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id CAA01221;
	Thu, 25 Apr 2002 02:40:55 -0400 (EDT)
Resent-Date: Thu, 25 Apr 2002 02:40:55 -0400 (EDT)
Resent-Message-Id: <200204250640.CAA01221@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA01197
	for <w3c-dist-auth@www19.w3.org>; Thu, 25 Apr 2002 02:40:43 -0400 (EDT)
Received: from kurgan.lyra.org (kurgan.lyra.org [198.144.203.198])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA16840
	for <w3c-dist-auth@w3c.org>; Thu, 25 Apr 2002 02:40:43 -0400
Received: (from gstein@localhost)
	by kurgan.lyra.org (8.9.3/8.9.3) id XAA06148
	for w3c-dist-auth@w3c.org; Wed, 24 Apr 2002 23:41:51 -0700
X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f
Date: Wed, 24 Apr 2002 23:41:51 -0700
From: Greg Stein <gstein@lyra.org>
To: "'Webdav WG (E-mail)'" <w3c-dist-auth@w3c.org>
Message-ID: <20020424234150.B6025@lyra.org>
Mail-Followup-To: "'Webdav WG (E-mail)'" <w3c-dist-auth@w3c.org>
References: <005401c1ea27$c300fad0$f8cb90c6@moose> <F7881661-5690-11D6-9959-00039384827E@greenbytes.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <F7881661-5690-11D6-9959-00039384827E@greenbytes.de>; from stefan.eissing@greenbytes.de on Tue, Apr 23, 2002 at 10:06:08AM +0200
X-URL: http://www.lyra.org/greg/
Subject: Re: 54th IETF Meeting Information, and RFC2518 open issues
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6158
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>

On Tue, Apr 23, 2002 at 10:06:08AM +0200, Stefan Eissing wrote:
>...
> Our server is able to handle the current IF header syntax, so I
> have no problem with the current specification. I just think that
> cutting away unused features will increase interoperable
> implementations.

Same here.

mod_dav handles the current If: header specification (entirely), so no skin
off my back to keep the current spec. However, it is some nasty code that
I'd just as soon remove.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From w3c-dist-auth-request@w3.org  Thu Apr 25 03:40:20 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28441
	for <webdav-archive@odin.ietf.org>; Thu, 25 Apr 2002 03:40:20 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 969C522F22; Thu, 25 Apr 2002 03:40:22 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id DAA07548;
	Thu, 25 Apr 2002 03:40:15 -0400 (EDT)
Resent-Date: Thu, 25 Apr 2002 03:40:15 -0400 (EDT)
Resent-Message-Id: <200204250740.DAA07548@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA07527
	for <w3c-dist-auth@www19.w3.org>; Thu, 25 Apr 2002 03:40:06 -0400 (EDT)
Received: from tarantula.inria.fr (daemon@tarantula.inria.fr [138.96.10.3])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA22278
	for <w3c-dist-auth@w3c.org>; Thu, 25 Apr 2002 03:20:38 -0400
Received: by tarantula.inria.fr (8.11.6/8.10.0) id g3P7KUP09169; Thu, 25 Apr 2002 09:20:30 +0200 (MET DST)
Date: Thu, 25 Apr 2002 09:20:29 +0200 (MET DST)
From: Yves Lafon <ylafon@w3.org>
X-X-Sender: ylafon@tarantula.inria.fr
To: Greg Stein <gstein@lyra.org>
Cc: "Webdav WG (E-mail)" <w3c-dist-auth@w3c.org>
In-Reply-To: <20020424233944.A6025@lyra.org>
Message-ID: <Pine.GSO.4.44.0204250912270.6474-100000@tarantula.inria.fr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: etags in If: headers (was: 54th IETF Meeting Information, and  RFC2518 open issues)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6159
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>

On Wed, 24 Apr 2002, Greg Stein wrote:

> On Mon, Apr 22, 2002 at 06:53:34PM +0200, Stefan Eissing wrote:
> > Am Montag den, 22. April 2002, um 18:36, schrieb Lisa Dusseault:
> >...
> > If headers with ETags do not add any value to the protocol. For
> > GET rfc2616 already defines If-Match and friends. Since the ETag
> > only captures content changes (property changes have undefined
> > effect on ETags), IF headers for ETag lack a use case.
>
> An etag in an If: header can be used to assert that a file has been
> unchanged since you last fetched it. Specifically, that you still have the
> locktoken *or* (you lost it and) it is unchanged.

You can also see the following note on this subject:
http://www.w3.org/1999/04/Editing/
Thanks,

-- 
Yves Lafon - W3C



From w3c-dist-auth-request@w3.org  Thu Apr 25 04:18:50 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29104
	for <webdav-archive@odin.ietf.org>; Thu, 25 Apr 2002 04:18:50 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 53FE122F69; Thu, 25 Apr 2002 04:18:52 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id EAA11199;
	Thu, 25 Apr 2002 04:18:48 -0400 (EDT)
Resent-Date: Thu, 25 Apr 2002 04:18:48 -0400 (EDT)
Resent-Message-Id: <200204250818.EAA11199@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA11159
	for <w3c-dist-auth@www19.w3.org>; Thu, 25 Apr 2002 04:18:34 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA29243
	for <w3c-dist-auth@w3c.org>; Thu, 25 Apr 2002 04:18:33 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3c.org>; Thu, 25 Apr 2002 10:17:33 +0200
Date: Thu, 25 Apr 2002 10:17:39 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
Cc: Greg Stein <gstein@lyra.org>, "Webdav WG (E-mail)" <w3c-dist-auth@w3c.org>
To: Yves Lafon <ylafon@w3.org>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <Pine.GSO.4.44.0204250912270.6474-100000@tarantula.inria.fr>
Message-Id: <E841E0A0-5824-11D6-9959-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.481)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: etags in If: headers (was: 54th IETF Meeting Information, and  RFC2518 open issues)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6160
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit

Yves, Greg, thanks for the link and the explanation.

So I change my mind and am in favour of keeping If: headers
functionality as they are described in 2518.

Regarding potential length of this header: would it be ok
to allow whitespace between tokens, so that the header can
be more easily split on several lines?

//Stefan

Am Donnerstag den, 25. April 2002, um 09:20, schrieb Yves Lafon:

> On Wed, 24 Apr 2002, Greg Stein wrote:
>
>> On Mon, Apr 22, 2002 at 06:53:34PM +0200, Stefan Eissing wrote:
>>> Am Montag den, 22. April 2002, um 18:36, schrieb Lisa Dusseault:
>>> ...
>>> If headers with ETags do not add any value to the protocol. For
>>> GET rfc2616 already defines If-Match and friends. Since the ETag
>>> only captures content changes (property changes have undefined
>>> effect on ETags), IF headers for ETag lack a use case.
>>
>> An etag in an If: header can be used to assert that a file has been
>> unchanged since you last fetched it. Specifically, that you still 
>> have the
>> locktoken *or* (you lost it and) it is unchanged.
>
> You can also see the following note on this subject:
> http://www.w3.org/1999/04/Editing/
> Thanks,
>
> --
> Yves Lafon - W3C
>




From w3c-dist-auth-request@w3.org  Thu Apr 25 11:38:17 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24069
	for <webdav-archive@odin.ietf.org>; Thu, 25 Apr 2002 11:38:17 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 47F8922F93; Thu, 25 Apr 2002 11:38:20 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA24627;
	Thu, 25 Apr 2002 11:38:11 -0400 (EDT)
Resent-Date: Thu, 25 Apr 2002 11:38:11 -0400 (EDT)
Resent-Message-Id: <200204251538.LAA24627@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA24525
	for <w3c-dist-auth@www19.w3.org>; Thu, 25 Apr 2002 11:37:57 -0400 (EDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA10464
	for <w3c-dist-auth@w3c.org>; Thu, 25 Apr 2002 11:37:57 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3PFbCms302660
	for <w3c-dist-auth@w3c.org>; Thu, 25 Apr 2002 11:37:12 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77])
	by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3PFbAP48318
	for <w3c-dist-auth@w3c.org>; Thu, 25 Apr 2002 11:37:10 -0400
To: w3c-dist-auth@w3c.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFE4B174EF.2C4E6AC8-ON85256BA6.00556BD3@pok.ibm.com>
From: "Jason Crawford" <ccjason@us.ibm.com>
Date: Thu, 25 Apr 2002 11:36:54 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at
 04/25/2002 11:37:09 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: Re: 54th IETF Meeting Information, and RFC2518 open issues
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6162
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


My preference is not strong, but I do agree with Geoff that we should
consider removing ETAG support from the IF: header unless someone steps
forward for a good reason to keep it.

The discussion has bounced around a bit, so I'll try to point out what
hasn't been covered.

As Geoff said... The functionality of ETags in IF: headers appear to
already be available via other means.

Stephan's question about whether any *clients* submit Etags in IF: headers
hasn't been answered.




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





From w3c-dist-auth-request@w3.org  Thu Apr 25 11:39:06 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24089
	for <webdav-archive@odin.ietf.org>; Thu, 25 Apr 2002 11:39:06 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 8C78D23050; Thu, 25 Apr 2002 11:39:09 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA24817;
	Thu, 25 Apr 2002 11:39:02 -0400 (EDT)
Resent-Date: Thu, 25 Apr 2002 11:39:02 -0400 (EDT)
Resent-Message-Id: <200204251539.LAA24817@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA24748
	for <w3c-dist-auth@www19.w3.org>; Thu, 25 Apr 2002 11:38:46 -0400 (EDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA10735
	for <w3c-dist-auth@w3c.org>; Thu, 25 Apr 2002 11:38:46 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3PFcAms464982;
	Thu, 25 Apr 2002 11:38:11 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77])
	by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3PFc8P88436;
	Thu, 25 Apr 2002 11:38:08 -0400
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: "'Webdav WG (E-mail)'" <w3c-dist-auth@w3c.org>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF1458EBEA.236CB563-ON85256BA6.005553D2@pok.ibm.com>
From: "Jason Crawford" <ccjason@us.ibm.com>
Date: Thu, 25 Apr 2002 11:38:01 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at
 04/25/2002 11:38:08 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: Re: 54th IETF Meeting Information, and RFC2518 open issues
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6163
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


> >> Having never encountered a client using them, I propose to
> >> drop ETags in IF headers.
> >
> > OK; if we drop ETags in If headers how are servers intended to handle
> > requests using the old syntax, or do you believe that is not an
> > issue (if
> > so, why)?
>
> We can handle this similar to the "keepalive" body for COPY requests.

Obviously if no clients use it, it's not a big issue, but please explain
further.


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





From w3c-dist-auth-request@w3.org  Thu Apr 25 13:16:08 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28055
	for <webdav-archive@odin.ietf.org>; Thu, 25 Apr 2002 13:16:08 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 7DE7C22F91; Thu, 25 Apr 2002 13:16:09 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA10446;
	Thu, 25 Apr 2002 13:16:00 -0400 (EDT)
Resent-Date: Thu, 25 Apr 2002 13:16:00 -0400 (EDT)
Resent-Message-Id: <200204251716.NAA10446@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA10376
	for <w3c-dist-auth@www19.w3.org>; Thu, 25 Apr 2002 13:15:39 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA03087
	for <w3c-dist-auth@w3c.org>; Thu, 25 Apr 2002 13:15:39 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3c.org>; Thu, 25 Apr 2002 19:14:42 +0200
Date: Thu, 25 Apr 2002 19:14:47 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
Cc: "'Webdav WG (E-mail)'" <w3c-dist-auth@w3c.org>
To: "Jason Crawford" <ccjason@us.ibm.com>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <OF1458EBEA.236CB563-ON85256BA6.005553D2@pok.ibm.com>
Message-Id: <F1964D20-586F-11D6-9959-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.481)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: 54th IETF Meeting Information, and RFC2518 open issues
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6164
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


Am Donnerstag den, 25. April 2002, um 17:38, schrieb Jason Crawford:

>
>>>> Having never encountered a client using them, I propose to
>>>> drop ETags in IF headers.
>>>
>>> OK; if we drop ETags in If headers how are servers intended to handle
>>> requests using the old syntax, or do you believe that is not an
>>> issue (if
>>> so, why)?
>>
>> We can handle this similar to the "keepalive" body for COPY requests.
>
> Obviously if no clients use it, it's not a big issue, but please 
> explain
> further.

As I wrote earlier today, Greg changed my mind on this matter.
There is a use case which cannot be covered by existing HTTP features.

So I'd vote for keeping the If: header as it is.

//Stefan





From w3c-dist-auth-request@w3.org  Thu Apr 25 13:40:11 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28892
	for <webdav-archive@odin.ietf.org>; Thu, 25 Apr 2002 13:40:11 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 5F42123288; Thu, 25 Apr 2002 13:36:59 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id JAA27748;
	Thu, 25 Apr 2002 09:10:58 -0400 (EDT)
Resent-Date: Thu, 25 Apr 2002 09:10:58 -0400 (EDT)
Resent-Message-Id: <200204251310.JAA27748@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA27399
	for <w3c-dist-auth@www19.w3.org>; Thu, 25 Apr 2002 09:10:09 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA28987
	for <w3c-dist-auth@w3c.org>; Thu, 25 Apr 2002 08:46:58 -0400
Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Thu, 25 Apr 2002 08:42:39 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19)
	id <26NBCBXD>; Thu, 25 Apr 2002 08:46:18 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B106979EE4@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "Webdav WG (E-mail)" <w3c-dist-auth@w3c.org>
Date: Thu, 25 Apr 2002 08:46:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: RE: etags in If: headers (was: 54th IETF Meeting Information, and 	 RFC2518 open issues)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6161
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>

I think a key point is the one Greg made at the end of this message,
namely that this use case can be achieved without allowing etags in
the If header.  In particular, you just try the PUT with the LOCK
request, and if that fails because you no longer have the lock, you
retry the PUT with the appropriate etag in an If-Match header.  I
think it is very reasonable to require an extra round trip in an
exceptional case like this (i.e. losing your lock).

So until a use case is identified that cannot be easily handled by
other machinery, I suggest we limit the If header to just lock tokens.
Cheers,
Geoff

-----Original Message-----
From: Greg Stein [mailto:gstein@lyra.org]
Sent: Thursday, April 25, 2002 2:40 AM
To: Webdav WG (E-mail)
Subject: etags in If: headers (was: 54th IETF Meeting Information, and
RFC2518 open issues)


On Mon, Apr 22, 2002 at 06:53:34PM +0200, Stefan Eissing wrote:
> Am Montag den, 22. April 2002, um 18:36, schrieb Lisa Dusseault:
>...
> If headers with ETags do not add any value to the protocol. For
> GET rfc2616 already defines If-Match and friends. Since the ETag
> only captures content changes (property changes have undefined
> effect on ETags), IF headers for ETag lack a use case.

An etag in an If: header can be used to assert that a file has been
unchanged since you last fetched it. Specifically, that you still have the
locktoken *or* (you lost it and) it is unchanged.

This is to cover the case where lock a file, fetch it, and then attempt to
PUT the file back. The PUT should succeed if you have the locktoken *or* if
you lost your lock but the etag matches what you GET'd (thus: nobody else
changed it).

Arguably, the semantic could be manufactured with other combinations, but
I'd suggest that is your use case.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



From w3c-dist-auth-request@w3.org  Thu Apr 25 13:56:57 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29512
	for <webdav-archive@odin.ietf.org>; Thu, 25 Apr 2002 13:56:57 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 23B2A232F9; Thu, 25 Apr 2002 13:54:28 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA18480;
	Thu, 25 Apr 2002 13:54:24 -0400 (EDT)
Resent-Date: Thu, 25 Apr 2002 13:54:24 -0400 (EDT)
Resent-Message-Id: <200204251754.NAA18480@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA18460
	for <w3c-dist-auth@www19.w3.org>; Thu, 25 Apr 2002 13:54:20 -0400 (EDT)
Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA10291
	for <w3c-dist-auth@w3.org>; Thu, 25 Apr 2002 13:54:20 -0400
Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177])
          by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP
	  id KAA28028 for <w3c-dist-auth@w3.org>; Thu, 25 Apr 2002 10:54:03 -0700 (PDT)
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "WebDAV" <w3c-dist-auth@w3.org>
Date: Thu, 25 Apr 2002 10:53:51 -0700
Message-ID: <AMEPKEBLDJJCCDEJHAMIOENPEKAA.ejw@cse.ucsc.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B106979EE4@SUS-MA1IT01>
Importance: Normal
Subject: RE: etags in If: headers
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6165
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit

The original rationale for including entity tags in the If header was to
make the If header a general purpose mechanism for evaluating method
preconditions (specifically, for evaluating preconditions concerning whether
the resource's state still matched the state expected by the client, where
the client's current understanding of the state is expressed using a state
token, like an Etag or a LockToken). We were reacting against the closed
design of the existing If-[None-]Match headers, which didn't allow expansion
to include other state tokens.

Our hope was that the If header would eventually replace the existing
If-[None-]Match mechanism.

One scenario that you can accomplish with the If header, and that you cannot
accomplish with other mechanisms, is to perform an operation like a MOVE on
a collection hierarchy, where the MOVE can only succeed if the client has
the right lock token and all of the resources have the Etag expected by the
client (i.e., they haven't been modified, which may be the case with shared
locks).

If the main concern about the feature is interoperability, then let's make
testing of this feature an issue at the next interoperability event, and add
a few tests concerning it to the Litmus test suite.

- Jim




From w3c-dist-auth-request@w3.org  Thu Apr 25 15:48:49 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03897
	for <webdav-archive@odin.ietf.org>; Thu, 25 Apr 2002 15:48:48 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 3CA4922FFD; Thu, 25 Apr 2002 15:48:49 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA10934;
	Thu, 25 Apr 2002 15:48:41 -0400 (EDT)
Resent-Date: Thu, 25 Apr 2002 15:48:41 -0400 (EDT)
Resent-Message-Id: <200204251948.PAA10934@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA10904
	for <w3c-dist-auth@www19.w3.org>; Thu, 25 Apr 2002 15:48:36 -0400 (EDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA06978
	for <w3c-dist-auth@w3c.org>; Thu, 25 Apr 2002 15:48:35 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3PJlpms479872;
	Thu, 25 Apr 2002 15:47:52 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77])
	by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3PJlnP91264;
	Thu, 25 Apr 2002 15:47:49 -0400
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: "'Webdav WG (E-mail)'" <w3c-dist-auth@w3c.org>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFB44E3123.3D9FC346-ON85256BA6.006AA5D0@pok.ibm.com>
From: "Jason Crawford" <ccjason@us.ibm.com>
Date: Thu, 25 Apr 2002 15:39:02 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at
 04/25/2002 03:47:48 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: Re: 54th IETF Meeting Information, and RFC2518 open issues
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6166
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


Stefan,
   Greg's posting didn't point out anything that can't be done without the
ETag support in the IF: header.   That's why he ended his posting with:

> Arguably, the semantic could be manufactured with other combinations, but
> I'd suggest that is your use case.

If you know of another case that he told you about off line, please share
it.

If anyone actually knows of a client that actually uses the IF: etag
feature, then please point it out.

J.






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



                                                                                                                                         
                      Stefan Eissing                                                                                                     
                      <stefan.eissing@gre        To:       Jason Crawford/Watson/IBM@IBMUS                                               
                      enbytes.de>                cc:       "'Webdav WG (E-mail)'" <w3c-dist-auth@w3c.org>                                
                      Sent by:                   Subject:  Re: 54th IETF Meeting Information, and RFC2518 open issues                    
                      w3c-dist-auth-reque                                                                                                
                      st@w3.org                                                                                                          
                                                                                                                                         
                                                                                                                                         
                      04/25/2002 01:14 PM                                                                                                
                                                                                                                                         
                                                                                                                                         




Am Donnerstag den, 25. April 2002, um 17:38, schrieb Jason Crawford:

>
>>>> Having never encountered a client using them, I propose to
>>>> drop ETags in IF headers.
>>>
>>> OK; if we drop ETags in If headers how are servers intended to handle
>>> requests using the old syntax, or do you believe that is not an
>>> issue (if
>>> so, why)?
>>
>> We can handle this similar to the "keepalive" body for COPY requests.
>
> Obviously if no clients use it, it's not a big issue, but please
> explain
> further.

As I wrote earlier today, Greg changed my mind on this matter.
There is a use case which cannot be covered by existing HTTP features.

So I'd vote for keeping the If: header as it is.

//Stefan










From w3c-dist-auth-request@w3.org  Thu Apr 25 15:48:59 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03911
	for <webdav-archive@odin.ietf.org>; Thu, 25 Apr 2002 15:48:58 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 5EA7F230A6; Thu, 25 Apr 2002 15:49:00 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA10967;
	Thu, 25 Apr 2002 15:48:51 -0400 (EDT)
Resent-Date: Thu, 25 Apr 2002 15:48:51 -0400 (EDT)
Resent-Message-Id: <200204251948.PAA10967@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA10939
	for <w3c-dist-auth@www19.w3.org>; Thu, 25 Apr 2002 15:48:42 -0400 (EDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA07002
	for <w3c-dist-auth@w3c.org>; Thu, 25 Apr 2002 15:48:41 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3PJlpms017232;
	Thu, 25 Apr 2002 15:47:53 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77])
	by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3PJlnP91266;
	Thu, 25 Apr 2002 15:47:49 -0400
To: "Clemm, Geoff" <gclemm@rational.com>
Cc: "Webdav WG (E-mail)" <w3c-dist-auth@w3c.org>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF182B6217.AC4DBB6A-ON85256BA6.006C299F@pok.ibm.com>
From: "Jason Crawford" <ccjason@us.ibm.com>
Date: Thu, 25 Apr 2002 15:46:12 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at
 04/25/2002 03:47:49 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: RE: etags in If: headers (was: 54th IETF Meeting Information, and 	 RFC2518  open issues)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6167
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


<<
I think a key point is the one Greg made at the end of this message,
namely that this use case can be achieved without allowing etags in
the If header.  In particular, you just try the PUT with the LOCK
request, and if that fails because you no longer have the lock, you
retry the PUT with the appropriate etag in an If-Match header.  I
think it is very reasonable to require an extra round trip in an
exceptional case like this (i.e. losing your lock).
>>
Or depending on your purpose, just skip directly to the second step
of using the If-Match header.  It depends on what you're trying to
achieve.


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





From w3c-dist-auth-request@w3.org  Thu Apr 25 22:23:15 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12574
	for <webdav-archive@odin.ietf.org>; Thu, 25 Apr 2002 22:23:14 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 8799122F13; Thu, 25 Apr 2002 22:23:16 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id WAA27916;
	Thu, 25 Apr 2002 22:22:44 -0400 (EDT)
Resent-Date: Thu, 25 Apr 2002 22:22:44 -0400 (EDT)
Resent-Message-Id: <200204260222.WAA27916@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA27891
	for <w3c-dist-auth@www19.w3.org>; Thu, 25 Apr 2002 22:22:37 -0400 (EDT)
Received: from tarantula.inria.fr (daemon@tarantula.inria.fr [138.96.10.3])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA07003
	for <w3c-dist-auth@w3.org>; Thu, 25 Apr 2002 22:22:37 -0400
Received: by tarantula.inria.fr (8.11.6/8.10.0) id g3Q2MUH20464; Fri, 26 Apr 2002 04:22:30 +0200 (MET DST)
Date: Fri, 26 Apr 2002 04:22:30 +0200 (MET DST)
From: Yves Lafon <ylafon@w3.org>
X-X-Sender: ylafon@tarantula.inria.fr
To: "Clemm, Geoff" <gclemm@rational.com>
Cc: "Webdav WG (E-mail)" <w3c-dist-auth@w3.org>
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B106979EE4@SUS-MA1IT01>
Message-ID: <Pine.GSO.4.44.0204260416190.19981-100000@tarantula.inria.fr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: RE: etags in If: headers (was: 54th IETF Meeting Information, and    RFC2518 open issues)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6168
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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, 25 Apr 2002, Clemm, Geoff wrote:

> exceptional case like this (i.e. losing your lock).
>
> So until a use case is identified that cannot be easily handled by
> other machinery, I suggest we limit the If header to just lock tokens.

Well, using also ETag verification allows consistency check. If you still
have your lock and the ETag has changed, then it's because something nasty
happened on the server side (as the ETag represents more or less a version
tag of the resource).
As it won't cost anything, I don't understand why you want to remove a
consistency check.

-- 
Yves Lafon - W3C



From w3c-dist-auth-request@w3.org  Fri Apr 26 01:07:13 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16550
	for <webdav-archive@odin.ietf.org>; Fri, 26 Apr 2002 01:07:12 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 3D4B822DFB; Fri, 26 Apr 2002 01:07:14 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id BAA14556;
	Fri, 26 Apr 2002 01:07:10 -0400 (EDT)
Resent-Date: Fri, 26 Apr 2002 01:07:10 -0400 (EDT)
Resent-Message-Id: <200204260507.BAA14556@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA14536
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Apr 2002 01:07:04 -0400 (EDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA25249;
	Fri, 26 Apr 2002 01:07:03 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3Q56Qms025634;
	Fri, 26 Apr 2002 01:06:26 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77])
	by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3Q56OP06430;
	Fri, 26 Apr 2002 01:06:25 -0400
To: Yves Lafon <ylafon@w3.org>
Cc: "Clemm, Geoff" <gclemm@Rational.Com>,
        "Webdav WG (E-mail)" <w3c-dist-auth@w3.org>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFAB2A7645.D0B7FB61-ON85256BA7.001AFADD@pok.ibm.com>
From: "Jason Crawford" <ccjason@us.ibm.com>
Date: Fri, 26 Apr 2002 01:06:02 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at
 04/26/2002 01:06:24 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: RE: etags in If: headers (was: 54th IETF Meeting Information, and     RFC2518 open issues)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6169
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>



<<
Well, using also ETag verification allows consistency check. If you still
have your lock and the ETag has changed, then it's because something nasty
happened on the server side (as the ETag represents more or less a version
tag of the resource).
As it won't cost anything, I don't understand why you want to remove a
consistency check.
>>
He wasn't suggesting giving up the consistancy check.  He was suggesting
you
can already do that consistancy check without IF:/etag.  You can use
HTTP's IF-MATCH:/etag instead in most cases.







From w3c-dist-auth-request@w3.org  Fri Apr 26 03:16:32 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26557
	for <webdav-archive@odin.ietf.org>; Fri, 26 Apr 2002 03:16:31 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 4D8C922C7E; Fri, 26 Apr 2002 03:16:33 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id DAA26741;
	Fri, 26 Apr 2002 03:16:09 -0400 (EDT)
Resent-Date: Fri, 26 Apr 2002 03:16:09 -0400 (EDT)
Resent-Message-Id: <200204260716.DAA26741@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA26715
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Apr 2002 03:15:59 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA10356
	for <w3c-dist-auth@w3.org>; Fri, 26 Apr 2002 03:15:58 -0400
Received: (qmail 19524 invoked by uid 0); 26 Apr 2002 07:15:26 -0000
Received: from p3ee24803.dip.t-dialin.net (HELO lisa) (62.226.72.3)
  by mail.gmx.net (mp016-rz3) with SMTP; 26 Apr 2002 07:15:26 -0000
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Yves Lafon" <ylafon@w3.org>, "Clemm, Geoff" <gclemm@rational.com>
Cc: "Webdav WG (E-mail)" <w3c-dist-auth@w3.org>
Date: Fri, 26 Apr 2002 09:15:32 +0200
Message-ID: <JIEGINCHMLABHJBIGKBCMEMEEHAA.julian.reschke@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <Pine.GSO.4.44.0204260416190.19981-100000@tarantula.inria.fr>
x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: RE: etags in If: headers (was: 54th IETF Meeting Information, and    RFC2518 open issues)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6170
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.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 Yves Lafon
> Sent: Friday, April 26, 2002 4:23 AM
> To: Clemm, Geoff
> Cc: Webdav WG (E-mail)
> Subject: RE: etags in If: headers (was: 54th IETF Meeting Information,
> and RFC2518 open issues)
>
>
> On Thu, 25 Apr 2002, Clemm, Geoff wrote:
>
> > exceptional case like this (i.e. losing your lock).
> >
> > So until a use case is identified that cannot be easily handled by
> > other machinery, I suggest we limit the If header to just lock tokens.
>
> Well, using also ETag verification allows consistency check. If you still
> have your lock and the ETag has changed, then it's because something nasty
> happened on the server side (as the ETag represents more or less a version
> tag of the resource).

That would be an internal server error -- I don't think the *protocol* needs
to allow discovery of problem like these...

> As it won't cost anything, I don't understand why you want to remove a
> consistency check.

Well, that's exactly the point: every feature that's hard to implement, of
questionable use *does* cost (in implementation/debugging time).

So the feature should stay if

- it gives us something that can't be easily done otherwise

- we have proven interoperability.



From w3c-dist-auth-request@w3.org  Fri Apr 26 07:34:32 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29818
	for <webdav-archive@odin.ietf.org>; Fri, 26 Apr 2002 07:34:32 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 91CDB22DAB; Fri, 26 Apr 2002 07:34:33 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id HAA21128;
	Fri, 26 Apr 2002 07:34:29 -0400 (EDT)
Resent-Date: Fri, 26 Apr 2002 07:34:29 -0400 (EDT)
Resent-Message-Id: <200204261134.HAA21128@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA21100
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Apr 2002 07:34:21 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA09500
	for <w3c-dist-auth@w3.org>; Fri, 26 Apr 2002 07:34:20 -0400
Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Fri, 26 Apr 2002 07:30:05 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19)
	id <26NBDW0P>; Fri, 26 Apr 2002 07:33:47 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10697A123@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "Webdav WG (E-mail)" <w3c-dist-auth@w3.org>
Date: Fri, 26 Apr 2002 07:33:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: RE: etags in If: headers (was: 54th IETF Meeting Information, and 	  RFC2518 open issues)
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6171
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>

You don't need to put the Etag in the If header to get the consistency
check;
you can just use both the If header with the lock token and an If-Match
header with the Etag.

I really don't care whether or not we keep the Etag semantics in
the If header.  The issue was that if it is not being used in practice by
clients, then it needs to be deleted when we go to proposed standard,
unless there were good arguments for keeping it in (and no such good
argument seems to have yet been fielded).

Cheers,
Geoff

-----Original Message-----
From: Yves Lafon [mailto:ylafon@w3.org]
Sent: Thursday, April 25, 2002 10:23 PM
To: Clemm, Geoff
Cc: Webdav WG (E-mail)
Subject: RE: etags in If: headers (was: 54th IETF Meeting Information,
and RFC2518 open issues)


On Thu, 25 Apr 2002, Clemm, Geoff wrote:

> exceptional case like this (i.e. losing your lock).
>
> So until a use case is identified that cannot be easily handled by
> other machinery, I suggest we limit the If header to just lock tokens.

Well, using also ETag verification allows consistency check. If you still
have your lock and the ETag has changed, then it's because something nasty
happened on the server side (as the ETag represents more or less a version
tag of the resource).
As it won't cost anything, I don't understand why you want to remove a
consistency check.

-- 
Yves Lafon - W3C



From w3c-dist-auth-request@w3.org  Fri Apr 26 12:20:26 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09698
	for <webdav-archive@odin.ietf.org>; Fri, 26 Apr 2002 12:20:25 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id DD1F4230B8; Fri, 26 Apr 2002 12:20:28 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA05106;
	Fri, 26 Apr 2002 12:20:20 -0400 (EDT)
Resent-Date: Fri, 26 Apr 2002 12:20:20 -0400 (EDT)
Resent-Message-Id: <200204261620.MAA05106@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA05017
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Apr 2002 12:20:10 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA05397
	for <w3c-dist-auth@w3c.org>; Fri, 26 Apr 2002 12:20:09 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3c.org>; Fri, 26 Apr 2002 18:19:21 +0200
Date: Fri, 26 Apr 2002 18:19:28 +0200
Mime-Version: 1.0 (Apple Message framework v481)
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: <62272144-5931-11D6-9959-00039384827E@greenbytes.de>
X-Mailer: Apple Mail (2.481)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: HTTP If-* headers
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6172
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit

You saw this coming, didn't you? ;)

The HTTP If-* header family, namely

If-Match, If-None-Match, If-Modified-Since,
If-Unmodified-Since and If-Range

are described in rfc2616 as they apply to
GET, HEAD and PUT.

But what about the WebDAV methods? I think we need
to clarify and put an advisory in an updated rfc2518.

Easy things first: If-Range seems only to make sense
with GET. So we could exclude it from discussions of
other methods.

The other four, IMO, should be honoured on DELETE,
COPY, MOVE, LOCK and UNLOCK.

But what about PROPFIND? For the If-* headers to make
sense with PROPFIND, a client would rely on the
assumption that DAV:getlastmodified and DAV:getetag
change when properties are changed (either by PROPPATCH
or as a side-effect on live properties from other
methods.)

Would the burden on the server (to update etag/lastmodified)
justify the benefit? I rather doubt that, but would like
to hear the opinion of the excellent audience on this list.

//Stefan





From w3c-dist-auth-request@w3.org  Fri Apr 26 12:42:32 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10235
	for <webdav-archive@odin.ietf.org>; Fri, 26 Apr 2002 12:42:31 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 11C6022FF4; Fri, 26 Apr 2002 12:42:33 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA07557;
	Fri, 26 Apr 2002 12:42:28 -0400 (EDT)
Resent-Date: Fri, 26 Apr 2002 12:42:28 -0400 (EDT)
Resent-Message-Id: <200204261642.MAA07557@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA07537
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Apr 2002 12:42:18 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA09604
	for <w3c-dist-auth@w3c.org>; Fri, 26 Apr 2002 12:42:18 -0400
Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Fri, 26 Apr 2002 12:38:04 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19)
	id <26NB1HZR>; Fri, 26 Apr 2002 12:41:47 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B15F@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3c.org
Date: Fri, 26 Apr 2002 12:41:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: RE: HTTP If-* headers
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6173
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>

Whenever the topic has come up in the past, it has always
become clear that there will always be some live properties
that will change without updating the DAV:getlastmodified
or DAV:getetag values, that some implementations will update
these values when dead properties (and certain live properties)
change, and that other implementations will never update these
values for any property change.

So there is little useful we can say about the relationship
between property values and the If-* headers.

Cheers,
Geoff

-----Original Message-----
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
Sent: Friday, April 26, 2002 12:19 PM
To: w3c-dist-auth@w3c.org
Subject: HTTP If-* headers


You saw this coming, didn't you? ;)

The HTTP If-* header family, namely

If-Match, If-None-Match, If-Modified-Since,
If-Unmodified-Since and If-Range

are described in rfc2616 as they apply to
GET, HEAD and PUT.

But what about the WebDAV methods? I think we need
to clarify and put an advisory in an updated rfc2518.

Easy things first: If-Range seems only to make sense
with GET. So we could exclude it from discussions of
other methods.

The other four, IMO, should be honoured on DELETE,
COPY, MOVE, LOCK and UNLOCK.

But what about PROPFIND? For the If-* headers to make
sense with PROPFIND, a client would rely on the
assumption that DAV:getlastmodified and DAV:getetag
change when properties are changed (either by PROPPATCH
or as a side-effect on live properties from other
methods.)

Would the burden on the server (to update etag/lastmodified)
justify the benefit? I rather doubt that, but would like
to hear the opinion of the excellent audience on this list.

//Stefan




From w3c-dist-auth-request@w3.org  Fri Apr 26 13:07:05 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10925
	for <webdav-archive@odin.ietf.org>; Fri, 26 Apr 2002 13:07:05 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id A908422FC6; Fri, 26 Apr 2002 13:07:06 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA10242;
	Fri, 26 Apr 2002 13:07:02 -0400 (EDT)
Resent-Date: Fri, 26 Apr 2002 13:07:02 -0400 (EDT)
Resent-Message-Id: <200204261707.NAA10242@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA10217
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Apr 2002 13:06:49 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA15152
	for <w3c-dist-auth@w3c.org>; Fri, 26 Apr 2002 13:06:48 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3c.org>; Fri, 26 Apr 2002 19:06:23 +0200
Date: Fri, 26 Apr 2002 19:06:29 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
Cc: w3c-dist-auth@w3c.org
To: "Clemm, Geoff" <gclemm@rational.com>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8B15F@SUS-MA1IT01>
Message-Id: <F3925EDC-5937-11D6-9959-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.481)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: HTTP If-* headers
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6174
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


Am Freitag den, 26. April 2002, um 18:41, schrieb Clemm, Geoff:

> Whenever the topic has come up in the past, it has always
> become clear that there will always be some live properties
> that will change without updating the DAV:getlastmodified
> or DAV:getetag values, that some implementations will update
> these values when dead properties (and certain live properties)
> change, and that other implementations will never update these
> values for any property change.

That is the current state of affairs, yes.

> So there is little useful we can say about the relationship
> between property values and the If-* headers.

Hmm. I think it would be useful to say that ETags should only
change on content modifications. In my understanding HTTP
caches are encouraged by HTTP/1.1 to validate on ETags.
WebDAV enabled servers could improve caching if PROPPATCH
and friends would not change ETags.

So, a recommendation in a future version of 2518 makes sense,
don't you think?

//Stefan

> Cheers,
> Geoff
>
> -----Original Message-----
> From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
> Sent: Friday, April 26, 2002 12:19 PM
> To: w3c-dist-auth@w3c.org
> Subject: HTTP If-* headers
>
>
> You saw this coming, didn't you? ;)
>
> The HTTP If-* header family, namely
>
> If-Match, If-None-Match, If-Modified-Since,
> If-Unmodified-Since and If-Range
>
> are described in rfc2616 as they apply to
> GET, HEAD and PUT.
>
> But what about the WebDAV methods? I think we need
> to clarify and put an advisory in an updated rfc2518.
>
> Easy things first: If-Range seems only to make sense
> with GET. So we could exclude it from discussions of
> other methods.
>
> The other four, IMO, should be honoured on DELETE,
> COPY, MOVE, LOCK and UNLOCK.
>
> But what about PROPFIND? For the If-* headers to make
> sense with PROPFIND, a client would rely on the
> assumption that DAV:getlastmodified and DAV:getetag
> change when properties are changed (either by PROPPATCH
> or as a side-effect on live properties from other
> methods.)
>
> Would the burden on the server (to update etag/lastmodified)
> justify the benefit? I rather doubt that, but would like
> to hear the opinion of the excellent audience on this list.
>
> //Stefan
>





From w3c-dist-auth-request@w3.org  Fri Apr 26 14:53:45 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25145
	for <webdav-archive@odin.ietf.org>; Fri, 26 Apr 2002 14:53:44 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 31A7422D53; Fri, 26 Apr 2002 14:53:46 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA24391;
	Fri, 26 Apr 2002 14:53:37 -0400 (EDT)
Resent-Date: Fri, 26 Apr 2002 14:53:37 -0400 (EDT)
Resent-Message-Id: <200204261853.OAA24391@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA24345
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Apr 2002 14:53:28 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA06328
	for <w3c-dist-auth@w3c.org>; Fri, 26 Apr 2002 14:53:28 -0400
Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Fri, 26 Apr 2002 14:49:14 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19)
	id <26NB13PB>; Fri, 26 Apr 2002 14:52:56 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B160@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3c.org
Date: Fri, 26 Apr 2002 14:52:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: RE: HTTP If-* headers
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6175
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>

I also agree that the Etag should only apply to the content.

Unfortunately, there are implementations (such as some by
Microsoft) that store the dead properties as hidden parts of
the file, and which use the file system to provide the 
modification dates and etags, and therefore a PROPPATCH will
in fact change the modification date and etag.

So if we want to avoid confusing clients that want to interoperate
with those implementations, we probably can at most say that
"PROPPATCH SHOULD NOT modify the etag or modification date".

Cheers,
Geoff


-----Original Message-----
From: Jason Crawford [mailto:ccjason@us.ibm.com]
Sent: Friday, April 26, 2002 2:29 PM
To: Stefan Eissing
Cc: Clemm, Geoff; w3c-dist-auth@w3c.org
Subject: Re: HTTP If-* headers



I agree with Stefan.  ETags should only apply to the GET/HEAD response.
We can invent something else if we want some ETAG-like support that applies
to properties.

Stefan did mention PUT.  I wound't even necessarily mention that since more
than just PUT can alter the GET response.

Stefan, you've apparently just read the IF-* specifications.   Does this
sound acceptable in view of what you read?

J.

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




From w3c-dist-auth-request@w3.org  Fri Apr 26 15:10:24 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27258
	for <webdav-archive@odin.ietf.org>; Fri, 26 Apr 2002 15:10:24 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 1F1EC23016; Fri, 26 Apr 2002 15:10:27 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id PAA25773;
	Fri, 26 Apr 2002 15:10:22 -0400 (EDT)
Resent-Date: Fri, 26 Apr 2002 15:10:22 -0400 (EDT)
Resent-Message-Id: <200204261910.PAA25773@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA25642
	for <w3c-dist-auth@www19.w3.org>; Fri, 26 Apr 2002 15:10:02 -0400 (EDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA04792
	for <w3c-dist-auth@w3c.org>; Fri, 26 Apr 2002 14:44:34 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3QIhrms034870;
	Fri, 26 Apr 2002 14:43:53 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77])
	by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3QIhoL29812;
	Fri, 26 Apr 2002 14:43:50 -0400
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: "Clemm, Geoff" <gclemm@Rational.Com>, w3c-dist-auth@w3c.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF2E445397.922136C2-ON85256BA7.0064C6BA@pok.ibm.com>
From: "Jason Crawford" <ccjason@us.ibm.com>
Date: Fri, 26 Apr 2002 14:28:42 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at
 04/26/2002 02:43:50 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: Re: HTTP If-* headers
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6176
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


I agree with Stefan.  ETags should only apply to the GET/HEAD response.
We can invent something else if we want some ETAG-like support that applies
to properties.

Stefan did mention PUT.  I wound't even necessarily mention that since more
than just PUT can alter the GET response.

Stefan, you've apparently just read the IF-* specifications.   Does this
sound acceptable in view of what you read?

J.

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





From w3c-dist-auth-request@w3.org  Sat Apr 27 11:22:53 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15447
	for <webdav-archive@odin.ietf.org>; Sat, 27 Apr 2002 11:22:53 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 2FF1E22C59; Sat, 27 Apr 2002 11:22:56 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id LAA27281;
	Sat, 27 Apr 2002 11:22:30 -0400 (EDT)
Resent-Date: Sat, 27 Apr 2002 11:22:30 -0400 (EDT)
Resent-Message-Id: <200204271522.LAA27281@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA27233
	for <w3c-dist-auth@www19.w3.org>; Sat, 27 Apr 2002 11:22:17 -0400 (EDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA02789
	for <w3c-dist-auth@w3c.org>; Sat, 27 Apr 2002 11:22:17 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3RFLfms442026;
	Sat, 27 Apr 2002 11:21:41 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77])
	by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3RFLdQ41650;
	Sat, 27 Apr 2002 11:21:39 -0400
To: "Clemm, Geoff" <gclemm@Rational.Com>
Cc: w3c-dist-auth@w3c.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF7E3EAF31.37AAF839-ON85256BA7.0069F7F5@pok.ibm.com>
From: "Jason Crawford" <ccjason@us.ibm.com>
Date: Sat, 27 Apr 2002 11:11:47 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at
 04/27/2002 11:21:39 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: RE: HTTP If-* headers, etags 
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6177
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


<<
So if we want to avoid confusing clients that want to interoperate
with those implementations, we probably can at most say that
"PROPPATCH SHOULD NOT modify the etag or modification date".
>>
Sounds good.   So then an ETAG change on a resource indicates to a
client that the GET response *MIGHT* have changed.

Hopefully we can make that a very strong SHOULD so that client checking
for the "lost update problem" as part of a PUT isn't thrown off.

One thing I was concerned about is resources whose GET output changes
often in hard to predict ways.  For such live resources, the server
might chose to change the ETAG continuously rather than try to track
if the GET output has changed.  If this is a red-herring, let me know.
Upon initial blush, I'd think that this means that "lost-update-checking"
will always fail.  But I think the answer to that is, you don't do a PUT
against the live resource.   You should do your PUT/PROPPATCH requests
against source resources because they don't have this behavior.

Does everyone agree on that?

J.

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





From w3c-dist-auth-request@w3.org  Mon Apr 29 03:30:08 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06851
	for <webdav-archive@odin.ietf.org>; Mon, 29 Apr 2002 03:30:07 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id BE9F522CF5; Mon, 29 Apr 2002 03:30:08 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id DAA09494;
	Mon, 29 Apr 2002 03:29:18 -0400 (EDT)
Resent-Date: Mon, 29 Apr 2002 03:29:18 -0400 (EDT)
Resent-Message-Id: <200204290729.DAA09494@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA09451
	for <w3c-dist-auth@www19.w3.org>; Mon, 29 Apr 2002 03:29:03 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA29967
	for <w3c-dist-auth@w3c.org>; Mon, 29 Apr 2002 03:29:03 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3c.org>; Mon, 29 Apr 2002 09:28:36 +0200
Date: Mon, 29 Apr 2002 09:28:35 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
Cc: w3c-dist-auth@w3c.org
To: "Jason Crawford" <ccjason@us.ibm.com>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <OF7E3EAF31.37AAF839-ON85256BA7.0069F7F5@pok.ibm.com>
Message-Id: <B71E0362-5B42-11D6-BBE9-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.481)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: HTTP If-* headers, etags
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6178
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


Am Samstag den, 27. April 2002, um 17:11, schrieb Jason Crawford:

>
> <<
> So if we want to avoid confusing clients that want to interoperate
> with those implementations, we probably can at most say that
> "PROPPATCH SHOULD NOT modify the etag or modification date".
>>>
> Sounds good.   So then an ETAG change on a resource indicates to a
> client that the GET response *MIGHT* have changed.

Fine with me.

> Hopefully we can make that a very strong SHOULD so that client checking
> for the "lost update problem" as part of a PUT isn't thrown off.
>
> One thing I was concerned about is resources whose GET output changes
> often in hard to predict ways.  For such live resources, the server
> might chose to change the ETAG continuously rather than try to track
> if the GET output has changed.  If this is a red-herring, let me know.

I think for continuously changing content, the server should not
generate an ETag at all. If content changes more frequently than
clock resolution (1 second), the server should send an Expires
header with a date in the past.


> Upon initial blush, I'd think that this means that 
> "lost-update-checking"
> will always fail.  But I think the answer to that is, you don't do 
> a PUT
> against the live resource.   You should do your PUT/PROPPATCH requests
> against source resources because they don't have this behavior.

Such resources would most likely be read only, I agree.

//Stefan




From w3c-dist-auth-request@w3.org  Mon Apr 29 07:43:13 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23899
	for <webdav-archive@odin.ietf.org>; Mon, 29 Apr 2002 07:43:12 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id DAC2B22E75; Mon, 29 Apr 2002 07:43:09 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id HAA00165;
	Mon, 29 Apr 2002 07:43:05 -0400 (EDT)
Resent-Date: Mon, 29 Apr 2002 07:43:05 -0400 (EDT)
Resent-Message-Id: <200204291143.HAA00165@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA00143
	for <w3c-dist-auth@www19.w3.org>; Mon, 29 Apr 2002 07:42:55 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA25127
	for <w3c-dist-auth@w3c.org>; Mon, 29 Apr 2002 07:42:55 -0400
Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Mon, 29 Apr 2002 07:38:29 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19)
	id <26NBG403>; Mon, 29 Apr 2002 07:42:18 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B106AEA362@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3c.org
Date: Mon, 29 Apr 2002 07:42:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: RE: HTTP If-* headers, etags 
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6179
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>

   From: Jason Crawford [mailto:ccjason@us.ibm.com]

      So if we want to avoid confusing clients that want to
      interoperate with those implementations, we probably can at most
      say that "PROPPATCH SHOULD NOT modify the etag or modification
      date".

   Sounds good.  So then an ETAG change on a resource indicates to a
   client that the GET response *MIGHT* have changed.  Hopefully we
   can make that a very strong SHOULD so that client checking for the
   "lost update problem" as part of a PUT isn't thrown off.

I'm not sure that one can specify "degrees of SHOULD" (:-),
but certainly one could mention the negative effect that violating
this SHOULD has on caching clients.

   One thing I was concerned about is resources whose GET output changes
   often in hard to predict ways.  For such live resources, the server
   might chose to change the ETAG continuously rather than try to track
   if the GET output has changed.  If this is a red-herring, let me know.

Yes, this is a red-herring (and even if it weren't, it is an HTTP-1.1 issue,
not a WebDAV issue.  Whether or not such a server choses to return
a continuously updated ETAG, or no ETAG at all is just a server choice.

   Upon initial blush, I'd think that this means that "lost-update-checking"
   will always fail.  But I think the answer to that is, you don't do a PUT
   against the live resource.

I don't think we need to (or should) make such a statement.  You could
have a time-of-day resource that is live and continuously updated,
but which allows a PUT to reset the time.  You of course wouldn't
use an If-Match etag with such an update request.

   You should do your PUT/PROPPATCH requests
   against source resources because they don't have this behavior.

That will certainly be the common case, but I don't see that we have
to say anything to that effect.

Cheers,
Geoff




From w3c-dist-auth-request@w3.org  Mon Apr 29 13:50:46 2002
Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05563
	for <webdav-archive@odin.ietf.org>; Mon, 29 Apr 2002 13:50:46 -0400 (EDT)
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by wiggum.w3.org (Postfix) with ESMTP
	id 94D4422B4A; Mon, 29 Apr 2002 13:50:45 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA01220;
	Mon, 29 Apr 2002 13:50:33 -0400 (EDT)
Resent-Date: Mon, 29 Apr 2002 13:50:33 -0400 (EDT)
Resent-Message-Id: <200204291750.NAA01220@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA01194
	for <w3c-dist-auth@www19.w3.org>; Mon, 29 Apr 2002 13:50:28 -0400 (EDT)
Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA17487
	for <w3c-dist-auth@w3c.org>; Mon, 29 Apr 2002 13:50:27 -0400
Received: from unx51.staff.flyingcroc.net (unx51.staff.flyingcroc.net [207.246.150.51])
	by gilliam.users.flyingcroc.net (8.9.3/8.9.3) with ESMTP id KAA74583
	for <w3c-dist-auth@w3c.org>; Mon, 29 Apr 2002 10:50:04 -0700 (PDT)
Received: (from erk@localhost)
	by unx51.staff.flyingcroc.net (8.11.6/8.11.6) id g3THn4636308;
	Mon, 29 Apr 2002 10:49:04 -0700 (PDT)
	(envelope-from erk)
To: w3c-dist-auth@w3c.org
In-Reply-To: <OF7E3EAF31.37AAF839-ON85256BA7.0069F7F5@pok.ibm.com>
References: <3906C56A7BD1F54593344C05BD1374B103F8B15F@SUS-MA1IT01>
	<F3925EDC-5937-11D6-9959-00039384827E@greenbytes.de>
	<OF7E3EAF31.37AAF839-ON85256BA7.0069F7F5@pok.ibm.com>
Organization: Accretive Technology Group
From: Erik Seaberg <erk@flyingcroc.com>
Date: 29 Apr 2002 10:49:03 -0700
Message-ID: <86bsc2e6pc.fsf@unx51.staff.flyingcroc.net>
Lines: 12
X-Mailer: Gnus v5.7/Emacs 20.7
Subject: Re: HTTP If-* headers, etags
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6180
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>

Jason Crawford <ccjason@us.ibm.com> writes:

> One thing I was concerned about is resources whose GET output
> changes often in hard to predict ways[....] But I think the answer
> to that is, you don't do a PUT against the live resource.

Are servers commonly expected to keep GET on a source resource bitwise
identical with the last PUT?  It seemed transcoding, canonicalizing,
or other postprocessing at PUT time would be expected to routinely
change strong ETags (in fact we do that sort of thing to deter abuse
of a free hosting service).  Are common clients unable to accomodate
this?



From w3c-dist-auth-request@w3.org  Tue Apr 30 10:54:04 2002
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23544
	for <webdav-archive@lists.ietf.org>; Tue, 30 Apr 2002 10:54:04 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id DAA08353;
	Tue, 30 Apr 2002 03:46:14 -0400 (EDT)
Resent-Date: Tue, 30 Apr 2002 03:46:14 -0400 (EDT)
Resent-Message-Id: <200204300746.DAA08353@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA07975
	for <w3c-dist-auth@www19.w3.org>; Tue, 30 Apr 2002 03:45:20 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA05753
	for <w3c-dist-auth@w3c.org>; Tue, 30 Apr 2002 03:12:46 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3c.org>; Tue, 30 Apr 2002 09:12:31 +0200
Date: Tue, 30 Apr 2002 09:12:30 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
Cc: w3c-dist-auth@w3c.org
To: Erik Seaberg <erk@flyingcroc.com>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <86bsc2e6pc.fsf@unx51.staff.flyingcroc.net>
Message-Id: <A2640A46-5C09-11D6-BBE9-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.481)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: HTTP If-* headers, etags
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6181
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit


Am Montag den, 29. April 2002, um 19:49, schrieb Erik Seaberg:

> Jason Crawford <ccjason@us.ibm.com> writes:
>
>> One thing I was concerned about is resources whose GET output
>> changes often in hard to predict ways[....] But I think the answer
>> to that is, you don't do a PUT against the live resource.
>
> Are servers commonly expected to keep GET on a source resource bitwise
> identical with the last PUT?  It seemed transcoding, canonicalizing,

Not at all. Etags are no CRC on the content - a client cannot
calculate an ETag before the PUT.

> or other postprocessing at PUT time would be expected to routinely
> change strong ETags (in fact we do that sort of thing to deter abuse
> of a free hosting service).  Are common clients unable to accomodate
> this?

Etags are not to be touched by caching proxies. With transcoding 
proxies,
I'm not sure what they should do.

To answer your question: I don't think that any plain HTTP or WebDAV
client will be confused by rapidly changing Etags as such.

However, the other side of the coin is that it makes sense for editable
content (say a PDF document) to keep their ETag between PUTs. Clients
can then use the ETag (and are indeed encouraged to do this) to check
for unexpected changes to the document they are about to replace.

//Stefan




From w3c-dist-auth-request@w3.org  Tue Apr 30 12:20:06 2002
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27456
	for <webdav-archive@lists.ietf.org>; Tue, 30 Apr 2002 12:20:04 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA18378;
	Tue, 30 Apr 2002 12:11:54 -0400 (EDT)
Resent-Date: Tue, 30 Apr 2002 12:11:54 -0400 (EDT)
Resent-Message-Id: <200204301611.MAA18378@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA18308
	for <w3c-dist-auth@www19.w3.org>; Tue, 30 Apr 2002 12:11:38 -0400 (EDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA18000
	for <w3c-dist-auth@w3c.org>; Tue, 30 Apr 2002 12:11:38 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3UGAsms089558;
	Tue, 30 Apr 2002 12:10:56 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77])
	by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3UGAqB20394;
	Tue, 30 Apr 2002 12:10:52 -0400
To: "Clemm, Geoff" <gclemm@Rational.Com>
Cc: w3c-dist-auth@w3c.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFF4C29C2A.5DF95CF3-ON85256BA8.0053875F@pok.ibm.com>
From: "Jason Crawford" <ccjason@us.ibm.com>
Date: Tue, 30 Apr 2002 11:36:20 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at
 04/30/2002 12:10:52 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: RE: getlastmodified changes when?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6183
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>


> So if we want to avoid confusing clients that want to interoperate
> with those implementations, we probably can at most say that
> "PROPPATCH SHOULD NOT modify the etag or modification date".

One thing to note... you added "or modification date" in to that.   I'm
going to start a seperate
thread for that with this note.   This has also been discussed in the
following thread:

http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0138.html

and two other threads within a month of that .  The issue wasn't resolved.
I believe the
discussion was left with the suggestion that someone make a concrete
proposal.   I'm
going to make a proposal that is similar to Geoff's but worded a bit
differently.  It will
encourage a change to some servers.

"The getlastmodified property SHOULD NOT change as a result of PROPPATCH
unless that PROPPATCH also causes the GET response to change"

This is not the same as saying that it should only change upon changes to
the content
of the underlying (source) resource, but the effect will usually be the
same.  Implicit
in this proposal is the suggestion that if some of us want a property that
tells us about
property changes, we should define/spec a new property for that.

So now we have a proposal on the floor....  :-)

What do people think?

J.

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





From w3c-dist-auth-request@w3.org  Tue Apr 30 12:20:16 2002
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27476
	for <webdav-archive@lists.ietf.org>; Tue, 30 Apr 2002 12:20:13 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA18344;
	Tue, 30 Apr 2002 12:11:45 -0400 (EDT)
Resent-Date: Tue, 30 Apr 2002 12:11:45 -0400 (EDT)
Resent-Message-Id: <200204301611.MAA18344@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA18291
	for <w3c-dist-auth@www19.w3.org>; Tue, 30 Apr 2002 12:11:37 -0400 (EDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA17994
	for <w3c-dist-auth@w3c.org>; Tue, 30 Apr 2002 12:11:37 -0400
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3UGAsms145012;
	Tue, 30 Apr 2002 12:10:56 -0400
Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77])
	by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3UGAqB79958;
	Tue, 30 Apr 2002 12:10:52 -0400
To: "Clemm, Geoff" <gclemm@Rational.Com>, w3c-dist-auth@w3c.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF8F9C2E0A.019537FA-ON85256BAB.005287BD@pok.ibm.com>
From: "Jason Crawford" <ccjason@us.ibm.com>
Date: Tue, 30 Apr 2002 11:22:35 -0400
X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.10 |March 22, 2002) at
 04/30/2002 12:10:51 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: RE: HTTP If-* headers, etags, property changes
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6182
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>




> > So if we want to avoid confusing clients that want to interoperate
> > with those implementations, we probably can at most say that
> > "PROPPATCH SHOULD NOT modify the etag or modification date".
> Sounds good.   So then an ETAG change on a resource indicates to a
> client that the GET response *MIGHT* have changed.

Please excuse the other distracting comments in my note.  I support
the text Geoff provided about etag above.  Although not complete
statement, I think it's up to the HTTP spec to clarify beyond what
Geoff said.

I'll add this as a todo item on the issues list unless someone protests.


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





From w3c-dist-auth-request@w3.org  Tue Apr 30 12:42:42 2002
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28345
	for <webdav-archive@lists.ietf.org>; Tue, 30 Apr 2002 12:42:40 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id MAA21299;
	Tue, 30 Apr 2002 12:40:12 -0400 (EDT)
Resent-Date: Tue, 30 Apr 2002 12:40:12 -0400 (EDT)
Resent-Message-Id: <200204301640.MAA21299@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA21258
	for <w3c-dist-auth@www19.w3.org>; Tue, 30 Apr 2002 12:40:05 -0400 (EDT)
Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA23662
	for <w3c-dist-auth@w3c.org>; Tue, 30 Apr 2002 12:40:05 -0400
Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Tue, 30 Apr 2002 12:34:34 -0400
Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19)
	id <26NBJGKF>; Tue, 30 Apr 2002 12:38:26 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B174@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: w3c-dist-auth@w3c.org
Date: Tue, 30 Apr 2002 12:38:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: RE: getlastmodified changes when?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6184
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-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 that both the last-modified and entity-tag values SHOULD
be reserved for use in caching resource content (i.e. what you get
with GET), and that they SHOULD NOT be used for property value caching.

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:ccjason@us.ibm.com]
Sent: Tuesday, April 30, 2002 11:36 AM
To: Clemm, Geoff
Cc: w3c-dist-auth@w3c.org
Subject: RE: getlastmodified changes when?



> So if we want to avoid confusing clients that want to interoperate
> with those implementations, we probably can at most say that
> "PROPPATCH SHOULD NOT modify the etag or modification date".

One thing to note... you added "or modification date" in to that.   I'm
going to start a seperate
thread for that with this note.   This has also been discussed in the
following thread:

http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0138.html

and two other threads within a month of that .  The issue wasn't resolved.
I believe the
discussion was left with the suggestion that someone make a concrete
proposal.   I'm
going to make a proposal that is similar to Geoff's but worded a bit
differently.  It will
encourage a change to some servers.

"The getlastmodified property SHOULD NOT change as a result of PROPPATCH
unless that PROPPATCH also causes the GET response to change"

This is not the same as saying that it should only change upon changes to
the content
of the underlying (source) resource, but the effect will usually be the
same.  Implicit
in this proposal is the suggestion that if some of us want a property that
tells us about
property changes, we should define/spec a new property for that.

So now we have a proposal on the floor....  :-)

What do people think?

J.

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




From w3c-dist-auth-request@w3.org  Tue Apr 30 13:12:09 2002
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29227
	for <webdav-archive@lists.ietf.org>; Tue, 30 Apr 2002 13:12:09 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA25788;
	Tue, 30 Apr 2002 13:09:44 -0400 (EDT)
Resent-Date: Tue, 30 Apr 2002 13:09:44 -0400 (EDT)
Resent-Message-Id: <200204301709.NAA25788@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA25747
	for <w3c-dist-auth@www19.w3.org>; Tue, 30 Apr 2002 13:09:37 -0400 (EDT)
Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged))
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA29133
	for <w3c-dist-auth@w3c.org>; Tue, 30 Apr 2002 13:09:37 -0400
Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11]
	with SMTP (MDaemon.v3.5.3.R)
	for <w3c-dist-auth@w3c.org>; Tue, 30 Apr 2002 19:08:59 +0200
Date: Tue, 30 Apr 2002 19:08:50 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
From: Stefan Eissing <stefan.eissing@greenbytes.de>
To: w3c-dist-auth@w3c.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8B174@SUS-MA1IT01>
Message-Id: <F117C988-5C5C-11D6-BBE9-00039384827E@greenbytes.de>
X-Mailer: Apple Mail (2.481)
X-MDRemoteIP: 192.168.1.23
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: getlastmodified changes when?
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6185
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.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 agree to that and support Jason's wording.

//Stefan

Am Dienstag den, 30. April 2002, um 18:38, schrieb Clemm, Geoff:

> I agree that both the last-modified and entity-tag values SHOULD
> be reserved for use in caching resource content (i.e. what you get
> with GET), and that they SHOULD NOT be used for property value caching.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Jason Crawford [mailto:ccjason@us.ibm.com]
> Sent: Tuesday, April 30, 2002 11:36 AM
> To: Clemm, Geoff
> Cc: w3c-dist-auth@w3c.org
> Subject: RE: getlastmodified changes when?
>
>
>
>> So if we want to avoid confusing clients that want to interoperate
>> with those implementations, we probably can at most say that
>> "PROPPATCH SHOULD NOT modify the etag or modification date".
>
> One thing to note... you added "or modification date" in to that.   I'm
> going to start a seperate
> thread for that with this note.   This has also been discussed in the
> following thread:
>
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0138.html
>
> and two other threads within a month of that .  The issue wasn't 
> resolved.
> I believe the
> discussion was left with the suggestion that someone make a concrete
> proposal.   I'm
> going to make a proposal that is similar to Geoff's but worded a bit
> differently.  It will
> encourage a change to some servers.
>
> "The getlastmodified property SHOULD NOT change as a result of 
> PROPPATCH
> unless that PROPPATCH also causes the GET response to change"
>
> This is not the same as saying that it should only change upon 
> changes to
> the content
> of the underlying (source) resource, but the effect will usually be the
> same.  Implicit
> in this proposal is the suggestion that if some of us want a 
> property that
> tells us about
> property changes, we should define/spec a new property for that.
>
> So now we have a proposal on the floor....  :-)
>
> What do people think?
>
> J.
>
> ------------------------------------------
> Phone: 914-784-7569,   ccjason@us.ibm.com
>





From w3c-dist-auth-request@w3.org  Tue Apr 30 13:46:32 2002
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00702
	for <webdav-archive@lists.ietf.org>; Tue, 30 Apr 2002 13:46:30 -0400 (EDT)
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA00828;
	Tue, 30 Apr 2002 13:43:37 -0400 (EDT)
Resent-Date: Tue, 30 Apr 2002 13:43:37 -0400 (EDT)
Resent-Message-Id: <200204301743.NAA00828@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA00799
	for <w3c-dist-auth@www19.w3.org>; Tue, 30 Apr 2002 13:43:22 -0400 (EDT)
Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24])
	by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA03305
	for <w3c-dist-auth@w3c.org>; Tue, 30 Apr 2002 13:43:21 -0400
Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 30 Apr 2002 13:42:41 -0400 (Eastern Daylight Time)
Received: from moose ([216.36.77.241]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 30 Apr 2002 13:42:40 -0400
From: "Lisa Dusseault" <ldusseault@xythos.com>
To: "'Stefan Eissing'" <stefan.eissing@greenbytes.de>,
        "'Erik Seaberg'" <erk@flyingcroc.com>
Cc: <w3c-dist-auth@w3c.org>
Date: Tue, 30 Apr 2002 10:43:34 -0700
Message-ID: <000001c1f06e$8e374460$7801a8c0@moose>
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 CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <A2640A46-5C09-11D6-BBE9-00039384827E@greenbytes.de>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 30 Apr 2002 17:42:40.0884 (UTC) FILETIME=[6CFF8B40:01C1F06E]
Subject: RE: HTTP If-* headers, etags
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/6186
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Content-Transfer-Encoding: 7bit

This is a really good point:

> However, the other side of the coin is that it makes sense
> for editable
> content (say a PDF document) to keep their ETag between PUTs. Clients
> can then use the ETag (and are indeed encouraged to do this) to check
> for unexpected changes to the document they are about to replace.

At risk of belaboring the obvious, I'd like to add that clients SHOULD check
the ETag when doing a PUT request (it's just one extra header).  This should
be done even if the client things they've locked the file because locks can
go away or (although wrongly) be used by another process owned by the same
user.

Thus, if clients SHOULD check the ETag before putting the file, it makes it
even more important for servers not to change the ETag unless the contents
have actually changed.  Changing the ETag when the body is unchanged could
result in a poor user experience, if their application has to pop up a
dialog or return an error saying "The file you are trying to save MAY have
been changed.  Do you want to save your changes anyway?"

lisa