From w3c-dist-auth-request@w3.org  Mon Mar  1 03:59:22 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03446
	for <webdav-archive@lists.ietf.org>; Mon, 1 Mar 2004 03:59:22 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 75FF4A07D2; Mon,  1 Mar 2004 03:59:22 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 97199A07D2
	for <w3c-dist-auth@listhub.w3.org>; Mon,  1 Mar 2004 03:59:18 -0500 (EST)
Received: by dr-nick.w3.org (Postfix)
	id A17CD3F4F9C; Mon,  1 Mar 2004 03:59:18 -0500 (EST)
Delivered-To: w3c-dist-auth@w3.org
Received: from mail.gmx.net (pop.gmx.de [213.165.64.20])
	by dr-nick.w3.org (Postfix) with SMTP id 352133F4F8B
	for <w3c-dist-auth@w3.org>; Mon,  1 Mar 2004 03:59:18 -0500 (EST)
Received: (qmail 2937 invoked by uid 65534); 1 Mar 2004 08:59:14 -0000
Received: from pD950C384.dip.t-dialin.net (EHLO gmx.de) (217.80.195.132)
  by mail.gmx.net (mp009) with SMTP; 01 Mar 2004 09:59:14 +0100
X-Authenticated: #1915285
Message-ID: <4042FB49.8030902@gmx.de>
Date: Mon, 01 Mar 2004 09:58:49 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Reminder: WebDAV WG meeting during 59th IETF on Tuesday, 4am UTC
X-Archived-At: http://www.w3.org/mid/4042FB49.8030902@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8317
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040301085922.75FF4A07D2@frink.w3.org>
Resent-Date: Mon,  1 Mar 2004 03:59:22 -0500 (EST)
Content-Transfer-Encoding: 7bit


Reminder:

the WebDAV working group meeting during the 59th IETF in Seoul takes 
place on Tuesday, 2004-03-02T13:00+09:00 (this is 2004-03-02T04:00 UTC). 
The agenda is available at <http://ietf.org/ietf/04mar/webdav.txt> 
(pasted-in below), instructions about XMPP-based text conferencing can 
be found at <http://xmpp.org/ietf-chat.html>.

See you online,

Julian

-

TUESDAY, March 2 at 1300-1400
==============================

CHAIRS:	Jim Whitehead <ejw@cse.ucsc.edu>
	Lisa Dusseault <lisa@xythos.com>

AGENDA:

5 min: agenda bashing
5 min: ACL and ordered collections status (RFC3648)
30 min: current WG charter, milestones, goals
         - draft standard progress -> bind/locking issues
         - property registry
         - binding
         - redirect references
10 min: current off-charter work
         - quota
         - property data typing
         - DASL

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



From w3c-dist-auth-request@w3.org  Tue Mar  2 00:11:21 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02061
	for <webdav-archive@lists.ietf.org>; Tue, 2 Mar 2004 00:11:21 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id CF3C7A06A7; Tue,  2 Mar 2004 00:11:21 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 4EDB5A06A7
	for <w3c-dist-auth@listhub.w3.org>; Tue,  2 Mar 2004 00:11:19 -0500 (EST)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1Ay2Bb-00017D-4R
	for w3c-dist-auth@w3.org; Tue, 02 Mar 2004 00:11:19 -0500
Received: (qmail 26888 invoked by uid 65534); 2 Mar 2004 05:10:44 -0000
Received: from pD950C386.dip.t-dialin.net (EHLO gmx.de) (217.80.195.134)
  by mail.gmx.net (mp006) with SMTP; 02 Mar 2004 06:10:44 +0100
X-Authenticated: #1915285
Message-ID: <40441740.9010605@gmx.de>
Date: Tue, 02 Mar 2004 06:10:24 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <4042FB49.8030902@gmx.de>
In-Reply-To: <4042FB49.8030902@gmx.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Status of BIND, was: Reminder: WebDAV WG meeting during 59th IETF  on Tuesday, 4am UTC
X-Archived-At: http://www.w3.org/mid/40441740.9010605@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8318
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040302051121.CF3C7A06A7@frink.w3.org>
Resent-Date: Tue,  2 Mar 2004 00:11:21 -0500 (EST)
Content-Transfer-Encoding: 7bit


Hi,

online logs for the meeting just finished are here:

<http://www.xmpp.org/ietf-logs/webdav@ietf.xmpp.org/2004-03-01.html>


There was some confusion about currently open issues with the BIND spec. 
The current issues list is here:

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html>

(and contains only one open issue regarding how to marshall bind loop 
error information).

The plan clearly is to resolve this issue, submit a new draft and then 
to last-call the spec. If people still feel that there are other issues 
with the document, *please* raise them *here*.

Regards, Julian

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



From w3c-dist-auth-request@w3.org  Sat Mar  6 15:12:26 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02770
	for <webdav-archive@lists.ietf.org>; Sat, 6 Mar 2004 15:12:25 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 14B57A08C2; Sat,  6 Mar 2004 15:12:27 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id CFEEDA0986
	for <w3c-dist-auth@listhub.w3.org>; Sat,  6 Mar 2004 15:12:21 -0500 (EST)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1Azi9l-0003rt-Hm
	for w3c-dist-auth@w3.org; Sat, 06 Mar 2004 15:12:21 -0500
Received: (qmail 28447 invoked by uid 65534); 6 Mar 2004 20:11:41 -0000
Received: from p3EE24735.dip.t-dialin.net (EHLO gmx.de) (62.226.71.53)
  by mail.gmx.net (mp009) with SMTP; 06 Mar 2004 21:11:41 +0100
X-Authenticated: #1915285
Message-ID: <404A305C.7010805@gmx.de>
Date: Sat, 06 Mar 2004 21:11:08 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Resolving BIND issue: 5.1_506_STATUS_STREAMING, other open BIND issues?
X-Archived-At: http://www.w3.org/mid/404A305C.7010805@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8319
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040306201227.14B57A08C2@frink.w3.org>
Resent-Date: Sat,  6 Mar 2004 15:12:27 -0500 (EST)
Content-Transfer-Encoding: 7bit


Hi,

to resolve the only remaining open (recorded) issue with the BIND spec 
(issues list: [1], actual issue: [2]), we (Geoff and I) propose to 
simply allow the 506 error code to appear within the multistatus 
element. Note that there doesn't seem to be an implementable alternative 
short of either forbidding bind loops or servers streaming multistatus 
reponses upon Depth:infinity (the revised section is attached below).

The only other issue I'm sort-of aware of is Lisa Duseault's concern 
about locking semantics when multiple bindings exist to a locked 
resource, voiced during the Seoul meeting (transcript at [3]).

IMHO this was dicussed here before, and the answer simply is that these 
concerns are invalid. A WebDAV lock both locks the resource (directly) 
and protects it's URI (indirectly). Given two bindings "a" and "b" to 
the same resource, you can't use "b" to modify it after it has been 
locked through "a" (because it's the resource that is locked). However 
you *may* DELETE or MOVE "b" (because that binding is not protected by 
the lock requested on "a").

This is the locking behaviour described in RFC2518, and clarified im 
GULP [4].

Note that multiple bindings to the same resource can exist independantly 
of the BIND spec (for instance as result of DeltaV operations). All the 
BIND spec adds is

- clarifying discovery of bindings
- clarify behaviour of bindings in face of namespace operations, incl 
error handling
- adding explicit operations to create new bindings

As the question seems to be re-raised every few months, I'll now add it 
(as "resolved") to the document's issues list.


Regards, Julian


[1]
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html>
[2] 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.5.1_506_STATUS_STREAMING>
[3]
<http://www.xmpp.org/ietf-logs/webdav@ietf.xmpp.org/2004-03-01.html>
[4]
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0001.html>

- Revised section:

7. Additional Status Codes

7.1 208 Already Reported

    The 208 (Already Reported) status code can be used inside a
    DAV:propstat response element to avoid enumerating the internal
    members of multiple bindings to the same collection repeatedly.  For
    each binding to a collection inside the request's scope, only one
    will be reported with a 200 status, while subsequent DAV:response
    elements for all other bindings will use the 208 status, and no
    DAV:response elements for their descendants are included.

    Note that the 208 status will only occur for "Depth: infinity"
    requests, and that it is of particular importance when the multiple
    collection bindings cause a bind loop as discussed in Section 2.2.

    A client can request the DAV:resourceid property in a PROPFIND
    request to guarantee that they can accurately reconstruct the binding
    structure of a collection with multiple bindings to a single
    resource.

    For backward compatibility with clients not aware of the 208 status
    code appearing in multistatus response bodies, it SHOULD NOT be used
    unless the client has signalled support for this specification using
    the "DAV" request header (see Section 8.2). Instead, a 506 status
    should be returned when a binding loop is discovered. This allows the
    server to return the 506 as the top level return status, if it
    discovers it before it started the response, or in the middle of a
    multistatus, if it discovers it in the middle of streaming out a
    multistatus response.

7.1.1 Example: PROPFIND by bind-aware client

    For example, consider a PROPFIND request on /Coll (bound to
    collection C), where the members of  /Coll are /Coll/Foo (bound to
    resource R) and /Coll/Bar (bound to collection C).

    >> Request:

    PROPFIND /Coll/ HTTP/1.1
    Host: www.example.com
    Depth: infinity
    DAV: bind
    Content-Type: text/xml; charset="utf-8"
    Content-Length: xxx

    <?xml version="1.0" encoding="utf-8" ?>
    <D:propfind xmlns:D="DAV:">
       <D:prop> <D:displayname/> </D:prop>
    </D:propfind>

    >> Response:

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

    <?xml version="1.0" encoding="utf-8" ?>
    <D:multistatus xmlns:D="DAV:">
       <D:response>
          <D:href>http://www.example.com/Coll/</D:href>
          <D:propstat>
             <D:prop>
                <D:displayname>Loop Demo</D:displayname>
             </D:prop>
             <D:status>HTTP/1.1 200 OK</D:status>
          </D:propstat>
       </D:response>
       <D:response>
          <D:href>http://www.example.com/Coll/Foo</D:href>
          <D:propstat>
             <D:prop>
                <D:displayname>Bird Inventory</D:displayname>
             </D:prop>
             <D:status>HTTP/1.1 200 OK</D:status>
          </D:propstat>
       </D:response>
       <D:response>
          <D:href>http://www.example.com/Coll/Bar</D:href>
          <D:propstat>
             <D:prop>
                <D:displayname>Loop Demo</D:displayname>
             </D:prop>
             <D:status>HTTP/1.1 208 Already Reported</D:status>
          </D:propstat>
       </D:response>
    </D:multistatus>


7.1.2 Example: PROPFIND by non-bind-aware client

    In this example, the client isn't aware of the 208 status code
    introduced by this specification.  As the "Depth: infinity" PROPFIND
    request would cause a loop condition, the whole request is rejected
    with a 506 status.

    >> Request:

    PROPFIND /Coll/ HTTP/1.1
    Host: www.example.com
    Depth: infinity
    Content-Type: text/xml; charset="utf-8"
    Content-Length: xxx

    <?xml version="1.0" encoding="utf-8" ?>
    <D:propfind xmlns:D="DAV:">
       <D:prop> <D:displayname/> </D:prop>
    </D:propfind>

    >> Response:

    HTTP/1.1 506 Loop Detected


7.2 506 Loop Detected

    The 506 (Loop Detected) status code indicates that the server
    terminated an operation because it encountered an infinite loop while
    processing a request with "Depth: infinity".   This status indicates
    that the entire operation failed.





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



From w3c-dist-auth-request@w3.org  Mon Mar  8 05:45:52 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23970
	for <webdav-archive@lists.ietf.org>; Mon, 8 Mar 2004 05:45:51 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 1355BA0805; Mon,  8 Mar 2004 05:45:53 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 650BCA086C
	for <w3c-dist-auth@listhub.w3.org>; Mon,  8 Mar 2004 05:45:51 -0500 (EST)
Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B0IGd-0003ib-2J
	for w3c-dist-auth@w3.org; Mon, 08 Mar 2004 05:45:51 -0500
Received: (qmail 1270 invoked by uid 65534); 8 Mar 2004 10:45:18 -0000
Received: from p50824D95.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.77.149)
  by mail.gmx.net (mp004) with SMTP; 08 Mar 2004 11:45:18 +0100
X-Authenticated: #1915285
Message-ID: <404C4EBD.6030200@gmx.de>
Date: Mon, 08 Mar 2004 11:45:17 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: XML/HTML versions of RFC2518 updated
X-Archived-At: http://www.w3.org/mid/404C4EBD.6030200@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8320
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040308104553.1355BA0805@frink.w3.org>
Resent-Date: Mon,  8 Mar 2004 05:45:53 -0500 (EST)
Content-Transfer-Encoding: 7bit


Hi,

I have updated the XML (RFC2629) [1] and HTML versions [2] of RFC2518.

Changes:

- fix broken nesting of last appendix
- add intra-document links to sections
- update references

Regards, Julian

[1] <http://greenbytes.de/tech/webdav/rfc2518.html>
[2] <http://greenbytes.de/tech/webdav/rfc2518.xml>


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



From w3c-dist-auth-request@w3.org  Mon Mar  8 11:44:48 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12895
	for <webdav-archive@lists.ietf.org>; Mon, 8 Mar 2004 11:44:47 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A72F2A0BF2; Mon,  8 Mar 2004 11:44:49 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 66AA5A1222
	for <w3c-dist-auth@listhub.w3.org>; Mon,  8 Mar 2004 11:44:47 -0500 (EST)
Received: from e2.ny.us.ibm.com ([32.97.182.102])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B0Nrz-0003v0-9F
	for w3c-dist-auth@w3.org; Mon, 08 Mar 2004 11:44:47 -0500
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i28GiG7b177592
	for <w3c-dist-auth@w3.org>; Mon, 8 Mar 2004 11:44:16 -0500
Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i28GiQdB077940
	for <w3c-dist-auth@w3.org>; Mon, 8 Mar 2004 11:44:27 -0500
In-Reply-To: <404A305C.7010805@gmx.de>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF7E88CAFD.45BECCA8-ON85256E51.005B68CC-85256E51.005BF11F@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Mon, 8 Mar 2004 11:44:07 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at
 03/08/2004 11:44:15,
	Serialize complete at 03/08/2004 11:44:15
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: Resolving other open BIND issues?
X-Archived-At: http://www.w3.org/mid/OF7E88CAFD.45BECCA8-ON85256E51.005B68CC-85256E51.005BF11F@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8321
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040308164449.A72F2A0BF2@frink.w3.org>
Resent-Date: Mon,  8 Mar 2004 11:44:49 -0500 (EST)


I agree that this is the appropriate resolution of this issue.

Cheers,
Geoff

Julian wrote on 03/06/2004 03:11:08 PM:
> ...
> The only other issue I'm sort-of aware of is Lisa Duseault's concern 
> about locking semantics when multiple bindings exist to a locked 
> resource, voiced during the Seoul meeting (transcript at [3]).
> 
> IMHO this was dicussed here before, and the answer simply is that these 
> concerns are invalid. A WebDAV lock both locks the resource (directly) 
> and protects it's URI (indirectly). Given two bindings "a" and "b" to 
> the same resource, you can't use "b" to modify it after it has been 
> locked through "a" (because it's the resource that is locked). However 
> you *may* DELETE or MOVE "b" (because that binding is not protected by 
> the lock requested on "a").
> 
> This is the locking behaviour described in RFC2518, and clarified im 
> GULP [4].
> 
> Note that multiple bindings to the same resource can exist independantly 

> of the BIND spec (for instance as result of DeltaV operations). All the 
> BIND spec adds is
> 
> - clarifying discovery of bindings
> - clarify behaviour of bindings in face of namespace operations, incl 
> error handling
> - adding explicit operations to create new bindings
> 
> As the question seems to be re-raised every few months, I'll now add it 
> (as "resolved") to the document's issues list.



From w3c-dist-auth-request@w3.org  Tue Mar  9 05:19:51 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18766
	for <webdav-archive@lists.ietf.org>; Tue, 9 Mar 2004 05:19:51 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 7D3F4A0F2B; Tue,  9 Mar 2004 05:19:51 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 6A6C2A0F2B
	for <w3c-dist-auth@listhub.w3.org>; Tue,  9 Mar 2004 05:19:48 -0500 (EST)
Received: from 212-59.84.64.master-link.com ([64.84.59.212] helo=NSNOVPS00411.nacio.xythos.com)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B0eKy-0005yS-8H
	for w3c-dist-auth@w3c.org; Tue, 09 Mar 2004 05:19:48 -0500
Received: from lisalap ([203.236.110.114]) by NSNOVPS00411.nacio.xythos.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 9 Mar 2004 02:19:15 -0800
From: "Lisa Dusseault" <lisa@xythos.com>
To: <minutes@ietf.org>
Cc: "Jim Whitehead" <ejw@cse.ucsc.edu>, "Webdav WG" <w3c-dist-auth@w3c.org>
Date: Tue, 9 Mar 2004 02:19:36 -0800
Message-ID: <000701c405c0$088c2b00$726eeccb@lisalap>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-OriginalArrivalTime: 09 Mar 2004 10:19:16.0342 (UTC) FILETIME=[F9F0D960:01C405BF]
Subject: WebDAV WG meeting minutes
X-Archived-At: http://www.w3.org/mid/000701c405c0$088c2b00$726eeccb@lisalap
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8322
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040309101951.7D3F4A0F2B@frink.w3.org>
Resent-Date: Tue,  9 Mar 2004 05:19:51 -0500 (EST)
Content-Transfer-Encoding: quoted-printable



Presentation: =
<http://www.sharemation.com/~milele/public/dav/presentations/webdav-wg-ie=
tf59.ppt>=20


Agenda bashing: No changes; Ted volunteered to scribe in chat room (also =
to be used for minutes)

WebDAV's been extant 7 years and rechartered once.  Lisa proposed that =
we should try to declare "partial success". =20
We completed these goals: RFC2518, ACL, ordered collections (RFC3648).
Here's the milestones we haven't finished, and where they're at:

Property registry: no draft, no volunteers --> this obviously wasn't =
needed after all and should be scratched.

Binding: Major issues -- possible incompatible changes with WebDAV, =
causing existing clients to see completely unexpected behavior.  At =
least issues with spec ambiguity.

Redirect: No major issues -- but no recent activity.  OTOH, there may =
not be many implementors.  Perhaps we can last call and require a =
minimum # of reviews.

ACL goals document: we can submit the last draft (many years expired) as =
Informational if desired.

DRAFT standard status(2518bis) -- We've collectively put a lot of work =
into that draft, feeding the results of those interop events into the =
draft.  However, now it's stalled, as new ideas have been raised =
recently about the whole approach.  Not sure working group has the =
energy to finish (and to keep changes to a minimum to meet DRAFT =
standard requirements).

Responses to this summation showed disagreement on whether there are =
major issues with 'bindings'.  Julian Reschke says there are no issues.  =
Can clients create a lock on a binding, and have the expectation met =
that he underlying document cannot be changed by other clients?  Ted and =
Lisa believe the draft says that the underlying document may change (and =
that that would be a serious incompatible change).  Julian says that the =
underlying document cannot change. =20

Other work is going on around WebDAV but as individual submissions: =
DASL, property data types, quota, http patch
DASL could go to proposed standard if it's in the form that's already =
been implemented by several separate groups.  Otherwise, it could go to =
experimental, etc.  =20

In general progress in this WG is hampered by limited participation, =
review, and consensus-building.  Chairs need to update the charter to =
reflect the things that actually will be done, and get the working group =
to agree whether it can resolve something that is a milestone.  Note =
that changing the charter requires new review by the IETF community.

Other suggestions (from Larry, Ted, Patrik in particular): suggest =
bugging people may be necessary--not waiting for people to respond, but =
going out and getting them involved.  Can do last call on some of our =
remaining docs, but require N independent reviews to be posted in order =
to successfully move on.  Without those N reviews -- e.g. 3 independent =
reviews -- Ted says it would no longer be considered a WG item (and it's =
up to the chairs to determine if the participation of the WG is =
sufficient to call consensus and come to completion).  The reviews would =
also indicate whether another cycle is needed on the document.

Complete Jabber room minutes are also available -- this is just a =
summation, as suggested in minute-writing guidelines.

Lisa



From w3c-dist-auth-request@w3.org  Tue Mar  9 08:25:26 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25976
	for <webdav-archive@lists.ietf.org>; Tue, 9 Mar 2004 08:25:26 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 1721CA15A2; Tue,  9 Mar 2004 08:25:23 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id C3705A15A5
	for <w3c-dist-auth@listhub.w3.org>; Tue,  9 Mar 2004 08:25:17 -0500 (EST)
Received: from e1.ny.us.ibm.com ([32.97.182.101])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B0hET-0003El-Sa
	for w3c-dist-auth@w3c.org; Tue, 09 Mar 2004 08:25:17 -0500
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i29DOlve332856
	for <w3c-dist-auth@w3c.org>; Tue, 9 Mar 2004 08:24:47 -0500
Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i29DOwJG104626
	for <w3c-dist-auth@w3c.org>; Tue, 9 Mar 2004 08:24:58 -0500
In-Reply-To: <000701c405c0$088c2b00$726eeccb@lisalap>
To: "Webdav WG" <w3c-dist-auth@w3c.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF6489724D.77211D65-ON85256E52.0048348E-85256E52.00499D6F@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Tue, 9 Mar 2004 08:24:40 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at
 03/09/2004 08:24:45,
	Serialize complete at 03/09/2004 08:24:45
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: WebDAV WG meeting minutes
X-Archived-At: http://www.w3.org/mid/OF6489724D.77211D65-ON85256E52.0048348E-85256E52.00499D6F@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8323
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040309132523.1721CA15A2@frink.w3.org>
Resent-Date: Tue,  9 Mar 2004 08:25:23 -0500 (EST)


Julian is correct.  Nothing in the binding draft allows a locked
resource to be modified by a client that does not hold the token
for that locked resource.  If anyone believes otherwise, 
I would appreciate it if they could raise the issue on the mailing
list by identifying the section of the draft that they believe 
makes this statement, so we can add whatever wording is necessary
to avoid anyone else misunderstanding the spec in this way.

Note: we carefully track all issues with the binding spec, but
(since none of us have reliable telepathic powers :-), we can only
track and respond to issues that have been explicitly raised on the
mailing list.

Cheers,
Geoff



Lisa wrote on 03/09/2004 05:19:36 AM:

> Binding: Major issues -- possible incompatible changes with WebDAV, 
> causing existing clients to see completely unexpected behavior.  At 
> least issues with spec ambiguity.
> 
> Responses to this summation showed disagreement on whether there are
> major issues with 'bindings'.  Julian Reschke says there are no 
> issues.  Can clients create a lock on a binding, and have the 
> expectation met that he underlying document cannot be changed by 
> other clients?  Ted and Lisa believe the draft says that the 
> underlying document may change (and that that would be a serious 
> incompatible change).  Julian says that the underlying document 
> cannot change. 




From w3c-dist-auth-request@w3.org  Mon Mar 15 15:56:39 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24444
	for <webdav-archive@lists.ietf.org>; Mon, 15 Mar 2004 15:56:39 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 2F020A0600; Mon, 15 Mar 2004 15:56:39 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id D3692A067B
	for <w3c-dist-auth@listhub.w3.org>; Mon, 15 Mar 2004 15:56:35 -0500 (EST)
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B2z8V-00018z-D4
	for w3c-dist-auth@w3.org; Mon, 15 Mar 2004 15:56:35 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24427;
	Mon, 15 Mar 2004 15:56:31 -0500 (EST)
Message-Id: <200403152056.PAA24427@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, 15 Mar 2004 15:56:31 -0500
Subject: I-D ACTION:draft-ietf-webdav-bind-04.txt
X-Archived-At: http://www.w3.org/mid/200403152056.PAA24427@ietf.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8324
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040315205639.2F020A0600@frink.w3.org>
Resent-Date: Mon, 15 Mar 2004 15:56:39 -0500 (EST)


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF.

	Title		: Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)
	Author(s)	: G. Clemm, J. Crawford
	Filename	: draft-ietf-webdav-bind-04.txt
	Pages		: 34
	Date		: 2004-3-15
	
This specification defines bindings, and the BIND method for creating 
multiple bindings to the same resource.  Creating a new binding to a 
resource causes at least one new URI to be mapped to that resource.  
Servers are required to insure the integrity of any bindings that they 
allow to be created.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-webdav-bind-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-webdav-bind-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2004-3-15142910.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID:	<2004-3-15142910.I-D@ietf.org>

--OtherAccess--

--NextPart--




From w3c-dist-auth-request@w3.org  Tue Mar 16 02:57:24 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16269
	for <webdav-archive@lists.ietf.org>; Tue, 16 Mar 2004 02:57:24 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id C108FA05AC; Tue, 16 Mar 2004 02:56:19 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 0FEA2A05AC
	for <w3c-dist-auth@listhub.w3.org>; Tue, 16 Mar 2004 02:56:18 -0500 (EST)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B39Qv-0001iU-LO
	for w3c-dist-auth@w3.org; Tue, 16 Mar 2004 02:56:17 -0500
Received: (qmail 27957 invoked by uid 65534); 16 Mar 2004 07:55:42 -0000
Received: from pD950C388.dip.t-dialin.net (EHLO gmx.de) (217.80.195.136)
  by mail.gmx.net (mp001) with SMTP; 16 Mar 2004 08:55:42 +0100
X-Authenticated: #1915285
Message-ID: <4056B2E8.6060506@gmx.de>
Date: Tue, 16 Mar 2004 08:55:20 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <200403152056.PAA24427@ietf.org>
In-Reply-To: <200403152056.PAA24427@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: I-D ACTION:draft-ietf-webdav-bind-04.txt
X-Archived-At: http://www.w3.org/mid/4056B2E8.6060506@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8325
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040316075619.C108FA05AC@frink.w3.org>
Resent-Date: Tue, 16 Mar 2004 02:56:19 -0500 (EST)
Content-Transfer-Encoding: 7bit


Hi folks,

a new draft for the BIND spec has been submitted. It resolves the only 
registered open issue (bind loop error marshalling) as discussed 
previously on this mailing list.

HTML version for this draft: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-04.html>

The updated issues list can be found here: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html>.

Regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Mar 17 13:30:12 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28042
	for <webdav-archive@lists.ietf.org>; Wed, 17 Mar 2004 13:30:06 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 72E60A0692; Wed, 17 Mar 2004 13:30:06 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 80F9CA09F0
	for <w3c-dist-auth@listhub.w3.org>; Wed, 17 Mar 2004 13:30:03 -0500 (EST)
Received: from imo-m22.mx.aol.com ([64.12.137.3])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B3fmj-0004hC-F2
	for w3c-dist-auth@w3.org; Wed, 17 Mar 2004 13:28:57 -0500
Received: from FengAndy@aol.com
	by imo-m22.mx.aol.com (mail_out_v37_r1.2.) id r.15f.2cff17d1 (18555)
	 for <w3c-dist-auth@w3.org>; Wed, 17 Mar 2004 13:28:25 -0500 (EST)
From: FengAndy@aol.com
Message-ID: <15f.2cff17d1.2d89f2c8@aol.com>
Date: Wed, 17 Mar 2004 13:28:24 EST
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-----------------------------1079548104"
X-Mailer: 9.0 for Windows sub 4042
Subject: FengAndy@aol.com
X-Archived-At: http://www.w3.org/mid/15f.2cff17d1.2d89f2c8@aol.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8326
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040317183006.72E60A0692@frink.w3.org>
Resent-Date: Wed, 17 Mar 2004 13:30:06 -0500 (EST)



-------------------------------1079548104
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Folks, 
Have anyone tried to enable thumbnails via WebDAV clients? Apple's iDisk  
enables such features. All other WebDAV clients don't seem to have such support.  
For example, in Windows, you could not select a WebFolder to have a  
thumbnail view.
Any suggestion? Thanks in advance.
Andy Feng 
Chief Architect, AOL
_AOL Storage &  Personalization Architecture_ 
(http://blues.netscape.com/users/afeng/publish/) 

-------------------------------1079548104
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3DUS-ASCII">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY id=3Drole_body style=3D"FONT-SIZE: 10pt; COLOR: #000000; FONT-FAMILY:=20=
Arial"=20
bottomMargin=3D7 leftMargin=3D7 topMargin=3D7 rightMargin=3D7><FONT id=3Drol=
e_document=20
face=3DArial color=3D#000000 size=3D2>
<DIV>Folks, </DIV>
<DIV>&nbsp;</DIV>
<DIV>Have anyone tried to enable thumbnails via WebDAV clients? Apple's iDis=
k=20
enables such features. All other WebDAV clients don't seem to have such supp=
ort.=20
For example, in Windows, you could not select a&nbsp;WebFolder to have a=20
thumbnail view.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Any suggestion? Thanks in advance.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT lang=3D0 face=3DArial color=3D#808000 size=3D2 FAMILY=3D"SANSSERI=
F"=20
PTSIZE=3D"10"><I>Andy Feng </I></FONT></DIV>
<DIV><FONT lang=3D0 face=3DArial color=3D#808000 size=3D2 FAMILY=3D"SANSSERI=
F"=20
PTSIZE=3D"10"><I>Chief Architect, AOL<BR><A=20
href=3D"http://blues.netscape.com/users/afeng/publish/">AOL Storage &amp;=20
Personalization Architecture</A></I></FONT></DIV></FONT></BODY></HTML>

-------------------------------1079548104--



From w3c-dist-auth-request@w3.org  Wed Mar 17 14:24:26 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00845
	for <webdav-archive@lists.ietf.org>; Wed, 17 Mar 2004 14:24:25 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 68083A111A; Wed, 17 Mar 2004 14:24:24 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id A40BEA111A
	for <w3c-dist-auth@listhub.w3.org>; Wed, 17 Mar 2004 14:24:22 -0500 (EST)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B3geL-0000mY-1Y
	for w3c-dist-auth@w3.org; Wed, 17 Mar 2004 14:24:21 -0500
Received: (qmail 13614 invoked by uid 65534); 17 Mar 2004 19:23:46 -0000
Received: from pD950C39E.dip.t-dialin.net (EHLO gmx.de) (217.80.195.158)
  by mail.gmx.net (mp022) with SMTP; 17 Mar 2004 20:23:46 +0100
X-Authenticated: #1915285
Message-ID: <4058A5A8.2050202@gmx.de>
Date: Wed, 17 Mar 2004 20:23:20 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: FengAndy@aol.com
Cc: w3c-dist-auth@w3.org
References: <15f.2cff17d1.2d89f2c8@aol.com>
In-Reply-To: <15f.2cff17d1.2d89f2c8@aol.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: FengAndy@aol.com
X-Archived-At: http://www.w3.org/mid/4058A5A8.2050202@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8327
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040317192424.68083A111A@frink.w3.org>
Resent-Date: Wed, 17 Mar 2004 14:24:24 -0500 (EST)
Content-Transfer-Encoding: 7bit


FengAndy@aol.com wrote:
> Folks,
>  
> Have anyone tried to enable thumbnails via WebDAV clients? Apple's iDisk 
> enables such features. All other WebDAV clients don't seem to have such 
> support. For example, in Windows, you could not select a WebFolder to 
> have a thumbnail view.
>  
> Any suggestion? Thanks in advance.

There's no specific support for that in WebDAV. Do you know what Apple's 
iDisk is doing here?

Regards, Julian


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



From w3c-dist-auth-request@w3.org  Wed Mar 17 14:31:49 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01420
	for <webdav-archive@lists.ietf.org>; Wed, 17 Mar 2004 14:31:44 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id ADA31A1438; Wed, 17 Mar 2004 14:31:38 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 34909A143C
	for <w3c-dist-auth@listhub.w3.org>; Wed, 17 Mar 2004 14:30:39 -0500 (EST)
Received: from imo-m24.mx.aol.com ([64.12.137.5])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B3gjq-00024s-Up
	for w3c-dist-auth@w3.org; Wed, 17 Mar 2004 14:30:03 -0500
Received: from FengAndy@aol.com
	by imo-m24.mx.aol.com (mail_out_v37_r1.2.) id i.60.3c499120 (18555);
	Wed, 17 Mar 2004 14:29:29 -0500 (EST)
From: FengAndy@aol.com
Message-ID: <60.3c499120.2d8a0118@aol.com>
Date: Wed, 17 Mar 2004 14:29:28 EST
To: julian.reschke@gmx.de
Cc: w3c-dist-auth@w3.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-----------------------------1079551768"
X-Mailer: 9.0 for Windows sub 4042
Subject: WebDAV and Thumbnail
X-Archived-At: http://www.w3.org/mid/60.3c499120.2d8a0118@aol.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8328
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040317193138.ADA31A1438@frink.w3.org>
Resent-Date: Wed, 17 Mar 2004 14:31:38 -0500 (EST)



-------------------------------1079551768
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

As far I could tell, iDisk is sending some "HTTP GET" request for thumbnail  
data.
In a message dated 3/17/2004 11:24:00 AM Pacific Standard Time,  
julian.reschke@gmx.de writes:

FengAndy@aol.com wrote:
> Folks,
>  
> Have  anyone tried to enable thumbnails via WebDAV clients? Apple's iDisk 
>  enables such features. All other WebDAV clients don't seem to have such  
> support. For example, in Windows, you could not select a WebFolder to  
> have a thumbnail view.
>  
> Any suggestion? Thanks  in advance.

There's no specific support for that in WebDAV. Do you know  what Apple's 
iDisk is doing here?

Regards,  Julian


-------------------------------1079551768
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3DUS-ASCII">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY id=3Drole_body style=3D"FONT-SIZE: 10pt; COLOR: #000000; FONT-FAMILY:=20=
Arial"=20
bottomMargin=3D7 leftMargin=3D7 topMargin=3D7 rightMargin=3D7><FONT id=3Drol=
e_document=20
face=3DArial color=3D#000000 size=3D2>
<DIV>
<DIV>
<DIV>As far I could tell, iDisk is sending some "HTTP GET" request for thumb=
nail=20
data.</DIV>
<DIV>&nbsp;</DIV>
<DIV>In a message dated 3/17/2004 11:24:00 AM Pacific Standard Time,=20
julian.reschke@gmx.de writes:</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: blue 2px solid"><=
FONT=20
  style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20
  size=3D2>FengAndy@aol.com wrote:<BR>&gt; Folks,<BR>&gt;&nbsp; <BR>&gt; Hav=
e=20
  anyone tried to enable thumbnails via WebDAV clients? Apple's iDisk <BR>&g=
t;=20
  enables such features. All other WebDAV clients don't seem to have such=20
  <BR>&gt; support. For example, in Windows, you could not select a WebFolde=
r to=20
  <BR>&gt; have a thumbnail view.<BR>&gt;&nbsp; <BR>&gt; Any suggestion? Tha=
nks=20
  in advance.<BR><BR>There's no specific support for that in WebDAV. Do you=20=
know=20
  what Apple's <BR>iDisk is doing here?<BR><BR>Regards,=20
Julian<BR></FONT></BLOCKQUOTE></DIV></DIV></FONT></BODY></HTML>

-------------------------------1079551768--



From w3c-dist-auth-request@w3.org  Wed Mar 17 14:41:50 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01961
	for <webdav-archive@lists.ietf.org>; Wed, 17 Mar 2004 14:41:50 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 8D87BA05D0; Wed, 17 Mar 2004 14:41:47 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id B1570A05D0
	for <w3c-dist-auth@listhub.w3.org>; Wed, 17 Mar 2004 14:41:45 -0500 (EST)
Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B3gvB-0005NO-2r
	for w3c-dist-auth@w3.org; Wed, 17 Mar 2004 14:41:45 -0500
Received: (qmail 19644 invoked by uid 65534); 17 Mar 2004 19:41:11 -0000
Received: from pD950C39E.dip.t-dialin.net (EHLO gmx.de) (217.80.195.158)
  by mail.gmx.net (mp005) with SMTP; 17 Mar 2004 20:41:11 +0100
X-Authenticated: #1915285
Message-ID: <4058A9C2.1040108@gmx.de>
Date: Wed, 17 Mar 2004 20:40:50 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: FengAndy@aol.com
Cc: w3c-dist-auth@w3.org
References: <60.3c499120.2d8a0118@aol.com>
In-Reply-To: <60.3c499120.2d8a0118@aol.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: WebDAV and Thumbnail
X-Archived-At: http://www.w3.org/mid/4058A9C2.1040108@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8329
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040317194147.8D87BA05D0@frink.w3.org>
Resent-Date: Wed, 17 Mar 2004 14:41:47 -0500 (EST)
Content-Transfer-Encoding: 7bit


FengAndy@aol.com wrote:

> As far I could tell, iDisk is sending some "HTTP GET" request for 
> thumbnail data.

Well, yes. But does it send any special request headers? Is there 
anything special about the URI?

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



From w3c-dist-auth-request@w3.org  Wed Mar 17 16:46:26 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09929
	for <webdav-archive@lists.ietf.org>; Wed, 17 Mar 2004 16:46:25 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 07697A0B6C; Wed, 17 Mar 2004 16:46:27 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 2CF7DA0B0C
	for <w3c-dist-auth@listhub.w3.org>; Wed, 17 Mar 2004 16:46:25 -0500 (EST)
Received: from mail-out4.apple.com ([17.254.13.23])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B3iro-0007EC-Kt
	for w3c-dist-auth@w3.org; Wed, 17 Mar 2004 16:46:24 -0500
Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204])
	by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i2HLmDcx008233
	for <w3c-dist-auth@w3.org>; Wed, 17 Mar 2004 13:48:13 -0800 (PST)
Received: from relay3.apple.com (relay3.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 4.3.6) with ESMTP id <T68657aed6e118064cc7c8@mailgate2.apple.com>;
 Wed, 17 Mar 2004 13:45:53 -0800
Received: from [17.202.43.76] (luthji.apple.com [17.202.43.76])
	by relay3.apple.com (8.12.11/8.12.11) with ESMTP id i2HLjpCS012355;
	Wed, 17 Mar 2004 21:45:52 GMT
In-Reply-To: <4058A5A8.2050202@gmx.de>
References: <15f.2cff17d1.2d89f2c8@aol.com> <4058A5A8.2050202@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <753B2BAA-785C-11D8-816B-000A95DC65E0@apple.com>
Content-Transfer-Encoding: 7bit
Cc: FengAndy@aol.com
From: Jim Luther <luther.j@apple.com>
Date: Wed, 17 Mar 2004 13:45:50 -0800
To: w3c-dist-auth@w3.org
X-Mailer: Apple Mail (2.613)
Subject: Re: FengAndy@aol.com
X-Archived-At: http://www.w3.org/mid/753B2BAA-785C-11D8-816B-000A95DC65E0@apple.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8330
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040317214627.07697A0B6C@frink.w3.org>
Resent-Date: Wed, 17 Mar 2004 16:46:27 -0500 (EST)
Content-Transfer-Encoding: 7bit


On a Macintosh, thumbnails icons for directories are stored in a  
special file inside the directory (Mac OS 8 through 9 and Mac OS X use  
different techniques for that file). Thumbnails icons for files are  
stored in a file's resource fork (the Macintosh file system supports  
two file forks -- See  
<http://developer.apple.com/documentation/mac/Files/Files-14.html>).

To store a file's data fork and the file's resource fork and other  
Macintosh-specific metadata on volume formats (like WebDAV) which don't  
support Macintosh-style resources forks or metadata, the file is stored  
in AppleDouble format (it's funny but the only place I can find the  
AppleDouble documentation isn't on Apple web site -- it's at  
<http://www.lazerware.com/formats/Specs/AppleSingle_AppleDouble.pdf>.  
The AppleDouble formatted file is stored as two files. The data for the  
file is stored in the "AppleDouble Data file" which has the file's  
name. The resource fork and other Macintosh-specific metadata is stored  
in the "AppleDouble Header file" which has the file's name with the  
characters "._" prepended.

So, if you look at a WebDAV server that has files stored by Mac OS X  
clients, you'll probably see files with names beginning with "._" --  
that's where the thumbnail icons (if any) are stored.

If a non-Macintosh client wanted to display those icons, it would be a  
lot of work. That client would have to know how to:

1 - Parse the AppleDouble Header file to get the Macintosh Finder  
information (the metadata which contains a flag indicating the presence  
of a custom thumbnail icon) and the resource fork.

2 - Interpret the resource fork to get to the custom icon resources  
(see  
http://developer.apple.com/documentation/mac/MoreToolbox/MoreToolbox 
-99.html for the resoruce file format).

3 - Display the icon resources (they are bitmaps (see  
http://developer.apple.com/documentation/mac/Toolbox/Toolbox-448.html),  
'icns' resources (see  
http://developer.apple.com/documentation/Carbon/Conceptual/ 
Icon_Service_nd_Utilities/02concepts/chapter_2_section_4.html), or in  
PICT format (see  
http://developer.apple.com/documentation/mac/QuickDraw/QuickDraw 
-458.html) -- they aren't jpeg or gif).

So... a bunch of work just for thumbnails.

- Jim Luther

On Mar 17, 2004, at 11:23 AM, Julian Reschke wrote:

>
> FengAndy@aol.com wrote:
>> Folks,
>>  Have anyone tried to enable thumbnails via WebDAV clients? Apple's  
>> iDisk enables such features. All other WebDAV clients don't seem to  
>> have such support. For example, in Windows, you could not select a  
>> WebFolder to have a thumbnail view.
>>  Any suggestion? Thanks in advance.
>
> There's no specific support for that in WebDAV. Do you know what  
> Apple's iDisk is doing here?
>
> Regards, Julian
>
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Wed Mar 17 17:05:32 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10960
	for <webdav-archive@lists.ietf.org>; Wed, 17 Mar 2004 17:05:32 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id AE67FA070C; Wed, 17 Mar 2004 17:05:33 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id D5034A070C
	for <w3c-dist-auth@listhub.w3.org>; Wed, 17 Mar 2004 17:05:31 -0500 (EST)
Received: from imo-d06.mx.aol.com ([205.188.157.38])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B3jAJ-0003fA-G2
	for w3c-dist-auth@w3.org; Wed, 17 Mar 2004 17:05:31 -0500
Received: from FengAndy@aol.com
	by imo-d06.mx.aol.com (mail_out_v37_r1.2.) id h.b7.3dce7acd (18555);
	Wed, 17 Mar 2004 17:04:53 -0500 (EST)
From: FengAndy@aol.com
Message-ID: <b7.3dce7acd.2d8a2585@aol.com>
Date: Wed, 17 Mar 2004 17:04:53 EST
To: luther.j@apple.com, w3c-dist-auth@w3.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-----------------------------1079561093"
X-Mailer: 9.0 for Windows sub 4042
Subject: Re: FengAndy@aol.com
X-Archived-At: http://www.w3.org/mid/b7.3dce7acd.2d8a2585@aol.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8331
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040317220533.AE67FA070C@frink.w3.org>
Resent-Date: Wed, 17 Mar 2004 17:05:33 -0500 (EST)



-------------------------------1079561093
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Jim, 
I noticed that Windows XP could display the thumbnail for iDisk  stored 
pictures. However, it's not be able to display thumbnails. 
Any explanation?
Andy
In a message dated 3/17/2004 1:46:11 PM Pacific Standard Time,  
luther.j@apple.com writes:

On a  Macintosh, thumbnails icons for directories are stored in a  
special  file inside the directory (Mac OS 8 through 9 and Mac OS X use   
different techniques for that file). Thumbnails icons for files are   
stored in a file's resource fork (the Macintosh file system supports   
two file forks -- See   
<http://developer.apple.com/documentation/mac/Files/Files-14.html>).

To  store a file's data fork and the file's resource fork and other   
Macintosh-specific metadata on volume formats (like WebDAV) which  don't  
support Macintosh-style resources forks or metadata, the file  is stored  
in AppleDouble format (it's funny but the only place I can  find the  
AppleDouble documentation isn't on Apple web site -- it's  at   
<http://www.lazerware.com/formats/Specs/AppleSingle_AppleDouble.pdf>.   
The AppleDouble formatted file is stored as two files. The data for  the  
file is stored in the "AppleDouble Data file" which has the  file's  
name. The resource fork and other Macintosh-specific metadata  isstored  
in the "AppleDouble Header file" which has the file's name  with the  
characters "._" prepended.

So, if you look at a  WebDAV server that has files stored by Mac OS X  
clients, you'll  probably see files with names beginning with "._" --  
that's where  the thumbnail icons (if any) are stored.

If a non-Macintosh client  wanted to display those icons, it would be a  
lot of work. That  client would have to know how to:

1 - Parse the AppleDouble Header file  to get the Macintosh Finder  
information (the metadata which contains  a flag indicating the presence  
of a custom thumbnail icon) and the  resource fork.

2 - Interpret the resource fork to get to the custom  icon resources  
(see   
http://developer.apple.com/documentation/mac/MoreToolbox/MoreToolbox  
-99.html for the resoruce file format).

3 - Display the icon  resources (they are bitmaps (see   
http://developer.apple.com/documentation/mac/Toolbox/Toolbox-448.html),   
'icns' resources (see   
http://developer.apple.com/documentation/arbon/Conceptual/  
Icon_Service_nd_Utilities/02concepts/chapter_2_section_4.html), or  in  
PICT format (see   
http://developer.apple.com/documentation/mac/QuickDraw/QuickDraw  
-458.html) -- they aren't jpeg or gif).

So... a bunch of work just  for thumbnails.

- Jim Luther

On Mar 17, 2004, at 11:23 AM,  Julian Reschke wrote:

>
> FengAndy@aol.com wrote:
>>  Folks,
>>  Have anyone tried to enable thumbnails via WebDAV  clients? Apple's  
>> iDisk enables such features. All other  WebDAV clients don't seem to  
>> have such support. For  example, in Windows, you could not select a  
>> WebFolder to  have a thumbnail view.
>>  Any suggestion? Thanks in  advance.
>
> There's no specific support for that in WebDAV. Do  you know what  
> Apple's iDisk is doing here?
>
>  Regards, Julian
>
>
> -- 
> <green/>bytes GmbH  -- http://www.greenbytes.de --  tel:+492512807760
>


Andy Feng 
_AOL Storage &  Personalization Architecture_ 
(http://blues.netscape.com/users/afeng/publish/) 

-------------------------------1079561093
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3DUS-ASCII">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY id=3Drole_body style=3D"FONT-SIZE: 10pt; COLOR: #000000; FONT-FAMILY:=20=
Arial"=20
bottomMargin=3D7 leftMargin=3D7 topMargin=3D7 rightMargin=3D7><FONT id=3Drol=
e_document=20
face=3DArial color=3D#000000 size=3D2>
<DIV>
<DIV>
<DIV>Jim, </DIV>
<DIV>&nbsp;</DIV>
<DIV>I&nbsp;noticed that Windows XP could&nbsp;display the thumbnail for iDi=
sk=20
stored pictures. However, it's not be able to display thumbnails. </DIV>
<DIV>&nbsp;</DIV>
<DIV>Any explanation?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Andy</DIV>
<DIV>&nbsp;</DIV>
<DIV>In a message dated 3/17/2004 1:46:11 PM Pacific Standard Time,=20
luther.j@apple.com writes:</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: blue 2px solid"><=
FONT=20
  style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size=
=3D2>On a=20
  Macintosh, thumbnails icons for directories are stored in a&nbsp; <BR>spec=
ial=20
  file inside the directory (Mac OS 8 through 9 and Mac OS X use&nbsp;=20
  <BR>different techniques for that file). Thumbnails icons for files are&nb=
sp;=20
  <BR>stored in a file's resource fork (the Macintosh file system supports&n=
bsp;=20
  <BR>two file forks -- See&nbsp;=20
  <BR>&lt;http://developer.apple.com/documentation/mac/Files/Files-14.html&g=
t;).<BR><BR>To=20
  store a file's data fork and the file's resource fork and other&nbsp;=20
  <BR>Macintosh-specific metadata on volume formats (like WebDAV) which=20
  don't&nbsp; <BR>support Macintosh-style resources forks or metadata, the f=
ile=20
  is stored&nbsp; <BR>in AppleDouble format (it's funny but the only place I=
 can=20
  find the&nbsp; <BR>AppleDouble documentation isn't on Apple web site -- it=
's=20
  at&nbsp;=20
  <BR>&lt;http://www.lazerware.com/formats/Specs/AppleSingle_AppleDouble.pdf=
&gt;.&nbsp;=20
  <BR>The AppleDouble formatted file is stored as two files. The data for=20
  the&nbsp; <BR>file is stored in the "AppleDouble Data file" which has the=20
  file's&nbsp; <BR>name. The resource fork and other Macintosh-specific meta=
data=20
  is stored&nbsp; <BR>in the "AppleDouble Header file" which has the file's=20=
name=20
  with the&nbsp; <BR>characters "._" prepended.<BR><BR>So, if you look at a=20
  WebDAV server that has files stored by Mac OS X&nbsp; <BR>clients, you'll=20
  probably see files with names beginning with "._" --&nbsp; <BR>that's wher=
e=20
  the thumbnail icons (if any) are stored.<BR><BR>If a non-Macintosh client=20
  wanted to display those icons, it would be a&nbsp; <BR>lot of work. That=20
  client would have to know how to:<BR><BR>1 - Parse the AppleDouble Header=20=
file=20
  to get the Macintosh Finder&nbsp; <BR>information (the metadata which cont=
ains=20
  a flag indicating the presence&nbsp; <BR>of a custom thumbnail icon) and t=
he=20
  resource fork.<BR><BR>2 - Interpret the resource fork to get to the custom=
=20
  icon resources&nbsp; <BR>(see&nbsp;=20
  <BR>http://developer.apple.com/documentation/mac/MoreToolbox/MoreToolbox=20
  <BR>-99.html for the resoruce file format).<BR><BR>3 - Display the icon=20
  resources (they are bitmaps (see&nbsp;=20
  <BR>http://developer.apple.com/documentation/mac/Toolbox/Toolbox-448.html)=
,&nbsp;=20
  <BR>'icns' resources (see&nbsp;=20
  <BR>http://developer.apple.com/documentation/Carbon/Conceptual/=20
  <BR>Icon_Service_nd_Utilities/02concepts/chapter_2_section_4.html), or=20
  in&nbsp; <BR>PICT format (see&nbsp;=20
  <BR>http://developer.apple.com/documentation/mac/QuickDraw/QuickDraw=20
  <BR>-458.html) -- they aren't jpeg or gif).<BR><BR>So... a bunch of work j=
ust=20
  for thumbnails.<BR><BR>- Jim Luther<BR><BR>On Mar 17, 2004, at 11:23 AM,=20
  Julian Reschke wrote:<BR><BR>&gt;<BR>&gt; FengAndy@aol.com wrote:<BR>&gt;&=
gt;=20
  Folks,<BR>&gt;&gt;&nbsp; Have anyone tried to enable thumbnails via WebDAV=
=20
  clients? Apple's&nbsp; <BR>&gt;&gt; iDisk enables such features. All other=
=20
  WebDAV clients don't seem to&nbsp; <BR>&gt;&gt; have such support. For=20
  example, in Windows, you could not select a&nbsp; <BR>&gt;&gt; WebFolder t=
o=20
  have a thumbnail view.<BR>&gt;&gt;&nbsp; Any suggestion? Thanks in=20
  advance.<BR>&gt;<BR>&gt; There's no specific support for that in WebDAV. D=
o=20
  you know what&nbsp; <BR>&gt; Apple's iDisk is doing here?<BR>&gt;<BR>&gt;=20
  Regards, Julian<BR>&gt;<BR>&gt;<BR>&gt; -- <BR>&gt; &lt;green/&gt;bytes Gm=
bH=20
  -- http://www.greenbytes.de --=20
tel:+492512807760<BR>&gt;<BR><BR></FONT></BLOCKQUOTE></DIV>
<DIV></DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT lang=3D0 face=3DArial color=3D#808000 size=3D2 FAMILY=3D"SANSSERI=
F"=20
PTSIZE=3D"10"><I>Andy Feng <BR><A=20
href=3D"http://blues.netscape.com/users/afeng/publish/">AOL Storage &amp;=20
Personalization Architecture</A></I></FONT></DIV></FONT></BODY></HTML>

-------------------------------1079561093--



From w3c-dist-auth-request@w3.org  Wed Mar 17 18:08:48 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14850
	for <webdav-archive@lists.ietf.org>; Wed, 17 Mar 2004 18:08:48 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id BA5F4A0611; Wed, 17 Mar 2004 18:08:50 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 50689A0611
	for <w3c-dist-auth@listhub.w3.org>; Wed, 17 Mar 2004 18:08:48 -0500 (EST)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B3k9X-0000NG-S8
	for w3c-dist-auth@w3c.org; Wed, 17 Mar 2004 18:08:48 -0500
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: <w3c-dist-auth@w3c.org>
Received: from [192.168.1.103] ([198.144.201.116])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i2HN7MIC024951
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <w3c-dist-auth@w3c.org>; Wed, 17 Mar 2004 15:07:25 -0800
Mime-Version: 1.0 (Apple Message framework v612)
To: Webdav WG <w3c-dist-auth@w3c.org>
Message-Id: <FF13A299-7867-11D8-85E3-000A95B2BB72@osafoundation.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-1-325974978
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 17 Mar 2004 15:08:26 -0800
X-Mailer: Apple Mail (2.612)
X-Scanned-By: MIMEDefang 2.39
Subject: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/FF13A299-7867-11D8-85E3-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8332
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040317230850.BA5F4A0611@frink.w3.org>
Resent-Date: Wed, 17 Mar 2004 18:08:50 -0500 (EST)



--Apple-Mail-1-325974978
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

I've re-reviewed the bind draft.  Many of these issues have come up 
before but I feel they haven't been resolved in the draft.

General
-----------

The spec must stand alone, not be dependent on changes to RFC2518 in 
'bis'.  Otherwise, bind can't be approved until RFC2518bis is approved. 
  That means no dependencies for things like 'lockroot'.

In general, the spec needs more info to specify how existing things 
work.  All the following questions must be answered in the spec, NOT 
just in email.  The spec must be explicit, because different people 
reading a model description always end up with different ideas how the 
model works in practice.

A - Issues relating to 2518 features
   1.  Can you UNLOCK a URI that binds to a locked resource, when that 
URI wasn't directly locked?  If not, what's the error?
   2. Can you LOCK a URI that binds to a locked resource, when that URI 
wasn't directly locked? If not, what's the error?
   3.  In If header evaluation, does a URI "match" a lock token, when 
that URI wasn't directly locked but the underlying resource was locked 
with that token?
   4.  What exactly does lockdiscovery show on a locked binding? On a 
locked resource accessed through an unlocked binding?  Does 
'lockdiscovery' look exactly the same on every binding to a locked 
resource?
   5.  What does creationdate refer to, I assume it's the creationdate 
of the underlying resource (not the creation date of the binding)?  If 
the underlying resource, is there any way to tell when a binding was 
created?  and vice versa?

B - Issues related to versioning features (massively incomplete), or 
how does a server supporting bindings and versioning work
   1. If a resource is checked out, do all bindings appear checked out?  
(In general, are all the live properties defined in versioning the same 
on all bindings?)
   2. Clarify that a VCR isn't just another binding (because different 
VCRs pointing to the same VHR have different live properties, not the 
same ones)
   etc...


Questions on specific text
-----------------------------------

What does this mean (section 2.3, second-last paragraph): "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."

I don't understand the case when more than one source resource updates 
a single destination resource.

I also don't see how this could arise:  " 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."

Section 2.4

" When DELETE is applied to a collection, it MUST NOT modify the 
membership  of any other collection that is not itself a member of the 
collection being deleted. For example, if both "/a/.../x" and 
"/b/.../y" identify the same  collection, C, then applying DELETE to 
"/a" MUST NOT delete an internal  member from C or from any other 
collection that is a member of C, because  that would modify the 
membership of "/b"."

I don't understand why there's a conditional on the first sentence of 
"that is not itself a member of the collection being deleted".  When 
would the membership of any other collection be modified?  In 
particular, C is a descendant (not a direct member) of /a, but even if 
it were a direct member, it seems the rule should apply.

Section 6 -- REBIND method

One precondition is " (DAV:binding-allowed): The resource identified by 
the DAV:href  supports multiple bindings to it."   How can this error 
possibly occur?

Does REBIND destroy locks, as MOVE does?  It shouldn't, unless there's 
a compelling reason for backward compatibility.

Does REBIND change the ETag of a resource?  Does it change the 
getlastmodified value of the resource?


--Apple-Mail-1-325974978
Content-Type: text/enriched;
	charset=US-ASCII
Content-Transfer-Encoding: 7bit

I've re-reviewed the bind draft.  Many of these issues have come up
before but I feel they haven't been resolved in the draft.


<x-tad-bigger>General

-----------


The spec must stand alone, not be dependent on changes to RFC2518 in
'bis'.  Otherwise, bind can't be approved until RFC2518bis is
approved.  That means no dependencies for things like 'lockroot'.


In general, the spec needs more info to specify how existing things
work.  All the following questions must be answered in the spec, NOT
just in email.  The spec must be explicit, because different people
reading a model description always end up with different ideas how the
model works in practice.  


A - Issues relating to 2518 features

  1.  Can you UNLOCK a URI that binds to a locked resource, when that
URI wasn't directly locked?  If not, what's the error?

  2. Can you LOCK a URI that binds to a locked resource, when that URI
wasn't directly locked? If not, what's the error?

  3.  In If header evaluation, does a URI "match" a lock token, when
that URI wasn't directly locked but the underlying resource was locked
with that token?

  4.  What exactly does lockdiscovery show on a locked binding? On a
locked resource accessed through an unlocked binding?  Does
'lockdiscovery' look exactly the same on every binding to a locked
resource?  

  5.  What does creationdate refer to, I assume it's the creationdate
of the underlying resource (not the creation date of the binding)?  If
the underlying resource, is there any way to tell when a binding was
created?  and vice versa? 


B - Issues related to versioning features (massively incomplete), or
how does a server supporting bindings and versioning work

  1. If a resource is checked out, do all bindings appear checked out? 
(In general, are all the live properties defined in versioning the
same on all bindings?)

  2. Clarify that a VCR isn't just another binding (because different
VCRs pointing to the same VHR have different live properties, not the
same ones)

  etc... 

</x-tad-bigger>


Questions on specific text

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


What does this mean (section 2.3, second-last paragraph):
"<x-tad-bigger>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."


I don't understand the case when more than one source resource updates
a single destination resource.


I also don't see how this could arise:  " 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."


Section 2.4


" When DELETE is applied to a collection, it MUST NOT modify the
membership  of any other collection that is not itself a member of the
collection being deleted. For example, if both "/a/.../x" and
"/b/.../y" identify the same  collection, C, then applying DELETE to
"/a" MUST NOT delete an internal  member from C or from any other
collection that is a member of C, because  that would modify the
membership of "/b"."


I don't understand why there's a conditional on the first sentence of
"that is not itself a member of the collection being deleted".  When
would the membership of any other collection be modified?  In
particular, C is a descendant (not a direct member) of /a, but even if
it were a direct member, it seems the rule should apply.


Section 6 -- REBIND method


One precondition is " (DAV:binding-allowed): The resource identified
by the DAV:href  supports multiple bindings to it."   How can this
error possibly occur?


Does REBIND destroy locks, as MOVE does?  It shouldn't, unless there's
a compelling reason for backward compatibility.


Does REBIND change the ETag of a resource?  Does it change the
getlastmodified value of the resource?


</x-tad-bigger>
--Apple-Mail-1-325974978--



From w3c-dist-auth-request@w3.org  Wed Mar 17 18:24:39 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16250
	for <webdav-archive@lists.ietf.org>; Wed, 17 Mar 2004 18:24:39 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 3515AA0715; Wed, 17 Mar 2004 18:24:41 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 62340A0779
	for <w3c-dist-auth@listhub.w3.org>; Wed, 17 Mar 2004 18:24:39 -0500 (EST)
Received: from mail-out3.apple.com ([17.254.13.22])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B3kOt-0003vL-5o
	for w3c-dist-auth@w3.org; Wed, 17 Mar 2004 18:24:39 -0500
Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225])
	by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i2HNO8Hs027339
	for <w3c-dist-auth@w3.org>; Wed, 17 Mar 2004 15:24:08 -0800 (PST)
Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.3.6) with ESMTP id <T6865d4df03118064e13b0@mailgate1.apple.com>;
 Wed, 17 Mar 2004 15:24:08 -0800
Received: from [17.202.43.76] (luthji.apple.com [17.202.43.76])
	by relay3.apple.com (8.12.11/8.12.11) with ESMTP id i2HNNptx024230;
	Wed, 17 Mar 2004 23:23:51 GMT
In-Reply-To: <b7.3dce7acd.2d8a2585@aol.com>
References: <b7.3dce7acd.2d8a2585@aol.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <25E4E884-786A-11D8-80BA-000A95DC65E0@apple.com>
Content-Transfer-Encoding: quoted-printable
Cc: FengAndy@aol.com
From: Jim Luther <luther.j@apple.com>
Date: Wed, 17 Mar 2004 15:23:50 -0800
To: w3c-dist-auth@w3.org
X-Mailer: Apple Mail (2.613)
Subject: Re: FengAndy@aol.com
X-Archived-At: http://www.w3.org/mid/25E4E884-786A-11D8-80BA-000A95DC65E0@apple.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8333
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040317232441.3515AA0715@frink.w3.org>
Resent-Date: Wed, 17 Mar 2004 18:24:41 -0500 (EST)
Content-Transfer-Encoding: quoted-printable


Windows XP uses a completely different scheme for displaying =20
thumbnails. You'd need to talk to someone at Microsoft about how it =20
works.

- Jim (at Apple, not Microsoft :)

> Jim,
>
> I=A0noticed that Windows XP could=A0display the thumbnail for iDisk =
stored =20
> pictures. However, it's not be able to display thumbnails.
>
> Any explanation?
>
> Andy
>
>> In a message dated 3/17/2004 1:46:11 PM Pacific Standard Time, =20
>> luther.j@apple.com writes:
>>
>> On a Macintosh, thumbnails icons for directories are stored in a=A0
>> special file inside the directory (Mac OS 8 through 9 and Mac OS X =20=

>> use=A0
>> different techniques for that file). Thumbnails icons for files are=A0
>> stored in a file's resource fork (the Macintosh file system supports=A0=

>> two file forks -- See=A0
>> <http://developer.apple.com/documentation/mac/Files/Files-14.html>).
>>
>> To store a file's data fork and the file's resource fork and other=A0
>> Macintosh-specific metadata on volume formats (like WebDAV) which =20
>> don't=A0
>> support Macintosh-style resources forks or metadata, the file is =20
>> stored=A0
>> in AppleDouble format (it's funny but the only place I can find the=A0
>> AppleDouble documentation isn't on Apple web site -- it's at=A0
>> =
<http://www.lazerware.com/formats/Specs/AppleSingle_AppleDouble.pdf>.=A0
>> The AppleDouble formatted file is stored as two files. The data for =20=

>> the=A0
>> file is stored in the "AppleDouble Data file" which has the file's=A0
>> name. The resource fork and other Macintosh-specific metadata is =20
>> stored=A0
>> in the "AppleDouble Header file" which has the file's name with the=A0
>> characters "._" prepended.
>>
>> So, if you look at a WebDAV server that has files stored by Mac OS X=A0=

>> clients, you'll probably see files with names beginning with "._" --=A0=

>> that's where the thumbnail icons (if any) are stored.
>>
>> If a non-Macintosh client wanted to display those icons, it would be =20=

>> a=A0
>> lot of work. That client would have to know how to:
>>
>> 1 - Parse the AppleDouble Header file to get the Macintosh Finder=A0
>> information (the metadata which contains a flag indicating the =20
>> presence=A0
>> of a custom thumbnail icon) and the resource fork.
>>
>> 2 - Interpret the resource fork to get to the custom icon resources=A0
>> (see=A0
>> http://developer.apple.com/documentation/mac/MoreToolbox/MoreToolbox
>> -99.html for the resoruce file format).
>>
>> 3 - Display the icon resources (they are bitmaps (see=A0
>> http://developer.apple.com/documentation/mac/Toolbox/Toolbox=20
>> -448.html),=A0
>> 'icns' resources (see=A0
>> http://developer.apple.com/documentation/Carbon/Conceptual/
>> Icon_Service_nd_Utilities/02concepts/chapter_2_section_4.html), or =
in=A0
>> PICT format (see=A0
>> http://developer.apple.com/documentation/mac/QuickDraw/QuickDraw
>> -458.html) -- they aren't jpeg or gif).
>>
>> So... a bunch of work just for thumbnails.
>>
>> - Jim Luther
>>
>> On Mar 17, 2004, at 11:23 AM, Julian Reschke wrote:
>>
>> >
>> > FengAndy@aol.com wrote:
>> >> Folks,
>> >>=A0 Have anyone tried to enable thumbnails via WebDAV clients? =20
>> Apple's=A0
>> >> iDisk enables such features. All other WebDAV clients don't seem =20=

>> to=A0
>> >> have such support. For example, in Windows, you could not select =
a=A0
>> >> WebFolder to have a thumbnail view.
>> >>=A0 Any suggestion? Thanks in advance.
>> >
>> > There's no specific support for that in WebDAV. Do you know what=A0
>> > Apple's iDisk is doing here?
>> >
>> > Regards, Julian
>> >
>> >
>> > --
>> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Wed Mar 17 20:39:12 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22938
	for <webdav-archive@lists.ietf.org>; Wed, 17 Mar 2004 20:39:11 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 30115A05E6; Wed, 17 Mar 2004 20:39:11 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id EA02BA05E6
	for <w3c-dist-auth@listhub.w3.org>; Wed, 17 Mar 2004 20:39:04 -0500 (EST)
Received: from snipe.mail.pas.earthlink.net ([207.217.120.62])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B3mUy-0007Wi-Km
	for w3c-dist-auth@w3.org; Wed, 17 Mar 2004 20:39:04 -0500
Received: from user-11falij.dsl.mindspring.com ([66.245.86.83] helo=[192.168.1.10])
	by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 1B3mUw-0002l8-00; Wed, 17 Mar 2004 17:39:02 -0800
In-Reply-To: <753B2BAA-785C-11D8-816B-000A95DC65E0@apple.com>
References: <15f.2cff17d1.2d89f2c8@aol.com> <4058A5A8.2050202@gmx.de> <753B2BAA-785C-11D8-816B-000A95DC65E0@apple.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <E17DC4D8-787C-11D8-A113-000A95B03262@icx.net>
Content-Transfer-Encoding: 7bit
Cc: w3c-dist-auth@w3.org
From: John DeSoi <jd@icx.net>
Date: Wed, 17 Mar 2004 20:37:56 -0500
To: Jim Luther <luther.j@apple.com>
X-Mailer: Apple Mail (2.606)
Subject: New OS X 10.3 WebDAV bug
X-Archived-At: http://www.w3.org/mid/E17DC4D8-787C-11D8-A113-000A95B03262@icx.net
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8334
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040318013911.30115A05E6@frink.w3.org>
Resent-Date: Wed, 17 Mar 2004 20:39:11 -0500 (EST)
Content-Transfer-Encoding: 7bit


Hi Jim,

I have the bug reporting URL you gave me a while back, but I don't see 
anyway to check if a bug has already reported (or fixed). So I thought 
I would mention it here in case you might know offhand.

With 10.3.1 I can no longer connect to a WebDAV server if I enter the 
IP numeric address directly (using connect to server from the Finder). 
If I enter a DNS or rendezvous name like mycomputer.local it works 
fine, but if I use the numeric IP address it never connects at all (no 
request in the HTTP log). The error message given is "The operation 
cannot be completed because one or more required items cannot be found. 
(Error code -43).

Thanks,

John DeSoi, Ph.D.



From w3c-dist-auth-request@w3.org  Thu Mar 18 06:37:39 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04181
	for <webdav-archive@lists.ietf.org>; Thu, 18 Mar 2004 06:37:38 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id C1770A0D2E; Thu, 18 Mar 2004 06:37:40 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id AA304A0D2E
	for <w3c-dist-auth@listhub.w3.org>; Thu, 18 Mar 2004 06:37:38 -0500 (EST)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B3vqE-0008Ea-1Q
	for w3c-dist-auth@w3c.org; Thu, 18 Mar 2004 06:37:38 -0500
Received: (qmail 14896 invoked by uid 65534); 18 Mar 2004 11:37:05 -0000
Received: from p50824FD1.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.79.209)
  by mail.gmx.net (mp022) with SMTP; 18 Mar 2004 12:37:05 +0100
X-Authenticated: #1915285
Message-ID: <405989DA.3090605@gmx.de>
Date: Thu, 18 Mar 2004 12:36:58 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
References: <FF13A299-7867-11D8-85E3-000A95B2BB72@osafoundation.org>
In-Reply-To: <FF13A299-7867-11D8-85E3-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/405989DA.3090605@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8335
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040318113740.C1770A0D2E@frink.w3.org>
Resent-Date: Thu, 18 Mar 2004 06:37:40 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> I've re-reviewed the bind draft. Many of these issues have come up 
> before but I feel they haven't been resolved in the draft.
> 
> General
> -----------
> 
> The spec must stand alone, not be dependent on changes to RFC2518 in 
> 'bis'. Otherwise, bind can't be approved until RFC2518bis is approved. 
> That means no dependencies for things like 'lockroot'.

There isn't any.

> In general, the spec needs more info to specify how existing things 
> work. All the following questions must be answered in the spec, NOT just 
> in email. The spec must be explicit, because different people reading a 
> model description always end up with different ideas how the model works 
> in practice.

Here I disagree.

First of all, there are several ways to resolve questions raised:

1) If there is a simple answer based on existing specs and the current 
draft, just answer it here on the mailing list.

2) If the issue is likely to be re-raised (because the answer is not 
obvious), record it (and the answer) on the issues list.

3) If the issue is indeed valid, add it to the issues list and attempt 
to resolve it.

In general, there are areas where the spec *can't* specify how existing 
things work, because they depend on specific implementations. I 
absolutely agree that those situations should be avoided, but sometime 
there's nothing we can do about that.

I'll post answers to the specific issues in a separate mail.

Regards, Julian

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



From w3c-dist-auth-request@w3.org  Thu Mar 18 08:29:46 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09526
	for <webdav-archive@lists.ietf.org>; Thu, 18 Mar 2004 08:29:41 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 0E9AFA11D5; Thu, 18 Mar 2004 08:29:42 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 42D82A11D5
	for <w3c-dist-auth@listhub.w3.org>; Thu, 18 Mar 2004 08:29:38 -0500 (EST)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B3xab-0001rj-Rj
	for w3c-dist-auth@w3c.org; Thu, 18 Mar 2004 08:29:38 -0500
Received: (qmail 9294 invoked by uid 65534); 18 Mar 2004 13:29:05 -0000
Received: from p50824FD1.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.79.209)
  by mail.gmx.net (mp026) with SMTP; 18 Mar 2004 14:29:05 +0100
X-Authenticated: #1915285
Message-ID: <4059A41F.4070809@gmx.de>
Date: Thu, 18 Mar 2004 14:29:03 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
References: <FF13A299-7867-11D8-85E3-000A95B2BB72@osafoundation.org>
In-Reply-To: <FF13A299-7867-11D8-85E3-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/4059A41F.4070809@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8336
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040318132942.0E9AFA11D5@frink.w3.org>
Resent-Date: Thu, 18 Mar 2004 08:29:42 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> A - Issues relating to 2518 features
> 1. Can you UNLOCK a URI that binds to a locked resource, when that URI 
> wasn't directly locked? If not, what's the error?

I can't see any language in RFC2518 and/or BIND saying that you can't, 
so you can. UNLOCK removes the lock identified by the lock token header 
from the resource identified by the request URI, so the actual URI being 
used for UNLOCK is irrelevant.

> 2. Can you LOCK a URI that binds to a locked resource, when that URI 
> wasn't directly locked? If not, what's the error?

You can, as long both locks are compatible (that is, none of them is 
exclusive). So the situation here is exactly as if you use the same 
request URI.

> 3. In If header evaluation, does a URI "match" a lock token, when that 
> URI wasn't directly locked but the underlying resource was locked with 
> that token?

The If header matching description 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.9.4.4>) 
talks about resources, not URIs, thus it's not relevant which URI you 
provide as long as it identifies the right resource.

> 4. What exactly does lockdiscovery show on a locked binding? On a locked 
> resource accessed through an unlocked binding? Does 'lockdiscovery' look 
> exactly the same on every binding to a locked resource?

Yes. The lock belongs to the state of the resource, so PROPFIND returns 
the same operation no matter which binding you use.

> 5. What does creationdate refer to, I assume it's the creationdate of 
> the underlying resource (not the creation date of the binding)? If the 

Yes.

> underlying resource, is there any way to tell when a binding was 

No.

> created? and vice versa?

> B - Issues related to versioning features (massively incomplete), or how 
> does a server supporting bindings and versioning work
> 1. If a resource is checked out, do all bindings appear checked out? (In 
> general, are all the live properties defined in versioning the same on 
> all bindings?)

Yes, again; that's the nature of bindings.

> 2. Clarify that a VCR isn't just another binding (because different VCRs 
> pointing to the same VHR have different live properties, not the same ones)
> etc...

As DeltaV doesn't say that, I'm not sure why we would need to clarify that.

> Questions on specific text
> -----------------------------------
> 
> What does this mean (section 2.3, second-last paragraph): "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."
>
> I don't understand the case when more than one source resource updates a 
> single destination resource.

This can happen when, for instance, you copy /a with members /a/b and 
/a/c (bindings to different resources) to a destination /d with members 
/d/a and /d/b (bindings to the same resource). The end result will be 
that /d/a and /d/b are still bindings to the same resource, but the spec 
doesn't guarantee whether it'll be the content of /a/b or /a/c. It's an 
edge case.

> I also don't see how this could arise: " 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."

See 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-03.html#rfc.issue.2.3_COPY_SHARED_BINDINGS>.

> Section 2.4
> 
> " When DELETE is applied to a collection, it MUST NOT modify the 
> membership of any other collection that is not itself a member of the 
> collection being deleted. For example, if both "/a/.../x" and "/b/.../y" 
> identify the same collection, C, then applying DELETE to "/a" MUST NOT 
> delete an internal member from C or from any other collection that is a 
> member of C, because that would modify the membership of "/b"."
> 
> I don't understand why there's a conditional on the first sentence of 
> "that is not itself a member of the collection being deleted". When 
> would the membership of any other collection be modified? In particular, 

It shouldn't. That's the point of the statement.

> C is a descendant (not a direct member) of /a, but even if it were a 
> direct member, it seems the rule should apply.
> 
> Section 6 -- REBIND method
> 
> One precondition is " (DAV:binding-allowed): The resource identified by 
> the DAV:href supports multiple bindings to it." How can this error 
> possibly occur?

If a part of your namespace doesn't allow multiple bindings.

> Does REBIND destroy locks, as MOVE does? It shouldn't, unless there's a 
> compelling reason for backward compatibility.

No, it should. REBIND is a "strong" MOVE (that will never attempt a 
"weak" resource move using COPY/DELETE). That's the only semantical 
difference to MOVE, and thus locks behave just like they do with MOVE.

> Does REBIND change the ETag of a resource? Does it change the 
> getlastmodified value of the resource?

Same as MOVE (which means: usually not).

Regards, Julian

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



From w3c-dist-auth-request@w3.org  Thu Mar 18 09:02:23 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11441
	for <webdav-archive@lists.ietf.org>; Thu, 18 Mar 2004 09:02:23 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 2599AA060B; Thu, 18 Mar 2004 09:02:24 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 13A13A0626
	for <w3c-dist-auth@listhub.w3.org>; Thu, 18 Mar 2004 09:02:20 -0500 (EST)
Received: from e3.ny.us.ibm.com ([32.97.182.103])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B3y6F-00009C-M8
	for w3c-dist-auth@w3c.org; Thu, 18 Mar 2004 09:02:19 -0500
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2IE1mAB790572
	for <w3c-dist-auth@w3c.org>; Thu, 18 Mar 2004 09:01:48 -0500
Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2IE1kpH031590
	for <w3c-dist-auth@w3c.org>; Thu, 18 Mar 2004 09:01:46 -0500
In-Reply-To: <FF13A299-7867-11D8-85E3-000A95B2BB72@osafoundation.org>
To: Webdav WG <w3c-dist-auth@w3c.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OFC7205BA3.DA32509E-ON85256E5B.0048D28F-85256E5B.004CFDB7@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Thu, 18 Mar 2004 09:01:35 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at
 03/18/2004 09:01:47,
	Serialize complete at 03/18/2004 09:01:47
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/OFC7205BA3.DA32509E-ON85256E5B.0048D28F-85256E5B.004CFDB7@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8337
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040318140224.2599AA060B@frink.w3.org>
Resent-Date: Thu, 18 Mar 2004 09:02:24 -0500 (EST)


Lisa wrote on 03/17/2004 06:08:26 PM:

> General
> -----------
> 
> The spec must stand alone, not be dependent on changes to RFC2518 in 
> 'bis'.  Otherwise, bind can't be approved until RFC2518bis is approved. 

I wouldn't describe this as "standing alone" (since it clearly must
depend on RFC2616, RFC2518, etc.), but I agree that it cannot depend
on material in specs that have not yet been finished/approved.

>   That means no dependencies for things like 'lockroot'.

As Julian indicated, we are not aware of any such dependencies.

> In general, the spec needs more info to specify how existing things 
> work. 

The spec needs to describe how the new things it is
defining work, and it needs to describe any modifications to the
behavior of existing things.  But if it is layered above some other
specs (as the binding spec is layered above 2616, 2518, etc), it
should not repeat or reword behavior it is just inheriting unmodified
from those other spec.  Doing so would only introduce confusion
when the spec that does define the behavior of those existing things is 
revised.

> All the following questions must be answered in the spec, NOT 
> just in email.

If every question that ever arises about a spec on the
mailing list resulted in a paragraph or even just a
sentence being added to the spec, the spec would rapidly
become too bulky and verbose to be useful as a spec.

> The spec must be explicit, because different people 
> reading a model description always end up with different ideas how the 
> model works in practice.

As Julian indicated, there are a variety of sources of information
that are used to help implementors.  The spec is of course a critical
piece, but the issues list and the mailing list are two other essential
pieces.

So every question gets answered in the mailing list.
Some questions get added to the issues list.
Some issues result in changes to the specification.

Cheers,
Geoff



From w3c-dist-auth-request@w3.org  Thu Mar 18 11:52:25 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24726
	for <webdav-archive@lists.ietf.org>; Thu, 18 Mar 2004 11:52:24 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 86F06A0787; Thu, 18 Mar 2004 11:52:26 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 4110EA0787
	for <w3c-dist-auth@listhub.w3.org>; Thu, 18 Mar 2004 11:52:23 -0500 (EST)
Received: from cats-mx3.ucsc.edu ([128.114.129.37] helo=ucsc.edu)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B40kk-0007M9-5F
	for w3c-dist-auth@w3.org; Thu, 18 Mar 2004 11:52:18 -0500
Received: from dhcp-63-214.cse.ucsc.edu (dhcp-63-214.cse.ucsc.edu [128.114.63.214])
	by ucsc.edu (8.10.1/8.10.1) with ESMTP id i2IGmNA09343;
	Thu, 18 Mar 2004 08:48:23 -0800 (PST)
To: "WebDAV" <w3c-dist-auth@w3.org>
Cc: "Ted Hardie" <hardie@qualcomm.com>
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
Reply-To: "Jim Whitehead" <ejw@cse.ucsc.edu>
Organization: UC Santa Cruz
X-Priority: 3 (normal)
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
X-Mailer: Bloomba 1.0.5
Mime-Version: 1.0
Message-Id: <20040318084703.1311917671.ejw@cse.ucsc.edu>
Date: Thu, 18 Mar 2004 08:47:03 -0800
X-UCSC-CATS-MailScanner: Found to be clean
Subject: Stepping down
X-Archived-At: http://www.w3.org/mid/20040318084703.1311917671.ejw@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8338
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040318165226.86F06A0787@frink.w3.org>
Resent-Date: Thu, 18 Mar 2004 11:52:26 -0500 (EST)
Content-Transfer-Encoding: quoted-printable


Over the past year it has become increasingly clear that I no longer have e=
nough time to dedicate to the task of effectively leading the WebDAV Workin=
g Group. This is perhaps inevitable. When I started the WebDAV Working Grou=
p I was a PhD student, and could dedicate significant blocks of time to thi=
s project. Now, as an Assistant Professor with 8 PhD students of my own (as=
 well as two small children at home), this is no longer the case. The final=
 straw was me taking on the role of General Chair (organizer) of the ACM Hy=
pertext 2004 conference, itself an enormously time consuming volunteer role=
.

WebDAV Working Group is very close to completing its original technical age=
nda, a tremendous accomplishment. Many standards development efforts never =
come close to this, or have the adoption and impact of WebDAV. Still, we do=
 have some final work to complete. There is the bindings specification, and=
 the redirect references protocol. Moving 2518 to Draft Standard is still a=
s important as ever. DASL is already effectively at a Proposed Standard lev=
el of adoption, and needs to be finished to ensure greater adoption. WebDAV=
 WG needs a steady hand to bring these to completion, and, alas, that's no =
longer me.

As a result, effective today, I am stepping down as Co-Chair of the WebDAV =
Working Group. Ted Hardie, our Applications Area Director, will be appointi=
ng Patrik Faltstrom (a former AD of the WebDAV WG) to take my place. Lisa D=
usseault will be continuing her excellent work as Co-Chair. I very much enc=
ourage you to work with Patrik and Lisa (as will I) to complete the WebDAV =
agenda. =


I still intend to continue contributing to the WebDAV community. Several of=
 my ongoing research projects have a WebDAV aspect to them, including the C=
atacomb server, and the Prestan performance analysis suite. I will continue=
 to contribute to the webdav.org site, as well as help with additional expl=
anation of the contributions and uses of the protocol. Finally, I also hope=
 to work to interest people in building new protocols on top of WebDAV -- c=
alendaring is one area that seems long overdue. I'm certainly not turning m=
y back on the WebDAV community. Rather I'm acknowledging that I'm no longer=
 the right person to lead protocol development efforts to completion.

- Jim Whitehead



From w3c-dist-auth-request@w3.org  Thu Mar 18 12:28:05 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26280
	for <webdav-archive@lists.ietf.org>; Thu, 18 Mar 2004 12:28:04 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 01B09A14E6; Thu, 18 Mar 2004 12:28:05 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id A6E43A1409
	for <w3c-dist-auth@listhub.w3.org>; Thu, 18 Mar 2004 12:27:59 -0500 (EST)
Received: from mail-out3.apple.com ([17.254.13.22])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B41JH-0007RR-BG
	for w3c-dist-auth@w3.org; Thu, 18 Mar 2004 12:27:59 -0500
Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225])
	by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i2IHRSvD002039
	for <w3c-dist-auth@w3.org>; Thu, 18 Mar 2004 09:27:28 -0800 (PST)
Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.3.6) with ESMTP id <T6869b4afdf118064e13b0@mailgate1.apple.com>;
 Thu, 18 Mar 2004 09:27:27 -0800
Received: from [17.202.43.76] (luthji.apple.com [17.202.43.76])
	by relay3.apple.com (8.12.11/8.12.11) with ESMTP id i2IHRA1Y019453;
	Thu, 18 Mar 2004 17:27:11 GMT
In-Reply-To: <E17DC4D8-787C-11D8-A113-000A95B03262@icx.net>
References: <15f.2cff17d1.2d89f2c8@aol.com> <4058A5A8.2050202@gmx.de> <753B2BAA-785C-11D8-816B-000A95DC65E0@apple.com> <E17DC4D8-787C-11D8-A113-000A95B03262@icx.net>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <7C18110C-7901-11D8-8F46-000A95DC65E0@apple.com>
Content-Transfer-Encoding: 7bit
Cc: w3c-dist-auth@w3.org
From: Jim Luther <luther.j@apple.com>
Date: Thu, 18 Mar 2004 09:27:09 -0800
To: John DeSoi <jd@icx.net>
X-Mailer: Apple Mail (2.613)
Subject: Re: New OS X 10.3 WebDAV bug
X-Archived-At: http://www.w3.org/mid/7C18110C-7901-11D8-8F46-000A95DC65E0@apple.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8339
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040318172805.01B09A14E6@frink.w3.org>
Resent-Date: Thu, 18 Mar 2004 12:28:05 -0500 (EST)
Content-Transfer-Encoding: 7bit


Try Mac OS X 10.3.2 or later. They contain a fix for that problem. The 
current version of Mac OS X is 10.3.3 (released earlier this week).

- Jim

On Mar 17, 2004, at 5:37 PM, John DeSoi wrote:

> Hi Jim,
>
> I have the bug reporting URL you gave me a while back, but I don't see 
> anyway to check if a bug has already reported (or fixed). So I thought 
> I would mention it here in case you might know offhand.
>
> With 10.3.1 I can no longer connect to a WebDAV server if I enter the 
> IP numeric address directly (using connect to server from the Finder). 
> If I enter a DNS or rendezvous name like mycomputer.local it works 
> fine, but if I use the numeric IP address it never connects at all (no 
> request in the HTTP log). The error message given is "The operation 
> cannot be completed because one or more required items cannot be 
> found. (Error code -43).
>
> Thanks,
>
> John DeSoi, Ph.D.
>



From w3c-dist-auth-request@w3.org  Thu Mar 18 13:16:42 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28693
	for <webdav-archive@lists.ietf.org>; Thu, 18 Mar 2004 13:16:41 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 5EFDCA156B; Thu, 18 Mar 2004 13:16:43 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 5B013A157D
	for <w3c-dist-auth@listhub.w3.org>; Thu, 18 Mar 2004 13:16:41 -0500 (EST)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B424O-0005aO-QZ
	for w3c-dist-auth@w3c.org; Thu, 18 Mar 2004 13:16:40 -0500
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i2IIFFIC004561
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Thu, 18 Mar 2004 10:15:15 -0800
In-Reply-To: <4059A41F.4070809@gmx.de>
References: <FF13A299-7867-11D8-85E3-000A95B2BB72@osafoundation.org> <4059A41F.4070809@gmx.de>
Mime-Version: 1.0 (Apple Message framework v612)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <60E0196A-7908-11D8-85E3-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Thu, 18 Mar 2004 10:16:29 -0800
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.612)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/60E0196A-7908-11D8-85E3-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8340
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040318181643.5EFDCA156B@frink.w3.org>
Resent-Date: Thu, 18 Mar 2004 13:16:43 -0500 (EST)
Content-Transfer-Encoding: 7bit




On Mar 18, 2004, at 5:29 AM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>
>> A - Issues relating to 2518 features
>> 1. Can you UNLOCK a URI that binds to a locked resource, when that  
>> URI wasn't directly locked? If not, what's the error?
>
> I can't see any language in RFC2518 and/or BIND saying that you can't,  
> so you can. UNLOCK removes the lock identified by the lock token  
> header from the resource identified by the request URI, so the actual  
> URI being used for UNLOCK is irrelevant.

It's not good enough to say that if it's not forbidden, it's allowed.   
Servers need to either allow this consistently, or disallow it  
consistently.  Clients need dependable behavior.  The spec needs to say  
something like "Servers MUST allow UNLOCK to succeed on a binding to a  
locked resource (provided other conditions are met like lock token),  
even if the locked resource was originally locked through another  
binding.

>> 2. Can you LOCK a URI that binds to a locked resource, when that URI  
>> wasn't directly locked? If not, what's the error?
>
> You can, as long both locks are compatible (that is, none of them is  
> exclusive). So the situation here is exactly as if you use the same  
> request URI.

Again, this needs to be clear in the spec.  Add language to the spec  
saying "A lock created on any binding to a resource prevents exclusive  
locks from being created on any other binding to the same resource."

>> 3. In If header evaluation, does a URI "match" a lock token, when  
>> that URI wasn't directly locked but the underlying resource was  
>> locked with that token?
>
> The If header matching description  
> (<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.9.4.4>)  
> talks about resources, not URIs, thus it's not relevant which URI you  
> provide as long as it identifies the right resource.

So say that in the spec.

>> 4. What exactly does lockdiscovery show on a locked binding? On a  
>> locked resource accessed through an unlocked binding? Does  
>> 'lockdiscovery' look exactly the same on every binding to a locked  
>> resource?
>
> Yes. The lock belongs to the state of the resource, so PROPFIND  
> returns the same operation no matter which binding you use.

So say that in the spec.  This clearly needs to be said, because  
several people have read the spec and come to different conclusions  
about whether other bindings also appear as locked.

>> 5. What does creationdate refer to, I assume it's the creationdate of  
>> the underlying resource (not the creation date of the binding)? If  
>> the
>
> Yes.

etc...

>> underlying resource, is there any way to tell when a binding was
>
> No.
>
>> created? and vice versa?
>
>> B - Issues related to versioning features (massively incomplete), or  
>> how does a server supporting bindings and versioning work
>> 1. If a resource is checked out, do all bindings appear checked out?  
>> (In general, are all the live properties defined in versioning the  
>> same on all bindings?)
>
> Yes, again; that's the nature of bindings.
>
>> 2. Clarify that a VCR isn't just another binding (because different  
>> VCRs pointing to the same VHR have different live properties, not the  
>> same ones)
>> etc...
>
> As DeltaV doesn't say that, I'm not sure why we would need to clarify  
> that.
>
I had to do a fair bit of thinking and logical deductions to figure  
that out, and I'm fairly experienced in this area.  Let's save  
implementors that work and the risk of making an incorrect assumption.   
A bindings section on the relationship of binding to the  
resources/properties defined in DeltaV isn't too hard to write.

>> Questions on specific text
>> -----------------------------------
>> What does this mean (section 2.3, second-last paragraph): "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."
>>
>> I don't understand the case when more than one source resource  
>> updates a single destination resource.
>
> This can happen when, for instance, you copy /a with members /a/b and  
> /a/c (bindings to different resources) to a destination /d with  
> members /d/a and /d/b (bindings to the same resource). The end result  
> will be that /d/a and /d/b are still bindings to the same resource,  
> but the spec doesn't guarantee whether it'll be the content of /a/b or  
> /a/c. It's an edge case.
>
Do you mean you're copying /a so that it becomes a child of the  
destination /d or so that it overwrites the destination /d?

>> I also don't see how this could arise: " 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."
>
> See  
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind 
> -03.html#rfc.issue.2.3_COPY_SHARED_BINDINGS>.
>
>> Section 2.4
>> " When DELETE is applied to a collection, it MUST NOT modify the  
>> membership of any other collection that is not itself a member of the  
>> collection being deleted. For example, if both "/a/.../x" and  
>> "/b/.../y" identify the same collection, C, then applying DELETE to  
>> "/a" MUST NOT delete an internal member from C or from any other  
>> collection that is a member of C, because that would modify the  
>> membership of "/b"."
>> I don't understand why there's a conditional on the first sentence of  
>> "that is not itself a member of the collection being deleted". When  
>> would the membership of any other collection be modified? In  
>> particular,
>
> It shouldn't. That's the point of the statement.

If you agree with me, then the text should simply read:

"When DELETE is applied to a collection, it MUST NOT modify the  
membership of any other collection.  For example, if both [continue  
text unchanged...]"

>
>> C is a descendant (not a direct member) of /a, but even if it were a  
>> direct member, it seems the rule should apply.
>> Section 6 -- REBIND method
>> One precondition is " (DAV:binding-allowed): The resource identified  
>> by the DAV:href supports multiple bindings to it." How can this error  
>> possibly occur?
>
> If a part of your namespace doesn't allow multiple bindings.

This is in a case where the resource already allowed multiple bindings,  
one of the bindings is simply being rebound.  So "DAV:binding-allowed"  
means either that the resource doesn't support multiple bindings, OR  
that the URI namespace area doesn't support multiple bindings?

>
>> Does REBIND destroy locks, as MOVE does? It shouldn't, unless there's  
>> a compelling reason for backward compatibility.
>
> No, it should. REBIND is a "strong" MOVE (that will never attempt a  
> "weak" resource move using COPY/DELETE). That's the only semantical  
> difference to MOVE, and thus locks behave just like they do with MOVE.

I disagree, but in either case, the spec needs to say this one way or  
another.

>
>> Does REBIND change the ETag of a resource? Does it change the  
>> getlastmodified value of the resource?
>
> Same as MOVE (which means: usually not).

Can't we be more specific about this?

Lisa



From w3c-dist-auth-request@w3.org  Thu Mar 18 13:51:43 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00314
	for <webdav-archive@lists.ietf.org>; Thu, 18 Mar 2004 13:51:43 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A41B2A14BA; Thu, 18 Mar 2004 13:51:42 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id D7DCCA14BA
	for <w3c-dist-auth@listhub.w3.org>; Thu, 18 Mar 2004 13:51:40 -0500 (EST)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B42cG-0007DY-8s
	for w3c-dist-auth@w3c.org; Thu, 18 Mar 2004 13:51:40 -0500
Received: (qmail 9875 invoked by uid 65534); 18 Mar 2004 18:51:08 -0000
Received: from mail.greenbytes.de (EHLO gmx.de) (217.5.201.10)
  by mail.gmx.net (mp017) with SMTP; 18 Mar 2004 19:51:08 +0100
X-Authenticated: #1915285
Message-ID: <4059EF8F.4090809@gmx.de>
Date: Thu, 18 Mar 2004 19:50:55 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
References: <FF13A299-7867-11D8-85E3-000A95B2BB72@osafoundation.org> <4059A41F.4070809@gmx.de> <60E0196A-7908-11D8-85E3-000A95B2BB72@osafoundation.org>
In-Reply-To: <60E0196A-7908-11D8-85E3-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/4059EF8F.4090809@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8341
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040318185142.A41B2A14BA@frink.w3.org>
Resent-Date: Thu, 18 Mar 2004 13:51:42 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> On Mar 18, 2004, at 5:29 AM, Julian Reschke wrote:
> 
>> Lisa Dusseault wrote:
>>
>>> A - Issues relating to 2518 features
>>> 1. Can you UNLOCK a URI that binds to a locked resource, when that  
>>> URI wasn't directly locked? If not, what's the error?
>>
>>
>> I can't see any language in RFC2518 and/or BIND saying that you 
>> can't,  so you can. UNLOCK removes the lock identified by the lock 
>> token  header from the resource identified by the request URI, so the 
>> actual  URI being used for UNLOCK is irrelevant.
> 
> 
> It's not good enough to say that if it's not forbidden, it's allowed.   
> Servers need to either allow this consistently, or disallow it  
> consistently.  Clients need dependable behavior.  The spec needs to say  
> something like "Servers MUST allow UNLOCK to succeed on a binding to a  
> locked resource (provided other conditions are met like lock token),  
> even if the locked resource was originally locked through another  binding.

The behaviour follows directly from what RFC2518 and the BIND spec say. 
The essential fact here is that live properties and locks belong to the 
state of the resource, so *unless stated explicitly otherwise*, the 
request URI does not matter. I think the BIND draft is very clear on 
that generic principle, and this is all we need.

>>> 2. Can you LOCK a URI that binds to a locked resource, when that URI  
>>> wasn't directly locked? If not, what's the error?
>>
>>
>> You can, as long both locks are compatible (that is, none of them is  
>> exclusive). So the situation here is exactly as if you use the same  
>> request URI.
> 
> 
> Again, this needs to be clear in the spec.  Add language to the spec  
> saying "A lock created on any binding to a resource prevents exclusive  
> locks from being created on any other binding to the same resource."

But that follows from RFC2518's locking semantics. The request URI does 
not matter -- you are accessing the same resource, and thus it behaves 
as if you'd attempt the two locks on the same request URI.

>>> 3. In If header evaluation, does a URI "match" a lock token, when  
>>> that URI wasn't directly locked but the underlying resource was  
>>> locked with that token?
>>
>>
>> The If header matching description  
>> (<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.9.4.4>)  
>> talks about resources, not URIs, thus it's not relevant which URI you  
>> provide as long as it identifies the right resource.
> 
> 
> So say that in the spec.

Sorry? Are you suggesting that anytime RFC2518 applies, we say that 
explicitly?

>>> 4. What exactly does lockdiscovery show on a locked binding? On a  
>>> locked resource accessed through an unlocked binding? Does  
>>> 'lockdiscovery' look exactly the same on every binding to a locked  
>>> resource?
>>
>>
>> Yes. The lock belongs to the state of the resource, so PROPFIND  
>> returns the same operation no matter which binding you use.
> 
> 
> So say that in the spec.  This clearly needs to be said, because  
> several people have read the spec and come to different conclusions  
> about whether other bindings also appear as locked.

In which case I'd like to hear *how* they came to that conclusion.

> ...

>>> 2. Clarify that a VCR isn't just another binding (because different  
>>> VCRs pointing to the same VHR have different live properties, not 
>>> the  same ones)
>>> etc...
>>
>>
>> As DeltaV doesn't say that, I'm not sure why we would need to clarify  
>> that.
>>
> I had to do a fair bit of thinking and logical deductions to figure  
> that out, and I'm fairly experienced in this area.  Let's save  
> implementors that work and the risk of making an incorrect assumption.   
> A bindings section on the relationship of binding to the  
> resources/properties defined in DeltaV isn't too hard to write.

I'm still not sure which part of DeltaV is supposed to be unclear here. 
But if there is one, this should be fixed as an RFC3253 erratum.

>>> Questions on specific text
>>> -----------------------------------
>>> What does this mean (section 2.3, second-last paragraph): "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."
>>>
>>> I don't understand the case when more than one source resource  
>>> updates a single destination resource.
>>
>>
>> This can happen when, for instance, you copy /a with members /a/b and  
>> /a/c (bindings to different resources) to a destination /d with  
>> members /d/a and /d/b (bindings to the same resource). The end result  
>> will be that /d/a and /d/b are still bindings to the same resource,  
>> but the spec doesn't guarantee whether it'll be the content of /a/b 
>> or  /a/c. It's an edge case.
>>
> Do you mean you're copying /a so that it becomes a child of the  
> destination /d or so that it overwrites the destination /d?

The latter.

> ...

>>> Section 2.4
>>> " When DELETE is applied to a collection, it MUST NOT modify the  
>>> membership of any other collection that is not itself a member of 
>>> the  collection being deleted. For example, if both "/a/.../x" and  
>>> "/b/.../y" identify the same collection, C, then applying DELETE to  
>>> "/a" MUST NOT delete an internal member from C or from any other  
>>> collection that is a member of C, because that would modify the  
>>> membership of "/b"."
>>> I don't understand why there's a conditional on the first sentence 
>>> of  "that is not itself a member of the collection being deleted". 
>>> When  would the membership of any other collection be modified? In  
>>> particular,
>>
>>
>> It shouldn't. That's the point of the statement.
> 
> 
> If you agree with me, then the text should simply read:
> 
> "When DELETE is applied to a collection, it MUST NOT modify the  
> membership of any other collection.  For example, if both [continue  
> text unchanged...]"

Well, it *may* change the membership of member collections.

>>> C is a descendant (not a direct member) of /a, but even if it were a  
>>> direct member, it seems the rule should apply.
>>> Section 6 -- REBIND method
>>> One precondition is " (DAV:binding-allowed): The resource identified  
>>> by the DAV:href supports multiple bindings to it." How can this 
>>> error  possibly occur?
>>
>>
>> If a part of your namespace doesn't allow multiple bindings.
> 
> 
> This is in a case where the resource already allowed multiple bindings,
> one of the bindings is simply being rebound.  So "DAV:binding-allowed"  
> means either that the resource doesn't support multiple bindings, OR  
> that the URI namespace area doesn't support multiple bindings?

OK, now I see. This precondition also exists on BIND (where it makes a 
lot of sense), however I'm not sure why we would need it for REBIND. 
Geoff, do you remember why it appears here?

>>> Does REBIND destroy locks, as MOVE does? It shouldn't, unless 
>>> there's  a compelling reason for backward compatibility.
>>
>>
>> No, it should. REBIND is a "strong" MOVE (that will never attempt a  
>> "weak" resource move using COPY/DELETE). That's the only semantical  
>> difference to MOVE, and thus locks behave just like they do with MOVE.
> 
> 
> I disagree, but in either case, the spec needs to say this one way or  
> another.

OK, we may have to add this piece of information, because it's not obvious.

>>> Does REBIND change the ETag of a resource? Does it change the  
>>> getlastmodified value of the resource?
>>
>>
>> Same as MOVE (which means: usually not).
> 
> 
> Can't we be more specific about this?

No, we can't. It *will* be the same as for MOVE, and for MOVE there's no 
guarantee whatsoever.


Julian

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



From w3c-dist-auth-request@w3.org  Thu Mar 18 15:48:17 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08123
	for <webdav-archive@lists.ietf.org>; Thu, 18 Mar 2004 15:48:16 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 4E85BA08D1; Thu, 18 Mar 2004 15:48:13 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id AB0A2A0CDC
	for <w3c-dist-auth@listhub.w3.org>; Thu, 18 Mar 2004 15:48:08 -0500 (EST)
Received: from e6.ny.us.ibm.com ([32.97.182.106])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B44Qy-0000Tq-94
	for w3c-dist-auth@w3c.org; Thu, 18 Mar 2004 15:48:08 -0500
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2IKlb4i702556
	for <w3c-dist-auth@w3c.org>; Thu, 18 Mar 2004 15:47:37 -0500
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2IKlapH084572
	for <w3c-dist-auth@w3c.org>; Thu, 18 Mar 2004 15:47:36 -0500
In-Reply-To: <4059EF8F.4090809@gmx.de>
To: Webdav WG <w3c-dist-auth@w3c.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF353135F8.6EBA581E-ON85256E5B.006F1A8A-85256E5B.00723892@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Thu, 18 Mar 2004 15:47:35 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at
 03/18/2004 15:47:37,
	Serialize complete at 03/18/2004 15:47:37
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/OF353135F8.6EBA581E-ON85256E5B.006F1A8A-85256E5B.00723892@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8342
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040318204813.4E85BA08D1@frink.w3.org>
Resent-Date: Thu, 18 Mar 2004 15:48:13 -0500 (EST)


Julian wrote on 03/18/2004 01:50:55 PM:

> Lisa Dusseault wrote:
> 
> > On Mar 18, 2004, at 5:29 AM, Julian Reschke wrote:
> > 
> >> Lisa Dusseault wrote:

> >>> 2. Clarify that a VCR isn't just another binding (because different 
> >>> VCRs pointing to the same VHR have different live properties, not 
> >>> the  same ones)
> >>> etc...
> >>
> >> As DeltaV doesn't say that, I'm not sure why we would need to clarify 
 
> >> that.
> >>
> > I had to do a fair bit of thinking and logical deductions to figure 
> > that out, and I'm fairly experienced in this area.  Let's save 
> > implementors that work and the risk of making an incorrect assumption. 
 
> > A bindings section on the relationship of binding to the 
> > resources/properties defined in DeltaV isn't too hard to write.
> 
> I'm still not sure which part of DeltaV is supposed to be unclear here. 
> But if there is one, this should be fixed as an RFC3253 erratum.

This is deliberately left as an implementation choices.  For example, on 
one
of our servers, we do use multiple bindings to a shared resource for 
checked-in VCR's, and then automatically create a new resource on
checkout.  As long as we satisfy the versioning pre and post conditions,
we are free to make that choice.  If the spec made the kind of statement
Lisa is asking for, it would be limiting the implementation choices of
a provider for no good reason.

In general, an implementor will have to do a fair bit of thinking and
logical deductions, because the spec is the basis for interoperation of
a wide range of implementations, not an implementation guide.

> >>> Section 6 -- REBIND method
> >>> One precondition is " (DAV:binding-allowed): The resource identified 
 
> >>> by the DAV:href supports multiple bindings to it." How can this 
> >>> error  possibly occur?

> OK, now I see. This precondition also exists on BIND (where it makes a 
> lot of sense), however I'm not sure why we would need it for REBIND. 
> Geoff, do you remember why it appears here?

I think it is just an error (resulting from copying all of the BIND
preconditions to the REBIND method).

So I think deleting the precondition would be the right thing to do.

> >>> Does REBIND destroy locks, as MOVE does? It shouldn't, unless 
> >>> there's  a compelling reason for backward compatibility.
> >>
> >> No, it should. REBIND is a "strong" MOVE (that will never attempt a 
> >> "weak" resource move using COPY/DELETE). That's the only semantical 
> >> difference to MOVE, and thus locks behave just like they do with 
MOVE.
> > 
> > I disagree, but in either case, the spec needs to say this one way or 
> > another.
> 
> OK, we may have to add this piece of information, because it's not 
obvious.

I agree with Julian that locking semantics require this behavior, and I
agree that it would be reasonable to add this as an explicit 
post-condition
of the REBIND method.  We would then need to add a similar post-condition 
to
the UNBIND method.

> >>> Does REBIND change the ETag of a resource? Does it change the 
> >>> getlastmodified value of the resource?
> >>
> >> Same as MOVE (which means: usually not).
> > 
> > Can't we be more specific about this?
> 
> No, we can't. It *will* be the same as for MOVE, and for MOVE there's no 

> guarantee whatsoever.

That is correct.  If the etags on the rebound (or moved) resources
satisfy etag semantics, the etags can stay the same.  But they might have
to be changed (in case there previously was a resource at the destination
of the REBIND MOVE with that etag but with different content), so you 
can't
infer whether or not the etag changes as the result of a MOVE.

Cheers,
Geoff







From w3c-dist-auth-request@w3.org  Thu Mar 18 16:02:21 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08491
	for <webdav-archive@lists.ietf.org>; Thu, 18 Mar 2004 16:02:16 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id F3B0EA110E; Thu, 18 Mar 2004 16:02:16 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id D0D5FA13F1
	for <w3c-dist-auth@listhub.w3.org>; Thu, 18 Mar 2004 16:02:07 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B44eV-0005nU-HR
	for w3c-dist-auth@w3c.org; Thu, 18 Mar 2004 16:02:07 -0500
Received: from ams-msg-core-1.cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 18 Mar 2004 13:06:54 +0000
Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202])
	by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2IL13ib000738
	for <w3c-dist-auth@w3c.org>; Thu, 18 Mar 2004 22:01:05 +0100 (MET)
Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 18 Mar 2004 22:01:34 +0100
Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(6.0.3790.0);
	 Thu, 18 Mar 2004 22:01:33 +0100
Mime-Version: 1.0 (Apple Message framework v613)
Content-Transfer-Encoding: 7bit
Message-Id: <6F78CBB9-791F-11D8-9B55-000A959CF516@cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: Webdav WG <w3c-dist-auth@w3c.org>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
Date: Thu, 18 Mar 2004 22:01:32 +0100
X-Mailer: Apple Mail (2.613)
X-OriginalArrivalTime: 18 Mar 2004 21:01:33.0816 (UTC) FILETIME=[31C87780:01C40D2C]
Subject: New to the list
X-Archived-At: http://www.w3.org/mid/6F78CBB9-791F-11D8-9B55-000A959CF516@cisco.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8343
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040318210216.F3B0EA110E@frink.w3.org>
Resent-Date: Thu, 18 Mar 2004 16:02:16 -0500 (EST)
Content-Transfer-Encoding: 7bit


As you saw on the message from Jim, I am replacing him as co-chair of 
the webdav wg.

Yes, I was the Apps AD for WebdDav for a while, but you should all be 
aware that I have *NOT* been following the mailing list. I browsed the 
archives a few minutes ago, and will from now on follow this list.

That said, I can also disclose I use WebDav on a daily basis ;-) so I 
know it works. There are some weird things in some 
implementations...but...it works. Not so fun though to try to get SSL 
and WebDav to work. It does not always "just work".

See http://paf.se/openssl/ for a description on how to get things going 
with Apache on FreeBSD as server and MacOSX (and others) as client.

Anyway, I will try to help as much as I can.

      paf



From w3c-dist-auth-request@w3.org  Thu Mar 18 16:38:31 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10183
	for <webdav-archive@lists.ietf.org>; Thu, 18 Mar 2004 16:38:25 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 632E8A1452; Thu, 18 Mar 2004 16:38:27 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id DE250A1452
	for <w3c-dist-auth@listhub.w3.org>; Thu, 18 Mar 2004 16:38:22 -0500 (EST)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B45Da-00071K-Fo
	for w3c-dist-auth@w3.org; Thu, 18 Mar 2004 16:38:22 -0500
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3.org
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i2ILaXIC018352
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Thu, 18 Mar 2004 13:36:35 -0800
In-Reply-To: <20040318084703.1311917671.ejw@cse.ucsc.edu>
References: <20040318084703.1311917671.ejw@cse.ucsc.edu>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <7F70D8A5-7924-11D8-BB68-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: "WebDAV" <w3c-dist-auth@w3.org>, "Ted Hardie" <hardie@qualcomm.com>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Thu, 18 Mar 2004 13:37:47 -0800
To: "Jim Whitehead" <ejw@cse.ucsc.edu>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: Stepping down
X-Archived-At: http://www.w3.org/mid/7F70D8A5-7924-11D8-BB68-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8344
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040318213827.632E8A1452@frink.w3.org>
Resent-Date: Thu, 18 Mar 2004 16:38:27 -0500 (EST)
Content-Transfer-Encoding: 7bit


The WebDAV WG and general WebDAV community owes a huge thank-you to Jim 
and this seems like an appropriate time to do that publicly. Jim led 
the first WebDAV BOF in San Jose in 1996, and gave a presentation [0] 
summarizing the design and coordination work he'd already begun to 
lead.  Since then he's gone beyond being a simple WG chair, supporting 
and encouraging the DeltaV WG, hosting WebDAV Interop events and 
evangelizing in many ways.  He has made significant technical and 
authoring contributions to WebDAV, particularly to the most difficult 
specs like DeltaV and ACL.  If we're smart we'll keep Jim involved as 
much as possible even if not as WG chair.

Lisa

[0] http://www.ietf.org/proceedings/96dec/app/webdav-slides/tsld018.htm

On Mar 18, 2004, at 8:47 AM, Jim Whitehead wrote:

>
> Over the past year it has become increasingly clear that I no longer 
> have enough time to dedicate to the task of effectively leading the 
> WebDAV Working Group. This is perhaps inevitable. When I started the 
> WebDAV Working Group I was a PhD student, and could dedicate 
> significant blocks of time to this project. Now, as an Assistant 
> Professor with 8 PhD students of my own (as well as two small children 
> at home), this is no longer the case. The final straw was me taking on 
> the role of General Chair (organizer) of the ACM Hypertext 2004 
> conference, itself an enormously time consuming volunteer role.
>
> WebDAV Working Group is very close to completing its original 
> technical agenda, a tremendous accomplishment. Many standards 
> development efforts never come close to this, or have the adoption and 
> impact of WebDAV. Still, we do have some final work to complete. There 
> is the bindings specification, and the redirect references protocol. 
> Moving 2518 to Draft Standard is still as important as ever. DASL is 
> already effectively at a Proposed Standard level of adoption, and 
> needs to be finished to ensure greater adoption. WebDAV WG needs a 
> steady hand to bring these to completion, and, alas, that's no longer 
> me.
>
> As a result, effective today, I am stepping down as Co-Chair of the 
> WebDAV Working Group. Ted Hardie, our Applications Area Director, will 
> be appointing Patrik Faltstrom (a former AD of the WebDAV WG) to take 
> my place. Lisa Dusseault will be continuing her excellent work as 
> Co-Chair. I very much encourage you to work with Patrik and Lisa (as 
> will I) to complete the WebDAV agenda.
>
> I still intend to continue contributing to the WebDAV community. 
> Several of my ongoing research projects have a WebDAV aspect to them, 
> including the Catacomb server, and the Prestan performance analysis 
> suite. I will continue to contribute to the webdav.org site, as well 
> as help with additional explanation of the contributions and uses of 
> the protocol. Finally, I also hope to work to interest people in 
> building new protocols on top of WebDAV -- calendaring is one area 
> that seems long overdue. I'm certainly not turning my back on the 
> WebDAV community. Rather I'm acknowledging that I'm no longer the 
> right person to lead protocol development efforts to completion.
>
> - Jim Whitehead
>



From w3c-dist-auth-request@w3.org  Thu Mar 18 16:43:33 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10369
	for <webdav-archive@lists.ietf.org>; Thu, 18 Mar 2004 16:43:33 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id DF685A08A3; Thu, 18 Mar 2004 16:43:33 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 8CF5EA08A3
	for <w3c-dist-auth@listhub.w3.org>; Thu, 18 Mar 2004 16:43:29 -0500 (EST)
Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B45IX-0000qk-3N
	for w3c-dist-auth@w3.org; Thu, 18 Mar 2004 16:43:29 -0500
Received: (qmail 32332 invoked by uid 65534); 18 Mar 2004 21:42:52 -0000
Received: from pD950C387.dip.t-dialin.net (EHLO gmx.de) (217.80.195.135)
  by mail.gmx.net (mp009) with SMTP; 18 Mar 2004 22:42:52 +0100
X-Authenticated: #1915285
Message-ID: <405A17A8.8060601@gmx.de>
Date: Thu, 18 Mar 2004 22:42:00 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Jim Whitehead <ejw@cse.ucsc.edu>, WebDAV <w3c-dist-auth@w3.org>,
        Ted Hardie <hardie@qualcomm.com>
References: <20040318084703.1311917671.ejw@cse.ucsc.edu> <7F70D8A5-7924-11D8-BB68-000A95B2BB72@osafoundation.org>
In-Reply-To: <7F70D8A5-7924-11D8-BB68-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Stepping down
X-Archived-At: http://www.w3.org/mid/405A17A8.8060601@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8345
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040318214333.DF685A08A3@frink.w3.org>
Resent-Date: Thu, 18 Mar 2004 16:43:33 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> 
> The WebDAV WG and general WebDAV community owes a huge thank-you to Jim 
> and this seems like an appropriate time to do that publicly. Jim led the 
> first WebDAV BOF in San Jose in 1996, and gave a presentation [0] 
> summarizing the design and coordination work he'd already begun to 
> lead.  Since then he's gone beyond being a simple WG chair, supporting 
> and encouraging the DeltaV WG, hosting WebDAV Interop events and 
> evangelizing in many ways.  He has made significant technical and 
> authoring contributions to WebDAV, particularly to the most difficult 
> specs like DeltaV and ACL.  If we're smart we'll keep Jim involved as 
> much as possible even if not as WG chair.
> 
> Lisa

Yep.

Thanks Jim for all the work you've done (and you and your students will 
be doing in the future).

And welcome Patrik!


Regards, Julian

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



From w3c-dist-auth-request@w3.org  Thu Mar 18 16:44:59 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10436
	for <webdav-archive@lists.ietf.org>; Thu, 18 Mar 2004 16:44:54 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id D81EBA0789; Thu, 18 Mar 2004 16:44:55 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id AB654A0789
	for <w3c-dist-auth@listhub.w3.org>; Thu, 18 Mar 2004 16:44:51 -0500 (EST)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B45Jr-0001BI-5d
	for w3c-dist-auth@w3c.org; Thu, 18 Mar 2004 16:44:51 -0500
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i2ILgvIC018916
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Thu, 18 Mar 2004 13:43:00 -0800
In-Reply-To: <OF353135F8.6EBA581E-ON85256E5B.006F1A8A-85256E5B.00723892@us.ibm.com>
References: <OF353135F8.6EBA581E-ON85256E5B.006F1A8A-85256E5B.00723892@us.ibm.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <64A6E1E4-7925-11D8-BB68-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Thu, 18 Mar 2004 13:44:11 -0800
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/64A6E1E4-7925-11D8-BB68-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8346
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040318214455.D81EBA0789@frink.w3.org>
Resent-Date: Thu, 18 Mar 2004 16:44:55 -0500 (EST)
Content-Transfer-Encoding: 7bit



On Mar 18, 2004, at 12:47 PM, Geoffrey M Clemm wrote:

>
> Julian wrote on 03/18/2004 01:50:55 PM:
>
>> Lisa Dusseault wrote:
>>
>>> On Mar 18, 2004, at 5:29 AM, Julian Reschke wrote:
>>>
>>>> Lisa Dusseault wrote:
>
>>>>> 2. Clarify that a VCR isn't just another binding (because different
>>>>> VCRs pointing to the same VHR have different live properties, not
>>>>> the  same ones)
>>>>> etc...
>>>>
>>>> As DeltaV doesn't say that, I'm not sure why we would need to 
>>>> clarify
>
>>>> that.
>>>>
>>> I had to do a fair bit of thinking and logical deductions to figure
>>> that out, and I'm fairly experienced in this area.  Let's save
>>> implementors that work and the risk of making an incorrect 
>>> assumption.
>
>>> A bindings section on the relationship of binding to the
>>> resources/properties defined in DeltaV isn't too hard to write.
>>
>> I'm still not sure which part of DeltaV is supposed to be unclear 
>> here.
>> But if there is one, this should be fixed as an RFC3253 erratum.
>
> This is deliberately left as an implementation choices.  For example, 
> on
> one
> of our servers, we do use multiple bindings to a shared resource for
> checked-in VCR's, and then automatically create a new resource on
> checkout.  As long as we satisfy the versioning pre and post 
> conditions,
> we are free to make that choice.  If the spec made the kind of 
> statement
> Lisa is asking for, it would be limiting the implementation choices of
> a provider for no good reason.
>
We don't necessarily have to restrict implementations when we add 
clarifying text.  For example, we could say that "A VCR is more than 
just a binding to a VHR -- it has different properties and state.  
Likewise, two VCRs pointing to the same VHR don't always behave as two 
bindings to the same underlying VCR resource, again because of 
different properties and state in certain circumstances, such as when 
one VCR is checked out."

>>>>> Does REBIND change the ETag of a resource? Does it change the
>>>>> getlastmodified value of the resource?
>>>>
>>>> Same as MOVE (which means: usually not).
>>>
>>> Can't we be more specific about this?
>>
>> No, we can't. It *will* be the same as for MOVE, and for MOVE there's 
>> no
>
>> guarantee whatsoever.
>
> That is correct.  If the etags on the rebound (or moved) resources
> satisfy etag semantics, the etags can stay the same.  But they might 
> have
> to be changed (in case there previously was a resource at the 
> destination
> of the REBIND MOVE with that etag but with different content), so you
> can't
> infer whether or not the etag changes as the result of a MOVE.
>

Why couldn't the source ETag be preserved in a REBIND, even if the 
destination resource is being overwritten?  At the least, the spec 
should say that the source ETag MAY be preserved, so that clients know 
they have to handle both cases.

The getlastmodified is a little more contentious.  Does it mean that 
the underlying resource body changed?  If so, then the spec should say 
that this property SHOULD NOT (or MUST NOT) change only because of a 
REBIND operation.

Lisa



From w3c-dist-auth-request@w3.org  Thu Mar 18 17:33:42 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13208
	for <webdav-archive@lists.ietf.org>; Thu, 18 Mar 2004 17:33:41 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 516FCA0880; Thu, 18 Mar 2004 17:33:43 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id D034BA15DC
	for <w3c-dist-auth@listhub.w3.org>; Thu, 18 Mar 2004 16:59:51 -0500 (EST)
Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B45YN-0004VL-F7
	for w3c-dist-auth@w3c.org; Thu, 18 Mar 2004 16:59:51 -0500
Received: (qmail 24428 invoked by uid 65534); 18 Mar 2004 21:59:11 -0000
Received: from pD950C387.dip.t-dialin.net (EHLO gmx.de) (217.80.195.135)
  by mail.gmx.net (mp007) with SMTP; 18 Mar 2004 22:59:11 +0100
X-Authenticated: #1915285
Message-ID: <405A1B82.6000001@gmx.de>
Date: Thu, 18 Mar 2004 22:58:26 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>,
        Webdav WG <w3c-dist-auth@w3c.org>
References: <OF353135F8.6EBA581E-ON85256E5B.006F1A8A-85256E5B.00723892@us.ibm.com> <64A6E1E4-7925-11D8-BB68-000A95B2BB72@osafoundation.org>
In-Reply-To: <64A6E1E4-7925-11D8-BB68-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/405A1B82.6000001@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8347
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040318223343.516FCA0880@frink.w3.org>
Resent-Date: Thu, 18 Mar 2004 17:33:43 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

>> That is correct.  If the etags on the rebound (or moved) resources
>> satisfy etag semantics, the etags can stay the same.  But they might have
>> to be changed (in case there previously was a resource at the destination
>> of the REBIND MOVE with that etag but with different content), so you
>> can't
>> infer whether or not the etag changes as the result of a MOVE.
>>
> 
> Why couldn't the source ETag be preserved in a REBIND, even if the 
> destination resource is being overwritten?  At the least, the spec 
> should say that the source ETag MAY be preserved, so that clients know 
> they have to handle both cases.

A "MAY" doesn't really help. The issue here is that servers that do have 
ETags that are unique across *all* resources in the namespace will be 
able to preserve them. However, those that use weaker RFC2616 semantics 
(unique per entity body and URL) will have to ensure that namespace 
operations such as COPY or MOVE (or REBIND) will not cause duplicate 
ETags for different entities to appear.

Both types of implementations exist (actually, we have both types within 
the same server).

Now it may make sense to discuss this issue, but it's not related to 
BIND. As I said, REBIND and MOVE share the same considerations here.

> The getlastmodified is a little more contentious.  Does it mean that the 
> underlying resource body changed?  If so, then the spec should say that 
> this property SHOULD NOT (or MUST NOT) change only because of a REBIND 
> operation.

Nope. If anything, the spec should say that REBIND should behave like 
MOVE in this regard.

In particular, I'd lean to SHOULD change, because in general there's no 
other reliable way to maintain RFC2616's semantics for the 
"Last-Modified" header.

Anyway, this issue applies to all WebDAV namespace operations, and we 
have lived with the current under-specification since 1999. Thus having 
it clarified in RFC2518bis should suffice.


Regards, Julian

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



From w3c-dist-auth-request@w3.org  Thu Mar 18 19:05:31 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18272
	for <webdav-archive@lists.ietf.org>; Thu, 18 Mar 2004 19:05:30 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id F3662A0906; Thu, 18 Mar 2004 19:05:32 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 862C2A0906
	for <w3c-dist-auth@listhub.w3.org>; Thu, 18 Mar 2004 19:05:30 -0500 (EST)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B47Vy-0006ix-3x
	for w3c-dist-auth@w3c.org; Thu, 18 Mar 2004 19:05:30 -0500
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: <w3c-dist-auth@w3c.org>
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i2J043IC031785
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <w3c-dist-auth@w3c.org>; Thu, 18 Mar 2004 16:04:04 -0800
Mime-Version: 1.0 (Apple Message framework v613)
Content-Transfer-Encoding: 7bit
Message-Id: <18F94BB3-7939-11D8-BB68-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Thu, 18 Mar 2004 16:05:14 -0800
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Should REBIND preserve locks, other live properties
X-Archived-At: http://www.w3.org/mid/18F94BB3-7939-11D8-BB68-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8348
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040319000532.F3662A0906@frink.w3.org>
Resent-Date: Thu, 18 Mar 2004 19:05:32 -0500 (EST)
Content-Transfer-Encoding: 7bit



In RFC2518, a MOVE operation is supposed to destroy all locks on the 
moved resource and any descendants.  This behavior is unlike most 
filesystems.  Yaron laid out the reasons but they weren't too strong.  
Basically the reasons why not amounted to the fact that some systems 
that didn't support bindings couldn't do this easily.
http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html

I'd assumed that a REBIND was different than MOVE, and couldn't be used 
in as many cases.  If a REBIND is really the same as a MOVE then why 
are we defining it?  If it's different -- e.g. if , as I had assumed, 
REBIND is "safer" and more high-fidelity than MOVE (but can be used in 
fewer cases) then we need to understand how it's different.

If REBIND can be different than MOVE, then we can make a number of 
things work better (more predictable) from a client point of view:
  - locks aren't destroyed, lock token doesn't change, the lock state 
appearing on other bindings doesn't change
  - getlastmodified date doesn't change unless another resource is 
overwritten (for that matter, we could specify that REBIND can't 
overwrite another binding which would make it even simpler), so the 
getlastmodified date on other bindings doesn't change
  - etag doesn't change...
  - live properties have more guarantees in how they are preserved
  - ACLs aren't re-inherited?
  - this makes a "rename" operation work exactly as the client expects 
it would (not the case today with MOVE)

If a server can't implement REBIND -- well, there's still MOVE.

Lisa



From w3c-dist-auth-request@w3.org  Fri Mar 19 04:49:04 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24833
	for <webdav-archive@lists.ietf.org>; Fri, 19 Mar 2004 04:49:03 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 24D56A168D; Fri, 19 Mar 2004 04:49:04 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id E3B40A168D
	for <w3c-dist-auth@listhub.w3.org>; Fri, 19 Mar 2004 04:49:01 -0500 (EST)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B4Gcf-0003wN-Bk
	for w3c-dist-auth@w3c.org; Fri, 19 Mar 2004 04:49:01 -0500
Received: (qmail 9564 invoked by uid 65534); 19 Mar 2004 09:48:24 -0000
Received: from pD950C38F.dip.t-dialin.net (EHLO gmx.de) (217.80.195.143)
  by mail.gmx.net (mp007) with SMTP; 19 Mar 2004 10:48:24 +0100
X-Authenticated: #1915285
Message-ID: <405AC1D7.6040006@gmx.de>
Date: Fri, 19 Mar 2004 10:48:07 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
References: <18F94BB3-7939-11D8-BB68-000A95B2BB72@osafoundation.org>
In-Reply-To: <18F94BB3-7939-11D8-BB68-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Should REBIND preserve locks, other live properties
X-Archived-At: http://www.w3.org/mid/405AC1D7.6040006@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8349
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040319094904.24D56A168D@frink.w3.org>
Resent-Date: Fri, 19 Mar 2004 04:49:04 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> In RFC2518, a MOVE operation is supposed to destroy all locks on the 
> moved resource and any descendants.  This behavior is unlike most 
> filesystems.  Yaron laid out the reasons but they weren't too strong.  
> Basically the reasons why not amounted to the fact that some systems 
> that didn't support bindings couldn't do this easily.
> http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html
> I'd assumed that a REBIND was different than MOVE, and couldn't be used 
> in as many cases.  If a REBIND is really the same as a MOVE then why are 
> we defining it?  If it's different -- e.g. if , as I had assumed, REBIND 

Because RFC2518 allows servers to implement MOVE as COPY/DELETE, and 
BIND can't override that (when it tried, we got complaints from people 
who rely on MOVE working as it does).

> is "safer" and more high-fidelity than MOVE (but can be used in fewer 
> cases) then we need to understand how it's different.
>
> If REBIND can be different than MOVE, then we can make a number of 
> things work better (more predictable) from a client point of view:
>  - locks aren't destroyed, lock token doesn't change, the lock state 
> appearing on other bindings doesn't change

However, the locking model we all agreed on (remember? -> 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0001.html>) 
explicitly says...:

- If a request causes a directly locked resource to no longer be
   mapped to the lock-root of that lock, then the request MUST
   fail unless the lock-token for that lock is submitted in the
   request.  If the request succeeds, then that lock MUST have been
   deleted by that request.

So REBIND behaves exactly as the locking model is predicting it: a 
namespace operation causes the locked resource not being mapped anymore 
to the lock root, and thus the lock is removed.

Changing this would mean that the locking model needs to made more 
complicated (again). In this case, we couldn't talk about namespace 
operations in general, but would need to go back to special cases.

Unless there's a clear benefit from that complication, I vote with "no".

>  - getlastmodified date doesn't change unless another resource is 
> overwritten (for that matter, we could specify that REBIND can't 
> overwrite another binding which would make it even simpler), so the 
> getlastmodified date on other bindings doesn't change

Again, this is incompatible with HTTP semantics for the Last-Modified 
header, please see my other mail 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0108.html>).

>  - etag doesn't change...

Same.

>  - live properties have more guarantees in how they are preserved

Live properties aren't affected except for the unfortunate cases where 
they are. Same behaviour as in RFC2518.

>  - ACLs aren't re-inherited?

If you're talking about 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.html#PROPERTY_inherited-acl-set>: 
no, they aren't.

>  - this makes a "rename" operation work exactly as the client expects it 
> would (not the case today with MOVE)
> 
> If a server can't implement REBIND -- well, there's still MOVE.

Lisa, the issue is that namespace operations in HTTP *can* *not* behave 
as in filesystems as far as HTTP headers such as "Last-Modified" or 
"ETag" are concerned -- this is just incompatible with HTTP, so there's 
no way to require it.

We *can* encourage servers to use "robust" ETags (Etags that are unique 
across all resources in the namespace) and thus don't have conflicts 
with ETags that may have been previously used for the same URL. But 
that's a general rule, not particular to BIND whatsoever, so if you 
think it's worth the effort, add it to RFC2518bis.

Regards, Julian


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



From w3c-dist-auth-request@w3.org  Fri Mar 19 08:34:46 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02534
	for <webdav-archive@lists.ietf.org>; Fri, 19 Mar 2004 08:34:41 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 5913BA16DF; Fri, 19 Mar 2004 08:34:40 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 319E2A16DF
	for <w3c-dist-auth@listhub.w3.org>; Fri, 19 Mar 2004 08:34:35 -0500 (EST)
Received: from e2.ny.us.ibm.com ([32.97.182.102])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B4K8w-0002LS-HS
	for w3c-dist-auth@w3c.org; Fri, 19 Mar 2004 08:34:34 -0500
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2JDY37b074454
	for <w3c-dist-auth@w3c.org>; Fri, 19 Mar 2004 08:34:03 -0500
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2JDY1KH131266
	for <w3c-dist-auth@w3c.org>; Fri, 19 Mar 2004 08:34:01 -0500
In-Reply-To: <405AC1D7.6040006@gmx.de>
To: Webdav WG <w3c-dist-auth@w3c.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF9711D7F6.44D14DBB-ON85256E5C.0048E74C-85256E5C.004A749C@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Fri, 19 Mar 2004 08:33:53 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at
 03/19/2004 08:34:02,
	Serialize complete at 03/19/2004 08:34:02
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: Should REBIND preserve locks, other live properties
X-Archived-At: http://www.w3.org/mid/OF9711D7F6.44D14DBB-ON85256E5C.0048E74C-85256E5C.004A749C@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8350
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040319133440.5913BA16DF@frink.w3.org>
Resent-Date: Fri, 19 Mar 2004 08:34:40 -0500 (EST)


I agree with Julian's responses.

In addition, a client-side motivation for the "delete on MOVE" behavior of
locks is that it simplifies client-side lock management.  When the
client locks a resource, it just adds the request-URL of the lock
and the returned lock token to its list of URL/lock-token pairs.
It knows that that lock-token will be at that URL for the lifetime of
that lock-token.  If locks were not deleted when the protected URL
was unmapped, it is harder for a client to keep track of its locks.

Cheers,
Geoff 


Julian wrote on 03/19/2004 04:48:07 AM:

> Lisa Dusseault wrote:
> 
> > In RFC2518, a MOVE operation is supposed to destroy all locks on the 
> > moved resource and any descendants.  This behavior is unlike most 
> > filesystems.  Yaron laid out the reasons but they weren't too strong. 
> > Basically the reasons why not amounted to the fact that some systems 
> > that didn't support bindings couldn't do this easily.
> > http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html
> > I'd assumed that a REBIND was different than MOVE, and couldn't be 
used 
> > in as many cases.  If a REBIND is really the same as a MOVE then why 
are 
> > we defining it?  If it's different -- e.g. if , as I had assumed, 
REBIND 
> 
> Because RFC2518 allows servers to implement MOVE as COPY/DELETE, and 
> BIND can't override that (when it tried, we got complaints from people 
> who rely on MOVE working as it does).
> 
> > is "safer" and more high-fidelity than MOVE (but can be used in fewer 
> > cases) then we need to understand how it's different.
> >
> > If REBIND can be different than MOVE, then we can make a number of 
> > things work better (more predictable) from a client point of view:
> >  - locks aren't destroyed, lock token doesn't change, the lock state 
> > appearing on other bindings doesn't change
> 
> However, the locking model we all agreed on (remember? -> 
> 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0001.html>) 
> explicitly says...:
> 
> - If a request causes a directly locked resource to no longer be
>    mapped to the lock-root of that lock, then the request MUST
>    fail unless the lock-token for that lock is submitted in the
>    request.  If the request succeeds, then that lock MUST have been
>    deleted by that request.
> 
> So REBIND behaves exactly as the locking model is predicting it: a 
> namespace operation causes the locked resource not being mapped anymore 
> to the lock root, and thus the lock is removed.
> 
> Changing this would mean that the locking model needs to made more 
> complicated (again). In this case, we couldn't talk about namespace 
> operations in general, but would need to go back to special cases.
> 
> Unless there's a clear benefit from that complication, I vote with "no".
> 
> >  - getlastmodified date doesn't change unless another resource is 
> > overwritten (for that matter, we could specify that REBIND can't 
> > overwrite another binding which would make it even simpler), so the 
> > getlastmodified date on other bindings doesn't change
> 
> Again, this is incompatible with HTTP semantics for the Last-Modified 
> header, please see my other mail 
> 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0108.html>).
> 
> >  - etag doesn't change...
> 
> Same.
> 
> >  - live properties have more guarantees in how they are preserved
> 
> Live properties aren't affected except for the unfortunate cases where 
> they are. Same behaviour as in RFC2518.
> 
> >  - ACLs aren't re-inherited?
> 
> If you're talking about 
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.
> html#PROPERTY_inherited-acl-set>: 
> no, they aren't.
> 
> >  - this makes a "rename" operation work exactly as the client expects 
it 
> > would (not the case today with MOVE)
> > 
> > If a server can't implement REBIND -- well, there's still MOVE.
> 
> Lisa, the issue is that namespace operations in HTTP *can* *not* behave 
> as in filesystems as far as HTTP headers such as "Last-Modified" or 
> "ETag" are concerned -- this is just incompatible with HTTP, so there's 
> no way to require it.
> 
> We *can* encourage servers to use "robust" ETags (Etags that are unique 
> across all resources in the namespace) and thus don't have conflicts 
> with ETags that may have been previously used for the same URL. But 
> that's a general rule, not particular to BIND whatsoever, so if you 
> think it's worth the effort, add it to RFC2518bis.
> 
> Regards, Julian
> 
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 



From w3c-dist-auth-request@w3.org  Fri Mar 19 09:12:33 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04063
	for <webdav-archive@lists.ietf.org>; Fri, 19 Mar 2004 09:12:33 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A5A0EA16C4; Fri, 19 Mar 2004 09:12:32 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 63A73A1655
	for <w3c-dist-auth@listhub.w3.org>; Fri, 19 Mar 2004 09:12:26 -0500 (EST)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B4KjY-000487-BJ
	for w3c-dist-auth@w3c.org; Fri, 19 Mar 2004 09:12:24 -0500
Received: (qmail 12273 invoked by uid 65534); 19 Mar 2004 14:11:49 -0000
Received: from p50824F51.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.79.81)
  by mail.gmx.net (mp025) with SMTP; 19 Mar 2004 15:11:49 +0100
X-Authenticated: #1915285
Message-ID: <405AFFA3.5030007@gmx.de>
Date: Fri, 19 Mar 2004 15:11:47 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
References: <OF353135F8.6EBA581E-ON85256E5B.006F1A8A-85256E5B.00723892@us.ibm.com>
In-Reply-To: <OF353135F8.6EBA581E-ON85256E5B.006F1A8A-85256E5B.00723892@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/405AFFA3.5030007@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8351
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040319141232.A5A0EA16C4@frink.w3.org>
Resent-Date: Fri, 19 Mar 2004 09:12:32 -0500 (EST)
Content-Transfer-Encoding: 7bit


Geoffrey M Clemm wrote:

>>OK, now I see. This precondition also exists on BIND (where it makes a 
>>lot of sense), however I'm not sure why we would need it for REBIND. 
>>Geoff, do you remember why it appears here?
> 
> 
> I think it is just an error (resulting from copying all of the BIND
> preconditions to the REBIND method).
> 
> So I think deleting the precondition would be the right thing to do.
> 
> ..

Done. See 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.6_precondition_binding_allowed>

>>>>>Does REBIND destroy locks, as MOVE does? It shouldn't, unless 
>>>>>there's  a compelling reason for backward compatibility.
>>>>
>>>>No, it should. REBIND is a "strong" MOVE (that will never attempt a 
>>>>"weak" resource move using COPY/DELETE). That's the only semantical 
>>>>difference to MOVE, and thus locks behave just like they do with 
> 
> MOVE.
> 
>>>I disagree, but in either case, the spec needs to say this one way or 
>>>another.
>>
>>OK, we may have to add this piece of information, because it's not 
> 
> obvious.
> 
> I agree with Julian that locking semantics require this behavior, and I
> agree that it would be reasonable to add this as an explicit 
> post-condition
> of the REBIND method.  We would then need to add a similar post-condition 
> to
> the UNBIND method.
 > ..

See 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.6_lock_behaviour>.

Can you suggest a specific text?

Regards, Julian

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



From w3c-dist-auth-request@w3.org  Fri Mar 19 14:25:41 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17036
	for <webdav-archive@lists.ietf.org>; Fri, 19 Mar 2004 14:25:36 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 0F3C3A177A; Fri, 19 Mar 2004 14:25:36 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 6BCABA177A
	for <w3c-dist-auth@listhub.w3.org>; Fri, 19 Mar 2004 14:25:33 -0500 (EST)
Received: from e3.ny.us.ibm.com ([32.97.182.103])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B4Pcb-00039f-8n
	for w3c-dist-auth@w3c.org; Fri, 19 Mar 2004 14:25:33 -0500
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2JJOxAB710088
	for <w3c-dist-auth@w3c.org>; Fri, 19 Mar 2004 14:24:59 -0500
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2JJPDxr085402
	for <w3c-dist-auth@w3c.org>; Fri, 19 Mar 2004 14:25:14 -0500
In-Reply-To: <405AFFA3.5030007@gmx.de>
To: Webdav WG <w3c-dist-auth@w3c.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OFF9933575.AF301A7E-ON85256E5C.0069DA11-85256E5C.006AA750@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Fri, 19 Mar 2004 14:24:55 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at
 03/19/2004 14:24:58,
	Serialize complete at 03/19/2004 14:24:58
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/OFF9933575.AF301A7E-ON85256E5C.0069DA11-85256E5C.006AA750@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8352
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040319192536.0F3C3A177A@frink.w3.org>
Resent-Date: Fri, 19 Mar 2004 14:25:36 -0500 (EST)


How about for REBIND:

(DAV:lock-deleted): If the URL specified in the DAV:href element in the 
request body was protected by a write-lock at the time of the request, 
that write-lock must have been deleted by the request.

And something similar for UNBIND.

Cheers,
Geoff

Julian Reschke <julian.reschke@gmx.de> wrote on 03/19/2004 09:11:47 AM:

> >>>>>Does REBIND destroy locks, as MOVE does? It shouldn't, unless 
> >>>>>there's  a compelling reason for backward compatibility.
> >>>>
> >>>>No, it should. REBIND is a "strong" MOVE (that will never attempt a 
> >>>>"weak" resource move using COPY/DELETE). That's the only semantical 
> >>>>difference to MOVE, and thus locks behave just like they do with 
> > 
> > I agree with Julian that locking semantics require this behavior, and 
I
> > agree that it would be reasonable to add this as an explicit 
> > post-condition
> > of the REBIND method.  We would then need to add a similar 
post-condition 
> > to
> > the UNBIND method.
>  > ..
> 
> Can you suggest a specific text?



From w3c-dist-auth-request@w3.org  Sat Mar 20 05:18:46 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04410
	for <webdav-archive@lists.ietf.org>; Sat, 20 Mar 2004 05:18:45 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 7F5ECA093B; Sat, 20 Mar 2004 05:18:45 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 8E17BA0D4E
	for <w3c-dist-auth@listhub.w3.org>; Sat, 20 Mar 2004 05:18:39 -0500 (EST)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B4dVO-0000Ds-26
	for w3c-dist-auth@w3c.org; Sat, 20 Mar 2004 05:15:02 -0500
Received: (qmail 12258 invoked by uid 65534); 20 Mar 2004 10:14:26 -0000
Received: from pD950C386.dip.t-dialin.net (EHLO gmx.de) (217.80.195.134)
  by mail.gmx.net (mp007) with SMTP; 20 Mar 2004 11:14:26 +0100
X-Authenticated: #1915285
Message-ID: <405C196C.1030609@gmx.de>
Date: Sat, 20 Mar 2004 11:14:04 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
References: <OFF9933575.AF301A7E-ON85256E5C.0069DA11-85256E5C.006AA750@us.ibm.com>
In-Reply-To: <OFF9933575.AF301A7E-ON85256E5C.0069DA11-85256E5C.006AA750@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/405C196C.1030609@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8353
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040320101845.7F5ECA093B@frink.w3.org>
Resent-Date: Sat, 20 Mar 2004 05:18:45 -0500 (EST)
Content-Transfer-Encoding: 7bit


Geoffrey M Clemm wrote:

> How about for REBIND:
> 
> (DAV:lock-deleted): If the URL specified in the DAV:href element in the 
> request body was protected by a write-lock at the time of the request, 
> that write-lock must have been deleted by the request.
> 
> And something similar for UNBIND.

OK, here's the change:

UNBIND postcondition:

       (DAV:lock-deleted): If the internal member URI of the binding
       specified by the Request-URI and the DAV:segment element in the
       request body was protected by a write-lock at the time of the
       request, that write-lock must have been deleted by the request.

REBIND postcondition:

       (DAV:lock-deleted): If the URL specified in the DAV:href element
       in the request body was protected by a write-lock at the time of
       the request, that write-lock must have been deleted by the
       request.

(note that for UNBIND the actual URI is composed from request-URI and 
DAV:segment in the request body).


 From Geoff's and my point of view, we have now resolved those issues 
raised by Lisa which indeed warranted a document change. As these 
changes are minor, we *could* proceed with draft 04 as base for the 
working group last call, but of course I can also produce a -05 draft 
early next week and submit that (Opinions?).

Regards, Julian

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



From w3c-dist-auth-request@w3.org  Sun Mar 21 10:22:23 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15567
	for <webdav-archive@lists.ietf.org>; Sun, 21 Mar 2004 10:22:23 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id C347DA0A49; Sun, 21 Mar 2004 10:22:24 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id DAFF5A0A49
	for <w3c-dist-auth@listhub.w3.org>; Sun, 21 Mar 2004 10:22:19 -0500 (EST)
Received: from e3.ny.us.ibm.com ([32.97.182.103])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B54mJ-0006BS-Qk
	for w3c-dist-auth@w3c.org; Sun, 21 Mar 2004 10:22:19 -0500
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2LFLjAB765246
	for <w3c-dist-auth@w3c.org>; Sun, 21 Mar 2004 10:21:48 -0500
Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2LFLhSS136930
	for <w3c-dist-auth@w3c.org>; Sun, 21 Mar 2004 10:21:44 -0500
In-Reply-To: <405C196C.1030609@gmx.de>
To: Webdav WG <w3c-dist-auth@w3c.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Message-ID: <OF9CE0D1B6.D4C3669E-ON85256E5E.0018FFEB-85256E5E.00545211@us.ibm.com>
Date: Sun, 21 Mar 2004 10:21:39 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at
 03/21/2004 10:21:44,
	Serialize complete at 03/21/2004 10:21:44
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/OF9CE0D1B6.D4C3669E-ON85256E5E.0018FFEB-85256E5E.00545211@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8354
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040321152224.C347DA0A49@frink.w3.org>
Resent-Date: Sun, 21 Mar 2004 10:22:24 -0500 (EST)


Either way is OK with me.  If it would take you more than a few minutes
to generate a new revision, I'd just last call the 04 version.

Cheers,
Geoff

Julian Reschke <julian.reschke@gmx.de> wrote on 03/20/2004 05:14:04 AM:

> Geoffrey M Clemm wrote:
> 
> > How about for REBIND:
> > 
> > (DAV:lock-deleted): If the URL specified in the DAV:href element in 
the 
> > request body was protected by a write-lock at the time of the request, 

> > that write-lock must have been deleted by the request.
> > 
> > And something similar for UNBIND.
> 
> OK, here's the change:
> 
> UNBIND postcondition:
> 
>        (DAV:lock-deleted): If the internal member URI of the binding
>        specified by the Request-URI and the DAV:segment element in the
>        request body was protected by a write-lock at the time of the
>        request, that write-lock must have been deleted by the request.
> 
> REBIND postcondition:
> 
>        (DAV:lock-deleted): If the URL specified in the DAV:href element
>        in the request body was protected by a write-lock at the time of
>        the request, that write-lock must have been deleted by the
>        request.
> 
> (note that for UNBIND the actual URI is composed from request-URI and 
> DAV:segment in the request body).
> 
> 
>  From Geoff's and my point of view, we have now resolved those issues 
> raised by Lisa which indeed warranted a document change. As these 
> changes are minor, we *could* proceed with draft 04 as base for the 
> working group last call, but of course I can also produce a -05 draft 
> early next week and submit that (Opinions?).
> 
> Regards, Julian
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Sun Mar 21 10:31:55 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15867
	for <webdav-archive@lists.ietf.org>; Sun, 21 Mar 2004 10:31:55 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id ADC8BA073A; Sun, 21 Mar 2004 10:31:56 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 96D60A073A
	for <w3c-dist-auth@listhub.w3.org>; Sun, 21 Mar 2004 10:31:54 -0500 (EST)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B54va-0008DD-6j
	for w3c-dist-auth@w3c.org; Sun, 21 Mar 2004 10:31:54 -0500
Received: (qmail 27719 invoked by uid 65534); 21 Mar 2004 15:31:20 -0000
Received: from pD950C382.dip.t-dialin.net (EHLO gmx.de) (217.80.195.130)
  by mail.gmx.net (mp008) with SMTP; 21 Mar 2004 16:31:20 +0100
X-Authenticated: #1915285
Message-ID: <405DB533.8070801@gmx.de>
Date: Sun, 21 Mar 2004 16:30:59 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
References: <OF9CE0D1B6.D4C3669E-ON85256E5E.0018FFEB-85256E5E.00545211@us.ibm.com>
In-Reply-To: <OF9CE0D1B6.D4C3669E-ON85256E5E.0018FFEB-85256E5E.00545211@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/405DB533.8070801@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8355
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040321153156.ADC8BA073A@frink.w3.org>
Resent-Date: Sun, 21 Mar 2004 10:31:56 -0500 (EST)
Content-Transfer-Encoding: 7bit


Geoffrey M Clemm wrote:

> Either way is OK with me.  If it would take you more than a few minutes
> to generate a new revision, I'd just last call the 04 version.

In fact, it'll only take a few minutes.  I'll await the feedback of our 
working group chairs...

Regards, Julian


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



From w3c-dist-auth-request@w3.org  Mon Mar 22 11:54:33 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05764
	for <webdav-archive@lists.ietf.org>; Mon, 22 Mar 2004 11:54:32 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A3E11A12BE; Mon, 22 Mar 2004 10:56:50 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 8EF98A12BE
	for <w3c-dist-auth@listhub.w3.org>; Mon, 22 Mar 2004 10:56:48 -0500 (EST)
Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B5Rn3-0003jQ-Ng
	for w3c-dist-auth@w3.org; Mon, 22 Mar 2004 10:56:37 -0500
Received: from [192.168.0.176] (gw.skyrix.com [213.211.192.97])
	by mail.mdlink.net (Postfix) with ESMTP
	id 0DBA02657C2; Mon, 22 Mar 2004 16:55:13 +0100 (CET)
In-Reply-To: <s05ea6d6.083@wh-inet.gmhwh.org>
References: <s05ea6d6.083@wh-inet.gmhwh.org>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <6D9ED86C-7C19-11D8-B1FD-000393BBAFF6@opengroupware.org>
Content-Transfer-Encoding: 7bit
Cc: w3c-dist-auth@w3.org, fchsupport@fch.ldschurch.org
From: Helge Hess <helge.hess@opengroupware.org>
Date: Mon, 22 Mar 2004 16:56:06 +0100
To: "Charlie Smith" <SmithCW@ldschurch.org>
X-Mailer: Apple Mail (2.613)
Subject: Re: Where is an open source example of using webdav  toseamlessly access and version files?
X-Archived-At: http://www.w3.org/mid/6D9ED86C-7C19-11D8-B1FD-000393BBAFF6@opengroupware.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8357
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040322155650.A3E11A12BE@frink.w3.org>
Resent-Date: Mon, 22 Mar 2004 10:56:50 -0500 (EST)
Content-Transfer-Encoding: 7bit


On Mar 22, 2004, at 4:41 PM, Charlie Smith wrote:
> How is this project coming?

<shameless plug>

You can also try the OpenGroupware.org ZideStore server:

   http://www.opengroupware.org/

The more recent versions of ZideStore 1.2 also support WebDAV access to 
documents stored in the groupware server.

</shameless plug>

On the other side installing a complete groupware might be overkill for 
your needs ...

best regards,
   Helge

> Charlie Smith wrote:
>> Is there available anywhere an open source example of using webdav to
> retrieve
>> files through a browser and seemlessly work with them using a client
> application
>> - word perfect or ms word.  Then, be able to save these files with 
>> same type
> of
>> interface one would experience as if saving to local disk?
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org



From w3c-dist-auth-request@w3.org  Mon Mar 22 12:27:56 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07469
	for <webdav-archive@lists.ietf.org>; Mon, 22 Mar 2004 12:27:55 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 73212A1D76; Mon, 22 Mar 2004 10:44:40 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 33B13A1D86
	for <w3c-dist-auth@listhub.w3.org>; Mon, 22 Mar 2004 10:44:38 -0500 (EST)
Received: from frink.w3.org ([18.29.1.71])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B5RbS-0001pq-2d
	for w3c-dist-auth@w3.org; Mon, 22 Mar 2004 10:44:38 -0500
Received: from mail.gmhwh.org (mail.gmhwh.org [12.110.19.37])
	by frink.w3.org (Postfix) with ESMTP id 856DFA1D86
	for <w3c-dist-auth@w3.org>; Mon, 22 Mar 2004 10:44:37 -0500 (EST)
Received: from 192.168.8.246 by mail.gmhwh.org with ESMTP (<SMTP Relay>
 (MMS v5.5.3)); Mon, 22 Mar 2004 08:45:39 -0600
Received: from WH-INET-MTA by wh-inet.gmhwh.org with Novell_GroupWise;
 Mon, 22 Mar 2004 08:41:58 -0700
Message-ID: <s05ea6d6.083@wh-inet.gmhwh.org>
X-Mailer: Novell GroupWise Internet Agent 6.5.1
Date: Mon, 22 Mar 2004 08:41:44 -0700
From: "Charlie Smith" <SmithCW@ldschurch.org>
To: michael.borko@tgm.ac.at, w3c-dist-auth@w3.org
Cc: fchsupport@fch.ldschurch.org
MIME-Version: 1.0
X-WSS-ID: 6C41D5A9731163-01-01
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: Where is an open source example of using webdav  toseamlessly access and version files?
X-Archived-At: http://www.w3.org/mid/s05ea6d6.083@wh-inet.gmhwh.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8356
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040322154440.73212A1D76@frink.w3.org>
Resent-Date: Mon, 22 Mar 2004 10:44:40 -0500 (EST)
Content-Transfer-Encoding: 7bit



How is this project coming?

>>> "Michael Borko"  2/24/2004 11:29:23 AM >>>

Charlie Smith wrote:
> Is there available anywhere an open source example of using webdav to
retrieve
> files through a browser and seemlessly work with them using a client
application
> - word perfect or ms word.  Then, be able to save these files with same type
of
> interface one would experience as if saving to local disk?
> 
> 


there will be ... in one week!

worked on it for my bacc.work on university - now I have to join the 
code with the CVS from Group-Office (group-office.sf.net) ... so, if you 
are patient, you can see it in less than one week!

If you can't wait, I can give you an account on the test-server for now...

regards, mike





From w3c-dist-auth-request@w3.org  Mon Mar 22 15:12:24 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16987
	for <webdav-archive@lists.ietf.org>; Mon, 22 Mar 2004 15:12:23 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 68E5EA1CF0; Mon, 22 Mar 2004 15:12:23 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 39B69A1CE4
	for <w3c-dist-auth@listhub.w3.org>; Mon, 22 Mar 2004 15:12:16 -0500 (EST)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B5VmM-0006DY-Fe
	for w3c-dist-auth@w3c.org; Mon, 22 Mar 2004 15:12:10 -0500
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i2MK8rIC014810
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 22 Mar 2004 12:08:56 -0800
In-Reply-To: <405C196C.1030609@gmx.de>
References: <OFF9933575.AF301A7E-ON85256E5C.0069DA11-85256E5C.006AA750@us.ibm.com> <405C196C.1030609@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <E80FC418-7C3C-11D8-BB68-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>,
        Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 22 Mar 2004 12:10:04 -0800
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/E80FC418-7C3C-11D8-BB68-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8358
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040322201223.68E5EA1CF0@frink.w3.org>
Resent-Date: Mon, 22 Mar 2004 15:12:23 -0500 (EST)
Content-Transfer-Encoding: 7bit


This is definitely an improvement.  However, I still  have some issues 
-- the interaction between bindings and locks is still unclear.  The 
spec needs to clearly say that
  - if one binding is locked, then every binding is locked (with the 
same lock token)
  - All bindings to the same resource MUST support the same features 
(e.g. locking)
  - All bindings to the same resource MUST show the same values for live 
properties defined in RFC2518, RFC3253, RFC3648 and the ACL RFC.

Unless my understanding of the intent is wrong...?  In which case, it 
needs to clarify some other way.

Lisa

On Mar 20, 2004, at 2:14 AM, Julian Reschke wrote:

>
> Geoffrey M Clemm wrote:
>
>> How about for REBIND:
>> (DAV:lock-deleted): If the URL specified in the DAV:href element in 
>> the request body was protected by a write-lock at the time of the 
>> request, that write-lock must have been deleted by the request.
>> And something similar for UNBIND.
>
> OK, here's the change:
>
> UNBIND postcondition:
>
>       (DAV:lock-deleted): If the internal member URI of the binding
>       specified by the Request-URI and the DAV:segment element in the
>       request body was protected by a write-lock at the time of the
>       request, that write-lock must have been deleted by the request.
>
> REBIND postcondition:
>
>       (DAV:lock-deleted): If the URL specified in the DAV:href element
>       in the request body was protected by a write-lock at the time of
>       the request, that write-lock must have been deleted by the
>       request.
>
> (note that for UNBIND the actual URI is composed from request-URI and 
> DAV:segment in the request body).
>
>
> From Geoff's and my point of view, we have now resolved those issues 
> raised by Lisa which indeed warranted a document change. As these 
> changes are minor, we *could* proceed with draft 04 as base for the 
> working group last call, but of course I can also produce a -05 draft 
> early next week and submit that (Opinions?).
>
> Regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>



From w3c-dist-auth-request@w3.org  Mon Mar 22 15:15:34 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17420
	for <webdav-archive@lists.ietf.org>; Mon, 22 Mar 2004 15:15:33 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 3A166A0636; Mon, 22 Mar 2004 15:15:33 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 3BC9AA09E6
	for <w3c-dist-auth@listhub.w3.org>; Mon, 22 Mar 2004 15:15:28 -0500 (EST)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B5VpV-00070E-Qq
	for w3c-dist-auth@w3c.org; Mon, 22 Mar 2004 15:15:25 -0500
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i2MKDVIC015060
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 22 Mar 2004 12:13:35 -0800
In-Reply-To: <OF9711D7F6.44D14DBB-ON85256E5C.0048E74C-85256E5C.004A749C@us.ibm.com>
References: <OF9711D7F6.44D14DBB-ON85256E5C.0048E74C-85256E5C.004A749C@us.ibm.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <907584BA-7C3D-11D8-BB68-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 22 Mar 2004 12:14:46 -0800
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: Should REBIND preserve locks, other live properties
X-Archived-At: http://www.w3.org/mid/907584BA-7C3D-11D8-BB68-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8359
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040322201533.3A166A0636@frink.w3.org>
Resent-Date: Mon, 22 Mar 2004 15:15:33 -0500 (EST)
Content-Transfer-Encoding: 7bit


So if REBIND is the same as MOVE in all cases, why are we defining it?

I reject the argument that this behavior is needed for REBIND as well  
as MOVE for client convenience.  MOVE would remain as defined for  
clients that want the convenience of keeping URL/Lock-token pairs  
unchanged.  A new method, like RENAME, could provide clients a  
completely optional method with different convenience tradeoffs: the  
convenience of not having to issue a new LOCK request if further  
resource changes are required, etc.  That's what I thought the original  
intent of REBIND was.

Lisa

On Mar 19, 2004, at 5:33 AM, Geoffrey M Clemm wrote:

>
> I agree with Julian's responses.
>
> In addition, a client-side motivation for the "delete on MOVE"  
> behavior of
> locks is that it simplifies client-side lock management.  When the
> client locks a resource, it just adds the request-URL of the lock
> and the returned lock token to its list of URL/lock-token pairs.
> It knows that that lock-token will be at that URL for the lifetime of
> that lock-token.  If locks were not deleted when the protected URL
> was unmapped, it is harder for a client to keep track of its locks.
>
> Cheers,
> Geoff
>
>
> Julian wrote on 03/19/2004 04:48:07 AM:
>
>> Lisa Dusseault wrote:
>>
>>> In RFC2518, a MOVE operation is supposed to destroy all locks on the
>>> moved resource and any descendants.  This behavior is unlike most
>>> filesystems.  Yaron laid out the reasons but they weren't too strong.
>>> Basically the reasons why not amounted to the fact that some systems
>>> that didn't support bindings couldn't do this easily.
>>> http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/ 
>>> 0177.html
>>> I'd assumed that a REBIND was different than MOVE, and couldn't be
> used
>>> in as many cases.  If a REBIND is really the same as a MOVE then why
> are
>>> we defining it?  If it's different -- e.g. if , as I had assumed,
> REBIND
>>
>> Because RFC2518 allows servers to implement MOVE as COPY/DELETE, and
>> BIND can't override that (when it tried, we got complaints from people
>> who rely on MOVE working as it does).
>>
>>> is "safer" and more high-fidelity than MOVE (but can be used in fewer
>>> cases) then we need to understand how it's different.
>>>
>>> If REBIND can be different than MOVE, then we can make a number of
>>> things work better (more predictable) from a client point of view:
>>>  - locks aren't destroyed, lock token doesn't change, the lock state
>>> appearing on other bindings doesn't change
>>
>> However, the locking model we all agreed on (remember? ->
>>
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/ 
> 0001.html>)
>> explicitly says...:
>>
>> - If a request causes a directly locked resource to no longer be
>>    mapped to the lock-root of that lock, then the request MUST
>>    fail unless the lock-token for that lock is submitted in the
>>    request.  If the request succeeds, then that lock MUST have been
>>    deleted by that request.
>>
>> So REBIND behaves exactly as the locking model is predicting it: a
>> namespace operation causes the locked resource not being mapped  
>> anymore
>> to the lock root, and thus the lock is removed.
>>
>> Changing this would mean that the locking model needs to made more
>> complicated (again). In this case, we couldn't talk about namespace
>> operations in general, but would need to go back to special cases.
>>
>> Unless there's a clear benefit from that complication, I vote with  
>> "no".
>>
>>>  - getlastmodified date doesn't change unless another resource is
>>> overwritten (for that matter, we could specify that REBIND can't
>>> overwrite another binding which would make it even simpler), so the
>>> getlastmodified date on other bindings doesn't change
>>
>> Again, this is incompatible with HTTP semantics for the Last-Modified
>> header, please see my other mail
>>
> (<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/ 
> 0108.html>).
>>
>>>  - etag doesn't change...
>>
>> Same.
>>
>>>  - live properties have more guarantees in how they are preserved
>>
>> Live properties aren't affected except for the unfortunate cases where
>> they are. Same behaviour as in RFC2518.
>>
>>>  - ACLs aren't re-inherited?
>>
>> If you're talking about
>> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.
>> html#PROPERTY_inherited-acl-set>:
>> no, they aren't.
>>
>>>  - this makes a "rename" operation work exactly as the client expects
> it
>>> would (not the case today with MOVE)
>>>
>>> If a server can't implement REBIND -- well, there's still MOVE.
>>
>> Lisa, the issue is that namespace operations in HTTP *can* *not*  
>> behave
>> as in filesystems as far as HTTP headers such as "Last-Modified" or
>> "ETag" are concerned -- this is just incompatible with HTTP, so  
>> there's
>> no way to require it.
>>
>> We *can* encourage servers to use "robust" ETags (Etags that are  
>> unique
>> across all resources in the namespace) and thus don't have conflicts
>> with ETags that may have been previously used for the same URL. But
>> that's a general rule, not particular to BIND whatsoever, so if you
>> think it's worth the effort, add it to RFC2518bis.
>>
>> Regards, Julian
>>
>>
>> -- 
>> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>>
>



From w3c-dist-auth-request@w3.org  Mon Mar 22 15:27:34 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18609
	for <webdav-archive@lists.ietf.org>; Mon, 22 Mar 2004 15:27:33 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 85A4CA08FA; Mon, 22 Mar 2004 15:27:33 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id E4DD7A1AC6
	for <w3c-dist-auth@listhub.w3.org>; Mon, 22 Mar 2004 15:27:28 -0500 (EST)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B5W19-0000cP-4d
	for w3c-dist-auth@w3c.org; Mon, 22 Mar 2004 15:27:27 -0500
Received: (qmail 27372 invoked by uid 65534); 22 Mar 2004 20:26:47 -0000
Received: from pD950C393.dip.t-dialin.net (EHLO gmx.de) (217.80.195.147)
  by mail.gmx.net (mp022) with SMTP; 22 Mar 2004 21:26:47 +0100
X-Authenticated: #1915285
Message-ID: <405F4BD5.5070302@gmx.de>
Date: Mon, 22 Mar 2004 21:25:57 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>,
        Webdav WG <w3c-dist-auth@w3c.org>
References: <OFF9933575.AF301A7E-ON85256E5C.0069DA11-85256E5C.006AA750@us.ibm.com> <405C196C.1030609@gmx.de> <E80FC418-7C3C-11D8-BB68-000A95B2BB72@osafoundation.org>
In-Reply-To: <E80FC418-7C3C-11D8-BB68-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/405F4BD5.5070302@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8360
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040322202733.85A4CA08FA@frink.w3.org>
Resent-Date: Mon, 22 Mar 2004 15:27:33 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> This is definitely an improvement.  However, I still  have some issues 
> -- the interaction between bindings and locks is still unclear.  The 
> spec needs to clearly say that
>  - if one binding is locked, then every binding is locked (with the same 
> lock token)

No, the bindings aren't locked, the *resource* is (RFC2518).

>  - All bindings to the same resource MUST support the same features 
> (e.g. locking)

The bindings themselves do not support anything; the resource they are 
mapped to do. As they are mapped to the same resource, the same features 
are available.

>  - All bindings to the same resource MUST show the same values for live 
> properties defined in RFC2518, RFC3253, RFC3648 and the ACL RFC.

Same. You're communicating with the resource, not particular bindings.

> Unless my understanding of the intent is wrong...?  In which case, it 
> needs to clarify some other way.

I'd say all of this follows from section 1, paragraphs 4 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-04.html#rfc.section.1.p.4>) 
to 6:

"The BIND method defined here provides a mechanism for allowing clients 
to create alternative access paths to existing WebDAV resources. HTTP 
[RFC2616] and WebDAV [RFC2518]  methods are able to work because there 
are mappings between URIs and resources. A method is addressed to a URI, 
and the server follows the mapping from that URI to a resource, applying 
the method to that resource. Multiple URIs may be mapped to the same 
resource, but until now there has been no way for clients to create 
additional URIs mapped to existing resources.

BIND lets clients associate a new URI with an existing WebDAV resource, 
and this URI can then be used to submit requests to the resource. Since 
URIs of WebDAV resources are hierarchical, and correspond to a hierarchy 
of collections in resource space, the BIND method also has the effect of 
adding the resource to a collection. As new URIs are associated with the 
resource, it appears in additional collections.

A BIND request does not create a new resource, but simply makes 
available a new URI for submitting requests to an existing resource. The 
new URI is indistinguishable from any other URI when submitting a 
request to a resource. Only one round trip is needed to submit a request 
to the intended target. Servers are required to enforce the integrity of 
the relationships between the new URIs and the resources associated with 
them. Consequently, it may be very costly for servers to support BIND 
requests that cross server boundaries."

At this point I really don't know how to improve that description 
(except by adding "we mean it -- it's really just another name mapped to 
the same resource" :-). If you think that this introduction needs to be 
improved, please make a concrete proposal.

Does anybody else feel that this is unclear?


Regards. Julian

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



From w3c-dist-auth-request@w3.org  Mon Mar 22 15:32:50 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18887
	for <webdav-archive@lists.ietf.org>; Mon, 22 Mar 2004 15:32:50 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 26B56A1CEC; Mon, 22 Mar 2004 15:32:50 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 99AE4A1CF7
	for <w3c-dist-auth@listhub.w3.org>; Mon, 22 Mar 2004 15:32:44 -0500 (EST)
Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B5W6F-0001ee-Sh
	for w3c-dist-auth@w3c.org; Mon, 22 Mar 2004 15:32:44 -0500
Received: (qmail 9503 invoked by uid 65534); 22 Mar 2004 20:32:06 -0000
Received: from pD950C393.dip.t-dialin.net (EHLO gmx.de) (217.80.195.147)
  by mail.gmx.net (mp015) with SMTP; 22 Mar 2004 21:32:06 +0100
X-Authenticated: #1915285
Message-ID: <405F4D11.7060608@gmx.de>
Date: Mon, 22 Mar 2004 21:31:13 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>,
        Webdav WG <w3c-dist-auth@w3c.org>
References: <OF9711D7F6.44D14DBB-ON85256E5C.0048E74C-85256E5C.004A749C@us.ibm.com> <907584BA-7C3D-11D8-BB68-000A95B2BB72@osafoundation.org>
In-Reply-To: <907584BA-7C3D-11D8-BB68-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Should REBIND preserve locks, other live properties
X-Archived-At: http://www.w3.org/mid/405F4D11.7060608@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8361
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040322203250.26B56A1CEC@frink.w3.org>
Resent-Date: Mon, 22 Mar 2004 15:32:50 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:
> 
> So if REBIND is the same as MOVE in all cases, why are we defining it?

It isn't 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-04.html#METHOD_REBIND>):

"The REBIND method removes a binding to a resource from one collection, 
and adds a binding to that resource into another collection. It is 
effectively an atomic form of a MOVE request."

> I reject the argument that this behavior is needed for REBIND as well  
> as MOVE for client convenience.  MOVE would remain as defined for  
> clients that want the convenience of keeping URL/Lock-token pairs  
> unchanged.  A new method, like RENAME, could provide clients a  
> completely optional method with different convenience tradeoffs: the  
> convenience of not having to issue a new LOCK request if further  
> resource changes are required, etc.  That's what I thought the original  
> intent of REBIND was.

Well, it isn't. If you feel that there should be a method allowing 
namespace manipulation while maintaining locks, you're free to work on 
it (I may even be interested on supporting it, once it's defined).

But this wasn't on the requirements list for BIND, and IMHO nobody has 
asked for it recently, so it doesn't belong into BIND. It's a completely 
separate issue.

Regards, Julian

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



From w3c-dist-auth-request@w3.org  Mon Mar 22 16:54:55 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27366
	for <webdav-archive@lists.ietf.org>; Mon, 22 Mar 2004 16:54:54 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 27918A0C92; Mon, 22 Mar 2004 16:54:52 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 5077EA0C92
	for <w3c-dist-auth@listhub.w3.org>; Mon, 22 Mar 2004 16:54:49 -0500 (EST)
Received: from natsmtp01.rzone.de ([81.169.145.166])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B5XNg-00008I-SX
	for w3c-dist-auth@w3.org; Mon, 22 Mar 2004 16:54:49 -0500
Received: from x.oberon.ethz.ch (p5083CE8F.dip0.t-ipconnect.de [80.131.206.143])
	by post.webmailer.de (8.12.10/8.12.10) with SMTP id i2MLsklG001596;
	Mon, 22 Mar 2004 22:54:46 +0100 (MET)
Date: Mon, 22 Mar 2004 22:54:46 +0100 (MET)
Message-Id: <200403222154.i2MLsklG001596@post.webmailer.de>
From: edgar@edgarschwarz.de
X-Mailer: Oberon Mail (ejz) on Aos 20.02.2004
To: w3c-dist-auth@w3.org
Cc: edgar@edgarschwarz.de
Subject: Re (2): Where is an example of using webdav seamlessly...and version files?
X-Archived-At: http://www.w3.org/mid/200403222154.i2MLsklG001596@post.webmailer.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8362
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040322215452.27918A0C92@frink.w3.org>
Resent-Date: Mon, 22 Mar 2004 16:54:52 -0500 (EST)


Charlie Smith wrote:
> Is there available anywhere an open source example of using webdav to retrieve
> files through a browser and seemlessly work with them using a client
> application - word perfect or ms word.  Then, be able to save these files with
> same type of interface one would experience as if saving to local disk?
Here I want to repeat my question again.
Suppose I edit a WebDAV file with my application.
- Now I want to save it. In a "normal" application I have "save" and "save as".
- With a WebDAV file I guess I have "save local", "save on server", "save local as"
  and "save on server as".
- I think "save local as" doesn't make that much sense and can be dropped.
- This leaves me with three choices. One should be default and be called save.
- So my idea is to have "save", "save WebDAV" and "save WebDAV as" which means
  a simple "save" means saving local. This could be fine for people with a slow
  server connection.
So do you think this sounds right for a user ?
Would you prefer other names or choices for saving ?
I know this isn't something the spec should say but nevertheless it would be nice
if users would have similar menu items for saving in their upcoming WebDAV empowered
applications. 
BTW for versioning I have at the moment in a directory window the following
menu items and subitems:
- Version Do
  - Checkin  (Which does a VERSION-CONTROL, BASELINE-CONTROL or CHECKIN depending
    on it's target)
  - Uncheckout
  - Checkout
  - Update
- Version Report
  - Version (For a resource or a configuration)
  - History (For a resource or a configuration)
  - Baseline Compare
Naturally most of these points also can be added to an editor menu. Also there
could be one versioning menu.

Cheers, Edgar



From w3c-dist-auth-request@w3.org  Tue Mar 23 10:55:00 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05225
	for <webdav-archive@lists.ietf.org>; Tue, 23 Mar 2004 10:55:00 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id F3274A052E; Tue, 23 Mar 2004 10:54:56 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 82D42A052E
	for <w3c-dist-auth@listhub.w3.org>; Tue, 23 Mar 2004 10:54:52 -0500 (EST)
Received: from e6.ny.us.ibm.com ([32.97.182.106])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B5oEW-0002lR-8L
	for w3c-dist-auth@w3.org; Tue, 23 Mar 2004 10:54:28 -0500
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2NFrv4i474648
	for <w3c-dist-auth@w3.org>; Tue, 23 Mar 2004 10:53:57 -0500
Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2NFsDad088806
	for <w3c-dist-auth@w3.org>; Tue, 23 Mar 2004 10:54:13 -0500
In-Reply-To: <200403222154.i2MLsklG001596@post.webmailer.de>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OFC44A1393.00B0BFE3-ON85256E60.0056F41B-85256E60.005745A6@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Tue, 23 Mar 2004 10:53:54 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at
 03/23/2004 10:53:56,
	Serialize complete at 03/23/2004 10:53:56
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: Re (2): Where is an example of using webdav seamlessly...and version  files?
X-Archived-At: http://www.w3.org/mid/OFC44A1393.00B0BFE3-ON85256E60.0056F41B-85256E60.005745A6@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8363
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040323155456.F3274A052E@frink.w3.org>
Resent-Date: Tue, 23 Mar 2004 10:54:56 -0500 (EST)


I'd suggest just using "save" and "save as" to mean "save local"
and "save local as" and have "checkin" mean "save to the server
(and create a new version if the server supports versioning)".

Cheers,
Geoff

Edgar wrote on 03/22/2004 04:54:46 PM:

> Suppose I edit a WebDAV file with my application.
> - Now I want to save it. In a "normal" application I have "save" 
and"save as".
> - With a WebDAV file I guess I have "save local", "save on server", 
> "save local as"
>   and "save on server as".
> - I think "save local as" doesn't make that much sense and can be 
dropped.
> - This leaves me with three choices. One should be default and be called 
save.
> - So my idea is to have "save", "save WebDAV" and "save WebDAV as" which 
means
>   a simple "save" means saving local. This could be fine for people 
> with a slow
>   server connection.
> So do you think this sounds right for a user ?
> Would you prefer other names or choices for saving ?
> I know this isn't something the spec should say but nevertheless it 
> would be nice
> if users would have similar menu items for saving in their upcoming 
> WebDAV empowered
> applications. 
> BTW for versioning I have at the moment in a directory window the 
following
> menu items and subitems:
> - Version Do
>   - Checkin  (Which does a VERSION-CONTROL, BASELINE-CONTROL or 
> CHECKIN depending
>     on it's target)
>   - Uncheckout
>   - Checkout
>   - Update
> - Version Report
>   - Version (For a resource or a configuration)
>   - History (For a resource or a configuration)
>   - Baseline Compare
> Naturally most of these points also can be added to an editor menu. Also 
there
> could be one versioning menu.
> 
> Cheers, Edgar
> 



From w3c-dist-auth-request@w3.org  Tue Mar 23 11:13:03 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06698
	for <webdav-archive@lists.ietf.org>; Tue, 23 Mar 2004 11:13:01 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E8BF6A0D54; Tue, 23 Mar 2004 11:13:01 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id BFE87A0D54
	for <w3c-dist-auth@listhub.w3.org>; Tue, 23 Mar 2004 11:12:58 -0500 (EST)
Received: from e3.ny.us.ibm.com ([32.97.182.103])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B5oWM-0007ix-BH
	for w3c-dist-auth@w3c.org; Tue, 23 Mar 2004 11:12:54 -0500
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2NGCIAB665180
	for <w3c-dist-auth@w3c.org>; Tue, 23 Mar 2004 11:12:19 -0500
Received: from d01ml261.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2NGCYad103778
	for <w3c-dist-auth@w3c.org>; Tue, 23 Mar 2004 11:12:35 -0500
In-Reply-To: <405F4D11.7060608@gmx.de>
To: Webdav WG <w3c-dist-auth@w3c.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OFF34CFD9F.C7037E91-ON85256E60.0058B48A-85256E60.0058F3F9@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Tue, 23 Mar 2004 11:12:16 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at
 03/23/2004 11:12:17,
	Serialize complete at 03/23/2004 11:12:17
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: Should REBIND preserve locks, other live properties
X-Archived-At: http://www.w3.org/mid/OFF34CFD9F.C7037E91-ON85256E60.0058B48A-85256E60.0058F3F9@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8364
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040323161301.E8BF6A0D54@frink.w3.org>
Resent-Date: Tue, 23 Mar 2004 11:13:01 -0500 (EST)


I agree with Julian that point of REBIND/UNBIND is (and has always been)
to define an atomic form of MOVE/DELETE.

The only point at which we differ is that he might be interested in
supporting a lock-preserving RENAME method, while I am not (:-).

Cheers,
Geoff

Julian Reschke <julian.reschke@gmx.de> wrote on 03/22/2004 03:31:13 PM:

> Lisa Dusseault wrote:
> > 
> > So if REBIND is the same as MOVE in all cases, why are we defining it?
> 
> It isn't 
> (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-04.
> html#METHOD_REBIND>):
> 
> "The REBIND method removes a binding to a resource from one collection, 
> and adds a binding to that resource into another collection. It is 
> effectively an atomic form of a MOVE request."
> 
> > I reject the argument that this behavior is needed for REBIND as well 
> > as MOVE for client convenience.  MOVE would remain as defined for 
> > clients that want the convenience of keeping URL/Lock-token pairs 
> > unchanged.  A new method, like RENAME, could provide clients a 
> > completely optional method with different convenience tradeoffs: the 
> > convenience of not having to issue a new LOCK request if further 
> > resource changes are required, etc.  That's what I thought the 
original 
> > intent of REBIND was.
> 
> Well, it isn't. If you feel that there should be a method allowing 
> namespace manipulation while maintaining locks, you're free to work on 
> it (I may even be interested on supporting it, once it's defined).
> 
> But this wasn't on the requirements list for BIND, and IMHO nobody has 
> asked for it recently, so it doesn't belong into BIND. It's a completely 

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



From w3c-dist-auth-request@w3.org  Tue Mar 23 11:25:06 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07852
	for <webdav-archive@lists.ietf.org>; Tue, 23 Mar 2004 11:25:05 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 1F4DFA05F1; Tue, 23 Mar 2004 11:25:05 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 74D6FA05F1
	for <w3c-dist-auth@listhub.w3.org>; Tue, 23 Mar 2004 11:25:02 -0500 (EST)
Received: from mail2.gmhwh.org ([12.110.19.38] helo=mail.gmhwh.org)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B5ohq-0002MM-0M
	for w3c-dist-auth@w3.org; Tue, 23 Mar 2004 11:24:46 -0500
Received: from 192.168.8.246 by mail.gmhwh.org with ESMTP (<SMTP Relay>
 (MMS v5.5.3)); Tue, 23 Mar 2004 09:27:13 -0600
Received: from WH-INET-MTA by wh-inet.gmhwh.org with Novell_GroupWise;
 Tue, 23 Mar 2004 09:23:45 -0700
Message-ID: <s0600221.048@wh-inet.gmhwh.org>
X-Mailer: Novell GroupWise Internet Agent 6.5.1
Date: Tue, 23 Mar 2004 09:23:30 -0700
From: "Charlie Smith" <SmithCW@ldschurch.org>
To: dav-dev@lyra.org, w3c-dist-auth@w3.org
MIME-Version: 1.0
X-WSS-ID: 6C7EBAEB668386-01-01
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: Re (2): Where is an example of using webdavseamlessly...and  version files?
X-Archived-At: http://www.w3.org/mid/s0600221.048@wh-inet.gmhwh.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8365
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040323162505.1F4DFA05F1@frink.w3.org>
Resent-Date: Tue, 23 Mar 2004 11:25:05 -0500 (EST)
Content-Transfer-Encoding: 7bit


Wouldn't this type of functionality - prescribing menu items for saving - be
something each application vendor has to do.  IE.  Doesn't Billy Gates need to
add this feature to his File|Save As menu item in MS Word and ditto for Word
Perfect?    So, I guess another question would be - aren't we really dependent
on major word processor application vendors to implement a webdav solution,
before this seemless stuff will really happen?

>>> "Geoffrey M Clemm" <geoffrey.clemm@us.ibm.com> 3/23/2004 8:53:54 AM >>>

I'd suggest just using "save" and "save as" to mean "save local"
and "save local as" and have "checkin" mean "save to the server
(and create a new version if the server supports versioning)".

Cheers,
Geoff

Edgar wrote on 03/22/2004 04:54:46 PM:

> Suppose I edit a WebDAV file with my application.
> - Now I want to save it. In a "normal" application I have "save" 
and"save as".
> - With a WebDAV file I guess I have "save local", "save on server", 
> "save local as"
>   and "save on server as".
> - I think "save local as" doesn't make that much sense and can be 
dropped.
> - This leaves me with three choices. One should be default and be called 
save.
> - So my idea is to have "save", "save WebDAV" and "save WebDAV as" which 
means
>   a simple "save" means saving local. This could be fine for people 
> with a slow
>   server connection.
> So do you think this sounds right for a user ?
> Would you prefer other names or choices for saving ?
> I know this isn't something the spec should say but nevertheless it 
> would be nice
> if users would have similar menu items for saving in their upcoming 
> WebDAV empowered
> applications. 
> BTW for versioning I have at the moment in a directory window the 
following
> menu items and subitems:
> - Version Do
>   - Checkin  (Which does a VERSION-CONTROL, BASELINE-CONTROL or 
> CHECKIN depending
>     on it's target)
>   - Uncheckout
>   - Checkout
>   - Update
> - Version Report
>   - Version (For a resource or a configuration)
>   - History (For a resource or a configuration)
>   - Baseline Compare
> Naturally most of these points also can be added to an editor menu. Also 
there
> could be one versioning menu.
> 
> Cheers, Edgar
> 





From w3c-dist-auth-request@w3.org  Tue Mar 23 11:32:02 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08671
	for <webdav-archive@lists.ietf.org>; Tue, 23 Mar 2004 11:32:00 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id F09C1A0625; Tue, 23 Mar 2004 11:31:50 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 2B383A0625
	for <w3c-dist-auth@listhub.w3.org>; Tue, 23 Mar 2004 11:31:49 -0500 (EST)
Received: from mail.gmhwh.org ([12.110.19.37])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B5ooQ-0003yh-1B
	for w3c-dist-auth@w3.org; Tue, 23 Mar 2004 11:31:34 -0500
Received: from 192.168.8.246 by mail.gmhwh.org with ESMTP (<SMTP Relay>
 (MMS v5.5.3)); Tue, 23 Mar 2004 09:34:11 -0600
Received: from WH-INET-MTA by wh-inet.gmhwh.org with Novell_GroupWise;
 Tue, 23 Mar 2004 09:30:42 -0700
Message-ID: <s06003c2.028@wh-inet.gmhwh.org>
X-Mailer: Novell GroupWise Internet Agent 6.5.1
Date: Tue, 23 Mar 2004 09:30:23 -0700
From: "Charlie Smith" <SmithCW@ldschurch.org>
To: geoffrey.clemm@us.ibm.com, w3c-dist-auth@w3.org
MIME-Version: 1.0
X-WSS-ID: 6C7EB889669053-01-01
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: Re (2): Where is an example of using webdavseamlessly...and  version files?
X-Archived-At: http://www.w3.org/mid/s06003c2.028@wh-inet.gmhwh.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8366
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040323163150.F09C1A0625@frink.w3.org>
Resent-Date: Tue, 23 Mar 2004 11:31:50 -0500 (EST)
Content-Transfer-Encoding: 7bit


Seems to me there are two scenarios to look at here.  I'm probably covering old
ground for this forum but:
Scenario 1:   Save file starting from client application.    You'd have a
browse button or just type in the http address of the file.   Hit Save and your
done.
Scenario 2: Update file/Download file   invoked from server application.  
You'd again have a browse button to save the file.  In this respect having
WebDav is no different than not having WebDav - same number of steps required.

For Scenario 1: 'Save' and 'Save as' would point to the file on the Web Server,
if that is where the file came from.  And the versioning might be automatic.

>>> "Geoffrey M Clemm"  3/23/2004 8:53:54 AM >>>

I'd suggest just using "save" and "save as" to mean "save local"
and "save local as" and have "checkin" mean "save to the server
(and create a new version if the server supports versioning)".

Cheers,
Geoff

Edgar wrote on 03/22/2004 04:54:46 PM:

> Suppose I edit a WebDAV file with my application.
> - Now I want to save it. In a "normal" application I have "save" 
and"save as".
> - With a WebDAV file I guess I have "save local", "save on server", 
> "save local as"
>   and "save on server as".
> - I think "save local as" doesn't make that much sense and can be 
dropped.
> - This leaves me with three choices. One should be default and be called 
save.
> - So my idea is to have "save", "save WebDAV" and "save WebDAV as" which 
means
>   a simple "save" means saving local. This could be fine for people 
> with a slow
>   server connection.
> So do you think this sounds right for a user ?
> Would you prefer other names or choices for saving ?
> I know this isn't something the spec should say but nevertheless it 
> would be nice
> if users would have similar menu items for saving in their upcoming 
> WebDAV empowered
> applications. 
> BTW for versioning I have at the moment in a directory window the 
following
> menu items and subitems:
> - Version Do
>   - Checkin  (Which does a VERSION-CONTROL, BASELINE-CONTROL or 
> CHECKIN depending
>     on it's target)
>   - Uncheckout
>   - Checkout
>   - Update
> - Version Report
>   - Version (For a resource or a configuration)
>   - History (For a resource or a configuration)
>   - Baseline Compare
> Naturally most of these points also can be added to an editor menu. Also 
there
> could be one versioning menu.
> 
> Cheers, Edgar
> 





From w3c-dist-auth-request@w3.org  Tue Mar 23 14:39:33 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20452
	for <webdav-archive@lists.ietf.org>; Tue, 23 Mar 2004 14:39:33 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 64409A154C; Tue, 23 Mar 2004 14:39:26 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 1F9B1A154C
	for <w3c-dist-auth@listhub.w3.org>; Tue, 23 Mar 2004 14:39:23 -0500 (EST)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B5rjv-0007Hb-IX
	for w3c-dist-auth@w3c.org; Tue, 23 Mar 2004 14:39:07 -0500
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: <w3c-dist-auth@w3c.org>
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i2NJd4IC021776
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <w3c-dist-auth@w3c.org>; Tue, 23 Mar 2004 11:39:05 -0800
Mime-Version: 1.0 (Apple Message framework v613)
Content-Transfer-Encoding: 7bit
Message-Id: <BA82F416-7D01-11D8-BB68-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Tue, 23 Mar 2004 11:38:58 -0800
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Charter update: remove property registry task?
X-Archived-At: http://www.w3.org/mid/BA82F416-7D01-11D8-BB68-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8367
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040323193926.64409A154C@frink.w3.org>
Resent-Date: Tue, 23 Mar 2004 14:39:26 -0500 (EST)
Content-Transfer-Encoding: 7bit



I'd like to find out if there is consensus on removing the "property 
registry" task from the WebDAV WG charter.

http://www.ietf.org/html.charters/webdav-charter.html

We've attempted to discuss this at various WG meetings, and we've never 
made any clear progress in defining the task -- so we don't even know 
whether this would be an Internet-Draft that could become an RFC, 
possibly defining an IANA process, or whether this would be a site or 
non-IANA process of some kind.  We also have never had a volunteer so 
we've never had anybody working on this item.  Perhaps nobody's ever 
found it to be really necessary.

Note that even if it's removed from the charter, progress can still be 
made if somebody finds the motivation.  For example, a property 
registry site could be developed with feedback from the Working Group, 
even if it's not a WG deliverable.

If we don't remove it from the charter, then we need volunteers ASAP to 
work on that item, and clear ideas what the WG deliverable really is.  
Please weigh in.

Lisa



From w3c-dist-auth-request@w3.org  Tue Mar 23 14:40:25 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20498
	for <webdav-archive@lists.ietf.org>; Tue, 23 Mar 2004 14:40:25 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id AD1A3A1557; Tue, 23 Mar 2004 14:40:25 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id DC4B6A1557
	for <w3c-dist-auth@listhub.w3.org>; Tue, 23 Mar 2004 14:40:20 -0500 (EST)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B5rkr-0007o3-Ed
	for w3c-dist-auth@w3c.org; Tue, 23 Mar 2004 14:40:05 -0500
Old-X-Envelope-From: lisa@osafoundation.org
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i2NJd4ID021776
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 23 Mar 2004 11:40:01 -0800
In-Reply-To: <BA82F416-7D01-11D8-BB68-000A95B2BB72@osafoundation.org>
References: <BA82F416-7D01-11D8-BB68-000A95B2BB72@osafoundation.org>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <DFB08FD0-7D01-11D8-BB68-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Tue, 23 Mar 2004 11:40:00 -0800
To: Lisa Dusseault <lisa@osafoundation.org>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: Charter update: remove property registry task?
X-Archived-At: http://www.w3.org/mid/DFB08FD0-7D01-11D8-BB68-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8368
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040323194025.AD1A3A1557@frink.w3.org>
Resent-Date: Tue, 23 Mar 2004 14:40:25 -0500 (EST)
Content-Transfer-Encoding: 7bit


Sorry, I meant to put a time limit on feedback -- we'll try to come to 
a conclusion in 2 weeks so please hold discussion in that time. thanks!

Lisa

On Mar 23, 2004, at 11:38 AM, Lisa Dusseault wrote:

>
> I'd like to find out if there is consensus on removing the "property 
> registry" task from the WebDAV WG charter.
>
> http://www.ietf.org/html.charters/webdav-charter.html
>
> We've attempted to discuss this at various WG meetings, and we've 
> never made any clear progress in defining the task -- so we don't even 
> know whether this would be an Internet-Draft that could become an RFC, 
> possibly defining an IANA process, or whether this would be a site or 
> non-IANA process of some kind.  We also have never had a volunteer so 
> we've never had anybody working on this item.  Perhaps nobody's ever 
> found it to be really necessary.
>
> Note that even if it's removed from the charter, progress can still be 
> made if somebody finds the motivation.  For example, a property 
> registry site could be developed with feedback from the Working Group, 
> even if it's not a WG deliverable.
>
> If we don't remove it from the charter, then we need volunteers ASAP 
> to work on that item, and clear ideas what the WG deliverable really 
> is.  Please weigh in.
>
> Lisa
>



From w3c-dist-auth-request@w3.org  Tue Mar 23 14:58:29 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22047
	for <webdav-archive@lists.ietf.org>; Tue, 23 Mar 2004 14:58:29 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id EF827A06E4; Tue, 23 Mar 2004 14:58:08 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 604E8A105B
	for <w3c-dist-auth@listhub.w3.org>; Tue, 23 Mar 2004 14:58:05 -0500 (EST)
Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B5s2F-0003Np-Pc
	for w3c-dist-auth@w3c.org; Tue, 23 Mar 2004 14:58:04 -0500
Received: (qmail 30073 invoked by uid 65534); 23 Mar 2004 19:57:27 -0000
Received: from pD950C38C.dip.t-dialin.net (EHLO gmx.de) (217.80.195.140)
  by mail.gmx.net (mp012) with SMTP; 23 Mar 2004 20:57:27 +0100
X-Authenticated: #1915285
Message-ID: <4060969D.2060505@gmx.de>
Date: Tue, 23 Mar 2004 20:57:17 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
References: <BA82F416-7D01-11D8-BB68-000A95B2BB72@osafoundation.org>
In-Reply-To: <BA82F416-7D01-11D8-BB68-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Charter update: remove property registry task?
X-Archived-At: http://www.w3.org/mid/4060969D.2060505@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8369
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040323195808.EF827A06E4@frink.w3.org>
Resent-Date: Tue, 23 Mar 2004 14:58:08 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> I'd like to find out if there is consensus on removing the "property 
> registry" task from the WebDAV WG charter.
> 
> http://www.ietf.org/html.charters/webdav-charter.html
> 
> We've attempted to discuss this at various WG meetings, and we've never 
> made any clear progress in defining the task -- so we don't even know 
> whether this would be an Internet-Draft that could become an RFC, 
> possibly defining an IANA process, or whether this would be a site or 
> non-IANA process of some kind.  We also have never had a volunteer so 
> we've never had anybody working on this item.  Perhaps nobody's ever 
> found it to be really necessary.
> 
> Note that even if it's removed from the charter, progress can still be 
> made if somebody finds the motivation.  For example, a property registry 
> site could be developed with feedback from the Working Group, even if 
> it's not a WG deliverable.
> 
> If we don't remove it from the charter, then we need volunteers ASAP to 
> work on that item, and clear ideas what the WG deliverable really is.  
> Please weigh in.

I vote for removing it. Clearly there's no energy for working on a 
universal registry, nor do we seem to need it.

Related: I've been working on scripts that compile information about 
method names, header names, property names, pre/postcondition names (and 
so on) from a set of RFC2629-XML-formatted documents. Basically I'm 
using a set of well-defined entries of index entries, and just combine 
them into a common document. This will give us the property index at 
least for all working-group documents (it's not quite ready yet, but if 
people are interested, I can produce an example in the next few days).

Regards, Julian

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



From w3c-dist-auth-request@w3.org  Tue Mar 23 16:37:09 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03653
	for <webdav-archive@lists.ietf.org>; Tue, 23 Mar 2004 16:37:09 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 135C6A1C6E; Tue, 23 Mar 2004 16:37:10 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id C7398A1C6E
	for <w3c-dist-auth@listhub.w3.org>; Tue, 23 Mar 2004 16:37:07 -0500 (EST)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B5ta5-0002Nu-RU
	for w3c-dist-auth@w3c.org; Tue, 23 Mar 2004 16:37:06 -0500
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: <w3c-dist-auth@w3c.org>
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i2NLb3IC029240
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <w3c-dist-auth@w3c.org>; Tue, 23 Mar 2004 13:37:03 -0800
Mime-Version: 1.0 (Apple Message framework v613)
Content-Transfer-Encoding: 7bit
Message-Id: <35E3C686-7D12-11D8-BB68-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Tue, 23 Mar 2004 13:36:57 -0800
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Charter update: remove ACL goals document
X-Archived-At: http://www.w3.org/mid/35E3C686-7D12-11D8-BB68-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8370
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040323213710.135C6A1C6E@frink.w3.org>
Resent-Date: Tue, 23 Mar 2004 16:37:10 -0500 (EST)
Content-Transfer-Encoding: 7bit



Another charter item which isn't met yet, and with no progress in 5 
years, is the ACL goals document.

http://www.webdav.org/acl/goals/draft-ietf-webdav-acl-reqts-00.txt

Attention went from goals to specification and never returned.  The ACL 
specification may no longer be very much in line with the goals 
document any more (somebody would have to reread the goals document to 
see).  It doesn't really matter because events left the goals document 
behind.  The main reason for the goals document to be standardized 
would have been to enforce some process on getting ACL itself to RFC 
but that's done now anyway.

So, to perform good housekeeping on our charter, does anybody object to 
simply removing this goal from the charter?

Again, feedback and discussion within 2 weeks would be appreciated.  
Thanks!

Lisa 



From w3c-dist-auth-request@w3.org  Tue Mar 23 19:24:41 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14202
	for <webdav-archive@lists.ietf.org>; Tue, 23 Mar 2004 19:24:40 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id CD103A120D; Tue, 23 Mar 2004 19:24:30 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 61AD6A12AD
	for <w3c-dist-auth@listhub.w3.org>; Tue, 23 Mar 2004 19:24:23 -0500 (EST)
Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B5w0c-0007EY-Ms
	for w3c-dist-auth@w3c.org; Tue, 23 Mar 2004 19:12:38 -0500
Received: (qmail 3446 invoked by uid 65534); 24 Mar 2004 00:10:58 -0000
Received: from pD950C38C.dip.t-dialin.net (EHLO gmx.de) (217.80.195.140)
  by mail.gmx.net (mp010) with SMTP; 24 Mar 2004 01:10:58 +0100
X-Authenticated: #1915285
Message-ID: <4060D206.9030001@gmx.de>
Date: Wed, 24 Mar 2004 01:10:46 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
References: <35E3C686-7D12-11D8-BB68-000A95B2BB72@osafoundation.org>
In-Reply-To: <35E3C686-7D12-11D8-BB68-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Charter update: remove ACL goals document
X-Archived-At: http://www.w3.org/mid/4060D206.9030001@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8371
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040324002430.CD103A120D@frink.w3.org>
Resent-Date: Tue, 23 Mar 2004 19:24:30 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:
> 
> 
> Another charter item which isn't met yet, and with no progress in 5 
> years, is the ACL goals document.
> 
> http://www.webdav.org/acl/goals/draft-ietf-webdav-acl-reqts-00.txt
> 
> Attention went from goals to specification and never returned.  The ACL 
> specification may no longer be very much in line with the goals document 
> any more (somebody would have to reread the goals document to see).  It 
> doesn't really matter because events left the goals document behind.  
> The main reason for the goals document to be standardized would have 
> been to enforce some process on getting ACL itself to RFC but that's 
> done now anyway.
> 
> So, to perform good housekeeping on our charter, does anybody object to 
> simply removing this goal from the charter?
> 
> Again, feedback and discussion within 2 weeks would be appreciated.  
> Thanks!

+1 for removing it from the agenda.

Julian

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



From w3c-dist-auth-request@w3.org  Tue Mar 23 20:39:12 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17711
	for <webdav-archive@lists.ietf.org>; Tue, 23 Mar 2004 20:39:11 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id DAC63A1469; Tue, 23 Mar 2004 20:39:02 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id E5827A1469
	for <w3c-dist-auth@listhub.w3.org>; Tue, 23 Mar 2004 20:38:43 -0500 (EST)
Received: from e3.ny.us.ibm.com ([32.97.182.103])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B5xJB-0000aw-BW
	for w3c-dist-auth@w3c.org; Tue, 23 Mar 2004 20:35:53 -0500
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2O1Z2AB749098
	for <w3c-dist-auth@w3c.org>; Tue, 23 Mar 2004 20:35:02 -0500
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2O1Z0ch104300
	for <w3c-dist-auth@w3c.org>; Tue, 23 Mar 2004 20:35:00 -0500
In-Reply-To: <4060D206.9030001@gmx.de>
To: Webdav WG <w3c-dist-auth@w3c.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF7DFF0C44.A87D498B-ON85256E61.0008968D-85256E61.0008A290@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Tue, 23 Mar 2004 20:34:59 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at
 03/23/2004 20:35:01,
	Serialize complete at 03/23/2004 20:35:01
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: Charter update: remove ACL goals document
X-Archived-At: http://www.w3.org/mid/OF7DFF0C44.A87D498B-ON85256E61.0008968D-85256E61.0008A290@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8372
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040324013902.DAC63A1469@frink.w3.org>
Resent-Date: Tue, 23 Mar 2004 20:39:02 -0500 (EST)


+1 for removing.

Cheers,
Geoff

Julian wrote on 03/23/2004 07:10:46 PM:

> 
> Lisa Dusseault wrote:
> > 
> > 
> > Another charter item which isn't met yet, and with no progress in 5 
> > years, is the ACL goals document.
> > 
> > http://www.webdav.org/acl/goals/draft-ietf-webdav-acl-reqts-00.txt
> > 
> > Attention went from goals to specification and never returned.  The 
ACL 
> > specification may no longer be very much in line with the goals 
document 
> > any more (somebody would have to reread the goals document to see). It 

> > doesn't really matter because events left the goals document behind. 
> > The main reason for the goals document to be standardized would have 
> > been to enforce some process on getting ACL itself to RFC but that's 
> > done now anyway.
> > 
> > So, to perform good housekeeping on our charter, does anybody object 
to 
> > simply removing this goal from the charter?
> > 
> > Again, feedback and discussion within 2 weeks would be appreciated. 
> > Thanks!
> 
> +1 for removing it from the agenda.
> 
> Julian
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 



From w3c-dist-auth-request@w3.org  Tue Mar 23 20:49:27 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18529
	for <webdav-archive@lists.ietf.org>; Tue, 23 Mar 2004 20:49:26 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 8388AA13FF; Tue, 23 Mar 2004 20:49:17 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 897A7A13FF
	for <w3c-dist-auth@listhub.w3.org>; Tue, 23 Mar 2004 20:49:00 -0500 (EST)
Received: from e5.ny.us.ibm.com ([32.97.182.105])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B5xSD-0001Xj-Bf
	for w3c-dist-auth@w3c.org; Tue, 23 Mar 2004 20:45:13 -0500
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2O1iLJr035502
	for <w3c-dist-auth@w3c.org>; Tue, 23 Mar 2004 20:44:21 -0500
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2O1iKch121122
	for <w3c-dist-auth@w3c.org>; Tue, 23 Mar 2004 20:44:20 -0500
In-Reply-To: <4060969D.2060505@gmx.de>
To: Webdav WG <w3c-dist-auth@w3c.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OFBE04363F.7C5F6309-ON85256E61.00096F33-85256E61.00097DBB@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Tue, 23 Mar 2004 20:44:20 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at
 03/23/2004 20:44:20,
	Serialize complete at 03/23/2004 20:44:20
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: Charter update: remove property registry task?
X-Archived-At: http://www.w3.org/mid/OFBE04363F.7C5F6309-ON85256E61.00096F33-85256E61.00097DBB@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8373
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040324014917.8388AA13FF@frink.w3.org>
Resent-Date: Tue, 23 Mar 2004 20:49:17 -0500 (EST)


+1 for removing it.

Cheers,
Geoff

Julian wrote on 03/23/2004 02:57:17 PM:

> 
> Lisa Dusseault wrote:
> 
> > I'd like to find out if there is consensus on removing the "property 
> > registry" task from the WebDAV WG charter.
> > 
> > http://www.ietf.org/html.charters/webdav-charter.html
> > 
> > We've attempted to discuss this at various WG meetings, and we've 
never 
> > made any clear progress in defining the task -- so we don't even know 
> > whether this would be an Internet-Draft that could become an RFC, 
> > possibly defining an IANA process, or whether this would be a site or 
> > non-IANA process of some kind.  We also have never had a volunteer so 
> > we've never had anybody working on this item.  Perhaps nobody's ever 
> > found it to be really necessary.
> > 
> > Note that even if it's removed from the charter, progress can still be 

> > made if somebody finds the motivation.  For example, a property 
registry 
> > site could be developed with feedback from the Working Group, even if 
> > it's not a WG deliverable.
> > 
> > If we don't remove it from the charter, then we need volunteers ASAP 
to 
> > work on that item, and clear ideas what the WG deliverable really is. 
> > Please weigh in.
> 
> I vote for removing it. Clearly there's no energy for working on a 
> universal registry, nor do we seem to need it.
> 
> Related: I've been working on scripts that compile information about 
> method names, header names, property names, pre/postcondition names (and 

> so on) from a set of RFC2629-XML-formatted documents. Basically I'm 
> using a set of well-defined entries of index entries, and just combine 
> them into a common document. This will give us the property index at 
> least for all working-group documents (it's not quite ready yet, but if 
> people are interested, I can produce an example in the next few days).
> 
> Regards, Julian
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 



From w3c-dist-auth-request@w3.org  Tue Mar 23 22:24:11 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22497
	for <webdav-archive@lists.ietf.org>; Tue, 23 Mar 2004 22:24:10 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E8948A0BA2; Tue, 23 Mar 2004 22:24:00 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id C94E3A0FF8
	for <w3c-dist-auth@listhub.w3.org>; Tue, 23 Mar 2004 22:23:52 -0500 (EST)
Received: from inet-mail4.oracle.com ([148.87.2.204])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B5ywn-0003nm-RL
	for w3c-dist-auth@w3c.org; Tue, 23 Mar 2004 22:20:54 -0500
Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14])
	by inet-mail4.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i2O3IFDS026498;
	Tue, 23 Mar 2004 19:18:15 -0800 (PST)
Received: from rgmgw5.us.oracle.com (localhost [127.0.0.1])
	by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id i2O3JuD01273;
	Tue, 23 Mar 2004 20:19:57 -0700 (MST)
Received: from esedlar (dhcp-amer-vpn-gw2-east-141-144-81-23.vpn.oracle.com [141.144.81.23])
	by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id i2O3JsD01156;
	Tue, 23 Mar 2004 20:19:54 -0700 (MST)
Message-Id: <200403240319.i2O3JsD01156@rgmgw5.us.oracle.com>
From: "Eric Sedlar" <eric.sedlar@oracle.com>
To: "'Geoffrey M Clemm'" <geoffrey.clemm@us.ibm.com>,
        "'Webdav WG'" <w3c-dist-auth@w3c.org>
Date: Tue, 23 Mar 2004 19:18:47 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <OF7DFF0C44.A87D498B-ON85256E61.0008968D-85256E61.0008A290@us.ibm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcQRQRLZ2SaCbp31T6i8ww63SRuwnwADaG7Q
Subject: RE: Charter update: remove ACL goals document
X-Archived-At: http://www.w3.org/mid/200403240319.i2O3JsD01156@rgmgw5.us.oracle.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8374
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040324032400.E8948A0BA2@frink.w3.org>
Resent-Date: Tue, 23 Mar 2004 22:24:00 -0500 (EST)
Content-Transfer-Encoding: 7bit


+1 for me

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]
> On Behalf Of Geoffrey M Clemm
> Sent: Tuesday, March 23, 2004 5:35 PM
> To: Webdav WG
> Subject: Re: Charter update: remove ACL goals document
> 
> 
> +1 for removing.
> 
> Cheers,
> Geoff
> 
> Julian wrote on 03/23/2004 07:10:46 PM:
> 
> >
> > Lisa Dusseault wrote:
> > >
> > >
> > > Another charter item which isn't met yet, and with no progress in 5
> > > years, is the ACL goals document.
> > >
> > > http://www.webdav.org/acl/goals/draft-ietf-webdav-acl-reqts-00.txt
> > >
> > > Attention went from goals to specification and never returned.  The
> ACL
> > > specification may no longer be very much in line with the goals
> document
> > > any more (somebody would have to reread the goals document to see). It
> 
> > > doesn't really matter because events left the goals document behind.
> > > The main reason for the goals document to be standardized would have
> > > been to enforce some process on getting ACL itself to RFC but that's
> > > done now anyway.
> > >
> > > So, to perform good housekeeping on our charter, does anybody object
> to
> > > simply removing this goal from the charter?
> > >
> > > Again, feedback and discussion within 2 weeks would be appreciated.
> > > Thanks!
> >
> > +1 for removing it from the agenda.
> >
> > Julian
> >
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> >




From w3c-dist-auth-request@w3.org  Tue Mar 23 22:27:34 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22554
	for <webdav-archive@lists.ietf.org>; Tue, 23 Mar 2004 22:27:34 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 376DEA1432; Tue, 23 Mar 2004 22:27:24 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id BAA1AA1558
	for <w3c-dist-auth@listhub.w3.org>; Tue, 23 Mar 2004 22:27:02 -0500 (EST)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B5z0f-0004GN-Qn
	for w3c-dist-auth@w3c.org; Tue, 23 Mar 2004 22:24:53 -0500
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i2O3OV1a027427 sender ccjason@us.ibm.com for w3c-dist-auth@w3c.org; Tue, 23 Mar 2004 19:24:31 -0800
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by bandage.seagull.net (8.12.10) with ESMTP id i2O3OTD4027363 sender ccjason@us.ibm.com; Tue, 23 Mar 2004 19:24:30 -0800
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2O3OIAB613302; Tue, 23 Mar 2004 22:24:19 -0500
Received: from d01ml604.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2O3OZad112546; Tue, 23 Mar 2004 22:24:35 -0500
To: Webdav WG <nnw3c-dist-auth___at___w3c.org@smallcue.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Jason Crawford <ccjason@us.ibm.com>
Message-ID: <OF26C07B87.52401E85-ON85256E61.0011C16E-85256E61.0012B65E@us.ibm.com>
Date: Tue, 23 Mar 2004 22:24:34 -0500
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF87 | March 11, 2004) at 03/23/2004 22:24:18, Serialize complete at 03/23/2004 22:24:18
Content-Type: multipart/alternative; boundary="=_alternative 001270B985256E61_="
Subject: Re: Charter update: remove property registry task?
X-Archived-At: http://www.w3.org/mid/OF26C07B87.52401E85-ON85256E61.0011C16E-85256E61.0012B65E@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8375
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040324032724.376DEA1432@frink.w3.org>
Resent-Date: Tue, 23 Mar 2004 22:27:24 -0500 (EST)


This is a multipart message in MIME format.
--=_alternative 001270B985256E61_=
Content-Type: text/plain; charset="us-ascii"

remove it
--=_alternative 001270B985256E61_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">remove it</font>
--=_alternative 001270B985256E61_=--



From w3c-dist-auth-request@w3.org  Wed Mar 24 01:38:39 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00810
	for <webdav-archive@lists.ietf.org>; Wed, 24 Mar 2004 01:38:39 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 5FF07A06A5; Wed, 24 Mar 2004 01:38:29 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id B049DA06A5
	for <w3c-dist-auth@listhub.w3.org>; Wed, 24 Mar 2004 01:38:20 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B61pw-0007L2-Oq
	for w3c-dist-auth@w3c.org; Wed, 24 Mar 2004 01:26:00 -0500
Received: from ams-msg-core-1.cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 23 Mar 2004 22:32:08 +0000
Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92])
	by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2O6Obsk027582;
	Wed, 24 Mar 2004 07:24:37 +0100 (MET)
Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 24 Mar 2004 07:23:29 +0100
Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(6.0.3790.0);
	 Wed, 24 Mar 2004 07:25:07 +0100
In-Reply-To: <4060969D.2060505@gmx.de>
References: <BA82F416-7D01-11D8-BB68-000A95B2BB72@osafoundation.org> <4060969D.2060505@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <FE4234A0-7D5B-11D8-9B8B-000A95B2B926@cisco.com>
Content-Transfer-Encoding: 7bit
Cc: Lisa Dusseault <lisa@osafoundation.org>, Webdav WG <w3c-dist-auth@w3c.org>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
Date: Wed, 24 Mar 2004 07:25:06 +0100
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-OriginalArrivalTime: 24 Mar 2004 06:25:07.0862 (UTC) FILETIME=[C0972B60:01C41168]
Subject: Process issue: Changing topics
X-Archived-At: http://www.w3.org/mid/FE4234A0-7D5B-11D8-9B8B-000A95B2B926@cisco.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8376
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040324063829.5FF07A06A5@frink.w3.org>
Resent-Date: Wed, 24 Mar 2004 01:38:29 -0500 (EST)
Content-Transfer-Encoding: 7bit


As co-chair for this wg I must state I do not want to see things like 
this in mail which explicitly by Lisa, myself or anyone else is talking 
about one and only one issue.

If you want to talk about related issues, create a new thread.

Please.

     paf

On Mar 23, 2004, at 20:57, Julian Reschke wrote:

> Related: I've been working on scripts that compile information about 
> method names, header names, property names, pre/postcondition names 
> (and so on) from a set of RFC2629-XML-formatted documents. Basically 
> I'm using a set of well-defined entries of index entries, and just 
> combine them into a common document. This will give us the property 
> index at least for all working-group documents (it's not quite ready 
> yet, but if people are interested, I can produce an example in the 
> next few days).



From w3c-dist-auth-request@w3.org  Wed Mar 24 03:39:56 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05157
	for <webdav-archive@lists.ietf.org>; Wed, 24 Mar 2004 03:39:56 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 1084CA0D7A; Wed, 24 Mar 2004 03:39:46 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 507BDA0D7A
	for <w3c-dist-auth@listhub.w3.org>; Wed, 24 Mar 2004 03:39:37 -0500 (EST)
Received: from [217.5.201.10] (helo=greenbytes.de)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B63uG-0000YC-RH
	for w3c-dist-auth@w3c.org; Wed, 24 Mar 2004 03:38:37 -0500
Received: from [192.168.1.26] ([192.168.1.26])
	(authenticated user se@greenbytes.de)
	by greenbytes.de (greenbytes.de)
	(Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000003938.msg
	for <w3c-dist-auth@w3c.org>; Wed, 24 Mar 2004 09:35:16 +0100
In-Reply-To: <DFB08FD0-7D01-11D8-BB68-000A95B2BB72@osafoundation.org>
References: <BA82F416-7D01-11D8-BB68-000A95B2BB72@osafoundation.org> <DFB08FD0-7D01-11D8-BB68-000A95B2BB72@osafoundation.org>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <7AFCE45E-7D6E-11D8-BB64-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
Cc: Webdav WG <w3c-dist-auth@w3c.org>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Wed, 24 Mar 2004 09:37:27 +0100
To: Lisa Dusseault <lisa@osafoundation.org>
X-Mailer: Apple Mail (2.613)
X-Authenticated-Sender: se@greenbytes.de
X-Spam-Processed: greenbytes.de, Wed, 24 Mar 2004 09:35:16 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 192.168.1.26
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: Charter update: remove property registry task?
X-Archived-At: http://www.w3.org/mid/7AFCE45E-7D6E-11D8-BB64-00039384827E@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8377
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040324083946.1084CA0D7A@frink.w3.org>
Resent-Date: Wed, 24 Mar 2004 03:39:46 -0500 (EST)
Content-Transfer-Encoding: 7bit


+1 for removing it.

Am 23.03.2004 um 20:40 schrieb Lisa Dusseault:

>
> Sorry, I meant to put a time limit on feedback -- we'll try to come to 
> a conclusion in 2 weeks so please hold discussion in that time. 
> thanks!
>
> Lisa
>
> On Mar 23, 2004, at 11:38 AM, Lisa Dusseault wrote:
>
>>
>> I'd like to find out if there is consensus on removing the "property 
>> registry" task from the WebDAV WG charter.
>>
>> http://www.ietf.org/html.charters/webdav-charter.html
>>
>> We've attempted to discuss this at various WG meetings, and we've 
>> never made any clear progress in defining the task -- so we don't 
>> even know whether this would be an Internet-Draft that could become 
>> an RFC, possibly defining an IANA process, or whether this would be a 
>> site or non-IANA process of some kind.  We also have never had a 
>> volunteer so we've never had anybody working on this item.  Perhaps 
>> nobody's ever found it to be really necessary.
>>
>> Note that even if it's removed from the charter, progress can still 
>> be made if somebody finds the motivation.  For example, a property 
>> registry site could be developed with feedback from the Working 
>> Group, even if it's not a WG deliverable.
>>
>> If we don't remove it from the charter, then we need volunteers ASAP 
>> to work on that item, and clear ideas what the WG deliverable really 
>> is.  Please weigh in.
>>
>> Lisa
>>
>




From w3c-dist-auth-request@w3.org  Wed Mar 24 11:53:50 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05998
	for <webdav-archive@lists.ietf.org>; Wed, 24 Mar 2004 11:53:50 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 41206A165B; Wed, 24 Mar 2004 11:53:41 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id DA941A16B5
	for <w3c-dist-auth@listhub.w3.org>; Wed, 24 Mar 2004 11:53:27 -0500 (EST)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B6Ba9-0001JP-2V
	for w3c-dist-auth@w3c.org; Wed, 24 Mar 2004 11:50:21 -0500
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Received: from [192.168.1.100] ([198.144.201.116])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i2OGmjhV015751
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 24 Mar 2004 08:48:47 -0800
In-Reply-To: <405F4BD5.5070302@gmx.de>
References: <OFF9933575.AF301A7E-ON85256E5C.0069DA11-85256E5C.006AA750@us.ibm.com> <405C196C.1030609@gmx.de> <E80FC418-7C3C-11D8-BB68-000A95B2BB72@osafoundation.org> <405F4BD5.5070302@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <19B65246-7DB3-11D8-9DC8-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>,
        Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 24 Mar 2004 08:48:39 -0800
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/19B65246-7DB3-11D8-9DC8-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8378
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040324165341.41206A165B@frink.w3.org>
Resent-Date: Wed, 24 Mar 2004 11:53:41 -0500 (EST)
Content-Transfer-Encoding: 7bit


I suggest adding the following text to the Bind draft:

"Methods that create a new resource (MKCOL, MKWORKSPACE, MKACTIVITY,  
PUT when the destination is unbound) each create only one binding and  
one resource.  Methods that create a new binding (BIND) leave other  
bindings unaffected.

"The following methods MUST have an identical result on every binding  
to a resource, regardless of which binding is addressed:
  - GET, PUT (to an existing binding), OPTIONS, HEAD.
  - PROPPATCH, LOCK, UNLOCK
  - all the methods defined in RFC3253 (except the ones that create a  
new resource)
  - ORDERPATCH
  - ACL

"The following methods have a result that only affects the binding that  
is addressed, and don't affect other bindings to the same resource:  
REBIND, UNBIND.  MOVE, COPY and DELETE have special behavior described  
in detail in sections 2.3 to 2.5.

"The REPORT and PROPFIND methods could conceivably provide different  
information depending on which binding to a resource is addressed but  
by default they return the same information regardless of binding.  The  
definition of each property or report ought to make clear if this  
property or report diverges from the default.  All reports defined in  
RFC3253 and the ACL RFC return the same result for any binding to the  
same resource.  All (live) properties defined in RFC2518, RFC3253,  
RFC3648 and the ACL RFC MUST have the same value appearing on all  
bindings to the same resource. All dead properties MUST appear the same  
on all bindings to the same resource. An implementation MAY define  
custom live properties which have different values on different  
bindings to the same resource."

---

This text is intended to supplement the model description by making  
requirements on implementations to encourage them to behave  
consistently, and to clear up confusion in applying the model in  
specific cases.

Lisa


On Mar 22, 2004, at 12:25 PM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>
>> This is definitely an improvement.  However, I still  have some  
>> issues -- the interaction between bindings and locks is still  
>> unclear.  The spec needs to clearly say that
>>  - if one binding is locked, then every binding is locked (with the  
>> same lock token)
>
> No, the bindings aren't locked, the *resource* is (RFC2518).
>
>>  - All bindings to the same resource MUST support the same features  
>> (e.g. locking)
>
> The bindings themselves do not support anything; the resource they are  
> mapped to do. As they are mapped to the same resource, the same  
> features are available.
>
>>  - All bindings to the same resource MUST show the same values for  
>> live properties defined in RFC2518, RFC3253, RFC3648 and the ACL RFC.
>
> Same. You're communicating with the resource, not particular bindings.
>
>> Unless my understanding of the intent is wrong...?  In which case, it  
>> needs to clarify some other way.
>
> I'd say all of this follows from section 1, paragraphs 4  
> (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind 
> -04.html#rfc.section.1.p.4>) to 6:
>
> "The BIND method defined here provides a mechanism for allowing  
> clients to create alternative access paths to existing WebDAV  
> resources. HTTP [RFC2616] and WebDAV [RFC2518]  methods are able to  
> work because there are mappings between URIs and resources. A method  
> is addressed to a URI, and the server follows the mapping from that  
> URI to a resource, applying the method to that resource. Multiple URIs  
> may be mapped to the same resource, but until now there has been no  
> way for clients to create additional URIs mapped to existing  
> resources.
>
> BIND lets clients associate a new URI with an existing WebDAV  
> resource, and this URI can then be used to submit requests to the  
> resource. Since URIs of WebDAV resources are hierarchical, and  
> correspond to a hierarchy of collections in resource space, the BIND  
> method also has the effect of adding the resource to a collection. As  
> new URIs are associated with the resource, it appears in additional  
> collections.
>
> A BIND request does not create a new resource, but simply makes  
> available a new URI for submitting requests to an existing resource.  
> The new URI is indistinguishable from any other URI when submitting a  
> request to a resource. Only one round trip is needed to submit a  
> request to the intended target. Servers are required to enforce the  
> integrity of the relationships between the new URIs and the resources  
> associated with them. Consequently, it may be very costly for servers  
> to support BIND requests that cross server boundaries."
>
> At this point I really don't know how to improve that description  
> (except by adding "we mean it -- it's really just another name mapped  
> to the same resource" :-). If you think that this introduction needs  
> to be improved, please make a concrete proposal.
>
> Does anybody else feel that this is unclear?
>
>
> Regards. Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Wed Mar 24 12:17:07 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07171
	for <webdav-archive@lists.ietf.org>; Wed, 24 Mar 2004 12:17:06 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id C506EA14AE; Wed, 24 Mar 2004 12:16:57 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 29A72A1379
	for <w3c-dist-auth@listhub.w3.org>; Wed, 24 Mar 2004 12:16:47 -0500 (EST)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B6BvO-0005M7-IA
	for w3c-dist-auth@w3c.org; Wed, 24 Mar 2004 12:12:18 -0500
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: <w3c-dist-auth@w3c.org>
Received: from [192.168.1.100] ([198.144.201.116])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i2OHBshV017368
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <w3c-dist-auth@w3c.org>; Wed, 24 Mar 2004 09:11:56 -0800
Mime-Version: 1.0 (Apple Message framework v613)
Content-Transfer-Encoding: 7bit
Message-Id: <543EB0EE-7DB6-11D8-9DC8-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 24 Mar 2004 09:11:45 -0800
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: COPY of a binding onto another binding of same resource
X-Archived-At: http://www.w3.org/mid/543EB0EE-7DB6-11D8-9DC8-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8379
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040324171657.C506EA14AE@frink.w3.org>
Resent-Date: Wed, 24 Mar 2004 12:16:57 -0500 (EST)
Content-Transfer-Encoding: 7bit


When a user does a COPY or MOVE from one binding to another binding to 
the same resource, this should be flagged as an error.  Since this has 
to interoperate with existing clients that won't look at the error 
body, the status code would have to stand alone.  409 is already used 
for non-existent parent collections, so that can't be reused.  Possibly 
403 which in 2518 for COPY means "_ The source and destination URIs are 
the same."

Lisa



From w3c-dist-auth-request@w3.org  Wed Mar 24 12:42:02 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08648
	for <webdav-archive@lists.ietf.org>; Wed, 24 Mar 2004 12:42:02 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 7CB55A066B; Wed, 24 Mar 2004 12:41:40 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 94C38A14CC
	for <w3c-dist-auth@listhub.w3.org>; Wed, 24 Mar 2004 12:41:18 -0500 (EST)
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B6CI4-00013n-ND
	for w3c-dist-auth@w3c.org; Wed, 24 Mar 2004 12:35:44 -0500
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2OHYj0k019307;
	Wed, 24 Mar 2004 09:34:46 -0800 (PST)
Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161])
	by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2OHYhVK012304;
	Wed, 24 Mar 2004 09:34:44 -0800 (PST)
Mime-Version: 1.0
X-Sender: hardie@mage.qualcomm.com
Message-Id: <p06020402bc8776b66df3@[129.46.227.161]>
In-Reply-To: <543EB0EE-7DB6-11D8-9DC8-000A95B2BB72@osafoundation.org>
References: <543EB0EE-7DB6-11D8-9DC8-000A95B2BB72@osafoundation.org>
Date: Wed, 24 Mar 2004 09:34:42 -0800
To: Lisa Dusseault <lisa@osafoundation.org>, Webdav WG <w3c-dist-auth@w3c.org>
From: Ted Hardie <hardie@qualcomm.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: Re: COPY of a binding onto another binding of same resource
X-Archived-At: http://www.w3.org/mid/p06020402bc8776b66df3@%5B129.46.227.161%5D
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8380
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040324174140.7CB55A066B@frink.w3.org>
Resent-Date: Wed, 24 Mar 2004 12:41:40 -0500 (EST)


At 9:11 AM -0800 03/24/2004, Lisa Dusseault wrote:
>When a user does a COPY or MOVE from one binding to another binding 
>to the same resource, this should be flagged as an error.  Since 
>this has to interoperate with existing clients that won't look at 
>the error body, the status code would have to stand alone.  409 is 
>already used for non-existent parent collections, so that can't be 
>reused.  Possibly 403 which in 2518 for COPY means "_ The source and 
>destination URIs are the same."

Unfortunately, I think it is pretty clear that the source and 
destination URIs are not
the same; the resource to which they are bound is the same.  Some other error
condition (4xx "Source and target bound to the same resource"?) seems more
appropriate to me.
			regards,
				Ted



From w3c-dist-auth-request@w3.org  Wed Mar 24 12:42:20 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08674
	for <webdav-archive@lists.ietf.org>; Wed, 24 Mar 2004 12:42:19 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id AED83A0A08; Wed, 24 Mar 2004 12:42:05 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id A1981A0A08
	for <w3c-dist-auth@listhub.w3.org>; Wed, 24 Mar 2004 12:41:50 -0500 (EST)
Received: from numenor.qualcomm.com ([129.46.51.58])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B6CGs-0000uc-Dd
	for w3c-dist-auth@w3c.org; Wed, 24 Mar 2004 12:34:30 -0500
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2OHWb5P026869
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 24 Mar 2004 09:32:37 -0800 (PST)
Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161])
	by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2OHWZVl019041;
	Wed, 24 Mar 2004 09:32:35 -0800 (PST)
Mime-Version: 1.0
X-Sender: hardie@mage.qualcomm.com
Message-Id: <p06020401bc8774d9fe1d@[129.46.227.161]>
In-Reply-To: <19B65246-7DB3-11D8-9DC8-000A95B2BB72@osafoundation.org>
References: 
 <OFF9933575.AF301A7E-ON85256E5C.0069DA11-85256E5C.006AA750@us.ibm.com>
 <405C196C.1030609@gmx.de>
 <E80FC418-7C3C-11D8-BB68-000A95B2BB72@osafoundation.org>
 <405F4BD5.5070302@gmx.de>
 <19B65246-7DB3-11D8-9DC8-000A95B2BB72@osafoundation.org>
Date: Wed, 24 Mar 2004 09:32:33 -0800
To: Lisa Dusseault <lisa@osafoundation.org>,
        Julian Reschke <julian.reschke@gmx.de>
From: Ted Hardie <hardie@qualcomm.com>
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>,
        Webdav WG <w3c-dist-auth@w3c.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/p06020401bc8774d9fe1d@%5B129.46.227.161%5D
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8381
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040324174205.AED83A0A08@frink.w3.org>
Resent-Date: Wed, 24 Mar 2004 12:42:05 -0500 (EST)


At 8:48 AM -0800 03/24/2004, Lisa Dusseault wrote:
>I suggest adding the following text to the Bind draft:
>
>"Methods that create a new resource (MKCOL, MKWORKSPACE, MKACTIVITY, 
>PUT when the destination is unbound) each create only one binding 
>and one resource.  Methods that create a new binding (BIND) leave 
>other bindings unaffected.
>
>"The following methods MUST have an identical result on every 
>binding to a resource, regardless of which binding is addressed:
>  - GET, PUT (to an existing binding), OPTIONS, HEAD.
>  - PROPPATCH, LOCK, UNLOCK
>  - all the methods defined in RFC3253 (except the ones that create a 
>new resource)

It strikes me that just listing them out from RFC 3253 would be useful here,
even if redundant, as it would eliminate any confusion on exactly which ones
are meant.

>  - ORDERPATCH
>  - ACL
>
>"The following methods have a result that only affects the binding 
>that is addressed, and don't affect other bindings to the same 
>resource: REBIND, UNBIND.

For the custom live properties, could PROPPATCH have an effect that 
affects only
the binding address (as noted below, implementations MAY define custom live
properties which have different values on different bindings)?


>MOVE, COPY and DELETE have special behavior described in detail in 
>sections 2.3 to 2.5.
>
>"The REPORT and PROPFIND methods could conceivably provide different 
>information depending on which binding to a resource is addressed 
>but by default they return the same information regardless of 
>binding.  The definition of each property or report ought to make 
>clear if this property or report diverges from the default.

I'm trying to work through the implications of this, and having a bit 
of trouble.
Does this imply that a method generating this must be applied both to the
binding against which it was targeted and against some other binding to test
this?  or does it imply some mechanism of indicating that a property is
capable fo divergence?  In the second case, how is that discovered/stored?


>  All reports defined in RFC3253 and the ACL RFC return the same 
>result for any binding to the same resource.  All (live) properties 
>defined in RFC2518, RFC3253, RFC3648 and the ACL RFC MUST have the 
>same value appearing on all bindings to the same resource. All dead 
>properties MUST appear the same on all bindings to the same 
>resource. An implementation MAY define custom live properties which 
>have different values on different bindings to the same resource."
>
>---
>
>This text is intended to supplement the model description by making 
>requirements on implementations to encourage them to behave 
>consistently, and to clear up confusion in applying the model in 
>specific cases.
>
>Lisa
>
>
>On Mar 22, 2004, at 12:25 PM, Julian Reschke wrote:
>
>>Lisa Dusseault wrote:
>>
>>>This is definitely an improvement.  However, I still  have some 
>>>issues -- the interaction between bindings and locks is still 
>>>unclear.  The spec needs to clearly say that
>>>  - if one binding is locked, then every binding is locked (with 
>>>the same lock token)
>>
>>No, the bindings aren't locked, the *resource* is (RFC2518).
>>
>>>  - All bindings to the same resource MUST support the same 
>>>features (e.g. locking)
>>
>>The bindings themselves do not support anything; the resource they 
>>are mapped to do. As they are mapped to the same resource, the same 
>>features are available.
>>
>>>  - All bindings to the same resource MUST show the same values for 
>>>live properties defined in RFC2518, RFC3253, RFC3648 and the ACL 
>>>RFC.
>>
>>Same. You're communicating with the resource, not particular bindings.
>>
>>>Unless my understanding of the intent is wrong...?  In which case, 
>>>it needs to clarify some other way.
>>
>>I'd say all of this follows from section 1, paragraphs 4 
>>(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-04.html#rfc.section.1.p.4>) 
>>to 6:
>>
>>"The BIND method defined here provides a mechanism for allowing 
>>clients to create alternative access paths to existing WebDAV 
>>resources. HTTP [RFC2616] and WebDAV [RFC2518]  methods are able to 
>>work because there are mappings between URIs and resources. A 
>>method is addressed to a URI, and the server follows the mapping 
>>from that URI to a resource, applying the method to that resource. 
>>Multiple URIs may be mapped to the same resource, but until now 
>>there has been no way for clients to create additional URIs mapped 
>>to existing resources.
>>
>>BIND lets clients associate a new URI with an existing WebDAV 
>>resource, and this URI can then be used to submit requests to the 
>>resource. Since URIs of WebDAV resources are hierarchical, and 
>>correspond to a hierarchy of collections in resource space, the 
>>BIND method also has the effect of adding the resource to a 
>>collection. As new URIs are associated with the resource, it 
>>appears in additional collections.
>>
>>A BIND request does not create a new resource, but simply makes 
>>available a new URI for submitting requests to an existing 
>>resource. The new URI is indistinguishable from any other URI when 
>>submitting a request to a resource. Only one round trip is needed 
>>to submit a request to the intended target. Servers are required to 
>>enforce the integrity of the relationships between the new URIs and 
>>the resources associated with them. Consequently, it may be very 
>>costly for servers to support BIND requests that cross server 
>>boundaries."
>>
>>At this point I really don't know how to improve that description 
>>(except by adding "we mean it -- it's really just another name 
>>mapped to the same resource" :-). If you think that this 
>>introduction needs to be improved, please make a concrete proposal.
>>
>>Does anybody else feel that this is unclear?
>>
>>
>>Regards. Julian
>>
>>--
>><green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Wed Mar 24 12:48:45 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09014
	for <webdav-archive@lists.ietf.org>; Wed, 24 Mar 2004 12:48:45 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 0CB15A082D; Wed, 24 Mar 2004 12:48:37 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id C0C22A082D
	for <w3c-dist-auth@listhub.w3.org>; Wed, 24 Mar 2004 12:48:28 -0500 (EST)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B6CM7-0001jd-PR
	for w3c-dist-auth@w3c.org; Wed, 24 Mar 2004 12:39:56 -0500
Received: (qmail 21118 invoked by uid 65534); 24 Mar 2004 17:38:18 -0000
Received: from p50824933.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.73.51)
  by mail.gmx.net (mp002) with SMTP; 24 Mar 2004 18:38:18 +0100
X-Authenticated: #1915285
Message-ID: <4061C788.60802@gmx.de>
Date: Wed, 24 Mar 2004 18:38:16 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
References: <543EB0EE-7DB6-11D8-9DC8-000A95B2BB72@osafoundation.org>
In-Reply-To: <543EB0EE-7DB6-11D8-9DC8-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: COPY of a binding onto another binding of same resource
X-Archived-At: http://www.w3.org/mid/4061C788.60802@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8382
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040324174837.0CB15A082D@frink.w3.org>
Resent-Date: Wed, 24 Mar 2004 12:48:37 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:
> 
> When a user does a COPY or MOVE from one binding to another binding to 
> the same resource, this should be flagged as an error.  Since this has 
> to interoperate with existing clients that won't look at the error body, 
> the status code would have to stand alone.  409 is already used for 
> non-existent parent collections, so that can't be reused.  Possibly 403 
> which in 2518 for COPY means "_ The source and destination URIs are the 
> same."

Why would that be an error?

If I have two bindings b1 and b2 to the same resource B, MOVE b1 -> b2 
will either fail (for Overwrite: F) or will first remove binding b2, 
then execute the rename. The result will be that there'll be one 
remaining binding (b2).

For the same situation, COPY seems to be no-op. Dead properties and 
content will be "replaced" by their current values (with possible side 
effects on ETag and so on...).

What am I missing?

Regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Mar 24 13:10:52 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10415
	for <webdav-archive@lists.ietf.org>; Wed, 24 Mar 2004 13:10:47 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 963BDA05C3; Wed, 24 Mar 2004 13:10:09 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 3E4CEA1379
	for <w3c-dist-auth@listhub.w3.org>; Wed, 24 Mar 2004 13:10:02 -0500 (EST)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B6CdA-000572-BB
	for w3c-dist-auth@w3c.org; Wed, 24 Mar 2004 12:57:32 -0500
Received: (qmail 13671 invoked by uid 65534); 24 Mar 2004 17:56:00 -0000
Received: from p50824933.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.73.51)
  by mail.gmx.net (mp016) with SMTP; 24 Mar 2004 18:56:00 +0100
X-Authenticated: #1915285
Message-ID: <4061CBAF.6090205@gmx.de>
Date: Wed, 24 Mar 2004 18:55:59 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ted Hardie <hardie@qualcomm.com>
Cc: Lisa Dusseault <lisa@osafoundation.org>,
        Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>,
        Webdav WG <w3c-dist-auth@w3c.org>
References: <OFF9933575.AF301A7E-ON85256E5C.0069DA11-85256E5C.006AA750@us.ibm.com> <405C196C.1030609@gmx.de> <E80FC418-7C3C-11D8-BB68-000A95B2BB72@osafoundation.org> <405F4BD5.5070302@gmx.de> <19B65246-7DB3-11D8-9DC8-000A95B2BB72@osafoundation.org> <p06020401bc8774d9fe1d@[129.46.227.161]>
In-Reply-To: <p06020401bc8774d9fe1d@[129.46.227.161]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/4061CBAF.6090205@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8383
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040324181009.963BDA05C3@frink.w3.org>
Resent-Date: Wed, 24 Mar 2004 13:10:09 -0500 (EST)
Content-Transfer-Encoding: 7bit


Ted Hardie wrote:

> For the custom live properties, could PROPPATCH have an effect that 
> affects only
> the binding address (as noted below, implementations MAY define custom live
> properties which have different values on different bindings)?

Nope, and I absolutely disagree that live properties may vary depending 
on access path.

> I'm trying to work through the implications of this, and having a bit of 
> trouble.
> Does this imply that a method generating this must be applied both to the
> binding against which it was targeted and against some other binding to 
> test
> this?  or does it imply some mechanism of indicating that a property is
> capable fo divergence?  In the second case, how is that discovered/stored?

There must not be any divergence.

 > ...

Regards, Julian


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



From w3c-dist-auth-request@w3.org  Wed Mar 24 14:57:25 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16575
	for <webdav-archive@lists.ietf.org>; Wed, 24 Mar 2004 14:57:24 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E2266A16E6; Wed, 24 Mar 2004 14:57:13 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id B049EA16E6
	for <w3c-dist-auth@listhub.w3.org>; Wed, 24 Mar 2004 14:57:05 -0500 (EST)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B6EQO-0002qS-TB
	for w3c-dist-auth@w3c.org; Wed, 24 Mar 2004 14:52:29 -0500
Received: (qmail 27551 invoked by uid 65534); 24 Mar 2004 19:50:25 -0000
Received: from pD950C388.dip.t-dialin.net (EHLO gmx.de) (217.80.195.136)
  by mail.gmx.net (mp004) with SMTP; 24 Mar 2004 20:50:25 +0100
X-Authenticated: #1915285
Message-ID: <4061E667.5050602@gmx.de>
Date: Wed, 24 Mar 2004 20:49:59 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>,
        Ted Hardie <hardie@qualcomm.com>, Webdav WG <w3c-dist-auth@w3c.org>
References: <OFF9933575.AF301A7E-ON85256E5C.0069DA11-85256E5C.006AA750@us.ibm.com> <405C196C.1030609@gmx.de> <E80FC418-7C3C-11D8-BB68-000A95B2BB72@osafoundation.org> <405F4BD5.5070302@gmx.de> <19B65246-7DB3-11D8-9DC8-000A95B2BB72@osafoundation.org> <p06020401bc8774d9fe1d@[129.46.227.161]> <4061CBAF.6090205@gmx.de> <9014A50E-7DC2-11D8-9DC8-000A95B2BB72@osafoundation.org>
In-Reply-To: <9014A50E-7DC2-11D8-9DC8-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/4061E667.5050602@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8384
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040324195713.E2266A16E6@frink.w3.org>
Resent-Date: Wed, 24 Mar 2004 14:57:13 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:
>> Nope, and I absolutely disagree that live properties may vary 
>> depending on access path.
> 
> 
> I believe servers have already been implemented and deployed where the 
> live property can vary depending on access path.  For example, in order 
> to continue to maintain backward compatibility for a custom property 
> called "parent-path", the server would have to implement bindings in 
> such a way that "parent-path" was calculated from the request address.

...or it could make the decision not to maintain support for something 
that doesn't fit into the BIND model.

What's the use case for that property?

>>> I'm trying to work through the implications of this, and having a bit 
>>> of trouble.
>>> Does this imply that a method generating this must be applied both to 
>>> the
>>> binding against which it was targeted and against some other binding 
>>> to test
>>> this?  or does it imply some mechanism of indicating that a property is
>>> capable fo divergence?  In the second case, how is that 
>>> discovered/stored?
>>
>>
>> There must not be any divergence.
> 
> 
> I should have been more clear in my original text.  What I meant was 
> that when a new live property is specified (e.g. in an Internet-Draft / 
> RFC), the specification should indicate if the live property may have 
> different values on different bindings.  Otherwise, the assumption is 

No, it must not have different values based on the access path.

> that the live property must have the same value on all bindings.

Precisely.

> Similarly, when a new report is specified, readers may assume that it 
> behaves the same on all bindings, unless the specification says otherwise.

Yes, they should assume it behaves the same on all bindings. The REPORT 
method is defined to return information for the resource referenced by 
the request URI. The request URI really is just the access path and has 
no influence on the result.

> I never envisioned a need or utility in having clients apply methods to 
> multiple bindings to test this.  I did envision a mechanism to indicate 
> that a property may diverge on different bindings, but I propose this 
> should be in the specification where the property is defined.  So there 
> are no issues for discovery/storage.

Again, I think the concept of properties that vary on access path is 
incompatible with what we are doing here. In the model we're working in, 
  state only exists in WebDAV resources (where bindings belong to the 
state of the containing collection).

So if you have a property that is supposed to vary, it *per definition* 
can't belong to the resource itself, thus it'll be part of the parent 
collection's state (an example would be a "hidden" flag that's attached 
to each of the bindings contained in the collection).

I agree that in many cases the strong model used in BIND doesn't work 
well in all practical use cases (there's a reason why Unix symbolic 
links seem to be more popular then hard links). That's why the Advanced 
Collection activity of this working group has resulted in *several* 
specs. For instance, REDIRECTREF resources 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-latest.html>) 
*are* separate resources that can have their own metadata attached to 
it.  There was yet another planned thingy called "direct reference" (as 
far as I understand similar to redirectrefs minus the redirection step) 
that seems to more closely map to what you feel bindings should be 
doing. Maybe you want to pursue that project?

Regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Mar 24 16:48:43 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23922
	for <webdav-archive@lists.ietf.org>; Wed, 24 Mar 2004 16:48:43 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 2A0C7A157D; Wed, 24 Mar 2004 16:48:34 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id CE355A157D
	for <w3c-dist-auth@listhub.w3.org>; Wed, 24 Mar 2004 16:48:25 -0500 (EST)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B6DIv-0002Za-E0
	for w3c-dist-auth@w3c.org; Wed, 24 Mar 2004 13:40:41 -0500
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Received: from [192.168.1.100] ([198.144.201.116])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i2OIdPhV023086
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 24 Mar 2004 10:39:27 -0800
In-Reply-To: <4061CBAF.6090205@gmx.de>
References: <OFF9933575.AF301A7E-ON85256E5C.0069DA11-85256E5C.006AA750@us.ibm.com> <405C196C.1030609@gmx.de> <E80FC418-7C3C-11D8-BB68-000A95B2BB72@osafoundation.org> <405F4BD5.5070302@gmx.de> <19B65246-7DB3-11D8-9DC8-000A95B2BB72@osafoundation.org> <p06020401bc8774d9fe1d@[129.46.227.161]> <4061CBAF.6090205@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <9014A50E-7DC2-11D8-9DC8-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>,
        Ted Hardie <hardie@qualcomm.com>, Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 24 Mar 2004 10:39:20 -0800
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/9014A50E-7DC2-11D8-9DC8-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8385
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040324214834.2A0C7A157D@frink.w3.org>
Resent-Date: Wed, 24 Mar 2004 16:48:34 -0500 (EST)
Content-Transfer-Encoding: 7bit



On Mar 24, 2004, at 9:55 AM, Julian Reschke wrote:

> Ted Hardie wrote:
>
>> For the custom live properties, could PROPPATCH have an effect that 
>> affects only
>> the binding address (as noted below, implementations MAY define 
>> custom live
>> properties which have different values on different bindings)?
>
> Nope, and I absolutely disagree that live properties may vary 
> depending on access path.

I believe servers have already been implemented and deployed where the 
live property can vary depending on access path.  For example, in order 
to continue to maintain backward compatibility for a custom property 
called "parent-path", the server would have to implement bindings in 
such a way that "parent-path" was calculated from the request address.

>
>> I'm trying to work through the implications of this, and having a bit 
>> of trouble.
>> Does this imply that a method generating this must be applied both to 
>> the
>> binding against which it was targeted and against some other binding 
>> to test
>> this?  or does it imply some mechanism of indicating that a property 
>> is
>> capable fo divergence?  In the second case, how is that 
>> discovered/stored?
>
> There must not be any divergence.

I should have been more clear in my original text.  What I meant was 
that when a new live property is specified (e.g. in an Internet-Draft / 
RFC), the specification should indicate if the live property may have 
different values on different bindings.  Otherwise, the assumption is 
that the live property must have the same value on all bindings.  
Similarly, when a new report is specified, readers may assume that it 
behaves the same on all bindings, unless the specification says 
otherwise.

I never envisioned a need or utility in having clients apply methods to 
multiple bindings to test this.  I did envision a mechanism to indicate 
that a property may diverge on different bindings, but I propose this 
should be in the specification where the property is defined.  So there 
are no issues for discovery/storage.

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



From w3c-dist-auth-request@w3.org  Wed Mar 24 16:51:31 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24043
	for <webdav-archive@lists.ietf.org>; Wed, 24 Mar 2004 16:51:31 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B2DAFA12FF; Wed, 24 Mar 2004 16:51:21 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 0B915A16B2
	for <w3c-dist-auth@listhub.w3.org>; Wed, 24 Mar 2004 16:51:14 -0500 (EST)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B6D3o-0000Vy-5e
	for w3c-dist-auth@w3c.org; Wed, 24 Mar 2004 13:25:04 -0500
Received: (qmail 24679 invoked by uid 65534); 24 Mar 2004 18:23:32 -0000
Received: from p50824933.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.73.51)
  by mail.gmx.net (mp016) with SMTP; 24 Mar 2004 19:23:32 +0100
X-Authenticated: #1915285
Message-ID: <4061D222.6090603@gmx.de>
Date: Wed, 24 Mar 2004 19:23:30 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
References: <543EB0EE-7DB6-11D8-9DC8-000A95B2BB72@osafoundation.org>
In-Reply-To: <543EB0EE-7DB6-11D8-9DC8-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: COPY of a binding onto another binding of same resource
X-Archived-At: http://www.w3.org/mid/4061D222.6090603@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8386
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040324215121.B2DAFA12FF@frink.w3.org>
Resent-Date: Wed, 24 Mar 2004 16:51:21 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> 
> When a user does a COPY or MOVE from one binding to another binding to 
> the same resource, this should be flagged as an error.  Since this has 
> to interoperate with existing clients that won't look at the error body, 
> the status code would have to stand alone.  409 is already used for 
> non-existent parent collections, so that can't be reused.  Possibly 403 
> which in 2518 for COPY means "_ The source and destination URIs are the 
> same."

...btw, I disagree with the sentiment that specific new error conditions 
must use HTTP status codes different from any status code used 
previously for that operation (in fact, the whole point is that by 
sending the same status code like for another situation I can trigger 
the same error recovery/treatment on the client).

In particular, note that 409 can occur for many other reasons, and a 
client that somehow equates 409 with "parent collection does not exist" 
is plain broken (this is why it would be a good thing ifg RFC2518bis 
associated that with a specific precondition name).

The advantage of RFC3253's HTTP status code / DAV:error body extension 
is that existing clients will continue to see well-defined HTTP status 
codes (usually defined by RFC2616, not RFC2518), while new, 
WebDAV-specific clients can take advantage of additional information 
sent with the body (for instance, in ACL this enables the client to 
state which privilege was missing causing the 403 Access Denied).


Julian


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



From w3c-dist-auth-request@w3.org  Wed Mar 24 17:04:56 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24606
	for <webdav-archive@lists.ietf.org>; Wed, 24 Mar 2004 17:04:56 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 2C35FA167B; Wed, 24 Mar 2004 17:04:46 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 3450BA16BC
	for <w3c-dist-auth@listhub.w3.org>; Wed, 24 Mar 2004 17:04:38 -0500 (EST)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B6CaB-0004cF-QC
	for w3c-dist-auth@w3c.org; Wed, 24 Mar 2004 12:54:28 -0500
Received: (qmail 13737 invoked by uid 65534); 24 Mar 2004 17:52:55 -0000
Received: from p50824933.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.73.51)
  by mail.gmx.net (mp002) with SMTP; 24 Mar 2004 18:52:55 +0100
X-Authenticated: #1915285
Message-ID: <4061CAF6.4050803@gmx.de>
Date: Wed, 24 Mar 2004 18:52:54 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>,
        Webdav WG <w3c-dist-auth@w3c.org>
References: <OFF9933575.AF301A7E-ON85256E5C.0069DA11-85256E5C.006AA750@us.ibm.com> <405C196C.1030609@gmx.de> <E80FC418-7C3C-11D8-BB68-000A95B2BB72@osafoundation.org> <405F4BD5.5070302@gmx.de> <19B65246-7DB3-11D8-9DC8-000A95B2BB72@osafoundation.org>
In-Reply-To: <19B65246-7DB3-11D8-9DC8-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Issues remaining with Bind draft
X-Archived-At: http://www.w3.org/mid/4061CAF6.4050803@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8387
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040324220446.2C35FA167B@frink.w3.org>
Resent-Date: Wed, 24 Mar 2004 17:04:46 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> I suggest adding the following text to the Bind draft:

Lisa, I appreciate the effort to provide additional wording. However, in 
each of the cases I think it's either unnecessary (because the behaviour 
follows from the very nature of bindings), or actually incorrect.

In particular:

> "Methods that create a new resource (MKCOL, MKWORKSPACE, MKACTIVITY,  
> PUT when the destination is unbound) each create only one binding and  
> one resource.  Methods that create a new binding (BIND) leave other  

*Usually* that's true. However, servers can do what they want. There's 
nothing preventing a server to create *two* resources and bindings upon 
each PUT (for instance, that may be the case for a server that has 
"source" and "transformed" content in different namespaces).

> bindings unaffected.

 From 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#METHOD_BIND>:

"The BIND method modifies the collection identified by the Request-URI, 
by adding a new binding from the segment specified in the BIND body to 
the resource identified in the BIND body."

This is the purpose of the BIND method, and I really don't want to get 
into the business of enumerating what a method *doesn't* do.

> "The following methods MUST have an identical result on every binding  
> to a resource, regardless of which binding is addressed:
>  - GET, PUT (to an existing binding), OPTIONS, HEAD.
>  - PROPPATCH, LOCK, UNLOCK
>  - all the methods defined in RFC3253 (except the ones that create a  
> new resource)
>  - ORDERPATCH
>  - ACL

Which of course provokes the question if there are any methods that do 
*not* have that property. Which of RFC3253's methods do you think have 
that property? And why do you feel that for instance BIND and REBIND 
don't have that property?

The only difference I'm aware of is that sometimes some bindings are 
protected by a lock, while other's aren't. In those cases only namespace 
operations that will affect these URIs behave differently.

> "The following methods have a result that only affects the binding that  
> is addressed, and don't affect other bindings to the same resource:  
> REBIND, UNBIND.  MOVE, COPY and DELETE have special behavior described  
> in detail in sections 2.3 to 2.5.

That doesn't offer any additional information, right? It's just a 
forward pointer to information that follows later.

> "The REPORT and PROPFIND methods could conceivably provide different  
> information depending on which binding to a resource is addressed but  
> by default they return the same information regardless of binding.  The

Let's see...

<http://greenbytes.de/tech/webdav/rfc2518.html#METHOD_PROPFIND>:

"The PROPFIND method retrieves properties defined on the resource 
identified by the Request-URI...."

<http://greenbytes.de/tech/webdav/rfc3253.html#METHOD_REPORT>:

"A REPORT request is an extensible mechanism for obtaining information 
about a resource."

So no, they should provide identical information.  We're getting 
information from resources, and as long as the resource is the same, the 
information is the same. The access path doesn't matter.

> definition of each property or report ought to make clear if this  
> property or report diverges from the default.  All reports defined in  
> RFC3253 and the ACL RFC return the same result for any binding to the  
> same resource.  All (live) properties defined in RFC2518, RFC3253,  
> RFC3648 and the ACL RFC MUST have the same value appearing on all  
> bindings to the same resource. All dead properties MUST appear the same  
> on all bindings to the same resource. An implementation MAY define  
> custom live properties which have different values on different  
> bindings to the same resource."

I strongly disagree -- a live property that varies based on the request 
URI IMHO is a violation of the binding semantics defined in this spec.

> This text is intended to supplement the model description by making  
> requirements on implementations to encourage them to behave  
> consistently, and to clear up confusion in applying the model in  
> specific cases.

Regards, Julian

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



From w3c-dist-auth-request@w3.org  Wed Mar 24 17:07:20 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24688
	for <webdav-archive@lists.ietf.org>; Wed, 24 Mar 2004 17:07:20 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id D0975A0F5E; Wed, 24 Mar 2004 17:06:53 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id A6382A0F5E
	for <w3c-dist-auth@listhub.w3.org>; Wed, 24 Mar 2004 17:06:45 -0500 (EST)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B6Bro-0004c6-6q
	for w3c-dist-auth@w3c.org; Wed, 24 Mar 2004 12:08:36 -0500
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: <w3c-dist-auth@w3c.org>
Received: from [192.168.1.100] ([198.144.201.116])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i2OH86hV016924
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <w3c-dist-auth@w3c.org>; Wed, 24 Mar 2004 09:08:12 -0800
Mime-Version: 1.0 (Apple Message framework v613)
Content-Transfer-Encoding: 7bit
Message-Id: <CE298388-7DB5-11D8-9DC8-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 24 Mar 2004 09:08:00 -0800
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: More open questions with bind - permissions, multi-resource operations
X-Archived-At: http://www.w3.org/mid/CE298388-7DB5-11D8-9DC8-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8388
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040324220653.D0975A0F5E@frink.w3.org>
Resent-Date: Wed, 24 Mar 2004 17:06:53 -0500 (EST)
Content-Transfer-Encoding: 7bit



What permissions are required in order to perform a BIND request?  I 
would think  that permissions for UNBIND and REBIND are identical to 
permissions for DELETE and MOVE respectively, but this should be 
stated.

Are there issues with CHECKIN of an activity changing multiple bindings 
to the same resource?  MERGE?  Are there any other methods that can 
make changes to a number of resources at once, and thus might have 
problems addressing several bindings to the same resource?

Lisa



From w3c-dist-auth-request@w3.org  Thu Mar 25 03:41:39 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09247
	for <webdav-archive@lists.ietf.org>; Thu, 25 Mar 2004 03:41:39 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B9649A099F; Thu, 25 Mar 2004 03:41:40 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 7DBE3A099F
	for <w3c-dist-auth@listhub.w3.org>; Thu, 25 Mar 2004 03:41:37 -0500 (EST)
Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B6QQZ-0004KF-B5
	for w3c-dist-auth@w3c.org; Thu, 25 Mar 2004 03:41:27 -0500
Received: (qmail 13372 invoked by uid 65534); 25 Mar 2004 08:40:51 -0000
Received: from pD950C386.dip.t-dialin.net (EHLO gmx.de) (217.80.195.134)
  by mail.gmx.net (mp005) with SMTP; 25 Mar 2004 09:40:51 +0100
X-Authenticated: #1915285
Message-ID: <40629AFF.5000106@gmx.de>
Date: Thu, 25 Mar 2004 09:40:31 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
References: <CE298388-7DB5-11D8-9DC8-000A95B2BB72@osafoundation.org>
In-Reply-To: <CE298388-7DB5-11D8-9DC8-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: More open questions with bind - permissions, multi-resource operations
X-Archived-At: http://www.w3.org/mid/40629AFF.5000106@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8389
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040325084140.B9649A099F@frink.w3.org>
Resent-Date: Thu, 25 Mar 2004 03:41:40 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> What permissions are required in order to perform a BIND request?  I 

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.html#PRIVILEGE_bind>

> would think  that permissions for UNBIND and REBIND are identical to 
> permissions for DELETE and MOVE respectively, but this should be stated.

They should be identical, but I don't agree it needs to be stated in 
this document. The ACL spec seems to be clear enough.

> Are there issues with CHECKIN of an activity changing multiple bindings 
> to the same resource?  MERGE?  Are there any other methods that can make 
> changes to a number of resources at once, and thus might have problems 
> addressing several bindings to the same resource?

Can you be more specific? I fail to see a problem so far...

Julian

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



From w3c-dist-auth-request@w3.org  Thu Mar 25 04:27:33 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10760
	for <webdav-archive@lists.ietf.org>; Thu, 25 Mar 2004 04:27:27 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 8160DA162B; Thu, 25 Mar 2004 04:27:28 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 73C0FA162B
	for <w3c-dist-auth@listhub.w3.org>; Thu, 25 Mar 2004 04:27:23 -0500 (EST)
Received: from [217.5.201.10] (helo=greenbytes.de)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B6R74-0005hg-1G
	for w3c-dist-auth@w3c.org; Thu, 25 Mar 2004 04:25:22 -0500
Received: from [192.168.1.26] ([192.168.1.26])
	(authenticated user se@greenbytes.de)
	by greenbytes.de (greenbytes.de)
	(Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.0.1.R)
	with ESMTP id md50000004193.msg
	for <w3c-dist-auth@w3c.org>; Thu, 25 Mar 2004 10:24:26 +0100
In-Reply-To: <CE298388-7DB5-11D8-9DC8-000A95B2BB72@osafoundation.org>
References: <CE298388-7DB5-11D8-9DC8-000A95B2BB72@osafoundation.org>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <371F2E02-7E3E-11D8-BB64-00039384827E@greenbytes.de>
Content-Transfer-Encoding: 7bit
Cc: Webdav WG <w3c-dist-auth@w3c.org>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Thu, 25 Mar 2004 10:24:28 +0100
To: Lisa Dusseault <lisa@osafoundation.org>
X-Mailer: Apple Mail (2.613)
X-Authenticated-Sender: se@greenbytes.de
X-Spam-Processed: greenbytes.de, Thu, 25 Mar 2004 10:24:26 +0100
	(not processed: message from valid local sender)
X-MDRemoteIP: 192.168.1.26
X-Return-Path: stefan.eissing@greenbytes.de
X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org
Subject: Re: More open questions with bind - permissions, multi-resource operations
X-Archived-At: http://www.w3.org/mid/371F2E02-7E3E-11D8-BB64-00039384827E@greenbytes.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8390
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040325092728.8160DA162B@frink.w3.org>
Resent-Date: Thu, 25 Mar 2004 04:27:28 -0500 (EST)
Content-Transfer-Encoding: 7bit



Am 24.03.2004 um 18:08 schrieb Lisa Dusseault:
>
> What permissions are required in order to perform a BIND request?  I 
> would think  that permissions for UNBIND and REBIND are identical to 
> permissions for DELETE and MOVE respectively, but this should be 
> stated.

I think this is well explained in the current ACL spec. Since BIND 
creates a new member URL in a
collection and the DAV:bind privilege controls who is allowed to create 
new member URLs in
a collection, it seems like a perfect match.

Stefan




From w3c-dist-auth-request@w3.org  Thu Mar 25 15:39:32 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19721
	for <webdav-archive@lists.ietf.org>; Thu, 25 Mar 2004 15:39:31 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 62B73A1078; Thu, 25 Mar 2004 15:39:33 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 86E79A1603
	for <w3c-dist-auth@listhub.w3.org>; Thu, 25 Mar 2004 15:39:29 -0500 (EST)
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B6bdR-00065X-8e
	for w3c-dist-auth@w3.org; Thu, 25 Mar 2004 15:39:29 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19686;
	Thu, 25 Mar 2004 15:39:26 -0500 (EST)
Message-Id: <200403252039.PAA19686@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: w3c-dist-auth@w3.org
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Date: Thu, 25 Mar 2004 15:39:26 -0500
Subject: I-D ACTION:draft-ietf-webdav-bind-05.txt
X-Archived-At: http://www.w3.org/mid/200403252039.PAA19686@ietf.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8391
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040325203933.62B73A1078@frink.w3.org>
Resent-Date: Thu, 25 Mar 2004 15:39:33 -0500 (EST)


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF.

	Title		: Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)
	Author(s)	: G. Clemm, et al.
	Filename	: draft-ietf-webdav-bind-05.txt
	Pages		: 32
	Date		: 2004-3-25
	
This specification defines bindings, and the BIND method for creating 
multiple bindings to the same resource.  Creating a new binding to a 
resource causes at least one new URI to be mapped to that resource.  
Servers are required to insure the integrity of any bindings that they 
allow to be created.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-webdav-bind-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-webdav-bind-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2004-3-25154758.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID:	<2004-3-25154758.I-D@ietf.org>

--OtherAccess--

--NextPart--




From w3c-dist-auth-request@w3.org  Thu Mar 25 15:59:29 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22579
	for <webdav-archive@lists.ietf.org>; Thu, 25 Mar 2004 15:59:29 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 48D78A0C9D; Thu, 25 Mar 2004 15:59:30 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id DAE0DA0C9D
	for <w3c-dist-auth@listhub.w3.org>; Thu, 25 Mar 2004 15:59:23 -0500 (EST)
Received: from mail.gmx.net ([213.165.64.20])
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B6bwh-0002ja-Ec
	for w3c-dist-auth@w3.org; Thu, 25 Mar 2004 15:59:23 -0500
Received: (qmail 26827 invoked by uid 65534); 25 Mar 2004 20:58:49 -0000
Received: from pD950C386.dip.t-dialin.net (EHLO gmx.de) (217.80.195.134)
  by mail.gmx.net (mp011) with SMTP; 25 Mar 2004 21:58:49 +0100
X-Authenticated: #1915285
Message-ID: <406347FA.9070700@gmx.de>
Date: Thu, 25 Mar 2004 21:58:34 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: w3c-dist-auth@w3.org
References: <200403252039.PAA19686@ietf.org>
In-Reply-To: <200403252039.PAA19686@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: I-D ACTION:draft-ietf-webdav-bind-05.txt
X-Archived-At: http://www.w3.org/mid/406347FA.9070700@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8392
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040325205930.48D78A0C9D@frink.w3.org>
Resent-Date: Thu, 25 Mar 2004 15:59:30 -0500 (EST)
Content-Transfer-Encoding: 7bit


Hi,

this draft contains the latest changes discussed here on the list (see 
issues (see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-05.html#rfc.issue.6_lock_behaviour> 
and 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-05.html#rfc.issue.6_precondition_binding_allowed>).

Geoff and I feel that this draft is ready for a working group last call. 
Any new issues that require spec changes then can be made in the draft 
that we submit to IESG last call.

Best regards,

Julian

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



From w3c-dist-auth-request@w3.org  Thu Mar 25 17:48:30 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29356
	for <webdav-archive@lists.ietf.org>; Thu, 25 Mar 2004 17:48:30 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B4A32A1B8B; Thu, 25 Mar 2004 17:48:26 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 825A1A0621
	for <w3c-dist-auth@listhub.w3.org>; Thu, 25 Mar 2004 17:48:07 -0500 (EST)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B6ddM-0007ij-RV
	for w3c-dist-auth@w3c.org; Thu, 25 Mar 2004 17:47:33 -0500
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i2PMl5hV015381
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Thu, 25 Mar 2004 14:47:06 -0800
In-Reply-To: <4061E667.5050602@gmx.de>
References: <OFF9933575.AF301A7E-ON85256E5C.0069DA11-85256E5C.006AA750@us.ibm.com> <405C196C.1030609@gmx.de> <E80FC418-7C3C-11D8-BB68-000A95B2BB72@osafoundation.org> <405F4BD5.5070302@gmx.de> <19B65246-7DB3-11D8-9DC8-000A95B2BB72@osafoundation.org> <p06020401bc8774d9fe1d@[129.46.227.161]> <4061CBAF.6090205@gmx.de> <9014A50E-7DC2-11D8-9DC8-000A95B2BB72@osafoundation.org> <4061E667.5050602@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <53680C68-7EAE-11D8-A4F9-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>,
        Ted Hardie <hardie@qualcomm.com>, Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Thu, 25 Mar 2004 14:46:59 -0800
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Properties of bindings (was Re: Issues remaining with Bind draft)
X-Archived-At: http://www.w3.org/mid/53680C68-7EAE-11D8-A4F9-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8393
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040325224826.B4A32A1B8B@frink.w3.org>
Resent-Date: Thu, 25 Mar 2004 17:48:26 -0500 (EST)
Content-Transfer-Encoding: 7bit


I found a reference to the "parentname" property, defined for Exchange  
2000 and Exchange 2003 in the "DAV:" namespace (no big surprise there  
though it's unfortunate):

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/ 
wss/_cdo_schema_dav.asp

The "hidden" flag you suggest would also be interesting as a binding  
property, as was suggested in this Internet-Draft (also implemented in  
Microsoft servers):

http://www.ics.uci.edu/~ejw/authoring/props/draft-hopmann-collection- 
props-00.txt

As you say, it could also be implemented on the parent collection as a  
list of hidden bindings within the collection, but the cat's out of the  
bag there for at least some implementations.  I don't see the harm in  
allowing some custom live properties to vary on bindings. Any  
implementation that didn't have the ability to calculate a live  
property based on a binding wouldn't have to do so.

Lisa

On Mar 24, 2004, at 11:49 AM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>>> Nope, and I absolutely disagree that live properties may vary  
>>> depending on access path.
>> I believe servers have already been implemented and deployed where  
>> the live property can vary depending on access path.  For example, in  
>> order to continue to maintain backward compatibility for a custom  
>> property called "parent-path", the server would have to implement  
>> bindings in such a way that "parent-path" was calculated from the  
>> request address.
>
> ...or it could make the decision not to maintain support for something  
> that doesn't fit into the BIND model.
>
> What's the use case for that property?
>
>>>> I'm trying to work through the implications of this, and having a  
>>>> bit of trouble.
>>>> Does this imply that a method generating this must be applied both  
>>>> to the
>>>> binding against which it was targeted and against some other  
>>>> binding to test
>>>> this?  or does it imply some mechanism of indicating that a  
>>>> property is
>>>> capable fo divergence?  In the second case, how is that  
>>>> discovered/stored?
>>>
>>>
>>> There must not be any divergence.
>> I should have been more clear in my original text.  What I meant was  
>> that when a new live property is specified (e.g. in an Internet-Draft  
>> / RFC), the specification should indicate if the live property may  
>> have different values on different bindings.  Otherwise, the  
>> assumption is
>
> No, it must not have different values based on the access path.
>
>> that the live property must have the same value on all bindings.
>
> Precisely.
>
>> Similarly, when a new report is specified, readers may assume that it  
>> behaves the same on all bindings, unless the specification says  
>> otherwise.
>
> Yes, they should assume it behaves the same on all bindings. The  
> REPORT method is defined to return information for the resource  
> referenced by the request URI. The request URI really is just the  
> access path and has no influence on the result.
>
>> I never envisioned a need or utility in having clients apply methods  
>> to multiple bindings to test this.  I did envision a mechanism to  
>> indicate that a property may diverge on different bindings, but I  
>> propose this should be in the specification where the property is  
>> defined.  So there are no issues for discovery/storage.
>
> Again, I think the concept of properties that vary on access path is  
> incompatible with what we are doing here. In the model we're working  
> in,  state only exists in WebDAV resources (where bindings belong to  
> the state of the containing collection).
>
> So if you have a property that is supposed to vary, it *per  
> definition* can't belong to the resource itself, thus it'll be part of  
> the parent collection's state (an example would be a "hidden" flag  
> that's attached to each of the bindings contained in the collection).
>
> I agree that in many cases the strong model used in BIND doesn't work  
> well in all practical use cases (there's a reason why Unix symbolic  
> links seem to be more popular then hard links). That's why the  
> Advanced Collection activity of this working group has resulted in  
> *several* specs. For instance, REDIRECTREF resources  
> (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref- 
> protocol-latest.html>) *are* separate resources that can have their  
> own metadata attached to it.  There was yet another planned thingy  
> called "direct reference" (as far as I understand similar to  
> redirectrefs minus the redirection step) that seems to more closely  
> map to what you feel bindings should be doing. Maybe you want to  
> pursue that project?
>
> Regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From w3c-dist-auth-request@w3.org  Thu Mar 25 18:05:39 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00361
	for <webdav-archive@lists.ietf.org>; Thu, 25 Mar 2004 18:05:38 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id DFB64A0B87; Thu, 25 Mar 2004 18:05:40 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 6555EA0B87
	for <w3c-dist-auth@listhub.w3.org>; Thu, 25 Mar 2004 18:05:37 -0500 (EST)
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B6duq-0004Qo-W8
	for w3c-dist-auth@w3c.org; Thu, 25 Mar 2004 18:05:37 -0500
Received: (qmail 23053 invoked by uid 65534); 25 Mar 2004 23:05:02 -0000
Received: from pD950C386.dip.t-dialin.net (EHLO gmx.de) (217.80.195.134)
  by mail.gmx.net (mp022) with SMTP; 26 Mar 2004 00:05:02 +0100
X-Authenticated: #1915285
Message-ID: <40636584.1030005@gmx.de>
Date: Fri, 26 Mar 2004 00:04:36 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>,
        Ted Hardie <hardie@qualcomm.com>, Webdav WG <w3c-dist-auth@w3c.org>
References: <OFF9933575.AF301A7E-ON85256E5C.0069DA11-85256E5C.006AA750@us.ibm.com> <405C196C.1030609@gmx.de> <E80FC418-7C3C-11D8-BB68-000A95B2BB72@osafoundation.org> <405F4BD5.5070302@gmx.de> <19B65246-7DB3-11D8-9DC8-000A95B2BB72@osafoundation.org> <p06020401bc8774d9fe1d@[129.46.227.161]> <4061CBAF.6090205@gmx.de> <9014A50E-7DC2-11D8-9DC8-000A95B2BB72@osafoundation.org> <4061E667.5050602@gmx.de> <53680C68-7EAE-11D8-A4F9-000A95B2BB72@osafoundation.org>
In-Reply-To: <53680C68-7EAE-11D8-A4F9-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Properties of bindings (was Re: Issues remaining with Bind draft)
X-Archived-At: http://www.w3.org/mid/40636584.1030005@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8394
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040325230540.DFB64A0B87@frink.w3.org>
Resent-Date: Thu, 25 Mar 2004 18:05:40 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> I found a reference to the "parentname" property, defined for Exchange  
> 2000 and Exchange 2003 in the "DAV:" namespace (no big surprise there  
> though it's unfortunate):
> 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/ 
> wss/_cdo_schema_dav.asp

I fail to see the issue. It only means that when Microsoft decides to 
support the BIND draft, they'll have to re-think that design decision. 
Just because somebody in the past did a poor system design that is 
inherently incompatible with having multiple URIs for the same resource 
shouldn't prevent *us* from doing things right.

> The "hidden" flag you suggest would also be interesting as a binding  
> property, as was suggested in this Internet-Draft (also implemented in  
> Microsoft servers):
> 
> http://www.ics.uci.edu/~ejw/authoring/props/draft-hopmann-collection- 
> props-00.txt
> 
> As you say, it could also be implemented on the parent collection as a  
> list of hidden bindings within the collection, but the cat's out of the  
> bag there for at least some implementations.  I don't see the harm in  
> allowing some custom live properties to vary on bindings. Any  
> implementation that didn't have the ability to calculate a live  
> property based on a binding wouldn't have to do so.

The harm is that it's incompatible with the stated purpose of the spec 
-- specifying additional URIs to the *same* resource. Of course we can't 
prevent anybody from doing that, but it's against the stated purpose of 
the spec, and thus the spec shouldn't do anything which would encourage 
this kind of design.

BTW: the "hidden" flag in NTFS in fact is kept as part of the file 
resource, not of the binding. Thus, IIS in fact does the right thing in 
presenting this as property on the resource (well, they shouldn't have 
uses the DAV: namespace...).

To test that: create a file, create a second binding to that file 
(cygwin ln), show properties in Explorer for first binding, set 
"hidden", refresh window multiple times. See?


Regards, Julian


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



From w3c-dist-auth-request@w3.org  Thu Mar 25 19:44:19 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05875
	for <webdav-archive@lists.ietf.org>; Thu, 25 Mar 2004 19:44:19 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 70A79A0621; Thu, 25 Mar 2004 19:44:20 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id B62C8A0621
	for <w3c-dist-auth@listhub.w3.org>; Thu, 25 Mar 2004 19:44:17 -0500 (EST)
Received: from kahuna.osafoundation.org ([204.152.186.98])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B6fSL-0001qP-CR
	for w3c-dist-auth@w3c.org; Thu, 25 Mar 2004 19:44:17 -0500
Old-X-Envelope-From: lisa@osafoundation.org
Old-X-Envelope-To: w3c-dist-auth@w3c.org
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2])
	(authenticated bits=0)
	by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i2Q0i5hV021894
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Thu, 25 Mar 2004 16:44:05 -0800
In-Reply-To: <40636584.1030005@gmx.de>
References: <OFF9933575.AF301A7E-ON85256E5C.0069DA11-85256E5C.006AA750@us.ibm.com> <405C196C.1030609@gmx.de> <E80FC418-7C3C-11D8-BB68-000A95B2BB72@osafoundation.org> <405F4BD5.5070302@gmx.de> <19B65246-7DB3-11D8-9DC8-000A95B2BB72@osafoundation.org> <p06020401bc8774d9fe1d@[129.46.227.161]> <4061CBAF.6090205@gmx.de> <9014A50E-7DC2-11D8-9DC8-000A95B2BB72@osafoundation.org> <4061E667.5050602@gmx.de> <53680C68-7EAE-11D8-A4F9-000A95B2BB72@osafoundation.org> <40636584.1030005@gmx.de>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <ACB54062-7EBE-11D8-A4F9-000A95B2BB72@osafoundation.org>
Content-Transfer-Encoding: 7bit
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>,
        Ted Hardie <hardie@qualcomm.com>, Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Date: Thu, 25 Mar 2004 16:44:01 -0800
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.613)
X-Scanned-By: MIMEDefang 2.39
Subject: Re: Properties of bindings (was Re: Issues remaining with Bind draft)
X-Archived-At: http://www.w3.org/mid/ACB54062-7EBE-11D8-A4F9-000A95B2BB72@osafoundation.org
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8395
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040326004420.70A79A0621@frink.w3.org>
Resent-Date: Thu, 25 Mar 2004 19:44:20 -0500 (EST)
Content-Transfer-Encoding: 7bit


>
> BTW: the "hidden" flag in NTFS in fact is kept as part of the file 
> resource, not of the binding. Thus, IIS in fact does the right thing 
> in presenting this as property on the resource (well, they shouldn't 
> have uses the DAV: namespace...).
>
> To test that: create a file, create a second binding to that file 
> (cygwin ln), show properties in Explorer for first binding, set 
> "hidden", refresh window multiple times. See?
>
>
That's an interesting test, but that doesn't tell us what Exchange 2000 
does with the "ishidden" flag, which is not stored as the "hidden" flag 
in NTFS.

Lisa



From w3c-dist-auth-request@w3.org  Thu Mar 25 22:56:28 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13235
	for <webdav-archive@lists.ietf.org>; Thu, 25 Mar 2004 22:56:28 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 64A79A1135; Thu, 25 Mar 2004 22:56:27 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id BCB3AA12BE
	for <w3c-dist-auth@listhub.w3.org>; Thu, 25 Mar 2004 22:56:13 -0500 (EST)
Received: from betlik.darwin.nasa.gov ([198.123.160.11] helo=dream.darwin.nasa.gov)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B6iC3-0004SC-3J
	for w3c-dist-auth@w3c.org; Thu, 25 Mar 2004 22:39:39 -0500
Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27])
	by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id i2Q3dbd23139
	for <w3c-dist-auth@w3c.org>; Thu, 25 Mar 2004 19:39:38 -0800 (PST)
Message-ID: <4063A5F9.7080404@cse.ucsc.edu>
Date: Thu, 25 Mar 2004 19:39:37 -0800
From: Elias Sinderson <elias@cse.ucsc.edu>
Reply-To: Webdav WG <w3c-dist-auth@w3c.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: Webdav WG <w3c-dist-auth@w3c.org>
References: <BA82F416-7D01-11D8-BB68-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Charter update: remove property registry task?
X-Archived-At: http://www.w3.org/mid/4063A5F9.7080404@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8396
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040326035627.64A79A1135@frink.w3.org>
Resent-Date: Thu, 25 Mar 2004 22:56:27 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

> I'd like to find out if there is consensus on removing the "property 
> registry" task from the WebDAV WG charter. 

+1, it can always be revived in the future if interest grows.


Elias




From w3c-dist-auth-request@w3.org  Fri Mar 26 00:07:49 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15864
	for <webdav-archive@lists.ietf.org>; Fri, 26 Mar 2004 00:07:48 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 7B96AA0699; Thu, 25 Mar 2004 23:04:39 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 0E1ABA161A
	for <w3c-dist-auth@listhub.w3.org>; Thu, 25 Mar 2004 23:04:29 -0500 (EST)
Received: from betlik.darwin.nasa.gov ([198.123.160.11] helo=dream.darwin.nasa.gov)
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B6i8v-0001io-Vy
	for w3c-dist-auth@w3.org; Thu, 25 Mar 2004 22:36:26 -0500
Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27])
	by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id i2Q3a4d23125;
	Thu, 25 Mar 2004 19:36:04 -0800 (PST)
Message-ID: <4063A524.4070808@cse.ucsc.edu>
Date: Thu, 25 Mar 2004 19:36:04 -0800
From: Elias Sinderson <elias@cse.ucsc.edu>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: edgar@edgarschwarz.de
Cc: w3c-dist-auth@w3.org
References: <200403222154.i2MLsklG001596@post.webmailer.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Re (2): Where is an example of using webdav seamlessly...and  version files?
X-Archived-At: http://www.w3.org/mid/4063A524.4070808@cse.ucsc.edu
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8397
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040326040439.7B96AA0699@frink.w3.org>
Resent-Date: Thu, 25 Mar 2004 23:04:39 -0500 (EST)
Content-Transfer-Encoding: 7bit


I agree with Geoff where versioning is concerned, as users familliar 
with versioning will know what that means. However, for applications 
(users?) that aren't version aware I would prefer 'Publish (as)' because 
most users will have a good semantic model for the meaning of 'publish', 
indicating that you are making the resource available for others.


Elias


edgar@edgarschwarz.de wrote:

>Suppose I edit a WebDAV file with my application.
>- Now I want to save it. In a "normal" application I have "save" and "save as".
>- With a WebDAV file I guess I have "save local", "save on server", "save local as"
>  and "save on server as".
>- I think "save local as" doesn't make that much sense and can be dropped.
>- This leaves me with three choices. One should be default and be called save.
>- So my idea is to have "save", "save WebDAV" and "save WebDAV as" which means
>  a simple "save" means saving local. This could be fine for people with a slow
>  server connection.
>So do you think this sounds right for a user ?
>Would you prefer other names or choices for saving ?
>I know this isn't something the spec should say but nevertheless it would be nice
>if users would have similar menu items for saving in their upcoming WebDAV empowered
>applications. 
>BTW for versioning I have at the moment in a directory window the following
>menu items and subitems:
>- Version Do
>  - Checkin  (Which does a VERSION-CONTROL, BASELINE-CONTROL or CHECKIN depending
>    on it's target)
>  - Uncheckout
>  - Checkout
>  - Update
>- Version Report
>  - Version (For a resource or a configuration)
>  - History (For a resource or a configuration)
>  - Baseline Compare
>Naturally most of these points also can be added to an editor menu. Also there
>could be one versioning menu.
>
>Cheers, Edgar
>  
>




From w3c-dist-auth-request@w3.org  Fri Mar 26 03:20:57 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06480
	for <webdav-archive@lists.ietf.org>; Fri, 26 Mar 2004 03:20:57 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id A9E30A1092; Fri, 26 Mar 2004 03:20:57 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id CAC7BA12E2
	for <w3c-dist-auth@listhub.w3.org>; Fri, 26 Mar 2004 03:20:27 -0500 (EST)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B6mY8-0000nv-9l
	for w3c-dist-auth@w3c.org; Fri, 26 Mar 2004 03:18:44 -0500
Received: (qmail 29075 invoked by uid 65534); 26 Mar 2004 08:18:09 -0000
Received: from pD950C389.dip.t-dialin.net (EHLO gmx.de) (217.80.195.137)
  by mail.gmx.net (mp002) with SMTP; 26 Mar 2004 09:18:09 +0100
X-Authenticated: #1915285
Message-ID: <4063E72C.4050608@gmx.de>
Date: Fri, 26 Mar 2004 09:17:48 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
References: <OFF9933575.AF301A7E-ON85256E5C.0069DA11-85256E5C.006AA750@us.ibm.com> <405C196C.1030609@gmx.de> <E80FC418-7C3C-11D8-BB68-000A95B2BB72@osafoundation.org> <405F4BD5.5070302@gmx.de> <19B65246-7DB3-11D8-9DC8-000A95B2BB72@osafoundation.org> <p06020401bc8774d9fe1d@[129.46.227.161]> <4061CBAF.6090205@gmx.de> <9014A50E-7DC2-11D8-9DC8-000A95B2BB72@osafoundation.org> <4061E667.5050602@gmx.de> <53680C68-7EAE-11D8-A4F9-000A95B2BB72@osafoundation.org> <40636584.1030005@gmx.de> <ACB54062-7EBE-11D8-A4F9-000A95B2BB72@osafoundation.org>
In-Reply-To: <ACB54062-7EBE-11D8-A4F9-000A95B2BB72@osafoundation.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Properties of bindings (was Re: Issues remaining with Bind draft)
X-Archived-At: http://www.w3.org/mid/4063E72C.4050608@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8398
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040326082057.A9E30A1092@frink.w3.org>
Resent-Date: Fri, 26 Mar 2004 03:20:57 -0500 (EST)
Content-Transfer-Encoding: 7bit


Lisa Dusseault wrote:

>> BTW: the "hidden" flag in NTFS in fact is kept as part of the file 
>> resource, not of the binding. Thus, IIS in fact does the right thing 
>> in presenting this as property on the resource (well, they shouldn't 
>> have uses the DAV: namespace...).
>>
>> To test that: create a file, create a second binding to that file 
>> (cygwin ln), show properties in Explorer for first binding, set 
>> "hidden", refresh window multiple times. See?
>>
>>
> That's an interesting test, but that doesn't tell us what Exchange 2000 
> does with the "ishidden" flag, which is not stored as the "hidden" flag 
> in NTFS.

Well, either it works as with IIS (in which case it works consistently 
across Microsoft products), or it doesn't. *Does* Exchange support hard 
links / bindings? If it doesn't, how is the question relevant?

Julian

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



From w3c-dist-auth-request@w3.org  Fri Mar 26 06:57:54 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15019
	for <webdav-archive@lists.ietf.org>; Fri, 26 Mar 2004 06:57:54 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 6F855A07D5; Fri, 26 Mar 2004 06:57:55 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id A9F97A07D5
	for <w3c-dist-auth@listhub.w3.org>; Fri, 26 Mar 2004 06:57:49 -0500 (EST)
Received: from e5.ny.us.ibm.com ([32.97.182.105])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B6pxl-0004LE-M8
	for w3c-dist-auth@w3c.org; Fri, 26 Mar 2004 06:57:25 -0500
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2QBurJr687858
	for <w3c-dist-auth@w3c.org>; Fri, 26 Mar 2004 06:56:54 -0500
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2QBvAim097502
	for <w3c-dist-auth@w3c.org>; Fri, 26 Mar 2004 06:57:11 -0500
In-Reply-To: <40636584.1030005@gmx.de>
To: Webdav WG <w3c-dist-auth@w3c.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Message-ID: <OFD31EFF64.C434FC32-ON85256E63.001548CD-85256E63.00419113@us.ibm.com>
Date: Fri, 26 Mar 2004 06:56:50 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at
 03/26/2004 06:56:53,
	Serialize complete at 03/26/2004 06:56:53
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: Properties of bindings (was Re: Issues remaining with Bind draft)
X-Archived-At: http://www.w3.org/mid/OFD31EFF64.C434FC32-ON85256E63.001548CD-85256E63.00419113@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8399
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040326115755.6F855A07D5@frink.w3.org>
Resent-Date: Fri, 26 Mar 2004 06:57:55 -0500 (EST)


I agree with Julian's response.  Systems that only allow one parent
for a resource are free to define/implement properties that only make
sense if there is exactly one parent.  If they decide to support 
multiple parents, then they will have to redefine that property.
One trivial way to do so is to just say that this property describes
one of the paths to the resource, e.g. in the case of "parentname",
you would say "this property describes the binding name of this resource
in one of its parents".

Cheers,
Geoff

Julian Reschke <julian.reschke@gmx.de> wrote on 03/25/2004 06:04:36 PM:

> Lisa Dusseault wrote:
> 
> > I found a reference to the "parentname" property, defined for Exchange 
 
> > 2000 and Exchange 2003 in the "DAV:" namespace (no big surprise there 
> > though it's unfortunate):
> > 
> > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/ 
> > wss/_cdo_schema_dav.asp
> 
> I fail to see the issue. It only means that when Microsoft decides to 
> support the BIND draft, they'll have to re-think that design decision. 
> Just because somebody in the past did a poor system design that is 
> inherently incompatible with having multiple URIs for the same resource 
> shouldn't prevent *us* from doing things right.




From w3c-dist-auth-request@w3.org  Fri Mar 26 07:18:15 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15923
	for <webdav-archive@lists.ietf.org>; Fri, 26 Mar 2004 07:18:14 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id B453BA0D50; Fri, 26 Mar 2004 07:18:14 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 5B800A0D50
	for <w3c-dist-auth@listhub.w3.org>; Fri, 26 Mar 2004 07:18:11 -0500 (EST)
Received: from e4.ny.us.ibm.com ([32.97.182.104])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B6qHX-0000ik-LQ
	for w3c-dist-auth@w3.org; Fri, 26 Mar 2004 07:17:51 -0500
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2QCHKG9685554
	for <w3c-dist-auth@w3.org>; Fri, 26 Mar 2004 07:17:20 -0500
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2QCHb6W104744
	for <w3c-dist-auth@w3.org>; Fri, 26 Mar 2004 07:17:37 -0500
In-Reply-To: <4063A524.4070808@cse.ucsc.edu>
To: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF76D3E91C.6FF9253A-ON85256E63.0042FF77-85256E63.00436F43@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Fri, 26 Mar 2004 07:17:14 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at
 03/26/2004 07:17:18,
	Serialize complete at 03/26/2004 07:17:18
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: Re (2): Where is an example of using webdav seamlessly...and  version  files?
X-Archived-At: http://www.w3.org/mid/OF76D3E91C.6FF9253A-ON85256E63.0042FF77-85256E63.00436F43@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8400
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040326121814.B453BA0D50@frink.w3.org>
Resent-Date: Fri, 26 Mar 2004 07:18:14 -0500 (EST)


That makes sense ... in fact, an interoperable client could have the
following logic:
- if local storage is available, provide a "save" and "save as" operation.
- if the WebDAV server is available:
  - if the resource is under version control, provide a "checkin" 
operation
  - otherwise; provide a "publish" operation

Note: we are defining client design issues, rather than protocol issues,
but since the mailing list has been rather quiet and there are a lot of
client implementors on this list, I think this is reasonably on-topic
(if anyone disagrees, please let me or the list know).

Cheers,
Geoff

Elias wrote on 03/25/2004 10:36:04 PM:
> 
> I agree with Geoff where versioning is concerned, as users familliar 
> with versioning will know what that means. However, for applications 
> (users?) that aren't version aware I would prefer 'Publish (as)' because 

> most users will have a good semantic model for the meaning of 'publish', 

> indicating that you are making the resource available for others.
> 
> 
> edgar@edgarschwarz.de wrote:
> 
> >Suppose I edit a WebDAV file with my application.
> >- Now I want to save it. In a "normal" application I have "save" 
> and "save as".
> >- With a WebDAV file I guess I have "save local", "save on server",
> "save local as"
> >  and "save on server as".
> >- I think "save local as" doesn't make that much sense and can be 
dropped.
> >- This leaves me with three choices. One should be default and be 
> called save.
> >- So my idea is to have "save", "save WebDAV" and "save WebDAV as" 
> which means
> >  a simple "save" means saving local. This could be fine for people
> with a slow
> >  server connection.
> >So do you think this sounds right for a user ?
> >Would you prefer other names or choices for saving ?
> >I know this isn't something the spec should say but nevertheless it
> would be nice
> >if users would have similar menu items for saving in their upcoming
> WebDAV empowered
> >applications. 
> >BTW for versioning I have at the moment in a directory window the 
following
> >menu items and subitems:
> >- Version Do
> >  - Checkin  (Which does a VERSION-CONTROL, BASELINE-CONTROL or 
> CHECKIN depending
> >    on it's target)
> >  - Uncheckout
> >  - Checkout
> >  - Update
> >- Version Report
> >  - Version (For a resource or a configuration)
> >  - History (For a resource or a configuration)
> >  - Baseline Compare
> >Naturally most of these points also can be added to an editor menu.Also 
there
> >could be one versioning menu.
> >
> >Cheers, Edgar
> > 
> >
> 
> 



From w3c-dist-auth-request@w3.org  Sun Mar 28 08:37:57 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17098
	for <webdav-archive@lists.ietf.org>; Sun, 28 Mar 2004 08:37:56 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 10212A1A53; Sun, 28 Mar 2004 07:28:32 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id EEC0AA1A53
	for <w3c-dist-auth@listhub.w3.org>; Sun, 28 Mar 2004 07:28:28 -0500 (EST)
Received: from ispmxmta06-srv.alltel.net ([166.102.165.167])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B7ZOt-00084R-28
	for w3c-dist-auth@w3.org; Sun, 28 Mar 2004 07:28:27 -0500
Received: from [192.168.1.102] (really [162.40.241.23])
          by ispmxmta06-srv.alltel.net with ESMTP
          id <20040328122755.NVGH21091.ispmxmta06-srv.alltel.net@[192.168.1.102]>
          for <w3c-dist-auth@w3.org>; Sun, 28 Mar 2004 06:27:55 -0600
Mime-Version: 1.0
X-Sender: frank.lowney@gcsu.edu@mail.gcsu.edu
Message-Id: <p06020403bc8c73da9d17@[192.168.1.102]>
Date: Sun, 28 Mar 2004 07:27:54 -0500
To: w3c-dist-auth@w3.org
From: Frank Lowney <frank.lowney@gcsu.edu>
Content-Type: text/plain; charset="us-ascii"
Subject: web-based upload via WebDAV
X-Archived-At: http://www.w3.org/mid/p06020403bc8c73da9d17@%5B192.168.1.102%5D
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8401
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040328122832.10212A1A53@frink.w3.org>
Resent-Date: Sun, 28 Mar 2004 07:28:32 -0500 (EST)


Since there are numerous examples of HTTP 1.0 upload (one file at a time) from within a web page, I wondered if it is possible to use HTTP 1.1 WebDAV protocols to upload multiple files at a time from within a web page.  How would authentication be handled in such a case and could that be programmatically supplied since one may already have authenticated oneself to obtain the upload page in the first place?


-- 
=====================================================================
Dr. Frank Lowney  frank.lowney@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.

Please note that my new e-mail address is: frank.lowney@gcsu.edu



From w3c-dist-auth-request@w3.org  Mon Mar 29 21:23:16 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09902
	for <webdav-archive@lists.ietf.org>; Mon, 29 Mar 2004 21:23:15 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id EA71CA14AE; Mon, 29 Mar 2004 21:23:15 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 99E0FA14AE
	for <w3c-dist-auth@listhub.w3.org>; Mon, 29 Mar 2004 21:23:11 -0500 (EST)
Received: from grouse.mail.pas.earthlink.net ([207.217.120.116])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B88uF-0007D2-3t
	for w3c-dist-auth@w3.org; Mon, 29 Mar 2004 21:23:11 -0500
Received: from user-1120lgh.dsl.mindspring.com ([66.32.86.17] helo=[192.168.1.10])
	by grouse.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 1B88uD-0001uJ-00; Mon, 29 Mar 2004 18:23:09 -0800
In-Reply-To: <p06020403bc8c73da9d17@[192.168.1.102]>
References: <p06020403bc8c73da9d17@[192.168.1.102]>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <06D9EC9C-81F1-11D8-B0B6-000A95B03262@icx.net>
Content-Transfer-Encoding: 7bit
Cc: w3c-dist-auth@w3.org
From: John DeSoi <jd@icx.net>
Date: Mon, 29 Mar 2004 21:22:00 -0500
To: Frank Lowney <frank.lowney@gcsu.edu>
X-Mailer: Apple Mail (2.613)
Subject: Re: web-based upload via WebDAV
X-Archived-At: http://www.w3.org/mid/06D9EC9C-81F1-11D8-B0B6-000A95B03262@icx.net
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8402
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040330022315.EA71CA14AE@frink.w3.org>
Resent-Date: Mon, 29 Mar 2004 21:23:15 -0500 (EST)
Content-Transfer-Encoding: 7bit


Frank,

On Mar 28, 2004, at 7:27 AM, Frank Lowney wrote:

> Since there are numerous examples of HTTP 1.0 upload (one file at a 
> time) from within a web page, I wondered if it is possible to use HTTP 
> 1.1 WebDAV protocols to upload multiple files at a time from within a 
> web page.  How would authentication be handled in such a case and 
> could that be programmatically supplied since one may already have 
> authenticated oneself to obtain the upload page in the first place?

I have not tried it in a while, but I doubt it will be possible to do 
this effectively from a web page. The user will still have to specify 
each and every file because the browser security settings are not going 
to allow you to programatically set file paths in a form. Even if you 
could, WebDAV would need to receive each file as a PUT request. I'm not 
aware of any standardized support for scripting this from a web page.

The closest thing I'm aware of is HTML editor built into Mozilla. You 
can create a page with included images and support files and Mozilla 
will upload the page and all related items using HTTP PUT. PUT is the 
the same mechanism used in WebDAV for storing documents.

Best,

John DeSoi, Ph.D.



From w3c-dist-auth-request@w3.org  Mon Mar 29 22:10:29 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11491
	for <webdav-archive@lists.ietf.org>; Mon, 29 Mar 2004 22:10:29 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id E1DB7A29FA; Mon, 29 Mar 2004 22:10:30 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 72CF0A29FA
	for <w3c-dist-auth@listhub.w3.org>; Mon, 29 Mar 2004 22:10:22 -0500 (EST)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B89du-0007IT-23
	for w3c-dist-auth@w3.org; Mon, 29 Mar 2004 22:10:22 -0500
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i2U3AK6Z019460 sender ccjason@us.ibm.com for w3c-dist-auth@w3.org; Mon, 29 Mar 2004 19:10:20 -0800
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by bandage.seagull.net (8.12.10) with ESMTP id i2U3AHkO019428 sender ccjason@us.ibm.com; Mon, 29 Mar 2004 19:10:18 -0800
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i2U3A7XP463088; Mon, 29 Mar 2004 22:10:07 -0500
Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2U3AO5Y094126; Mon, 29 Mar 2004 22:10:25 -0500
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 <ccjason@us.ibm.com>
Message-ID: <OFFA2C90E2.4DBC7E1F-ON85256E67.000EED25-85256E67.0011658A@us.ibm.com>
Date: Mon, 29 Mar 2004 22:10:03 -0500
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF87 | March 11, 2004) at 03/29/2004 22:10:06, Serialize complete at 03/29/2004 22:10:06
Content-Type: multipart/alternative; boundary="=_alternative 001137C085256E67_="
Subject: Re: Properties of bindings (was Re: Issues remaining with Bind draft)
X-Archived-At: http://www.w3.org/mid/OFFA2C90E2.4DBC7E1F-ON85256E67.000EED25-85256E67.0011658A@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8403
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040330031030.E1DB7A29FA@frink.w3.org>
Resent-Date: Mon, 29 Mar 2004 22:10:30 -0500 (EST)


This is a multipart message in MIME format.
--=_alternative 001137C085256E67_=
Content-Type: text/plain; charset="us-ascii"

> The "hidden" flag you suggest would also be interesting as a 
> binding  property, as was suggested in this Internet-Draft 
> (also implemented in  Microsoft servers):
> http://www.ics.uci.edu/~ejw/authoring/props/draft-hopmann-
> collection-props-00.txt

Although I'm not sure if hidden is a good example, I don't have a problem 
with some hypothetical property returning a different value depending on 
which URL you use to reference it.  In fact I wouldn't be surprised if we 
eventually intentionally define a property that does vary by URL.  But we 
should be clear right now that all properties that are resource based 
(which is basically everything at the time of the writing) should not vary 
by URL and that future properties should not vary by URL without a 
documented reason. 

J.


--=_alternative 001137C085256E67_=
Content-Type: text/html; charset="us-ascii"


<br>
<br>
<br><font size=2 face="sans-serif">&gt; The &quot;hidden&quot; flag you suggest would also be interesting as a </font>
<br><font size=2 face="sans-serif">&gt; binding &nbsp;property, as was suggested in this Internet-Draft </font>
<br><font size=2 face="sans-serif">&gt; (also implemented in &nbsp;Microsoft servers):</font>
<br><font size=2 face="sans-serif">&gt; http://www.ics.uci.edu/~ejw/authoring/props/draft-hopmann-</font>
<br><font size=2 face="sans-serif">&gt; collection-props-00.txt</font>
<br>
<br><font size=2 face="sans-serif">Although I'm not sure if hidden is a good example, I don't have a problem with some hypothetical property returning a different value depending on which URL you use to reference it. &nbsp;In fact I wouldn't be surprised if we eventually intentionally define a property that does vary by URL. &nbsp;But we should be clear right now that all properties that are resource based (which is basically everything at the time of the writing) should not vary by URL and that future properties should not vary by URL without a documented reason. </font>
<br>
<br><font size=2 face="sans-serif">J.</font>
<br>
<br>
--=_alternative 001137C085256E67_=--



From w3c-dist-auth-request@w3.org  Mon Mar 29 22:10:34 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11509
	for <webdav-archive@lists.ietf.org>; Mon, 29 Mar 2004 22:10:34 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 0A9A5A29FD; Mon, 29 Mar 2004 22:10:33 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 8BD61A29FD
	for <w3c-dist-auth@listhub.w3.org>; Mon, 29 Mar 2004 22:10:22 -0500 (EST)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B89du-0007IV-3J
	for w3c-dist-auth@w3.org; Mon, 29 Mar 2004 22:10:22 -0500
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i2U3ALOg019465 sender ccjason@us.ibm.com for w3c-dist-auth@w3.org; Mon, 29 Mar 2004 19:10:21 -0800
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by bandage.seagull.net (8.12.10) with ESMTP id i2U3AH20019427 sender ccjason@us.ibm.com; Mon, 29 Mar 2004 19:10:18 -0800
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2U3A6Jr273158; Mon, 29 Mar 2004 22:10:06 -0500
Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2U3AO5X094126; Mon, 29 Mar 2004 22:10:25 -0500
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 <ccjason@us.ibm.com>
Message-ID: <OF07C3266C.779B2D7B-ON85256E67.000E169D-85256E67.0011658C@us.ibm.com>
Date: Mon, 29 Mar 2004 22:10:03 -0500
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF87 | March 11, 2004) at 03/29/2004 22:10:05, Serialize complete at 03/29/2004 22:10:05
Content-Type: multipart/alternative; boundary="=_alternative 00113D4885256E67_="
Subject: Re: Properties of bindings (was Re: Issues remaining with Bind draft)
X-Archived-At: http://www.w3.org/mid/OF07C3266C.779B2D7B-ON85256E67.000E169D-85256E67.0011658C@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8404
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040330031033.0A9A5A29FD@frink.w3.org>
Resent-Date: Mon, 29 Mar 2004 22:10:33 -0500 (EST)


This is a multipart message in MIME format.
--=_alternative 00113D4885256E67_=
Content-Type: text/plain; charset="us-ascii"

> Lisa Dusseault wrote:
> 
> > I found a reference to the "parentname" property, defined for Exchange 

> > 2000 and Exchange 2003 in the "DAV:" namespace (no big surprise there 
> > though it's unfortunate):
> > 
> > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/ 
> > wss/_cdo_schema_dav.asp
> 
> I fail to see the issue. It only means that when Microsoft decides to 
> support the BIND draft, they'll have to re-think that design decision. 
> Just because somebody in the past did a poor system design that is 
> inherently incompatible with having multiple URIs for the same resource 
> shouldn't prevent *us* from doing things right.

I agree although I'd not be so harsh in my wording.  :-)

If they decide to support bindings, then they might have to make changes 
to that property definition.  This shouldn't be a big problem because it's 
their property to define however they like.   Although hopefully they 
avoid using the DAV: namespace.

J.
--=_alternative 00113D4885256E67_=
Content-Type: text/html; charset="us-ascii"


<br>
<br><font size=2 face="sans-serif">&gt; Lisa Dusseault wrote:</font>
<br><font size=2 face="sans-serif">&gt; </font>
<br><font size=2 face="sans-serif">&gt; &gt; I found a reference to the &quot;parentname&quot; property, defined for Exchange </font>
<br><font size=2 face="sans-serif">&gt; &gt; 2000 and Exchange 2003 in the &quot;DAV:&quot; namespace (no big surprise there </font>
<br><font size=2 face="sans-serif">&gt; &gt; though it's unfortunate):</font>
<br><font size=2 face="sans-serif">&gt; &gt; </font>
<br><font size=2 face="sans-serif">&gt; &gt; http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/ </font>
<br><font size=2 face="sans-serif">&gt; &gt; wss/_cdo_schema_dav.asp</font>
<br><font size=2 face="sans-serif">&gt; </font>
<br><font size=2 face="sans-serif">&gt; I fail to see the issue. It only means that when Microsoft decides to </font>
<br><font size=2 face="sans-serif">&gt; support the BIND draft, they'll have to re-think that design decision. </font>
<br><font size=2 face="sans-serif">&gt; Just because somebody in the past did a poor system design that is </font>
<br><font size=2 face="sans-serif">&gt; inherently incompatible with having multiple URIs for the same resource </font>
<br><font size=2 face="sans-serif">&gt; shouldn't prevent *us* from doing things right.</font>
<br>
<br><font size=2 face="sans-serif">I agree although I'd not be so harsh in my wording. &nbsp;:-)</font>
<br>
<br><font size=2 face="sans-serif">If they decide to support bindings, then they might have to make changes to that property definition. &nbsp;This shouldn't be a big problem because it's their property to define however they like. &nbsp; Although hopefully they avoid using the DAV: namespace.</font>
<br>
<br><font size=2 face="sans-serif">J.</font>
--=_alternative 00113D4885256E67_=--



From w3c-dist-auth-request@w3.org  Tue Mar 30 02:37:01 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04889
	for <webdav-archive@lists.ietf.org>; Tue, 30 Mar 2004 02:37:00 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 77633A1A87; Tue, 30 Mar 2004 02:37:01 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 9AC05A1A87
	for <w3c-dist-auth@listhub.w3.org>; Tue, 30 Mar 2004 02:36:46 -0500 (EST)
Received: from frink.w3.org ([18.29.1.71])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B8Dly-0007JU-PU
	for w3c-dist-auth@w3.org; Tue, 30 Mar 2004 02:34:58 -0500
Received: from bandage.seagull.net (bandage.seagull.net [67.136.24.2])
	by frink.w3.org (Postfix) with ESMTP id 37E50A2D1F
	for <w3c-dist-auth@w3.org>; Tue, 30 Mar 2004 02:14:56 -0500 (EST)
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i2U7B9xM009153 sender julian.reschke@gmx.de for w3c-dist-auth@w3.org; Mon, 29 Mar 2004 23:11:09 -0800
Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by bandage.seagull.net (8.12.10) with SMTP id i2U7B8tL009055 sender julian.reschke@gmx.de for <nnw3c-dist-auth___at___w3.org@smallcue.com>; Mon, 29 Mar 2004 23:11:08 -0800
Received: (qmail 19507 invoked by uid 65534); 30 Mar 2004 07:10:55 -0000
Received: from pD950C38A.dip.t-dialin.net (EHLO gmx.de) (217.80.195.138) by mail.gmx.net (mp002) with SMTP; 30 Mar 2004 09:10:55 +0200
Message-ID: <40691D6B.3030601@gmx.de>
Date: Tue, 30 Mar 2004 09:10:35 +0200
From: Julian Reschke <julian.reschke@gmx.de>
MIME-Version: 1.0
To: Jason Crawford <ccjason@us.ibm.com>
Cc: nnw3c-dist-auth___at___w3.org@smallcue.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Subject: Re: Properties of bindings (was Re: Issues remaining with Bind draft)
X-Archived-At: http://www.w3.org/mid/40691D6B.3030601@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8405
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040330073701.77633A1A87@frink.w3.org>
Resent-Date: Tue, 30 Mar 2004 02:37:01 -0500 (EST)


Jason Crawford wrote:

>  > The "hidden" flag you suggest would also be interesting as a
>  > binding  property, as was suggested in this Internet-Draft
>  > (also implemented in  Microsoft servers):
>  > http://www.ics.uci.edu/~ejw/authoring/props/draft-hopmann-
>  > collection-props-00.txt
> 
> Although I'm not sure if hidden is a good example, I don't have a 
> problem with some hypothetical property returning a different value 
> depending on which URL you use to reference it.  In fact I wouldn't be 
> surprised if we eventually intentionally define a property that does 
> vary by URL.  But we should be clear right now that all properties that 
> are resource based (which is basically everything at the time of the 
> writing) should not vary by URL and that future properties should not 
> vary by URL without a documented reason.

Well, I think that properties SHOULD NOT vary on request URI (nor should 
the content), as this is clearly against the goals of the BIND spec. 
RFC2518 says that PROPFIND returns the resource's properties, and BIND 
speaks about having multiple URIs for the same resource. I think this is 
clear enough...

If you need responses that vary with the request URI, you're IMHO not 
talking to the *same* resource anymore.

Regards, Julian

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



From w3c-dist-auth-request@w3.org  Tue Mar 30 02:37:45 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04922
	for <webdav-archive@lists.ietf.org>; Tue, 30 Mar 2004 02:37:45 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 4A18FA276A; Tue, 30 Mar 2004 02:37:42 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 8F50FA232A
	for <w3c-dist-auth@listhub.w3.org>; Tue, 30 Mar 2004 02:37:30 -0500 (EST)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B8DjY-0006Q5-Jv
	for w3c-dist-auth@w3.org; Tue, 30 Mar 2004 02:32:28 -0500
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i2U7WR1S013855 sender ccjason@us.ibm.com for w3c-dist-auth@w3.org; Mon, 29 Mar 2004 23:32:27 -0800
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by bandage.seagull.net (8.12.10) with ESMTP id i2U7WP5I013773 sender ccjason@us.ibm.com; Mon, 29 Mar 2004 23:32:26 -0800
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2U7WEJr479288; Tue, 30 Mar 2004 02:32:15 -0500
Received: from d01ml604.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2U7WDoc131092; Tue, 30 Mar 2004 02:32:14 -0500
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 <ccjason@us.ibm.com>
Message-ID: <OF1B9D44F3.05BCF603-ON85256E67.0028D48A-85256E67.002963C3@us.ibm.com>
Date: Tue, 30 Mar 2004 02:32:07 -0500
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF87 | March 11, 2004) at 03/30/2004 02:32:14, Serialize complete at 03/30/2004 02:32:14
Content-Type: multipart/alternative; boundary="=_alternative 00295F0A85256E67_="
Subject: Re: Properties of bindings (was Re: Issues remaining with Bind draft)
X-Archived-At: http://www.w3.org/mid/OF1B9D44F3.05BCF603-ON85256E67.0028D48A-85256E67.002963C3@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8406
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040330073742.4A18FA276A@frink.w3.org>
Resent-Date: Tue, 30 Mar 2004 02:37:42 -0500 (EST)


This is a multipart message in MIME format.
--=_alternative 00295F0A85256E67_=
Content-Type: text/plain; charset="us-ascii"

> > Although I'm not sure if hidden is a good example, I don't have a
> > problem with some hypothetical property returning a different value
> > depending on which URL you use to reference it.  In fact I wouldn't be
> > surprised if we eventually intentionally define a property that does
> > vary by URL.  But we should be clear right now that all properties 
that
> > are resource based (which is basically everything at the time of the
> > writing) should not vary by URL and that future properties should not
> > vary by URL without a documented reason.
> 
> Well, I think that properties SHOULD NOT vary on request URI (nor should
> the content), as this is clearly against the goals of the BIND spec.
I agree.  "SHOULD NOT" seems more than lenient enough.


> RFC2518 says that PROPFIND returns the resource's properties, and BIND
> speaks about having multiple URIs for the same resource. I think this is
> clear enough...

Agreed.

--=_alternative 00295F0A85256E67_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">&gt; &gt; Although I'm not sure if hidden is a good example, I don't have a<br>
&gt; &gt; problem with some hypothetical property returning a different value<br>
&gt; &gt; depending on which URL you use to reference it. &nbsp;In fact I wouldn't be<br>
&gt; &gt; surprised if we eventually intentionally define a property that does<br>
&gt; &gt; vary by URL. &nbsp;But we should be clear right now that all properties that<br>
&gt; &gt; are resource based (which is basically everything at the time of the<br>
&gt; &gt; writing) should not vary by URL and that future properties should not<br>
&gt; &gt; vary by URL without a documented reason.<br>
&gt; <br>
&gt; Well, I think that properties SHOULD NOT vary on request URI (nor should<br>
&gt; the content), as this is clearly against the goals of the BIND spec.</font>
<br><font size=2 face="sans-serif">I agree. &nbsp;&quot;SHOULD NOT&quot; seems more than lenient enough.</font>
<br>
<br><font size=2 face="sans-serif"><br>
&gt; RFC2518 says that PROPFIND returns the resource's properties, and BIND<br>
&gt; speaks about having multiple URIs for the same resource. I think this is<br>
&gt; clear enough...</font>
<br>
<br><font size=2 face="sans-serif">Agreed.</font>
<br>
--=_alternative 00295F0A85256E67_=--



From w3c-dist-auth-request@w3.org  Tue Mar 30 07:40:49 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16359
	for <webdav-archive@lists.ietf.org>; Tue, 30 Mar 2004 07:40:49 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 062BBA05F7; Tue, 30 Mar 2004 07:40:50 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id F2731A160E
	for <w3c-dist-auth@listhub.w3.org>; Tue, 30 Mar 2004 07:40:43 -0500 (EST)
Received: from e6.ny.us.ibm.com ([32.97.182.106])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B8IXS-0003VL-H5
	for w3c-dist-auth@w3.org; Tue, 30 Mar 2004 07:40:18 -0500
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2UCdR4i534564;
	Tue, 30 Mar 2004 07:39:27 -0500
Received: from d01ml261.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2UCdjUk037322;
	Tue, 30 Mar 2004 07:39:46 -0500
In-Reply-To: <406347FA.9070700@gmx.de>
To: paf@cisco.com, lisa@osafoundation.org
Cc: w3c-dist-auth@w3.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF80D5785E.E32C7B4A-ON85256E67.00444705-85256E67.0045752A@us.ibm.com>
From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Tue, 30 Mar 2004 07:39:20 -0500
X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.0.2CF2HF273 | March 23, 2004) at
 03/30/2004 07:39:26,
	Serialize complete at 03/30/2004 07:39:26
Content-Type: text/plain; charset="US-ASCII"
Subject: Please submit last call on draft-ietf-webdav-bind-05.txt
X-Archived-At: http://www.w3.org/mid/OF80D5785E.E32C7B4A-ON85256E67.00444705-85256E67.0045752A@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8407
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040330124050.062BBA05F7@frink.w3.org>
Resent-Date: Tue, 30 Mar 2004 07:40:50 -0500 (EST)


Patrik, Lisa:

Please issue last call on the draft-ietf-webdav-bind-05.txt.

All semantic and marshalling issues have been resolved,
and all recent email has been around questions of whether to
add any additional explanatory text, which we can continue
to discuss during last call.

Thanks,
Geoff



Julian wrote on 03/25/2004 03:58:34 PM:
> Hi,
> 
> this draft contains the latest changes discussed here on the list (see 
> issues (see 
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-05.
> html#rfc.issue.6_lock_behaviour> 
> and 
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-05.
> html#rfc.issue.6_precondition_binding_allowed>).



From w3c-dist-auth-request@w3.org  Tue Mar 30 07:57:18 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16981
	for <webdav-archive@lists.ietf.org>; Tue, 30 Mar 2004 07:57:18 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 2F859A0644; Tue, 30 Mar 2004 07:57:19 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id 6A6E2A0644
	for <w3c-dist-auth@listhub.w3.org>; Tue, 30 Mar 2004 07:56:59 -0500 (EST)
Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net)
	by dr-nick.w3.org with smtp (Exim 4.30)
	id 1B8Ina-0006V0-Vr
	for w3c-dist-auth@w3.org; Tue, 30 Mar 2004 07:56:59 -0500
Received: (qmail 31068 invoked by uid 65534); 30 Mar 2004 12:56:23 -0000
Received: from p5082515C.dip0.t-ipconnect.de (EHLO gmx.de) (80.130.81.92)
  by mail.gmx.net (mp003) with SMTP; 30 Mar 2004 14:56:23 +0200
X-Authenticated: #1915285
Message-ID: <40696E71.5060205@gmx.de>
Date: Tue, 30 Mar 2004 14:56:17 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Cc: w3c-dist-auth@w3.org
References: <OF80D5785E.E32C7B4A-ON85256E67.00444705-85256E67.0045752A@us.ibm.com>
In-Reply-To: <OF80D5785E.E32C7B4A-ON85256E67.00444705-85256E67.0045752A@us.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Please submit last call on draft-ietf-webdav-bind-05.txt
X-Archived-At: http://www.w3.org/mid/40696E71.5060205@gmx.de
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8408
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040330125719.2F859A0644@frink.w3.org>
Resent-Date: Tue, 30 Mar 2004 07:57:19 -0500 (EST)
Content-Transfer-Encoding: 7bit


Geoffrey M Clemm wrote:

> Patrik, Lisa:
> 
> Please issue last call on the draft-ietf-webdav-bind-05.txt.
> 
> All semantic and marshalling issues have been resolved,
> and all recent email has been around questions of whether to
> add any additional explanatory text, which we can continue
> to discuss during last call.

+1

Julian


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



From w3c-dist-auth-request@w3.org  Tue Mar 30 17:35:06 2004
Received: from frink.w3.org (frink.w3.org [18.29.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18423
	for <webdav-archive@lists.ietf.org>; Tue, 30 Mar 2004 17:35:05 -0500 (EST)
Received: by frink.w3.org (Postfix, from userid 59936)
	id 0BA0AA1101; Tue, 30 Mar 2004 17:35:08 -0500 (EST)
X-Original-To: w3c-dist-auth@listhub.w3.org
Delivered-To: w3c-dist-auth@listhub.w3.org
Received: from dr-nick.w3.org (dr-nick.w3.org [18.29.1.73])
	by frink.w3.org (Postfix) with ESMTP id B18CEA1101
	for <w3c-dist-auth@listhub.w3.org>; Tue, 30 Mar 2004 17:35:04 -0500 (EST)
Received: from bandage.seagull.net ([67.136.24.2])
	by dr-nick.w3.org with esmtp (Exim 4.30)
	id 1B8Roz-0004tK-B0
	for w3c-dist-auth@w3.org; Tue, 30 Mar 2004 17:35:01 -0500
Received: (mail@localhost) by bandage.seagull.net (8.12.10) id i2UMYdAK006916 sender ccjason@us.ibm.com for w3c-dist-auth@w3.org; Tue, 30 Mar 2004 14:34:39 -0800
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by bandage.seagull.net (8.12.10) with ESMTP id i2UMYc8m006885 sender ccjason@us.ibm.com; Tue, 30 Mar 2004 14:34:38 -0800
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i2UMYQG9772156; Tue, 30 Mar 2004 17:34:26 -0500
Received: from d01ml604.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2UMYP72136724; Tue, 30 Mar 2004 17:34:25 -0500
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 <ccjason@us.ibm.com>
Message-ID: <OF53A758F1.74E7C887-ON85256E67.007B0DF6-85256E67.007BFE9B@us.ibm.com>
Date: Tue, 30 Mar 2004 17:34:23 -0500
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.51HF87 | March 11, 2004) at 03/30/2004 17:34:25, Serialize complete at 03/30/2004 17:34:25
Content-Type: multipart/alternative; boundary="=_alternative 007B36E085256E67_="
Subject: Re: Please submit last call on draft-ietf-webdav-bind-05.txt
X-Archived-At: http://www.w3.org/mid/OF53A758F1.74E7C887-ON85256E67.007B0DF6-85256E67.007BFE9B@us.ibm.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/8409
X-Loop: w3c-dist-auth@w3.org
Sender: w3c-dist-auth-request@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <20040330223508.0BA0AA1101@frink.w3.org>
Resent-Date: Tue, 30 Mar 2004 17:35:08 -0500 (EST)


This is a multipart message in MIME format.
--=_alternative 007B36E085256E67_=
Content-Type: text/plain; charset="us-ascii"

> Geoffrey M Clemm wrote:
> 
> > Patrik, Lisa:
> >
> > Please issue last call on the draft-ietf-webdav-bind-05.txt.
> >
> > All semantic and marshalling issues have been resolved,
> > and all recent email has been around questions of whether to
> > add any additional explanatory text, which we can continue
> > to discuss during last call.
> 
> +1
We've addressed all issues brought up, right?  Count me as +1.

--=_alternative 007B36E085256E67_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">&gt; Geoffrey M Clemm wrote:<br>
&gt; <br>
&gt; &gt; Patrik, Lisa:<br>
&gt; &gt;<br>
&gt; &gt; Please issue last call on the draft-ietf-webdav-bind-05.txt.<br>
&gt; &gt;<br>
&gt; &gt; All semantic and marshalling issues have been resolved,<br>
&gt; &gt; and all recent email has been around questions of whether to<br>
&gt; &gt; add any additional explanatory text, which we can continue<br>
&gt; &gt; to discuss during last call.<br>
&gt; <br>
&gt; +1</font>
<br><font size=2 face="sans-serif">We've addressed all issues brought up, right? &nbsp;Count me as +1.</font>
<br>
--=_alternative 007B36E085256E67_=--