From w3c-dist-auth-request@w3.org Sun Aug 3 09:30:18 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17086 for ; Sun, 3 Aug 2003 09:30:17 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h73DUKEh026938; Sun, 3 Aug 2003 09:30:20 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h73DTYk1025094; Sun, 3 Aug 2003 09:29:34 -0400 (EDT) Resent-Date: Sun, 3 Aug 2003 09:29:34 -0400 (EDT) Resent-Message-Id: <200308031329.h73DTYk1025094@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h73DTQFL024556 for ; Sun, 3 Aug 2003 09:29:30 -0400 (EDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h73DI2PT004331 for ; Sun, 3 Aug 2003 09:18:02 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h73DHvwO160282 for ; Sun, 3 Aug 2003 09:17:57 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h73DHtQv179234 for ; Sun, 3 Aug 2003 09:17:56 -0400 In-Reply-To: To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 From: Geoffrey M Clemm Message-ID: Date: Sun, 3 Aug 2003 09:17:49 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 08/03/2003 09:17:56, Serialize complete at 08/03/2003 09:17:56 Content-Type: multipart/alternative; boundary="=_alternative 0019230085256D77_=" Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings) X-Archived-At: http://www.w3.org/mid/OF6E64004E.2C5F470C-ON85256D77.00183F7E-85256D77.00490B43@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7769 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0019230085256D77_= Content-Type: text/plain; charset="US-ASCII" "Julian Reschke" wrote on 07/20/2003 12:18:01 PM: > > From: Geoffrey M Clemm > > > > How about the following alternative: > > > > For PROPFIND, define a new 208 status code that means "resource already > > reported". > > > > A server that detects a loop in a PROPFIND result, would use 208 status > > code for the 2'nd (and subsequent) encounters with a given resource. This > > allows > > the client to reconstruct the binding structure based on just a single > > PROPFIND call. > OK, this issue has been coming up several times (see > for > the last time). > > 1) Can we get rid of 506 (loop detected)? No, we can't. 506 can occur as > result of operations other than PROPFIND, for instance COPY. I agree that we need the 506 for methods that want to just fail the request. The 208 was for operations like PROPFIND, that do not want to fail, but want to give an accurate report while avoiding the infinite loop. > 2) What error condition do we need to really indicate for the documented > example (PROPFIND depth infinity)? The problem is not with the resource > itself or a specific binding to it. In fact, a PROPFIND depth:1 wouldn't > indicate any special condition at all. The problem occurs *only* because > there's a bind loop, yet the request asked for a depth: infinity resource > listing. So there's not a specific resource that can be "blamed" -- instead, > it's the traversal of the collection's children that can't be done, and for > which optimally the response should indicate failure. There is no error. We just need to provide a way for the server to convey to the client that there is a loop. > 3) A similar problem exists with PROPFINDing deph != 0 on collections when > access privileges forbid listing the members. That can be handled by the appropriate status on the appropriate members. > 4) Will clients that aren't aware of the ordering protocol ignore resources > with a status of 208? Not necessarily -- there may be clients that accept > all 2xx status codes as success (and I think those a stricly conforming to > RFC2518 and RFC2616!). This would mean that we can't use a 2xx code, or if > we do use it, we can simply use the approach outlined in > . I believe the protocol should be designed to produce good behavior to a client that understands the protocol, and reasonable behavior for a client that does not. I believe the 208 will produce this result. > I'm not convinced that a new 2xx status code is a good idea -- one approach > that's much more simpler would be just to forbid depth:infinity PROPFINDs on > collections that contain bind loops and to define an according precondition > value. A server that believes that can chose to just return 506. But a server should be allowed to do better than this. > If we *do* want a new 2xx code, I'd rephrase the status condition. As a > matter of fact, the issue is *not* that the resource already was reported! > In fact, having multiple bindings to the same resource within the same > PROPFIND result is just fine. The 208 status code is explicitly designed to allow a server to use it to minimize the size of the response in this case as well. > So, I'd propose: > > "208 OK, but children not listed" > > We could then extend the response body to indicate *why* children haven't > been traversed: > > DAV:no-bind-loop (recursing below this collection would result in a loop) > DAV:need-privileges (you are allowed to see this collection, but not it's > content)> (see > for > a proposal how to marshall that). I see no need for this added complexity. 208 Already Reported handles both of these cases equally well. Cheers, Geoff --=_alternative 0019230085256D77_= Content-Type: text/html; charset="US-ASCII"
"Julian Reschke" <julian.reschke@gmx.de> wrote on 07/20/2003 12:18:01 PM:

> > From: Geoffrey M Clemm
> >
> > How about the following alternative:
> >
> > For PROPFIND, define a new 208 status code that means "resource already
> > reported".
> >
> > A server that detects a loop in a PROPFIND result, would use 208 status
> > code for the 2'nd (and subsequent) encounters with a given resource.  This
> > allows
> > the client to reconstruct the binding structure based on just a single
> > PROPFIND call.

> OK, this issue has been coming up several times (see
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0081.html> for
> the last time).
>
> 1) Can we get rid of 506 (loop detected)? No, we can't. 506 can occur as
> result of operations other than PROPFIND, for instance COPY.

I agree that we need the 506 for methods that want to just fail the request.
The 208 was for operations like PROPFIND, that do not want to fail, but want
to give an accurate report while avoiding the infinite loop.

> 2) What error condition do we need to really indicate for the documented
> example (PROPFIND depth infinity)? The problem is not with the resource
> itself or a specific binding to it. In fact, a PROPFIND depth:1 wouldn't
> indicate any special condition at all. The problem occurs *only* because
> there's a bind loop, yet the request asked for a depth: infinity resource
> listing. So there's not a specific resource that can be "blamed" -- instead,
> it's the traversal of the collection's children that can't be done, and for
> which optimally the response should indicate failure.

There is no error.  We just need to provide a way for the server to convey to
the client that there is a loop.

> 3) A similar problem exists with PROPFINDing deph != 0 on collections when
> access privileges forbid listing the members.

That can be handled by the appropriate status on the appropriate members.

> 4) Will clients that aren't aware of the ordering protocol ignore resources
> with a status of 208? Not necessarily -- there may be clients that accept
> all 2xx status codes as success (and I think those a stricly conforming to
> RFC2518 and RFC2616!). This would mean that we can't use a 2xx code, or if
> we do use it, we can simply use the approach outlined in
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0080.html>.

I believe the protocol should be designed to produce good behavior to a
client that understands the protocol, and reasonable behavior for a client that
does not.  I believe the 208 will produce this result.

> I'm not convinced that a new 2xx status code is a good idea -- one approach
> that's much more simpler would be just to forbid depth:infinity PROPFINDs on
> collections that contain bind loops and to define an according precondition
> value.

A server that believes that can chose to just return 506.  But a server should
be allowed to do better than this.

> If we *do* want a new 2xx code, I'd rephrase the status condition. As a
> matter of fact, the issue is *not* that the resource already was reported!
> In fact, having multiple bindings to the same resource within the same
> PROPFIND result is just fine.

The 208 status code is explicitly designed to allow a server to use it to
minimize the size of the response in this case as well.

> So, I'd propose:
>
> "208 OK, but children not listed"
>
> We could then extend the response body to indicate *why* children haven't
> been traversed:
>
> DAV:no-bind-loop (recursing below this collection would result in a loop)
> DAV:need-privileges (you are allowed to see this collection, but not it's
> content)> (see
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0080.html> for
> a proposal how to marshall that).

I see no need for this added complexity.  208 Already Reported handles
both of these cases equally well.
Cheers,
Geoff
--=_alternative 0019230085256D77_=-- From w3c-dist-auth-request@w3.org Sun Aug 3 11:24:16 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21088 for ; Sun, 3 Aug 2003 11:24:16 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h73FOJEh027809; Sun, 3 Aug 2003 11:24:19 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h73FOFxb027785; Sun, 3 Aug 2003 11:24:15 -0400 (EDT) Resent-Date: Sun, 3 Aug 2003 11:24:15 -0400 (EDT) Resent-Message-Id: <200308031524.h73FOFxb027785@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h73FOEEh027752 for ; Sun, 3 Aug 2003 11:24:14 -0400 (EDT) Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h73FOCPT007628 for ; Sun, 3 Aug 2003 11:24:13 -0400 Received: from daehub01.software-ag.de by server8a.software-ag.de; (8.11.6/8.9.3) id h73FOC332385; Sun, 3 Aug 2003 17:24:12 +0200 Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2653.19) id <3GBNN04P>; Sun, 3 Aug 2003 17:24:11 +0200 Message-ID: From: "Nevermann, Dr., Peter" To: "'w3c-dist-auth@w3.org'" Date: Sun, 3 Aug 2003 17:24:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C359D3.49466EB0" Subject: BIND: precondition DAV:locked-overwrite-allowed X-Archived-At: http://www.w3.org/mid/DFF2AC9E3583D511A21F0008C7E6210605C47FCB@daemsg02.software-ag.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7770 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C359D3.49466EB0 Content-Type: text/plain; charset="iso-8859-1" Some time ago, I asked what status code should a BIND request return, if the precondition DAV:locked-update-allowed is violated. Apparently, there has been consensus in that is should be: 423 "Locked" with in the response-body What if DAV:locked-overwrite-allowed is violated? It could be: 1) 423 "Locked" with in the response-body 2) 409 "Conflict" with in the response-body Isn't 2) more reasonable in this case, because this time it is not the resource identified by the request URI which is locked? Thanks, Peter ------_=_NextPart_001_01C359D3.49466EB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable BIND: precondition DAV:locked-overwrite-allowed

Some time ago, I asked what status code should a BIND = request return, if the precondition
DAV:locked-update-allowed is violated. Apparently, = there has been consensus in that is should be:

423 "Locked" with = <D:error><D:locked-update-allowed/></error> in the = response-body

What if DAV:locked-overwrite-allowed is violated? It = could be:

1) 423 "Locked" with = <D:error><D:locked-overwrite-allowed/></error> in the = response-body

2) 409 "Conflict" with = <D:error><D:locked-overwrite-allowed/></error> in the = response-body

Isn't 2) more reasonable in this case, because this = time it is not the resource identified by the request URI which is = locked?

Thanks,
Peter

------_=_NextPart_001_01C359D3.49466EB0-- From w3c-dist-auth-request@w3.org Mon Aug 4 05:54:08 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20883 for ; Mon, 4 Aug 2003 05:54:08 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h749sAEh026608; Mon, 4 Aug 2003 05:54:10 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h749rmCm026578; Mon, 4 Aug 2003 05:53:48 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 05:53:48 -0400 (EDT) Resent-Message-Id: <200308040953.h749rmCm026578@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h749rkEh026545 for ; Mon, 4 Aug 2003 05:53:46 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h749rjPT030101 for ; Mon, 4 Aug 2003 05:53:45 -0400 Received: (qmail 24354 invoked by uid 65534); 4 Aug 2003 09:53:33 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp004) with SMTP; 04 Aug 2003 11:53:33 +0200 From: "Julian Reschke" To: "Nevermann, Dr., Peter" , Date: Mon, 4 Aug 2003 11:53:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Subject: RE: BIND: precondition DAV:locked-overwrite-allowed X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEPMIAAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7771 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Nevermann, Dr., Peter > Sent: Sunday, August 03, 2003 5:24 PM > To: 'w3c-dist-auth@w3.org' > Subject: BIND: precondition DAV:locked-overwrite-allowed > > > Some time ago, I asked what status code should a BIND request > return, if the > precondition > DAV:locked-update-allowed is violated. Apparently, there has been > consensus > in that is should be: > 423 "Locked" with in the > response-body > What if DAV:locked-overwrite-allowed is violated? It could be: > 1) 423 "Locked" with in the > response-body > 2) 409 "Conflict" with > in the > response-body > Isn't 2) more reasonable in this case, because this time it is not the > resource identified by the request URI which is locked? Agreed. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Aug 4 09:41:36 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25541 for ; Mon, 4 Aug 2003 09:41:35 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74DZGd9024045; Mon, 4 Aug 2003 09:41:33 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h74DLRMf005981; Mon, 4 Aug 2003 09:21:27 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 09:21:27 -0400 (EDT) Resent-Message-Id: <200308041321.h74DLRMf005981@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74DJgSl000008 for ; Mon, 4 Aug 2003 09:21:21 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h74CqcPT011655 for ; Mon, 4 Aug 2003 08:52:39 -0400 Received: (qmail 5834 invoked by uid 65534); 4 Aug 2003 12:52:32 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp023) with SMTP; 04 Aug 2003 14:52:32 +0200 From: "Julian Reschke" To: "Geoffrey M Clemm" , Date: Mon, 4 Aug 2003 14:52:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEACIBAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7772 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Geoffrey M Clemm > Sent: Sunday, August 03, 2003 3:18 PM > To: w3c-dist-auth@w3.org > Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY > and bindings) > > > ... > > > 2) What error condition do we need to really indicate for the documented > > example (PROPFIND depth infinity)? The problem is not with the resource > > itself or a specific binding to it. In fact, a PROPFIND depth:1 wouldn't > > indicate any special condition at all. The problem occurs *only* because > > there's a bind loop, yet the request asked for a depth: infinity resource > > listing. So there's not a specific resource that can be "blamed" -- instead, > > it's the traversal of the collection's children that can't be done, and for > > which optimally the response should indicate failure. > > There is no error. We just need to provide a way for the server to convey to > the client that there is a loop. I really don't care how you call it. The client is asking for a recursive listing, and the server can't provide it. The *problem* is that recursing into the collection would lead to an infinite loop, so there's really no issue with the collection itself. > > 3) A similar problem exists with PROPFINDing deph != 0 on collections when > > access privileges forbid listing the members. > > That can be handled by the appropriate status on the appropriate members. How? If you don't have permission to list the members of a collection, how do you report it for a PROPFIND depth!=0? > > 4) Will clients that aren't aware of the ordering protocol ignore resources > > with a status of 208? Not necessarily -- there may be clients that accept > > all 2xx status codes as success (and I think those a stricly conforming to > > RFC2518 and RFC2616!). This would mean that we can't use a 2xx code, or if > > we do use it, we can simply use the approach outlined in > > > . > > I believe the protocol should be designed to produce good behavior to a > client that understands the protocol, and reasonable behavior for a client that > does not. I believe the 208 will produce this result. I believe it has the same problem that you pointed out re: my proposal, in particular: "If we handled it the way proposed below, the old clients will just ignore the new element, and the user will incorrectly conclude that the collection had no child by that name." I agree that it's less likely that an old client will treat 208 the same way as 200, but it's quite possible. > > I'm not convinced that a new 2xx status code is a good idea -- one approach > > that's much more simpler would be just to forbid depth:infinity PROPFINDs on > > collections that contain bind loops and to define an according precondition > > value. > > A server that believes that can chose to just return 506. But a server should > be allowed to do better than this. If we can find a way that is actually better. I fear that the 208 proposal has the same problem as my original proposal, being that old clients may incorrectly assume that the collection doesn't have children. > > If we *do* want a new 2xx code, I'd rephrase the status condition. As a > > matter of fact, the issue is *not* that the resource already was reported! > > In fact, having multiple bindings to the same resource within the same > > PROPFIND result is just fine. > > The 208 status code is explicitly designed to allow a server to use it to > minimize the size of the response in this case as well. I see. So you'd also use it for all duplicates, no matter what the depth parameter was and whether it's collection or not? This is more consistent, yet it may cause old clients not to display the second binding to a resource within a collection because it *doesn't* treat 208 as success. So old clients that treat 208 as success will incorrectly assume that a collection was empty, while old clients that treat 208 as error will fail to display additional bindings to a resource. > > So, I'd propose: > > > > "208 OK, but children not listed" > > > > We could then extend the response body to indicate *why* children haven't > > been traversed: > > > > DAV:no-bind-loop (recursing below this collection would result > in a loop) > > DAV:need-privileges (you are allowed to see this collection, > but not it's > > content)> (see > > > for > > a proposal how to marshall that). > > I see no need for this added complexity. 208 Already Reported handles > both of these cases equally well. I think not. Actually, I think that there is no easy way to marshall this information in a way compatible with old clients. We've spent a lot of time discussing this, but still don't have a solution. Therefore my alternate proposal just to forbid this very special case. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Aug 4 11:40:06 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01848 for ; Mon, 4 Aug 2003 11:40:05 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74Fe8L3005730; Mon, 4 Aug 2003 11:40:08 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h74Fdvdn005108; Mon, 4 Aug 2003 11:39:57 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 11:39:57 -0400 (EDT) Resent-Message-Id: <200308041539.h74Fdvdn005108@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74FdtL3004870 for ; Mon, 4 Aug 2003 11:39:55 -0400 (EDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h74FdtPT029351 for ; Mon, 4 Aug 2003 11:39:55 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h74Fdm4X152106 for ; Mon, 4 Aug 2003 11:39:48 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h74Fdlpc029746 for ; Mon, 4 Aug 2003 11:39:47 -0400 In-Reply-To: To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 4 Aug 2003 11:39:40 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 08/04/2003 11:39:47, Serialize complete at 08/04/2003 11:39:47 Content-Type: multipart/alternative; boundary="=_alternative 005607AE85256D78_=" Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings) X-Archived-At: http://www.w3.org/mid/OF60A9F265.151BBE83-ON85256D78.004EBD6B-85256D78.005607B1@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7773 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005607AE85256D78_= Content-Type: text/plain; charset="US-ASCII" "Julian Reschke" wrote on 08/04/2003 08:52:26 AM: > ... old clients that treat 208 as success will incorrectly assume > that a collection was empty, while old clients that treat 208 as > error will fail to display additional bindings to a resource. > > I think that there is no easy way to marshall this information in a > way compatible with old clients. We've spent a lot of time > discussing this, but still don't have a solution. Therefore my > alternate proposal just to forbid this very special case. My counter proposal is that servers who are concerned about this can return 506 on the request as a whole, while servers that are not concerned about old client behavior in this regard can take advantage of 208. Cheers, Geoff --=_alternative 005607AE85256D78_= Content-Type: text/html; charset="US-ASCII"
"Julian Reschke" <julian.reschke@gmx.de> wrote on 08/04/2003 08:52:26 AM:

> ... old clients that treat 208 as success will incorrectly assume
> that a collection was empty, while old clients that treat 208 as
> error will fail to display additional bindings to a resource.
>
> I think that there is no easy way to marshall this information in a
> way compatible with old clients. We've spent a lot of time
> discussing this, but still don't have a solution. Therefore my
> alternate proposal just to forbid this very special case.

My counter proposal is that servers who are concerned about this can
return 506 on the request as a whole, while servers that are not
concerned about old client behavior in this regard can take advantage
of 208.

Cheers,
Geoff
--=_alternative 005607AE85256D78_=-- From w3c-dist-auth-request@w3.org Mon Aug 4 11:51:05 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01971 for ; Mon, 4 Aug 2003 11:51:04 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74Fp7L3007306; Mon, 4 Aug 2003 11:51:07 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h74Fp5c3007131; Mon, 4 Aug 2003 11:51:05 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 11:51:05 -0400 (EDT) Resent-Message-Id: <200308041551.h74Fp5c3007131@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74Fp3L3006874 for ; Mon, 4 Aug 2003 11:51:03 -0400 (EDT) Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h74Fp2PT000602 for ; Mon, 4 Aug 2003 11:51:02 -0400 Received: from daehub01.software-ag.de by server8a.software-ag.de; (8.11.6/8.9.3) id h74Fp2308077; Mon, 4 Aug 2003 17:51:02 +0200 Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2653.19) id <3GBN3W5W>; Mon, 4 Aug 2003 17:51:00 +0200 Message-ID: From: "Nevermann, Dr., Peter" To: "'w3c-dist-auth@w3.org'" Date: Mon, 4 Aug 2003 17:50:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35AA0.330E0590" Subject: Clarification of COPY semantics with Overwrite: T X-Archived-At: http://www.w3.org/mid/DFF2AC9E3583D511A21F0008C7E6210605C47FD9@daemsg02.software-ag.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7774 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C35AA0.330E0590 Content-Type: text/plain; charset="iso-8859-1" RFC2518, Section 8.8.4 states: If a resource exists at the destination and the Overwrite header is "T" then prior to performing the copy the server MUST perform a DELETE with "Depth: infinity" on the destination resource. RFC3253, Section 1.7 states: If at the time of the request, there already is a resource at the destination that has the same resource type as the corresponding resource at the request-URL, that resource MUST NOT be deleted, but MUST be updated to have the content and dead properties of its corresponding member. 1) Resource-ID: In terms of binding and with the semantics of RFC3253, I suppose that the DAV:resource-id of the resource being overwritten at destination doesn't change by the COPY operation. Right? 2) Bindings: Suppose there is a collection C1 mapped to URI-1 with 2 bindings a1->R1 and a2->R2 ... moreover, a colletion C2 mapped to URI-2 with 2 bindings a1->R1' and a3->R3'. Now I issue the follwing request: COPY URI-1 Destination: URI-2 Overwrite: T How many bindings has C2 after the COPY? In the "old" semantics of RFC2518 the answer clearly is 2 since the tree of C2 gets deleted prior to the COPY. In the semantics of RFC3253 it could be 3: C2 is updated with the dead properties of C1, a1->R1' is updated with content+dead-props of R1, a2->R2' is created based of R2 and a3->R3' remains unchanged. Or should a3->R3' be unbinded? Thanks, Peter ------_=_NextPart_001_01C35AA0.330E0590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Clarification of COPY semantics with Overwrite: T

RFC2518, Section 8.8.4 states:

   If a resource exists at the destination = and the
   Overwrite header is "T" then = prior to performing
   the copy the server MUST perform a = DELETE with
   "Depth: infinity" on the = destination resource.

RFC3253, Section 1.7 states:

   If at the time of the request, there = already is a
   resource at the destination that has = the same
   resource type as the corresponding = resource at the
   request-URL, that resource MUST NOT be = deleted,
   but MUST be updated to have the content = and dead
   properties of its corresponding = member.

1) Resource-ID:
In terms of binding and with the semantics of = RFC3253, I suppose that the DAV:resource-id of the resource being = overwritten at destination doesn't change by the COPY operation. = Right?

2) Bindings:
Suppose there is a collection C1 mapped to URI-1 = with 2 bindings a1->R1 and a2->R2 ... moreover, a colletion C2 = mapped to URI-2 with 2 bindings a1->R1' and a3->R3'.

Now I issue the follwing request:
  COPY URI-1
  Destination: URI-2
  Overwrite: T

How many bindings has C2 after the COPY? In the = "old" semantics of RFC2518 the answer clearly is 2 since the = tree of C2 gets deleted prior to the COPY. In the semantics of RFC3253 = it could be 3: C2 is updated with the dead properties of C1, a1->R1' = is updated with content+dead-props of R1, a2->R2' is created based = of R2 and a3->R3' remains unchanged. Or should a3->R3' be = unbinded?

Thanks,
Peter

------_=_NextPart_001_01C35AA0.330E0590-- From w3c-dist-auth-request@w3.org Mon Aug 4 12:03:10 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02556 for ; Mon, 4 Aug 2003 12:03:10 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74G3DL3022277; Mon, 4 Aug 2003 12:03:13 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h74G3BE9022225; Mon, 4 Aug 2003 12:03:11 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 12:03:11 -0400 (EDT) Resent-Message-Id: <200308041603.h74G3BE9022225@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74G38L3022179 for ; Mon, 4 Aug 2003 12:03:08 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h74G37PT003454 for ; Mon, 4 Aug 2003 12:03:07 -0400 Received: (qmail 9362 invoked by uid 65534); 4 Aug 2003 16:03:01 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp027) with SMTP; 04 Aug 2003 18:03:01 +0200 From: "Julian Reschke" To: "Nevermann, Dr., Peter" , Date: Mon, 4 Aug 2003 18:02:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01C35AB2.A185B9C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Subject: RE: Clarification of COPY semantics with Overwrite: T X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEALIBAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7775 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_003B_01C35AB2.A185B9C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Clarification of COPY semantics with Overwrite: T1) Yes. 2) 3 (I doubt that many servers get this right :-). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Nevermann, Dr., Peter Sent: Monday, August 04, 2003 5:51 PM To: 'w3c-dist-auth@w3.org' Subject: Clarification of COPY semantics with Overwrite: T RFC2518, Section 8.8.4 states: If a resource exists at the destination and the Overwrite header is "T" then prior to performing the copy the server MUST perform a DELETE with "Depth: infinity" on the destination resource. RFC3253, Section 1.7 states: If at the time of the request, there already is a resource at the destination that has the same resource type as the corresponding resource at the request-URL, that resource MUST NOT be deleted, but MUST be updated to have the content and dead properties of its corresponding member. 1) Resource-ID: In terms of binding and with the semantics of RFC3253, I suppose that the DAV:resource-id of the resource being overwritten at destination doesn't change by the COPY operation. Right? 2) Bindings: Suppose there is a collection C1 mapped to URI-1 with 2 bindings a1->R1 and a2->R2 ... moreover, a colletion C2 mapped to URI-2 with 2 bindings a1->R1' and a3->R3'. Now I issue the follwing request: COPY URI-1 Destination: URI-2 Overwrite: T How many bindings has C2 after the COPY? In the "old" semantics of RFC2518 the answer clearly is 2 since the tree of C2 gets deleted prior to the COPY. In the semantics of RFC3253 it could be 3: C2 is updated with the dead properties of C1, a1->R1' is updated with content+dead-props of R1, a2->R2' is created based of R2 and a3->R3' remains unchanged. Or should a3->R3' be unbinded? Thanks, Peter ------=_NextPart_000_003B_01C35AB2.A185B9C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Clarification of COPY semantics with Overwrite: = T
1) Yes.
 
2) 3 (I doubt that many servers get this right = :-).
 
Julian
 

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

-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Nevermann, = Dr.,=20 Peter
Sent: Monday, August 04, 2003 5:51 PM
To:=20 'w3c-dist-auth@w3.org'
Subject: Clarification of COPY = semantics with=20 Overwrite: T

RFC2518, Section 8.8.4 states:

   If a resource exists at the destination = and the=20
   Overwrite header is "T" then = prior to=20 performing
   the copy the server = MUST=20 perform a DELETE with
   "Depth: = infinity"=20 on the destination resource.

RFC3253, Section 1.7 states:

   If at the time of the request, there = already is=20 a
   resource at the destination = that has=20 the same
   resource type as the=20 corresponding resource at the
  =20 request-URL, that resource MUST NOT be deleted,
   but MUST be updated to have the content and dead =
   properties of its corresponding = member.

1) Resource-ID:
In terms = of binding=20 and with the semantics of RFC3253, I suppose that the DAV:resource-id = of the=20 resource being overwritten at destination doesn't change by the COPY=20 operation. Right?

2) Bindings:
Suppose there = is a=20 collection C1 mapped to URI-1 with 2 bindings a1->R1 and a2->R2 = ...=20 moreover, a colletion C2 mapped to URI-2 with 2 bindings a1->R1' = and=20 a3->R3'.

Now I issue the follwing request:
  COPY URI-1
  = Destination:=20 URI-2
  Overwrite: T

How many bindings has C2 after the COPY? In the = "old"=20 semantics of RFC2518 the answer clearly is 2 since the tree of C2 gets = deleted=20 prior to the COPY. In the semantics of RFC3253 it could be 3: C2 is = updated=20 with the dead properties of C1, a1->R1' is updated with = content+dead-props=20 of R1, a2->R2' is created based of R2 and a3->R3' remains = unchanged. Or=20 should a3->R3' be unbinded?

Thanks,
Peter=20

------=_NextPart_000_003B_01C35AB2.A185B9C0-- From w3c-dist-auth-request@w3.org Mon Aug 4 12:42:45 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04006 for ; Mon, 4 Aug 2003 12:42:45 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74GgmL3019745; Mon, 4 Aug 2003 12:42:48 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h74GgTmY017672; Mon, 4 Aug 2003 12:42:29 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 12:42:29 -0400 (EDT) Resent-Message-Id: <200308041642.h74GgTmY017672@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74GgQL3017622 for ; Mon, 4 Aug 2003 12:42:26 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h74GgQPT016407 for ; Mon, 4 Aug 2003 12:42:26 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19jiPg-0007gh-00; Mon, 04 Aug 2003 16:42:24 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19jiPg-0007gW-00; Mon, 04 Aug 2003 16:42:24 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Geoffrey M Clemm'" , Date: Mon, 4 Aug 2003 09:43:03 -0700 Message-ID: <005301c35aa7$7a04a970$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Old-X-Envelope-To: geoffrey.clemm@us.ibm.com, julian.reschke@gmx.de, w3c-dist-auth@w3.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h74GgQL3017622 Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings) X-Archived-At: http://www.w3.org/mid/005301c35aa7$7a04a970$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7776 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > I really don't care how you call it. The client is asking for > a recursive listing, and the server can't provide it. The > *problem* is that recursing into the collection would lead to > an infinite loop, so there's really no issue with the > collection itself. The client is asking for a recursive listing? That's one way to look at it. Another way to look at it is that the client is asking for a listing of a finite set of resources, and the specification can decide how to successfully return properties of those resources in presence of loops. It serves no purpose for the client to get an infinite set of properties nor does it want them. So as we're defining what the behavior of PROPFIND-depth-infinity is in the presence of loops, we can define what the client "asks for" too, according to what we think the requirements are. I agreed with your arguments about how existing clients might react to a new status code. I suspect that the way existing clients respond to a supposed success (2xx) will be more interoperable than the way they will respond to a supposed failure (4xx, 5xx). Lisa From w3c-dist-auth-request@w3.org Mon Aug 4 12:52:59 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04197 for ; Mon, 4 Aug 2003 12:52:58 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74Gr2L3012958; Mon, 4 Aug 2003 12:53:02 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h74GqxQv012731; Mon, 4 Aug 2003 12:52:59 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 12:52:59 -0400 (EDT) Resent-Message-Id: <200308041652.h74GqxQv012731@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74GquL3012609 for ; Mon, 4 Aug 2003 12:52:56 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h74GquPT019457 for ; Mon, 4 Aug 2003 12:52:56 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19jiZr-0007v0-00; Mon, 04 Aug 2003 16:52:55 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19jiZr-0007ua-00; Mon, 04 Aug 2003 16:52:55 +0000 From: "Lisa Dusseault" To: "'Geoffrey M Clemm'" , Date: Mon, 4 Aug 2003 09:53:33 -0700 Message-ID: <007701c35aa8$f2084660$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0078_01C35A6E.45A96E60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Old-X-Envelope-To: geoffrey.clemm@us.ibm.com, w3c-dist-auth@w3.org Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings) X-Archived-At: http://www.w3.org/mid/007701c35aa8$f2084660$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7777 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0078_01C35A6E.45A96E60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Let's not encourage servers behave differently unless that's really necessary. Clients that *do* support bindings, in particular, should be able to count on servers handling this case in predictable ways. lisa -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm Sent: Monday, August 04, 2003 8:40 AM To: w3c-dist-auth@w3.org Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings) "Julian Reschke" wrote on 08/04/2003 08:52:26 AM: > ... old clients that treat 208 as success will incorrectly assume > that a collection was empty, while old clients that treat 208 as > error will fail to display additional bindings to a resource. > > I think that there is no easy way to marshall this information in a > way compatible with old clients. We've spent a lot of time > discussing this, but still don't have a solution. Therefore my > alternate proposal just to forbid this very special case. My counter proposal is that servers who are concerned about this can return 506 on the request as a whole, while servers that are not concerned about old client behavior in this regard can take advantage of 208. Cheers, Geoff ------=_NextPart_000_0078_01C35A6E.45A96E60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Let's=20 not encourage servers behave differently unless that's really = necessary. =20 Clients that *do* support bindings, in particular, should be able to = count on=20 servers handling this case in predictable ways.
 
lisa
-----Original Message-----
From:=20 w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] = On=20 Behalf Of Geoffrey M Clemm
Sent: Monday, August 04, 2003 = 8:40=20 AM
To: w3c-dist-auth@w3.org
Subject: RE: Binding = loops and=20 PROPFIND clarification needed (was Re: COPY and=20 bindings)


"Julian Reschke"=20 <julian.reschke@gmx.de> wrote on 08/04/2003 08:52:26 = AM:=20

> ... old clients that treat 208 as = success will=20 incorrectly assume
> that a = collection was=20 empty, while old clients that treat 208 as
> error will fail to display additional bindings to a=20 resource.
> =
> I think that there is no easy way to marshall this = information=20 in a
> way compatible with old = clients.=20 We've spent a lot of time
> = discussing=20 this, but still don't have a solution. Therefore my =
> alternate proposal just to forbid this very special=20 case.

My counter proposal is = that servers=20 who are concerned about this can
return 506=20 on the request as a whole, while servers that are not =
concerned about old client behavior in this regard can = take=20 advantage
of 208. =

Cheers,
Geoff=20
------=_NextPart_000_0078_01C35A6E.45A96E60-- From w3c-dist-auth-request@w3.org Mon Aug 4 13:47:42 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05287 for ; Mon, 4 Aug 2003 13:47:42 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74HlhL3007083; Mon, 4 Aug 2003 13:47:43 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h74HlcnM007046; Mon, 4 Aug 2003 13:47:38 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 13:47:38 -0400 (EDT) Resent-Message-Id: <200308041747.h74HlcnM007046@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74HlaL3007010 for ; Mon, 4 Aug 2003 13:47:36 -0400 (EDT) Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h74HlZPT000889 for ; Mon, 4 Aug 2003 13:47:35 -0400 Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27]) by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id h74HlRO08291 for ; Mon, 4 Aug 2003 10:47:29 -0700 (PDT) Message-ID: <3F2E9C2F.1030307@cse.ucsc.edu> Date: Mon, 04 Aug 2003 10:47:27 -0700 From: Elias Sinderson Reply-To: w3c-dist-auth@w3.org User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: Content-Type: multipart/alternative; boundary="------------080902070906040307020402" Subject: Re: URI scheme uniqueness X-Archived-At: http://www.w3.org/mid/3F2E9C2F.1030307@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7778 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --------------080902070906040307020402 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > >>[...] >> Perhaps something along the lines of the following would be acceptable? >> >>"...are free to use any URI scheme so long as it meets the stated uniqueness >>requirements. One way to accomplish this is to use IETF-registered URI schemes." >> >> > That's plain and simply wrong. The only way is to use an URI scheme that >*both* is IETF-registered and meets the uniqueness criterium. > Goodness, you are correct, mea culpa - I see your point now. >> This language seems specific enough to be unambiguous while flexible enough to allow for other mechanisms to ensure uniqueness. The drawback of not [...] >> >> > See, this kind of proves that the spec needs to be enhanced. You and others seem to read it as a license to come up with "private" URI schemes, which is plainly wrong and breaks the uniqueness requirements. Therefore the text >should be clarified. > Yes, I agree, the current text allows for a looser interpretation than is desired - consider me in favor of modifying the current wording. Cheers, Elias --------------080902070906040307020402 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
[...]
<Elias Sinderson> Perhaps something along the lines of the following would be acceptable?

"...are free to use any URI scheme so long as it meets the stated uniqueness
requirements. One way to accomplish this is to use IETF-registered URI schemes."
    
<Julian Reschke> That's plain and simply wrong. The only way is to use an URI scheme that
*both* is IETF-registered and meets the uniqueness criterium.
<Elias Sinderson> Goodness, you are correct, mea culpa - I see your point now.
<Elias Sinderson> This language seems specific enough to be unambiguous while flexible enough to allow for other mechanisms to ensure uniqueness. The drawback of not [...]
    
<Julian Reschke> See, this kind of proves that the spec needs to be enhanced. You and others seem to read it as a license to come up with "private" URI schemes, which is plainly wrong and breaks the uniqueness requirements. Therefore the text
should be clarified.
<Elias Sinderson> Yes, I agree, the current text allows for a looser interpretation than is desired - consider me in favor of modifying the current wording.


Cheers,
Elias
--------------080902070906040307020402-- From w3c-dist-auth-request@w3.org Mon Aug 4 16:54:16 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11768 for ; Mon, 4 Aug 2003 16:54:13 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74Ks4L3029998; Mon, 4 Aug 2003 16:54:04 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h74Kqi7Q029462; Mon, 4 Aug 2003 16:52:44 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 16:52:44 -0400 (EDT) Resent-Message-Id: <200308042052.h74Kqi7Q029462@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74KqfL3029428 for ; Mon, 4 Aug 2003 16:52:41 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h74KqdEr020469 for ; Mon, 4 Aug 2003 16:52:40 -0400 Received: (qmail 28184 invoked by uid 65534); 4 Aug 2003 20:52:28 -0000 Received: from p3EE24758.dip.t-dialin.net (HELO lisa) (62.226.71.88) by mail.gmx.net (mp012) with SMTP; 04 Aug 2003 22:52:28 +0200 From: "Julian Reschke" To: "Geoffrey M Clemm" , Date: Mon, 4 Aug 2003 22:52:20 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEBLIBAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7779 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Geoffrey M Clemm > Sent: Monday, August 04, 2003 5:40 PM > To: w3c-dist-auth@w3.org > Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY > and bindings) > > > > "Julian Reschke" wrote on 08/04/2003 08:52:26 AM: > > > ... old clients that treat 208 as success will incorrectly assume > > that a collection was empty, while old clients that treat 208 as > > error will fail to display additional bindings to a resource. > > > > I think that there is no easy way to marshall this information in a > > way compatible with old clients. We've spent a lot of time > > discussing this, but still don't have a solution. Therefore my > > alternate proposal just to forbid this very special case. > > My counter proposal is that servers who are concerned about this can > return 506 on the request as a whole, while servers that are not > concerned about old client behavior in this regard can take advantage > of 208. OK, but let's please be clear about what we're doing. Both your "208" proposal and my old proposal suffer from old clients possibly misinterpreting the response. In general, a server has no way to know what a client will understand, so -- as Lisa just pointed out -- we really shouldn't send possibly misleading information to the client. But fortunately, this can be fixed: 1) For PROPFIND/depth:infinity on a collection containing bind loops, always return 506 *unless* the client clearly indicates that it knows about the protocol extension. 2) Extend PROPFIND such that the client can indicate that it knows about our new-style responses, such as: This would settle the issue about not confusing old clients. We thus would have the freedom to express the "new" conditions we want to marshall. There seem to be two approaches: a) (your 208 proposal): allow the server just to report a 208 for a resource that was already mentioned in the response. A smart client would need to PROPFIND DAV:resource-id to actually process these, but that's easy enough. b) (my proposal): allow the server to indicate somehow that the resource was reported ok, but members were omitted from the result. I like this one more because it would also resolve the other issue (PROPFIND not being able to report that the client didn't have the *right* to list the members of a collection -- I think you missed this one from my previous reply). Regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Aug 4 16:55:05 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11784 for ; Mon, 4 Aug 2003 16:55:04 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74Kt7L3000469; Mon, 4 Aug 2003 16:55:07 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h74Kt6hj000440; Mon, 4 Aug 2003 16:55:06 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 16:55:06 -0400 (EDT) Resent-Message-Id: <200308042055.h74Kt6hj000440@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74Kt4L3000407 for ; Mon, 4 Aug 2003 16:55:04 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h74Kt3Er021226 for ; Mon, 4 Aug 2003 16:55:03 -0400 Received: (qmail 7137 invoked by uid 65534); 4 Aug 2003 20:54:57 -0000 Received: from p3EE24758.dip.t-dialin.net (HELO lisa) (62.226.71.88) by mail.gmx.net (mp002) with SMTP; 04 Aug 2003 22:54:57 +0200 From: "Julian Reschke" To: Date: Mon, 4 Aug 2003 22:54:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C35ADB.68FEE9E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: <3F2E9C2F.1030307@cse.ucsc.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: URI scheme uniqueness X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEBMIBAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7780 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C35ADB.68FEE9E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Summarizing... I think I've collected enough evidence (people that indeed thought that they can achieve global uniqueness without using an IETF-registered scheme) that this should at least be added to the RFC2518 issues list :-) Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Elias Sinderson Sent: Monday, August 04, 2003 7:47 PM To: w3c-dist-auth@w3.org Subject: Re: URI scheme uniqueness [...] Perhaps something along the lines of the following would be acceptable? "...are free to use any URI scheme so long as it meets the stated uniqueness requirements. One way to accomplish this is to use IETF-registered URI schemes." That's plain and simply wrong. The only way is to use an URI scheme that *both* is IETF-registered and meets the uniqueness criterium. Goodness, you are correct, mea culpa - I see your point now. This language seems specific enough to be unambiguous while flexible enough to allow for other mechanisms to ensure uniqueness. The drawback of not [...] See, this kind of proves that the spec needs to be enhanced. You and others seem to read it as a license to come up with "private" URI schemes, which is plainly wrong and breaks the uniqueness requirements. Therefore the text should be clarified. Yes, I agree, the current text allows for a looser interpretation than is desired - consider me in favor of modifying the current wording. Cheers, Elias ------=_NextPart_000_001A_01C35ADB.68FEE9E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Summarizing...
 
I think I've collected enough evidence (people that indeed = thought that=20 they can achieve global uniqueness without using an IETF-registered = scheme) that=20 this should at least be added to the RFC2518 issues list = :-)
 
Julian
 

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

-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Elias=20 Sinderson
Sent: Monday, August 04, 2003 7:47 = PM
To:=20 w3c-dist-auth@w3.org
Subject: Re: URI scheme uniqueness=20 

[...]
<Elias Sinderson> Perhaps something along the lines of the =
following would be acceptable?

"...are free to use any URI scheme so long as it meets the stated =
uniqueness
requirements. One way to accomplish this is to use IETF-registered URI =
schemes."
    
<Julian Reschke> =
That's plain and simply wrong. The only way is to use an URI scheme that
*both* is IETF-registered and meets the uniqueness =
criterium.
<Elias=20 Sinderson> Goodness, you are correct, mea culpa - I see your point = now.
<Elias Sinderson> =
This language seems specific enough to be unambiguous while flexible =
enough to allow for other mechanisms to ensure uniqueness. The drawback =
of not [...]
    
<Julian Reschke> See, =
this kind of proves that the spec needs to be enhanced. You and others =
seem to read it as a license to come up with "private" URI schemes, =
which is plainly wrong and breaks the uniqueness requirements. Therefore =
the text
should be clarified.
<Elias Sinderson> Yes, I = agree,=20 the current text allows for a looser interpretation than is desired - = consider=20 me in favor of modifying the current=20 wording.


Cheers,
Elias
------=_NextPart_000_001A_01C35ADB.68FEE9E0-- From w3c-dist-auth-request@w3.org Mon Aug 4 17:03:47 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12060 for ; Mon, 4 Aug 2003 17:03:47 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74L3nL3002395; Mon, 4 Aug 2003 17:03:49 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h74L3lwY002367; Mon, 4 Aug 2003 17:03:47 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 17:03:47 -0400 (EDT) Resent-Message-Id: <200308042103.h74L3lwY002367@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74L3jL3002334 for ; Mon, 4 Aug 2003 17:03:45 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h74L3jEr023265 for ; Mon, 4 Aug 2003 17:03:45 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19jmUW-0003Pl-00; Mon, 04 Aug 2003 21:03:40 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19jmUV-0003Pa-00; Mon, 04 Aug 2003 21:03:39 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , Date: Mon, 4 Aug 2003 14:04:19 -0700 Message-ID: <00d301c35acb$f911f370$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D4_01C35A91.4CB31B70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Old-X-Envelope-To: julian.reschke@gmx.de, w3c-dist-auth@w3.org Subject: RE: URI scheme uniqueness X-Archived-At: http://www.w3.org/mid/00d301c35acb$f911f370$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7781 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00D4_01C35A91.4CB31B70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't object to this being an issue, and I'm happy to see suggestions = for new wording. However, I think we're missing something here. You've = already pointed out that using an IETF-registered schema doesn't guarantee uniqueness which is true, but the wording below suggests that you can't = have uniqueness without having IETF registration. Rather, IETF registration = and uniqueness are completely independent qualities. =20 As a counter-example, consider if you invented the schema "greenbytes:", = in which you might find a URI like "greenbytes:www.greenbytes.com:1234-5678-9012:3365008, where the first = part is the schema name, the second part is a domain name, the third part is = a network card ID, and the fourth part is a non-reusable sequence number. This schema has the quality of allowing globally unique URIs to be = selected without being IETF registered. =20 Lisa -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] = On Behalf Of Julian Reschke Sent: Monday, August 04, 2003 1:55 PM To: w3c-dist-auth@w3.org Subject: RE: URI scheme uniqueness=20 Summarizing... =20 I think I've collected enough evidence (people that indeed thought that = they can achieve global uniqueness without using an IETF-registered scheme) = that this should at least be added to the RFC2518 issues list :-) =20 Julian =20 -- bytes GmbH -- http://www.greenbytes.de = -- tel:+492512807760=20 -----Original Message----- From: w3c-dist-auth-request@w3.org = [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Elias Sinderson Sent: Monday, August 04, 2003 7:47 PM To: w3c-dist-auth@w3.org Subject: Re: URI scheme uniqueness=20 [...] Perhaps something along the lines of the following = would be acceptable? "...are free to use any URI scheme so long as it meets the stated = uniqueness requirements. One way to accomplish this is to use IETF-registered URI schemes." =20 That's plain and simply wrong. The only way is to use = an URI scheme that *both* is IETF-registered and meets the uniqueness criterium. Goodness, you are correct, mea culpa - I see your = point now. This language seems specific enough to be unambiguous while flexible enough to allow for other mechanisms to ensure = uniqueness. The drawback of not [...] =20 See, this kind of proves that the spec needs to be enhanced. You and others seem to read it as a license to come up with "private" URI schemes, which is plainly wrong and breaks the uniqueness requirements. Therefore the text should be clarified. Yes, I agree, the current text allows for a looser interpretation than is desired - consider me in favor of modifying the current wording. Cheers, Elias ------=_NextPart_000_00D4_01C35A91.4CB31B70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I=20 don't object to this being an issue, and I'm happy to see suggestions = for new=20 wording.  However, I think we're missing something here.  = You've=20 already pointed out that using an IETF-registered schema doesn't = guarantee=20 uniqueness which is true, but the wording below suggests that you can't = have=20 uniqueness without having IETF registration. Rather, IETF = registration and=20 uniqueness are completely independent qualities.
 
As a=20 counter-example, consider if you invented the schema "greenbytes:", in = which you=20 might find a URI like = "greenbytes:www.greenbytes.com:1234-5678-9012:3365008,=20 where the first part is the schema name, the second part is a domain = name, the=20 third part is a network card ID, and the fourth part is a non-reusable = sequence=20 number.  This schema has the quality of allowing globally unique = URIs to be=20 selected without being IETF registered.
 
Lisa
-----Original Message-----
From:=20 w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] = On=20 Behalf Of Julian Reschke
Sent: Monday, August 04, 2003 = 1:55=20 PM
To: w3c-dist-auth@w3.org
Subject: RE: URI = scheme=20 uniqueness

Summarizing...
 
I think I've collected enough evidence (people that indeed = thought that=20 they can achieve global uniqueness without using an IETF-registered = scheme)=20 that this should at least be added to the RFC2518 issues list=20 :-)
 
Julian
 

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

-----Original Message-----
From:=20 w3c-dist-auth-request@w3.org = [mailto:w3c-dist-auth-request@w3.org]On=20 Behalf Of Elias Sinderson
Sent: Monday, August 04, = 2003 7:47=20 PM
To: w3c-dist-auth@w3.org
Subject: Re: URI = scheme=20 uniqueness 

[...]
<Elias Sinderson> Perhaps something along the lines of the =
following would be acceptable?

"...are free to use any URI scheme so long as it meets the stated =
uniqueness
requirements. One way to accomplish this is to use IETF-registered URI =
schemes."
    
<Julian Reschke> =
That's plain and simply wrong. The only way is to use an URI scheme that
*both* is IETF-registered and meets the uniqueness =
criterium.
<Elias=20 Sinderson> Goodness, you are correct, mea culpa - I see your = point=20 now.
<Elias Sinderson> =
This language seems specific enough to be unambiguous while flexible =
enough to allow for other mechanisms to ensure uniqueness. The drawback =
of not [...]
    
<Julian Reschke> See, =
this kind of proves that the spec needs to be enhanced. You and others =
seem to read it as a license to come up with "private" URI schemes, =
which is plainly wrong and breaks the uniqueness requirements. Therefore =
the text
should be clarified.
<Elias Sinderson> Yes, I = agree,=20 the current text allows for a looser interpretation than is desired = -=20 consider me in favor of modifying the current=20 = wording.


Cheers,
Elias
= ------=_NextPart_000_00D4_01C35A91.4CB31B70-- From w3c-dist-auth-request@w3.org Mon Aug 4 17:22:49 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12358 for ; Mon, 4 Aug 2003 17:22:49 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74LMoL3004432; Mon, 4 Aug 2003 17:22:50 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h74LMmhn004401; Mon, 4 Aug 2003 17:22:48 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 17:22:48 -0400 (EDT) Resent-Message-Id: <200308042122.h74LMmhn004401@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74LMlL3004363 for ; Mon, 4 Aug 2003 17:22:47 -0400 (EDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h74LMkEr027454 for ; Mon, 4 Aug 2003 17:22:46 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h74LMfVp020792 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 4 Aug 2003 14:22:41 -0700 (PDT) Received: from [10.30.7.162] (vpn-10-50-0-84.qualcomm.com [10.50.0.84]) by crowley.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h74LMdix028111; Mon, 4 Aug 2003 14:22:39 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <00d301c35acb$f911f370$f8cb90c6@lisalap> References: <00d301c35acb$f911f370$f8cb90c6@lisalap> Date: Mon, 4 Aug 2003 14:22:41 -0700 To: "Lisa Dusseault" , "'Julian Reschke'" , From: hardie@qualcomm.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: URI scheme uniqueness X-Archived-At: http://www.w3.org/mid/p06001a01bb547d65efd0@%5B10.30.7.162%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7782 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 2:04 PM -0700 8/4/03, Lisa Dusseault wrote: >I don't object to this being an issue, and I'm happy to see >suggestions for new wording. However, I think we're missing >something here. You've already pointed out that using an >IETF-registered schema doesn't guarantee uniqueness which is true, >but the wording below suggests that you can't have uniqueness >without having IETF registration. Rather, IETF registration and >uniqueness are completely independent qualities. I agree that they are independent, but we shouldn't lose sight of the idea that registration tells you whether a scheme will or will not give you uniqueness. The double issues for non-registered schemes is that you can get overlap (the same human-friendly scheme names occur to lots of people) and those using the scheme may have different ideas about the syntax as things evolve. Both can really damage interoperability. I encourage folks to register schemes, and we are now working again on the procedures for non-IETF trees, which would allow people to do a lightweight registration. regards, Ted Hardie From w3c-dist-auth-request@w3.org Mon Aug 4 17:38:04 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12613 for ; Mon, 4 Aug 2003 17:38:04 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74Lc7L3007046; Mon, 4 Aug 2003 17:38:07 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h74Lc54V007016; Mon, 4 Aug 2003 17:38:05 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 17:38:05 -0400 (EDT) Resent-Message-Id: <200308042138.h74Lc54V007016@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74Lc3L3006983 for ; Mon, 4 Aug 2003 17:38:03 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h74Lc2Er031087 for ; Mon, 4 Aug 2003 17:38:02 -0400 Received: (qmail 18330 invoked by uid 65534); 4 Aug 2003 21:37:54 -0000 Received: from p3EE24758.dip.t-dialin.net (HELO lisa) (62.226.71.88) by mail.gmx.net (mp023) with SMTP; 04 Aug 2003 23:37:54 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , Date: Mon, 4 Aug 2003 23:37:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C35AE1.687DEB50" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <00d301c35acb$f911f370$f8cb90c6@lisalap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: URI scheme uniqueness X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEBOIBAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7783 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C35AE1.687DEB50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MessageLisa, this really isn't a counter-example. Just as *I* could define a "private" URI scheme called "greenbytes", everybody else could. Unless you are *the* naming authority for the URI schema (for which you'll need the IETF registration), you simply can't *rely* on nobody else using the same scheme name and scheme-dependant part. Yes, it's unlikely. But writing protocols is about making things 100% robust, not 99.99%. Besides, I really don't see the point in *not* using IETF-registered URI schemes. There are lots that are *guaranteed* to give you the required uniqueness, one of which is the "opaquelocktoken" scheme RFC2518 defines *for this very purpose*. Can you give a single reason why it would be preferrable for a server implementor *not* to use one of the available schemes? Julian (P.S.: I already suggested a new wording) -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault Sent: Monday, August 04, 2003 11:04 PM To: 'Julian Reschke'; w3c-dist-auth@w3.org Subject: RE: URI scheme uniqueness I don't object to this being an issue, and I'm happy to see suggestions for new wording. However, I think we're missing something here. You've already pointed out that using an IETF-registered schema doesn't guarantee uniqueness which is true, but the wording below suggests that you can't have uniqueness without having IETF registration. Rather, IETF registration and uniqueness are completely independent qualities. As a counter-example, consider if you invented the schema "greenbytes:", in which you might find a URI like "greenbytes:www.greenbytes.com:1234-5678-9012:3365008, where the first part is the schema name, the second part is a domain name, the third part is a network card ID, and the fourth part is a non-reusable sequence number. This schema has the quality of allowing globally unique URIs to be selected without being IETF registered. Lisa -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke Sent: Monday, August 04, 2003 1:55 PM To: w3c-dist-auth@w3.org Subject: RE: URI scheme uniqueness Summarizing... I think I've collected enough evidence (people that indeed thought that they can achieve global uniqueness without using an IETF-registered scheme) that this should at least be added to the RFC2518 issues list :-) Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Elias Sinderson Sent: Monday, August 04, 2003 7:47 PM To: w3c-dist-auth@w3.org Subject: Re: URI scheme uniqueness [...] Perhaps something along the lines of the following would be acceptable? "...are free to use any URI scheme so long as it meets the stated uniqueness requirements. One way to accomplish this is to use IETF-registered URI schemes." That's plain and simply wrong. The only way is to use an URI scheme that *both* is IETF-registered and meets the uniqueness criterium. Goodness, you are correct, mea culpa - I see your point now. This language seems specific enough to be unambiguous while flexible enough to allow for other mechanisms to ensure uniqueness. The drawback of not [...] See, this kind of proves that the spec needs to be enhanced. You and others seem to read it as a license to come up with "private" URI schemes, which is plainly wrong and breaks the uniqueness requirements. Therefore the text should be clarified. Yes, I agree, the current text allows for a looser interpretation than is desired - consider me in favor of modifying the current wording. Cheers, Elias ------=_NextPart_000_0009_01C35AE1.687DEB50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Lisa,
 
this really isn't a counter-example. Just as *I* could define a = "private"=20 URI scheme called "greenbytes", everybody else could. Unless you are = *the*=20 naming authority for the URI schema (for which you'll need the IETF=20 registration), you simply can't *rely* on nobody else using the same = scheme name=20 and scheme-dependant part.
 
Yes, it's unlikely. But writing protocols is about making = things 100%=20 robust, not 99.99%.
 
Besides, I really don't see the point in *not* using = IETF-registered URI=20 schemes. There are lots that are *guaranteed* to give you the required=20 uniqueness, one of which is the "opaquelocktoken" scheme RFC2518 defines = *for=20 this very purpose*.
 
Can you give a single reason why it would be preferrable = for a=20 server implementor *not* to use one of the available=20 schemes?
 
Julian
 
(P.S.: I already suggested a new wording)
 

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

-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa=20 Dusseault
Sent: Monday, August 04, 2003 11:04 = PM
To:=20 'Julian Reschke'; w3c-dist-auth@w3.org
Subject: RE: URI = scheme=20 uniqueness

I=20 don't object to this being an issue, and I'm happy to see suggestions = for new=20 wording.  However, I think we're missing something here.  = You've=20 already pointed out that using an IETF-registered schema doesn't = guarantee=20 uniqueness which is true, but the wording below suggests that you = can't have=20 uniqueness without having IETF registration. Rather, IETF = registration=20 and uniqueness are completely independent = qualities.
 
As a=20 counter-example, consider if you invented the schema "greenbytes:", in = which=20 you might find a URI like=20 "greenbytes:www.greenbytes.com:1234-5678-9012:3365008, where the first = part is=20 the schema name, the second part is a domain name, the third part is a = network=20 card ID, and the fourth part is a non-reusable sequence number.  = This=20 schema has the quality of allowing globally unique URIs to be selected = without=20 being IETF registered.
 
Lisa
-----Original Message-----
From:=20 w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] = On=20 Behalf Of Julian Reschke
Sent: Monday, August 04, 2003 = 1:55=20 PM
To: w3c-dist-auth@w3.org
Subject: RE: URI = scheme=20 uniqueness

Summarizing...
 
I think I've collected enough evidence (people that indeed = thought=20 that they can achieve global uniqueness without using an = IETF-registered=20 scheme) that this should at least be added to the RFC2518 issues = list=20 :-)
 
Julian
 

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

-----Original Message-----
From:=20 w3c-dist-auth-request@w3.org = [mailto:w3c-dist-auth-request@w3.org]On=20 Behalf Of Elias Sinderson
Sent: Monday, August 04, = 2003 7:47=20 PM
To: w3c-dist-auth@w3.org
Subject: Re: URI = scheme=20 uniqueness 

[...]
<Elias Sinderson> Perhaps something along the lines of the =
following would be acceptable?

"...are free to use any URI scheme so long as it meets the stated =
uniqueness
requirements. One way to accomplish this is to use IETF-registered URI =
schemes."
    
<Julian Reschke> =
That's plain and simply wrong. The only way is to use an URI scheme that
*both* is IETF-registered and meets the uniqueness =
criterium.
<Elias=20 Sinderson> Goodness, you are correct, mea culpa - I see your = point=20 now.
<Elias Sinderson> =
This language seems specific enough to be unambiguous while flexible =
enough to allow for other mechanisms to ensure uniqueness. The drawback =
of not [...]
    
<Julian Reschke> See, =
this kind of proves that the spec needs to be enhanced. You and others =
seem to read it as a license to come up with "private" URI schemes, =
which is plainly wrong and breaks the uniqueness requirements. Therefore =
the text
should be clarified.
<Elias Sinderson> Yes, I=20 agree, the current text allows for a looser interpretation than is = desired=20 - consider me in favor of modifying the current=20 = wording.


Cheers,
Elias
------=_NextPart_000_0009_01C35AE1.687DEB50-- From w3c-dist-auth-request@w3.org Mon Aug 4 17:47:12 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12734 for ; Mon, 4 Aug 2003 17:47:12 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74LlFL3008849; Mon, 4 Aug 2003 17:47:15 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h74LlFwj008837; Mon, 4 Aug 2003 17:47:15 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 17:47:15 -0400 (EDT) Resent-Message-Id: <200308042147.h74LlFwj008837@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74LlDL3008771 for ; Mon, 4 Aug 2003 17:47:13 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h74LlCEr000865 for ; Mon, 4 Aug 2003 17:47:12 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h74Ll6Kb204740 for ; Mon, 4 Aug 2003 17:47:06 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h74Ll5sx058976 for ; Mon, 4 Aug 2003 17:47:05 -0400 In-Reply-To: To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 4 Aug 2003 17:46:57 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 08/04/2003 17:47:04, Serialize complete at 08/04/2003 17:47:04 Content-Type: multipart/alternative; boundary="=_alternative 0077A80B85256D78_=" Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings) X-Archived-At: http://www.w3.org/mid/OFDAE4431B.82096012-ON85256D78.0075ED4B-85256D78.0077A80E@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7784 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0077A80B85256D78_= Content-Type: text/plain; charset="US-ASCII" Since this statement of "what protocol extensions I understand" is a generically interesting one, including for requests that do not have an extensible body (e.g. PUT), I suggest we marshall this information in the form of a header, not as an XML tag in the body of the request. Other than that, your proposal is fine with me. This is clearly something which should eventually find its way into a successor of 2518, but I'm happy to introduce it in the binding protocol first. I'd like to see more folks comment on this though, before moving in that direction. WRT to the 208 approach vs. the alternative you described, I believe that the 208 approach is the simplest approach, and I do not think it is a benefit to try to couple two very different kinds of situations, i.e. how to marshall a recursive structure vs. how to report on an access restriction. Cheers, Geoff "Julian Reschke" wrote on 08/04/2003 04:52:20 PM: > > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > > Behalf Of Geoffrey M Clemm > > Sent: Monday, August 04, 2003 5:40 PM > > To: w3c-dist-auth@w3.org > > Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY > > and bindings) > > > > > > > > "Julian Reschke" wrote on 08/04/2003 08:52:26 AM: > > > > > ... old clients that treat 208 as success will incorrectly assume > > > that a collection was empty, while old clients that treat 208 as > > > error will fail to display additional bindings to a resource. > > > > > > I think that there is no easy way to marshall this information in a > > > way compatible with old clients. We've spent a lot of time > > > discussing this, but still don't have a solution. Therefore my > > > alternate proposal just to forbid this very special case. > > > > My counter proposal is that servers who are concerned about this can > > return 506 on the request as a whole, while servers that are not > > concerned about old client behavior in this regard can take advantage > > of 208. > > OK, but let's please be clear about what we're doing. Both your "208" > proposal and my old proposal suffer from old clients possibly > misinterpreting the response. In general, a server has no way to know what a > client will understand, so -- as Lisa just pointed out -- we really > shouldn't send possibly misleading information to the client. > > But fortunately, this can be fixed: > > 1) For PROPFIND/depth:infinity on a collection containing bind loops, always > return 506 *unless* the client clearly indicates that it knows about the > protocol extension. > > 2) Extend PROPFIND such that the client can indicate that it knows about our > new-style responses, such as: > > > > This would settle the issue about not confusing old clients. We thus would > have the freedom to express the "new" conditions we want to marshall. There > seem to be two approaches: > > a) (your 208 proposal): allow the server just to report a 208 for a resource > that was already mentioned in the response. A smart client would need to > PROPFIND DAV:resource-id to actually process these, but that's easy enough. > > b) (my proposal): allow the server to indicate somehow that the resource was > reported ok, but members were omitted from the result. I like this one more > because it would also resolve the other issue (PROPFIND not being able to > report that the client didn't have the *right* to list the members of a > collection -- I think you missed this one from my previous reply). > > Regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 0077A80B85256D78_= Content-Type: text/html; charset="US-ASCII"
Since this statement of "what protocol extensions I understand" is
a generically interesting one, including for requests that do not have
an extensible body (e.g. PUT), I suggest we marshall this information
in the form of a header, not as an XML tag in the body of the request.

Other than that, your proposal is fine with me.  This is clearly something
which should eventually find its way into a successor of 2518, but I'm
happy to introduce it in the binding protocol first.

I'd like to see more folks comment on this though, before moving in that
direction.

WRT to the 208 approach vs. the alternative you described, I believe that
the 208 approach is the simplest approach, and I do not think
it is a benefit to try to couple two very different kinds of situations, i.e. how
to marshall a recursive structure vs. how to report on an access restriction.

Cheers,
Geoff


"Julian Reschke" <julian.reschke@gmx.de> wrote on 08/04/2003 04:52:20 PM:

> > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
> > Behalf Of Geoffrey M Clemm
> > Sent: Monday, August 04, 2003 5:40 PM
> > To: w3c-dist-auth@w3.org
> > Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY
> > and bindings)
> >
> >
> >
> > "Julian Reschke" <julian.reschke@gmx.de> wrote on 08/04/2003 08:52:26 AM:
> >
> > > ... old clients that treat 208 as success will incorrectly assume
> > > that a collection was empty, while old clients that treat 208 as
> > > error will fail to display additional bindings to a resource.
> > >
> > > I think that there is no easy way to marshall this information in a
> > > way compatible with old clients. We've spent a lot of time
> > > discussing this, but still don't have a solution. Therefore my
> > > alternate proposal just to forbid this very special case.
> >
> > My counter proposal is that servers who are concerned about this can
> > return 506 on the request as a whole, while servers that are not
> > concerned about old client behavior in this regard can take advantage
> > of 208.
>
> OK, but let's please be clear about what we're doing. Both your "208"
> proposal and my old proposal suffer from old clients possibly
> misinterpreting the response. In general, a server has no way to know what a
> client will understand, so -- as Lisa just pointed out -- we really
> shouldn't send possibly misleading information to the client.
>
> But fortunately, this can be fixed:
>
> 1) For PROPFIND/depth:infinity on a collection containing bind loops, always
> return 506 *unless* the client clearly indicates that it knows about the
> protocol extension.
>
> 2) Extend PROPFIND such that the client can indicate that it knows about our
> new-style responses, such as:
>
> <propfind xmlns="DAV:"><allprop/><understand-208/></propfind>
>
> This would settle the issue about not confusing old clients. We thus would
> have the freedom to express the "new" conditions we want to marshall. There
> seem to be two approaches:
>
> a) (your 208 proposal): allow the server just to report a 208 for a resource
> that was already mentioned in the response. A smart client would need to
> PROPFIND DAV:resource-id to actually process these, but that's easy enough.
>
> b) (my proposal): allow the server to indicate somehow that the resource was
> reported ok, but members were omitted from the result. I like this one more
> because it would also resolve the other issue (PROPFIND not being able to
> report that the client didn't have the *right* to list the members of a
> collection -- I think you missed this one from my previous reply).
>
> Regards, Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 0077A80B85256D78_=-- From w3c-dist-auth-request@w3.org Mon Aug 4 18:58:32 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15002 for ; Mon, 4 Aug 2003 18:58:32 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74MwZL3021211; Mon, 4 Aug 2003 18:58:35 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h74MucPK021062; Mon, 4 Aug 2003 18:56:38 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 18:56:38 -0400 (EDT) Resent-Message-Id: <200308042256.h74MucPK021062@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74MuVL3021025 for ; Mon, 4 Aug 2003 18:56:31 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h74MuUEr017147 for ; Mon, 4 Aug 2003 18:56:31 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19joFS-0005Vq-00; Mon, 04 Aug 2003 22:56:14 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19joFS-0005Vf-00; Mon, 04 Aug 2003 22:56:14 +0000 From: "Lisa Dusseault" To: , "'Julian Reschke'" , Date: Mon, 4 Aug 2003 15:56:55 -0700 Message-ID: <00fc01c35adb$b3bd9670$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Old-X-Envelope-To: hardie@qualcomm.com, julian.reschke@gmx.de, w3c-dist-auth@w3.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h74MuVL3021025 Subject: RE: URI scheme uniqueness X-Archived-At: http://www.w3.org/mid/00fc01c35adb$b3bd9670$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7785 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: hardie@qualcomm.com [mailto:hardie@qualcomm.com] > Sent: Monday, August 04, 2003 2:23 PM > To: Lisa Dusseault; 'Julian Reschke'; w3c-dist-auth@w3.org > Subject: RE: URI scheme uniqueness > > > At 2:04 PM -0700 8/4/03, Lisa Dusseault wrote: > >I don't object to this being an issue, and I'm happy to see > >suggestions for new wording. However, I think we're missing > >something here. You've already pointed out that using an > >IETF-registered schema doesn't guarantee uniqueness which is true, > >but the wording below suggests that you can't have uniqueness > >without having IETF registration. Rather, IETF registration and > >uniqueness are completely independent qualities. > > I agree that they are independent, but we shouldn't lose > sight of the idea that registration tells you whether a > scheme will or will not give you > uniqueness. The > double issues for non-registered schemes is that you can get > overlap (the same human-friendly scheme names occur to lots > of people) and those using the scheme may have different > ideas about the syntax as things evolve. Both can really > damage interoperability. I encourage folks to > register schemes, > and we are now working again on the procedures for non-IETF > trees, which would allow people to do a lightweight registration. In this case interoperability shouldn't be affected. I haven't seen a case where problems have been caused in real life, and I haven't heard a scenario for problems caused (although a poorly chosen schema could compound poor implementation practice). The section under discussion describes how lock tokens are generated. Servers generate lock tokens as URIs for formatting reasons -- so that we know what characters can appear and how they can be marshalled in XML. We could just as easily have required lock tokens to be opaque strings containing only alphanumeric characters, because clients get no semantics out of these tokens. But, because these are URIs there must be a URI scheme. That scheme may or may not be IETF-registered. It may be the http: scheme, the DAV: scheme, the opaquelocktoken: scheme, or something else entirely. It doesn't really matter for interoperability whether the lock token is really unique, or whether it uses an IETF-registered scheme. Since the lock token is never parsed by foreign software (software other than the software which generated the token) it is not an interoperability issue, period. (the only interoperability issue is what characters can appear, which seems uncontroversial since we've defined it as a URI). The uniqueness issue does matter to the server implementor to make their implementation work. But in practice it doesn't have to be universally unique in order to work, it just has to be unique to that server. So if my server issues a locktoken 'DAV:1234', it doesn't matter to either successful interoperability or to the successful functioning of my server if another server issues the same lock token. My server should probably not reuse the locktoken "DAV:1234" for another lock in the future although after sufficient time passes it would be a harmless mistake. That said, it does little harm for the WebDAV spec to be more strict in its requirements, which it is -- it says "Lock token URIs MUST be unique across all resources for all time. ...across resources and servers...". The syntax issue (which you mention as a reason to register schemas) is completely irrelevant as lock tokens are unparsable by any other agent - they are opaque strings in the format of URIs. The issuing server may even treat them as unparsable lookup strings. The issue under discussion is whether we should additionally require the scheme in the lock token to be registered. Currently the spec says "resources are free to return any URI scheme so long as it meets the uniqueness requirements". An additional requirement for registration doesn't help interoperability problems in this particular case as I could register a schema that did not meet the uniqueness requirements (or I could use an existing schema like http: in a way that does not meet the uniqueness requirements). If it is an IETF policy to require registration regardless of the interoperability considerations then it's trivial to add that requirement. Lisa From w3c-dist-auth-request@w3.org Mon Aug 4 19:07:24 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15137 for ; Mon, 4 Aug 2003 19:07:24 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74N7RL3022514; Mon, 4 Aug 2003 19:07:27 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h74N7P0M022480; Mon, 4 Aug 2003 19:07:25 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 19:07:25 -0400 (EDT) Resent-Message-Id: <200308042307.h74N7P0M022480@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74N7OL3022447 for ; Mon, 4 Aug 2003 19:07:24 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h74N7OEr019426 for ; Mon, 4 Aug 2003 19:07:24 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19joQF-0005gt-00; Mon, 04 Aug 2003 23:07:23 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19joQF-0005gi-00; Mon, 04 Aug 2003 23:07:23 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , Date: Mon, 4 Aug 2003 16:08:03 -0700 Message-ID: <00ff01c35add$421d6200$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Old-X-Envelope-To: julian.reschke@gmx.de, w3c-dist-auth@w3.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h74N7OL3022447 Subject: RE: URI scheme uniqueness X-Archived-At: http://www.w3.org/mid/00ff01c35add$421d6200$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7786 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit According to your logic, if I register the scheme "foo:", and I don't register the scheme "bar:", and if both schemes are defined to use a registered domain name and a unique network card ID plus a unique sequence number, then --> foo:www.greenbytes.com:1234-5678-9012:3365008 is guaranteed to be unique --> bar:www.greenbytes.com:1234-5678-9012:3365008 is NOT guaranteed to be unique You think that because "foo:" is registered everybody will use it properly, whereas because "bar:" is unregistered somebody else is likely to use it improperly? In the real world, registering a schema makes it *more* likely that other people will use it. Increasing the usage of the scheme will also increase the likelihood that even if that scheme is designed to allow uniqueness it will be misused and create a non-unique URI. So in some sense encouraging registration does more to make things less-than-100% robust. Bugs and poor implementation choices are the likely causes of non-uniqueness here, not the registration of the scheme. I did not say it would be preferable for a server implementor to use an unregistered scheme. I am merely arguing that some of the arguments used in this discussion are bogus arguments. Generally I don't like things to be changed for poor reasons. Even if I'm not opposed to the change we ought to understand the reasons. Lisa -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, August 04, 2003 2:38 PM To: Lisa Dusseault; w3c-dist-auth@w3.org Subject: RE: URI scheme uniqueness Lisa, this really isn't a counter-example. Just as *I* could define a "private" URI scheme called "greenbytes", everybody else could. Unless you are *the* naming authority for the URI schema (for which you'll need the IETF registration), you simply can't *rely* on nobody else using the same scheme name and scheme-dependant part. Yes, it's unlikely. But writing protocols is about making things 100% robust, not 99.99%. Besides, I really don't see the point in *not* using IETF-registered URI schemes. There are lots that are *guaranteed* to give you the required uniqueness, one of which is the "opaquelocktoken" scheme RFC2518 defines *for this very purpose*. Can you give a single reason why it would be preferrable for a server implementor *not* to use one of the available schemes? Julian (P.S.: I already suggested a new wording) -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault Sent: Monday, August 04, 2003 11:04 PM To: 'Julian Reschke'; w3c-dist-auth@w3.org Subject: RE: URI scheme uniqueness I don't object to this being an issue, and I'm happy to see suggestions for new wording. However, I think we're missing something here. You've already pointed out that using an IETF-registered schema doesn't guarantee uniqueness which is true, but the wording below suggests that you can't have uniqueness without having IETF registration. Rather, IETF registration and uniqueness are completely independent qualities. As a counter-example, consider if you invented the schema "greenbytes:", in which you might find a URI like "greenbytes:www.greenbytes.com:1234-5678-9012:3365008, where the first part is the schema name, the second part is a domain name, the third part is a network card ID, and the fourth part is a non-reusable sequence number. This schema has the quality of allowing globally unique URIs to be selected without being IETF registered. Lisa -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke Sent: Monday, August 04, 2003 1:55 PM To: w3c-dist-auth@w3.org Subject: RE: URI scheme uniqueness Summarizing... I think I've collected enough evidence (people that indeed thought that they can achieve global uniqueness without using an IETF-registered scheme) that this should at least be added to the RFC2518 issues list :-) Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Elias Sinderson Sent: Monday, August 04, 2003 7:47 PM To: w3c-dist-auth@w3.org Subject: Re: URI scheme uniqueness [...] Perhaps something along the lines of the following would be acceptable? "...are free to use any URI scheme so long as it meets the stated uniqueness requirements. One way to accomplish this is to use IETF-registered URI schemes." That's plain and simply wrong. The only way is to use an URI scheme that *both* is IETF-registered and meets the uniqueness criterium. Goodness, you are correct, mea culpa - I see your point now. This language seems specific enough to be unambiguous while flexible enough to allow for other mechanisms to ensure uniqueness. The drawback of not [...] See, this kind of proves that the spec needs to be enhanced. You and others seem to read it as a license to come up with "private" URI schemes, which is plainly wrong and breaks the uniqueness requirements. Therefore the text should be clarified. Yes, I agree, the current text allows for a looser interpretation than is desired - consider me in favor of modifying the current wording. Cheers, Elias From w3c-dist-auth-request@w3.org Mon Aug 4 19:42:21 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15696 for ; Mon, 4 Aug 2003 19:42:21 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74NgML3028797; Mon, 4 Aug 2003 19:42:22 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h74NejXF028656; Mon, 4 Aug 2003 19:40:45 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 19:40:45 -0400 (EDT) Resent-Message-Id: <200308042340.h74NejXF028656@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h74NehL3028623 for ; Mon, 4 Aug 2003 19:40:44 -0400 (EDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h74NehEr025740 for ; Mon, 4 Aug 2003 19:40:43 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h74NeXVp028195 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 4 Aug 2003 16:40:33 -0700 (PDT) Received: from [10.30.7.162] (vpn-10-50-0-38.qualcomm.com [10.50.0.38]) by sabrina.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h74NeUBC012676; Mon, 4 Aug 2003 16:40:31 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <00fc01c35adb$b3bd9670$f8cb90c6@lisalap> References: <00fc01c35adb$b3bd9670$f8cb90c6@lisalap> Date: Mon, 4 Aug 2003 16:40:32 -0700 To: "Lisa Dusseault" , "'Julian Reschke'" , From: hardie@qualcomm.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: URI scheme uniqueness X-Archived-At: http://www.w3.org/mid/p06001a03bb549711379e@%5B10.30.7.162%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7787 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 3:56 PM -0700 8/4/03, Lisa Dusseault wrote: > > -----Original Message----- >> From: hardie@qualcomm.com [mailto:hardie@qualcomm.com] >> Sent: Monday, August 04, 2003 2:23 PM >> To: Lisa Dusseault; 'Julian Reschke'; w3c-dist-auth@w3.org >> Subject: RE: URI scheme uniqueness >> >> >> At 2:04 PM -0700 8/4/03, Lisa Dusseault wrote: >> >I don't object to this being an issue, and I'm happy to see >> >suggestions for new wording. However, I think we're missing >> >something here. You've already pointed out that using an >> >IETF-registered schema doesn't guarantee uniqueness which is true, >> >but the wording below suggests that you can't have uniqueness >> >without having IETF registration. Rather, IETF registration and >> >uniqueness are completely independent qualities. >> >> I agree that they are independent, but we shouldn't lose >> sight of the idea that registration tells you whether a >> scheme will or will not give you >> uniqueness. The >> double issues for non-registered schemes is that you can get >> overlap (the same human-friendly scheme names occur to lots >> of people) and those using the scheme may have different >> ideas about the syntax as things evolve. Both can really >> damage interoperability. I encourage folks to >> register schemes, >> and we are now working again on the procedures for non-IETF > > trees, which would allow people to do a lightweight registration. Obviously my transition here wasn't very good. As you say above, the two are independent; you can have IETF schemes which are not unique and non-IETF schemes which are. If you are an implementor considering using a non-IETF registered URI scheme _for_any_purpose_, don't lose sight of what using a registered URI scheme gives you. Non-registered schemes risk overlap and risk misunderstandings of syntax developing over time. We're trying to reduce the overhead of registration by re-introducing the idea of non-IETF trees and making the registration procedures for them lightweight. A presumption (possibly unwarranted) on my part was that anyone choosing an unregistered URI scheme for lock tokens is doing so to reuse scheme they are already using for some other purpose. Hence the motivation to make the general plug above to register schemes whenever they can. >The uniqueness issue does matter to the server implementor to make their >implementation work. But in practice it doesn't have to be universally >unique in order to work, it just has to be unique to that server. So if my >server issues a locktoken 'DAV:1234', it doesn't matter to either successful >interoperability or to the successful functioning of my server if another >server issues the same lock token. My server should probably not reuse the >locktoken "DAV:1234" for another lock in the future although after >sufficient time passes it would be a harmless mistake. That said, it does >little harm for the WebDAV spec to be more strict in its requirements, which >it is -- it says "Lock token URIs MUST be unique across all resources for >all time. ...across resources and servers...". I suspect that this presumes something about the way clients should behave; to wit, if they get a lock token DAV:1234 issued by server dav.example.com, they will not get whacked out when they get a lock token DAV:1234 issued by server dav.example.net (obviously, for some other resource). I believe that this would be good engineering, obviously, but I think maintaining a stricter requirement is useful. >The syntax issue (which you mention as a reason to register schemas) is >completely irrelevant as lock tokens are unparsable by any other agent - >they are opaque strings in the format of URIs. The issuing server may even >treat them as unparsable lookup strings. Again, I was making a more general point about the usefulness of registering schemes. That said, having external review of the minting algorithms can be useful, as achieving uniqueness can be harder than many folks believe. >The issue under discussion is whether we should additionally require the >scheme in the lock token to be registered. Currently the spec says >"resources are free to return any URI scheme so long as it meets the >uniqueness requirements". An additional requirement for registration >doesn't help interoperability problems in this particular case as I could >register a schema that did not meet the uniqueness requirements (or I could >use an existing schema like http: in a way that does not meet the uniqueness >requirements). If it is an IETF policy to require registration regardless >of the interoperability considerations then it's trivial to add that >requirement. I guess I'm looking at this from a different perspective. If you have a URI scheme that you find useful (if my backstory guess is correct, for something more than opaque lock tokens), then registering seems like a good move, so why not do that? (assuming, of course, we can get the registration process finalized and lightweight). Reading the quoted text "resources are free to return any URI scheme so long as it meets the uniqueness requirements", I would have presumed "registered URI scheme" was implied. You could, however, rewrite it to "resources are free to return any opaque lock token so long as it meets the uniqueness requirements and conforms to URI syntax" (or something similar) and get much the same effect without that same presumption. regards Ted Hardie From w3c-dist-auth-request@w3.org Tue Aug 5 03:10:27 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03931 for ; Tue, 5 Aug 2003 03:10:26 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h757ASL3014257; Tue, 5 Aug 2003 03:10:28 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h757AF8V014233; Tue, 5 Aug 2003 03:10:15 -0400 (EDT) Resent-Date: Tue, 5 Aug 2003 03:10:15 -0400 (EDT) Resent-Message-Id: <200308050710.h757AF8V014233@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h757A5L3014196 for ; Tue, 5 Aug 2003 03:10:05 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h757A4Y9025661 for ; Tue, 5 Aug 2003 03:10:04 -0400 Received: (qmail 17105 invoked by uid 65534); 5 Aug 2003 07:09:48 -0000 Received: from p3EE24758.dip.t-dialin.net (HELO lisa) (62.226.71.88) by mail.gmx.net (mp023) with SMTP; 05 Aug 2003 09:09:48 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , , Date: Tue, 5 Aug 2003 09:09:37 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <00fc01c35adb$b3bd9670$f8cb90c6@lisalap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: URI scheme uniqueness X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIECOIBAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7788 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, August 05, 2003 12:57 AM > To: hardie@qualcomm.com; 'Julian Reschke'; w3c-dist-auth@w3.org > Subject: RE: URI scheme uniqueness > > ... > > In this case interoperability shouldn't be affected. I haven't seen a case > where problems have been caused in real life, and I haven't heard a scenario > for problems caused (although a poorly chosen schema could compound poor > implementation practice). > > The section under discussion describes how lock tokens are generated. > Servers generate lock tokens as URIs for formatting reasons -- so that we > know what characters can appear and how they can be marshalled in XML. We I absolutely disagree with this statement. URIs were chosen as this was simply the best way to come up with a robust identifier syntax. > could just as easily have required lock tokens to be opaque strings > containing only alphanumeric characters, because clients get no semantics ...in which case you would have reached the uniqueness criteria exactly how...? > out of these tokens. But, because these are URIs there must be a URI > scheme. That scheme may or may not be IETF-registered. It may be the http: > scheme, the DAV: scheme, the opaquelocktoken: scheme, or something else > entirely. > > It doesn't really matter for interoperability whether the lock token is > really unique, or whether it uses an IETF-registered scheme. Since the lock > token is never parsed by foreign software (software other than the software > which generated the token) it is not an interoperability issue, period. Not true. The spec says that the lock token is a URI. A user agent is absolutely allowed to run a lock token through a URI parser. In particular, this URI parser may actually do scheme-dependant parsing. For instance, it would be perfectly legal for a client to reject a lock token on the basis that it doesn't comply to the syntactical rules for the scheme used, for instance: "opaquelocktoken:foobar" or "http:foobar" > (the only interoperability issue is what characters can appear, which seems > uncontroversial since we've defined it as a URI). Well, uniqueness as well. As RFC2518 guarantess uniqueess...: "Lock token URIs MUST be unique across all resources for all time. This uniqueness constraint allows lock tokens to be submitted across resources and servers without fear of confusion." a client may store all lock tokens in a map, independantly of where they came from. In particular, the spec allows it to *keep* these tokens and to raise an error if a token is issued a second time (this may not be very useful, but the issue is that the spec *allows* that behaviour). > The uniqueness issue does matter to the server implementor to make their > implementation work. But in practice it doesn't have to be universally ...and to the client. > unique in order to work, it just has to be unique to that server. So if my > server issues a locktoken 'DAV:1234', it doesn't matter to either successful No, no, no. The spec says that clients can rely on lock tokens to be unique. If a client talks to two different servers and they both use the lock token "DAV:1234", this can clearly be a problem. *Please* do not make assumptions about what clients do or don't. From what you're saying right now it seems that you're trying to reverse history by removing a required feature from the protocol, and I really really would like to understand *why* you're doing that. > interoperability or to the successful functioning of my server if another > server issues the same lock token. My server should probably not reuse the > locktoken "DAV:1234" for another lock in the future although after > sufficient time passes it would be a harmless mistake. That said, it does Are you saying that breaking a MUST-level requirement of the protocol is harmless? > little harm for the WebDAV spec to be more strict in its requirements, which > it is -- it says "Lock token URIs MUST be unique across all resources for > all time. ...across resources and servers...". > > The syntax issue (which you mention as a reason to register schemas) is > completely irrelevant as lock tokens are unparsable by any other agent - > they are opaque strings in the format of URIs. The issuing server may even > treat them as unparsable lookup strings. Yes. But the spec clearly says that both servers and clients can rely on them being URIs, therefore are allowed to run them through a URI parser and reject them if they aren't valid URIs (for instance, rejecting string that contain non-ASCII characters). > The issue under discussion is whether we should additionally require the > scheme in the lock token to be registered. Currently the spec says > "resources are free to return any URI scheme so long as it meets the > uniqueness requirements". An additional requirement for registration ...my point being that you can't have *guaranteed* uniqueness unless you register the scheme. > doesn't help interoperability problems in this particular case as I could > register a schema that did not meet the uniqueness requirements (or I could It does help interop issues if they are a result of - people using the same non-registered URI scheme with conflicting tokens, and/or - clients rejecting lock tokens because they don't parse as valid URI. > use an existing schema like http: in a way that does not meet the uniqueness > requirements). If it is an IETF policy to require registration regardless > of the interoperability considerations then it's trivial to add that > requirement. Yes. Please. The discussion has shown that it doesn't seem to be obvious, because making up ad-hoc URI schemes seems to be almost the norm, not the exception. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Aug 5 03:20:06 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04108 for ; Tue, 5 Aug 2003 03:20:05 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h757K6L3015201; Tue, 5 Aug 2003 03:20:07 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h757K6gv015190; Tue, 5 Aug 2003 03:20:06 -0400 (EDT) Resent-Date: Tue, 5 Aug 2003 03:20:06 -0400 (EDT) Resent-Message-Id: <200308050720.h757K6gv015190@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h757K4L3015157 for ; Tue, 5 Aug 2003 03:20:04 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h757K3Y9027932 for ; Tue, 5 Aug 2003 03:20:03 -0400 Received: (qmail 16718 invoked by uid 65534); 5 Aug 2003 07:19:57 -0000 Received: from p3EE24758.dip.t-dialin.net (HELO lisa) (62.226.71.88) by mail.gmx.net (mp004) with SMTP; 05 Aug 2003 09:19:57 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , Date: Tue, 5 Aug 2003 09:19:47 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <00ff01c35add$421d6200$f8cb90c6@lisalap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: URI scheme uniqueness X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEECPIBAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7789 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, August 05, 2003 1:08 AM > To: 'Julian Reschke'; w3c-dist-auth@w3.org > Subject: RE: URI scheme uniqueness > > > > > According to your logic, if I register the scheme "foo:", and I don't > register the scheme "bar:", and if both schemes are defined to use a > registered domain name and a unique network card ID plus a unique sequence > number, then > --> foo:www.greenbytes.com:1234-5678-9012:3365008 is guaranteed to be > unique > --> bar:www.greenbytes.com:1234-5678-9012:3365008 is NOT > guaranteed to be > unique Yes. > You think that because "foo:" is registered everybody will use it properly, > whereas because "bar:" is unregistered somebody else is likely to use it > improperly? In the real world, registering a schema makes it *more* likely Nope. Please define what you call "improper" use of a URI schema that is not registered. The scheme name "bar" doesn't "belong* to anybody. Thus all uses of it in public protocols is "improper". Because it is not registered, you simply don't have any control over it. The next day, an IETF RFC may define the "bar:" scheme for something else and define a grammar for legal "bar:" URIs that's incompatible to your ad-hoc usage. Clients would have every right to reject the URI because they may have a URI parser that knows about the new scheme and rejects it. > that other people will use it. Increasing the usage of the scheme will also > increase the likelihood that even if that scheme is designed to allow > uniqueness it will be misused and create a non-unique URI. So in some sense > encouraging registration does more to make things less-than-100% robust. > Bugs and poor implementation choices are the likely causes of non-uniqueness > here, not the registration of the scheme. Both. Anyway, you seem to suggest a mechanism that I'll call "uniqueness-by-obscurity". > I did not say it would be preferable for a server implementor to use an > unregistered scheme. I am merely arguing that some of the arguments used in > this discussion are bogus arguments. Generally I don't like things to be Such as...? > changed for poor reasons. Even if I'm not opposed to the change we ought to > understand the reasons. Again: I understand this as clarification. You simply can't have guaranteed uniqueness in a URI unless the URI scheme is registered. This is *by definition* how URIs work. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Aug 5 03:24:53 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04157 for ; Tue, 5 Aug 2003 03:24:53 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h757OtL3016260; Tue, 5 Aug 2003 03:24:55 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h757Orbg016205; Tue, 5 Aug 2003 03:24:53 -0400 (EDT) Resent-Date: Tue, 5 Aug 2003 03:24:53 -0400 (EDT) Resent-Message-Id: <200308050724.h757Orbg016205@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h757OqL3016169 for ; Tue, 5 Aug 2003 03:24:52 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h757OoY9028928 for ; Tue, 5 Aug 2003 03:24:51 -0400 Received: (qmail 19557 invoked by uid 65534); 5 Aug 2003 07:24:45 -0000 Received: from p3EE24758.dip.t-dialin.net (HELO lisa) (62.226.71.88) by mail.gmx.net (mp027) with SMTP; 05 Aug 2003 09:24:45 +0200 From: "Julian Reschke" To: , "Lisa Dusseault" , "'Julian Reschke'" , Date: Tue, 5 Aug 2003 09:24:35 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: URI scheme uniqueness X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOECPIBAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7790 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of hardie@qualcomm.com > Sent: Tuesday, August 05, 2003 1:41 AM > To: Lisa Dusseault; 'Julian Reschke'; w3c-dist-auth@w3.org > Subject: RE: URI scheme uniqueness > > ... > > Reading the quoted text "resources are free to return any URI scheme so long > as it meets the uniqueness requirements", I would have presumed "registered > URI scheme" was implied. You could, however, rewrite it to "resources are Thanks, Ted. This is where I came from: most people to which I talked about this assumed that as well. However, during testing I found servers that simply use ad-hoc schemes. I think this is a very bad practice, and thus RFC2518bis should be *clarified*.> free to return any opaque lock token so long as it meets the uniqueness > requirements and conforms to URI syntax" (or something similar) and get > much the same effect without that same presumption. So *how* do you produce a guaranteed-to-be-unique URI without using a registered scheme? I think this is simply impossible. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Aug 5 03:31:01 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04277 for ; Tue, 5 Aug 2003 03:31:01 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h757V2L3017527; Tue, 5 Aug 2003 03:31:02 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h757V1ae017517; Tue, 5 Aug 2003 03:31:01 -0400 (EDT) Resent-Date: Tue, 5 Aug 2003 03:31:01 -0400 (EDT) Resent-Message-Id: <200308050731.h757V1ae017517@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h757UxL3017484 for ; Tue, 5 Aug 2003 03:30:59 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h757UwY9030025 for ; Tue, 5 Aug 2003 03:30:58 -0400 Received: (qmail 21486 invoked by uid 65534); 5 Aug 2003 07:30:50 -0000 Received: from p3EE24758.dip.t-dialin.net (HELO lisa) (62.226.71.88) by mail.gmx.net (mp026) with SMTP; 05 Aug 2003 09:30:50 +0200 From: "Julian Reschke" To: "Geoffrey M Clemm" , Date: Tue, 5 Aug 2003 09:30:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEDAIBAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7791 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Geoffrey M Clemm > Sent: Monday, August 04, 2003 11:47 PM > To: w3c-dist-auth@w3.org > Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY > and bindings) > > > > Since this statement of "what protocol extensions I understand" is > a generically interesting one, including for requests that do not have > an extensible body (e.g. PUT), I suggest we marshall this information > in the form of a header, not as an XML tag in the body of the request. Yes and no. As you say, using headers has the advantage to work with PUT. However, I'd like to avoid adding headers because of the namespacing problems. If we go down that road, we really should adopt an extensible scheme, such as the HTTP Extension Framework (RFC2774). > Other than that, your proposal is fine with me. This is clearly something > which should eventually find its way into a successor of 2518, but I'm > happy to introduce it in the binding protocol first. > > I'd like to see more folks comment on this though, before moving in that > direction. > > WRT to the 208 approach vs. the alternative you described, I believe that > the 208 approach is the simplest approach, and I do not think > it is a benefit to try to couple two very different kinds of situations, i.e. how > to marshall a recursive structure vs. how to report on an access > restriction. OK, here'a proposal: add a DAV:response-format element to DAV:propfind. Members of DAV:response-format indicate that the client is prepared to process particular response formats that are not strictly compatible tp RFC2518. In this case, a client would submit (I'd like to be able to re-use that for other extensions, therefore a container element seems to be a good idea). -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Aug 5 11:19:15 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15904 for ; Tue, 5 Aug 2003 11:19:14 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h75FJFL3013040; Tue, 5 Aug 2003 11:19:15 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h75FIYXm012994; Tue, 5 Aug 2003 11:18:34 -0400 (EDT) Resent-Date: Tue, 5 Aug 2003 11:18:34 -0400 (EDT) Resent-Message-Id: <200308051518.h75FIYXm012994@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h75FIWL3012957 for ; Tue, 5 Aug 2003 11:18:32 -0400 (EDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h75FIWY9023633 for ; Tue, 5 Aug 2003 11:18:32 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h75FIRpW134496 for ; Tue, 5 Aug 2003 11:18:27 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h75FIN8J088698 for ; Tue, 5 Aug 2003 11:18:26 -0400 In-Reply-To: To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Tue, 5 Aug 2003 11:17:33 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 08/05/2003 11:18:25, Serialize complete at 08/05/2003 11:18:25 Content-Type: multipart/alternative; boundary="=_alternative 0054016285256D79_=" Subject: RE: URI scheme uniqueness X-Archived-At: http://www.w3.org/mid/OF694794BE.EE6485D7-ON85256D79.00526CB9-85256D79.00540165@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7792 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0054016285256D79_= Content-Type: text/plain; charset="US-ASCII" Julian is correct here. I support adding the clarification to 2518bis that he suggests, i.e. the lock token schema MUST be an IETF-registered schema. Cheers, Geoff w3c-dist-auth-request@w3.org wrote on 08/05/2003 03:09:37 AM: > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Tuesday, August 05, 2003 12:57 AM > > To: hardie@qualcomm.com; 'Julian Reschke'; w3c-dist-auth@w3.org > > Subject: RE: URI scheme uniqueness > > > > ... > > > > In this case interoperability shouldn't be affected. I haven't seen a case > > where problems have been caused in real life, and I haven't heard a > scenario > > for problems caused (although a poorly chosen schema could compound poor > > implementation practice). > > > > The section under discussion describes how lock tokens are generated. > > Servers generate lock tokens as URIs for formatting reasons -- so that we > > know what characters can appear and how they can be marshalled in XML. We > > I absolutely disagree with this statement. URIs were chosen as this was > simply the best way to come up with a robust identifier syntax. > > > could just as easily have required lock tokens to be opaque strings > > containing only alphanumeric characters, because clients get no semantics > > ...in which case you would have reached the uniqueness criteria exactly > how...? > > > out of these tokens. But, because these are URIs there must be a URI > > scheme. That scheme may or may not be IETF-registered. It may be the > http: > > scheme, the DAV: scheme, the opaquelocktoken: scheme, or something else > > entirely. > > > > It doesn't really matter for interoperability whether the lock token is > > really unique, or whether it uses an IETF-registered scheme. Since the > lock > > token is never parsed by foreign software (software other than the > software > > which generated the token) it is not an interoperability issue, period. > > Not true. The spec says that the lock token is a URI. A user agent is > absolutely allowed to run a lock token through a URI parser. In particular, > this URI parser may actually do scheme-dependant parsing. For instance, it > would be perfectly legal for a client to reject a lock token on the basis > that it doesn't comply to the syntactical rules for the scheme used, for > instance: > > "opaquelocktoken:foobar" or "http:foobar" > > > (the only interoperability issue is what characters can appear, which > seems > > uncontroversial since we've defined it as a URI). > > Well, uniqueness as well. As RFC2518 guarantess uniqueess...: > > "Lock token URIs MUST be unique across all resources for all time. This > uniqueness constraint allows lock tokens to be submitted across resources > and servers without fear of confusion." > > a client may store all lock tokens in a map, independantly of where they > came from. In particular, the spec allows it to *keep* these tokens and to > raise an error if a token is issued a second time (this may not be very > useful, but the issue is that the spec *allows* that behaviour). > > > The uniqueness issue does matter to the server implementor to make their > > implementation work. But in practice it doesn't have to be universally > > ...and to the client. > > > unique in order to work, it just has to be unique to that server. So if my > > server issues a locktoken 'DAV:1234', it doesn't matter to either > successful > > No, no, no. The spec says that clients can rely on lock tokens to be unique. > If a client talks to two different servers and they both use the lock token > "DAV:1234", this can clearly be a problem. *Please* do not make assumptions > about what clients do or don't. From what you're saying right now it seems > that you're trying to reverse history by removing a required feature from > the protocol, and I really really would like to understand *why* you're > doing that. > > > interoperability or to the successful functioning of my server if another > > server issues the same lock token. My server should probably not reuse the > > locktoken "DAV:1234" for another lock in the future although after > > sufficient time passes it would be a harmless mistake. That said, it does > > Are you saying that breaking a MUST-level requirement of the protocol is > harmless? > > > little harm for the WebDAV spec to be more strict in its requirements, > which > > it is -- it says "Lock token URIs MUST be unique across all resources for > > all time. ...across resources and servers...". > > > > The syntax issue (which you mention as a reason to register schemas) is > > completely irrelevant as lock tokens are unparsable by any other agent - > > they are opaque strings in the format of URIs. The issuing server may > even > > treat them as unparsable lookup strings. > > Yes. But the spec clearly says that both servers and clients can rely on > them being URIs, therefore are allowed to run them through a URI parser and > reject them if they aren't valid URIs (for instance, rejecting string that > contain non-ASCII characters). > > > The issue under discussion is whether we should additionally require the > > scheme in the lock token to be registered. Currently the spec says > > "resources are free to return any URI scheme so long as it meets the > > uniqueness requirements". An additional requirement for registration > > ...my point being that you can't have *guaranteed* uniqueness unless you > register the scheme. > > > doesn't help interoperability problems in this particular case as I could > > register a schema that did not meet the uniqueness requirements (or I > could > > It does help interop issues if they are a result of > > - people using the same non-registered URI scheme with conflicting tokens, > and/or > - clients rejecting lock tokens because they don't parse as valid URI. > > > use an existing schema like http: in a way that does not meet the > uniqueness > > requirements). If it is an IETF policy to require registration regardless > > of the interoperability considerations then it's trivial to add that > > requirement. > > Yes. Please. The discussion has shown that it doesn't seem to be obvious, > because making up ad-hoc URI schemes seems to be almost the norm, not the > exception. > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > --=_alternative 0054016285256D79_= Content-Type: text/html; charset="US-ASCII"
Julian is correct here.  I support adding the clarification to 2518bis
that he suggests, i.e. the lock token schema MUST be an IETF-registered schema.

Cheers,
Geoff

w3c-dist-auth-request@w3.org wrote on 08/05/2003 03:09:37 AM:

>
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> > Sent: Tuesday, August 05, 2003 12:57 AM
> > To: hardie@qualcomm.com; 'Julian Reschke'; w3c-dist-auth@w3.org
> > Subject: RE: URI scheme uniqueness
> >
> > ...
> >
> > In this case interoperability shouldn't be affected. I haven't seen a case
> > where problems have been caused in real life, and I haven't heard a
> scenario
> > for problems caused (although a poorly chosen schema could compound poor
> > implementation practice).
> >
> > The section under discussion describes how lock tokens are generated.
> > Servers generate lock tokens as URIs for formatting reasons -- so that we
> > know what characters can appear and how they can be marshalled in XML.  We
>
> I absolutely disagree with this statement. URIs were chosen as this was
> simply the best way to come up with a robust identifier syntax.
>
> > could just as easily have required lock tokens to be opaque strings
> > containing only alphanumeric characters, because clients get no semantics
>
> ...in which case you would have reached the uniqueness criteria exactly
> how...?
>
> > out of these tokens.  But, because these are URIs there must be a URI
> > scheme.  That scheme may or may not be IETF-registered.  It may  be the
> http:
> > scheme, the DAV: scheme, the opaquelocktoken: scheme, or something else
> > entirely.
> >
> > It doesn't really matter for interoperability whether the lock token is
> > really unique, or whether it uses an IETF-registered scheme.  Since the
> lock
> > token is never parsed by foreign software (software other than  the
> software
> > which generated the token) it is not an interoperability issue, period.
>
> Not true. The spec says that the lock token is a URI. A user agent is
> absolutely allowed to run a lock token through a URI parser. In particular,
> this URI parser may actually do scheme-dependant parsing. For instance, it
> would be perfectly legal for a client to reject a lock token on the basis
> that it doesn't comply to the syntactical rules for the scheme used, for
> instance:
>
> "opaquelocktoken:foobar" or "http:foobar"
>
> > (the only interoperability issue is what characters can appear, which
> seems
> > uncontroversial since we've defined it as a URI).
>
> Well, uniqueness as well. As RFC2518 guarantess uniqueess...:
>
> "Lock token URIs MUST be unique across all resources for all time. This
> uniqueness constraint allows lock tokens to be submitted across resources
> and servers without fear of confusion."
>
> a client may store all lock tokens in a map, independantly of where they
> came from. In particular, the spec allows it to *keep* these tokens and to
> raise an error if a token is issued a second time (this may not be very
> useful, but the issue is that the spec *allows* that behaviour).
>
> > The uniqueness issue does matter to the server implementor to make their
> > implementation work.  But in practice it doesn't have to be universally
>
> ...and to the client.
>
> > unique in order to work, it just has to be unique to that server. So if my
> > server issues a locktoken 'DAV:1234', it doesn't matter to either
> successful
>
> No, no, no. The spec says that clients can rely on lock tokens to be unique.
> If a client talks to two different servers and they both use the lock token
> "DAV:1234", this can clearly be a problem. *Please* do not make assumptions
> about what clients do or don't. From what you're saying right now it seems
> that you're trying to reverse history by removing a required feature from
> the protocol, and I really really would like to understand *why* you're
> doing that.
>
> > interoperability or to the successful functioning of my server if another
> > server issues the same lock token. My server should probably not reuse the
> > locktoken "DAV:1234" for another lock in the future although after
> > sufficient time passes it would be a harmless mistake.  That said, it does
>
> Are you saying that breaking a MUST-level requirement of the protocol is
> harmless?
>
> > little harm for the WebDAV spec to be more strict in its requirements,
> which
> > it is -- it says "Lock token URIs MUST be unique across all resources for
> > all time. ...across resources and servers...".
> >
> > The syntax issue (which you mention as a reason to register schemas) is
> > completely irrelevant as lock tokens are unparsable by any other agent -
> > they are opaque strings in the format of URIs.  The issuing server may
> even
> > treat them as unparsable lookup strings.
>
> Yes. But the spec clearly says that both servers and clients can rely on
> them being URIs, therefore are allowed to run them through a URI parser and
> reject them if they aren't valid URIs (for instance, rejecting string that
> contain non-ASCII characters).
>
> > The issue under discussion is whether we should additionally require the
> > scheme in the lock token to be registered.  Currently the spec says
> > "resources are free to return any URI scheme so long as it meets the
> > uniqueness requirements".  An additional requirement for registration
>
> ...my point being that you can't have *guaranteed* uniqueness unless you
> register the scheme.
>
> > doesn't help interoperability problems in this particular case as I could
> > register a schema that did not meet the uniqueness requirements (or I
> could
>
> It does help interop issues if they are a result of
>
> - people using the same non-registered URI scheme with conflicting tokens,
> and/or
> - clients rejecting lock tokens because they don't parse as valid URI.
>
> > use an existing schema like http: in a way that does not meet the
> uniqueness
> > requirements).  If it is an IETF policy to require registration regardless
> > of the interoperability considerations then it's trivial to add that
> > requirement.
>
> Yes. Please. The discussion has shown that it doesn't seem to be obvious,
> because making up ad-hoc URI schemes seems to be almost the norm, not the
> exception.
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
--=_alternative 0054016285256D79_=-- From w3c-dist-auth-request@w3.org Tue Aug 5 14:21:12 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21029 for ; Tue, 5 Aug 2003 14:21:10 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h75IL9L3029712; Tue, 5 Aug 2003 14:21:09 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h75IJrRd029399; Tue, 5 Aug 2003 14:19:53 -0400 (EDT) Resent-Date: Tue, 5 Aug 2003 14:19:53 -0400 (EDT) Resent-Message-Id: <200308051819.h75IJrRd029399@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h75IJpL3029366 for ; Tue, 5 Aug 2003 14:19:51 -0400 (EDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h75ID23c009370 for ; Tue, 5 Aug 2003 14:13:02 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h75IJepW054360 for ; Tue, 5 Aug 2003 14:19:40 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h75IJdvu092076 for ; Tue, 5 Aug 2003 14:19:39 -0400 In-Reply-To: To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Tue, 5 Aug 2003 14:19:35 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 08/05/2003 14:19:39, Serialize complete at 08/05/2003 14:19:39 Content-Type: multipart/alternative; boundary="=_alternative 0064ABB085256D79_=" Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings) X-Archived-At: http://www.w3.org/mid/OF3495F79A.1EBE5F64-ON85256D79.0062D273-85256D79.0064ABB3@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7793 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0064ABB085256D79_= Content-Type: text/plain; charset="US-ASCII" I think the granularity of is too fine. I'd prefer to just allow the use of the DAV header as a request header, and if the client says: PROPFIND DAV: 1,2,bind and then the server can use 208 responses (i.e. because "bind" appears in the request DAV header). Or if the request header should have its own name, use something like a "DAV-CLIENT" header. Cheers, Geoff "Julian Reschke" wrote on 08/05/2003 03:30:38 AM: > OK, here'a proposal: add a DAV:response-format element to DAV:propfind. > Members of DAV:response-format indicate that the client is prepared to > process particular response formats that are not strictly compatible tp > RFC2518. In this case, a client would submit > > > > > > > (I'd like to be able to re-use that for other extensions, therefore a > container element seems to be a good idea). --=_alternative 0064ABB085256D79_= Content-Type: text/html; charset="US-ASCII"
I think the granularity of <process-208> is too fine.
I'd prefer to just allow the use of the DAV header as a request header,
and if the client says:

PROPFIND
DAV: 1,2,bind

and then the server can use 208 responses (i.e. because "bind" appears
in the request DAV header).

Or if the request header should have its own name, use something like
a "DAV-CLIENT" header.

Cheers,
Geoff

"Julian Reschke" <julian.reschke@gmx.de> wrote on 08/05/2003 03:30:38 AM:

> OK, here'a proposal: add a DAV:response-format element to DAV:propfind.
> Members of DAV:response-format indicate that the client is prepared to
> process particular response formats that are not strictly compatible tp
> RFC2518. In this case, a client would submit
>
> <propfind xmlns="DAV:">
>   <response-format><process-208/></response-format>
>   <allprop/>
> </propfind>
>
> (I'd like to be able to re-use that for other extensions, therefore a
> container element seems to be a good idea).
 --=_alternative 0064ABB085256D79_=-- From w3c-dist-auth-request@w3.org Tue Aug 5 14:24:36 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21256 for ; Tue, 5 Aug 2003 14:24:36 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h75IOYL3000733; Tue, 5 Aug 2003 14:24:34 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h75IOYIM000723; Tue, 5 Aug 2003 14:24:34 -0400 (EDT) Resent-Date: Tue, 5 Aug 2003 14:24:34 -0400 (EDT) Resent-Message-Id: <200308051824.h75IOYIM000723@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h75IOVL3000686 for ; Tue, 5 Aug 2003 14:24:31 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h75IHg3c010371 for ; Tue, 5 Aug 2003 14:17:43 -0400 Received: (qmail 21309 invoked by uid 65534); 5 Aug 2003 18:24:19 -0000 Received: from p3EE24763.dip.t-dialin.net (HELO lisa) (62.226.71.99) by mail.gmx.net (mp004) with SMTP; 05 Aug 2003 20:24:19 +0200 From: "Julian Reschke" To: Cc: , "Lisa Dusseault" Date: Tue, 5 Aug 2003 20:24:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: URI scheme uniqueness X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEEJIBAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7794 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ted, actually I think it is the *main* issue (well, I did raise the issue after all :-) URI syntax is defined by RFC2396. URIs consist of the scheme name and a scheme-dependant part. Different URI schemes have different characterestics re: uniquenes, for instance - file: would be bad, - http: can be used as long as the owner of the domain ensures that the path components are built in a unique way, - opaquelocktoken: or urn:uuid (draft) are *designed* to accomplish this. The point however is that unless a URI scheme is registered, *anybody* can come up with URIs in the same scheme, and there's no *reliable* way to avoid collision of URIs. Of course, using a registered scheme doesn't guarantee uniqueness either, but at least it provides a chance to blame one of the two sources of the duplicate URI for not complying to the syntax and semantics that have been defined for the URI scheme. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: hardie@qualcomm.com [mailto:hardie@qualcomm.com] > Sent: Tuesday, August 05, 2003 6:10 PM > To: Julian Reschke; Lisa Dusseault > Subject: RE: URI scheme uniqueness > > > >So *how* do you produce a guaranteed-to-be-unique URI without using a > >registered scheme? I think this is simply impossible. > > > >Julian > > I think this is a side issue to the current discussion, so I've > removed the list; > if you disagree, feel free to forward back to the list. > > First, note that I said "that conforms to the URI syntax" rather > than is a URI. > There is a long philosophical discussion we could have about whether > or not something which conforms to the syntax automatically is a URI, but > please let's not. (Frankly, I put it that way to avoid that discussion.) > > Second, there are a number of minting algorithms which are designed to > provide uniqueness, either by reuse of cryptographic functions or by > associating authority and time functions with a specific minter. One > proposal for moving forward with draft-kindberg-tag-uri, for example, > is to shift the draft to describing a minting algorithm for re-use by much > more restricted-function URIs. > regards, > Ted Hardie > From w3c-dist-auth-request@w3.org Tue Aug 5 14:53:44 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23024 for ; Tue, 5 Aug 2003 14:53:44 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h75IrkL3007823; Tue, 5 Aug 2003 14:53:46 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h75Iri3L007800; Tue, 5 Aug 2003 14:53:44 -0400 (EDT) Resent-Date: Tue, 5 Aug 2003 14:53:44 -0400 (EDT) Resent-Message-Id: <200308051853.h75Iri3L007800@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h75IrhL3007767 for ; Tue, 5 Aug 2003 14:53:43 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h75Irg3c018403 for ; Tue, 5 Aug 2003 14:53:42 -0400 Received: (qmail 7537 invoked by uid 65534); 5 Aug 2003 18:53:30 -0000 Received: from p3EE24763.dip.t-dialin.net (HELO lisa) (62.226.71.99) by mail.gmx.net (mp015) with SMTP; 05 Aug 2003 20:53:30 +0200 From: "Julian Reschke" To: "Geoffrey M Clemm" , Date: Tue, 5 Aug 2003 20:53:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEEMIBAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7795 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Geoffrey M Clemm > Sent: Tuesday, August 05, 2003 8:20 PM > To: w3c-dist-auth@w3.org > Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY > and bindings) > > > > I think the granularity of is too fine. Well, we could choose a different name and make it less granular if you prefer that. > I'd prefer to just allow the use of the DAV header as a request header, > and if the client says: > > PROPFIND > DAV: 1,2,bind > > and then the server can use 208 responses (i.e. because "bind" appears > in the request DAV header). I dislike inventing new headers, but in fact that wouldn't be a new header. So we would define that clients can claim compatibility to a specific DAV feature by sending the header. In this particular case, we'd still need to define what "bind" means when it appears in a "DAV" header, because currently the draft doesn't. > Or if the request header should have its own name, use something like > a "DAV-CLIENT" header. Let's try to avoid that. I'd like to state again why I prefer to marshall this in the request body: we don't need to think about what the header means for methods other than PROPFIND, and we can use the same extension mechanism to fix another issue RFC2518/ACL altready has (not being able to marshall information about the fact that the content of a collection couldn't be listed). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Aug 6 09:04:37 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14883 for ; Wed, 6 Aug 2003 09:04:37 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h76D4bL3028920; Wed, 6 Aug 2003 09:04:37 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h76D46wQ028840; Wed, 6 Aug 2003 09:04:06 -0400 (EDT) Resent-Date: Wed, 6 Aug 2003 09:04:06 -0400 (EDT) Resent-Message-Id: <200308061304.h76D46wQ028840@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h76D44L3028806 for ; Wed, 6 Aug 2003 09:04:04 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h76D433c018750 for ; Wed, 6 Aug 2003 09:04:04 -0400 Received: (qmail 9166 invoked by uid 65534); 6 Aug 2003 13:03:57 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp023) with SMTP; 06 Aug 2003 15:03:57 +0200 From: "Julian Reschke" To: Date: Wed, 6 Aug 2003 15:03:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: another thought on "is element order significant" vs DTDs in WebDAV X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEGPIBAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7796 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, here are a few reasons why I think WebDAV should say that element ordering is irrelevant: 1) There are already existing well-deployed servers (in this case IIS) that get the ordering wrong (here: propstat content), thus clients can't rely on ordering anyway for all practical purposes, 2) Requiring a specific ordering will make protocol extensions extremely hard. For instance, take two independant extensions "A" and "B" that extend RFC2518 and add new elements to the same container element. If at a later point a new protocol revision tries to integrate both extensions, it will be hard to come up with a simple DTD that consolidates both changes. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Aug 6 12:44:55 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23911 for ; Wed, 6 Aug 2003 12:44:55 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h76GivL3001160; Wed, 6 Aug 2003 12:44:57 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h76Ginaa001078; Wed, 6 Aug 2003 12:44:49 -0400 (EDT) Resent-Date: Wed, 6 Aug 2003 12:44:49 -0400 (EDT) Resent-Message-Id: <200308061644.h76Ginaa001078@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h76GimL3001045 for ; Wed, 6 Aug 2003 12:44:48 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h76Gil3c022645 for ; Wed, 6 Aug 2003 12:44:47 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19kRP4-00007L-00; Wed, 06 Aug 2003 16:44:46 +0000 Received: from [198.144.203.248] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19kRP4-00007A-00; Wed, 06 Aug 2003 16:44:46 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , Date: Wed, 6 Aug 2003 09:45:28 -0700 Message-ID: <005101c35c3a$24b1da80$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Old-X-Envelope-To: julian.reschke@gmx.de, w3c-dist-auth@w3.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h76GimL3001045 Subject: RE: another thought on "is element order significant" vs DTDs in WebDAV X-Archived-At: http://www.w3.org/mid/005101c35c3a$24b1da80$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7797 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit I agree. I'll add a further reason, which is that it's more important for servers, which handle 1000s of clients, to be able to stream data out in the order most quickly obtainable, to maximize server performance. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke > Sent: Wednesday, August 06, 2003 6:04 AM > To: w3c-dist-auth@w3.org > Subject: another thought on "is element order significant" vs > DTDs in WebDAV > > > > Hi, > > here are a few reasons why I think WebDAV should say that > element ordering is irrelevant: > > 1) There are already existing well-deployed servers (in this > case IIS) that get the ordering wrong (here: propstat > content), thus clients can't rely on ordering anyway for all > practical purposes, > > 2) Requiring a specific ordering will make protocol > extensions extremely hard. For instance, take two independant > extensions "A" and "B" that extend RFC2518 and add new > elements to the same container element. If at a later point a > new protocol revision tries to integrate both extensions, it > will be hard to come up with a simple DTD that consolidates > both changes. > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Wed Aug 6 19:40:50 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10219 for ; Wed, 6 Aug 2003 19:40:50 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h76NemL3021574; Wed, 6 Aug 2003 19:40:48 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h76NeYgY020879; Wed, 6 Aug 2003 19:40:34 -0400 (EDT) Resent-Date: Wed, 6 Aug 2003 19:40:34 -0400 (EDT) Resent-Message-Id: <200308062340.h76NeYgY020879@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h76Ne1Mv019061 for ; Wed, 6 Aug 2003 19:40:28 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h76NCW3c022777 for ; Wed, 6 Aug 2003 19:12:33 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19kXSK-00052Q-00 for w3c-dist-auth@w3c.org; Wed, 06 Aug 2003 23:12:32 +0000 Received: from [198.144.203.248] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19kXSK-00052F-00 for w3c-dist-auth@w3c.org; Wed, 06 Aug 2003 23:12:32 +0000 From: "Lisa Dusseault" To: "Webdav WG" Date: Wed, 6 Aug 2003 16:13:14 -0700 Message-ID: <00aa01c35c70$502bb4c0$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h76Ne1Mv019061 Subject: Changing etag and getlastmodified on move/rename X-Archived-At: http://www.w3.org/mid/00aa01c35c70$502bb4c0$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7798 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit What's the general behavior for changing etag and getlastmodified when a resource is simply renamed via a MOVE, or when it's moved to another directory? Do any clients benefit if the ETag is the same after a MOVE? Would the client get confused if the ETag is the same but the getlastmodified value is different after a MOVE? Lisa From w3c-dist-auth-request@w3.org Thu Aug 7 03:04:04 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02803 for ; Thu, 7 Aug 2003 03:04:04 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h77747L3025306; Thu, 7 Aug 2003 03:04:07 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7773vP5025281; Thu, 7 Aug 2003 03:03:57 -0400 (EDT) Resent-Date: Thu, 7 Aug 2003 03:03:57 -0400 (EDT) Resent-Message-Id: <200308070703.h7773vP5025281@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7773tL3025248 for ; Thu, 7 Aug 2003 03:03:56 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h7773s3c011899 for ; Thu, 7 Aug 2003 03:03:55 -0400 Received: (qmail 28727 invoked by uid 65534); 7 Aug 2003 07:03:49 -0000 Received: from pD950C3B2.dip.t-dialin.net (HELO lisa) (217.80.195.178) by mail.gmx.net (mp025) with SMTP; 07 Aug 2003 09:03:49 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "Webdav WG" Date: Thu, 7 Aug 2003 09:03:36 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <00aa01c35c70$502bb4c0$f8cb90c6@lisalap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h7773tL3025248 Subject: RE: Changing etag and getlastmodified on move/rename X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEINIBAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7799 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Thursday, August 07, 2003 1:13 AM > To: Webdav WG > Subject: Changing etag and getlastmodified on move/rename > > > > > What's the general behavior for changing etag and getlastmodified > when a resource is simply renamed via a MOVE, or when it's moved > to another directory? > > Do any clients benefit if the ETag is the same after a MOVE? > Would the client get confused if the ETag is the same but the > getlastmodified value is different after a MOVE? It shouldn't. Also, the other combination can occur as well (ETag changes, but getlastmodified doesn't). This is because the ETag must be unique for all representations produced for a particular URL (+ variant-selecting headers), *not* the resource. Consider: /a/b with etag "1" /a/c with etag "1" MOVE /a/b -> a/c The resulting ETag for "/a/c" MUST NOT be 1. If a server needs a way to robustly identify a resource indepedantly of the URL, it should use DAV:resource-id. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Aug 10 10:26:53 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08366 for ; Sun, 10 Aug 2003 10:26:53 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7AEQqpI018171; Sun, 10 Aug 2003 10:26:52 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7AEQfNs018131; Sun, 10 Aug 2003 10:26:41 -0400 (EDT) Resent-Date: Sun, 10 Aug 2003 10:26:41 -0400 (EDT) Resent-Message-Id: <200308101426.h7AEQfNs018131@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7AEQepI018098 for ; Sun, 10 Aug 2003 10:26:40 -0400 (EDT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.86]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7AEQd1m020580 for ; Sun, 10 Aug 2003 10:26:39 -0400 Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h7AEQcCw012951 for ; Sun, 10 Aug 2003 07:26:38 -0700 (PDT) Received: from [192.168.1.101] (h209.241.40.162.ip.alltel.net [162.40.241.209]) (authenticated bits=0) by mac.com (Xserve/8.12.9/MantshX 2.0) with ESMTP id h7AEQX9e013816 for ; Sun, 10 Aug 2003 07:26:34 -0700 (PDT) Mime-Version: 1.0 X-Sender: frank.lowney@mail.mac.com Message-Id: In-Reply-To: <005101c35c3a$24b1da80$f8cb90c6@lisalap> References: <005101c35c3a$24b1da80$f8cb90c6@lisalap> Date: Sun, 10 Aug 2003 10:26:32 -0400 To: w3c-dist-auth@w3.org From: Frank Lowney Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: WebDAV Standards, browser & server compliance X-Archived-At: http://www.w3.org/mid/p05210601bb5bfbbc80d1@%5B192.168.1.101%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7800 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Please let me know if I am posting to the wrong list and suggest better venues if I'm off target. Posting: The Goal: This may be premature on our part but we are trying to take advantage of the WebDAV standard to accomplish two major goals across a variety of web-based facilities: 1) Eliminate or significantly reduce reliance upon FTP so as to obtain: a) higher levels of ease-of-use on behalf of content experts who are not technophiles b) higher levels of security (FTP sends PWs in the clear, SFTP is complex & finicky, etc.) c) divert the current high demand for proprietary solutions such as MS FrontPage server extensions. 2) Simplify the training of content experts publishing via the web by: a) Training for fewer applications (no instruction in a number of FTP apps) b) Train for apps that offer greater expressive freedom (Adobe GoLive and Macromedia Dreamweaver instead of MS FrontPage, AOL Press, Netscape Composer, etc.) that also use WebDAV effectively. The Problem: WebDAV simply doesn't seem to work consistently and well over the range of server and client environments that we must work with. The following sketches out those environments: Server Environments: NOTE: All claim to support the WebDAV standard but end user experience tends to contradict those claims. WebCT Vista 2.x (see http://www.webct.com/products/viewpage?name=products_vista). As I understand it, this Courseware Management System (CMS) is based upon the BEA WebLogic webserver and an Oracle 9i database. Apache webserver (as implemented in the MacOS X Server suite, see: http://www.apple.com/macosx/server/). WebSTAR V webserver (as implemented in the 4D WebSTAR Server Suite, see: http://www.4d.com/products/webstar.html) Client Environments: The overall issue here is that consistency and reliability is absent from all these environments. Consequently. our training efforts have not been as successful as we would like them to be. Windows 98, 2000, and XP NOTE: There are a variety of strategies that trainers must be prepared to present to end users: Internet Explorer & Web Folders, My Network Places, etc. None of these work completely as advertised across all environments. MacOS X Native OS support **appears** to be both robust and easy-to-use in the case of Apple's ostensibly WebDAV-based dotMac service but clients have difficulty in other WebDAV environments. MacOS Classic (8.6 to 9.2) Requires the use of an app such as Goliath. We have few clients using this OS/app combination so pilot error may be a disproportionately great factor but the experience reported here is spotty as in the case of all other client environments. Discussion: We are perhaps naive in expecting the WebDAV standard to be so complete and internally consistent as well as so thoroughly and faithfully implemented in both server and client environments that training could be simple, straightforward and w/o a raft of "ifs," "ands" or "buts." True? Is there an ongoing discussion somewhere for folks like us who are trying to implement WebDAV into our work flow? -- ===================================================================== Dr. Frank Lowney flowney@mail.gcsu.edu Director, Electronic Instructional Services, a unit of the Office of Information and Instructional Technology, Professional Pages: http://www.gcsu.edu/oiit/eis/ Personal Pages: http://www.faculty.de.gcsu.edu/~flowney Voice: (478) 445-5260 ===================================================================== We don't make instruction effective, we make effective instruction more accessible. From w3c-dist-auth-request@w3.org Sun Aug 10 14:40:38 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12623 for ; Sun, 10 Aug 2003 14:40:37 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7AIedpI014411; Sun, 10 Aug 2003 14:40:39 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7AIeG03014363; Sun, 10 Aug 2003 14:40:16 -0400 (EDT) Resent-Date: Sun, 10 Aug 2003 14:40:16 -0400 (EDT) Resent-Message-Id: <200308101840.h7AIeG03014363@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7AIeEpI014330 for ; Sun, 10 Aug 2003 14:40:14 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h7AIeD1m018616 for ; Sun, 10 Aug 2003 14:40:13 -0400 Received: (qmail 5790 invoked by uid 65534); 10 Aug 2003 18:40:01 -0000 Received: from p3EE24739.dip.t-dialin.net (HELO lisa) (62.226.71.57) by mail.gmx.net (mp005) with SMTP; 10 Aug 2003 20:40:01 +0200 From: "Julian Reschke" To: "Frank Lowney" , Date: Sun, 10 Aug 2003 20:39:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: WebDAV Standards, browser & server compliance X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEABICAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7801 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit First of all, you are absolutely on the right mailing list. There's also a special WebDAV interop list, but that one is mainly used to organize and exchange interop test results. You didn't mention exactly *what* problems you see. In general, there are quite a few vendors that advertise WebDAV compliance, but test their servers only with the Microsoft webfolder client, therefore having lots of problems with other clients. On the other hand, you may also see client issues. A few things you can do: - If you suspect a server compliance issue, as a first step run the Litmus test suite against it [1]. - If you suspect a Microsoft webfolder client issue, check the list of known versions and their issues [2]. - If you suspect a MacOSX client issue, report it here. Apple programmers are (hopefully they still are!) monitoring this list and are very responsive. - If you think you have found an Apache/moddav issue, you probably should report it to the dav-dev mailing list [3]. - Otherwise, just describe your specific problem here and we'll try to help. Hope this helps, Julian [1] [2] [3] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Frank Lowney > Sent: Sunday, August 10, 2003 4:27 PM > To: w3c-dist-auth@w3.org > Subject: WebDAV Standards, browser & server compliance > > > > Please let me know if I am posting to the wrong list and suggest > better venues if I'm off target. > > Posting: > > The Goal: > This may be premature on our part but we are trying to take advantage > of the WebDAV standard to accomplish two major goals across a variety > of web-based facilities: > > 1) Eliminate or significantly reduce reliance upon FTP so as to obtain: > a) higher levels of ease-of-use on behalf of content experts who > are not technophiles > b) higher levels of security (FTP sends PWs in the clear, SFTP is > complex & finicky, etc.) > c) divert the current high demand for proprietary solutions such > as MS FrontPage server extensions. > > 2) Simplify the training of content experts publishing via the web by: > a) Training for fewer applications (no instruction in a > number of FTP apps) > b) Train for apps that offer greater expressive freedom (Adobe > GoLive and Macromedia Dreamweaver instead of MS FrontPage, AOL Press, > Netscape Composer, etc.) that also use WebDAV effectively. > > The Problem: > WebDAV simply doesn't seem to work consistently and well over the > range of server and client environments that we must work with. The > following sketches out those environments: > > Server Environments: > NOTE: All claim to support the WebDAV standard but end user > experience tends to contradict those claims. > > WebCT Vista 2.x (see > http://www.webct.com/products/viewpage?name=products_vista). As I > understand it, this Courseware Management System (CMS) is based upon > the BEA WebLogic webserver and an Oracle 9i database. > > Apache webserver (as implemented in the MacOS X Server suite, see: > http://www.apple.com/macosx/server/). > > WebSTAR V webserver (as implemented in the 4D WebSTAR Server Suite, > see: http://www.4d.com/products/webstar.html) > > Client Environments: > The overall issue here is that consistency and reliability is absent > from all these environments. Consequently. our training efforts have > not been as successful as we would like them to be. > > Windows 98, 2000, and XP > NOTE: There are a variety of strategies that trainers must be > prepared to present to end users: Internet Explorer & Web Folders, My > Network Places, etc. None of these work completely as advertised > across all environments. > > MacOS X > Native OS support **appears** to be both robust and easy-to-use in > the case of Apple's ostensibly WebDAV-based dotMac service but > clients have difficulty in other WebDAV environments. > > MacOS Classic (8.6 to 9.2) > Requires the use of an app such as Goliath. We have few clients > using this OS/app combination so pilot error may be a > disproportionately great factor but the experience reported here is > spotty as in the case of all other client environments. > > Discussion: > > We are perhaps naive in expecting the WebDAV standard to be so > complete and internally consistent as well as so thoroughly and > faithfully implemented in both server and client environments that > training could be simple, straightforward and w/o a raft of "ifs," > "ands" or "buts." True? > > Is there an ongoing discussion somewhere for folks like us who are > trying to implement WebDAV into our work flow? > > -- > ===================================================================== > Dr. Frank Lowney flowney@mail.gcsu.edu > Director, Electronic Instructional Services, a unit of the > Office of Information and Instructional Technology, > Professional Pages: http://www.gcsu.edu/oiit/eis/ > Personal Pages: http://www.faculty.de.gcsu.edu/~flowney > Voice: (478) 445-5260 > ===================================================================== > We don't make instruction effective, we make effective instruction > more accessible. > From w3c-dist-auth-request@w3.org Mon Aug 11 13:37:59 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25323 for ; Mon, 11 Aug 2003 13:37:58 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BHbvpI006564; Mon, 11 Aug 2003 13:37:57 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7BHbkq4006558; Mon, 11 Aug 2003 13:37:46 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 13:37:46 -0400 (EDT) Resent-Message-Id: <200308111737.h7BHbkq4006558@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BHbipI006513 for ; Mon, 11 Aug 2003 13:37:44 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7BHbiB9022663 for ; Mon, 11 Aug 2003 13:37:44 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19mGc3-00046A-00; Mon, 11 Aug 2003 17:37:43 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19mGc3-00045z-00; Mon, 11 Aug 2003 17:37:43 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Webdav WG'" Date: Mon, 11 Aug 2003 10:38:28 -0700 Message-ID: <008101c3602f$5fd6fc00$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: julian.reschke@gmx.de, w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h7BHbipI006513 Subject: RE: Changing etag and getlastmodified on move/rename X-Archived-At: http://www.w3.org/mid/008101c3602f$5fd6fc00$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7802 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > It shouldn't. Also, the other combination can occur as well > (ETag changes, but getlastmodified doesn't). This is because > the ETag must be unique for all representations produced for > a particular URL (+ variant-selecting headers), *not* the resource. > > Consider: > > /a/b with etag "1" > /a/c with etag "1" > MOVE /a/b -> a/c > > The resulting ETag for "/a/c" MUST NOT be 1. > Wouldn't the "getlastmodified" value change during this operation as well? I'm assuming that at the beginning /a/b and /a/c had different content, which is why the ETag had to changed when the MOVE caused the content /a/c to be overwritten with the content from /a/b. If that's the case then the result of a GET to /a/c is different after the move, so the 'getlastmodified' must also change. Lisa From w3c-dist-auth-request@w3.org Mon Aug 11 13:42:06 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25638 for ; Mon, 11 Aug 2003 13:42:06 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BHg8pI008282; Mon, 11 Aug 2003 13:42:08 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7BHg86F008277; Mon, 11 Aug 2003 13:42:08 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 13:42:08 -0400 (EDT) Resent-Message-Id: <200308111742.h7BHg86F008277@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BHg6pI008189 for ; Mon, 11 Aug 2003 13:42:06 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7BHg5B9023399 for ; Mon, 11 Aug 2003 13:42:05 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19mGgH-0004CK-00; Mon, 11 Aug 2003 17:42:05 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19mGgG-0004C9-00; Mon, 11 Aug 2003 17:42:04 +0000 From: "Lisa Dusseault" To: "'Lisa Dusseault'" , "'Julian Reschke'" , Date: Mon, 11 Aug 2003 10:42:49 -0700 Message-ID: <008201c3602f$fba4d940$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <005101c35c3a$24b1da80$f8cb90c6@lisalap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: julian.reschke@gmx.de, lisa@xythos.com, w3c-dist-auth@w3.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h7BHg6pI008189 Subject: RE: another thought on "is element order significant" vs DTDs in WebDAV X-Archived-At: http://www.w3.org/mid/008201c3602f$fba4d940$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7803 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit I just noticed that the specification for PROPPATCH says that property changes MUST be applied in order. So clearly there are already some cases in WebDAV in which XML order of elements is significant. I still think it's a good idea to say at a minimum that the order of resources and properties in a PROPFIND response is irrelevant. So should we say that in general order is irrelevant but the PROPPATCH request body is an exception? Or should we say that in general order is important but the PROPFIND response body is an exception? I favour the first - the general rule being that order is irrelevant unless specified as relevant. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Lisa Dusseault > Sent: Wednesday, August 06, 2003 9:45 AM > To: 'Julian Reschke'; w3c-dist-auth@w3.org > Subject: RE: another thought on "is element order > significant" vs DTDs in WebDAV > > > > I agree. I'll add a further reason, which is that it's more > important for servers, which handle 1000s of clients, to be > able to stream data out in the order most quickly obtainable, > to maximize server performance. > > Lisa > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke > > Sent: Wednesday, August 06, 2003 6:04 AM > > To: w3c-dist-auth@w3.org > > Subject: another thought on "is element order significant" vs > > DTDs in WebDAV > > > > > > > > Hi, > > > > here are a few reasons why I think WebDAV should say that > > element ordering is irrelevant: > > > > 1) There are already existing well-deployed servers (in this > > case IIS) that get the ordering wrong (here: propstat > > content), thus clients can't rely on ordering anyway for all > > practical purposes, > > > > 2) Requiring a specific ordering will make protocol > > extensions extremely hard. For instance, take two independant > > extensions "A" and "B" that extend RFC2518 and add new > > elements to the same container element. If at a later point a > > new protocol revision tries to integrate both extensions, it > > will be hard to come up with a simple DTD that consolidates > > both changes. > > > > Julian > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > > > > > From w3c-dist-auth-request@w3.org Mon Aug 11 13:46:35 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25740 for ; Mon, 11 Aug 2003 13:46:35 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BHkYpI009891; Mon, 11 Aug 2003 13:46:34 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7BHkY0g009883; Mon, 11 Aug 2003 13:46:34 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 13:46:34 -0400 (EDT) Resent-Message-Id: <200308111746.h7BHkY0g009883@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BHkTpI009741 for ; Mon, 11 Aug 2003 13:46:29 -0400 (EDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7BHkTB9024188; Mon, 11 Aug 2003 13:46:29 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7BHkN4X217916; Mon, 11 Aug 2003 13:46:23 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7BHkMMS115798; Mon, 11 Aug 2003 13:46:22 -0400 In-Reply-To: <004901c3602b$64c024c0$f8cb90c6@lisalap> To: ietf-dav-versioning@w3.org, " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 11 Aug 2003 13:46:27 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 08/11/2003 13:46:22, Serialize complete at 08/11/2003 13:46:22 Content-Type: text/plain; charset="US-ASCII" Subject: RE: DAV:displayname with versions X-Archived-At: http://www.w3.org/mid/OFA49AE41A.793847AA-ON85256D7F.005F6C9E-85256D7F.0061A3CB@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7804 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Yes, 3253 leaves the definition of versioning behavior for live properties up to the standard that defines those live properties. So we should probably try to define the versioning behavior for 2518 properties in 2518bis. In general, the simplest default versioning behavior for a property such as DAV:displayname is to treat it the same as a dead property, i.e. it is an immutable copy of the value of that property on the VCR at CHECKIN time. Does this work for folks currently doing versioning? (I couldn't quite tell from Lisa's description whether this is the Xythos behavior or not). Cheers, Geoff Lisa wrote on 08/11/2003 01:09:58 PM: > > Sure, every version must have the displayname property so you can get it > with PROPFIND. However, no specification requires that to be either > writable or protected on a version, so on some servers it won't be writable. > Also no specification requires it to be either static or dynamic, so it's > possible on some servers that the property would be protected, and it would > change whenever the value on the VCR changed. > > I believe on Xythos WFS the displayname property is protected and static on > versions. It will always have the same value as the displayname property of > the VCR. > > -----Original Message----- > > From: Geoffrey M Clemm > > > > There is no concept of a "global" property of a version. > > Each version is a separate resource, with its own properties. > > So each version has its own DAV:displayname property. > > > > But there is a natural place to put a "global" property of a > > version, namely, as a property on the VersionHistory of that version. > > Horst wrote on 08/11/2003 11:47:38 AM: > > > > > > Just a simple question, is the DAV:displayname of a > > resource "global" > > > ? Or is it possible to have different DAV:displayname(s) > > for different > > > versions of the same resource. From w3c-dist-auth-request@w3.org Mon Aug 11 13:48:27 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25824 for ; Mon, 11 Aug 2003 13:48:26 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BHmTpI010778; Mon, 11 Aug 2003 13:48:29 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7BHmRHY010712; Mon, 11 Aug 2003 13:48:27 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 13:48:27 -0400 (EDT) Resent-Message-Id: <200308111748.h7BHmRHY010712@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BHmPpI010679 for ; Mon, 11 Aug 2003 13:48:25 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7BHmPB9024540 for ; Mon, 11 Aug 2003 13:48:25 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7BHmKPS196486 for ; Mon, 11 Aug 2003 13:48:20 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7BHmHAB119206 for ; Mon, 11 Aug 2003 13:48:19 -0400 In-Reply-To: <008201c3602f$fba4d940$f8cb90c6@lisalap> To: w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 11 Aug 2003 13:48:10 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 08/11/2003 13:48:18, Serialize complete at 08/11/2003 13:48:18 Content-Type: text/plain; charset="US-ASCII" Subject: RE: another thought on "is element order significant" vs DTDs in WebDAV X-Archived-At: http://www.w3.org/mid/OF6F223425.EFFE8604-ON85256D7F.0061B67A-85256D7F.0061CBEA@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7805 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I support the former as well (order is irrelevant unless explicitly stated otherwise). Cheers, Geoff w3c-dist-auth-request@w3.org wrote on 08/11/2003 01:42:49 PM: > > I just noticed that the specification for PROPPATCH says that property > changes MUST be applied in order. So clearly there are already some cases > in WebDAV in which XML order of elements is significant. > > I still think it's a good idea to say at a minimum that the order of > resources and properties in a PROPFIND response is irrelevant. So should we > say that in general order is irrelevant but the PROPPATCH request body is an > exception? Or should we say that in general order is important but the > PROPFIND response body is an exception? > > I favour the first - the general rule being that order is irrelevant unless > specified as relevant. > > Lisa > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Lisa Dusseault > > Sent: Wednesday, August 06, 2003 9:45 AM > > To: 'Julian Reschke'; w3c-dist-auth@w3.org > > Subject: RE: another thought on "is element order > > significant" vs DTDs in WebDAV > > > > > > > > I agree. I'll add a further reason, which is that it's more > > important for servers, which handle 1000s of clients, to be > > able to stream data out in the order most quickly obtainable, > > to maximize server performance. > > > > Lisa > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke > > > Sent: Wednesday, August 06, 2003 6:04 AM > > > To: w3c-dist-auth@w3.org > > > Subject: another thought on "is element order significant" vs > > > DTDs in WebDAV > > > > > > > > > > > > Hi, > > > > > > here are a few reasons why I think WebDAV should say that > > > element ordering is irrelevant: > > > > > > 1) There are already existing well-deployed servers (in this > > > case IIS) that get the ordering wrong (here: propstat > > > content), thus clients can't rely on ordering anyway for all > > > practical purposes, > > > > > > 2) Requiring a specific ordering will make protocol > > > extensions extremely hard. For instance, take two independant > > > extensions "A" and "B" that extend RFC2518 and add new > > > elements to the same container element. If at a later point a > > > new protocol revision tries to integrate both extensions, it > > > will be hard to come up with a simple DTD that consolidates > > > both changes. > > > > > > Julian > > > > > > -- > > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > > > > > > > > > > > > > > From w3c-dist-auth-request@w3.org Mon Aug 11 13:57:13 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26083 for ; Mon, 11 Aug 2003 13:57:13 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BHvGpI012601; Mon, 11 Aug 2003 13:57:16 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7BHvG3V012592; Mon, 11 Aug 2003 13:57:16 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 13:57:16 -0400 (EDT) Resent-Message-Id: <200308111757.h7BHvG3V012592@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BHvEpI012559 for ; Mon, 11 Aug 2003 13:57:14 -0400 (EDT) Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7BHvDB9025813 for ; Mon, 11 Aug 2003 13:57:13 -0400 Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27]) by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id h7BHv7O12790 for ; Mon, 11 Aug 2003 10:57:08 -0700 (PDT) Message-ID: <3F37D8F3.1060907@cse.ucsc.edu> Date: Mon, 11 Aug 2003 10:57:07 -0700 From: Elias Sinderson Reply-To: w3c-dist-auth@w3.org User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <008201c3602f$fba4d940$f8cb90c6@lisalap> Content-Type: multipart/alternative; boundary="------------010109050905070407030507" Subject: Re: another thought on "is element order significant" vs DTDs in WebDAV X-Archived-At: http://www.w3.org/mid/3F37D8F3.1060907@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7806 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --------------010109050905070407030507 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit +1, being less strict unless otherwise noted is the best approach. Elias Lisa Dusseault wrote: >I just noticed that the specification for PROPPATCH says that property >changes MUST be applied in order. So clearly there are already some cases >in WebDAV in which XML order of elements is significant. > >I still think it's a good idea to say at a minimum that the order of >resources and properties in a PROPFIND response is irrelevant. So should we >say that in general order is irrelevant but the PROPPATCH request body is an >exception? Or should we say that in general order is important but the >PROPFIND response body is an exception? > >I favour the first - the general rule being that order is irrelevant unless >specified as relevant. > >Lisa > > > >>-----Original Message----- >>From: w3c-dist-auth-request@w3.org >>[mailto:w3c-dist-auth-request@w3.org] On Behalf Of Lisa Dusseault >>Sent: Wednesday, August 06, 2003 9:45 AM >>To: 'Julian Reschke'; w3c-dist-auth@w3.org >>Subject: RE: another thought on "is element order >>significant" vs DTDs in WebDAV >> >> >> >>I agree. I'll add a further reason, which is that it's more >>important for servers, which handle 1000s of clients, to be >>able to stream data out in the order most quickly obtainable, >>to maximize server performance. >> >>Lisa >> >> >> >>>-----Original Message----- >>>From: w3c-dist-auth-request@w3.org >>>[mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke >>>Sent: Wednesday, August 06, 2003 6:04 AM >>>To: w3c-dist-auth@w3.org >>>Subject: another thought on "is element order significant" vs >>>DTDs in WebDAV >>> >>> >>> >>>Hi, >>> >>>here are a few reasons why I think WebDAV should say that >>>element ordering is irrelevant: >>> >>>1) There are already existing well-deployed servers (in this >>>case IIS) that get the ordering wrong (here: propstat >>>content), thus clients can't rely on ordering anyway for all >>>practical purposes, >>> >>>2) Requiring a specific ordering will make protocol >>>extensions extremely hard. For instance, take two independant >>>extensions "A" and "B" that extend RFC2518 and add new >>>elements to the same container element. If at a later point a >>>new protocol revision tries to integrate both extensions, it >>>will be hard to come up with a simple DTD that consolidates >>>both changes. >>> >>>Julian >>> >>>-- >>>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 >>> >>> >>> >>> >> >> >> >> > > > > --------------010109050905070407030507 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit +1, being less strict unless otherwise noted is the best approach.

Elias


Lisa Dusseault wrote:
I just noticed that the specification for PROPPATCH says that property
changes MUST be applied in order.  So clearly there are already some cases
in WebDAV in which XML order of elements is significant.  

I still think it's a good idea to say at a minimum that the order of
resources and properties in a PROPFIND response is irrelevant.  So should we
say that in general order is irrelevant but the PROPPATCH request body is an
exception?  Or should we say that in general order is important but the
PROPFIND response body is an exception?

I favour the first - the general rule being that order is irrelevant unless
specified as relevant. 

Lisa

  
-----Original Message-----
From: w3c-dist-auth-request@w3.org 
[mailto:w3c-dist-auth-request@w3.org] On Behalf Of Lisa Dusseault
Sent: Wednesday, August 06, 2003 9:45 AM
To: 'Julian Reschke'; w3c-dist-auth@w3.org
Subject: RE: another thought on "is element order 
significant" vs DTDs in WebDAV



I agree.  I'll add a further reason, which is that it's more 
important for servers, which handle 1000s of clients, to be 
able to stream data out in the order most quickly obtainable, 
to maximize server performance.

Lisa

    
-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke
Sent: Wednesday, August 06, 2003 6:04 AM
To: w3c-dist-auth@w3.org
Subject: another thought on "is element order significant" vs 
DTDs in WebDAV



Hi,

here are a few reasons why I think WebDAV should say that
element ordering is irrelevant:

1) There are already existing well-deployed servers (in this
case IIS) that get the ordering wrong (here: propstat 
content), thus clients can't rely on ordering anyway for all 
practical purposes,

2) Requiring a specific ordering will make protocol
extensions extremely hard. For instance, take two independant 
extensions "A" and "B" that extend RFC2518 and add new 
elements to the same container element. If at a later point a 
new protocol revision  tries to integrate both extensions, it 
will be hard to come up with a simple DTD that consolidates 
both changes.

Julian

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

--------------010109050905070407030507-- From w3c-dist-auth-request@w3.org Mon Aug 11 14:03:48 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26400 for ; Mon, 11 Aug 2003 14:03:47 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BI3npI013949; Mon, 11 Aug 2003 14:03:49 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7BI3jLi013878; Mon, 11 Aug 2003 14:03:45 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 14:03:45 -0400 (EDT) Resent-Message-Id: <200308111803.h7BI3jLi013878@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BI3epI013751 for ; Mon, 11 Aug 2003 14:03:40 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7BI3eB9026502 for ; Mon, 11 Aug 2003 14:03:40 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19mH19-0004dY-00; Mon, 11 Aug 2003 18:03:39 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19mH19-0004dN-00; Mon, 11 Aug 2003 18:03:39 +0000 From: "Lisa Dusseault" To: "'Geoffrey M Clemm'" , , "'webdav'" Date: Mon, 11 Aug 2003 11:04:24 -0700 Message-ID: <008d01c36032$ff666dc0$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: geoffrey.clemm@us.ibm.com, ietf-dav-versioning@w3.org, w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h7BI3epI013751 Subject: RE: DAV:displayname with versions X-Archived-At: http://www.w3.org/mid/008d01c36032$ff666dc0$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7807 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit That isn't quite the Xythos WFS behavior. If you MOVE a VCR, its displayname changes to the current name. Thus the displayname changes for all the versions as well. They aren't entirely immutable, in other words. I wouldn't put the versioning behavior of properties in RFC2518bis, however, we need to keep changes there down so we get finished in finite time and get draft standard status with tested interoperable features. If we think we can specify property behavior for versioning it could just as easily be done in a separate short draft. Speaking of this, what are the issues for the binding draft and the behavior of live properties? Does the binding draft sufficiently cover what happens with versioning in the mix? Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm > Sent: Monday, August 11, 2003 10:46 AM > To: ietf-dav-versioning@w3.org; webdav > Subject: RE: DAV:displayname with versions > > > > Yes, 3253 leaves the definition of versioning behavior for > live properties up to the standard that defines those live properties. > > > So we should probably try to define the versioning behavior for 2518 > properties > in 2518bis. In general, the simplest default versioning > behavior for a property such as DAV:displayname is to treat > it the same as a dead > property, > i.e. it is an immutable copy of the value of that property on > the VCR at CHECKIN time. Does this work for folks currently > doing versioning? (I couldn't quite tell from Lisa's > description whether this is the Xythos behavior or not). > > Cheers, > Geoff > > Lisa wrote on 08/11/2003 01:09:58 PM: > > > > Sure, every version must have the displayname property so > you can get > > it with PROPFIND. However, no specification requires that to be > > either writable or protected on a version, so on some > servers it won't > > be > writable. > > Also no specification requires it to be either static or dynamic, so > it's > > possible on some servers that the property would be > protected, and it > would > > change whenever the value on the VCR changed. > > > > I believe on Xythos WFS the displayname property is protected and > > static > on > > versions. It will always have the same value as the displayname > property of > > the VCR. > > > > -----Original Message----- > > > From: Geoffrey M Clemm > > > > > > There is no concept of a "global" property of a version. Each > > > version is a separate resource, with its own properties. So each > > > version has its own DAV:displayname property. > > > > > > But there is a natural place to put a "global" property of a > > > version, namely, as a property on the VersionHistory of > that version. > > > > Horst wrote on 08/11/2003 11:47:38 AM: > > > > > > > > Just a simple question, is the DAV:displayname of a > > > resource "global" > > > > ? Or is it possible to have different DAV:displayname(s) > > > for different > > > > versions of the same resource. > > From w3c-dist-auth-request@w3.org Mon Aug 11 14:25:55 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27282 for ; Mon, 11 Aug 2003 14:25:54 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BIPvpI025177; Mon, 11 Aug 2003 14:25:57 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7BIPtR8025144; Mon, 11 Aug 2003 14:25:55 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 14:25:55 -0400 (EDT) Resent-Message-Id: <200308111825.h7BIPtR8025144@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BIPnpI024910 for ; Mon, 11 Aug 2003 14:25:49 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h7BIPl3b031193 for ; Mon, 11 Aug 2003 14:25:48 -0400 Received: from lisa ([192.168.1.23]) by greenbytes.de (greenbytes.de [217.5.201.11]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 58-md50000000009.tmp for ; Mon, 11 Aug 2003 20:25:40 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "'Geoffrey M Clemm'" , , "'webdav'" Date: Mon, 11 Aug 2003 20:25:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <008d01c36032$ff666dc0$f8cb90c6@lisalap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: greenbytes.de, Mon, 11 Aug 2003 20:25:40 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.23 X-Return-Path: julian.reschke@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: RE: DAV:displayname with versions X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGECKICAA.julian.reschke@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7808 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Monday, August 11, 2003 8:04 PM > To: 'Geoffrey M Clemm'; ietf-dav-versioning@w3.org; 'webdav' > Subject: RE: DAV:displayname with versions > > > > That isn't quite the Xythos WFS behavior. If you MOVE a VCR, its > displayname changes to the current name. Thus the displayname changes for > all the versions as well. They aren't entirely immutable, in other words. May I ask what this is good for? If the DAV:displayname always equals the last path component, it's much simpler not to have it at all. [WYes, I know that IIS behaves the same -- however this doesn't make it right] > I wouldn't put the versioning behavior of properties in RFC2518bis, > however, we need to keep changes there down so we get finished in finite > time and get draft standard status with tested interoperable features. If > we think we can specify property behavior for versioning it could just as > easily be done in a separate short draft. > > Speaking of this, what are the issues for the binding draft and the behavior > of live properties? Does the binding draft sufficiently cover what happens > with versioning in the mix? Which reminds me that having the DAV:displayname change with MOVE is deeply incompatible with bindings. In particular, consider one resource A with bindings a' and a''. How does the DAV:displayname obtained from a' change if you rename a''? Don't tell me that the property value will vary depending on the URL you use. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Aug 11 14:31:16 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27457 for ; Mon, 11 Aug 2003 14:31:15 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BIVIpI026504; Mon, 11 Aug 2003 14:31:18 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7BIVIbk026498; Mon, 11 Aug 2003 14:31:18 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 14:31:18 -0400 (EDT) Resent-Message-Id: <200308111831.h7BIVIbk026498@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BIVFpI026401 for ; Mon, 11 Aug 2003 14:31:15 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h7BIVD3b031857 for ; Mon, 11 Aug 2003 14:31:14 -0400 Received: from lisa ([192.168.1.23]) by greenbytes.de (greenbytes.de [217.5.201.11]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 61-md50000000009.tmp for ; Mon, 11 Aug 2003 20:30:36 +0200 From: "Julian Reschke" To: "Geoffrey M Clemm" , , " webdav" Date: Mon, 11 Aug 2003 20:30:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: greenbytes.de, Mon, 11 Aug 2003 20:30:36 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.23 X-Return-Path: julian.reschke@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: RE: DAV:displayname with versions X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAECLICAA.julian.reschke@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7809 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Geoffrey M Clemm > Sent: Monday, August 11, 2003 7:46 PM > To: ietf-dav-versioning@w3.org; webdav > Subject: RE: DAV:displayname with versions > > > > Yes, 3253 leaves the definition of versioning behavior for live properties > up to the standard that defines those live properties. > > > So we should probably try to define the versioning behavior for 2518 > properties > in 2518bis. In general, the simplest default versioning behavior for a > property such as DAV:displayname is to treat it the same as a dead > property, > i.e. it is an immutable copy of the value of that property on the VCR at > CHECKIN time. Does this work for folks currently doing versioning? Yes. > (I couldn't quite tell from Lisa's description whether this is > the Xythos behavior or not). I'd really like to see a use case that conflicts with Geoff's definition. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Aug 11 14:34:36 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27547 for ; Mon, 11 Aug 2003 14:34:36 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BIYdpI027197; Mon, 11 Aug 2003 14:34:39 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7BIYce8027191; Mon, 11 Aug 2003 14:34:38 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 14:34:38 -0400 (EDT) Resent-Message-Id: <200308111834.h7BIYce8027191@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BIYapI027156 for ; Mon, 11 Aug 2003 14:34:36 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h7BIYZ3b032444 for ; Mon, 11 Aug 2003 14:34:35 -0400 Received: (qmail 15557 invoked by uid 65534); 11 Aug 2003 18:34:29 -0000 Received: from p3EE24753.dip.t-dialin.net (HELO lisa) (62.226.71.83) by mail.gmx.net (mp022) with SMTP; 11 Aug 2003 20:34:29 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , Date: Mon, 11 Aug 2003 20:34:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <008201c3602f$fba4d940$f8cb90c6@lisalap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: another thought on "is element order significant" vs DTDs in WebDAV X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGECLICAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7810 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Monday, August 11, 2003 7:43 PM > To: 'Lisa Dusseault'; 'Julian Reschke'; w3c-dist-auth@w3.org > Subject: RE: another thought on "is element order significant" vs DTDs > in WebDAV > > > > I just noticed that the specification for PROPPATCH says that property > changes MUST be applied in order. So clearly there are already some cases > in WebDAV in which XML order of elements is significant. Agreed. Order may be significant for *execution* (and I think the spec already clearly says where this is the case). I was considering *validity*. > I still think it's a good idea to say at a minimum that the order of > resources and properties in a PROPFIND response is irrelevant. > So should we > say that in general order is irrelevant but the PROPPATCH request > body is an > exception? Or should we say that in general order is important but the > PROPFIND response body is an exception? The former. > I favour the first - the general rule being that order is irrelevant unless > specified as relevant. Correct. A related issue is when unknown elements are to be ignored (generally yes, but for instance not within PROPFIND/prop). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Aug 11 14:41:10 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27682 for ; Mon, 11 Aug 2003 14:41:10 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BIfDpI028552; Mon, 11 Aug 2003 14:41:13 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7BIfB8m028546; Mon, 11 Aug 2003 14:41:11 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 14:41:11 -0400 (EDT) Resent-Message-Id: <200308111841.h7BIfB8m028546@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BIf9pI028512 for ; Mon, 11 Aug 2003 14:41:09 -0400 (EDT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h7BIf83b001237 for ; Mon, 11 Aug 2003 14:41:09 -0400 Received: (qmail 26242 invoked by uid 65534); 11 Aug 2003 18:40:57 -0000 Received: from p3EE24753.dip.t-dialin.net (HELO lisa) (62.226.71.83) by mail.gmx.net (mp015) with SMTP; 11 Aug 2003 20:40:57 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Webdav WG'" Date: Mon, 11 Aug 2003 20:40:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <008101c3602f$5fd6fc00$f8cb90c6@lisalap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h7BIf9pI028512 Subject: RE: Changing etag and getlastmodified on move/rename X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGECMICAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7811 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Monday, August 11, 2003 7:38 PM > To: 'Julian Reschke'; 'Webdav WG' > Subject: RE: Changing etag and getlastmodified on move/rename > > > > > It shouldn't. Also, the other combination can occur as well > > (ETag changes, but getlastmodified doesn't). This is because > > the ETag must be unique for all representations produced for > > a particular URL (+ variant-selecting headers), *not* the resource. > > > > Consider: > > > > /a/b with etag "1" > > /a/c with etag "1" > > MOVE /a/b -> a/c > > > > The resulting ETag for "/a/c" MUST NOT be 1. > > > > Wouldn't the "getlastmodified" value change during this operation > as well? I'm assuming that at the beginning /a/b and /a/c had > different content, which is why the ETag had to changed when the > MOVE caused the content /a/c to be overwritten with the content > from /a/b. If that's the case then the result of a GET to /a/c > is different after the move, so the 'getlastmodified' must also change. Most of the time yes, but not always: if /a/b and /a/c might have had the same DAV:getlastmodified property before the MOVE, in which case the date for /a/c may not change (one of the reasons why ETags are better than dates). Seems that the HTTP caching (lastmodified and etag) aren't very compatible with WebDAV namespace operations. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Aug 11 15:47:03 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01509 for ; Mon, 11 Aug 2003 15:47:03 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BJl6pI024796; Mon, 11 Aug 2003 15:47:06 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7BJl0PW024766; Mon, 11 Aug 2003 15:47:00 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 15:47:00 -0400 (EDT) Resent-Message-Id: <200308111947.h7BJl0PW024766@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BJkwpI024729 for ; Mon, 11 Aug 2003 15:46:58 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7BJkv3b013282 for ; Mon, 11 Aug 2003 15:46:57 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01482; Mon, 11 Aug 2003 15:46:52 -0400 (EDT) Message-Id: <200308111946.PAA01482@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 11 Aug 2003 15:46:52 -0400 Subject: I-D ACTION:draft-ietf-webdav-ordering-protocol-10.txt X-Archived-At: http://www.w3.org/mid/200308111946.PAA01482@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7812 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : WebDAV Ordered Collections Protocol Author(s) : E. Whitehead, J. Reschke Filename : draft-ietf-webdav-ordering-protocol-10.txt Pages : 39 Date : 2003-8-11 This specification extends the WebDAV Distributed Authoring Protocol to support server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering. Distribution of this document is unlimited. Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at w3c-dist-auth@w3.org, which may be joined by sending a message with subject 'subscribe' to w3c-dist-auth-request@w3.org. Discussions of the WEBDAV working group are archived at URL: http://lists.w3.org/Archives/Public/w3c-dist-auth/. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-protocol-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-ordering-protocol-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-ordering-protocol-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-11143403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-ordering-protocol-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-ordering-protocol-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-11143403.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Mon Aug 11 15:53:40 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02324 for ; Mon, 11 Aug 2003 15:53:39 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BJrgpI027991; Mon, 11 Aug 2003 15:53:42 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7BJrgAD027970; Mon, 11 Aug 2003 15:53:42 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 15:53:42 -0400 (EDT) Resent-Message-Id: <200308111953.h7BJrgAD027970@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BJrcpI027837 for ; Mon, 11 Aug 2003 15:53:38 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7BJrc3b014208; Mon, 11 Aug 2003 15:53:38 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7BJrSKb301818; Mon, 11 Aug 2003 15:53:28 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7BJrKAB112982; Mon, 11 Aug 2003 15:53:27 -0400 In-Reply-To: <008d01c36032$ff666dc0$f8cb90c6@lisalap> To: "Lisa Dusseault" Cc: ietf-dav-versioning@w3.org, "'webdav'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 11 Aug 2003 15:51:37 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 08/11/2003 15:53:27, Serialize complete at 08/11/2003 15:53:27 Content-Type: text/plain; charset="US-ASCII" Subject: RE: DAV:displayname with versions X-Archived-At: http://www.w3.org/mid/OFC75E4736.01C6BBF5-ON85256D7F.006C4340-85256D7F.006D1932@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7813 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree that we want to finish RFC2518bis in a finite amount of time, but I disagree that versioning behavior of RFC2518 properties should be defined in a separate draft. Any new WebDAV draft should fully define the behavior of any live property it defines, and versioning is a standard part of the WebDAV family (after all, it is "WebDAV", not "WebDA" :-). Cheers, Geoff "Lisa Dusseault" wrote on 08/11/2003 02:04:24 PM: > That isn't quite the Xythos WFS behavior. If you MOVE a VCR, its > displayname changes to the current name. Thus the displayname changes for > all the versions as well. They aren't entirely immutable, in other words. > > I wouldn't put the versioning behavior of properties in RFC2518bis, > however, we need to keep changes there down so we get finished in finite > time and get draft standard status with tested interoperable features. If > we think we can specify property behavior for versioning it could just as > easily be done in a separate short draft. > > Speaking of this, what are the issues for the binding draft and the behavior > of live properties? Does the binding draft sufficiently cover what happens > with versioning in the mix? > > Lisa > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm > > Sent: Monday, August 11, 2003 10:46 AM > > To: ietf-dav-versioning@w3.org; webdav > > Subject: RE: DAV:displayname with versions > > > > > > > > Yes, 3253 leaves the definition of versioning behavior for > > live properties up to the standard that defines those live properties. > > > > > > So we should probably try to define the versioning behavior for 2518 > > properties > > in 2518bis. In general, the simplest default versioning > > behavior for a property such as DAV:displayname is to treat > > it the same as a dead > > property, > > i.e. it is an immutable copy of the value of that property on > > the VCR at CHECKIN time. Does this work for folks currently > > doing versioning? (I couldn't quite tell from Lisa's > > description whether this is the Xythos behavior or not). > > > > Cheers, > > Geoff > > > > Lisa wrote on 08/11/2003 01:09:58 PM: > > > > > > Sure, every version must have the displayname property so > > you can get > > > it with PROPFIND. However, no specification requires that to be > > > either writable or protected on a version, so on some > > servers it won't > > > be > > writable. > > > Also no specification requires it to be either static or dynamic, so > > it's > > > possible on some servers that the property would be > > protected, and it > > would > > > change whenever the value on the VCR changed. > > > > > > I believe on Xythos WFS the displayname property is protected and > > > static > > on > > > versions. It will always have the same value as the displayname > > property of > > > the VCR. > > > > > > -----Original Message----- > > > > From: Geoffrey M Clemm > > > > > > > > There is no concept of a "global" property of a version. Each > > > > version is a separate resource, with its own properties. So each > > > > version has its own DAV:displayname property. > > > > > > > > But there is a natural place to put a "global" property of a > > > > version, namely, as a property on the VersionHistory of > > that version. > > > > > > Horst wrote on 08/11/2003 11:47:38 AM: > > > > > > > > > > Just a simple question, is the DAV:displayname of a > > > > resource "global" > > > > > ? Or is it possible to have different DAV:displayname(s) > > > > for different > > > > > versions of the same resource. > > > > > > From w3c-dist-auth-request@w3.org Mon Aug 11 16:05:34 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03873 for ; Mon, 11 Aug 2003 16:05:34 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BK5apI002063; Mon, 11 Aug 2003 16:05:36 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7BK5VDH001973; Mon, 11 Aug 2003 16:05:31 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 16:05:31 -0400 (EDT) Resent-Message-Id: <200308112005.h7BK5VDH001973@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BK5TpI001918 for ; Mon, 11 Aug 2003 16:05:29 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7BK5T3b015851 for ; Mon, 11 Aug 2003 16:05:29 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19mIv2-0000Pg-00; Mon, 11 Aug 2003 20:05:28 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19mIv2-0000PF-00; Mon, 11 Aug 2003 20:05:28 +0000 From: "Lisa Dusseault" To: , "'Julian Reschke'" , Date: Mon, 11 Aug 2003 13:06:10 -0700 Message-ID: <009701c36044$0397d2b0$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: hardie@qualcomm.com, julian.reschke@gmx.de, w3c-dist-auth@w3.org Subject: RE: URI scheme uniqueness X-Archived-At: http://www.w3.org/mid/009701c36044$0397d2b0$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7814 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > As you say above, the two are independent; you can have IETF > schemes which are not unique and non-IETF schemes which are. Great, I think we all agree on that... > If you are an implementor considering using a non-IETF registered URI > scheme _for_any_purpose_, > don't lose sight of what using a registered URI scheme gives you. > Non-registered > schemes risk overlap and risk misunderstandings of syntax > developing over time. I agree with this so the next version of RFC2518bis will recommend using a registered scheme unless I start hearing more disagreement. > A presumption (possibly unwarranted) on my part was that > anyone choosing an unregistered URI scheme for lock tokens is > doing so to reuse scheme they are already using for some > other purpose. Hence the motivation to make the general plug > above to register schemes whenever they can. I hadn't made that presumption but it's a fair consideration. > I suspect that this presumes something about the way clients > should behave; to wit, if they get a lock token DAV:1234 > issued by server dav.example.com, they will not get whacked > out when they get a lock token DAV:1234 issued by server > dav.example.net (obviously, for some other resource). I > believe that this would be good engineering, obviously, but I > think maintaining a stricter requirement is useful. I think that although we have the uniqueness requirement already (it can't be made stricter very easily) clients simply can't assume that lock tokens really are globally unique. Should we add some client advice to RFC2518bis, saying that in practice clients cannot assume that lock tokens will be unique across servers and should not be used as unique lookups in client code? It provides little advantage to the client to assume uniqueness, and it could be an easy source of bugs. This falls under the IETF principle of being generous in what you accept (non-unique tokens) but strict in what you generate (unique only). Lisa From w3c-dist-auth-request@w3.org Mon Aug 11 16:14:40 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04495 for ; Mon, 11 Aug 2003 16:14:39 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BKEgpI005205; Mon, 11 Aug 2003 16:14:43 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7BKEgNL005199; Mon, 11 Aug 2003 16:14:42 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 16:14:42 -0400 (EDT) Resent-Message-Id: <200308112014.h7BKEgNL005199@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BKEfpI005165 for ; Mon, 11 Aug 2003 16:14:41 -0400 (EDT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h7BKEe3b016902 for ; Mon, 11 Aug 2003 16:14:40 -0400 Received: (qmail 32573 invoked by uid 65534); 11 Aug 2003 20:14:34 -0000 Received: from p3EE24753.dip.t-dialin.net (HELO lisa) (62.226.71.83) by mail.gmx.net (mp025) with SMTP; 11 Aug 2003 22:14:34 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , , "'Julian Reschke'" , Date: Mon, 11 Aug 2003 22:14:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <009701c36044$0397d2b0$f8cb90c6@lisalap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: URI scheme uniqueness X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEDAICAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7815 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Monday, August 11, 2003 10:06 PM > To: hardie@qualcomm.com; 'Julian Reschke'; w3c-dist-auth@w3.org > Subject: RE: URI scheme uniqueness > > ... > > > If you are an implementor considering using a non-IETF registered URI > > scheme _for_any_purpose_, > > don't lose sight of what using a registered URI scheme gives you. > > Non-registered > > schemes risk overlap and risk misunderstandings of syntax > > developing over time. > > I agree with this so the next version of RFC2518bis will recommend > using a registered scheme unless I start hearing more disagreement. Sounds good so far. > > I suspect that this presumes something about the way clients > > should behave; to wit, if they get a lock token DAV:1234 > > issued by server dav.example.com, they will not get whacked > > out when they get a lock token DAV:1234 issued by server > > dav.example.net (obviously, for some other resource). I > > believe that this would be good engineering, obviously, but I > > think maintaining a stricter requirement is useful. > > I think that although we have the uniqueness requirement already > (it can't be made stricter very easily) clients simply can't assume > that lock tokens really are globally unique. Wait a minute. The spec says that they MUST be globally unique. It even defines a URI scheme that is supposed to guarantee that uniqueness. And now you want to tell clients that they can't rely on that??? > Should we add some client advice to RFC2518bis, saying that in > practice clients cannot assume that lock tokens will be unique > across servers and should not be used as unique lookups in client > code? It provides little advantage to the client to assume > uniqueness, and it could be an easy source of bugs. This falls > under the IETF principle of being generous in what you accept > (non-unique tokens) but strict in what you generate (unique only). Absolutely no. Either clients can rely on uniquess, or they can't. RFC2518 guarantees this, and I don't see an interoperability problem caused by this. Removing the guarantee potentially breaks existing clients with no visible benefit. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Aug 11 16:47:56 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05707 for ; Mon, 11 Aug 2003 16:47:55 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BKlxpI012687; Mon, 11 Aug 2003 16:47:59 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7BKlsje012640; Mon, 11 Aug 2003 16:47:54 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 16:47:54 -0400 (EDT) Resent-Message-Id: <200308112047.h7BKlsje012640@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BKlqpI012587 for ; Mon, 11 Aug 2003 16:47:52 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7BKlq3b022129 for ; Mon, 11 Aug 2003 16:47:52 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19mJa3-0001J9-00; Mon, 11 Aug 2003 20:47:51 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19mJa3-0001Ix-00; Mon, 11 Aug 2003 20:47:51 +0000 From: "Lisa Dusseault" To: "'Geoffrey M Clemm'" Cc: , "'webdav'" Date: Mon, 11 Aug 2003 13:48:36 -0700 Message-ID: <00eb01c36049$ef8425c0$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: geoffrey.clemm@us.ibm.com, ietf-dav-versioning@w3.org, w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h7BKlqpI012587 Subject: RE: DAV:displayname with versions X-Archived-At: http://www.w3.org/mid/00eb01c36049$ef8425c0$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7816 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Yes, but support for RFC3253 is not required for support of RFC2518. The core or base specification is responsible for core functionality. I think it encourages implementation of RFC2518 to keep it as simple as it can be, and keeping description of optional functionality (other than locking) outside of RFC2518 is one way to continue to keep it simple. Another reason is that versioning functionality is newer and has seen much less interoperability testing. One of the considerations for RFC2518bis is whether each feature specified meets the interoperability bar for IETF draft standard publication. For drafts like binding and ordering, I agree that new properties should have their versioning behavior specified as well as their non-versioning behavior if necessary. And for drafts after that, new properties may have to be defined with their binding behavior as well as versioning. Lisa > -----Original Message----- > From: Geoffrey M Clemm [mailto:geoffrey.clemm@us.ibm.com] > Sent: Monday, August 11, 2003 12:52 PM > To: Lisa Dusseault > Cc: ietf-dav-versioning@w3.org; 'webdav' > Subject: RE: DAV:displayname with versions > > > I agree that we want to finish RFC2518bis in a finite amount > of time, but I disagree that versioning behavior of RFC2518 > properties should be defined in a separate draft. Any new > WebDAV draft should fully define the behavior of any live > property it defines, and versioning is > a standard part of the WebDAV family (after all, it is > "WebDAV", not "WebDA" :-). > > Cheers, > Geoff > > "Lisa Dusseault" wrote on 08/11/2003 02:04:24 PM: > > > That isn't quite the Xythos WFS behavior. If you MOVE a VCR, its > > displayname changes to the current name. Thus the > displayname changes > for > > all the versions as well. They aren't entirely immutable, in other > words. > > > > I wouldn't put the versioning behavior of properties in > RFC2518bis, > > however, we need to keep changes there down so we get finished in > > finite time and get draft standard status with tested interoperable > > features. > If > > we think we can specify property behavior for versioning it > could just > as > > easily be done in a separate short draft. > > > > Speaking of this, what are the issues for the binding draft and the > behavior > > of live properties? Does the binding draft sufficiently cover what > happens > > with versioning in the mix? > > > > Lisa > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of > Geoffrey M Clemm > > > Sent: Monday, August 11, 2003 10:46 AM > > > To: ietf-dav-versioning@w3.org; webdav > > > Subject: RE: DAV:displayname with versions > > > > > > > > > > > > Yes, 3253 leaves the definition of versioning behavior for > > > live properties up to the standard that defines those > live properties. > > > > > > > > > So we should probably try to define the versioning > behavior for 2518 > > > properties > > > in 2518bis. In general, the simplest default versioning > > > behavior for a property such as DAV:displayname is to treat > > > it the same as a dead > > > property, > > > i.e. it is an immutable copy of the value of that property on > > > the VCR at CHECKIN time. Does this work for folks currently > > > doing versioning? (I couldn't quite tell from Lisa's > > > description whether this is the Xythos behavior or not). > > > > > > Cheers, > > > Geoff > > > > > > Lisa wrote on 08/11/2003 01:09:58 PM: > > > > > > > > Sure, every version must have the displayname property so > > > you can get > > > > it with PROPFIND. However, no specification requires that to be > > > > either writable or protected on a version, so on some > > > servers it won't > > > > be > > > writable. > > > > Also no specification requires it to be either static > or dynamic, > > > > so > > > it's > > > > possible on some servers that the property would be > > > protected, and it > > > would > > > > change whenever the value on the VCR changed. > > > > > > > > I believe on Xythos WFS the displayname property is > protected and > > > > static > > > on > > > > versions. It will always have the same value as the displayname > > > property of > > > > the VCR. > > > > > > > > -----Original Message----- > > > > > From: Geoffrey M Clemm > > > > > > > > > > There is no concept of a "global" property of a version. Each > > > > > version is a separate resource, with its own > properties. So each > > > > > version has its own DAV:displayname property. > > > > > > > > > > But there is a natural place to put a "global" property of a > > > > > version, namely, as a property on the VersionHistory of > > > that version. > > > > > > > > Horst wrote on 08/11/2003 11:47:38 AM: > > > > > > > > > > > > Just a simple question, is the DAV:displayname of a > > > > > resource "global" > > > > > > ? Or is it possible to have different DAV:displayname(s) > > > > > for different > > > > > > versions of the same resource. > > > > > > > > > > > > From w3c-dist-auth-request@w3.org Mon Aug 11 16:50:08 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05752 for ; Mon, 11 Aug 2003 16:50:08 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BKoBpI013514; Mon, 11 Aug 2003 16:50:11 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7BKoBp1013498; Mon, 11 Aug 2003 16:50:11 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 16:50:11 -0400 (EDT) Resent-Message-Id: <200308112050.h7BKoBp1013498@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BKoApI013464 for ; Mon, 11 Aug 2003 16:50:10 -0400 (EDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7BKo93b022582 for ; Mon, 11 Aug 2003 16:50:10 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7BKo44X094068 for ; Mon, 11 Aug 2003 16:50:04 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7BKo3AA154736 for ; Mon, 11 Aug 2003 16:50:03 -0400 In-Reply-To: To: " webdav" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 11 Aug 2003 16:50:09 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 08/11/2003 16:50:02, Serialize complete at 08/11/2003 16:50:02 Content-Type: text/plain; charset="US-ASCII" Subject: RE: URI scheme uniqueness X-Archived-At: http://www.w3.org/mid/OF0DE8307C.DF51173D-ON85256D7F.007236B6-85256D7F.00727531@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7817 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree with Julian. I have seen no reason to weaken the current requirement that lock tokens be globablly unique. Cheers, Geoff w3c-dist-auth-request@w3.org wrote on 08/11/2003 04:14:07 PM: > > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > Sent: Monday, August 11, 2003 10:06 PM > > To: hardie@qualcomm.com; 'Julian Reschke'; w3c-dist-auth@w3.org > > Subject: RE: URI scheme uniqueness > > > > ... > > > > > If you are an implementor considering using a non-IETF registered URI > > > scheme _for_any_purpose_, > > > don't lose sight of what using a registered URI scheme gives you. > > > Non-registered > > > schemes risk overlap and risk misunderstandings of syntax > > > developing over time. > > > > I agree with this so the next version of RFC2518bis will recommend > > using a registered scheme unless I start hearing more disagreement. > > Sounds good so far. > > > > I suspect that this presumes something about the way clients > > > should behave; to wit, if they get a lock token DAV:1234 > > > issued by server dav.example.com, they will not get whacked > > > out when they get a lock token DAV:1234 issued by server > > > dav.example.net (obviously, for some other resource). I > > > believe that this would be good engineering, obviously, but I > > > think maintaining a stricter requirement is useful. > > > > I think that although we have the uniqueness requirement already > > (it can't be made stricter very easily) clients simply can't assume > > that lock tokens really are globally unique. > > Wait a minute. The spec says that they MUST be globally unique. It even > defines a URI scheme that is supposed to guarantee that uniqueness. And now > you want to tell clients that they can't rely on that??? > > > Should we add some client advice to RFC2518bis, saying that in > > practice clients cannot assume that lock tokens will be unique > > across servers and should not be used as unique lookups in client > > code? It provides little advantage to the client to assume > > uniqueness, and it could be an easy source of bugs. This falls > > under the IETF principle of being generous in what you accept > > (non-unique tokens) but strict in what you generate (unique only). > > Absolutely no. Either clients can rely on uniquess, or they can't. RFC2518 > guarantees this, and I don't see an interoperability problem caused by this. > Removing the guarantee potentially breaks existing clients with no visible > benefit. From w3c-dist-auth-request@w3.org Mon Aug 11 16:53:52 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05848 for ; Mon, 11 Aug 2003 16:53:52 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BKrtpI015085; Mon, 11 Aug 2003 16:53:55 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7BKrsCv015061; Mon, 11 Aug 2003 16:53:54 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 16:53:54 -0400 (EDT) Resent-Message-Id: <200308112053.h7BKrsCv015061@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BKrrpI015025 for ; Mon, 11 Aug 2003 16:53:53 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7BKrr3b023299 for ; Mon, 11 Aug 2003 16:53:53 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19mJfs-0001PU-00; Mon, 11 Aug 2003 20:53:52 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19mJfs-0001PJ-00; Mon, 11 Aug 2003 20:53:52 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Webdav WG'" Date: Mon, 11 Aug 2003 13:54:37 -0700 Message-ID: <00f101c3604a$c6b1bfd0$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: julian.reschke@gmx.de, w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h7BKrrpI015025 Subject: RE: Changing etag and getlastmodified on move/rename X-Archived-At: http://www.w3.org/mid/00f101c3604a$c6b1bfd0$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7818 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > > Wouldn't the "getlastmodified" value change during this operation > > as well? I'm assuming that at the beginning /a/b and /a/c had > > different content, which is why the ETag had to changed when the > > MOVE caused the content /a/c to be overwritten with the content > > from /a/b. If that's the case then the result of a GET to /a/c > > is different after the move, so the 'getlastmodified' must > also change. > > Most of the time yes, but not always: if /a/b and /a/c might > have had the same DAV:getlastmodified property before the > MOVE, in which case the date for /a/c may not change (one of > the reasons why ETags are better than dates). > The 'getlastmodified' property probably shouldn't be preserved across most MOVE operations. Recall that the meaning of 'getlastmodified' isn't defined as the time that a user last made changes to the content of a resource. Rather, it's the date at which the results of a GET request to that URL last changed. That's because it's tied to the Last-Modified header definition in HTTP. Consider the case where a MOVE operation overwrites an existing resource with different content. Clearly the HTTP Last-Modified header value must now be set to the timestamp of the MOVE operation, because this operation invalidates previously cached copies of the destination resource. Consider next the case where a MOVE operation creates a new resource with content from somewhere else. Even though that content wasn't new content, it is new at that URL. A client may get confused trying to synchronize a resource which didn't even exist before time T, yet its 'getlastmodified' or Last-Modified value is prior to time T. I think the safest thing to do in this case is again to update the value to the timestamp of the MOVE operation. If we want a property which instead tells us the last time a user made changes to the body of a file, we would have to define a new property which would happen to have the same value as 'getlastmodified' much of the time. But the new property would probably be client writable so that a synchronizing or backup client could tell the server when the file was last changed. Lisa From w3c-dist-auth-request@w3.org Mon Aug 11 17:08:52 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06572 for ; Mon, 11 Aug 2003 17:08:52 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BL8upI019383; Mon, 11 Aug 2003 17:08:56 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7BL8sVS019358; Mon, 11 Aug 2003 17:08:54 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 17:08:54 -0400 (EDT) Resent-Message-Id: <200308112108.h7BL8sVS019358@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BL8rpI019325 for ; Mon, 11 Aug 2003 17:08:53 -0400 (EDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7BL8q3b025654 for ; Mon, 11 Aug 2003 17:08:52 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7BL8lkh148624 for ; Mon, 11 Aug 2003 17:08:47 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7BL8kAB127008 for ; Mon, 11 Aug 2003 17:08:46 -0400 In-Reply-To: <00f101c3604a$c6b1bfd0$f8cb90c6@lisalap> To: "'Webdav WG'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 Message-ID: From: Geoffrey M Clemm Date: Mon, 11 Aug 2003 17:08:52 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 08/11/2003 17:08:46, Serialize complete at 08/11/2003 17:08:46 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Changing etag and getlastmodified on move/rename X-Archived-At: http://www.w3.org/mid/OFB66CF310.5041A99E-ON85256D7F.007371CD-85256D7F.00742BC0@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7819 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree that a WebDAV client would prefer that the Last-Modified header (and the DAV:getlastmodified property) be based on the URL (and therefore change on every MOVE) rather than be based on the resource (and therefore not change on a MOVE), but 2616 explicitly states that a possible implementation of the Last-Modified value is the file system modification time. This is based on the pragmatic observation that it would be prohibitively expensive for a variety of WebDAV servers to modify (or supplement) the last-modification semantics of their underlying repository (which is resource based, not URL based). Cheers, Geoff Lisa wrote on 08/11/2003 04:54:37 PM: > > > > Wouldn't the "getlastmodified" value change during this operation > > > as well? I'm assuming that at the beginning /a/b and /a/c had > > > different content, which is why the ETag had to changed when the > > > MOVE caused the content /a/c to be overwritten with the content > > > from /a/b. If that's the case then the result of a GET to /a/c > > > is different after the move, so the 'getlastmodified' must > > also change. > > > > Most of the time yes, but not always: if /a/b and /a/c might > > have had the same DAV:getlastmodified property before the > > MOVE, in which case the date for /a/c may not change (one of > > the reasons why ETags are better than dates). > > > > The 'getlastmodified' property probably shouldn't be preserved > across most MOVE operations. Recall that the meaning of > 'getlastmodified' isn't defined as the time that a user last made > changes to the content of a resource. Rather, it's the date at > which the results of a GET request to that URL last changed. That's > because it's tied to the Last-Modified header definition in HTTP. > > Consider the case where a MOVE operation overwrites an existing > resource with different content. Clearly the HTTP Last-Modified > header value must now be set to the timestamp of the MOVE operation, > because this operation invalidates previously cached copies of the > destination resource. > > Consider next the case where a MOVE operation creates a new resource > with content from somewhere else. Even though that content wasn't > new content, it is new at that URL. A client may get confused > trying to synchronize a resource which didn't even exist before time > T, yet its 'getlastmodified' or Last-Modified value is prior to time > T. I think the safest thing to do in this case is again to update > the value to the timestamp of the MOVE operation. > > If we want a property which instead tells us the last time a user > made changes to the body of a file, we would have to define a new > property which would happen to have the same value as > 'getlastmodified' much of the time. But the new property would > probably be client writable so that a synchronizing or backup client > could tell the server when the file was last changed. > > Lisa > > > From w3c-dist-auth-request@w3.org Mon Aug 11 19:01:36 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10235 for ; Mon, 11 Aug 2003 19:01:36 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BN1epI020661; Mon, 11 Aug 2003 19:01:40 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7BN1Y4g020636; Mon, 11 Aug 2003 19:01:34 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 19:01:34 -0400 (EDT) Resent-Message-Id: <200308112301.h7BN1Y4g020636@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BN1WpI020595 for ; Mon, 11 Aug 2003 19:01:32 -0400 (EDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7BN1V3b010448 for ; Mon, 11 Aug 2003 19:01:32 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h7BN1KVp003860 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 11 Aug 2003 16:01:20 -0700 (PDT) Received: from [205.214.163.32] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h7BN1Ish025018; Mon, 11 Aug 2003 16:01:18 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <009701c36044$0397d2b0$f8cb90c6@lisalap> References: <009701c36044$0397d2b0$f8cb90c6@lisalap> Date: Mon, 11 Aug 2003 16:01:21 -0700 To: "Lisa Dusseault" , "'Julian Reschke'" , From: hardie@qualcomm.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: URI scheme uniqueness X-Archived-At: http://www.w3.org/mid/p06001a06bb5dcf666e62@%5B205.214.163.32%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7820 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: >Lisa Dusseault writes: >> I suspect that this presumes something about the way clients >> should behave; to wit, if they get a lock token DAV:1234 >> issued by server dav.example.com, they will not get whacked >> out when they get a lock token DAV:1234 issued by server >> dav.example.net (obviously, for some other resource). I >> believe that this would be good engineering, obviously, but I >> think maintaining a stricter requirement is useful. > >I think that although we have the uniqueness requirement already >(it can't be made stricter very easily) clients simply can't assume >that lock tokens really are globally unique. > >Should we add some client advice to RFC2518bis, saying that in >practice clients cannot assume that lock tokens will be unique >across servers and should not be used as unique lookups in client >code? It provides little advantage to the client to assume >uniqueness, and it could be an easy source of bugs. This falls >under the IETF principle of being generous in what you accept >(non-unique tokens) but strict in what you generate (unique only). > > It's always tricky to write that sort of text without weakening the core requirement, but it is possible. Usually it falls under the "fail gracefully" rubric--in other words, saying that clients which receive the same lock token a second time should neither accept it nor crash, but do something else which allows them to fail gracefully. Given the potential uses here, though, I'm not sure what the "graceful failure" mode is. What would you suggest the right behavior is in that case? regards, Ted From w3c-dist-auth-request@w3.org Mon Aug 11 19:08:26 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10379 for ; Mon, 11 Aug 2003 19:08:26 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BN8VpI022785; Mon, 11 Aug 2003 19:08:31 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7BN8UoY022775; Mon, 11 Aug 2003 19:08:30 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 19:08:30 -0400 (EDT) Resent-Message-Id: <200308112308.h7BN8UoY022775@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7BN8UpI022742 for ; Mon, 11 Aug 2003 19:08:30 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7BN8T3b011708 for ; Mon, 11 Aug 2003 19:08:29 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19mLm9-0003Jm-00; Mon, 11 Aug 2003 23:08:29 +0000 Received: from [216.36.77.241] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19mLm8-0003Jb-00; Mon, 11 Aug 2003 23:08:29 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Webdav WG'" Date: Mon, 11 Aug 2003 16:09:13 -0700 Message-ID: <010901c3605d$948bc9c0$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Old-X-Envelope-To: julian.reschke@gmx.de, w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h7BN8UpI022742 Subject: RE: Changing etag and getlastmodified on move/rename X-Archived-At: http://www.w3.org/mid/010901c3605d$948bc9c0$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7821 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > > Wouldn't the "getlastmodified" value change during this operation > > as well? I'm assuming that at the beginning /a/b and /a/c had > > different content, which is why the ETag had to changed when the > > MOVE caused the content /a/c to be overwritten with the content > > from /a/b. If that's the case then the result of a GET to /a/c > > is different after the move, so the 'getlastmodified' must > also change. > > Most of the time yes, but not always: if /a/b and /a/c might > have had the same DAV:getlastmodified property before the > MOVE, in which case the date for /a/c may not change (one of > the reasons why ETags are better than dates). > > Seems that the HTTP caching (lastmodified and etag) aren't > very compatible with WebDAV namespace operations. > HTTP caching is very carefully defined. The "Last-Modified" header isn't defined as the last time the user did a PUT request, it's defined very carefully in terms of when the entity changed: " The Last-Modified entity-header field indicates the date and time at which the origin server believes the variant was last modified. " If the variant was last changed through either a local file system move overwrite, or through a WebDAV MOVE operation that targetted the URL where that variant is accessed, then Last-Modified has changed according to the definition. HTTP doesn't say how it behaves in terms of MOVE because to HTTP, MOVE doesn't exist. But it does define things carefully enough so that you can deduce that a MOVE must change the Last-Modified value. The reason for this is because Last-Modified was designed for caching, not for display. If a MOVE request overwrites a resource with different content, caching agents need to know to update their cached copy. We've noticed that Apache doesn't change the Last-Modified date when a file is moved in the server's file system. It accepts the file system's say-so, even when the file has been overwritten during a local move. However Apache simply doesn't have the information that the file was changed so it can't -- in essence this is the "origin server believes" phrase of the spec. Thus, Apache can break caching. A client can ask for a file with a "Last-Modified-Since" value, and Apache may return a 412 Precondition Failed response even when the file has been changed due to a local file-system move. Clearly that's wrong. The design of HTTP caching isn't very compatible with how clients want to display the last time a user edited a file, and it isn't very compatible with how the Windows file system works. But HTTP caching wasn't designed to solve either of those problems. Lisa From w3c-dist-auth-request@w3.org Tue Aug 12 01:06:57 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16872 for ; Tue, 12 Aug 2003 01:06:56 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7C56wpI015193; Tue, 12 Aug 2003 01:06:58 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7C56nuW015183; Tue, 12 Aug 2003 01:06:49 -0400 (EDT) Resent-Date: Tue, 12 Aug 2003 01:06:49 -0400 (EDT) Resent-Message-Id: <200308120506.h7C56nuW015183@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7C56kpI015146 for ; Tue, 12 Aug 2003 01:06:46 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7C56jGB026123 for ; Tue, 12 Aug 2003 01:06:46 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.12.1) id h7C56i4J031834 sender ccjason@us.ibm.com for w3c-dist-auth@w3.org; Mon, 11 Aug 2003 22:06:44 -0700 Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by sunbelt.seagull.net (8.12.1) with ESMTP id h7C56h3P031824 sender ccjason@us.ibm.com; Mon, 11 Aug 2003 22:06:43 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7C56gkh081604; Tue, 12 Aug 2003 01:06:42 -0400 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7C56eMS039708; Tue, 12 Aug 2003 01:06:41 -0400 To: nnw3c-dist-auth___at___w3.org@smallcue.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Jason Crawford Message-ID: Date: Tue, 12 Aug 2003 01:06:35 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.2CF1|June 9, 2003) at 08/12/2003 01:06:41, Serialize complete at 08/12/2003 01:06:41 Content-Type: text/plain; charset="us-ascii" Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings) X-Archived-At: http://www.w3.org/mid/OF6CCF32EB.A33DA232-ON85256D80.001B1A2A-85256D80.001C1209@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7822 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > I think the granularity of is too fine. > I'd prefer to just allow the use of the DAV header as a request header, > and if the client says: > > PROPFIND > DAV: 1,2,bind > > and then the server can use 208 responses (i.e. because "bind" appears > in the request DAV header). This sounds good to me. If we start having trouble managing all those values, we can explore another approach. In the meantime, the binding spec will need to define this DAV: bind header value and indicate what servers can do with a PROPFIND in it's absense. From w3c-dist-auth-request@w3.org Tue Aug 12 03:02:40 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01809 for ; Tue, 12 Aug 2003 03:02:40 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7C72gpI007170; Tue, 12 Aug 2003 03:02:42 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7C72ckh007163; Tue, 12 Aug 2003 03:02:38 -0400 (EDT) Resent-Date: Tue, 12 Aug 2003 03:02:38 -0400 (EDT) Resent-Message-Id: <200308120702.h7C72ckh007163@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7C72bpI007128 for ; Tue, 12 Aug 2003 03:02:37 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7C72aGB005344 for ; Tue, 12 Aug 2003 03:02:36 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.12.1) id h7C72aB3006499 sender julian.reschke@gmx.de for w3c-dist-auth@w3.org; Tue, 12 Aug 2003 00:02:36 -0700 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by sunbelt.seagull.net (8.12.1) with SMTP id h7C72YxJ006489 sender julian.reschke@gmx.de for ; Tue, 12 Aug 2003 00:02:35 -0700 Received: (qmail 16612 invoked by uid 65534); 12 Aug 2003 07:02:32 -0000 Received: from p3EE24753.dip.t-dialin.net (HELO lisa) (62.226.71.83) by mail.gmx.net (mp005) with SMTP; 12 Aug 2003 09:02:32 +0200 From: "Julian Reschke" To: "Jason Crawford" , Date: Tue, 12 Aug 2003 09:02:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEEGICAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7823 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Tuesday, August 12, 2003 7:07 AM > To: nnw3c-dist-auth___at___w3.org@smallcue.com > Subject: RE: Binding loops and PROPFIND clarification needed (was Re: > COPY and bindings) > > > > > I think the granularity of is too fine. > > I'd prefer to just allow the use of the DAV header as a request header, > > and if the client says: > > > > PROPFIND > > DAV: 1,2,bind > > > > and then the server can use 208 responses (i.e. because "bind" appears > > in the request DAV header). > This sounds good to me. I still don't like it, primarily because this is *too* generic. It will probably cause clients to send this header with each and every request, even when it doesn't make a difference. It also opens the door to new interoperability problems -- what if the set of extensions keeps growing and different extensions create subtile incompatibilities. It may become really painful to the server to decide based on the request header what to do. I really really prefer to be *specific*. The problem *only* occurs with bind loops and PROPFIND/depth infinity. Let us only do what's needed to fix that, instead of inventing a whole new negotiation mechanism. In this case, just marshall the flag as part of the request body. > If we start having trouble managing all those values, we can explore another > approach. In the meantime, the binding spec will need to define this DAV: bind But then it's too late, isn't it? > header value and indicate what servers can do with a PROPFIND in it's > absense. Independantly of how we send the information: if the client sends a PROPFIND/depth infinity to a collection that contains bind cycles (thus requires the new format), just reply with 506. Julian From w3c-dist-auth-request@w3.org Tue Aug 12 12:05:03 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19905 for ; Tue, 12 Aug 2003 12:05:02 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7CG53pI001147; Tue, 12 Aug 2003 12:05:03 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7CG3o5n000942; Tue, 12 Aug 2003 12:03:50 -0400 (EDT) Resent-Date: Tue, 12 Aug 2003 12:03:50 -0400 (EDT) Resent-Message-Id: <200308121603.h7CG3o5n000942@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7CG3mpI000905 for ; Tue, 12 Aug 2003 12:03:48 -0400 (EDT) Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7CG3lGB013979 for ; Tue, 12 Aug 2003 12:03:48 -0400 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h7CG0U904997 for ; Tue, 12 Aug 2003 09:00:31 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 12 Aug 2003 09:02:03 -0700 Message-ID: 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.2800.1165 X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: [Moderator Action] WEBDAV SEARCH Query X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIAEBNIMAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7824 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Paras Navinchandra Shah [mailto:ParasNS@mascotsystems.com] Sent: Tuesday, July 29, 2003 3:40 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] WEBDAV SEARCH Query This is regarding ur WEBDAV SEARCH Query Please modify ur code in following manner Set query = doc.createTextNode("Select ""urn:schemas:calendar:dtstart"" FROM Scope('SHALLOW TRAVERSAL OF ""http://192.168.219.172/exchange/parasns/calendar""' ) WHERE ""urn:schemas:calendar:dtstart"" > '1999/09/27 00:00:00' ") I hope that after this changes it would work fine Regs, Paras From w3c-dist-auth-request@w3.org Tue Aug 12 17:30:42 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29803 for ; Tue, 12 Aug 2003 17:30:41 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7CLUipI015168; Tue, 12 Aug 2003 17:30:44 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7CLUOOY015059; Tue, 12 Aug 2003 17:30:24 -0400 (EDT) Resent-Date: Tue, 12 Aug 2003 17:30:24 -0400 (EDT) Resent-Message-Id: <200308122130.h7CLUOOY015059@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7CLUMpI015026 for ; Tue, 12 Aug 2003 17:30:22 -0400 (EDT) Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7CLUMGB023425 for ; Tue, 12 Aug 2003 17:30:22 -0400 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h7CLRn914259 for ; Tue, 12 Aug 2003 14:27:49 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 12 Aug 2003 14:29:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0165_01C360DE.1E942F60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-UCSC-CATS-MailScanner: Found to be clean Subject: WebDAV Interoperability Testing Event - Sept. 15-16, Santa Cruz, CA X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIOEDCIMAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7825 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0165_01C360DE.1E942F60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit All, UC Santa Cruz is planning on hosting another interoperability testing event this year, following up on the very successful events held the past two years. This is a very efficient way to test your WebDAV implementation against other clients/servers. I very much encourage WebDAV implementors to attend. I'm having some graduate students (Kai Pan, Sung Kim) help out with the organization this year,so that's why you'll see their names below. The event is coming up very quickly, just about a month away. So, let us know soon if you're planning on attending. Thanks! - Jim 2003 WebDAV Face-to-Face Interoperability Testing Event Santa Cruz, California September 15-16, 2003, 9AM-6:30PM Baskin Engineering Bldg., University of California, Santa Cruz The goal of the WebDAV Interoperability Testing Event is to gather together, in one physical location, developers and testers of WebDAV/DASL/DeltaV/ACL clients and servers so they can exercise as many client/server pairs as possible. Ideally, all functionality of each client will be tested against every server. This will quickly surface interoperability problems. Once identified, these problems can sometimes be fixed on the spot (if developers have brought source code), or can be targeted for resolution in the Draft Standard (i.e., revised) version of RFC 2518. Similar WebDAV interop events were held in 2001 and 2002, and were very successful. They are an extremely efficient way to do interoperability testing against a broad array of clients and servers, allowing problems to be quickly identified and resolved. Invariably, the net result of an interoperability testing event is a set of clients and servers that work together better, offering better value for end-users. If you are planning on attending the WebDAV Interoperability Testing Event, please register with Kai Pan Some details on the event: * Results from the event are NOT intended for distribution to the Press. This is not an interoperability demonstration like those sometimes held at trade shows for marketing purposes. Instead, this is a normal part of the engineering activity of creating an interoperability standard. People attending the event for the sole purpose of collecting marketing information will be asked to leave. * Since the room for this event is not super-big, a maximum of two people may attend per independent code base. If you feel this is too restrictive, and would prevent you from adequately testing your implementation, please send an email to Sung Kim to discuss alternatives. * The event will be held in the Baskin Engineering building on the campus of UC Santa Cruz. Specifically, the room for the event (a picture of 1/2 of the room) is a large common area, located outside room BE 115 (on the ground/first floor). There are lots of tables, chairs, whiteboards, and electrical outlets available. Some directions to UCSC and Baskin Engineering can be found here. * You will need to provide your own machines, with the client and/or server software installed. UCSC will provide networking capabilities. The room for the event is not secure, and only limited security will be provided. Ideally, you will bring your WebDAV implementation on a laptop machine, so it can be set up and torn down quickly. * Ideally attendees will bring their development environment, and a copy of their source code, so that minor errors can be fixed on the spot. Sometimes it is necessary to fix an error before further interoperability testing can take place. * Your WebDAV implementation does not need to be a shipping product. It is OK to bring pre-release code for testing purposes. After all, it is best to catch interoperability problems before users do. * DeltaV, DASL, and ACL client and server implementations are welcome at the event. * HTTP proxies and caches that understand WebDAV and DeltaV are also welcome to attend. * Open source implementations are welcome at the event. * A small, per-organization fee of $225 is being charged to cover the cost of food and parking for the event. Please bring a check (no credit cards, sorry) payable to UC Regents. It's free for the open source implementation group. * Cell phones do not work well in buildings on the UC Santa Cruz campus. They do work reasonably well outside of buildings. * If you're traveling from afar, you should get accommodations as early as you can. Santa Cruz is a popular vacation location in the summer. There are web sites with information on Santa Cruz hotels and Bed and Breakfasts. The West Coast Santa Cruz Hotel is nice, close to the event, and most rooms have an ocean view. 175 West Cliff Drive, Santa Cruz, California 95060, 831-426-4330 or 800-426-0670. * The closest airport to Santa Cruz is San Jose (SJC), about 50 minutes away. San Francisco airport (SFO) is also an option. It is about 1 hour and 30 minutes away. Rush hour traffic can add 10-20 minutes to these drive times. * Electrical power (US style outlets only), network access, tables, chairs, and food (coffee, lunch, and snacks) will be provided. A printer, and land phone lines for credit card calls will very likely be available (this is planned, but not yet confirmed). * Find more updated information on the 2003 WebDAV interoperability event webpage, http://www.webdav.org/other/interop03. Other questions? Ask Sung Kim . ------=_NextPart_000_0165_01C360DE.1E942F60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

All,

UC Santa Cruz is planning on hosting = another=20 interoperability testing event this year, following up on the very = successful=20 events held the past two years. This is a very efficient way to = test your=20 WebDAV implementation against other clients/servers. I very much=20 encourage WebDAV implementors to attend. I'm having some=20 graduate students (Kai Pan, Sung Kim) help out with the = organization this=20 year,so that's why you'll see their names below.

The event is coming up very quickly, just about a = month away.=20 So, let us know soon if you're planning on attending. Thanks! =

- Jim


  

       &n= bsp;          =20 2003 WebDAV Face-to-Face Interoperability Testing=20 Event

          =             &= nbsp;           &n= bsp;   =20 Santa Cruz,=20 California
          = ;            =           =20 September 15-16, 2003,=20 9AM-6:30PM
          = ;        =20 Baskin Engineering Bldg., University of California, Santa=20 Cruz

   The goal of the WebDAV Interoperability Testing = Event=20 is to gather together, in one physical
   location, = developers and=20 testers of WebDAV/DASL/DeltaV/ACL clients and servers so they=20 can
   exercise as many client/server pairs as possible. = Ideally,=20 all functionality of each client
   will be tested against = every=20 server. This will quickly surface interoperability problems.=20 Once
   identified, these problems can sometimes be fixed = on the=20 spot (if developers have brought
   source code), or can be = targeted for resolution in the Draft Standard (i.e., revised)=20 version
   of RFC 2518.

   Similar WebDAV = interop=20 events were held in 2001 and 2002, and were very successful. They=20 are
   an extremely efficient way to do interoperability = testing=20 against a broad array of clients and
   servers, allowing = problems=20 to be quickly identified and resolved. Invariably, the net=20 result
   of an interoperability testing event is a set of = clients=20 and servers that work together
   better, offering better = value for=20 end-users.

   If you are planning on attending the = WebDAV=20 Interoperability Testing Event, please register
   with Kai = Pan=20 <pankai@cs.ucsc.edu>

   Some details on the=20 event:
     * Results from the event are NOT = intended for=20 distribution to the Press. This is not=20 an
       interoperability = demonstration like=20 those sometimes held at trade shows for=20 marketing
       purposes. Instead, = this is a=20 normal part of the engineering activity of creating=20 an
       interoperability standard. = People=20 attending the event for the sole purpose of=20 collecting
       marketing information = will be=20 asked to leave.
     * Since the room for this = event is=20 not super-big, a maximum of two people may attend=20 per
       independent code base. If = you feel=20 this is too restrictive, and would prevent you=20 from
       adequately testing your=20 implementation, please send an email to Sung=20 Kim
       <hunkim@cs.ucsc.edu> = to=20 discuss alternatives.
     * The event will be = held in=20 the Baskin Engineering building on the campus of UC Santa=20 Cruz.
       Specifically, the room for = the=20 event (a picture of 1/2 of the room) is a large=20 common
       area, located outside = room BE 115=20 (on the ground/first floor). There are lots of=20 tables,
       chairs, whiteboards, and = electrical outlets available. Some directions to UCSC and=20 Baskin
       Engineering can be found=20 here.
     * You will need to provide your own = machines,=20 with the client and/or server = software
      =20 installed. UCSC will provide networking capabilities. The room for the = event is=20 not
       secure, and only limited = security=20 will be provided. Ideally, you will bring your=20 WebDAV
       implementation on a = laptop=20 machine, so it can be set up and torn down = quickly.
    =20 * Ideally attendees will bring their development environment, and a copy = of=20 their source
       code, so that minor = errors=20 can be fixed on the spot. Sometimes it is necessary to fix=20 an
       error before further = interoperability=20 testing can take place.
     * Your WebDAV = implementation=20 does not need to be a shipping product. It is OK to=20 bring
       pre-release code for = testing=20 purposes. After all, it is best to catch=20 interoperability
       problems before = users=20 do.
     * DeltaV, DASL, and ACL client and = server=20 implementations are welcome at the event.
     * = HTTP=20 proxies and caches that understand WebDAV and DeltaV are also welcome to = attend.
     * Open source implementations are = welcome at=20 the event.
     * A small, per-organization fee = of $225=20 is being charged to cover the cost of food=20 and
       parking for the event. = Please bring=20 a check (no credit cards, sorry) payable to=20 UC
       Regents. It's free for the = open=20 source implementation group.
     * Cell phones = do not=20 work well in buildings on the UC Santa Cruz campus. They do=20 work
       reasonably well outside of=20 buildings.
     * If you're traveling from afar, = you=20 should get accommodations as early as you can.=20 Santa
       Cruz is a popular vacation = location in the summer. There are web sites with information=20 on
       Santa Cruz hotels and Bed and = Breakfasts. The West Coast Santa Cruz Hotel is nice,=20 close
       to the event, and most = rooms have=20 an ocean view. 175 West Cliff Drive, Santa=20 Cruz,
       California 95060, = 831-426-4330 or=20 800-426-0670.
     * The closest airport to Santa = Cruz is=20 San Jose (SJC), about 50 minutes away. San=20 Francisco
       airport (SFO) is also = an=20 option. It is about 1 hour and 30 minutes away. Rush hour=20 traffic
       can add 10-20 minutes to = these=20 drive times.
     * Electrical power (US style = outlets=20 only), network access, tables, chairs, and=20 food
       (coffee, lunch, and snacks) = will be=20 provided. A printer, and land phone lines for=20 credit
       card calls will very = likely be=20 available (this is planned, but not yet = confirmed).
    =20 * Find more updated information on the 2003 WebDAV interoperability = event=20 webpage,
       http://www.webdav.org/other/interop03.

   Other questions? Ask Sung Kim=20 <hunkim@cs.ucsc.edu>.

------=_NextPart_000_0165_01C360DE.1E942F60-- From w3c-dist-auth-request@w3.org Wed Aug 13 19:27:55 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10926 for ; Wed, 13 Aug 2003 19:27:55 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7DNRupI004064; Wed, 13 Aug 2003 19:27:56 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7DNRLQf003915; Wed, 13 Aug 2003 19:27:21 -0400 (EDT) Resent-Date: Wed, 13 Aug 2003 19:27:21 -0400 (EDT) Resent-Message-Id: <200308132327.h7DNRLQf003915@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7DNRJpI003880 for ; Wed, 13 Aug 2003 19:27:19 -0400 (EDT) Received: from smtpout.mac.com (A17-250-248-87.apple.com [17.250.248.87]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7DNRIGB021959 for ; Wed, 13 Aug 2003 19:27:19 -0400 Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h7DNRFBM000910; Wed, 13 Aug 2003 16:27:15 -0700 (PDT) Received: from [162.39.216.175] (h175.216.39.162.ip.alltel.net [162.39.216.175]) (authenticated bits=0) by mac.com (Xserve/8.12.9/MantshX 2.0) with ESMTP id h7DNQj9e024976; Wed, 13 Aug 2003 16:27:07 -0700 (PDT) Mime-Version: 1.0 X-Sender: frank.lowney@mail.mac.com Message-Id: Date: Wed, 13 Aug 2003 19:26:43 -0400 To: w3c-dist-auth@w3.org From: Frank Lowney Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: WebDAV Compliance Case Studies X-Archived-At: http://www.w3.org/mid/p05210605bb6076cacf08@%5B162.39.216.175%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7826 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Julian Reschke said: >First of all, you are absolutely on the right mailing list. There's also a >special WebDAV interop list, but that one is mainly used to organize and >exchange interop test results. > >You didn't mention exactly *what* problems you see. In general, there are >quite a few vendors that advertise WebDAV compliance, but test their servers >only with the Microsoft webfolder client, therefore having lots of problems >with other clients. On the other hand, you may also see client issues. Excellent! Then let me present our findings as separate, server-specific case studies starting with the 4D WebSTAR V server (MacOS X, see: http://www.4d.com/products/webstar.html) as reported by Cathy Locks of our staff followed by results of the Litmus test and commentary by Luke van der Westhuyzen, Product Coordinator 4D, Inc - http://www.4d.com/ At 3:19 PM -0400 8/13/03, Cathy Locks wrote: >I've gone back over the previous problems we noted with WebDav in >regards to trying to transfer files from a Windows machine to a >WebStar server. > >Our biggest problem is that we cannot drag and drop files, either >html or graphic files into the webdav folder. We can get around this >by dragging and dropping folders containing files, but we should not >have to do this. > >A second continuing problem concerns deleting files from the webdav >folder. At one point we could simply drag the items to be deleted >to the recycling bin and they would be gone. We noted on 7-1-03 >that this had changed after an update was installed on the server. >Now if we drag files to the recycling bin, a message window appears >warning that moving items to the Recucle bin will cause them to be >permanently deleted. Are you sure you want to continue? Clicking >yes should delete the files. Instead the files remain in the webdav >folder. > >I've tested these problems on a Windows XP laptop. In our previous >tests, the results were identical for the XP laptop and the Windows >2000 desktop. At 9:53 AM -0700 8/11/03, Luke van der Westhuyzen wrote: >Here are the test results: > > 0. init.................. pass > 1. begin................. pass > 2. options............... pass > 3. put_get............... pass > 4. put_get_utf8_segment.. pass > 5. mkcol_over_plain...... pass > 6. delete................ pass > 7. delete_null........... pass > 8. mkcol................. pass > 9. mkcol_again........... pass >10. delete_coll........... pass >11. mkcol_no_parent....... WARNING: MKCOL with missing intermediate >gave 403, should be 409 > ...................... pass (with 1 warning) >12. mkcol_with_body....... FAIL (MKCOL with weird body must fail >(RFC2518:8.3.1)) >13. finish................ pass ><- summary for `basic': of 14 tests run: 13 passed, 1 failed. 92.9% >-> 1 warning was issued. > >Of the two failures/warnings, 11 is most likely to give you problems >(wrong response code when trying to create a subfolder in a folder >that does not exist), although even that does not ring a bell. Most >of your issues seem to be in the initial authentication phase. > >It's a pity the test is not more comprehensive. -- ===================================================================== Dr. Frank Lowney flowney@mail.gcsu.edu Director, Electronic Instructional Services, a unit of the Office of Information and Instructional Technology, Professional Pages: http://www.gcsu.edu/oiit/eis/ Personal Pages: http://www.faculty.de.gcsu.edu/~flowney Voice: (478) 445-5260 ===================================================================== We don't make instruction effective, we make effective instruction more accessible. From w3c-dist-auth-request@w3.org Thu Aug 14 04:05:43 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03112 for ; Thu, 14 Aug 2003 04:05:43 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7E85ipI013691; Thu, 14 Aug 2003 04:05:44 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7E85N2x013630; Thu, 14 Aug 2003 04:05:23 -0400 (EDT) Resent-Date: Thu, 14 Aug 2003 04:05:23 -0400 (EDT) Resent-Message-Id: <200308140805.h7E85N2x013630@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7E85KpI013578 for ; Thu, 14 Aug 2003 04:05:20 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h7E85JGB013964 for ; Thu, 14 Aug 2003 04:05:19 -0400 Received: (qmail 7205 invoked by uid 65534); 14 Aug 2003 08:05:14 -0000 Received: from pD950C38D.dip.t-dialin.net (HELO lisa) (217.80.195.141) by mail.gmx.net (mp012) with SMTP; 14 Aug 2003 10:05:14 +0200 From: "Julian Reschke" To: "Frank Lowney" , Date: Thu, 14 Aug 2003 10:04:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Subject: RE: WebDAV Compliance Case Studies X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMELBICAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7827 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Frank Lowney > Sent: Thursday, August 14, 2003 1:27 AM > To: w3c-dist-auth@w3.org > Subject: WebDAV Compliance Case Studies > > > > ... > > >Of the two failures/warnings, 11 is most likely to give you problems > >(wrong response code when trying to create a subfolder in a folder > >that does not exist), although even that does not ring a bell. Most > >of your issues seem to be in the initial authentication phase. > > > >It's a pity the test is not more comprehensive. It is. However by default it stops running if the basic tests fail. See the command line option "-k" ("keep going"). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Aug 14 14:33:30 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21347 for ; Thu, 14 Aug 2003 14:33:30 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7EIXWpI001042; Thu, 14 Aug 2003 14:33:32 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7EIWb3d000433; Thu, 14 Aug 2003 14:32:37 -0400 (EDT) Resent-Date: Thu, 14 Aug 2003 14:32:37 -0400 (EDT) Resent-Message-Id: <200308141832.h7EIWb3d000433@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7EIWYpI000375 for ; Thu, 14 Aug 2003 14:32:34 -0400 (EDT) Received: from smtpout.mac.com (A17-250-248-85.apple.com [17.250.248.85]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7EIWXGB019598 for ; Thu, 14 Aug 2003 14:32:34 -0400 Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h7EIWT7Q026627; Thu, 14 Aug 2003 11:32:30 -0700 (PDT) Received: from [168.16.213.98] (sleepy.gcsu.edu [168.16.213.98]) (authenticated bits=0) by mac.com (Xserve/8.12.9/MantshX 2.0) with ESMTP id h7EIWKdT008732; Thu, 14 Aug 2003 11:32:22 -0700 (PDT) Mime-Version: 1.0 X-Sender: frank.lowney@mail.mac.com Message-Id: Date: Thu, 14 Aug 2003 14:32:18 -0400 To: w3c-dist-auth@w3.org From: Frank Lowney Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: WebDAV Compliance Case Studies X-Archived-At: http://www.w3.org/mid/p0521061bbb618484321f@%5B168.16.213.98%5D Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7828 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Continuing with the WebSTAR V case study and following Julian Reschke's tip on running the litmus test, we have more results for your comment. How many of these failure pointa map to real world operations likely to impact end users? -> running `basic': 0. init.................. pass 1. begin................. pass 2. options............... pass 3. put_get............... pass 4. put_get_utf8_segment.. pass 5. mkcol_over_plain...... pass 6. delete................ pass 7. delete_null........... pass 8. mkcol................. pass 9. mkcol_again........... pass 10. delete_coll........... pass 11. mkcol_no_parent....... WARNING: MKCOL with missing intermediate gave 403, should be 409 ...................... pass (with 1 warning) 12. mkcol_with_body....... FAIL (MKCOL with weird body must fail (RFC2518:8.3.1)) 13. finish................ pass <- summary for `basic': of 14 tests run: 13 passed, 1 failed. 92.9% -> 1 warning was issued. -> running `copymove': 0. init.................. pass 1. begin................. pass 2. copy_init............. pass 3. copy_simple........... pass 4. copy_overwrite........ pass 5. copy_cleanup.......... pass 6. copy_coll............. pass 7. move.................. pass 8. move_coll............. FAIL (MOVE collection `/path/litmus/mvdest2/' over non-collection `/path/litmus/mvnoncoll' with overwrite: 404 Not Found) 9. move_cleanup.......... pass 10. finish................ pass <- summary for `copymove': of 11 tests run: 10 passed, 1 failed. 90.9% -> running `props': 0. init.................. pass 1. begin................. pass 2. propfind_invalid...... pass 3. propfind_invalid2..... FAIL (PROPFIND with invalid namespace declaration in body (see FAQ) got 207 response not 400) 4. propfind_d0........... pass 5. propinit.............. pass 6. propset............... pass 7. propget............... pass 8. propmove.............. pass 9. propget............... pass 10. propdeletes........... pass 11. propget............... pass 12. propreplace........... pass 13. propget............... pass 14. propnullns............ pass 15. propget............... FAIL (PROPFIND on `/path/litmus/prop2': Invalid namespace declaration for 'xmlns:ns2' in 'D:response' at line 2.) 16. prophighunicode....... pass 17. propget............... FAIL (PROPFIND on `/path/litmus/prop2': Invalid namespace declaration for 'xmlns:ns2' in 'D:response' at line 2.) 18. propvalnspace......... pass 19. propwformed........... FAIL (PROPFIND response was not well-formed: Invalid namespace declaration for 'xmlns:ns2' in 'D:response' at line 2.) 20. propinit.............. pass 21. propmanyns............ pass 22. propget............... pass 23. propcleanup........... pass 24. finish................ pass <- summary for `props': of 25 tests run: 21 passed, 4 failed. 84.0% -> running `http': 0. init.................. pass 1. begin................. pass 2. expect100............. FAIL (timeout waiting for interim response) 3. finish................ pass <- summary for `http': of 4 tests run: 3 passed, 1 failed. 75.0% -- ===================================================================== Dr. Frank Lowney flowney@mail.gcsu.edu Director, Electronic Instructional Services, a unit of the Office of Information and Instructional Technology, Professional Pages: http://www.gcsu.edu/oiit/eis/ Personal Pages: http://www.faculty.de.gcsu.edu/~flowney Voice: (478) 445-5260 ===================================================================== We don't make instruction effective, we make effective instruction more accessible. From w3c-dist-auth-request@w3.org Thu Aug 14 15:03:16 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22282 for ; Thu, 14 Aug 2003 15:03:15 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7EJ3HpI010036; Thu, 14 Aug 2003 15:03:17 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7EJ3GZ8010023; Thu, 14 Aug 2003 15:03:16 -0400 (EDT) Resent-Date: Thu, 14 Aug 2003 15:03:16 -0400 (EDT) Resent-Message-Id: <200308141903.h7EJ3GZ8010023@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7EJ3EpI009978 for ; Thu, 14 Aug 2003 15:03:14 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h7EJ3DGB023202 for ; Thu, 14 Aug 2003 15:03:13 -0400 Received: (qmail 26462 invoked by uid 65534); 14 Aug 2003 19:03:09 -0000 Received: from pD950C3BE.dip.t-dialin.net (HELO lisa) (217.80.195.190) by mail.gmx.net (mp004) with SMTP; 14 Aug 2003 21:03:09 +0200 From: "Julian Reschke" To: "Frank Lowney" , Date: Thu, 14 Aug 2003 21:02:29 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: WebDAV Compliance Case Studies X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIENAICAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7829 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Frank, 1) I'd say whenever Litmus is reporting a FAIL that is serious. For instance, the FAIL for props 3 indicates that the server doesn't use a compliant XML parser. 2) Did you use the latest Litmus version? 0.9.2 includes many more tests, I'm not sure why they weren't run in your case (maybe -k doesn't work as advertised). For instance, I'm missing results of LOCK tests. At the end of the day, Litmus is the thing closest to a "conformance test suite" that we have. If a server produces failures, I'd recommend to get back to the vendor and ask for an explanation. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Frank Lowney > Sent: Thursday, August 14, 2003 8:32 PM > To: w3c-dist-auth@w3.org > Subject: WebDAV Compliance Case Studies > > > > Continuing with the WebSTAR V case study and following Julian > Reschke's tip on running the litmus test, we have more results for > your comment. How many of these failure pointa map to real world > operations likely to impact end users? > > -> running `basic': > 0. init.................. pass > 1. begin................. pass > 2. options............... pass > 3. put_get............... pass > 4. put_get_utf8_segment.. pass > 5. mkcol_over_plain...... pass > 6. delete................ pass > 7. delete_null........... pass > 8. mkcol................. pass > 9. mkcol_again........... pass > 10. delete_coll........... pass > 11. mkcol_no_parent....... WARNING: MKCOL with missing intermediate > gave 403, should be 409 > ...................... pass (with 1 warning) > 12. mkcol_with_body....... FAIL (MKCOL with weird body must fail > (RFC2518:8.3.1)) > 13. finish................ pass > <- summary for `basic': of 14 tests run: 13 passed, 1 failed. 92.9% > -> 1 warning was issued. > -> running `copymove': > 0. init.................. pass > 1. begin................. pass > 2. copy_init............. pass > 3. copy_simple........... pass > 4. copy_overwrite........ pass > 5. copy_cleanup.......... pass > 6. copy_coll............. pass > 7. move.................. pass > 8. move_coll............. FAIL (MOVE collection > `/path/litmus/mvdest2/' over non-collection `/path/litmus/mvnoncoll' > with overwrite: 404 Not Found) > 9. move_cleanup.......... pass > 10. finish................ pass > <- summary for `copymove': of 11 tests run: 10 passed, 1 failed. 90.9% > -> running `props': > 0. init.................. pass > 1. begin................. pass > 2. propfind_invalid...... pass > 3. propfind_invalid2..... FAIL (PROPFIND with invalid namespace > declaration in body (see FAQ) got 207 response not 400) > 4. propfind_d0........... pass > 5. propinit.............. pass > 6. propset............... pass > 7. propget............... pass > 8. propmove.............. pass > 9. propget............... pass > 10. propdeletes........... pass > 11. propget............... pass > 12. propreplace........... pass > 13. propget............... pass > 14. propnullns............ pass > 15. propget............... FAIL (PROPFIND on `/path/litmus/prop2': > Invalid namespace declaration for 'xmlns:ns2' in 'D:response' at line > 2.) > 16. prophighunicode....... pass > 17. propget............... FAIL (PROPFIND on `/path/litmus/prop2': > Invalid namespace declaration for 'xmlns:ns2' in 'D:response' at line > 2.) > 18. propvalnspace......... pass > 19. propwformed........... FAIL (PROPFIND response was not > well-formed: Invalid namespace declaration for 'xmlns:ns2' in > 'D:response' at line 2.) > 20. propinit.............. pass > 21. propmanyns............ pass > 22. propget............... pass > 23. propcleanup........... pass > 24. finish................ pass > <- summary for `props': of 25 tests run: 21 passed, 4 failed. 84.0% > -> running `http': > 0. init.................. pass > 1. begin................. pass > 2. expect100............. FAIL (timeout waiting for interim response) > 3. finish................ pass > <- summary for `http': of 4 tests run: 3 passed, 1 failed. 75.0% > -- > ===================================================================== > Dr. Frank Lowney flowney@mail.gcsu.edu > Director, Electronic Instructional Services, a unit of the > Office of Information and Instructional Technology, > Professional Pages: http://www.gcsu.edu/oiit/eis/ > Personal Pages: http://www.faculty.de.gcsu.edu/~flowney > Voice: (478) 445-5260 > ===================================================================== > We don't make instruction effective, we make effective instruction > more accessible. > From w3c-dist-auth-request@w3.org Sun Aug 17 06:52:44 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11047 for ; Sun, 17 Aug 2003 06:52:44 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7HAqmpI027143; Sun, 17 Aug 2003 06:52:48 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7HAqF8W027133; Sun, 17 Aug 2003 06:52:15 -0400 (EDT) Resent-Date: Sun, 17 Aug 2003 06:52:15 -0400 (EDT) Resent-Message-Id: <200308171052.h7HAqF8W027133@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7HAqDpI027100 for ; Sun, 17 Aug 2003 06:52:13 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h7HAqCGB006688 for ; Sun, 17 Aug 2003 06:52:13 -0400 Received: (qmail 17433 invoked by uid 65534); 17 Aug 2003 10:52:01 -0000 Received: from p3EE24818.dip.t-dialin.net (HELO lisa) (62.226.72.24) by mail.gmx.net (mp014) with SMTP; 17 Aug 2003 12:52:01 +0200 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Webdav WG'" Date: Sun, 17 Aug 2003 12:51:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <010901c3605d$948bc9c0$f8cb90c6@lisalap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h7HAqDpI027100 Subject: RE: Changing etag and getlastmodified on move/rename X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEBFIDAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7830 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Lisa, you are right that WebDAV absolutely can't overrule what RFC2616 (HTTP/1.1) says about the Last-Modified header and caching. Thus 1) We probably should clarify the COPY/MOVE behaviour. Currently the draft says: "COPY/MOVE behaviour: This property value is dependent on the final state of the destination resource, not the value of the property on the source resource. It MUST NOT be set in PROPPATCH during a cross-server copy. " How is the previous DAV:getlastmodified date of the destination resource relevant? I think the only safe way to respect RFC2616 semantics is to require that after a COPY/MOVE, DAV:getlastmodified is set to the current date. 2) I also agree that this is likely to cause complaints from people who actually want a time stamp for *resource* modifications. A proper way to address this may be to define a new optional property (if we make it optional, we may be able to get it into RFC52518bis), for instance: Name: modificationdate Namespace: DAV: Purpose: Records the time and date the resource was modified. Value: date-time COPY/MOVE behaviour: This property value SHOULD be kept during a MOVE operation, but is re-initialized when a resource is created with a COPY. It should not be set in a remote COPY. Description: The creationdate property should be defined on all DAV compliant resources. If present, it contains a timestamp of the moment when the resource was last modified (i.e., the moment when content and/or propertoes last changed). This property is live and protected. The Internet date-time format is defined in [RFC3339], see the ABNF in section 5.6. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Aug 17 07:04:19 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11205 for ; Sun, 17 Aug 2003 07:04:19 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7HB4NpI028782; Sun, 17 Aug 2003 07:04:23 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7HB4LLE028762; Sun, 17 Aug 2003 07:04:21 -0400 (EDT) Resent-Date: Sun, 17 Aug 2003 07:04:21 -0400 (EDT) Resent-Message-Id: <200308171104.h7HB4LLE028762@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7HB4KpI028728 for ; Sun, 17 Aug 2003 07:04:20 -0400 (EDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with SMTP id h7HB4JGB007663 for ; Sun, 17 Aug 2003 07:04:19 -0400 Received: (qmail 5732 invoked by uid 65534); 17 Aug 2003 11:04:13 -0000 Received: from p3EE24818.dip.t-dialin.net (HELO lisa) (62.226.72.24) by mail.gmx.net (mp014) with SMTP; 17 Aug 2003 13:04:13 +0200 From: "Julian Reschke" To: "'Webdav WG'" Date: Sun, 17 Aug 2003 13:03:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: new issue: DAV:displayname X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEBGIDAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7831 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, looking at our recent discussion, I feel that we clearly have a problem with the usage of DAV:displayname. The current situation seems to be: 1) Some servers implement DAV:displayname as protected live property that just reflects the last name segment of the request URI (Microsoft IIS) 2) Other servers implement DAV:displayname as dead property that by default is not set until it get's explicitly set by a client (Apache moddav) We are currently discussing whether 1) is ok. My position is that it's clearly not, as - the value of the last path segment is not "a description of the resource that is suitable for presentation to a user", - replicating something that's already available from the element of the PROPFIND response into a property just has no benefit at all, - clients demonstratibly can cope with absent DAV:displayname values (as they all interoperate with Apache moddav today) and finally - the concept of a property that varies with the request URI is deeply incompatible with the concept of multiple bindings to resources. So my preference would be just to state that DAV:displayname SHOULD NOT be used to replicate the information from the last path segment. Another alternative would be to *deprecate* DAV:displayname and to define a new property with more precisely defined semantics, such as DAV:description. Note that this in fact *is* a interoperability issues, as we are getting lots of complaints from users not being able to set display names on some remote WebDAV servers mounted into the SAP Enterprise Portal. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Aug 17 08:58:20 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12562 for ; Sun, 17 Aug 2003 08:58:20 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7HCwNpI012319; Sun, 17 Aug 2003 08:58:23 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7HCwIUg012295; Sun, 17 Aug 2003 08:58:18 -0400 (EDT) Resent-Date: Sun, 17 Aug 2003 08:58:18 -0400 (EDT) Resent-Message-Id: <200308171258.h7HCwIUg012295@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7HCwFpI012258 for ; Sun, 17 Aug 2003 08:58:15 -0400 (EDT) Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7HCwEGB016339 for ; Sun, 17 Aug 2003 08:58:14 -0400 Received: from daehub01.software-ag.de by server8a.software-ag.de; (8.11.6/8.9.3) id h7HCwD324890; Sun, 17 Aug 2003 14:58:13 +0200 Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2653.19) id ; Sun, 17 Aug 2003 14:58:11 +0200 Message-ID: From: "Nevermann, Dr., Peter" To: "'w3c-dist-auth@w3c.org'" Date: Sun, 17 Aug 2003 14:57:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C364BF.279FA190" Subject: COPY and bindings II X-Archived-At: http://www.w3.org/mid/DFF2AC9E3583D511A21F0008C7E6210605C48010@daemsg02.software-ag.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7832 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C364BF.279FA190 Content-Type: text/plain; charset="iso-8859-1" A while ago I asked, whether - assuming no resource at destination to overwrite - COPY should preserve bindings, i.e. should COPY yield 1) or 2) (see below): 1) |u1 --COPY--> |u2 C C' a/ \b a/ \b C1 C2 Ca Cb x\ /y x| |y R Rx Ry 2) |u1 --COPY--> |u2 C C' a/ \b a/ \b C1 C2 Ca Cb x\ /y x\ /y R R' Most of you voted for 2). Now, assuming there *were* resources at destination to overwrite - take diagram 1) for visualization, where C', Ca, Cb, Rx, Ry all existed beforehand - I assume that COPY u1->u2 would result in Rx and Ry both being updated with content + dead-properties from R. And, again using diagram 1) and assuming all shown resources existed beforehand, what happens if we do the COPY the other way round, i.e. COPY u2->u1? The Binding spec states in section 2.3, last paragraph: "If a COPY causes one or more existing resources to be updated, the bindings to those resources MUST be unaffected by the COPY." Is it then correct, that while copying the C'-tree over the C-tree, resource R is first updated by Rx and then again by Ry (or the other way round)? That is, one of Rx or Ry "wins" in updating R? Hm??? Regards, Peter ------_=_NextPart_001_01C364BF.279FA190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable COPY and bindings II

A while ago I asked, whether - assuming no resource = at destination to overwrite - COPY should preserve bindings, i.e. = should COPY yield 1) or 2) (see below):

1)
      = |u1     --COPY-->    |u2
      = C            = ;        C' 
    a/  = \b           &nbs= p;   a/  \b
    C1  = C2           &nbs= p;   Ca  Cb
    x\  = /y           &nbs= p;  x|    |y
      = R            = ;      Rx  Ry

2)
      = |u1     --COPY-->    = |u2   
      = C            = ;        C' 
    a/  = \b           &nbs= p;   a/  \b
    C1  = C2           &nbs= p;   Ca  Cb
    x\  = /y           &nbs= p;   x\  /y
      = R            = ;        R'

Most of you voted for 2).

Now, assuming there *were* resources at destination = to overwrite - take diagram 1) for visualization, where C', Ca, Cb, Rx, = Ry all existed beforehand - I assume that COPY u1->u2 would result = in Rx and Ry both being updated with content + dead-properties from = R.

And, again using diagram 1) and assuming all shown = resources existed beforehand, what happens if we do the COPY the other = way round, i.e. COPY u2->u1? The Binding spec states in section 2.3, = last paragraph:

"If a COPY causes one or more existing resources = to be updated, the bindings to those resources MUST be unaffected by = the COPY."

Is it then correct, that while copying the C'-tree = over the C-tree, resource R is first updated by Rx and then again by Ry = (or the other way round)? That is, one of Rx or Ry "wins" in = updating R? Hm???

Regards,
Peter

------_=_NextPart_001_01C364BF.279FA190-- From w3c-dist-auth-request@w3.org Sun Aug 17 16:01:50 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19799 for ; Sun, 17 Aug 2003 16:01:50 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7HK1qpI009413; Sun, 17 Aug 2003 16:01:52 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7HK1XNX009373; Sun, 17 Aug 2003 16:01:33 -0400 (EDT) Resent-Date: Sun, 17 Aug 2003 16:01:33 -0400 (EDT) Resent-Message-Id: <200308172001.h7HK1XNX009373@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7HK1VpI009340 for ; Sun, 17 Aug 2003 16:01:31 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7HK1UGB022760 for ; Sun, 17 Aug 2003 16:01:31 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.12.1) id h7HK1UwQ004277 sender ccjason@us.ibm.com for w3c-dist-auth@w3c.org; Sun, 17 Aug 2003 13:01:30 -0700 Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by sunbelt.seagull.net (8.12.1) with ESMTP id h7HK1SCC004252 sender ccjason@us.ibm.com; Sun, 17 Aug 2003 13:01:29 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7HK1R4X616482; Sun, 17 Aug 2003 16:01:28 -0400 Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7HK1Qjf079650; Sun, 17 Aug 2003 16:01:27 -0400 To: "Julian Reschke" Cc: "'Webdav WG'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Jason Crawford Message-ID: Date: Sun, 17 Aug 2003 16:01:20 -0400 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V65_08112003|August 11, 2003) at 08/17/2003 16:01:26, Serialize complete at 08/17/2003 16:01:26 Content-Type: text/plain; charset="us-ascii" Subject: Re: new issue: DAV:displayname X-Archived-At: http://www.w3.org/mid/OFD9C425B1.5A1944CA-ON85256D85.006C3B16-85256D85.006DFA83@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7833 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Sunday, 08/17/2003 at 01:03 ZE2, "Julian Reschke" wrote: > Hi, > > looking at our recent discussion, I feel that we clearly have a problem with > the usage of DAV:displayname. > > The current situation seems to be: > > 1) Some servers implement DAV:displayname as protected live property that > just reflects the last name segment of the request URI (Microsoft IIS) > > 2) Other servers implement DAV:displayname as dead property that by default > is not set until it get's explicitly set by a client (Apache moddav) I tend to agree with you that among these two choices (2) is superior. But that seems obvious. What's more interesting is whether (3) A server can treat it as a dead property but initialize it to the segment name. My impression is that (2) is still a better approach. Are there issues for mapping this to a file system? J. From w3c-dist-auth-request@w3.org Sun Aug 17 16:27:04 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20103 for ; Sun, 17 Aug 2003 16:27:04 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7HKR7pI011467; Sun, 17 Aug 2003 16:27:07 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7HKR6sS011444; Sun, 17 Aug 2003 16:27:06 -0400 (EDT) Resent-Date: Sun, 17 Aug 2003 16:27:06 -0400 (EDT) Resent-Message-Id: <200308172027.h7HKR6sS011444@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7HKR3pI011407 for ; Sun, 17 Aug 2003 16:27:03 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7HKR2GB024275 for ; Sun, 17 Aug 2003 16:27:03 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.12.1) id h7HKR385006363 sender julian.reschke@gmx.de for w3c-dist-auth@w3c.org; Sun, 17 Aug 2003 13:27:03 -0700 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by sunbelt.seagull.net (8.12.1) with SMTP id h7HKR13F006331 sender julian.reschke@gmx.de for ; Sun, 17 Aug 2003 13:27:01 -0700 Received: (qmail 28258 invoked by uid 65534); 17 Aug 2003 20:26:50 -0000 Received: from pD950C247.dip.t-dialin.net (HELO lisa) (217.80.194.71) by mail.gmx.net (mp002) with SMTP; 17 Aug 2003 22:26:50 +0200 From: "Julian Reschke" To: "Jason Crawford" , "Julian Reschke" Cc: "'Webdav WG'" Date: Sun, 17 Aug 2003 22:25:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Subject: RE: new issue: DAV:displayname X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEBPIDAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7834 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Sunday, August 17, 2003 10:01 PM > To: Julian Reschke > Cc: 'Webdav WG' > Subject: Re: new issue: DAV:displayname > > > > On Sunday, 08/17/2003 at 01:03 ZE2, "Julian Reschke" > wrote: > > Hi, > > > > looking at our recent discussion, I feel that we clearly have a problem with > > the usage of DAV:displayname. > > > > The current situation seems to be: > > > > 1) Some servers implement DAV:displayname as protected live property that > > just reflects the last name segment of the request URI (Microsoft IIS) > > > > 2) Other servers implement DAV:displayname as dead property that by default > > is not set until it get's explicitly set by a client (Apache moddav) > > I tend to agree with you that among these two choices (2) is superior. But > that seems obvious. What's more interesting is whether > > (3) A server can treat it as a dead property but initialize it to the segment > name. If I understand you correctly the server would set an initial value, and then treat the property as dead. The result would be that unless a client resets the DAV:displayname, it will always be the last segment of the request URL where the resource was initially created (even if it was MOVEd later). I think that sounds even worse than (1). > My impression is that (2) is still a better approach. Yes. > Are there issues for mapping this to a file system? Not really. A server that supports setting of dead properties (such as Apache/moddav) doesn't have any issue. A server that does not support dead properties on a certain resource will just reject the PROPPATCHH attempt. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Aug 17 16:32:22 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20169 for ; Sun, 17 Aug 2003 16:32:21 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7HKWPpI012057; Sun, 17 Aug 2003 16:32:25 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7HKWOBK012045; Sun, 17 Aug 2003 16:32:24 -0400 (EDT) Resent-Date: Sun, 17 Aug 2003 16:32:24 -0400 (EDT) Resent-Message-Id: <200308172032.h7HKWOBK012045@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7HKWNpI012012 for ; Sun, 17 Aug 2003 16:32:23 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7HKWNGB024753 for ; Sun, 17 Aug 2003 16:32:23 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.12.1) id h7HKWMuv006537 sender ccjason@us.ibm.com for w3c-dist-auth@w3c.org; Sun, 17 Aug 2003 13:32:22 -0700 Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by sunbelt.seagull.net (8.12.1) with ESMTP id h7HKWL67006512 sender ccjason@us.ibm.com; Sun, 17 Aug 2003 13:32:21 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7HKWKkh700220; Sun, 17 Aug 2003 16:32:20 -0400 Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7HKWJKh056186; Sun, 17 Aug 2003 16:32:19 -0400 To: "Julian Reschke" Cc: "'Webdav WG'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Jason Crawford Message-ID: Date: Sun, 17 Aug 2003 16:32:08 -0400 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V65_08112003|August 11, 2003) at 08/17/2003 16:32:20, Serialize complete at 08/17/2003 16:32:20 Content-Type: text/plain; charset="us-ascii" Subject: RE: Changing etag and getlastmodified on move/rename X-Archived-At: http://www.w3.org/mid/OFB0F01881.77B1BAA0-ON85256D85.006ECD81-85256D85.0070CC46@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7835 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Sunday, 08/17/2003 at 12:51 ZE2, "Julian Reschke" wrote: > I think the only safe way to respect RFC2616 semantics is to require that after > a COPY/MOVE, DAV:getlastmodified is set to the current date. > > 2) I also agree that this is likely to cause complaints from people who > actually want a time stamp for *resource* modifications. So it sounds like getlastmodified becomes a 100% live property that really isn't a property of the resource, but instead is a property of the URL. It won't be setable and it's up to the server to maintain some sort of database to track if the mapping of any given URL has changed since some other point in time or if the resource itself has been modified. Is this doable? Would a server tend to do this recursively? ie, Every binding has an age and the URL can be no older than any of the bindings that are currently traversed to reach that URL? Or is there a better way to maintain the semantics that you propose we maintain? Do servers already do this sort of thing? If I mv a resource in to a directory served by Apache, does it use the date the file system lists, or something newer? J. From w3c-dist-auth-request@w3.org Sun Aug 17 22:08:33 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26151 for ; Sun, 17 Aug 2003 22:08:32 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7I28ZpI003743; Sun, 17 Aug 2003 22:08:36 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7I287wf003720; Sun, 17 Aug 2003 22:08:07 -0400 (EDT) Resent-Date: Sun, 17 Aug 2003 22:08:07 -0400 (EDT) Resent-Message-Id: <200308180208.h7I287wf003720@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7I285pI003687 for ; Sun, 17 Aug 2003 22:08:05 -0400 (EDT) Received: from mail.xythos.com ([206.14.210.116]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7I284GB024800 for ; Sun, 17 Aug 2003 22:08:05 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 19oZRE-0007NN-00; Mon, 18 Aug 2003 02:08:04 +0000 Received: from [198.144.203.248] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 19oZRD-0007NC-00; Mon, 18 Aug 2003 02:08:04 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Webdav WG'" Date: Sun, 17 Aug 2003 19:08:50 -0700 Message-ID: <003701c3652d$aac47000$f8cb90c6@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Old-X-Envelope-To: julian.reschke@gmx.de, w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id h7I285pI003687 Subject: RE: Changing etag and getlastmodified on move/rename X-Archived-At: http://www.w3.org/mid/003701c3652d$aac47000$f8cb90c6@lisalap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7836 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit I agree with all of this. I have no problems putting an optional modificationdate in RFC2518bis if we can get agreement quickly because I think it could be implemented extremely quickly in several implementations. Lisa > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Sunday, August 17, 2003 3:51 AM > To: Lisa Dusseault; 'Julian Reschke'; 'Webdav WG' > Subject: RE: Changing etag and getlastmodified on move/rename > > > Lisa, > > you are right that WebDAV absolutely can't overrule what > RFC2616 (HTTP/1.1) says about the Last-Modified header and > caching. Thus > > 1) We probably should clarify the COPY/MOVE behaviour. > Currently the draft says: > > "COPY/MOVE behaviour: This property value is dependent on the final > state of the destination resource, not the value of the > property on the source resource. It MUST NOT be set in > PROPPATCH during a cross-server copy. " > > How is the previous DAV:getlastmodified date of the > destination resource relevant? > > I think the only safe way to respect RFC2616 semantics is to > require that after a COPY/MOVE, DAV:getlastmodified is set to > the current date. > > > 2) I also agree that this is likely to cause complaints from > people who actually want a time stamp for *resource* > modifications. A proper way to address this may be to define > a new optional property (if we make it optional, we may be > able to get it into RFC52518bis), for instance: > > Name: modificationdate > Namespace: DAV: > Purpose: Records the time and date the resource was modified. > Value: date-time > COPY/MOVE behaviour: This property value SHOULD be kept during a > MOVE operation, but is re-initialized when a resource is > created with a COPY. It should not be set in a > remote COPY. > Description: The creationdate property should be defined > on all DAV > compliant resources. If present, it contains a timestamp > of the moment when the resource was last modified > (i.e., the > moment when content and/or propertoes last changed). > This property is live and > protected. The Internet date-time format is defined in > [RFC3339], see the ABNF in section 5.6. > > > > Julian > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Mon Aug 18 09:53:33 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18939 for ; Mon, 18 Aug 2003 09:53:33 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7IDrZpI025043; Mon, 18 Aug 2003 09:53:35 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7IDrJ6W025024; Mon, 18 Aug 2003 09:53:19 -0400 (EDT) Resent-Date: Mon, 18 Aug 2003 09:53:19 -0400 (EDT) Resent-Message-Id: <200308181353.h7IDrJ6W025024@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7IDrIpI024991 for ; Mon, 18 Aug 2003 09:53:18 -0400 (EDT) Received: from mucmx02.ixos.de (HOST.31.93.ixos.de [149.235.31.93]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7IDrHGB029821 for ; Mon, 18 Aug 2003 09:53:17 -0400 Received: from MUCXG02.ixos.de (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.9/8.12.9) with ESMTP id h7IDr91P018130; Mon, 18 Aug 2003 15:53:09 +0200 (MEST) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Aug 2003 15:52:46 +0200 Message-ID: <077097E85A6BD3119E910800062786A905121EBA@muc-mail5.ixos.de> From: Horst Liermann To: "'Julian Reschke'" , "'Webdav WG'" Date: Mon, 18 Aug 2003 15:52:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: new issue: DAV:displayname X-Archived-At: http://www.w3.org/mid/077097E85A6BD3119E910800062786A905121EBA@muc-mail5.ixos.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7837 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Hi, I have installed "MS Sharepoint" and I tested the behavior of Sharepoint. Sharepoint is a basic WebDAV implementation. They have something like versioning, but it's not DeltaV. As far as I understand MS-Sharepoint, the behavior is: There is a URL "segment name" for the name of the resource. There is a DAV:displayname for the "title" of the resource. DAV:displayname normaly is not the same as the "segment name". So DAV:displayname is a "dead" property It's also possible NOT setting the property DAV:displayname. Behavior is like 2). Horst -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Sunday, August 17, 2003 1:03 PM To: 'Webdav WG' Subject: new issue: DAV:displayname Hi, looking at our recent discussion, I feel that we clearly have a problem with the usage of DAV:displayname. The current situation seems to be: 1) Some servers implement DAV:displayname as protected live property that just reflects the last name segment of the request URI (Microsoft IIS) 2) Other servers implement DAV:displayname as dead property that by default is not set until it get's explicitly set by a client (Apache moddav) We are currently discussing whether 1) is ok. My position is that it's clearly not, as - the value of the last path segment is not "a description of the resource that is suitable for presentation to a user", - replicating something that's already available from the element of the PROPFIND response into a property just has no benefit at all, - clients demonstratibly can cope with absent DAV:displayname values (as they all interoperate with Apache moddav today) and finally - the concept of a property that varies with the request URI is deeply incompatible with the concept of multiple bindings to resources. So my preference would be just to state that DAV:displayname SHOULD NOT be used to replicate the information from the last path segment. Another alternative would be to *deprecate* DAV:displayname and to define a new property with more precisely defined semantics, such as DAV:description. Note that this in fact *is* a interoperability issues, as we are getting lots of complaints from users not being able to set display names on some remote WebDAV servers mounted into the SAP Enterprise Portal. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Aug 18 11:01:22 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21820 for ; Mon, 18 Aug 2003 11:01:22 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7IF1OpI012009; Mon, 18 Aug 2003 11:01:24 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7IF1GBI011988; Mon, 18 Aug 2003 11:01:16 -0400 (EDT) Resent-Date: Mon, 18 Aug 2003 11:01:16 -0400 (EDT) Resent-Message-Id: <200308181501.h7IF1GBI011988@frink.w3.org> Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (8.12.9/8.12.9) with ESMTP id h7IF1EpI011949 for ; Mon, 18 Aug 2003 11:01:14 -0400 (EDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by dr-nick.w3.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7IF1EGB006162 for ; Mon, 18 Aug 2003 11:01:14 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7IF184X610146 for ; Mon, 18 Aug 2003 11:01:08 -0400 Received: from D01ML239.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7IF17Uw135886 for ; Mon, 18 Aug 2003 11:01:07 -0400 In-Reply-To: <003701c3652d$aac47000$f8cb90c6@lisalap> To: "'Webdav WG'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 From: Geoffrey M Clemm Message-ID: Date: Mon, 18 Aug 2003 11:01:06 -0400 X-MIMETrack: Serialize by Router on D01ML239/01/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 08/18/2003 11:01:07, Serialize complete at 08/18/2003 11:01:07 Content-Type: multipart/alternative; boundary="=_alternative 0048312D85256D86_=" Subject: RE: Changing etag and getlastmodified on move/rename X-Archived-At: http://www.w3.org/mid/OF9FBF34F0.8FF65711-ON85256D86.00479B16-85256D86.00528006@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7838 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0048312D85256D86_= Content-Type: text/plain; charset="US-ASCII" Since RFC2616 explicitly states that a server may use the file system last-modified dates for the value of the Last-Modified header, I suggest that we also add words to the effect that: "To deal correctly with servers that use the native repository last-modified times which are not updated by a MOVE, a conservative caching mechanism will store the results of the previous getlastmodified date, and only assume the cache is valid if the current getlastmodified date is equal to the stored getlastmodified date". Cheers, Geoff w3c-dist-auth-request@w3.org wrote on 08/17/2003 10:08:50 PM: > > I agree with all of this. I have no problems putting an optional > modificationdate in RFC2518bis if we can get agreement quickly > because I think it could be implemented extremely quickly in several > implementations. > > Lisa > > > -----Original Message----- > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > Sent: Sunday, August 17, 2003 3:51 AM > > To: Lisa Dusseault; 'Julian Reschke'; 'Webdav WG' > > Subject: RE: Changing etag and getlastmodified on move/rename > > > > > > Lisa, > > > > you are right that WebDAV absolutely can't overrule what > > RFC2616 (HTTP/1.1) says about the Last-Modified header and > > caching. Thus > > > > 1) We probably should clarify the COPY/MOVE behaviour. > > Currently the draft says: > > > > "COPY/MOVE behaviour: This property value is dependent on the final > > state of the destination resource, not the value of the > > property on the source resource. It MUST NOT be set in > > PROPPATCH during a cross-server copy. " > > > > How is the previous DAV:getlastmodified date of the > > destination resource relevant? > > > > I think the only safe way to respect RFC2616 semantics is to > > require that after a COPY/MOVE, DAV:getlastmodified is set to > > the current date. > > > > > > 2) I also agree that this is likely to cause complaints from > > people who actually want a time stamp for *resource* > > modifications. A proper way to address this may be to define > > a new optional property (if we make it optional, we may be > > able to get it into RFC52518bis), for instance: > > > > Name: modificationdate > > Namespace: DAV: > > Purpose: Records the time and date the resource was modified. > > Value: date-time > > COPY/MOVE behaviour: This property value SHOULD be kept during a > > MOVE operation, but is re-initialized when a resource is > > created with a COPY. It should not be set in a > > remote COPY. > > Description: The creationdate property should be defined > > on all DAV > > compliant resources. If present, it contains a timestamp > > of the moment when the resource was last modified > > (i.e., the > > moment when content and/or propertoes last changed). > > This property is live and > > protected. The Internet date-time format is defined in > > [RFC3339], see the ABNF in section 5.6. > > > > > > > > Julian > > > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > > > > --=_alternative 0048312D85256D86_= Content-Type: text/html; charset="US-ASCII"
Since RFC2616 explicitly states that a server may use
the file system last-modified dates for the value of the
Last-Modified header, I suggest that we also add words
to the effect that:

"To deal correctly with servers that use the native
repository last-modified times which are not updated by a MOVE,
a conservative caching mechanism will store the results of the previous
getlastmodified date, and only assume the cache is valid if
the current getlastmodified date is equal to the stored
getlastmodified date".

Cheers,
Geoff


w3c-dist-auth-request@w3.org wrote on 08/17/2003 10:08:50 PM:

>
> I agree with all of this.  I have no problems putting an optional
> modificationdate in RFC2518bis if we can get agreement quickly
> because I think it could be implemented extremely quickly in several
> implementations.  
>
> Lisa
>
> > -----Original Message-----
> > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > Sent: Sunday, August 17, 2003 3:51 AM
> > To: Lisa Dusseault; 'Julian Reschke'; 'Webdav WG'
> > Subject: RE: Changing etag and getlastmodified on move/rename
> >
> >
> > Lisa,
> >
> > you are right that WebDAV absolutely can't overrule what
> > RFC2616 (HTTP/1.1) says about the Last-Modified header and
> > caching. Thus
> >
> > 1) We probably should clarify the COPY/MOVE behaviour.
> > Currently the draft says:
> >
> > "COPY/MOVE behaviour: This property value is dependent on the final
> >             state of the destination resource, not the value of the
> >             property on the source resource. It MUST NOT be set in
> >             PROPPATCH during a cross-server copy. "
> >
> > How is the previous DAV:getlastmodified date of the
> > destination resource relevant?
> >
> > I think the only safe way to respect RFC2616 semantics is to
> > require that after a COPY/MOVE, DAV:getlastmodified is set to
> > the current date.
> >
> >
> > 2) I also agree that this is likely to cause complaints from
> > people who actually want a time stamp for *resource*
> > modifications. A proper way to address this may be to define
> > a new optional property (if we make it optional, we may be
> > able to get it into RFC52518bis), for instance:
> >
> >    Name:    modificationdate
> >    Namespace:   DAV:
> >    Purpose:     Records the time and date the resource was modified.
> >    Value:   date-time  
> >    COPY/MOVE behaviour: This property value SHOULD be kept during a
> >             MOVE operation, but is re-initialized when a resource is
> >             created with a COPY. It should not be set in a
> > remote COPY.
> >    Description: The creationdate property should be defined
> > on all DAV
> >             compliant resources.  If present, it contains a timestamp
> >             of the moment when the resource was last modified
> > (i.e., the
> >             moment when content and/or propertoes last changed).
> >             This property is live and
> >             protected. The Internet date-time format is defined in
> >             [RFC3339], see the ABNF in section 5.6.
> >    
> >    <!ELEMENT modificationdate (#PCDATA) >
> >    
> > Julian
> >
> >
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >
> >
>
>
>
--=_alternative 0048312D85256D86_=-- From w3c-dist-auth-request@w3.org Sat Aug 23 10:31:50 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12074 for ; Sat, 23 Aug 2003 10:31:49 -0400 (EDT) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (Postfix) with ESMTP id 6739AAAC99; Sat, 23 Aug 2003 07:12:47 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.12.9/8.12.9/Submit) id h7NBCTZg002259; Sat, 23 Aug 2003 07:12:29 -0400 (EDT) Resent-Date: Sat, 23 Aug 2003 07:12:29 -0400 (EDT) Resent-Message-Id: <200308231112.h7NBCTZg002259@frink.w3.org> X-Original-To: w3c-dist-auth@frink.w3.org Delivered-To: w3c-dist-auth@frink.w3.org Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73]) by frink.w3.org (Postfix) with ESMTP id C5EC942C3 for ; Fri, 22 Aug 2003 18:25:31 -0400 (EDT) Received: by dr-nick.w3.org (Postfix) id A5D7D1CBED; Fri, 22 Aug 2003 08:03:45 -0400 (EDT) Delivered-To: w3c-dist-auth@w3.org Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by dr-nick.w3.org (Postfix) with ESMTP id CCBBC24F50 for ; Fri, 22 Aug 2003 08:03:41 -0400 (EDT) Received: from daehub01.software-ag.de by server8a.software-ag.de; (8.11.6/8.9.3) id h7MC3b330425; Fri, 22 Aug 2003 14:03:37 +0200 Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Aug 2003 14:03:36 +0200 Message-ID: From: "Nevermann, Dr., Peter" To: "'WebDAV Mailing List'" Date: Fri, 22 Aug 2003 14:03:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C368A5.6A233290" Subject: RE: COPY and bindings II X-Archived-At: http://www.w3.org/mid/DFF2AC9E3583D511A21F0008C7E6210605C4802B@daemsg02.software-ag.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7839 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C368A5.6A233290 Content-Type: text/plain; charset="iso-8859-1" On behalf of Geoff Clemm: Peter: This keeps bouncing when I try to send it to the w3c-dist-auth@w3c.org mailing list ... could you try posting it for me? Thanks, Geoff ----- Forwarded by Geoffrey M Clemm/Lexington/IBM on 08/21/2003 04:15 PM ----- Geoffrey M Clemm/Lexington/IBM 08/20/2003 06:08 PM To "Nevermann, Dr., Peter" cc "'w3c-dist-auth@w3c.org'" , w3c-dist-auth-request@w3.org Subject Re: COPY and bindings II Yes, we need language to cover the case Peter describes. I suggest we add the sentence: If because of multiple bindings to a resource, more than one source resource updates a single destination resource, the order of the updates is server defined. Also, I notices that the current description of COPY does not fully cover the case where the COPY creates a new copy of a resource when there were multiple bindings to that resource in the source of the copy. To remedy this omission, I propose that we replace the final paragraph of section 2.3 of the Binding protocol with: If a COPY request would cause a new resource to be created as a copy of an existing resource, and that COPY request has already created a copy of that existing resource, the COPY request instead creates another binding to the previous copy, instead of creating a new resource. Cheers, Geoff Peter wrote on 08/17/2003 08:57:46 AM: > A while ago I asked, whether - assuming no resource at destination > to overwrite - COPY should preserve bindings, i.e. should COPY yield > 1) or 2) (see below): > 1) > |u1 --COPY--> |u2 > C C' > a/ \b a/ \b > C1 C2 Ca Cb > x\ /y x| |y > R Rx Ry > 2) > |u1 --COPY--> |u2 > C C' > a/ \b a/ \b > C1 C2 Ca Cb > x\ /y x\ /y > R R' > Most of you voted for 2). > Now, assuming there *were* resources at destination to overwrite - > take diagram 1) for visualization, where C', Ca, Cb, Rx, Ry all > existed beforehand - I assume that COPY u1->u2 would result in Rx > and Ry both being updated with content + dead-properties from R. > And, again using diagram 1) and assuming all shown resources existed > beforehand, what happens if we do the COPY the other way round, i.e. > COPY u2->u1? The Binding spec states in section 2.3, last paragraph: > "If a COPY causes one or more existing resources to be updated, the > bindings to those resources MUST be unaffected by the COPY." > Is it then correct, that while copying the C'-tree over the C-tree, > resource R is first updated by Rx and then again by Ry (or the other > way round)? That is, one of Rx or Ry "wins" in updating R? Hm??? > Regards, > Peter ------_=_NextPart_001_01C368A5.6A233290 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: COPY and bindings II

On behalf of Geoff Clemm:

Peter:  This keeps bouncing when I try to send = it to the
w3c-dist-auth@w3c.org mailing list ... could you try = posting it for me?

Thanks,
Geoff

----- Forwarded by Geoffrey M Clemm/Lexington/IBM on = 08/21/2003 04:15 PM
-----

Geoffrey M Clemm/Lexington/IBM
08/20/2003 06:08 PM

To
"Nevermann, Dr., Peter" = <Peter.Nevermann@softwareag.com>
cc
"'w3c-dist-auth@w3c.org'" = <w3c-dist-auth@w3c.org>,
w3c-dist-auth-request@w3.org
Subject
Re: COPY and bindings II





Yes, we need language to cover the case Peter = describes.  I suggest we
add the sentence:

If because of multiple bindings to a resource, more = than one source
resource updates a single destination resource, the = order of the
updates is server defined.

Also, I notices that the current description of COPY = does not fully cover
the case where the COPY creates a new copy of a = resource when there were
multiple bindings to that resource in the source of = the copy.  To remedy
this omission, I propose that we replace the final = paragraph of section
2.3
of the Binding protocol with:

If a COPY request would cause a new resource to be = created
as a copy of an existing resource, and that COPY = request
has already created a copy of that existing = resource,
the COPY request instead creates another binding to = the
previous copy, instead of creating a new = resource.
Cheers,
Geoff

Peter wrote on 08/17/2003 08:57:46 AM:

> A while ago I asked, whether - assuming no = resource at destination
> to overwrite - COPY should preserve bindings, = i.e. should COPY yield
> 1) or 2) (see below):
> 1)
>       = |u1     --COPY-->    |u2
>       = C            = ;        C'
>     a/  = \b           &nbs= p;   a/  \b
>     C1  = C2           &nbs= p;   Ca  Cb
>     x\  = /y           &nbs= p;  x|    |y
>       = R            = ;      Rx  Ry
> 2)
>       = |u1     --COPY-->    |u2
>       = C            = ;        C'
>     a/  = \b           &nbs= p;   a/  \b
>     C1  = C2           &nbs= p;   Ca  Cb
>     x\  = /y           &nbs= p;   x\  /y
>       = R            = ;        R'
> Most of you voted for 2).
> Now, assuming there *were* resources at = destination to overwrite -
> take diagram 1) for visualization, where C', = Ca, Cb, Rx, Ry all
> existed beforehand - I assume that COPY = u1->u2 would result in Rx
> and Ry both being updated with content + = dead-properties from R.
> And, again using diagram 1) and assuming all = shown resources existed
> beforehand, what happens if we do the COPY the = other way round, i.e.
> COPY u2->u1? The Binding spec states in = section 2.3, last paragraph:
> "If a COPY causes one or more existing = resources to be updated, the
> bindings to those resources MUST be unaffected = by the COPY."
> Is it then correct, that while copying the = C'-tree over the C-tree,
> resource R is first updated by Rx and then = again by Ry (or the other
> way round)? That is, one of Rx or Ry = "wins" in updating R? Hm???
> Regards,
> Peter

------_=_NextPart_001_01C368A5.6A233290--