From w3c-dist-auth-request@w3.org Mon Jul 1 16:54:17 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02540 for ; Mon, 1 Jul 2002 16:54:16 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA31038; Mon, 1 Jul 2002 16:51:53 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g61Kp3p00525; Mon, 1 Jul 2002 16:51:03 -0400 (EDT) Resent-Date: Mon, 1 Jul 2002 16:51:03 -0400 (EDT) Resent-Message-Id: <200207012051.g61Kp3p00525@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g61Kp3w00505 for ; Mon, 1 Jul 2002 16:51:03 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA30865 for ; Mon, 1 Jul 2002 16:51:02 -0400 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.192.101]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g61KoWg5145186 for ; Mon, 1 Jul 2002 16:50:32 -0400 Received: from dcertp57.raleigh.ibm.com (dcertpmail.raleigh.ibm.com [9.27.103.143]) by westrelay05.boulder.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g61Knh150988 for ; Mon, 1 Jul 2002 14:49:43 -0600 Received: from us.ibm.com (bpsnt6.raleigh.ibm.com [9.27.41.115]) by dcertp57.raleigh.ibm.com (AIX4.3/8.9.3/8.7/RTP-ral-1.0) with ESMTP id QAA23310 for ; Mon, 1 Jul 2002 16:50:30 -0400 Message-ID: <3D20C169.568A6D2D@us.ibm.com> Date: Mon, 01 Jul 2002 16:54:01 -0400 From: Geoff Alexander X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: FW: Re: Collections and Request-URIs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6360 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit One other related question. Does a resource whose name ends with a slash always represent a collection? RFC 2518 section 5.2 doesn't explicitly say this. For example, say that we receive a PUT request for /dir/ and that /dir/ does not exist. Do we treat /dir/ as a collection and fail the request as implied in RFC 2518 Section 8.7.2 paragraph 1 or do we ignore the trailing slash and perform a PUT on /dir? Thanks, Geoff Alexander, Ph.D. 919/254-5216 T/L 444-5216 CMVC WebDAV Development IBM Corporation RTP, NC From w3c-dist-auth-request@w3.org Tue Jul 2 06:37:13 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02048 for ; Tue, 2 Jul 2002 06:37:13 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA18867; Tue, 2 Jul 2002 06:36:38 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g62AaaH27302; Tue, 2 Jul 2002 06:36:36 -0400 (EDT) Resent-Date: Tue, 2 Jul 2002 06:36:36 -0400 (EDT) Resent-Message-Id: <200207021036.g62AaaH27302@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g62AaZw27282 for ; Tue, 2 Jul 2002 06:36:35 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA18858 for ; Tue, 2 Jul 2002 06:36:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01973; Tue, 2 Jul 2002 06:35:46 -0400 (EDT) Message-Id: <200207021035.GAA01973@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 02 Jul 2002 06:35:46 -0400 Subject: I-D ACTION:draft-ietf-webdav-rfc2518bis-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6361 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : HTTP Extensions for Distributed Authoring û WebDAV RFC2518 bis Author(s) : Y. Goland et al. Filename : draft-ietf-webdav-rfc2518bis-01.txt Pages : 89 Date : 01-Jul-02 WebDAV consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). RFC2518 was published in February 1998, and this draft makes only minor revisions mostly due to interoperability experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-rfc2518bis-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-rfc2518bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-rfc2518bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020701152907.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-rfc2518bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-rfc2518bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020701152907.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Tue Jul 2 13:41:16 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03485 for ; Tue, 2 Jul 2002 13:41:16 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA15752; Tue, 2 Jul 2002 13:40:26 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g62HeOd14826; Tue, 2 Jul 2002 13:40:24 -0400 (EDT) Resent-Date: Tue, 2 Jul 2002 13:40:24 -0400 (EDT) Resent-Message-Id: <200207021740.g62HeOd14826@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g62HeNw14803 for ; Tue, 2 Jul 2002 13:40:23 -0400 (EDT) Received: from peregrine.cqhost.net (peregrine.cqhost.net [209.126.140.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA15705 for ; Tue, 2 Jul 2002 13:40:22 -0400 Received: from koberg.com (adsl-64-173-57-78.dsl.snfc21.pacbell.net [64.173.57.78]) (authenticated) by virtualperegrine.cqhost.net (8.10.2/8.10.2) with ESMTP id g62HeHe30732 for ; Tue, 2 Jul 2002 13:40:17 -0400 Message-ID: <3D21E4F8.1070609@koberg.com> Date: Tue, 02 Jul 2002 10:38:00 -0700 From: "Robert S. Koberg" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: w3c-dist-auth@w3.org References: <200207021035.GAA01973@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: java, server-side lock/unlock resource - simple example? To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6362 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Is there a simple example of how I can lock/unlock (using java preferably) a resource on a server? Explantion: I have an app (content management for client sites) that has its own locking system which needs to tell the webdav whether a file is locked or not. It also needs to read whether a resource is locked or unlocked. ---------- I also want to explain the file-system/apache structure for the app to see if there are any problems. All 3 views work off the same directory. The app has 3 views: 1. authoring or development - this is the main app accessed by https://myappco.com/appname/ -- using the servlet container's config to set the approot to: /sites/myapp 2. certification - a generated version of the site accessed by: https://clientsite.myappco.com/ -- using the apache httpd.conf to set a DocumentRoot /sites/myapp/clientsite require group clientsite_qa 3. webdav - set to give authorized webdav access: https://myappco.com/appname/clientsite/ -- using the apache httpd.conf to set a #directives require group clientsite_webdav Thanks for any help/advice, -Rob From w3c-dist-auth-request@w3.org Tue Jul 2 14:06:51 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04898 for ; Tue, 2 Jul 2002 14:06:51 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA21383; Tue, 2 Jul 2002 14:05:33 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g62I5XA16644; Tue, 2 Jul 2002 14:05:33 -0400 (EDT) Resent-Date: Tue, 2 Jul 2002 14:05:33 -0400 (EDT) Resent-Message-Id: <200207021805.g62I5XA16644@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g62I5Ww16624 for ; Tue, 2 Jul 2002 14:05:32 -0400 (EDT) Received: from peregrine.cqhost.net (peregrine.cqhost.net [209.126.140.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA21349 for ; Tue, 2 Jul 2002 14:05:32 -0400 Received: from koberg.com (adsl-64-173-57-78.dsl.snfc21.pacbell.net [64.173.57.78]) (authenticated) by virtualperegrine.cqhost.net (8.10.2/8.10.2) with ESMTP id g62I5We32489 for ; Tue, 2 Jul 2002 14:05:32 -0400 Message-ID: <3D21EAE3.7070405@koberg.com> Date: Tue, 02 Jul 2002 11:03:15 -0700 From: "Robert S. Koberg" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: w3c-dist-auth@w3.org References: <200207021035.GAA01973@ietf.org> <3D21E4F8.1070609@koberg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: java, server-side lock/unlock resource - simple example? To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6363 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Arrrgghhh... I found what I need in rfc2518.html, sorry for the bother. Robert S. Koberg wrote: > Hi, > > Is there a simple example of how I can lock/unlock (using java > preferably) a resource on a server? > > Explantion: > I have an app (content management for client sites) that has its own > locking system which needs to tell the webdav whether a file is locked > or not. It also needs to read whether a resource is locked or unlocked. > ---------- > > I also want to explain the file-system/apache structure for the app to > see if there are any problems. All 3 views work off the same directory. > The app has 3 views: > > 1. authoring or development - this is the main app accessed by > https://myappco.com/appname/ > -- using the servlet container's config to set the approot to: /sites/myapp > > 2. certification - a generated version of the site accessed by: > https://clientsite.myappco.com/ > > -- using the apache httpd.conf to set a > > DocumentRoot /sites/myapp/clientsite > require group clientsite_qa > > > 3. webdav - set to give authorized webdav access: > https://myappco.com/appname/clientsite/ > -- using the apache httpd.conf to set a > > #directives > require group clientsite_webdav > > > Thanks for any help/advice, > -Rob > > > > From w3c-dist-auth-request@w3.org Tue Jul 2 18:30:31 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19475 for ; Tue, 2 Jul 2002 18:30:31 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA30324; Tue, 2 Jul 2002 18:28:04 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g62MRJr15684; Tue, 2 Jul 2002 18:27:20 -0400 (EDT) Resent-Date: Tue, 2 Jul 2002 18:27:20 -0400 (EDT) Resent-Message-Id: <200207022227.g62MRJr15684@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g62MRJw15659 for ; Tue, 2 Jul 2002 18:27:19 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA30195 for ; Tue, 2 Jul 2002 18:27:18 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g62MQkg5190374; Tue, 2 Jul 2002 18:26:46 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g62MQiw100876; Tue, 2 Jul 2002 18:26:44 -0400 To: "Julian Reschke" Cc: X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Tue, 2 Jul 2002 18:16:53 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_05312002 Pre-release 2|May 31, 2002) at 07/02/2002 18:26:44 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE179DFE9E3EB8f9e8a93df938690918c0ABBE179DFE9E3EB" Content-Disposition: inline Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6364 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE179DFE9E3EB8f9e8a93df938690918c0ABBE179DFE9E3EB Content-type: text/plain; charset=US-ASCII << The W3C has decided to treat link roles as URIs. If we decide to define a different mechanism, we will sooner or later have to define a mapping of XLink role URIs to our role schema (because other systems with which a WebDAv server connect may have decided to use standard Xlink roles). >> I assume Geoff or others will respond to this and hopefully also to my questions. << Furthermore this brings *us* into the business of defining roles (I think the spec should only define a mechanism to marshall them, that's it). >> By *US* I take it you mean the WebDAV community. Is it your view that some non-WebDAV entity will end up defining XLink roles that are also pertainent to WebDAV? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com --0__=0ABBE179DFE9E3EB8f9e8a93df938690918c0ABBE179DFE9E3EB Content-type: text/html; charset=US-ASCII Content-Disposition: inline

<<
The W3C has decided to treat link roles as URIs. If we decide to define a
different mechanism, we will
sooner or later have to define a mapping of XLink role URIs to our role
schema (because other systems with which a WebDAv server connect may have
decided to use standard Xlink roles).
>>
I assume Geoff or others will respond to this and hopefully also to my
questions.

<<
Furthermore this brings *us* into the
business of defining roles (I think the spec should only define a mechanism
to marshall them, that's it).
>>
By *US* I take it you mean the WebDAV community. Is it your view that some
non-WebDAV entity will end up defining XLink roles that are also pertainent to
WebDAV?

------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com
--0__=0ABBE179DFE9E3EB8f9e8a93df938690918c0ABBE179DFE9E3EB-- From w3c-dist-auth-request@w3.org Tue Jul 2 19:09:10 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21029 for ; Tue, 2 Jul 2002 19:09:09 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA03856; Tue, 2 Jul 2002 19:07:46 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g62N7ja22027; Tue, 2 Jul 2002 19:07:45 -0400 (EDT) Resent-Date: Tue, 2 Jul 2002 19:07:45 -0400 (EDT) Resent-Message-Id: <200207022307.g62N7ja22027@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g62N7iw22007 for ; Tue, 2 Jul 2002 19:07:44 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA03848 for ; Tue, 2 Jul 2002 19:07:44 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g62N76e8068404; Tue, 2 Jul 2002 19:07:06 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g62N74w76360; Tue, 2 Jul 2002 19:07:04 -0400 To: Dan Brotsky Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Tue, 2 Jul 2002 18:57:09 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_05312002 Pre-release 2|May 31, 2002) at 07/02/2002 19:07:03 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE179DFEE7D908f9e8a93df938690918c0ABBE179DFEE7D90" Content-Disposition: inline Subject: Re: New RFC2518bis draft, LOCK_REFRESH_BY_METHODS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6365 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE179DFEE7D908f9e8a93df938690918c0ABBE179DFEE7D90 Content-type: text/plain; charset=US-ASCII > The timeout counter MUST be restarted if a refresh LOCK request is > successfully executed on any resource controlled by the lock. The > timeout counter SHOULD NOT be restarted as a consequence of any other > client request. This wording is fine by me. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com --0__=0ABBE179DFEE7D908f9e8a93df938690918c0ABBE179DFEE7D90 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

> The timeout counter MUST be restarted if a refresh LOCK request is
> successfully executed on any resource controlled by the lock. The
> timeout counter SHOULD NOT be restarted as a consequence of any other
> client request.

This wording is fine by me.

------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com
--0__=0ABBE179DFEE7D908f9e8a93df938690918c0ABBE179DFEE7D90-- From w3c-dist-auth-request@w3.org Tue Jul 2 19:30:31 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22005 for ; Tue, 2 Jul 2002 19:30:31 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA06715; Tue, 2 Jul 2002 19:29:05 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g62NT5h24319; Tue, 2 Jul 2002 19:29:05 -0400 (EDT) Resent-Date: Tue, 2 Jul 2002 19:29:05 -0400 (EDT) Resent-Message-Id: <200207022329.g62NT5h24319@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g62NT4w24299 for ; Tue, 2 Jul 2002 19:29:04 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA06700 for ; Tue, 2 Jul 2002 19:29:04 -0400 Received: (qmail 14941 invoked by uid 0); 2 Jul 2002 23:28:40 -0000 Received: from p3ee24833.dip.t-dialin.net (HELO lisa) (62.226.72.51) by mail.gmx.net (mp004-rz3) with SMTP; 2 Jul 2002 23:28:40 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Julian Reschke" Cc: Date: Wed, 3 Jul 2002 01:28:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C22230.F59FCB60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6366 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C22230.F59FCB60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Not exactly the WebDAV community in total, but the subset of it actively working on fixing RFC2518. Regarding role URIs: yes, I'd expect this: see, for instance: http://www.rddl.org/#role BTW: just because a role is identified by a URI, it doesn't need to be opaque. For instance, the role URI may identify a HTTP-GETtable resource in a specific format. There's a reason why the ACL spec identifies principals by URI instead of marshalling all principal information in each PROPFIND, right? -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford Sent: Wednesday, July 03, 2002 12:17 AM To: Julian Reschke Cc: w3c-dist-auth@w3c.org Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED << The W3C has decided to treat link roles as URIs. If we decide to define a different mechanism, we will sooner or later have to define a mapping of XLink role URIs to our role schema (because other systems with which a WebDAv server connect may have decided to use standard Xlink roles). >> I assume Geoff or others will respond to this and hopefully also to my questions. << Furthermore this brings *us* into the business of defining roles (I think the spec should only define a mechanism to marshall them, that's it). >> By *US* I take it you mean the WebDAV community. Is it your view that some non-WebDAV entity will end up defining XLink roles that are also pertainent to WebDAV? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com ------=_NextPart_000_000E_01C22230.F59FCB60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Not=20 exactly the WebDAV community in total, but the subset of it actively = working on=20 fixing RFC2518.
 
Regarding role URIs: yes, I'd expect this: = see, for=20 instance:
 
http://www.rddl.org/#role
 
BTW:=20 just because a role is identified by a URI, it doesn't need to be = opaque.=20 For instance, the role URI may identify a HTTP-GETtable resource in a = specific=20 format. There's a reason why the ACL spec identifies principals by URI = instead=20 of marshalling all principal information in each PROPFIND,=20 right?
-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason=20 Crawford
Sent: Wednesday, July 03, 2002 12:17 = AM
To:=20 Julian Reschke
Cc: w3c-dist-auth@w3c.org
Subject: = RE:=20 Issue: SOURCE_PROPERTY_UNDERSPECIFIED

<<
The W3C has decided to treat = link=20 roles as URIs. If we decide to define a
different mechanism, we=20 will
sooner or later have to define a mapping of XLink role URIs to = our=20 role
schema (because other systems with which a WebDAv server = connect may=20 have
decided to use standard Xlink roles).
>>
I = assume Geoff=20 or others will respond to this and hopefully also to = my
questions.

<<
Furthermore=20 this brings *us* into the
business of defining roles (I think the = spec=20 should only define a mechanism
to marshall them, that's=20 it).
>>
By *US* I take = it you mean=20 the WebDAV community. Is it your view that some
non-WebDAV entity will end up defining XLink = roles that are=20 also pertainent to
WebDAV?

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

------=_NextPart_000_000E_01C22230.F59FCB60-- From w3c-dist-auth-request@w3.org Wed Jul 3 14:48:41 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28755 for ; Wed, 3 Jul 2002 14:48:40 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA29075; Wed, 3 Jul 2002 14:46:43 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g63Ik0H16785; Wed, 3 Jul 2002 14:46:00 -0400 (EDT) Resent-Date: Wed, 3 Jul 2002 14:46:00 -0400 (EDT) Resent-Message-Id: <200207031846.g63Ik0H16785@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g63Ijxw16765 for ; Wed, 3 Jul 2002 14:45:59 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA28948 for ; Wed, 3 Jul 2002 14:45:59 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 03 Jul 2002 14:45:27 -0400 (Eastern Daylight Time) Received: from ATL1VEXC006.usdom004.tco.tc ([209.225.56.58]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 3 Jul 2002 14:45:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C222C1.B9A1E4A4" Date: Wed, 3 Jul 2002 14:44:55 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA601736D81F@ATL1VEXC006.usdom004.tco.tc> Thread-topic: I-D ACTION:draft-mealling-iana-xmlns-registry-04.txt thread-index: AcIivjYmqT+/wDQpQ4e00W+hwaXxPQAA19XQ From: "Lisa Dusseault" To: "Webdav WG" X-OriginalArrivalTime: 03 Jul 2002 18:45:27.0039 (UTC) FILETIME=[CC3D30F0:01C222C1] Subject: FW: I-D ACTION:draft-mealling-iana-xmlns-registry-04.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6367 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C222C1.B9A1E4A4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI - I don't think Mealling's XML registry draft has been discussed on the list yet, so I wanted to point it out. It may be useful to register custom WebDAV properties.=20 Lisa -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Wednesday, July 03, 2002 3:30 AM Subject: I-D ACTION:draft-mealling-iana-xmlns-registry-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The IETF XML Registry Author(s) : M. Mealling Filename : draft-mealling-iana-xmlns-registry-04.txt Pages : 7 Date : 02-Jul-02 =09 This documenet describes an IANA maintained registry for IETF standards which use XML related items such as Namespaces, DTD, Schemas, and RDF Schemas. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mealling-iana-xmlns-registry-0 4.txt To remove yourself from the IETF Announcement list, send a message to=20 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-mealling-iana-xmlns-registry-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-mealling-iana-xmlns-registry-04.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C222C1.B9A1E4A4 Content-Type: application/octet-stream; name="draft-mealling-iana-xmlns-registry-04.URL" Content-Description: draft-mealling-iana-xmlns-registry-04.URL Content-Disposition: attachment; filename="draft-mealling-iana-xmlns-registry-04.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1tZWFsbGluZy1pYW5hLXhtbG5zLXJlZ2lzdHJ5LTA0LnR4dA0K ------_=_NextPart_001_01C222C1.B9A1E4A4-- From w3c-dist-auth-request@w3.org Wed Jul 3 15:06:06 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29963 for ; Wed, 3 Jul 2002 15:06:06 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA01179; Wed, 3 Jul 2002 15:04:42 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g63J4fN19320; Wed, 3 Jul 2002 15:04:41 -0400 (EDT) Resent-Date: Wed, 3 Jul 2002 15:04:41 -0400 (EDT) Resent-Message-Id: <200207031904.g63J4fN19320@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g63J4ew19297 for ; Wed, 3 Jul 2002 15:04:40 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA01167 for ; Wed, 3 Jul 2002 15:04:40 -0400 Received: from Tycho (dhcp-60-113.cse.ucsc.edu [128.114.60.113]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g63J3xi09321 for ; Wed, 3 Jul 2002 12:03:59 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 3 Jul 2002 12:02:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: WebDav information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6368 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: filio [mailto:f.chatzeioannou.2001@cranfield.ac.uk] Sent: Wednesday, July 03, 2002 10:08 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] WebDav information To whom ever may concern: Dr Sir/Madam, I'm a student in an MSc Course of Management and Infromation Systems in Cranfield university and for my thesis I'm doing an investigation on how WebDav extends the HTTP, what are the benefits for collaborative working on the internet and which tools have already implemented the WebDav protocol, like Dreamweaver and Adobe GoLive. I would be grateful if you could send me any information on the last part, tools that are using WebDav and how, because although there are some information on the sites of Macromedia or Adobe, they don't say anything about the way WebDav is implemented. Thanks anyway. Filio Chatzeioannou MSc in Management and Information systems Cranfield University ext.8336 From w3c-dist-auth-request@w3.org Wed Jul 3 15:14:40 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00815 for ; Wed, 3 Jul 2002 15:14:39 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA03075; Wed, 3 Jul 2002 15:13:11 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g63JDBt19985; Wed, 3 Jul 2002 15:13:11 -0400 (EDT) Resent-Date: Wed, 3 Jul 2002 15:13:11 -0400 (EDT) Resent-Message-Id: <200207031913.g63JDBt19985@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g63JDAw19965 for ; Wed, 3 Jul 2002 15:13:10 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA03069 for ; Wed, 3 Jul 2002 15:13:10 -0400 Received: (qmail 2886 invoked by uid 0); 3 Jul 2002 19:12:39 -0000 Received: from p3ee24735.dip.t-dialin.net (HELO lisa) (62.226.71.53) by mail.gmx.net (mp001-rz3) with SMTP; 3 Jul 2002 19:12:39 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "Webdav WG" Date: Wed, 3 Jul 2002 21:12:37 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <27889B08CAEC7049B68FAD8717BA601736D81F@ATL1VEXC006.usdom004.tco.tc> Importance: Normal Subject: RE: I-D ACTION:draft-mealling-iana-xmlns-registry-04.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6369 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm not sure... this is a registry for namespace names, DTD identifiers, XML schemas or RDF schemas -- not for specific element names. How do you think it can be applied to WebDAV properties? > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, July 03, 2002 8:45 PM > To: Webdav WG > Subject: FW: I-D ACTION:draft-mealling-iana-xmlns-registry-04.txt > > > FYI - I don't think Mealling's XML registry draft has been discussed on > the list yet, so I wanted to point it out. It may be useful to register > custom WebDAV properties. > > Lisa > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, July 03, 2002 3:30 AM > Subject: I-D ACTION:draft-mealling-iana-xmlns-registry-04.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : The IETF XML Registry > Author(s) : M. Mealling > Filename : draft-mealling-iana-xmlns-registry-04.txt > Pages : 7 > Date : 02-Jul-02 > > This documenet describes an IANA maintained registry for IETF > standards which use XML related items such as Namespaces, DTD, > Schemas, and RDF Schemas. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mealling-iana-xmlns-registry-0 > 4.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-mealling-iana-xmlns-registry-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-mealling-iana-xmlns-registry-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. > From w3c-dist-auth-request@w3.org Wed Jul 3 15:21:32 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01296 for ; Wed, 3 Jul 2002 15:21:32 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA07046; Wed, 3 Jul 2002 15:20:04 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g63JK3E21381; Wed, 3 Jul 2002 15:20:03 -0400 (EDT) Resent-Date: Wed, 3 Jul 2002 15:20:03 -0400 (EDT) Resent-Message-Id: <200207031920.g63JK3E21381@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g63JK3w21361 for ; Wed, 3 Jul 2002 15:20:03 -0400 (EDT) Received: from passwall.com (passwall.com [208.201.231.120]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA07014 for ; Wed, 3 Jul 2002 15:20:02 -0400 Received: (qmail 28247 invoked from network); 3 Jul 2002 19:31:47 -0000 Received: from nerds.intra.passwall.com (HELO nerds.passwall.com) (172.16.0.1) by ns1.intra.passwall.com with SMTP; 3 Jul 2002 19:31:47 -0000 Date: Wed, 3 Jul 2002 12:17:13 -0700 (PDT) From: ME Reply-To: ME To: w3c-dist-auth@w3.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by frink.w3.org id g63JK3w21361 Subject: Q?: Tx of text type docs and CR/LF, CR, LF translation Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6370 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, I have searched with google, read afew dav FAQs, and looked through some RFC before posting this message here. This is my first post to any W3/IETF list, so please bear with me for any mistakes I may make. :-) Problem: When WebDAV enabled clients (tested with "MS Web Folders", "Cadaver", and "Goliath") request a text file (text/plain, text/html) from a DavEnabled Webserver (in this case Apache 1.3.26 with mod-dav-1.0.3 running over SSL) the file is transmitted from the server with the same line termination the file had when examined on the server from a shell. Files previously edited with SimpleText (MacOS), or notepad (Windows) and stored on the server with netatalk-asun or samba contain CR (^M) or CRLF (^M^J) respectively. Files created from Linux bash with emacs/vi have the LF (^J) as the line termination char. Files created strictly from a Mac are not in "human readable format" when the windows user opens then with notepad. Files created strictly from a Windows box are not in "human readable format" when the mac user opens then with SimpleText. Forcing users to use a web authoring tool, or "BBEdit" (Mac) or something like Codewarrior Editor (Windows) that can deal with the 3 common line terminations strings for files and leave the file in "human readable format" are known, but not desired. Web browsers (Netscape, MSIE, Lynx) read these files from the same web server and perform proper translation such that the browser subsitutes the client OS's own line break for the served content's body (or file's contents.) This seems to echo rfc2616 , section: 3.7.1   "Canonicalization and Text Defaults:" ( http://asg.web.cmu.edu/rfc/rfc2616.html ) "When in canonical form, media subtypes of the "text" type use CRLF as the text line break. HTTP relaxes this requirement and allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an entire entity-body. HTTP applications MUST accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP." So, here is my thought: If RFC for HTTP/1.1 states "HTTP applications must accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP." and WebDAV clients are considered HTTP Applications, and the specs for WebDAV include use of HTTP for transmission of text type docs, then shouldn't WebDAV clients also "inheirit" this requirement from HTTP/1.1 RFC? If so, could this be included to be more explicit in the present RFC for WebDAV? Presently, I am using mod_rewrite and server side processing with directory forward inheiritance to process through DAV based requests for files and perform translation to the end of line termination string of the DAV requests files based on the client string submitted in the request. This is clunky and is not the "right solution" and I am looking for somehting better such as getting vendors of WebDAV based clients to change. Thanks! -ME -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++ L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z? ------END GEEK CODE BLOCK------ decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html From w3c-dist-auth-request@w3.org Wed Jul 3 16:06:37 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03923 for ; Wed, 3 Jul 2002 16:06:36 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA20392; Wed, 3 Jul 2002 16:03:18 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g63K3Hu26174; Wed, 3 Jul 2002 16:03:17 -0400 (EDT) Resent-Date: Wed, 3 Jul 2002 16:03:17 -0400 (EDT) Resent-Message-Id: <200207032003.g63K3Hu26174@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g63K3Hw26154 for ; Wed, 3 Jul 2002 16:03:17 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA20386 for ; Wed, 3 Jul 2002 16:03:17 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 03 Jul 2002 16:02:01 -0400 (Eastern Daylight Time) Received: from ATL1VEXC006.usdom004.tco.tc ([209.225.56.58]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 3 Jul 2002 16:02:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Jul 2002 16:01:29 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA601736D822@ATL1VEXC006.usdom004.tco.tc> Thread-topic: I-D ACTION:draft-mealling-iana-xmlns-registry-04.txt thread-index: AcIixYeLSHoOEQftSM2hp+CL2xh2bwABsfJg From: "Lisa Dusseault" To: "Julian Reschke" , "Webdav WG" X-OriginalArrivalTime: 03 Jul 2002 20:02:01.0146 (UTC) FILETIME=[7E8A49A0:01C222CC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g63K3Hw26154 Subject: RE: I-D ACTION:draft-mealling-iana-xmlns-registry-04.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6371 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Well, one possibility is that a set of custom WebDAV properties (or at the limit, just one) could be expressed in an XML schema, and that schema could be registered. Another possibility is that committed individuals could work with Mealling to see if it's feasible for the registry specification to include specific element names. lisa -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Wednesday, July 03, 2002 12:13 PM To: Lisa Dusseault; Webdav WG Subject: RE: I-D ACTION:draft-mealling-iana-xmlns-registry-04.txt I'm not sure... this is a registry for namespace names, DTD identifiers, XML schemas or RDF schemas -- not for specific element names. How do you think it can be applied to WebDAV properties? > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, July 03, 2002 8:45 PM > To: Webdav WG > Subject: FW: I-D ACTION:draft-mealling-iana-xmlns-registry-04.txt > > > FYI - I don't think Mealling's XML registry draft has been discussed on > the list yet, so I wanted to point it out. It may be useful to register > custom WebDAV properties. > > Lisa > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, July 03, 2002 3:30 AM > Subject: I-D ACTION:draft-mealling-iana-xmlns-registry-04.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : The IETF XML Registry > Author(s) : M. Mealling > Filename : draft-mealling-iana-xmlns-registry-04.txt > Pages : 7 > Date : 02-Jul-02 > > This documenet describes an IANA maintained registry for IETF > standards which use XML related items such as Namespaces, DTD, > Schemas, and RDF Schemas. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mealling-iana-xmlns-registry-0 > 4.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-mealling-iana-xmlns-registry-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-mealling-iana-xmlns-registry-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. > From w3c-dist-auth-request@w3.org Wed Jul 3 16:12:57 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04324 for ; Wed, 3 Jul 2002 16:12:57 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA23288; Wed, 3 Jul 2002 16:11:33 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g63KBWC26802; Wed, 3 Jul 2002 16:11:32 -0400 (EDT) Resent-Date: Wed, 3 Jul 2002 16:11:32 -0400 (EDT) Resent-Message-Id: <200207032011.g63KBWC26802@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g63KBVw26778 for ; Wed, 3 Jul 2002 16:11:31 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA23223 for ; Wed, 3 Jul 2002 16:11:31 -0400 Received: (qmail 6202 invoked by uid 0); 3 Jul 2002 20:11:00 -0000 Received: from p3ee24735.dip.t-dialin.net (HELO lisa) (62.226.71.53) by mail.gmx.net (mp009-rz3) with SMTP; 3 Jul 2002 20:11:00 -0000 From: "Julian Reschke" To: "Webdav WG" Date: Wed, 3 Jul 2002 22:10:59 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <27889B08CAEC7049B68FAD8717BA601736D822@ATL1VEXC006.usdom004.tco.tc> Importance: Normal Subject: RE: I-D ACTION:draft-mealling-iana-xmlns-registry-04.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6372 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I know that a property registry has been on the to-do list for a long time, yet I'm not sure what the goal would be. For DAV: properties, I think we have established that they MUST be defined in a WebDAV related RFC. It may make sense to come up with an informational document that lists all RFC2518/RFC3253/RFC(ACL) properties, but do third-party properties really need a registry? In the general case, I'd expect that the creator of a new property will use it's namespace name to make a namespace description document (for instance in RDDL) available. Do we really need more? > -----Original Message----- > From: Lisa Dusseault [mailto:ldusseault@xythos.com] > Sent: Wednesday, July 03, 2002 10:01 PM > To: Julian Reschke; Webdav WG > Subject: RE: I-D ACTION:draft-mealling-iana-xmlns-registry-04.txt > > > Well, one possibility is that a set of custom WebDAV properties (or at > the limit, just one) could be expressed in an XML schema, and that > schema could be registered. Another possibility is that committed > individuals could work with Mealling to see if it's feasible for the > registry specification to include specific element names. > > lisa > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Wednesday, July 03, 2002 12:13 PM > To: Lisa Dusseault; Webdav WG > Subject: RE: I-D ACTION:draft-mealling-iana-xmlns-registry-04.txt > > I'm not sure... this is a registry for namespace names, DTD identifiers, > XML > schemas or RDF schemas -- not for specific element names. How do you > think > it can be applied to WebDAV properties? > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Wednesday, July 03, 2002 8:45 PM > > To: Webdav WG > > Subject: FW: I-D ACTION:draft-mealling-iana-xmlns-registry-04.txt > > > > > > FYI - I don't think Mealling's XML registry draft has been discussed > on > > the list yet, so I wanted to point it out. It may be useful to > register > > custom WebDAV properties. > > > > Lisa > > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Wednesday, July 03, 2002 3:30 AM > > Subject: I-D ACTION:draft-mealling-iana-xmlns-registry-04.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : The IETF XML Registry > > Author(s) : M. Mealling > > Filename : draft-mealling-iana-xmlns-registry-04.txt > > Pages : 7 > > Date : 02-Jul-02 > > > > This documenet describes an IANA maintained registry for IETF > > standards which use XML related items such as Namespaces, DTD, > > Schemas, and RDF Schemas. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-mealling-iana-xmlns-registry-0 > > 4.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-mealling-iana-xmlns-registry-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-mealling-iana-xmlns-registry-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. > > > From w3c-dist-auth-request@w3.org Wed Jul 3 16:21:16 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04696 for ; Wed, 3 Jul 2002 16:21:16 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA26146; Wed, 3 Jul 2002 16:19:53 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g63KJqb27479; Wed, 3 Jul 2002 16:19:52 -0400 (EDT) Resent-Date: Wed, 3 Jul 2002 16:19:52 -0400 (EDT) Resent-Message-Id: <200207032019.g63KJqb27479@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g63KJpw27459 for ; Wed, 3 Jul 2002 16:19:51 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA26095 for ; Wed, 3 Jul 2002 16:19:52 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 03 Jul 2002 16:19:21 -0400 (Eastern Daylight Time) Received: from ATL1VEXC006.usdom004.tco.tc ([209.225.56.58]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 3 Jul 2002 16:19:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 3 Jul 2002 16:18:49 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA6017371BA0@ATL1VEXC006.usdom004.tco.tc> Thread-topic: Tx of text type docs and CR/LF, CR, LF translation thread-index: AcIix65z6Fon8u7BRX64NnYVwx1pzgABQ5xA From: "Lisa Dusseault" To: "ME" , X-OriginalArrivalTime: 03 Jul 2002 20:19:20.0903 (UTC) FILETIME=[EA489D70:01C222CE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g63KJpw27459 Subject: RE: Tx of text type docs and CR/LF, CR, LF translation Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6373 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit The problem you describe is not particularly a WebDAV problem. IMAP and FTP are subject to the same problems. MIME also does not attempt to fix the problem. The HTTP 1.1 specification does make some attempt to improve the situation, and it works *when viewing in the browser*. It's not clear how browsers should save files though. The browser could: - save the file the same way it was downloaded - save the transformed file, replacing single CR or LF with CRLF Either approach leads to problems. The current common approach, where the browser saves the file the way it was downloaded, means the file may be unusable when viewed in various text editors. However, if the browser transforms the file, it may be altering the file inappropriately. The transformation assumes that wherever CR or LF is used CRLF is appropriate, and that may not be true for all uses of 'text/plain'. I see why you wish attention to be brought to this subject, but the real offenders are not WebDAV clients. It's applications like NotePad that can't display reasonable file formats that are problematic. Those implementers are unlikely to read this list or the WebDAV specification. You might try reporting this behavior as a bug to the manufacturers of the offending software. Lisa -----Original Message----- From: ME [mailto:dugan@passwall.com] Sent: Wednesday, July 03, 2002 12:17 PM To: w3c-dist-auth@w3.org Subject: Q?: Tx of text type docs and CR/LF, CR, LF translation Hello, I have searched with google, read afew dav FAQs, and looked through some RFC before posting this message here. This is my first post to any W3/IETF list, so please bear with me for any mistakes I may make. :-) Problem: When WebDAV enabled clients (tested with "MS Web Folders", "Cadaver", and "Goliath") request a text file (text/plain, text/html) from a DavEnabled Webserver (in this case Apache 1.3.26 with mod-dav-1.0.3 running over SSL) the file is transmitted from the server with the same line termination the file had when examined on the server from a shell. Files previously edited with SimpleText (MacOS), or notepad (Windows) and stored on the server with netatalk-asun or samba contain CR (^M) or CRLF (^M^J) respectively. Files created from Linux bash with emacs/vi have the LF (^J) as the line termination char. Files created strictly from a Mac are not in "human readable format" when the windows user opens then with notepad. Files created strictly from a Windows box are not in "human readable format" when the mac user opens then with SimpleText. Forcing users to use a web authoring tool, or "BBEdit" (Mac) or something like Codewarrior Editor (Windows) that can deal with the 3 common line terminations strings for files and leave the file in "human readable format" are known, but not desired. Web browsers (Netscape, MSIE, Lynx) read these files from the same web server and perform proper translation such that the browser subsitutes the client OS's own line break for the served content's body (or file's contents.) This seems to echo rfc2616 , section: 3.7.1   "Canonicalization and Text Defaults:" ( http://asg.web.cmu.edu/rfc/rfc2616.html ) "When in canonical form, media subtypes of the "text" type use CRLF as the text line break. HTTP relaxes this requirement and allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an entire entity-body. HTTP applications MUST accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP." So, here is my thought: If RFC for HTTP/1.1 states "HTTP applications must accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP." and WebDAV clients are considered HTTP Applications, and the specs for WebDAV include use of HTTP for transmission of text type docs, then shouldn't WebDAV clients also "inheirit" this requirement from HTTP/1.1 RFC? If so, could this be included to be more explicit in the present RFC for WebDAV? Presently, I am using mod_rewrite and server side processing with directory forward inheiritance to process through DAV based requests for files and perform translation to the end of line termination string of the DAV requests files based on the client string submitted in the request. This is clunky and is not the "right solution" and I am looking for somehting better such as getting vendors of WebDAV based clients to change. Thanks! -ME -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++ L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z? ------END GEEK CODE BLOCK------ decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html From w3c-dist-auth-request@w3.org Wed Jul 3 17:29:53 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07401 for ; Wed, 3 Jul 2002 17:29:52 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA12921; Wed, 3 Jul 2002 17:27:48 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g63LRkB05968; Wed, 3 Jul 2002 17:27:46 -0400 (EDT) Resent-Date: Wed, 3 Jul 2002 17:27:46 -0400 (EDT) Resent-Message-Id: <200207032127.g63LRkB05968@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g63LRjw05945 for ; Wed, 3 Jul 2002 17:27:45 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA12904 for ; Wed, 3 Jul 2002 17:27:45 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 03 Jul 2002 17:27:14 -0400 (Eastern Daylight Time) Received: from ATL1VEXC006.usdom004.tco.tc ([209.225.56.58]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 3 Jul 2002 17:27:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Jul 2002 17:26:42 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA6017371BA2@ATL1VEXC006.usdom004.tco.tc> Thread-topic: New RFC2518bis draft thread-index: AcIgfrPmEvkm6Lw3TlmQz+11aHiYegCVSFVw From: "Lisa Dusseault" To: X-OriginalArrivalTime: 03 Jul 2002 21:27:14.0131 (UTC) FILETIME=[661DE230:01C222D8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g63LRjw05945 Subject: RE: New RFC2518bis draft Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6374 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Julian, I've made a number of your suggestions exactly, or used them to guide me to do a better job. I have comments on some others. > Section 2.2: where to put xml:lang attribute > > This may need to be clarified, but a better place is to do it where > property > values are defined. I think this is part of a larger discussion... I don't recall any opinions from others yet. > Section 3.3: Attributes in property values are significant. > > Do not add the new text. Instead, replace > > "The value of a property when expressed in XML MUST be well formed." > > by > > "The value of a property element formally consists of the following > items > defined in [XMLINFOSET], chapter 2.2: > > - Child element and character information items (element and text > content), > - Attributes, > - Namespace attributes (as far as used by child information items) > - In-scope namespaces (as far as used by child information items) > - The value of an xml:lang attribute if in scope of the property > element." 1) What is XMLINFOSET? 2) This definition of a property value adds significant definitions to the specification. Are the implications of each of these consistent with existing implementations? > Section 4.2: Lock-null resources removed > > Text mentions: "SHOULD default to reasonable, or reasonably blank, values > for other properties like getcontentlanguage" > > I disagree: unknown properties should be treated as not being present > (just > like the relevant HTTP headers), NOT as blank. Any reasons? Any suggested text? Is it OK for these particular properties to be not present? > Section 4.5: Propertybehavior (in MOVE, COPY) removed > > Quote: "Live properties described in this document SHOULD be duplicated as > identically behaving live properties at the destination resource. If a > property cannot be copied live, then its value MUST be duplicated, > octet-for-octet, in an identically named, dead property on the destination > resource. " > > Comments: > > 1) did we reach consensus on this? We did reach consensus on removing propertybehavior, IMO. I attempted to turn the vague idea into text. This particular text existed before, by the way so is in some sense a different issue. > 2) If we did, the wording "octet-by-octet" doesn't make sense (because > we're > talking of property values) You may be right. Do you have another suggestion? Lisa From w3c-dist-auth-request@w3.org Wed Jul 3 17:31:52 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07440 for ; Wed, 3 Jul 2002 17:31:52 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA13779; Wed, 3 Jul 2002 17:30:09 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g63LU8X06266; Wed, 3 Jul 2002 17:30:08 -0400 (EDT) Resent-Date: Wed, 3 Jul 2002 17:30:08 -0400 (EDT) Resent-Message-Id: <200207032130.g63LU8X06266@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g63LU8w06246 for ; Wed, 3 Jul 2002 17:30:08 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA13770 for ; Wed, 3 Jul 2002 17:30:07 -0400 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g63LU6k21053 for ; Wed, 3 Jul 2002 14:30:06 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 3 Jul 2002 14:30:06 -0700 Received: from luthji (luthji.apple.com [17.202.43.76]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g63LU5T15843; Wed, 3 Jul 2002 14:30:05 -0700 (PDT) Date: Wed, 3 Jul 2002 14:30:05 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: Jim Luther To: w3c-dist-auth@w3.org, ME Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <0AC0871A-8ECC-11D6-B98D-0003934B6A22@apple.com> X-Mailer: Apple Mail (2.482) Subject: Re: Q?: Tx of text type docs and CR/LF, CR, LF translation Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6375 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wednesday, July 3, 2002, at 12:17 PM, ME wrote: > Files created strictly from a Mac are not in "human readable format" > when the windows user opens then with notepad. > > Files created strictly from a Windows box are not in "human readable > format" when the mac user opens then with SimpleText. On Wednesday, July 3, 2002, at 01:18 PM, Lisa Dusseault wrote: > I see why you wish attention to be brought to this subject, but the real > offenders are not WebDAV clients. It's applications like NotePad that > can't display reasonable file formats that are problematic. Those > implementers are unlikely to read this list or the WebDAV specification. I agree with Lisa -- that is a text editor problem, not a WebDAV client problem. If you try the try again with Mac OS X's TextEdit application, you'll see that it handles CR, LF and CR/LF correctly. It's *very* unlikely that Mac OS 9's SimpleText application will ever be changed. - Jim From w3c-dist-auth-request@w3.org Wed Jul 3 23:56:00 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26864 for ; Wed, 3 Jul 2002 23:56:00 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA01121; Wed, 3 Jul 2002 23:54:12 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g643sAk01455; Wed, 3 Jul 2002 23:54:10 -0400 (EDT) Resent-Date: Wed, 3 Jul 2002 23:54:10 -0400 (EDT) Resent-Message-Id: <200207040354.g643sAk01455@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g643sAw01435 for ; Wed, 3 Jul 2002 23:54:10 -0400 (EDT) Received: from nhweb.newgen.co.in ([202.89.68.162]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA01113 for ; Wed, 3 Jul 2002 23:54:07 -0400 Received: from maggon (ws40.newgen.co.in [192.168.5.40]) by nhweb.newgen.co.in (8.12.3/8.12.3/Debian -4) with SMTP id g6443mDR027939 for ; Thu, 4 Jul 2002 09:33:49 +0530 From: "Sameer Maggon" To: "WebDAV IETF" Date: Thu, 4 Jul 2002 09:22:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: Problem in Frontpage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6376 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I have a Webdav server running on Apache-Tomcat and on the client machine i've made a Web Folder (Windows 2000 pro). I can easily access that web folder through Network Neigh.. and Explorer.. but i'am facing a small problem.. I've created an HTML page in Frontpage and inserted a Hyperlink in the Document. If give the name of the Web Folder directly as 'http://machinemname/webdav/rename.txt' its working fine.. but if I right click to make a Hyperlink and then browse through the Web Folder and then point to a File.. and Associate it with the Link.. The hyperlink points to a temporary file in the Disk. 'file:///......'. How do i solve the problem...??? Thanx in advance Sameer From w3c-dist-auth-request@w3.org Thu Jul 4 02:04:37 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05795 for ; Thu, 4 Jul 2002 02:04:36 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA15342; Thu, 4 Jul 2002 02:01:46 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6461ZW09220; Thu, 4 Jul 2002 02:01:35 -0400 (EDT) Resent-Date: Thu, 4 Jul 2002 02:01:35 -0400 (EDT) Resent-Message-Id: <200207040601.g6461ZW09220@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6461Yw09200 for ; Thu, 4 Jul 2002 02:01:34 -0400 (EDT) Received: from cpimssmtpu01.email.msn.com (cpimssmtpu01.email.msn.com [207.46.181.77]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA15285 for ; Thu, 4 Jul 2002 02:01:34 -0400 Received: from centro ([63.231.39.78]) by cpimssmtpu01.email.msn.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 3 Jul 2002 23:00:14 -0700 Reply-To: From: "Dennis E. Hamilton" To: "Sameer Maggon" , "WebDAV IETF" Date: Wed, 3 Jul 2002 23:01:01 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 04 Jul 2002 06:00:14.0199 (UTC) FILETIME=[10778870:01C22320] Subject: RE: Problem in Frontpage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6377 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Microsoft FrontPage is not a DAV-enabled client. At least not for versions through FrontPage 2000. When accessing a Web Folder, FrontPage 2000 will fail if the target site does not support FrontPage Server extensions. It's Web Folders integration is not as complete as that of some other Office applications. -- Dennis Dennis E. Hamilton AIIM DMware Technical Coordinator ------------------ mailto:dennis.hamilton@acm.org tel. +1-206-932-6970 http://DMware.info/ cel. +1-206-779-9430 ODMA Support http://ODMA.info/ -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Sameer Maggon Sent: Thursday, July 04, 2002 09:23 To: WebDAV IETF Subject: Problem in Frontpage Hi, I have a Webdav server running on Apache-Tomcat and on the client machine i've made a Web Folder (Windows 2000 pro). I can easily access that web folder through Network Neigh.. and Explorer.. but i'am facing a small problem.. I've created an HTML page in Frontpage and inserted a Hyperlink in the Document. If give the name of the Web Folder directly as 'http://machinemname/webdav/rename.txt' its working fine.. but if I right click to make a Hyperlink and then browse through the Web Folder and then point to a File.. and Associate it with the Link.. The hyperlink points to a temporary file in the Disk. 'file:///......'. How do i solve the problem...??? Thanx in advance Sameer From w3c-dist-auth-request@w3.org Thu Jul 4 02:33:47 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09087 for ; Thu, 4 Jul 2002 02:33:46 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA18809; Thu, 4 Jul 2002 02:32:22 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g646WLZ10299; Thu, 4 Jul 2002 02:32:21 -0400 (EDT) Resent-Date: Thu, 4 Jul 2002 02:32:21 -0400 (EDT) Resent-Message-Id: <200207040632.g646WLZ10299@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g646WKw10276 for ; Thu, 4 Jul 2002 02:32:20 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id CAA18780 for ; Thu, 4 Jul 2002 02:32:20 -0400 Received: (qmail 3054 invoked by uid 0); 4 Jul 2002 06:31:48 -0000 Received: from p3ee24735.dip.t-dialin.net (HELO lisa) (62.226.71.53) by mail.gmx.net (mp016-rz3) with SMTP; 4 Jul 2002 06:31:48 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , Date: Thu, 4 Jul 2002 08:31:54 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <27889B08CAEC7049B68FAD8717BA6017371BA2@ATL1VEXC006.usdom004.tco.tc> Importance: Normal Subject: RE: New RFC2518bis draft Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6378 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, July 03, 2002 11:27 PM > To: w3c-dist-auth@w3c.org > Subject: RE: New RFC2518bis draft > > > > Julian, I've made a number of your suggestions exactly, or used them to > guide me to do a better job. I have comments on some others. > > > Section 2.2: where to put xml:lang attribute > > > > This may need to be clarified, but a better place is to do it where > > property > > values are defined. > > I think this is part of a larger discussion... I don't recall any > opinions from others yet. Geoff: > > Section 3.3: Attributes in property values are significant. > > > > Do not add the new text. Instead, replace > > > > "The value of a property when expressed in XML MUST be well > formed." > > > > by > > > > "The value of a property element formally consists of the > following > > items > > defined in [XMLINFOSET], chapter 2.2: > > > > - Child element and character information items (element and text > > content), > > - Attributes, > > - Namespace attributes (as far as used by child information items) > > - In-scope namespaces (as far as used by child information items) > > - The value of an xml:lang attribute if in scope of the property > > element." > > 1) What is XMLINFOSET? > 2) This definition of a property value adds significant definitions to > the specification. Are the implications of each of these consistent with > existing implementations? It adds definitions where the spec used to be silent. I think this is a good thing. What may be controversial is the requirement to persist attributes attached to the property element itself, but AFAIK this is supported both in IIS and moddav (will have to check). > > Section 4.2: Lock-null resources removed > > > > Text mentions: "SHOULD default to reasonable, or reasonably blank, > values > > for other properties like getcontentlanguage" > > > > I disagree: unknown properties should be treated as not being present > > (just > > like the relevant HTTP headers), NOT as blank. > > Any reasons? Any suggested text? Is it OK for these particular > properties to be not present? The reason is that "being blank" is *different* from "not being present". This is something we need to sort out for all resources, not only the formerly lock-null-resources. So the text *here* probably shouldn't say anything at all, and then we should clarify which DAV: properties are really required. Please do not require to report "reasonable defaults" for things like the content type when the server doesn't know. That would break HTTP. > > Section 4.5: Propertybehavior (in MOVE, COPY) removed > > > > Quote: "Live properties described in this document SHOULD be > duplicated as > > identically behaving live properties at the destination resource. If > a > > property cannot be copied live, then its value MUST be duplicated, > > octet-for-octet, in an identically named, dead property on the > destination > > resource. " > > > > Comments: > > > > 1) did we reach consensus on this? > We did reach consensus on removing propertybehavior, IMO. I attempted to Correct. > turn the vague idea into text. This particular text existed before, by > the way so is in some sense a different issue. Maybe MOVE and COPY need to be treated differently. If a server can't move a resource with it's live properties staying alive, I'd claim that it actually can't move the resource at all, and thus MOVE should fail (requiring the client to fall back to COPY/DELETE). Opinions? > > 2) If we did, the wording "octet-by-octet" doesn't make sense (because > > we're > > talking of property values) > You may be right. Do you have another suggestion? Just remove it. "Duplicating" a property value is well-defined, as long as the "property value" is well-defined (which we're trying to fix). Julian From w3c-dist-auth-request@w3.org Thu Jul 4 03:08:46 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10029 for ; Thu, 4 Jul 2002 03:08:45 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA22847; Thu, 4 Jul 2002 03:08:02 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g64780s12405; Thu, 4 Jul 2002 03:08:00 -0400 (EDT) Resent-Date: Thu, 4 Jul 2002 03:08:00 -0400 (EDT) Resent-Message-Id: <200207040708.g64780s12405@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6477xw12384 for ; Thu, 4 Jul 2002 03:07:59 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA22844 for ; Thu, 4 Jul 2002 03:07:59 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Thu, 04 Jul 2002 03:05:51 -0400 (Eastern Daylight Time) Received: from ATL1VEXC006.usdom004.tco.tc ([209.225.56.58]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 4 Jul 2002 03:05:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Jul 2002 03:05:50 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA601736D82E@ATL1VEXC006.usdom004.tco.tc> Thread-topic: Problem in Frontpage thread-index: AcIjD++PnSppIABcQtmFZxYholu+gwAGTJHw From: "Lisa Dusseault" To: "Sameer Maggon" Cc: "Webdav WG" X-OriginalArrivalTime: 04 Jul 2002 07:05:50.0837 (UTC) FILETIME=[3AE2D250:01C22329] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g6477xw12384 Subject: RE: Problem in Frontpage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6379 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit It seems your version of FrontPage doesn't directly support WebDAV. You might check to see if there is a version that can browse WebDAV servers directly, but I don't think there is one. Lisa > -----Original Message----- > From: Sameer Maggon [mailto:maggon@newgen.co.in] > Sent: Thursday, July 04, 2002 9:23 AM > To: WebDAV IETF > Subject: Problem in Frontpage > > > Hi, > I have a Webdav server running on Apache-Tomcat and on the client > machine > i've made a Web Folder (Windows 2000 pro). I can easily access that web > folder through Network Neigh.. and Explorer.. but i'am facing a small > problem.. I've created an HTML page in Frontpage and inserted a Hyperlink > in > the Document. If give the name of the Web Folder directly as > 'http://machinemname/webdav/rename.txt' its working fine.. but if I right > click to make a Hyperlink and then browse through the Web Folder and then > point to a File.. and Associate it with the Link.. The hyperlink points to > a > temporary file in the Disk. 'file:///......'. > > How do i solve the problem...??? > > Thanx in advance > Sameer From w3c-dist-auth-request@w3.org Thu Jul 4 04:03:27 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11056 for ; Thu, 4 Jul 2002 04:03:27 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA30147; Thu, 4 Jul 2002 04:02:35 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6482Yt16966; Thu, 4 Jul 2002 04:02:34 -0400 (EDT) Resent-Date: Thu, 4 Jul 2002 04:02:34 -0400 (EDT) Resent-Message-Id: <200207040802.g6482Yt16966@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6482Xw16946 for ; Thu, 4 Jul 2002 04:02:33 -0400 (EDT) Received: from bosvwl01.infy.com (bosvwl01.infy.com [216.52.49.35]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA30141 for ; Thu, 4 Jul 2002 04:02:33 -0400 Received: from 192.168.200.82 by bosvwl01.infy.com (InterScan E-Mail VirusWall NT); Thu, 04 Jul 2002 03:56:40 -0400 Received: from BLRKECIMR01.ad.infosys.com ([192.168.200.58]) by INDHUBBHS02.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Jul 2002 13:32:32 +0530 Received: from kecmsg05.ad.infosys.com ([192.168.117.11]) by BLRKECIMR01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Jul 2002 13:32:32 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Date: Thu, 4 Jul 2002 13:32:32 +0530 Message-ID: <9DB6357440BAD411A6A00050BA8CA56B09AF6A2A@kecmsg05.ad.infosys.com> Thread-Topic: Doubt in error response Thread-Index: AcIjMSabU3YS3msNRc23tenVCbMBTw== From: "ganesh_k" To: X-OriginalArrivalTime: 04 Jul 2002 08:02:32.0853 (UTC) FILETIME=[26A54450:01C22331] Subject: Doubt in error response Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6380 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all What error response is the WebDAV server supposed to send if it receives an UNLOCK request on a resource which is not locked in the first place? Is it it 403- forbidden or method failed or something else? Regds Ganesh From w3c-dist-auth-request@w3.org Sat Jul 6 15:02:51 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28929 for ; Sat, 6 Jul 2002 15:02:51 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA09854; Sat, 6 Jul 2002 15:01:44 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g66J10Y20559; Sat, 6 Jul 2002 15:01:00 -0400 (EDT) Resent-Date: Sat, 6 Jul 2002 15:01:00 -0400 (EDT) Resent-Message-Id: <200207061901.g66J10Y20559@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g66J0xw20539 for ; Sat, 6 Jul 2002 15:00:59 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA09599 for ; Sat, 6 Jul 2002 15:00:59 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g66J05g5168202; Sat, 6 Jul 2002 15:00:05 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g66J03M83164; Sat, 6 Jul 2002 15:00:03 -0400 To: "Julian Reschke" Cc: "Lisa Dusseault" , w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Sat, 6 Jul 2002 14:45:00 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_06262002 Pre-release 2|June 26, 2002) at 07/06/2002 15:00:04 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE17DDFF5C5918f9e8a93df938690918c0ABBE17DDFF5C591" Content-Disposition: inline Subject: RE: New RFC2518bis draft, xml:lang Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6381 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE17DDFF5C5918f9e8a93df938690918c0ABBE17DDFF5C591 Content-type: text/plain; charset=US-ASCII > > I think this is part of a larger discussion... I don't recall any > > opinions from others yet. > Geoff: > I also expressed support for this. Lacking a significant reason not to, it seems like the way to go. If xml:lang was in scope for the property when it was set, it should remain so when returned via PROPFIND. Where that attribute is set to bring it in to scope is up to the server as long as it satisfies XML scoping rules to do so. Similarly, I believe if the property had no xml:lang declaration in scope when set, it should not have one when returned via PROPFIND. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com --0__=0ABBE17DDFF5C5918f9e8a93df938690918c0ABBE17DDFF5C591 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

> > I think this is part of a larger discussion... I don't recall any
> > opinions from others yet.
> Geoff:
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0318.html>

I also expressed support for this. Lacking a significant reason not to,
it seems like the way to go. If xml:lang was in scope for the property
when it was set, it should remain so when returned via PROPFIND. Where
that attribute is set to bring it in to scope is up to the server as long
as it satisfies XML scoping rules to do so. Similarly, I believe if the
property had no xml:lang declaration in scope when set, it should not have
one when returned via PROPFIND.




------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com
--0__=0ABBE17DDFF5C5918f9e8a93df938690918c0ABBE17DDFF5C591-- From w3c-dist-auth-request@w3.org Sat Jul 6 19:48:51 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02663 for ; Sat, 6 Jul 2002 19:48:51 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA03229; Sat, 6 Jul 2002 19:34:36 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g66NYZ929973; Sat, 6 Jul 2002 19:34:35 -0400 (EDT) Resent-Date: Sat, 6 Jul 2002 19:34:35 -0400 (EDT) Resent-Message-Id: <200207062334.g66NYZ929973@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g66NYRw29898 for ; Sat, 6 Jul 2002 19:34:27 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA03168 for ; Sat, 6 Jul 2002 19:34:26 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Sat, 06 Jul 2002 19:27:07 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sat, 6 Jul 2002 19:33:55 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1075FD3D3@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Sat, 6 Jul 2002 19:33:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: New RFC2518bis draft Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6383 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Lisa Dusseault > Section 4.5: Propertybehavior (in MOVE, COPY) removed Maybe MOVE and COPY need to be treated differently. If a server can't move a resource with it's live properties staying alive, I'd claim that it actually can't move the resource at all, and thus MOVE should fail (requiring the client to fall back to COPY/DELETE). Opinions? I agree that MOVE and COPY need to be treated differently, and I further agree that MOVE should fail if live properties cannot be maintained (requiring the client to fall back to COPY/DELETE). Lisa: I noticed that you did not respond to Julian's concern about deprecating DAV:allprop. Does this mean that you agree with his proposal to have it mean "2518 properties and all dead properties"? Note that I am happy to have DAV:allprop be given this interpretation. Cheers, Geoff From w3c-dist-auth-request@w3.org Sat Jul 6 20:40:10 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02662 for ; Sat, 6 Jul 2002 19:48:51 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA03186; Sat, 6 Jul 2002 19:34:29 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g66NYSn29931; Sat, 6 Jul 2002 19:34:28 -0400 (EDT) Resent-Date: Sat, 6 Jul 2002 19:34:28 -0400 (EDT) Resent-Message-Id: <200207062334.g66NYSn29931@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g66NYRw29899 for ; Sat, 6 Jul 2002 19:34:27 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA03167 for ; Sat, 6 Jul 2002 19:34:26 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Sat, 06 Jul 2002 19:27:07 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sat, 6 Jul 2002 19:33:55 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1075FD3D1@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Sat, 6 Jul 2002 19:33:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6382 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I'm happy to have one of the role elements be an href, and have this href be the XLink role URI, e.g.: /some/xlink/role/uri ... P.S. I know that isn't what Julian was suggesting, but I believe it answers his concerns while still letting the WebDAV role be an extensible element. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Sunday, June 30, 2002 4:09 AM To: Jason Crawford; Clemm, Geoff Cc: w3c-dist-auth@w3c.org Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED I don't think this a good idea. The W3C has decided to treat link roles as URIs. If we decide to define a different mechanism, we will sooner or later have to define a mapping of XLink role URIs to our role schema (because other systems with which a WebDAv server connect may have decided to use standard Xlink roles). Furthermore this brings *us* into the business of defining roles (I think the spec should only define a mechanism to marshall them, that's it). Julian -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford Sent: Sunday, June 30, 2002 12:06 AM To: Clemm, Geoff Cc: w3c-dist-auth@w3c.org Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED I've made a proposal in the following post... http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0141.html There have been several suggestions. I'd like to focus on one of them. The suggestion is the suggestion to make the role be a tag rather than an attribute. The justification was that this could allow for structured roles. That actually sounds good to me in principle, but I'd like to make sure we're actually likely to capitalize on it. Could someone suggest some roles that they'd like to see. Also if you can think of any *structured* roles, please put them on the table so that we can at least see how that might work. Thanks, J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Sun Jul 7 14:18:19 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29076 for ; Sun, 7 Jul 2002 14:18:19 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA28612; Sun, 7 Jul 2002 14:17:46 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g67IHhS13665; Sun, 7 Jul 2002 14:17:43 -0400 (EDT) Resent-Date: Sun, 7 Jul 2002 14:17:43 -0400 (EDT) Resent-Message-Id: <200207071817.g67IHhS13665@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g67IHfw13642 for ; Sun, 7 Jul 2002 14:17:41 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA28607 for ; Sun, 7 Jul 2002 14:17:41 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Sun, 07 Jul 2002 14:16:57 -0400 (Eastern Daylight Time) Received: from ATL1VEXC006.usdom004.tco.tc ([209.225.56.58]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 7 Jul 2002 14:16:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 7 Jul 2002 14:16:56 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA6017371BA3@ATL1VEXC006.usdom004.tco.tc> Thread-topic: New RFC2518bis draft thread-index: AcIlR2o7SmMugJflTHCQvZjzpXxYYQAmaHxA From: "Lisa Dusseault" To: "Clemm, Geoff" , X-OriginalArrivalTime: 07 Jul 2002 18:16:56.0827 (UTC) FILETIME=[7A868CB0:01C225E2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g67IHfw13642 Subject: RE: New RFC2518bis draft Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6384 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > Lisa: I noticed that you did not respond to Julian's concern > about deprecating DAV:allprop. Does this mean that you agree with > his proposal to have it mean "2518 properties and all dead properties"? > Note that I am happy to have DAV:allprop be given this interpretation. With an issue as difficult as "allprop", where it was originally given a meaning that we cannot continue to support, I do not believe that every concern can be completely addressed. I think all of Julian's concerns are valid and share them, yet we still have to compromise among these concerns to find a solution. The proposed text in 2518 bis does deprecate allprop as well as redefine it to a certain extent. If 'allprop' is redefined, without being renamed or deprecated, it will cause confusion for new implementors. Here are some of the options: 1) Deprecate. 2) Redefine and leave in place. Disadvantage: confusion to new implementers who will be misled by the apparent meaning of 'allprop' into misunderstanding what it does. 3) Rename and redefine (e.g. 'deadprop', defined to return all the dead properties). Disadvantage: servers that were previously compliant with 2518 will not be compliant with 2518bis. No functionality is lost by deprecating allprop - clients can always use the 'propname' request to find all the dead and live property names, and select among those. I'd like to see broader support for one of the other options and discussion of the tradeoffs before changing the current proposed text. lisa From w3c-dist-auth-request@w3.org Sun Jul 7 15:21:40 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01911 for ; Sun, 7 Jul 2002 15:21:40 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA05084; Sun, 7 Jul 2002 15:21:07 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g67JKvP16963; Sun, 7 Jul 2002 15:20:57 -0400 (EDT) Resent-Date: Sun, 7 Jul 2002 15:20:57 -0400 (EDT) Resent-Message-Id: <200207071920.g67JKvP16963@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g67JKtw16943 for ; Sun, 7 Jul 2002 15:20:55 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA05042 for ; Sun, 7 Jul 2002 15:20:55 -0400 Received: (qmail 24817 invoked by uid 0); 7 Jul 2002 19:20:13 -0000 Received: from p3ee2477e.dip.t-dialin.net (HELO lisa) (62.226.71.126) by mail.gmx.net (mp012-rz3) with SMTP; 7 Jul 2002 19:20:13 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "Clemm, Geoff" , Date: Sun, 7 Jul 2002 21:20:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <27889B08CAEC7049B68FAD8717BA6017371BA3@ATL1VEXC006.usdom004.tco.tc> Subject: RE: New RFC2518bis draft Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6385 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Sunday, July 07, 2002 8:17 PM > To: Clemm, Geoff; w3c-dist-auth@w3c.org > Subject: RE: New RFC2518bis draft > > > > > Lisa: I noticed that you did not respond to Julian's concern > > about deprecating DAV:allprop. Does this mean that you agree with > > his proposal to have it mean "2518 properties and all dead > properties"? > > Note that I am happy to have DAV:allprop be given this interpretation. > > With an issue as difficult as "allprop", where it was originally given a > meaning that we cannot continue to support, I do not believe that every > concern can be completely addressed. I think all of Julian's concerns > are valid and share them, yet we still have to compromise among these > concerns to find a solution. > > The proposed text in 2518 bis does deprecate allprop as well as redefine > it to a certain extent. If 'allprop' is redefined, without being renamed > or deprecated, it will cause confusion for new implementors. Here are > some of the options: > 1) Deprecate. > 2) Redefine and leave in place. Disadvantage: confusion to new > implementers who will be misled by the apparent meaning of 'allprop' > into misunderstanding what it does. Advantage: this is the current situation with RFC3253 and the ACL spec, and this doesn't seem to cause any confusion at all. All we need is to clarify RFC2518. I agree that the name "allprop" will be a bit confusing. But that's something that can be solved by properly explaining it, right? > 3) Rename and redefine (e.g. 'deadprop', defined to return all the dead > properties). Disadvantage: servers that were previously compliant with > 2518 will not be compliant with 2518bis. > > No functionality is lost by deprecating allprop - clients can always use > the 'propname' request to find all the dead and live property names, and > select among those. Yes, but at greatly increased cost, both in number of roundtrips, client complexity and computation time in the server. I've explained this in : "The client will issue two calls: first it will use propname to find the list of properties. Computing whether a live property exists maybe as expensive as computing it (for instance, to find out whether something is checked in/out). *Then* it will submit PROPFIND / prop will all these properties. So as compared to the current situation, the server may have to compute things twice which wouldn't have been computed at all before (since asking for allprop wouldn't require computing live deltaV properties)." In particular this means that if a client really *wants* propname, the server will have to compute whether each and every live property is present, while with the current RFC3253 definition of allprop, adding new live properties doesn't cause any additional overhead *at all*. Could you please address this concern? > I'd like to see broader support for one of the other options and > discussion of the tradeoffs before changing the current proposed text. Actually, I'd like to see a broad discussion before changing the *current* status, as defined by RFC2518/3253. From w3c-dist-auth-request@w3.org Sun Jul 7 20:02:17 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12664 for ; Sun, 7 Jul 2002 20:02:17 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA00467; Sun, 7 Jul 2002 20:01:42 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6801PB29420; Sun, 7 Jul 2002 20:01:25 -0400 (EDT) Resent-Date: Sun, 7 Jul 2002 20:01:25 -0400 (EDT) Resent-Message-Id: <200207080001.g6801PB29420@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6801Ow29400 for ; Sun, 7 Jul 2002 20:01:24 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA00400 for ; Sun, 7 Jul 2002 20:01:24 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Sun, 07 Jul 2002 19:54:02 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sun, 7 Jul 2002 20:00:52 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1075FD41F@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Sun, 7 Jul 2002 20:00:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: New RFC2518bis draft Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6386 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Lisa Dusseault > > The proposed text in 2518 bis does deprecate allprop as well as redefine > it to a certain extent. If 'allprop' is redefined, without being renamed > or deprecated, it will cause confusion for new implementors. Here are > some of the options: > 1) Deprecate. > 2) Redefine and leave in place. Disadvantage: confusion to new > implementers who will be misled by the apparent meaning of 'allprop' > into misunderstanding what it does. Advantage: this is the current situation with RFC3253 and the ACL spec, and this doesn't seem to cause any confusion at all. All we need is to clarify RFC2518. I agree that the name "allprop" will be a bit confusing. But that's something that can be solved by properly explaining it, right? I agree. I have little concern over any confusion resulting from the name "DAV:allprop". The concept of "all dead properties plus 2518 defined properties" is very simple, and should be easy to convey. And even if an implementor gets it wrong and returns some (or all) non-2518 live properties as well, little or no harm is done. > 3) Rename and redefine (e.g. 'deadprop', defined to return all > the dead properties). Disadvantage: servers that were previously > compliant with 2518 will not be compliant with 2518bis. I think this disadvantage significantly outweighs the minor benefits of a slightly better name for this concept. > No functionality is lost by deprecating allprop - clients can always use > the 'propname' request to find all the dead and live property names, and > select among those. Yes, but at greatly increased cost, both in number of roundtrips, client complexity and computation time in the server. I've explained this in : I agree that it is valuable to have a simple mechanism for retrieving all dead properties in one request (especially for a non-zero Depth PROPFIND), and I agree that using DAV:allprop is the most interoperable mechanism for providing this mechanism. Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Jul 8 07:25:51 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10713 for ; Mon, 8 Jul 2002 07:25:51 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA23735; Mon, 8 Jul 2002 07:25:20 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g68BPGY19322; Mon, 8 Jul 2002 07:25:16 -0400 (EDT) Resent-Date: Mon, 8 Jul 2002 07:25:16 -0400 (EDT) Resent-Message-Id: <200207081125.g68BPGY19322@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g68BPFw19302 for ; Mon, 8 Jul 2002 07:25:15 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA23726 for ; Mon, 8 Jul 2002 07:25:14 -0400 Received: (qmail 23048 invoked by uid 0); 8 Jul 2002 11:24:43 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp012-rz3) with SMTP; 8 Jul 2002 11:24:43 -0000 From: "Julian Reschke" To: Date: Mon, 8 Jul 2002 13:24:43 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6387 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > To: Daniel Brotsky > Cc: "Clemm, Geoff" , w3c-dist-auth@w3c.org > Message-ID: > From: "Jason Crawford" > Date: Mon, 14 Jan 2002 15:19:50 -0500 > Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER > > > > In addition to Geoff's answer: > > If you are an administrator trying to unlock a resource obtained by > > someone else, you have to be able to figure out which resource to > > unlock. You can't unlock an internal member of a collection that's > > locked by a depth-inifinity lock without knowing which collection was > > actually locked. > > CAN'T? (going back to an old discussion...) RFC2518, 8.11 says [1]: "The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header from the Request-URI, and all other resources included in the lock. If all resources which have been locked under the submitted lock token can not be unlocked then the UNLOCK request MUST fail. " So do we have agreement that *any* of the URIs affected by a deep lock can be used to do the UNLOCK operation? [1] From w3c-dist-auth-request@w3.org Mon Jul 8 09:53:05 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14683 for ; Mon, 8 Jul 2002 09:53:04 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA16520; Mon, 8 Jul 2002 09:51:39 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g68DpcZ08443; Mon, 8 Jul 2002 09:51:38 -0400 (EDT) Resent-Date: Mon, 8 Jul 2002 09:51:38 -0400 (EDT) Resent-Message-Id: <200207081351.g68DpcZ08443@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g68Dpbw08420 for ; Mon, 8 Jul 2002 09:51:37 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA16504 for ; Mon, 8 Jul 2002 09:51:37 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Mon, 08 Jul 2002 09:44:14 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 09:51:06 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B318@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Mon, 8 Jul 2002 09:51:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6388 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: That is fine with me. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, July 08, 2002 7:25 AM To: w3c-dist-auth@w3.org Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER > To: Daniel Brotsky > Cc: "Clemm, Geoff" , w3c-dist-auth@w3c.org > Message-ID: > From: "Jason Crawford" > Date: Mon, 14 Jan 2002 15:19:50 -0500 > Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER > > > > In addition to Geoff's answer: > > If you are an administrator trying to unlock a resource obtained by > > someone else, you have to be able to figure out which resource to > > unlock. You can't unlock an internal member of a collection that's > > locked by a depth-inifinity lock without knowing which collection was > > actually locked. > > CAN'T? (going back to an old discussion...) RFC2518, 8.11 says [1]: "The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header from the Request-URI, and all other resources included in the lock. If all resources which have been locked under the submitted lock token can not be unlocked then the UNLOCK request MUST fail. " So do we have agreement that *any* of the URIs affected by a deep lock can be used to do the UNLOCK operation? [1] From w3c-dist-auth-request@w3.org Mon Jul 8 11:37:27 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20050 for ; Mon, 8 Jul 2002 11:37:27 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA16160; Mon, 8 Jul 2002 11:36:15 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g68FaDX25651; Mon, 8 Jul 2002 11:36:13 -0400 (EDT) Resent-Date: Mon, 8 Jul 2002 11:36:13 -0400 (EDT) Resent-Message-Id: <200207081536.g68FaDX25651@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g68FaCw25631 for ; Mon, 8 Jul 2002 11:36:13 -0400 (EDT) Received: from smtp-relay-1.adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA16127 for ; Mon, 8 Jul 2002 11:36:11 -0400 Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-1.adobe.com (8.12.3/8.12.3) with ESMTP id g68FblRC016308 for ; Mon, 8 Jul 2002 08:37:47 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-1.corp.adobe.com (8.12.3/8.12.3) with ESMTP id g68Fa8uE023046 for ; Mon, 8 Jul 2002 08:36:08 -0700 (PDT) Received: from dan.local.brotsky.com ([130.248.184.188]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GYXSNB00.KVJ for ; Mon, 8 Jul 2002 08:35:35 -0700 Date: Mon, 8 Jul 2002 08:35:34 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: Dan Brotsky To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 7bit In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1075FD3D3@SUS-MA1IT01> Message-Id: <585EA96C-9288-11D6-87FC-0003931036B4@adobe.com> X-Mailer: Apple Mail (2.482) Subject: Re: New RFC2518bis draft Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6389 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Saturday, July 6, 2002, at 04:33 PM, Clemm, Geoff wrote: > Lisa: I noticed that you did not respond to Julian's concern > about deprecating DAV:allprop. Does this mean that you agree with > his proposal to have it mean "2518 properties and all dead properties"? > Note that I am happy to have DAV:allprop be given this interpretation. > > Cheers, > Geoff I am also happy with changing DAV:allprop to be given this interpretation. I also do NOT want deprecation done of DAV:allprop. I think this can be a simple clarification without damaging existing client interoperability (given the existing actual behavior of servers) or introducing confusion for new ones. dan From w3c-dist-auth-request@w3.org Mon Jul 8 11:39:05 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20158 for ; Mon, 8 Jul 2002 11:39:05 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA16529; Mon, 8 Jul 2002 11:37:57 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g68FbuG25841; Mon, 8 Jul 2002 11:37:56 -0400 (EDT) Resent-Date: Mon, 8 Jul 2002 11:37:56 -0400 (EDT) Resent-Message-Id: <200207081537.g68FbuG25841@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g68Fbtw25821 for ; Mon, 8 Jul 2002 11:37:55 -0400 (EDT) Received: from smtp-relay-2.adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA16501 for ; Mon, 8 Jul 2002 11:37:54 -0400 Received: from inner-relay-2.corp.adobe.com (inner-relay-2 [153.32.1.52]) by smtp-relay-2.adobe.com (8.12.3/8.12.3) with ESMTP id g68FZ6q7022363 for ; Mon, 8 Jul 2002 08:35:06 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.12.3/8.12.3) with ESMTP id g68FZDUU026903 for ; Mon, 8 Jul 2002 08:35:13 -0700 (PDT) Received: from dan.local.brotsky.com ([130.248.184.188]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GYXSQ600.RSV for ; Mon, 8 Jul 2002 08:37:18 -0700 Date: Mon, 8 Jul 2002 08:37:17 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: Dan Brotsky To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <95B10A66-9288-11D6-87FC-0003931036B4@adobe.com> X-Mailer: Apple Mail (2.482) Subject: Re: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6390 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Monday, July 8, 2002, at 04:24 AM, Julian Reschke wrote: > So do we have agreement that *any* of the URIs affected by a deep lock > can > be used to do the UNLOCK operation? Yes. (My earlier wording reflected a different confusion about the conversation Geoff and I were having. :^) dan From w3c-dist-auth-request@w3.org Mon Jul 8 11:49:52 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20778 for ; Mon, 8 Jul 2002 11:49:52 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA19029; Mon, 8 Jul 2002 11:46:27 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g68FkQT27333; Mon, 8 Jul 2002 11:46:26 -0400 (EDT) Resent-Date: Mon, 8 Jul 2002 11:46:26 -0400 (EDT) Resent-Message-Id: <200207081546.g68FkQT27333@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g68FkPw27313 for ; Mon, 8 Jul 2002 11:46:25 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA19008 for ; Mon, 8 Jul 2002 11:46:24 -0400 Received: (qmail 20346 invoked by uid 0); 8 Jul 2002 15:45:53 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp010-rz3) with SMTP; 8 Jul 2002 15:45:53 -0000 From: "Julian Reschke" To: "Dan Brotsky" , Date: Mon, 8 Jul 2002 17:45:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <95B10A66-9288-11D6-87FC-0003931036B4@adobe.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6391 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dan Brotsky > Sent: Monday, July 08, 2002 5:37 PM > To: w3c-dist-auth@w3c.org > Subject: Re: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER > > > > On Monday, July 8, 2002, at 04:24 AM, Julian Reschke wrote: > > So do we have agreement that *any* of the URIs affected by a deep lock > > can > > be used to do the UNLOCK operation? > > Yes. (My earlier wording reflected a different confusion about the > conversation Geoff and I were having. :^) In the meantime I can confirm that indeed this is what moddav and Xythos implement (IIS doesn't seem to support deep locks). From w3c-dist-auth-request@w3.org Mon Jul 8 12:36:34 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23606 for ; Mon, 8 Jul 2002 12:36:34 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA01222; Mon, 8 Jul 2002 12:35:45 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g68GZiD08301; Mon, 8 Jul 2002 12:35:44 -0400 (EDT) Resent-Date: Mon, 8 Jul 2002 12:35:44 -0400 (EDT) Resent-Message-Id: <200207081635.g68GZiD08301@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g68GZhw08278 for ; Mon, 8 Jul 2002 12:35:43 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA01215 for ; Mon, 8 Jul 2002 12:35:43 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Mon, 08 Jul 2002 12:34:58 -0400 (Eastern Daylight Time) Received: from ATL1VEXC006.usdom004.tco.tc ([10.158.7.208]) by atl1simr002.tco.tc with Microsoft SMTPSVC(5.0.2195.2966); Mon, 8 Jul 2002 12:34:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 8 Jul 2002 12:34:51 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA601736D841@ATL1VEXC006.usdom004.tco.tc> Thread-topic: New RFC2518bis draft thread-index: AcImlpfgR6oTaJkKRTi+fSGOmN9QfAABsX5w From: "Lisa Dusseault" To: "Dan Brotsky" , X-OriginalArrivalTime: 08 Jul 2002 16:34:51.0684 (UTC) FILETIME=[6211A640:01C2269D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g68GZhw08278 Subject: RE: New RFC2518bis draft Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6392 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Thanks for the feedback! I will change RFC2518bis so that it no longer deprecates allprop, just redefines it. lisa > -----Original Message----- > From: Dan Brotsky [mailto:dbrotsky@adobe.com] > Sent: Monday, July 08, 2002 8:36 AM > To: w3c-dist-auth@w3c.org > Subject: Re: New RFC2518bis draft > > > On Saturday, July 6, 2002, at 04:33 PM, Clemm, Geoff wrote: > > > Lisa: I noticed that you did not respond to Julian's concern > > about deprecating DAV:allprop. Does this mean that you agree with > > his proposal to have it mean "2518 properties and all dead properties"? > > Note that I am happy to have DAV:allprop be given this interpretation. > > > > Cheers, > > Geoff > > I am also happy with changing DAV:allprop to be given this > interpretation. I also do NOT want deprecation done of DAV:allprop. I > think this can be a simple clarification without damaging existing > client interoperability (given the existing actual behavior of servers) > or introducing confusion for new ones. > > dan From w3c-dist-auth-request@w3.org Mon Jul 8 12:44:57 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24043 for ; Mon, 8 Jul 2002 12:44:57 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA03281; Mon, 8 Jul 2002 12:44:13 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g68GiC809444; Mon, 8 Jul 2002 12:44:12 -0400 (EDT) Resent-Date: Mon, 8 Jul 2002 12:44:12 -0400 (EDT) Resent-Message-Id: <200207081644.g68GiC809444@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g68GiCw09424 for ; Mon, 8 Jul 2002 12:44:12 -0400 (EDT) Received: from smtp-relay-3.sea.adobe.com (smtp-relay-3.adobe.com [192.150.22.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA03263 for ; Mon, 8 Jul 2002 12:44:11 -0400 Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-3.sea.adobe.com (8.12.3/8.12.3) with ESMTP id g68Ggmh4022875 for ; Mon, 8 Jul 2002 09:42:48 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-3.corp.adobe.com (8.12.3/8.12.3) with ESMTP id g68GeaQG018315 for ; Mon, 8 Jul 2002 09:40:36 -0700 (PDT) Received: from dan.local.brotsky.com ([130.248.184.198]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GYXVSR00.1W1 for ; Mon, 8 Jul 2002 09:43:39 -0700 Date: Mon, 8 Jul 2002 09:43:40 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: Dan Brotsky To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 7bit In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1075FD41F@SUS-MA1IT01> Message-Id: X-Mailer: Apple Mail (2.482) Subject: Re: New RFC2518bis draft Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6393 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Just for clarity, given the timing of various responses: I'm squarely with Geoff and Julian on this one: we should redefine (well, clarify) DAV:ALLPROP as Julian suggests and not do any deprecation. dan On Sunday, July 7, 2002, at 05:00 PM, Clemm, Geoff wrote: > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > >> From: Lisa Dusseault >> >> The proposed text in 2518 bis does deprecate allprop as well as > redefine >> it to a certain extent. If 'allprop' is redefined, without being > renamed >> or deprecated, it will cause confusion for new implementors. Here are >> some of the options: >> 1) Deprecate. >> 2) Redefine and leave in place. Disadvantage: confusion to new >> implementers who will be misled by the apparent meaning of 'allprop' >> into misunderstanding what it does. > > Advantage: this is the current situation with RFC3253 and the ACL > spec, and this doesn't seem to cause any confusion at all. All we > need is to clarify RFC2518. > > I agree that the name "allprop" will be a bit confusing. But that's > something that can be solved by properly explaining it, right? > > I agree. I have little concern over any confusion resulting from the > name "DAV:allprop". The concept of "all dead properties plus 2518 > defined properties" is very simple, and should be easy to convey. And > even if an implementor gets it wrong and returns some (or all) > non-2518 live properties as well, little or no harm is done. > >> 3) Rename and redefine (e.g. 'deadprop', defined to return all >> the dead properties). Disadvantage: servers that were previously >> compliant with 2518 will not be compliant with 2518bis. > > I think this disadvantage significantly outweighs the minor benefits > of a slightly better name for this concept. > >> No functionality is lost by deprecating allprop - clients can always > use >> the 'propname' request to find all the dead and live property names, > and >> select among those. > > Yes, but at greatly increased cost, both in number of roundtrips, > client > complexity and computation time in the server. I've explained this in > auth/2002JanMar/0186.html>: > > I agree that it is valuable to have a simple mechanism for retrieving > all dead properties in one request (especially for a non-zero Depth > PROPFIND), and I agree that using DAV:allprop is the most interoperable > mechanism for providing this mechanism. > > Cheers, > Geoff > From w3c-dist-auth-request@w3.org Mon Jul 8 13:16:57 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26008 for ; Mon, 8 Jul 2002 13:16:57 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA10368; Mon, 8 Jul 2002 13:16:23 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g68HGMC14916; Mon, 8 Jul 2002 13:16:22 -0400 (EDT) Resent-Date: Mon, 8 Jul 2002 13:16:22 -0400 (EDT) Resent-Message-Id: <200207081716.g68HGMC14916@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g68HGLw14870 for ; Mon, 8 Jul 2002 13:16:21 -0400 (EDT) Received: from passwall.com (passwall.com [208.201.231.120]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA10356 for ; Mon, 8 Jul 2002 13:16:20 -0400 Received: (qmail 31648 invoked from network); 8 Jul 2002 17:32:28 -0000 Received: from nerds.intra.passwall.com (HELO nerds.passwall.com) (172.16.0.1) by ns1.intra.passwall.com with SMTP; 8 Jul 2002 17:32:28 -0000 Date: Mon, 8 Jul 2002 10:12:50 -0700 (PDT) From: ME Reply-To: ME To: Lisa Dusseault cc: w3c-dist-auth@w3.org In-Reply-To: <27889B08CAEC7049B68FAD8717BA6017371BA0@ATL1VEXC006.usdom004.tco.tc> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: Tx of text type docs and CR/LF, CR, LF translation Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6394 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Wed, 3 Jul 2002, Lisa Dusseault wrote: > The problem you describe is not particularly a WebDAV problem. IMAP and > FTP are subject to the same problems. MIME also does not attempt to fix > the problem. FTP allows for use of ASCII (A) mode transfers as well as binary/image (I), and as for MIME attached docs to e-mail messages, CR/LF and line termination for text files is done by most modern mail clients to allow the user of the local OS to view their text/* files in their local OS's line termination format. (I know this means some mail clients do not follow the RFC for mail, but they offer the user something they want and are able to use.) > The HTTP 1.1 specification does make some attempt to improve the > situation, and it works *when viewing in the browser*. It's not clear > how browsers should save files though. The browser could: > - save the file the same way it was downloaded > - save the transformed file, replacing single CR or LF with CRLF > > Either approach leads to problems. The current common approach, where > the browser saves the file the way it was downloaded, means the file may > be unusable when viewed in various text editors. However, if the > browser transforms the file, it may be altering the file > inappropriately. The transformation assumes that wherever CR or LF is > used CRLF is appropriate, and that may not be true for all uses of > 'text/plain'. > > I see why you wish attention to be brought to this subject, but the real > offenders are not WebDAV clients. It's applications like NotePad that > can't display reasonable file formats that are problematic. Those > implementers are unlikely to read this list or the WebDAV specification. I can understand this side and point of view, and see it would be easier to not enforce client side conversion for local OS line break format with text files. Inclusion of an OS specific line break as a requirement ties "OS" to the RFC, and can make it less employable in unforseen environments. Users who happen to use WebDAV to move CGI files or perl scripts and edit with a text editor that does not understand multi-OS line break formats will wonder why the script stops working on the web server, but they will need to be told it is not WebDAV, but the editor that came with their OS. They can download and use BBEdit for MacOS 9.x and earlier or the new one with MacOSX, etc. > You might try reporting this behavior as a bug to the manufacturers of > the offending software. Alas, there are at least 30 different text based editors for various OS that recognize the local OS line break formats exclusively, though many are used by few, outdated, no longer available, and not open source. However, there are about 4 major WebDAV clients out there in production where a modification from server formatted line breaks to local OS line breaks with little modification to code required. I chose to try the least-work path and have it addressed here. Based on the responses in this list, I can see enough support exists against this line break feature being incorporated into the WebDAV RFC that I don't feel any need to push it. Insetad, I have found a way to make my web server provide on-the-fly line break conversion of files pushed through WebDAV such that each client gets their local OS's line breaks for specific text/* files and then upon being returned to the server get converted to the Server's expected line break format. This works for my users, and only applies to the WebDAV work. If WebDAV clients should ever add this as a local feature, the "fix" (hack) allows for addresing client specific information to determine how the conversion should work - if at all. Thanks for your time in reading the original request, WebDAV is still much, much better than other file transfer protocols for the needs of my web users. -ME -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++ L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z? ------END GEEK CODE BLOCK------ decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html From w3c-dist-auth-request@w3.org Mon Jul 8 14:30:59 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00293 for ; Mon, 8 Jul 2002 14:30:59 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA25000; Mon, 8 Jul 2002 14:30:18 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g68IUHH26339; Mon, 8 Jul 2002 14:30:17 -0400 (EDT) Resent-Date: Mon, 8 Jul 2002 14:30:17 -0400 (EDT) Resent-Message-Id: <200207081830.g68IUHH26339@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g68IUGw26319 for ; Mon, 8 Jul 2002 14:30:16 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA24995 for ; Mon, 8 Jul 2002 14:30:16 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g68ITig5045814; Mon, 8 Jul 2002 14:29:44 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g68ITgW116040; Mon, 8 Jul 2002 14:29:42 -0400 To: "Julian Reschke" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Mon, 8 Jul 2002 14:28:34 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_06262002 Pre-release 2|June 26, 2002) at 07/08/2002 14:29:41 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE163DFF6DC3C8f9e8a93df938690918c0ABBE163DFF6DC3C" Content-Disposition: inline Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6395 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE163DFF6DC3C8f9e8a93df938690918c0ABBE163DFF6DC3C Content-type: text/plain; charset=US-ASCII > So do we have agreement that *any* of the URIs affected by a deep lock can > be used to do the UNLOCK operation? Fine with me. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com --0__=0ABBE163DFF6DC3C8f9e8a93df938690918c0ABBE163DFF6DC3C Content-type: text/html; charset=US-ASCII Content-Disposition: inline

> So do we have agreement that *any* of the URIs affected by a deep lock can
> be used to do the UNLOCK operation?

Fine with me.

------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com
--0__=0ABBE163DFF6DC3C8f9e8a93df938690918c0ABBE163DFF6DC3C-- From w3c-dist-auth-request@w3.org Mon Jul 8 15:32:30 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04583 for ; Mon, 8 Jul 2002 15:32:30 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA06959; Mon, 8 Jul 2002 15:31:17 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g68JV1B05383; Mon, 8 Jul 2002 15:31:01 -0400 (EDT) Resent-Date: Mon, 8 Jul 2002 15:31:01 -0400 (EDT) Resent-Message-Id: <200207081931.g68JV1B05383@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g68JV0w05361 for ; Mon, 8 Jul 2002 15:31:00 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA06791 for ; Mon, 8 Jul 2002 15:31:00 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.192.94]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g68JUHg5033536; Mon, 8 Jul 2002 15:30:19 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by westrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g68JTPf43300; Mon, 8 Jul 2002 13:29:25 -0600 To: "Clemm, Geoff" Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Mon, 8 Jul 2002 15:22:58 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_06262002 Pre-release 2|June 26, 2002) at 07/08/2002 15:30:13 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE163DFF9BBCD8f9e8a93df938690918c0ABBE163DFF9BBCD" Content-Disposition: inline Subject: RE: New RFC2518bis draft, MOVE vs COPY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6397 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE163DFF9BBCD8f9e8a93df938690918c0ABBE163DFF9BBCD Content-type: text/plain; charset=US-ASCII Just giving this one a new subject line to distinguish it from the discussion that spun off and is probably concluding... ------------------------------------------------------------------------------------------------------------------- From: Geoff Clemm [mailto:gclemm@rational.com] From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Lisa Dusseault > Section 4.5: Propertybehavior (in MOVE, COPY) removed Maybe MOVE and COPY need to be treated differently. If a server can't move a resource with it's live properties staying alive, I'd claim that it actually can't move the resource at all, and thus MOVE should fail (requiring the client to fall back to COPY/DELETE). Opinions? I agree that MOVE and COPY need to be treated differently, and I further agree that MOVE should fail if live properties cannot be maintained (requiring the client to fall back to COPY/DELETE). --0__=0ABBE163DFF9BBCD8f9e8a93df938690918c0ABBE163DFF9BBCD Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Just giving this one a new subject line to distinguish it from the discussion that spun off and
is probably concluding...

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

From: Geoff Clemm [mailto:gclemm@rational.com]

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

> From: Lisa Dusseault

> Section 4.5: Propertybehavior (in MOVE, COPY) removed

Maybe MOVE and COPY need to be treated differently. If a server
can't move a resource with it's live properties staying alive, I'd
claim that it actually can't move the resource at all, and thus
MOVE should fail (requiring the client to fall back to
COPY/DELETE).

Opinions?

I agree that MOVE and COPY need to be treated differently, and I
further agree that MOVE should fail if live properties cannot be
maintained (requiring the client to fall back to COPY/DELETE).

--0__=0ABBE163DFF9BBCD8f9e8a93df938690918c0ABBE163DFF9BBCD-- From w3c-dist-auth-request@w3.org Mon Jul 8 15:32:38 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04597 for ; Mon, 8 Jul 2002 15:32:38 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA06961; Mon, 8 Jul 2002 15:31:17 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g68JUSZ05341; Mon, 8 Jul 2002 15:30:28 -0400 (EDT) Resent-Date: Mon, 8 Jul 2002 15:30:28 -0400 (EDT) Resent-Message-Id: <200207081930.g68JUSZ05341@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g68JURw05321 for ; Mon, 8 Jul 2002 15:30:27 -0400 (EDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA06700 for ; Mon, 8 Jul 2002 15:30:25 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.192.94]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g68JUH4J024158; Mon, 8 Jul 2002 15:30:17 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by westrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g68JTNf43296; Mon, 8 Jul 2002 13:29:23 -0600 To: "Julian Reschke" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Mon, 8 Jul 2002 15:10:17 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_06262002 Pre-release 2|June 26, 2002) at 07/08/2002 15:30:12 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBE163DFFBE4658f9e8a93df938690918c0ABBE163DFFBE465" Subject: Issue: UNLOCK_WHAT_URL Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6396 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE163DFFBE4658f9e8a93df938690918c0ABBE163DFFBE465 Content-type: multipart/alternative; Boundary="1__=0ABBE163DFFBE4658f9e8a93df938690918c0ABBE163DFFBE465" --1__=0ABBE163DFFBE4658f9e8a93df938690918c0ABBE163DFFBE465 Content-type: text/plain; charset=US-ASCII I've changed the issue name to the one on the issue list that seems more appropriate. See new Subject: line. > So do we have agreement that *any* of the URIs affected by a deep lock can > be used to do the UNLOCK operation? The other question of that issue is... do we agree that if you request an UNLOCK on a resource that is not locked by that lock, that the request should fail? I believe in previous discussions it was suggested that we should not allow one to specify a URL other than one that is locked by the lock. The reasoning was that in a virtual website where the URI space might be partitioned and delegated across several machines (perhaps using intermachine BIND requests), it might be burdensome for all machines of the virtual website to be familiar with all locks. Anyway, regardless of folks believing this, I'd like to confirm that UNLOCK requests specifying a request URI of an unlocked resource should be rejected. Opinions? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com "Julian Reschke" reschke@gmx.de> cc: Sent by: w3c- Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER dist-auth- request@w3.org 07/08/2002 07:24 AM > To: Daniel Brotsky > Cc: "Clemm, Geoff" , w3c-dist-auth@w3c.org > Message-ID: > From: "Jason Crawford" > Date: Mon, 14 Jan 2002 15:19:50 -0500 > Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER > > > > In addition to Geoff's answer: > > If you are an administrator trying to unlock a resource obtained by > > someone else, you have to be able to figure out which resource to > > unlock. You can't unlock an internal member of a collection that's > > locked by a depth-inifinity lock without knowing which collection was > > actually locked. > > CAN'T? (going back to an old discussion...) RFC2518, 8.11 says [1]: "The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header from the Request-URI, and all other resources included in the lock. If all resources which have been locked under the submitted lock token can not be unlocked then the UNLOCK request MUST fail. " So do we have agreement that *any* of the URIs affected by a deep lock can be used to do the UNLOCK operation? [1] --1__=0ABBE163DFFBE4658f9e8a93df938690918c0ABBE163DFFBE465 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I've changed the issue name to the one on the issue list that seems more appropriate. See new Subject: line.

> So do we have agreement that *any* of the URIs affected by a deep lock can
> be used to do the UNLOCK operation?


The other question of that issue is... do we agree that if you request an UNLOCK
on a resource that is not locked by that lock, that the request should fail?

I believe in previous discussions it was suggested that we should not allow one
to specify a URL other than one that is locked by the lock. The reasoning was
that in a virtual website where the URI space might be partitioned and delegated
across several machines (perhaps using intermachine BIND requests), it might be
burdensome for all machines of the virtual website to be familiar with all locks.

Anyway, regardless of folks believing this, I'd like to confirm that UNLOCK requests
specifying a request URI of an unlocked resource should be rejected.

Opinions?

J.


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

"Julian Reschke" <julian.reschke@gmx.de>




          "Julian Reschke" <julian.reschke@gmx.de>
          Sent by: w3c-dist-auth-request@w3.org

          07/08/2002 07:24 AM



To: <w3c-dist-auth@w3.org>
cc:
Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER



> To: Daniel Brotsky <dbrotsky@adobe.com>
> Cc: "Clemm, Geoff" <gclemm@Rational.Com>, w3c-dist-auth@w3c.org
> Message-ID: <OF7C4220CB.830F87EE-ON85256B41.006F0EFA@pok.ibm.com>
> From: "Jason Crawford" <ccjason@us.ibm.com>
> Date: Mon, 14 Jan 2002 15:19:50 -0500
> Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER
>
>
> > In addition to Geoff's answer:
> > If you are an administrator trying to unlock a resource obtained by
> > someone else, you have to be able to figure out which resource to
> > unlock. You can't unlock an internal member of a collection that's
> > locked by a depth-inifinity lock without knowing which collection was
> > actually locked.
>
> CAN'T?

(going back to an old discussion...)

RFC2518, 8.11 says [1]:

"The UNLOCK method removes the lock identified by the lock token in the
Lock-Token request header from the Request-URI, and all other resources
included in the lock. If all resources which have been locked under the
submitted lock token can not be unlocked then the UNLOCK request MUST fail.
"

So do we have agreement that *any* of the URIs affected by a deep lock can
be used to do the UNLOCK operation?


[1] <http://greenbytes.de/tech/webdav/rfc2518.html#METHOD_UNLOCK>



--1__=0ABBE163DFFBE4658f9e8a93df938690918c0ABBE163DFFBE465-- --0__=0ABBE163DFFBE4658f9e8a93df938690918c0ABBE163DFFBE465 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=0ABBE163DFFBE4658f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBE163DFFBE4658f9e8a93df938690918c0ABBE163DFFBE465 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=0ABBE163DFFBE4658f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE163DFFBE4658f9e8a93df938690918c0ABBE163DFFBE465 Content-type: image/gif; name="pic16244.gif" Content-Disposition: inline; filename="pic16244.gif" Content-ID: <30__=0ABBE163DFFBE4658f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=0ABBE163DFFBE4658f9e8a93df938690918c0ABBE163DFFBE465-- From w3c-dist-auth-request@w3.org Mon Jul 8 16:14:29 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06761 for ; Mon, 8 Jul 2002 16:14:29 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA13947; Mon, 8 Jul 2002 16:11:50 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g68KBmI08327; Mon, 8 Jul 2002 16:11:48 -0400 (EDT) Resent-Date: Mon, 8 Jul 2002 16:11:48 -0400 (EDT) Resent-Message-Id: <200207082011.g68KBmI08327@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g68KBlw08304 for ; Mon, 8 Jul 2002 16:11:47 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA13933 for ; Mon, 8 Jul 2002 16:11:47 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Mon, 08 Jul 2002 16:04:23 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 16:11:16 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B325@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Mon, 8 Jul 2002 16:11:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: UNLOCK_WHAT_URL Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6398 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree that an UNLOCK on a resource not locked by the specified lock token MUST fail. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Monday, July 08, 2002 3:10 PM To: Julian Reschke Cc: w3c-dist-auth@w3.org Subject: Issue: UNLOCK_WHAT_URL I've changed the issue name to the one on the issue list that seems more appropriate. See new Subject: line. > So do we have agreement that *any* of the URIs affected by a deep lock can > be used to do the UNLOCK operation? The other question of that issue is... do we agree that if you request an UNLOCK on a resource that is not locked by that lock, that the request should fail? I believe in previous discussions it was suggested that we should not allow one to specify a URL other than one that is locked by the lock. The reasoning was that in a virtual website where the URI space might be partitioned and delegated across several machines (perhaps using intermachine BIND requests), it might be burdensome for all machines of the virtual website to be familiar with all locks. Anyway, regardless of folks believing this, I'd like to confirm that UNLOCK requests specifying a request URI of an unlocked resource should be rejected. Opinions? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com "Julian Reschke" "Julian Reschke" Sent by: w3c-dist-auth-request@w3.org 07/08/2002 07:24 AM To: cc: Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER > To: Daniel Brotsky > Cc: "Clemm, Geoff" , w3c-dist-auth@w3c.org > Message-ID: > From: "Jason Crawford" > Date: Mon, 14 Jan 2002 15:19:50 -0500 > Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER > > > > In addition to Geoff's answer: > > If you are an administrator trying to unlock a resource obtained by > > someone else, you have to be able to figure out which resource to > > unlock. You can't unlock an internal member of a collection that's > > locked by a depth-inifinity lock without knowing which collection was > > actually locked. > > CAN'T? (going back to an old discussion...) RFC2518, 8.11 says [1]: "The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header from the Request-URI, and all other resources included in the lock. If all resources which have been locked under the submitted lock token can not be unlocked then the UNLOCK request MUST fail. " So do we have agreement that *any* of the URIs affected by a deep lock can be used to do the UNLOCK operation? [1] From w3c-dist-auth-request@w3.org Mon Jul 8 16:45:19 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07771 for ; Mon, 8 Jul 2002 16:45:19 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA21290; Mon, 8 Jul 2002 16:44:35 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g68KiYT13423; Mon, 8 Jul 2002 16:44:34 -0400 (EDT) Resent-Date: Mon, 8 Jul 2002 16:44:34 -0400 (EDT) Resent-Message-Id: <200207082044.g68KiYT13423@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g68KiXw13403 for ; Mon, 8 Jul 2002 16:44:33 -0400 (EDT) Received: from webweaving.org (IDENT:Chuck@adsl-66-124-87-42.dsl.snfc21.pacbell.net [66.124.87.42]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA21283 for ; Mon, 8 Jul 2002 16:44:32 -0400 Received: from dirkx (helo=localhost) by webweaving.org with local-esmtp (Exim 3.14 #1) id 17Rg9v-0006pj-00; Mon, 08 Jul 2002 21:35:03 +0000 Date: Mon, 8 Jul 2002 21:35:03 +0000 (GMT) From: Dirk-Willem van Gulik X-Sender: dirkx@router.ispra.webweaving.org To: "Clemm, Geoff" cc: w3c-dist-auth@w3.org In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8B325@SUS-MA1IT01> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: Issue: UNLOCK_WHAT_URL Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6399 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: y On Mon, 8 Jul 2002, Clemm, Geoff wrote: > > I agree that an UNLOCK on a resource not locked by the > specified lock token MUST fail. > > Cheers, > Geoff > > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Monday, July 08, 2002 3:10 PM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: Issue: UNLOCK_WHAT_URL > > > I've changed the issue name to the one on the issue list that seems more > appropriate. See new Subject: line. > > > So do we have agreement that *any* of the URIs affected by a deep lock can > > be used to do the UNLOCK operation? > > > The other question of that issue is... do we agree that if you request an > UNLOCK > on a resource that is not locked by that lock, that the request should fail? > > > I believe in previous discussions it was suggested that we should not allow > one > to specify a URL other than one that is locked by the lock. The reasoning > was > that in a virtual website where the URI space might be partitioned and > delegated > across several machines (perhaps using intermachine BIND requests), it might > be > burdensome for all machines of the virtual website to be familiar with all > locks. > > Anyway, regardless of folks believing this, I'd like to confirm that UNLOCK > requests > specifying a request URI of an unlocked resource should be rejected. > > Opinions? > > J. > > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > "Julian Reschke" > > > > > > "Julian Reschke" > Sent by: w3c-dist-auth-request@w3.org > 07/08/2002 07:24 AM > > To: > cc: > Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER > > > > > > To: Daniel Brotsky > > Cc: "Clemm, Geoff" , w3c-dist-auth@w3c.org > > Message-ID: > > From: "Jason Crawford" > > Date: Mon, 14 Jan 2002 15:19:50 -0500 > > Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER > > > > > > > In addition to Geoff's answer: > > > If you are an administrator trying to unlock a resource obtained by > > > someone else, you have to be able to figure out which resource to > > > unlock. You can't unlock an internal member of a collection that's > > > locked by a depth-inifinity lock without knowing which collection was > > > actually locked. > > > > CAN'T? > > (going back to an old discussion...) > > RFC2518, 8.11 says [1]: > > "The UNLOCK method removes the lock identified by the lock token in the > Lock-Token request header from the Request-URI, and all other resources > included in the lock. If all resources which have been locked under the > submitted lock token can not be unlocked then the UNLOCK request MUST fail. > " > > So do we have agreement that *any* of the URIs affected by a deep lock can > be used to do the UNLOCK operation? > > > [1] > > From w3c-dist-auth-request@w3.org Mon Jul 8 17:01:38 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09784 for ; Mon, 8 Jul 2002 17:01:37 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA23925; Mon, 8 Jul 2002 17:00:10 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g68L0AC14310; Mon, 8 Jul 2002 17:00:10 -0400 (EDT) Resent-Date: Mon, 8 Jul 2002 17:00:10 -0400 (EDT) Resent-Message-Id: <200207082100.g68L0AC14310@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g68L09w14290 for ; Mon, 8 Jul 2002 17:00:09 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA23913 for ; Mon, 8 Jul 2002 17:00:09 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Mon, 08 Jul 2002 16:59:35 -0400 (Eastern Daylight Time) Received: from ATL1VEXC006.usdom004.tco.tc ([209.225.56.58]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 8 Jul 2002 16:59:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C226C2.4A261105" Date: Mon, 8 Jul 2002 16:59:02 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA601736D843@ATL1VEXC006.usdom004.tco.tc> Thread-topic: Issue: UNLOCK_WHAT_URL thread-index: AcImt1SDrbagJhxSSF+vI+P+8LbcnwACrhlw From: "Lisa Dusseault" To: "Jason Crawford" Cc: X-OriginalArrivalTime: 08 Jul 2002 20:59:35.0129 (UTC) FILETIME=[5D570490:01C226C2] Subject: RE: Issue: UNLOCK_WHAT_URL Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6400 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C226C2.4A261105 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C226C2.4A261105" ------_=_NextPart_002_01C226C2.4A261105 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That was the assumption I had made too.. the sentence so far reads =20 "Any locked resource may be addressed by UNLOCK, not just the resource that the LOCK method applied to. " =20 Lisa =20 -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com]=20 Sent: Monday, July 08, 2002 12:10 PM To: Julian Reschke Cc: w3c-dist-auth@w3.org Subject: Issue: UNLOCK_WHAT_URL =20 I've changed the issue name to the one on the issue list that seems more appropriate. See new Subject: line. > So do we have agreement that *any* of the URIs affected by a deep lock can > be used to do the UNLOCK operation? The other question of that issue is... do we agree that if you request an UNLOCK on a resource that is not locked by that lock, that the request should fail?=20 I believe in previous discussions it was suggested that we should not allow one to specify a URL other than one that is locked by the lock. The reasoning was that in a virtual website where the URI space might be partitioned and delegated=20 across several machines (perhaps using intermachine BIND requests), it might be=20 burdensome for all machines of the virtual website to be familiar with all locks. Anyway, regardless of folks believing this, I'd like to confirm that UNLOCK requests specifying a request URI of an unlocked resource should be rejected. Opinions? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com "Julian Reschke" =20 =20 "Julian Reschke" Sent by: w3c-dist-auth-request@w3.org=20 07/08/2002 07:24 AM =20 To: cc:=20 Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER > To: Daniel Brotsky > Cc: "Clemm, Geoff" , w3c-dist-auth@w3c.org > Message-ID: > From: "Jason Crawford" > Date: Mon, 14 Jan 2002 15:19:50 -0500 > Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER > > > > In addition to Geoff's answer: > > If you are an administrator trying to unlock a resource obtained by > > someone else, you have to be able to figure out which resource to > > unlock. You can't unlock an internal member of a collection that's > > locked by a depth-inifinity lock without knowing which collection was > > actually locked. > > CAN'T? (going back to an old discussion...) RFC2518, 8.11 says [1]: "The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header from the Request-URI, and all other resources included in the lock. If all resources which have been locked under the submitted lock token can not be unlocked then the UNLOCK request MUST fail. " So do we have agreement that *any* of the URIs affected by a deep lock can be used to do the UNLOCK operation? [1] ------_=_NextPart_002_01C226C2.4A261105 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That was the assumption I had made = too.. the sentence so far reads

 

“Any locked resource may be addressed by UNLOCK, not just the resource that = the LOCK method applied to.  “

 

Lisa

 

-----Original Message-----
From: Jason Crawford [mailto:ccjason@us.ibm.com]
Sent: Monday, July 08, 2002 12:10 = PM
To: Julian Reschke
Cc: = w3c-dist-auth@w3.org
Subject: Issue: = UNLOCK_WHAT_URL

 

I've changed the issue name to the one on the = issue list that seems more appropriate. See new Subject: line.

> So do we have agreement that *any* of the URIs affected by a deep lock = can
> be used to do the UNLOCK operation?


The = other question of that issue is... do we agree that if you request an = UNLOCK
on = a resource that is not locked by that lock, that the request should fail? =

I = believe in previous discussions it was suggested that we should not allow = one
to = specify a URL other than one that is locked by the lock. The reasoning = was
that in a virtual website where the URI space might be partitioned and delegated =
across several machines (perhaps using intermachine BIND requests), it might be =
burdensome for all machines of the virtual website to be familiar with all = locks.

Anyway, regardless of folks believing this, I'd like to confirm that UNLOCK = requests
specifying a request URI of an unlocked resource should be = rejected.

Opinions?

J.


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

"Julian Reschke" <julian.reschke@gmx.de>

"Julian Reschke" <julian.reschke@gmx.de>
Sent by: w3c-dist-auth-request@w3.org

07/08/2002 07:24 AM



To: <w3c-dist-auth@w3.org>
cc:
Subject: RE: root of a = lock, was HOW_TO_IDENTIFY_LOCK_OWNER



> To: Daniel Brotsky <dbrotsky@adobe.com>
> Cc: "Clemm, Geoff" <gclemm@Rational.Com>, w3c-dist-auth@w3c.org
> Message-ID: = <OF7C4220CB.830F87EE-ON85256B41.006F0EFA@pok.ibm.com>
> From: "Jason Crawford" <ccjason@us.ibm.com>
> Date: Mon, 14 Jan 2002 15:19:50 = -0500
> Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER
>
>
> > In addition to Geoff's answer:
> > If you are an administrator trying to unlock a resource = obtained by
> > someone else, you have to be able to figure out which resource = to
> > unlock. You can't unlock an internal member of a collection = that's
> > locked by a depth-inifinity lock without knowing which = collection was
> > actually locked.
>
> CAN'T?

(going back to an old discussion...)

RFC2518, 8.11 says [1]:

"The UNLOCK method removes the lock identified by the lock token in = the
Lock-Token request header from the Request-URI, and all other = resources
included in the lock. If all resources which have been locked under = the
submitted lock token can not be unlocked then the UNLOCK request MUST = fail.
"

So do we have agreement that *any* of the URIs affected by a deep lock = can
be used to do the UNLOCK operation?


[1] <http= ://greenbytes.de/tech/webdav/rfc2518.html#METHOD_UNLOCK>


=00 ------_=_NextPart_002_01C226C2.4A261105-- --------------InterScan_NT_MIME_Boundary Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --------------InterScan_NT_MIME_Boundary Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif Content-Transfer-Encoding: base64 R0lGODlhSAABAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAAAB AAEAgAAAAAECAwICRAEAOw== --------------InterScan_NT_MIME_Boundary Content-Type: image/gif; name="image003.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.gif Content-Location: image003.gif Content-Transfer-Encoding: base64 R0lGODlh4QABAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAAAB AAEAgAAAAAECAwICRAEAOw== --------------InterScan_NT_MIME_Boundary Content-Type: image/gif; name="image004.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image004.gif Content-Location: image004.gif Content-Transfer-Encoding: base64 R0lGODlhAQABAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAAAB AAEAgAAAAAECAwICRAEAOw== --------------InterScan_NT_MIME_Boundary-- --------------InterScan_NT_MIME_Boundary-- ------_=_NextPart_001_01C226C2.4A261105-- From w3c-dist-auth-request@w3.org Mon Jul 8 17:17:48 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10734 for ; Mon, 8 Jul 2002 17:17:48 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA28952; Mon, 8 Jul 2002 17:17:16 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g68LHFk16720; Mon, 8 Jul 2002 17:17:15 -0400 (EDT) Resent-Date: Mon, 8 Jul 2002 17:17:15 -0400 (EDT) Resent-Message-Id: <200207082117.g68LHFk16720@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g68LHEw16700 for ; Mon, 8 Jul 2002 17:17:14 -0400 (EDT) Received: from smtp-relay-1.adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA28932 for ; Mon, 8 Jul 2002 17:17:14 -0400 Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-1.adobe.com (8.12.3/8.12.3) with ESMTP id g68LInLw008378 for ; Mon, 8 Jul 2002 14:18:49 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-1.corp.adobe.com (8.12.3/8.12.3) with ESMTP id g68LHCuE009294 for ; Mon, 8 Jul 2002 14:17:12 -0700 (PDT) Received: from dan.local.brotsky.com ([130.248.184.198]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GYY8FQ00.3KG for ; Mon, 8 Jul 2002 14:16:38 -0700 Date: Mon, 8 Jul 2002 14:16:37 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: Dan Brotsky To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.482) Subject: Re: Issue: UNLOCK_WHAT_URL Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6401 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree they should be rejected, but I thought there was some question of what the error should be. dan On Monday, July 8, 2002, at 12:10 PM, Jason Crawford wrote: > I've changed the issue name to the one on the issue list that seems > more appropriate. See new Subject: line. > > > So do we have agreement that *any* of the URIs affected by a deep > lock can > > be used to do the UNLOCK operation? > > > The other question of that issue is... do we agree that if you request > an UNLOCK > on a resource that is not locked by that lock, that the request should > fail? > > I believe in previous discussions it was suggested that we should not > allow one > to specify a URL other than one that is locked by the lock. The > reasoning was > that in a virtual website where the URI space might be partitioned and > delegated > across several machines (perhaps using intermachine BIND requests), it > might be > burdensome for all machines of the virtual website to be familiar with > all locks. > > Anyway, regardless of folks believing this, I'd like to confirm that > UNLOCK requests > specifying a request URI of an unlocked resource should be rejected. > > Opinions? > > J. > > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > "Julian Reschke" > > > > > > > To: Daniel Brotsky > > Cc: "Clemm, Geoff" , w3c-dist-auth@w3c.org > > Message-ID: > > From: "Jason Crawford" > > Date: Mon, 14 Jan 2002 15:19:50 -0500 > > Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER > > > > > > > In addition to Geoff's answer: > > > If you are an administrator trying to unlock a resource obtained by > > > someone else, you have to be able to figure out which resource to > > > unlock. You can't unlock an internal member of a collection that's > > > locked by a depth-inifinity lock without knowing which collection > was > > > actually locked. > > > > CAN'T? > > (going back to an old discussion...) > > RFC2518, 8.11 says [1]: > > "The UNLOCK method removes the lock identified by the lock token in the > Lock-Token request header from the Request-URI, and all other resources > included in the lock. If all resources which have been locked under the > submitted lock token can not be unlocked then the UNLOCK request MUST > fail. > " > > So do we have agreement that *any* of the URIs affected by a deep lock > can > be used to do the UNLOCK operation? > > > [1] > > > From w3c-dist-auth-request@w3.org Mon Jul 8 18:53:26 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15578 for ; Mon, 8 Jul 2002 18:53:25 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA15536; Mon, 8 Jul 2002 18:52:41 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g68MqUa00339; Mon, 8 Jul 2002 18:52:30 -0400 (EDT) Resent-Date: Mon, 8 Jul 2002 18:52:30 -0400 (EDT) Resent-Message-Id: <200207082252.g68MqUa00339@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g68MqTw00313 for ; Mon, 8 Jul 2002 18:52:29 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA15458 for ; Mon, 8 Jul 2002 18:52:29 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g68Mpqe8127172; Mon, 8 Jul 2002 18:51:52 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g68Mpol46604; Mon, 8 Jul 2002 18:51:50 -0400 To: Dan Brotsky Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Mon, 8 Jul 2002 18:36:36 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_06262002 Pre-release 2|June 26, 2002) at 07/08/2002 18:51:49 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE163DFE87EC18f9e8a93df938690918c0ABBE163DFE87EC1" Content-Disposition: inline Subject: Re: Issue: UNLOCK_WHAT_URL Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6402 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE163DFE87EC18f9e8a93df938690918c0ABBE163DFE87EC1 Content-type: text/plain; charset=US-ASCII > I agree they should be rejected, We appear to have a consensus. > but I thought there was some question > of what the error should be. Right you are. So the final question is, what error code should we return if a client submits an UNLOCK request with a request URL for a resource that isn't locked by the specified lock? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com --0__=0ABBE163DFE87EC18f9e8a93df938690918c0ABBE163DFE87EC1 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

> I agree they should be rejected,

We appear to have a consensus.


> but I thought there was some question
> of what the error should be.

Right you are. So the final question is, what error code should we return if a client submits an UNLOCK request with a request URL for a resource that isn't locked by the specified lock?

------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com
--0__=0ABBE163DFE87EC18f9e8a93df938690918c0ABBE163DFE87EC1-- From w3c-dist-auth-request@w3.org Tue Jul 9 09:24:12 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24033 for ; Tue, 9 Jul 2002 09:24:12 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA32277; Tue, 9 Jul 2002 09:19:36 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g69DJZT25447; Tue, 9 Jul 2002 09:19:35 -0400 (EDT) Resent-Date: Tue, 9 Jul 2002 09:19:35 -0400 (EDT) Resent-Message-Id: <200207091319.g69DJZT25447@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g69DJYw25424 for ; Tue, 9 Jul 2002 09:19:34 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA32268 for ; Tue, 9 Jul 2002 09:19:34 -0400 Received: (qmail 11218 invoked by uid 0); 9 Jul 2002 13:19:24 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp011-rz3) with SMTP; 9 Jul 2002 13:19:24 -0000 From: "Julian Reschke" To: Date: Tue, 9 Jul 2002 15:19:24 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: response marshalling in RFC2518, section 8.10.10 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6404 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit (sorry, operator error) The example response is: http://webdav.sb.aol.com/webdav/secret HTTP/1.1 403 Forbidden http://webdav.sb.aol.com/webdav/ HTTP/1.1 424 Failed Dependency and the spec says furthermore: "In this example the lockdiscovery property is empty which means that there are no outstanding locks on the resource." What's the point in returning the DAV:lockdiscovery property if it will always be empty (otherwise a 200 would have been returned). And shouldn't the response better be: http://webdav.sb.aol.com/webdav/secret HTTP/1.1 403 Forbidden http://webdav.sb.aol.com/webdav/ HTTP/1.1 424 Failed Dependency ...because the error condition applies to the complete resource, not a specific property? [1] From w3c-dist-auth-request@w3.org Tue Jul 9 09:29:32 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24305 for ; Tue, 9 Jul 2002 09:29:32 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA31525; Tue, 9 Jul 2002 09:16:08 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g69DG6Z25092; Tue, 9 Jul 2002 09:16:06 -0400 (EDT) Resent-Date: Tue, 9 Jul 2002 09:16:06 -0400 (EDT) Resent-Message-Id: <200207091316.g69DG6Z25092@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g69DG5w25072 for ; Tue, 9 Jul 2002 09:16:05 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA31519 for ; Tue, 9 Jul 2002 09:16:04 -0400 Received: (qmail 29130 invoked by uid 0); 9 Jul 2002 13:15:33 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp003-rz3) with SMTP; 9 Jul 2002 13:15:33 -0000 From: "Julian Reschke" To: Date: Tue, 9 Jul 2002 15:15:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <27889B08CAEC7049B68FAD8717BA601736D843@ATL1VEXC006.usdom004.tco.tc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: response marshalling in RFC2518, section 8.10.10 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6403 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, the example response is: [1] From w3c-dist-auth-request@w3.org Tue Jul 9 14:13:54 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05877 for ; Tue, 9 Jul 2002 14:13:54 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA26467; Tue, 9 Jul 2002 14:13:26 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g69IDO513273; Tue, 9 Jul 2002 14:13:24 -0400 (EDT) Resent-Date: Tue, 9 Jul 2002 14:13:24 -0400 (EDT) Resent-Message-Id: <200207091813.g69IDO513273@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g69IDMw13251 for ; Tue, 9 Jul 2002 14:13:23 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA26450 for ; Tue, 9 Jul 2002 14:13:22 -0400 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g69IDLk20657 for ; Tue, 9 Jul 2002 11:13:21 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 9 Jul 2002 11:12:43 -0700 Received: from luthji.apple.com (luthji.apple.com [17.202.43.76]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g69IDLT06567 for ; Tue, 9 Jul 2002 11:13:21 -0700 (PDT) Date: Tue, 9 Jul 2002 11:13:19 -0700 Mime-Version: 1.0 (Apple Message framework v533) Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed From: Jim Luther To: w3c-dist-auth@w3.org Content-Transfer-Encoding: 7bit Message-Id: <8BE55024-9367-11D6-AE77-0003934B6A22@apple.com> X-Mailer: Apple Mail (2.533) Subject: A couple of issues Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6405 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I haven't seen this mentioned, but in section 9 it would be helpful to classify the new headers as general-header, response-header, or entity-header. Also, I want to make sure the trailing slash for collections issue (section 5.2) isn't forgotten. Julian suggested that it be added to the issues list in . - Jim From w3c-dist-auth-request@w3.org Tue Jul 9 15:39:39 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14609 for ; Tue, 9 Jul 2002 15:39:39 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA19242; Tue, 9 Jul 2002 15:39:08 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g69JcxE00588; Tue, 9 Jul 2002 15:38:59 -0400 (EDT) Resent-Date: Tue, 9 Jul 2002 15:38:59 -0400 (EDT) Resent-Message-Id: <200207091938.g69JcxE00588@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g69Jcww00568 for ; Tue, 9 Jul 2002 15:38:58 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA19198 for ; Tue, 9 Jul 2002 15:38:58 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g69JcJe8051758; Tue, 9 Jul 2002 15:38:20 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g69JcI634132; Tue, 9 Jul 2002 15:38:18 -0400 To: Jim Luther Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Tue, 9 Jul 2002 15:26:49 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_06262002 Pre-release 2|June 26, 2002) at 07/09/2002 15:38:17 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE162DFF955F78f9e8a93df938690918c0ABBE162DFF955F7" Content-Disposition: inline Subject: Re: A couple of issues Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6406 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE162DFF955F78f9e8a93df938690918c0ABBE162DFF955F7 Content-type: text/plain; charset=US-ASCII << I haven't seen this mentioned, but in section 9 it would be helpful to classify the new headers as general-header, response-header, or entity-header. >> Lisa, let me know if you need an issue added for this. << Also, I want to make sure the trailing slash for collections issue (section 5.2) isn't forgotten. Julian suggested that it be added to the issues list in . >> Wow. Right you are. I just added an issue for it: HOW_ARE_TRAILING_SLASHES_USED ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com --0__=0ABBE162DFF955F78f9e8a93df938690918c0ABBE162DFF955F7 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

<<
I haven't seen this mentioned, but in section 9 it would be helpful to
classify the new headers as general-header, response-header, or
entity-header.
>>
Lisa, let me know if you need an issue added for this.

<<
Also, I want to make sure the trailing slash for collections issue
(section 5.2) isn't forgotten. Julian suggested that it be added to the
issues list in
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0201.html>
.
>>
Wow. Right you are. I just added an issue for it: HOW_ARE_TRAILING_SLASHES_USED

------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com
--0__=0ABBE162DFF955F78f9e8a93df938690918c0ABBE162DFF955F7-- From w3c-dist-auth-request@w3.org Tue Jul 9 15:41:22 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14692 for ; Tue, 9 Jul 2002 15:41:22 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA19595; Tue, 9 Jul 2002 15:40:55 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g69JetY00742; Tue, 9 Jul 2002 15:40:55 -0400 (EDT) Resent-Date: Tue, 9 Jul 2002 15:40:55 -0400 (EDT) Resent-Message-Id: <200207091940.g69JetY00742@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g69Jesw00722 for ; Tue, 9 Jul 2002 15:40:54 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA19587 for ; Tue, 9 Jul 2002 15:40:54 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g69JeKi21502 for ; Tue, 9 Jul 2002 12:40:21 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 9 Jul 2002 12:38:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: character encoding. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6407 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Andy Rayne [mailto:andy.rayne@x-manage.de] Sent: Friday, July 05, 2002 3:52 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] character encoding. Hi, First how do i join the list, just came accross it. Second i have a java implementation of a webdav server running on resin (webserver). Resin allows one to specify character encoding in the conf file. However when used with other webservers or OS ( using windows just now) it isnt possible to set the character encoding. Therefore when my windows explorer client sends the encoded request the server doesnt recognise it and spits out a bad request 400. DO i now have to go and implement the character encoding too? Is this even the correct list to ask this question. Cheers Andy From w3c-dist-auth-request@w3.org Tue Jul 9 16:00:05 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15293 for ; Tue, 9 Jul 2002 16:00:04 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA23348; Tue, 9 Jul 2002 15:59:43 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g69JxgN02530; Tue, 9 Jul 2002 15:59:42 -0400 (EDT) Resent-Date: Tue, 9 Jul 2002 15:59:42 -0400 (EDT) Resent-Message-Id: <200207091959.g69JxgN02530@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g69Jxew02504 for ; Tue, 9 Jul 2002 15:59:40 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA23339 for ; Tue, 9 Jul 2002 15:59:40 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g69JwSg5052264; Tue, 9 Jul 2002 15:58:30 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g69JwQ608186; Tue, 9 Jul 2002 15:58:26 -0400 To: "Julian Reschke" Cc: "Lisa Dusseault" , w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Tue, 9 Jul 2002 15:56:42 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_06262002 Pre-release 2|June 26, 2002) at 07/09/2002 15:58:26 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE17EDF9FE8B18f9e8a93df938690918c0ABBE17EDF9FE8B1" Content-Disposition: inline Subject: RE: New RFC2518bis draft, MOVE vs COPY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6408 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE17EDF9FE8B18f9e8a93df938690918c0ABBE17EDF9FE8B1 Content-type: text/plain; charset=US-ASCII > Maybe MOVE and COPY need to be treated differently. If a server can't move a > resource with it's live properties staying alive, I'd claim that it actually > can't move the resource at all, and thus MOVE should fail (requiring the > client to fall back to COPY/DELETE). > > Opinions? I'd like to see us try this requirement for MOVE and see how much trouble folks have complying. I think it will require some coordination between resource authors and server writers to insure the authors concept of "resource" is supportable in server's implementation of MOVE. > > > 2) If we did, the wording "octet-by-octet" doesn't make sense (because > > > we're > > > talking of property values) > > You may be right. Do you have another suggestion? > Just remove it. "Duplicating" a property value is well-defined, as long as > the "property value" is well-defined (which we're trying to fix). I should then enhance the description of issue:COPY_LIVE_PROPS to make sure that's the case after we define the properties well. Hopefully we'll also define the default behavior of unknown dead properties clearly enough so that COPY/MOVE behavior is clear for them also. (PROP_ROUNDTRIP) ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com --0__=0ABBE17EDF9FE8B18f9e8a93df938690918c0ABBE17EDF9FE8B1 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

> Maybe MOVE and COPY need to be treated differently. If a server can't move a
> resource with it's live properties staying alive, I'd claim that it actually
> can't move the resource at all, and thus MOVE should fail (requiring the
> client to fall back to COPY/DELETE).
>
> Opinions?

I'd like to see us try this requirement for MOVE and see how much trouble
folks have complying. I think it will require some coordination between
resource authors and server writers to insure the authors concept of
"resource" is supportable in server's implementation of MOVE.



> > > 2) If we did, the wording "octet-by-octet" doesn't make sense (because
> > > we're
> > > talking of property values)
> > You may be right. Do you have another suggestion?

> Just remove it. "Duplicating" a property value is well-defined, as long as
> the "property value" is well-defined (which we're trying to fix).

I should then enhance the description of issue:COPY_LIVE_PROPS to make sure that's the case after we define the properties well. Hopefully we'll also define the default behavior of unknown dead properties clearly enough so that COPY/MOVE behavior is clear for them also. (PROP_ROUNDTRIP)


------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com
--0__=0ABBE17EDF9FE8B18f9e8a93df938690918c0ABBE17EDF9FE8B1-- From w3c-dist-auth-request@w3.org Wed Jul 10 03:39:45 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23846 for ; Wed, 10 Jul 2002 03:39:45 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA31456; Wed, 10 Jul 2002 03:39:21 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6A7dCp09729; Wed, 10 Jul 2002 03:39:12 -0400 (EDT) Resent-Date: Wed, 10 Jul 2002 03:39:12 -0400 (EDT) Resent-Message-Id: <200207100739.g6A7dCp09729@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6A7dBw09709 for ; Wed, 10 Jul 2002 03:39:11 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA31391 for ; Wed, 10 Jul 2002 03:39:10 -0400 Received: (qmail 22835 invoked by uid 0); 10 Jul 2002 07:38:38 -0000 Received: from p3ee24814.dip.t-dialin.net (HELO lisa) (62.226.72.20) by mail.gmx.net (mp011-rz3) with SMTP; 10 Jul 2002 07:38:38 -0000 From: "Julian Reschke" To: Date: Wed, 10 Jul 2002 09:38:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: discovering the root of a deep lock Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6409 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit (see also issue LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY) Proposed syntax: 12.1 activelock XML Element Name: activelock Namespace: DAV: Purpose: Describes a lock on a resource. 12.1.x lockroot XML Element Name: lockroot Namespace: DAV: Purpose: For locks with depth infinity, servers SHOULD report the root of the lock using the DAV:lockroot element. This enables clients to know the scope of resources affected by a subsequent UNLOCK with the given lock token. For lock with depth 0, the DAV:lockroot element MUST NOT be present. -- Note: I made it a "SHOULD" in order not to break existing implementations. From w3c-dist-auth-request@w3.org Wed Jul 10 03:42:31 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23928 for ; Wed, 10 Jul 2002 03:42:31 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA32388; Wed, 10 Jul 2002 03:43:10 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6A7h8O10470; Wed, 10 Jul 2002 03:43:08 -0400 (EDT) Resent-Date: Wed, 10 Jul 2002 03:43:08 -0400 (EDT) Resent-Message-Id: <200207100743.g6A7h8O10470@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6A7h6w10447 for ; Wed, 10 Jul 2002 03:43:07 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA32368 for ; Wed, 10 Jul 2002 03:43:06 -0400 Received: (qmail 32585 invoked by uid 0); 10 Jul 2002 07:42:35 -0000 Received: from p3ee24814.dip.t-dialin.net (HELO lisa) (62.226.72.20) by mail.gmx.net (mp007-rz3) with SMTP; 10 Jul 2002 07:42:35 -0000 From: "Julian Reschke" To: Date: Wed, 10 Jul 2002 09:42:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: New issue (?): locktoken (12.1.2) syntax Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6410 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, 12.1.2 ([1]) states: "Purpose: The lock token associated with a lock. Description: The href contains one or more opaque lock token URIs which all refer to the same lock (i.e., the OpaqueLockToken-URI production in section 6.4). " Question: why would multiple lock tokens refer to the same lock? And *if* there are multiple URIs referring to the same lock (a consequence of BINDs???), what's the point in reporting more than one? Is anybody using this? Has interoperability been tested? [1] From w3c-dist-auth-request@w3.org Wed Jul 10 09:22:36 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01636 for ; Wed, 10 Jul 2002 09:22:36 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA06293; Wed, 10 Jul 2002 09:22:45 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6ADMbv03869; Wed, 10 Jul 2002 09:22:37 -0400 (EDT) Resent-Date: Wed, 10 Jul 2002 09:22:37 -0400 (EDT) Resent-Message-Id: <200207101322.g6ADMbv03869@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6ADMaw03849 for ; Wed, 10 Jul 2002 09:22:36 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA06271 for ; Wed, 10 Jul 2002 09:22:36 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Wed, 10 Jul 2002 09:15:08 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Jul 2002 09:22:05 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B107761316@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Wed, 10 Jul 2002 09:22:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: discovering the root of a deep lock Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6411 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree that the lock discovery should report on the root of a depth lock. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Wednesday, July 10, 2002 3:39 AM To: w3c-dist-auth@w3.org Subject: discovering the root of a deep lock (see also issue LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY) Proposed syntax: 12.1 activelock XML Element Name: activelock Namespace: DAV: Purpose: Describes a lock on a resource. 12.1.x lockroot XML Element Name: lockroot Namespace: DAV: Purpose: For locks with depth infinity, servers SHOULD report the root of the lock using the DAV:lockroot element. This enables clients to know the scope of resources affected by a subsequent UNLOCK with the given lock token. For lock with depth 0, the DAV:lockroot element MUST NOT be present. -- Note: I made it a "SHOULD" in order not to break existing implementations. From w3c-dist-auth-request@w3.org Wed Jul 10 14:34:45 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14736 for ; Wed, 10 Jul 2002 14:34:44 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA29615; Wed, 10 Jul 2002 14:35:06 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6AIZ4500433; Wed, 10 Jul 2002 14:35:04 -0400 (EDT) Resent-Date: Wed, 10 Jul 2002 14:35:04 -0400 (EDT) Resent-Message-Id: <200207101835.g6AIZ4500433@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6AIZ2w00409 for ; Wed, 10 Jul 2002 14:35:02 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA29610 for ; Wed, 10 Jul 2002 14:35:02 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6AIYPe8091166; Wed, 10 Jul 2002 14:34:25 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g6AIYOp109030; Wed, 10 Jul 2002 14:34:24 -0400 To: "Clemm, Geoff" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Wed, 10 Jul 2002 14:31:44 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_06262002 Pre-release 2|June 26, 2002) at 07/10/2002 14:34:23 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE161DFF628B38f9e8a93df938690918c0ABBE161DFF628B3" Content-Disposition: inline Subject: RE: discovering the root of a deep lock Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6412 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE161DFF628B38f9e8a93df938690918c0ABBE161DFF628B3 Content-type: text/plain; charset=US-ASCII A dav:lockroot as proposed is fine with me. Do we have one more person that will endorse this? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com --0__=0ABBE161DFF628B38f9e8a93df938690918c0ABBE161DFF628B3 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

A dav:lockroot as proposed is fine with me. Do we have one more person that will endorse this?

------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com
--0__=0ABBE161DFF628B38f9e8a93df938690918c0ABBE161DFF628B3-- From w3c-dist-auth-request@w3.org Wed Jul 10 15:52:14 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17233 for ; Wed, 10 Jul 2002 15:52:14 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA16094; Wed, 10 Jul 2002 15:52:13 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6AJohe15797; Wed, 10 Jul 2002 15:50:43 -0400 (EDT) Resent-Date: Wed, 10 Jul 2002 15:50:43 -0400 (EDT) Resent-Message-Id: <200207101950.g6AJohe15797@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6AJogw15777 for ; Wed, 10 Jul 2002 15:50:42 -0400 (EDT) Received: from smtp-relay-2.adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA15757 for ; Wed, 10 Jul 2002 15:50:42 -0400 Received: from inner-relay-2.corp.adobe.com (inner-relay-2 [153.32.1.52]) by smtp-relay-2.adobe.com (8.12.3/8.12.3) with ESMTP id g6AJlqWd007336 for ; Wed, 10 Jul 2002 12:47:53 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.12.3/8.12.3) with ESMTP id g6AJm0UU027583 for ; Wed, 10 Jul 2002 12:48:01 -0700 (PDT) Received: from dan.local.brotsky.com ([153.32.165.185]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GZ1TRH00.1XK for ; Wed, 10 Jul 2002 12:50:05 -0700 Date: Wed, 10 Jul 2002 12:50:09 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: Dan Brotsky To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <3D66B02C-943E-11D6-9665-0003931036B4@adobe.com> X-Mailer: Apple Mail (2.482) Subject: Re: discovering the root of a deep lock Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6413 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I will endorse it as well. dan On Wednesday, July 10, 2002, at 11:31 AM, Jason Crawford wrote: > A dav:lockroot as proposed is fine with me. Do we have one more person > that will endorse this? > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > From w3c-dist-auth-request@w3.org Wed Jul 10 17:07:36 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19771 for ; Wed, 10 Jul 2002 17:07:36 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA02851; Wed, 10 Jul 2002 17:07:16 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6AL65I27223; Wed, 10 Jul 2002 17:06:05 -0400 (EDT) Resent-Date: Wed, 10 Jul 2002 17:06:05 -0400 (EDT) Resent-Message-Id: <200207102106.g6AL65I27223@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6AL5sw27198 for ; Wed, 10 Jul 2002 17:05:54 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA02611 for ; Wed, 10 Jul 2002 17:05:54 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 10 Jul 2002 17:05:20 -0400 (Eastern Daylight Time) Received: from ATL1VEXC006.usdom004.tco.tc ([209.225.56.58]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 10 Jul 2002 17:05:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Wed, 10 Jul 2002 17:05:20 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA6017371BAC@ATL1VEXC006.usdom004.tco.tc> Thread-topic: Agenda for WebDAV WG meeting, Yokohama thread-index: AcIoVX+FgOlaAr6AQGKGmdsNmbxNmg== From: "Lisa Dusseault" To: "Webdav WG" X-OriginalArrivalTime: 10 Jul 2002 21:05:20.0031 (UTC) FILETIME=[7FBE62F0:01C22855] Subject: Agenda for WebDAV WG meeting, Yokohama Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6414 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22855.7FBFB088" ------_=_NextPart_001_01C22855.7FBFB088 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 The WebDAV WG meets in Yokohama, Tuesday July 16, 9:00 am to 11:00 am. Jim won't be there unfortunately. =20 I plan to discuss mostly RFC2518bis issues. I will also cover interop plans and ACL progress, in greater or lesser detail depending on who's there and how much interest there is, unless somebody else shows up to discuss these items. So here's the rough agenda so far: =20 10 min agenda bashing 20 min Interop plans 20 min ACL progress (last call) 60 min RFC2518bis issues =20 Does anybody have other topics to discuss at the WG?=20 Lisa =20 =20 ------_=_NextPart_001_01C22855.7FBFB088 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

The WebDAV WG meets in Yokohama, Tuesday July 16, 9:00 am to 11:00 am. Jim won’t be there unfortunately.

 

I plan to discuss mostly RFC2518bis issues.  I = will also cover interop plans and ACL progress, in greater or lesser detail depending on who’s there and how much interest there is, unless = somebody else shows up to discuss these items.  So here’s the rough = agenda so far:

 

10 min agenda bashing

20 min Interop plans

20 min ACL progress (last call)

60 min RFC2518bis issues

 

Does anybody have other topics to discuss at the WG? =

Lisa

 

 

=00 ------_=_NextPart_001_01C22855.7FBFB088-- --------------InterScan_NT_MIME_Boundary-- From w3c-dist-auth-request@w3.org Wed Jul 10 19:09:37 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22894 for ; Wed, 10 Jul 2002 19:09:37 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA31658; Wed, 10 Jul 2002 19:08:11 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6AN6fd06535; Wed, 10 Jul 2002 19:06:41 -0400 (EDT) Resent-Date: Wed, 10 Jul 2002 19:06:41 -0400 (EDT) Resent-Message-Id: <200207102306.g6AN6fd06535@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6AN5Jw06274 for ; Wed, 10 Jul 2002 19:05:19 -0400 (EDT) Received: from smtp-relay-3.sea.adobe.com (smtp-relay-3.adobe.com [192.150.22.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA31124 for ; Wed, 10 Jul 2002 19:05:19 -0400 Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-3.sea.adobe.com (8.12.3/8.12.3) with ESMTP id g6AN3uYb023602 for ; Wed, 10 Jul 2002 16:03:56 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-3.corp.adobe.com (8.12.3/8.12.3) with ESMTP id g6AN1fQG003650 for ; Wed, 10 Jul 2002 16:01:42 -0700 (PDT) Received: from masinter ([153.32.67.37]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GZ22RZ00.SB8; Wed, 10 Jul 2002 16:04:47 -0700 From: "Larry Masinter" To: "'Stefan Eissing'" , "'Julian Reschke'" Cc: "'Lisa Dusseault'" , "'Webdav WG \(E-mail\)'" Date: Wed, 10 Jul 2002 16:05:32 -0700 Keywords: backed-up Message-ID: <007801c22866$4ae51ea0$25432099@masinter> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Subject: RE: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6415 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I would like to -- but am having trouble -- extracting from this discussion a set of requirements that a revised RFC 2396 URI specification would need to meet. What about the usage of the terms URI, URL and URN do you actually need? In what way does the definition of these terms affect the WebDAV specification? Most of the terminology is really just advisory. Another alternative would be to establish specific WebDAV terminology and then define that terminology in terms of the various URI RFCs. Stefan Eissing wrote on June 27: > As an addendum to this: there is work in progress on a new > version of RFC 2396, which should also include clarifications > about the usage of terms URI, URL and URN - among other things. > > I think Larry Masinter has taken the lead on this activity and > I would consider it prudent to align the wording of a future > 2518 with his findings. Maybe Larry can give us a hint at his > schedule? > > //Stefan > > Am Donnerstag den, 27. Juni 2002, um 00:42, schrieb Julian Reschke: > > > > > I think it is a good idea to delay this change. The whole terminology needs > > to be checked carefully if we update the draft to refer to RFC2396 rather > > than RFC2068 (because the *meaning* of the term "URI" changed between the > > two RFCs!). > > > > Some more comments inline. > > > >> - Change to refer to URL whenever we refer to the address of a collection > >> or resource. This replaces the definition of "Member URI" with "Member URL" > >> in the Terminology section, and replaces URI with URL in the definition of > >> that. Same with "Internal Member URI" to "Internal Member URL". Many other > >> instances of URI will be replaced with URL according to this new terminology > >> approach. E.g. throughout sections 5.2, 5.4, 7.5, 8.1, and 8.10.3 . > > > > When 5.4 refers to source URIs, it needs to continue to do so. Source > > resources may not be HTTP resources at all. > > > > 8.1: > > > > "Each response XML element MUST contain an href XML element that gives the > > URI of the resource on which the properties in the prop XML element are > > defined" > > > > needs to be fixed in that the DAV:href element must be defined to be a "URI > > reference to be resolved relative to the request URI" (1). If we require a > > URI (or URL), we wouldn't be allowed to return absolute URI references such > > as "/collection/resource" (this isn't syntactically a URL or URI). > > > > 8.10.3: don't agree - resources may have alternate URIs which do not happen > > to be URLs. > > > >> - Change the language to refer to what the Destination header contains as a > >> URL, not a URI. > >> > >> - Continue to refer to URI when discussing lock tokens. E.g. section 6.3, > >> 6.4 > >> > >> - Continue to refer to the "Request-URI" as that is the way the address in > >> the first line of a request is named. > >> > >> - Continue to refer to tokens in the IF header as URIs. > >> > >> - Continue to use URI in section 9.7, where the Status-URI response header > >> is defined to contain a URI. > > > > I think that's a section that we may have to remove anyway (issue: > > INTEROPERABILITY_OF_102PROCESSING_STATUS_DEMONSTRATED). > > > >> - Continue to define the element in section 12.3 as containing a > >> URI, because to do otherwise would change the specificaiton, not clarify it. > > > > Actually, this needs to be fixed. The definition should refer to RFC2396, > > and use the term "URI reference". > > > >> Likewise for , and elements. > >> > >> - Continue to define the property name as a URI in section 16. > > > > As mentioned before, properties do not have URIs (at least there's no > > one-to-one mapping unless we define it ourselves). The entire paragraph in > > section 16 needs to be removed or rewritten. > > > >> - Continue to use the term URI in IANA considerations, where the property > >> name and lock token URIs are discussed. > > > > Again -- needs to be fixed. > > > >> - Continue to use the term URL as in "HTTP URL Namespace" (e.g. section > >> 5.1). Continue using the term URL wherever it is used. > >> > >> I will not be able to get this done by the draft deadline (Monday) since I'm > >> taking a long weekend to celebrate Canada Day ;) But I'll gather the > >> feedback after that and incorporate it later. From w3c-dist-auth-request@w3.org Thu Jul 11 01:09:16 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00444 for ; Thu, 11 Jul 2002 01:09:15 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA22226; Thu, 11 Jul 2002 01:08:20 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6B576T09515; Thu, 11 Jul 2002 01:07:06 -0400 (EDT) Resent-Date: Thu, 11 Jul 2002 01:07:06 -0400 (EDT) Resent-Message-Id: <200207110507.g6B576T09515@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6B575w09495 for ; Thu, 11 Jul 2002 01:07:05 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA22069 for ; Thu, 11 Jul 2002 01:07:05 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6B56Xg5211382; Thu, 11 Jul 2002 01:06:33 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g6B56Wp44982; Thu, 11 Jul 2002 01:06:32 -0400 To: "Julian Reschke" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Wed, 10 Jul 2002 23:48:09 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_06262002 Pre-release 2|June 26, 2002) at 07/11/2002 01:06:32 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE160DF80169A8f9e8a93df938690918c0ABBE160DF80169A" Content-Disposition: inline Subject: Re: New issue (?): locktoken (12.1.2) syntax Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6416 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE160DF80169A8f9e8a93df938690918c0ABBE160DF80169A Content-type: text/plain; charset=US-ASCII << Question: why would multiple lock tokens refer to the same lock? And *if* there are multiple URIs referring to the same lock (a consequence of BINDs???), what's the point in reporting more than one? Is anybody using this? Has interoperability been tested? >> That caught me by surprise. But you made me read a bit and I did uncover the following. Apparently in the case of a shared lock it's considered the same lock, just different tokens. It's not clear they actually mean that with the following wording, but the following is just one of several places where they use the same sort of wording. 7.2 Write Locks and Lock Tokens A successful request for an exclusive or shared write lock MUST result in the generation of a unique lock token associated with the requesting principal. Thus if five principals have a shared write lock on the same resource there will be five lock tokens, one for each principal. This leaves me perplexed about how UNLOCK works for shared locks. I suggest we (1) check with Yaron if this was intentional and get an explanation and (2) make it clear that each lock has one token and a shared lock means that multiple locks are acting on a resource, not just multiple tokens. (Does anyone know how to contact Yaron?) J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com --0__=0ABBE160DF80169A8f9e8a93df938690918c0ABBE160DF80169A Content-type: text/html; charset=US-ASCII Content-Disposition: inline

<<
Question: why would multiple lock tokens refer to the same lock? And *if*
there are multiple URIs referring to the same lock (a consequence of
BINDs???), what's the point in reporting more than one? Is anybody using
this? Has interoperability been tested?
>>
That caught me by surprise. But you made me read a bit and I did
uncover the following. Apparently in the case of a shared lock
it's considered the same lock, just different tokens. It's not
clear they actually mean that with the following wording, but the
following is just one of several places where they use the same
sort of wording.

7.2 Write Locks and Lock Tokens

  A successful request for an exclusive or shared write lock MUST
  result in the generation of a unique lock token associated with the
  requesting principal.  Thus if five principals have a shared write
  lock on the same resource there will be five lock tokens, one for
  each principal.


This leaves me perplexed about how UNLOCK works for shared locks. I
suggest we (1) check with Yaron if this was intentional and get an
explanation and (2) make it clear that each lock has one token and a
shared lock means that multiple locks are acting on a resource, not
just multiple tokens. (Does anyone know how to contact Yaron?)

J.

------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com
--0__=0ABBE160DF80169A8f9e8a93df938690918c0ABBE160DF80169A-- From w3c-dist-auth-request@w3.org Thu Jul 11 01:09:17 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00457 for ; Thu, 11 Jul 2002 01:09:17 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA22224; Thu, 11 Jul 2002 01:08:19 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6B579609543; Thu, 11 Jul 2002 01:07:09 -0400 (EDT) Resent-Date: Thu, 11 Jul 2002 01:07:09 -0400 (EDT) Resent-Message-Id: <200207110507.g6B579609543@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6B578w09520 for ; Thu, 11 Jul 2002 01:07:08 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA22073 for ; Thu, 11 Jul 2002 01:07:08 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6B56Wg5168308; Thu, 11 Jul 2002 01:06:32 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g6B56Vp118656; Thu, 11 Jul 2002 01:06:31 -0400 To: Dan Brotsky Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Wed, 10 Jul 2002 23:25:32 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_06262002 Pre-release 2|June 26, 2002) at 07/11/2002 01:06:31 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBE160DF819C058f9e8a93df938690918c0ABBE160DF819C05" Subject: Re: discovering the root of a deep lock, HOW_TO_FIND_THE_ROOT_OF_A_LOCK Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6417 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE160DF819C058f9e8a93df938690918c0ABBE160DF819C05 Content-type: multipart/alternative; Boundary="1__=0ABBE160DF819C058f9e8a93df938690918c0ABBE160DF819C05" --1__=0ABBE160DF819C058f9e8a93df938690918c0ABBE160DF819C05 Content-type: text/plain; charset=US-ASCII I've added an issue for this called: HOW_TO_FIND_THE_ROOT_OF_A_LOCK and marked it as approved and awaiting editing of the spec. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com Dan Brotsky cc: Sent by: w3c- Subject: Re: discovering the root of a deep lock dist-auth- request@w3.org 07/10/2002 03:50 PM I will endorse it as well. dan On Wednesday, July 10, 2002, at 11:31 AM, Jason Crawford wrote: > A dav:lockroot as proposed is fine with me. Do we have one more person > that will endorse this? > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > --1__=0ABBE160DF819C058f9e8a93df938690918c0ABBE160DF819C05 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I've added an issue for this called: HOW_TO_FIND_THE_ROOT_OF_A_LOCK

and marked it as approved and awaiting editing of the spec.

J.

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

Dan Brotsky <dbrotsky@adobe.com>




          Dan Brotsky <dbrotsky@adobe.com>
          Sent by: w3c-dist-auth-request@w3.org

          07/10/2002 03:50 PM



To: w3c-dist-auth@w3c.org
cc:
Subject: Re: discovering the root of a deep lock



I will endorse it as well.

dan

On Wednesday, July 10, 2002, at 11:31 AM, Jason Crawford wrote:

> A dav:lockroot as proposed is fine with me. Do we have one more person
> that will endorse this?
>
> ------------------------------------------
> Phone: 914-784-7569, ccjason@us.ibm.com
>



--1__=0ABBE160DF819C058f9e8a93df938690918c0ABBE160DF819C05-- --0__=0ABBE160DF819C058f9e8a93df938690918c0ABBE160DF819C05 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=0ABBE160DF819C058f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBE160DF819C058f9e8a93df938690918c0ABBE160DF819C05 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=0ABBE160DF819C058f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE160DF819C058f9e8a93df938690918c0ABBE160DF819C05 Content-type: image/gif; name="pic32594.gif" Content-Disposition: inline; filename="pic32594.gif" Content-ID: <30__=0ABBE160DF819C058f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=0ABBE160DF819C058f9e8a93df938690918c0ABBE160DF819C05-- From w3c-dist-auth-request@w3.org Thu Jul 11 05:37:52 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14253 for ; Thu, 11 Jul 2002 05:37:52 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA24442; Thu, 11 Jul 2002 05:38:28 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6B9bH529996; Thu, 11 Jul 2002 05:37:17 -0400 (EDT) Resent-Date: Thu, 11 Jul 2002 05:37:17 -0400 (EDT) Resent-Message-Id: <200207110937.g6B9bH529996@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6B9bFw29973 for ; Thu, 11 Jul 2002 05:37:15 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA24294 for ; Thu, 11 Jul 2002 05:37:15 -0400 Received: (qmail 13104 invoked by uid 0); 11 Jul 2002 09:36:44 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp012-rz3) with SMTP; 11 Jul 2002 09:36:44 -0000 From: "Julian Reschke" To: "Jason Crawford" , Date: Thu, 11 Jul 2002 11:36:43 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Subject: RE: New issue (?): locktoken (12.1.2) syntax Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6418 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jason, a few thoughts. - a lock is a resource (by definition: it's identified by a URI) - a lock token is a URI - one could identify LOCK with BINDing the lock token to the lock resource and UNLOCK with deleting the lock token, and that wouldn't affect the basic functionality of shared locks However, the difference is that if we have a 1-1 relation between lock tokens and lock resources, each lock will have it's own timeout value and owner, and I think this is what's implemented in moddav and IIS. So I think the spec should reflect that. Julian -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford Sent: Thursday, July 11, 2002 5:48 AM To: Julian Reschke Cc: w3c-dist-auth@w3.org Subject: Re: New issue (?): locktoken (12.1.2) syntax << Question: why would multiple lock tokens refer to the same lock? And *if* there are multiple URIs referring to the same lock (a consequence of BINDs???), what's the point in reporting more than one? Is anybody using this? Has interoperability been tested? >> That caught me by surprise. But you made me read a bit and I did uncover the following. Apparently in the case of a shared lock it's considered the same lock, just different tokens. It's not clear they actually mean that with the following wording, but the following is just one of several places where they use the same sort of wording. 7.2 Write Locks and Lock Tokens A successful request for an exclusive or shared write lock MUST result in the generation of a unique lock token associated with the requesting principal. Thus if five principals have a shared write lock on the same resource there will be five lock tokens, one for each principal. This leaves me perplexed about how UNLOCK works for shared locks. I suggest we (1) check with Yaron if this was intentional and get an explanation and (2) make it clear that each lock has one token and a shared lock means that multiple locks are acting on a resource, not just multiple tokens. (Does anyone know how to contact Yaron?) J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Jul 11 08:53:15 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17542 for ; Thu, 11 Jul 2002 08:53:15 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA32203; Thu, 11 Jul 2002 08:53:49 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6BCrm325863; Thu, 11 Jul 2002 08:53:48 -0400 (EDT) Resent-Date: Thu, 11 Jul 2002 08:53:48 -0400 (EDT) Resent-Message-Id: <200207111253.g6BCrm325863@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6BCrlw25834 for ; Thu, 11 Jul 2002 08:53:47 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA32179 for ; Thu, 11 Jul 2002 08:53:47 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Thu, 11 Jul 2002 08:46:17 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <3VAG4S60>; Thu, 11 Jul 2002 08:53:16 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B10776154B@SUS-MA1IT01> From: "Clemm, Geoff" To: "'Webdav WG (E-mail)'" Date: Thu, 11 Jul 2002 08:51:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6420 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Larry Masinter [mailto:LMM@acm.org] What about the usage of the terms URI, URL and URN do you actually need? In what way does the definition of these terms affect the WebDAV specification? Most of the terminology is really just advisory. I also don't see what changes we need/expect from RFC-2396. The language there is quite clear. The superclass is "URI". The subclass of "locatable" URIs (i.e. ones that you can type in to a client and expect it to "locate" the specified resource is "URL". The subclass of "naming" URIs (ones that will never be shared by two "different" resources) is URN. In WebDAV, we have some URIs that we SHOULD/MUST be usable to locate the resource. We should call those "URLs" to emphasize that point. For example, the contents of the DAV:href elements returned in DAV:response should be URLs (or more accurately, URL-references). We also have some URIs which name a resource (in particular, lock tokens). These should be called URNs. And while I'm responding to this thread anyway, a few comments on one of Julian's messages: From: Julian Reschke [mailto:julian.reschke@gmx.de] Some more comments inline. > - Change to refer to URL whenever we refer to the address of a > collection or resource. This replaces the definition of "Member > URI" with "Member URL" in the Terminology section, and replaces > URI with URL in the definition of that. Same with "Internal > Member URI" to "Internal Member URL". Many other instances of > URI will be replaced with URL according to this new terminology > approach. E.g. throughout sections 5.2, 5.4, 7.5, 8.1, and > 8.10.3 . When 5.4 refers to source URIs, it needs to continue to do so. Source resources may not be HTTP resources at all. Whether or not it is an HTTP URI/URL is not the issue here. I believe that the purpose of the source property is to locate the resource, and therefore I believe it is appropriately called a URL. 8.1: "Each response XML element MUST contain an href XML element that gives the URI of the resource on which the properties in the prop XML element are defined" needs to be fixed in that the DAV:href element must be defined to be a "URI reference to be resolved relative to the request URI" I agree. 8.10.3: don't agree - resources may have alternate URIs which do not happen to be URLs. I disagree. This is about URIs at which the resource is "available". To me, being available means it is a URL, i.e. can be used to locate the resource. > - Continue to refer to URI when discussing lock > tokens. E.g. section 6.3, 6.4 I disagree with this comment (note that this was something in the original message, not something from Julian's post). We should use the term URN when discussing lock tokens. > - Continue to define the property name as a URI in section 16. As mentioned before, properties do not have URIs (at least there's no one-to-one mapping unless we define it ourselves). The entire paragraph in section 16 needs to be removed or rewritten. I agree. > - Continue to use the term URI in IANA considerations, where the property > name and lock token URIs are discussed. Again -- needs to be fixed. In particular, property names are not URIs at all (but rather a pair consisting of a URI and a property name) and lock tokens should be called URNs, not URIs. Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Jul 11 08:53:19 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17555 for ; Thu, 11 Jul 2002 08:53:19 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA32178; Thu, 11 Jul 2002 08:53:47 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6BCrjv25823; Thu, 11 Jul 2002 08:53:45 -0400 (EDT) Resent-Date: Thu, 11 Jul 2002 08:53:45 -0400 (EDT) Resent-Message-Id: <200207111253.g6BCrjv25823@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6BCriw25803 for ; Thu, 11 Jul 2002 08:53:44 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA32167 for ; Thu, 11 Jul 2002 08:53:44 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Thu, 11 Jul 2002 08:46:13 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <3VAG4S66>; Thu, 11 Jul 2002 08:53:12 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B107761549@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Thu, 11 Jul 2002 08:51:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: New issue (?): locktoken (12.1.2) syntax Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6419 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree with Julian that it makes more sense to have each instance of a shared lock have its own timeout value and lockowner, so I also vote to limit the number of URI's for a given lock to be exactly one. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Thursday, July 11, 2002 5:37 AM To: Jason Crawford; w3c-dist-auth@w3.org Subject: RE: New issue (?): locktoken (12.1.2) syntax Jason, a few thoughts. - a lock is a resource (by definition: it's identified by a URI) - a lock token is a URI - one could identify LOCK with BINDing the lock token to the lock resource and UNLOCK with deleting the lock token, and that wouldn't affect the basic functionality of shared locks However, the difference is that if we have a 1-1 relation between lock tokens and lock resources, each lock will have it's own timeout value and owner, and I think this is what's implemented in moddav and IIS. So I think the spec should reflect that. Julian -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford Sent: Thursday, July 11, 2002 5:48 AM To: Julian Reschke Cc: w3c-dist-auth@w3.org Subject: Re: New issue (?): locktoken (12.1.2) syntax << Question: why would multiple lock tokens refer to the same lock? And *if* there are multiple URIs referring to the same lock (a consequence of BINDs???), what's the point in reporting more than one? Is anybody using this? Has interoperability been tested? >> That caught me by surprise. But you made me read a bit and I did uncover the following. Apparently in the case of a shared lock it's considered the same lock, just different tokens. It's not clear they actually mean that with the following wording, but the following is just one of several places where they use the same sort of wording. 7.2 Write Locks and Lock Tokens A successful request for an exclusive or shared write lock MUST result in the generation of a unique lock token associated with the requesting principal. Thus if five principals have a shared write lock on the same resource there will be five lock tokens, one for each principal. This leaves me perplexed about how UNLOCK works for shared locks. I suggest we (1) check with Yaron if this was intentional and get an explanation and (2) make it clear that each lock has one token and a shared lock means that multiple locks are acting on a resource, not just multiple tokens. (Does anyone know how to contact Yaron?) J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Jul 11 09:31:04 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18171 for ; Thu, 11 Jul 2002 09:31:04 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA07558; Thu, 11 Jul 2002 09:31:34 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6BDVXQ29725; Thu, 11 Jul 2002 09:31:33 -0400 (EDT) Resent-Date: Thu, 11 Jul 2002 09:31:33 -0400 (EDT) Resent-Message-Id: <200207111331.g6BDVXQ29725@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6BDVWw29705 for ; Thu, 11 Jul 2002 09:31:32 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA07534 for ; Thu, 11 Jul 2002 09:31:32 -0400 Received: (qmail 9679 invoked by uid 0); 11 Jul 2002 13:30:59 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp008-rz3) with SMTP; 11 Jul 2002 13:30:59 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG \(E-mail\)'" Date: Thu, 11 Jul 2002 15:31:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10776154B@SUS-MA1IT01> Subject: RE: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6421 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Thursday, July 11, 2002 2:52 PM > To: 'Webdav WG (E-mail)' > Subject: RE: Issue: URI_URL, proposed changes > > > > From: Larry Masinter [mailto:LMM@acm.org] > > What about the usage of the terms URI, URL and URN do you actually > need? In what way does the definition of these terms affect the > WebDAV specification? Most of the terminology is really just > advisory. > > > I also don't see what changes we need/expect from RFC-2396. > The language there is quite clear. The superclass is "URI". > The subclass of "locatable" URIs (i.e. ones that you can > type in to a client and expect it to "locate" the specified > resource is "URL". The subclass of "naming" URIs > (ones that will never be shared by two "different" resources) > is URN. I don't think this is supported by RFC2396. Two URNs may identify the same resource. If you disagree, you'll have to prove that. > In WebDAV, we have some URIs that we SHOULD/MUST be usable > to locate the resource. We should call those "URLs" to emphasize > that point. For example, the contents of the DAV:href elements > returned in DAV:response should be URLs (or more accurately, > URL-references). We also have some URIs which name a resource > (in particular, lock tokens). These should be called URNs. I disagree. URLs are just a subset of URIs. When we talk about URIs that identify WebDAV resources, we can talk about URLs (because we know that they use the http: or https: scheme). Otherwise, we shouldn't make any assumptions. > And while I'm responding to this thread anyway, a few comments > on one of Julian's messages: > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > Some more comments inline. > > > - Change to refer to URL whenever we refer to the address of a > > collection or resource. This replaces the definition of "Member > > URI" with "Member URL" in the Terminology section, and replaces > > URI with URL in the definition of that. Same with "Internal > > Member URI" to "Internal Member URL". Many other instances of > > URI will be replaced with URL according to this new terminology > > approach. E.g. throughout sections 5.2, 5.4, 7.5, 8.1, and > > 8.10.3 . > > When 5.4 refers to source URIs, it needs to continue to do so. Source > resources may not be HTTP resources at all. > > Whether or not it is an HTTP URI/URL is not the issue here. I believe > that the purpose of the source property is to locate the resource, > and therefore I believe it is appropriately called a URL. I think you are in disagreement with the current usage of terms, and with the intended purpose of the source property. Source properties define links to other resources, and whether these resources are identified by a URL or URN should be completely irrelevant. You might want to take a look at . > 8.10.3: don't agree - resources may have alternate URIs which do > not happen to be URLs. > > I disagree. This is about URIs at which the resource is "available". > To me, being available means it is a URL, i.e. can be used to > locate the resource. Yes, but it doesn't mean that there can't be a non-URL URI that identifies the same resource. > > - Continue to refer to URI when discussing lock > > tokens. E.g. section 6.3, 6.4 > > I disagree with this comment (note that this was something in the > original message, not something from Julian's post). We should use > the term URN when discussing lock tokens. That will break existing code for no good reason. One of my repository managers uses the http: scheme to identify lock tokens. So in general - only use URL instead of URI when we *know* it to be a URL (so for http: or https:) - don't touch anything else, except for the purpose of updating from RFC2068 compliance to RFC2396 compliance From w3c-dist-auth-request@w3.org Thu Jul 11 14:42:58 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00562 for ; Thu, 11 Jul 2002 14:42:58 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA30126; Thu, 11 Jul 2002 14:40:39 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6BIebC10893; Thu, 11 Jul 2002 14:40:37 -0400 (EDT) Resent-Date: Thu, 11 Jul 2002 14:40:37 -0400 (EDT) Resent-Message-Id: <200207111840.g6BIebC10893@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6BIeZw10849 for ; Thu, 11 Jul 2002 14:40:35 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA30122; Thu, 11 Jul 2002 14:40:34 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g6BIeL404829; Thu, 11 Jul 2002 11:40:21 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" , , Cc: Date: Thu, 11 Jul 2002 11:38:45 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-UCSC-CATS-MailScanner: Found to be clean Subject: WebDAV/DeltaV Face-to-Face Interoperability Testing Event Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6422 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit WebDAV/DeltaV Interoperability Testing Event -------------------------------------------- Where: Univ. of California, Santa Cruz Baskin Engineering Building "Jack's Lounge" (same location as last year) Santa Cruz, California When: September 11-13, 2002 Who: Developers or testers of WebDAV and DeltaV clients and servers. Cost: Still working on this. It will be free for Open Source developers, and a modest fee (TBD, not to exceed USD $500) per organization for commercial implementors, to cover food, computing support, and setup costs. (But let me know if this fee would prevent you from attending). How to Register: Send email to Jim Whitehead . Following up on last year's very successful interoperability testing event attended by over 50 people, there will be a face-to-face interoperability testing event for WebDAV/DeltaV clients and servers. The intent of this exercise is to gather together, in one physical location, the developers/testers of WebDAV/DeltaV clients and servers, to exerce as many client/server pairs as possible. This will quickly surface interoperability problems. Once identified, these problems can sometimes be fixed on the spot (if developers have brought source code), or can be targeted for resolution in the Draft Standard (i.e., revised) version of RFC 2518. Interoperability testing events are an extremely efficient way to do interoperability testing against a broad array of clients/servers, allowing problems to be quickly identified and resolved. Most organizations do not have the resources to install and operate the wide range of WebDAV/DeltaV clients and servers, and hence only test a small number of the total amount. These events provide a way to test against a wide range of other implementations much faster than would be possible with each organization testing by themselves. Invariably, the net result of an interop. event is a set of clients and servers that work better, hence offering better value for end-users. After all, the expectation of users is that WebDAV clients and servers "just work" with each other. Note that this event is intended to complement the Always on-line Interoperability Testing being organized by Jim Luther . Some details about the event: * Results from the event are NOT intended for distribution to the Press. This is not an interoperability demonstration like those sometimes held at trade shows for marketing purposes. Instead, this is a normal part of the *engineering* activity of creating an interoperability standard. * Since the intended room for this event is not super-big, I request that a maximum of two people attend per independent code base (if this seems too restrictive, let me know). * You will need to provide your own machines, with the client and/or server software installed. UCSC will provide networking capabilities. * DeltaV clients and servers are encouraged to participate, as are ACL, DASL, and Advanced Collections implementations. * If you're intending on participating, please let me know via email to . * If you're traveling from afar, you should try and get accommodations as early as you can (I will not be handling accommodations). Santa Cruz is a popular vacation location in the summer... Here is a Web page giving hotels: http://www.scccvc.org/accom/accsearch.cfm If it's in your price range, the West Coast Santa Cruz Hotel is nice, and most rooms have an ocean view. http://www.westcoastsantacruz.com/ WestCoast Santa Cruz Hotel 175 West Cliff Drive, Santa Cruz, California 95060 831-426-4330 * 800-426-0670 * FAX 831-427-2025 Here's a list of Bed and Breakfast places as well. http://santacruz.about.com/citiestowns/caus/santacruz/cs/accomscbedbreak/ind ex.htm * Some pictures of the location: A picture of half of the room: http://www.webdav.org/other/baskin-commons.jpg A picture of Baskin Engineering: http://www.webdav.org/other/baskin-outside.jpg * Some directions to UCSC and Baskin Engineering: http://www.cse.ucsc.edu/general/find.html A virtual tour of campus (QuickTime VR images): http://www.ucsc.edu/general_info/vtour/index.html * Pictures from last year's event: http://www.webdav.org/other/interop/interop1.jpg http://www.webdav.org/other/interop/interop2.jpg http://www.webdav.org/other/interop/interop3.jpg http://www.webdav.org/other/interop/interop4.jpg http://www.webdav.org/other/interop/interop5.jpg http://www.webdav.org/other/interop/interop6.jpg - Jim From w3c-dist-auth-request@w3.org Sat Jul 13 12:20:02 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26931 for ; Sat, 13 Jul 2002 12:20:01 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA04036; Sat, 13 Jul 2002 12:19:49 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6DGJTG02846; Sat, 13 Jul 2002 12:19:29 -0400 (EDT) Resent-Date: Sat, 13 Jul 2002 12:19:29 -0400 (EDT) Resent-Message-Id: <200207131619.g6DGJTG02846@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6DGJSw02826 for ; Sat, 13 Jul 2002 12:19:28 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA03928 for ; Sat, 13 Jul 2002 12:19:28 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Sat, 13 Jul 2002 12:11:52 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <3VAGX00Y>; Sat, 13 Jul 2002 12:18:57 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B10776196B@SUS-MA1IT01> From: "Clemm, Geoff" To: "'Webdav WG (E-mail)'" Date: Sat, 13 Jul 2002 12:18:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6423 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Clemm, Geoff > > I also don't see what changes we need/expect from RFC-2396. > The language there is quite clear. The superclass is "URI". > The subclass of "locatable" URIs (i.e. ones that you can > type in to a client and expect it to "locate" the specified > resource is "URL". The subclass of "naming" URIs > (ones that will never be shared by two "different" resources) > is URN. I don't think this is supported by RFC2396. Two URNs may identify the same resource. If you disagree, you'll have to prove that. I don't disagree, but I (and RFC-2396) was making the opposite point, namely that two different resources cannot be identified by the same URN. So if two resources have the same URN, you are guaranteed that they are the same resource. > In WebDAV, we have some URIs that we SHOULD/MUST be usable > to locate the resource. We should call those "URLs" to emphasize > that point. For example, the contents of the DAV:href elements > returned in DAV:response should be URLs (or more accurately, > URL-references). We also have some URIs which name a resource > (in particular, lock tokens). These should be called URNs. I disagree. URLs are just a subset of URIs. We don't disagree there. When we talk about URIs that identify WebDAV resources, we can talk about URLs (because we know that they use the http: or https: scheme). Otherwise, we shouldn't make any assumptions. There are places where the URIs are not required to identify WebDAV resources, but which are required to be usable to access the resource. It believe it is appropriate and desireable to use "URL" for those places (the DAV:source URIs are examples of such a place). > Whether or not it is an HTTP URI/URL is not the issue here. I believe > that the purpose of the source property is to locate the resource, > and therefore I believe it is appropriately called a URL. I think you are in disagreement with the current usage of terms, and with the intended purpose of the source property. WRT to "current usage" of those terms, until it is superceded by another RFC, I will use the definitions from RFC-2396, which in my opinion gives those terms acceptably clear and unambiguous definitions. WRT the intended purpose of the source property, section 13.10 of RFC-2518 states: "there is typically only one destination (dst) of the link, which is the URI where the unprocessed source of the resource may be accessed." If something can be "accessed" at that URI, that URI is a URL, as URLs are defined in RFC-2396. And therefore it would have been preferable for section 13.10 to use the term "URL" here, and not "URI". Note: It is not wrong to use "URI" here, but it is just clearer to use "URL". Source properties define links to other resources, and whether these resources are identified by a URL or URN should be completely irrelevant. Not if you are going to use that URI to "access" the resource. A URL is used to access a resource, while a URN only guarantees that it names that resource. A particular URI can of course be both a URL and a URI, but for the purposes of the source property, what matters is that it can be used to access the resource, and there is no guarantee that it names the resource. You might want to take a look at . This draft is primarily about registration of URI schemes, but there is an early section about the "confusion" in usage of the terms URI, URL, and URN, which the authors conclude by saying that "[RFC-2396] has not been successful in clearing up". I find this conclusion a bit puzzling, since the main "confusion" identified by the authors is how/whether URL and URN "partition" the URI space, when RFC-2396 clearly states that a URI can be a URL, a URN, *or both*, and therefore URLs and URNs *do not* partition the URI space. (I would have thought that a reasonably careful reading of RFC-2396 would have therefore cleared up this "confusion"). > 8.10.3: don't agree - resources may have alternate URIs which do > not happen to be URLs. > > I disagree. This is about URIs at which the resource is > "available". To me, being available means it is a URL, i.e. can > be used to locate the resource. Yes, but it doesn't mean that there can't be a non-URL URI that identifies the same resource. Certainly there can be, but those are not URIs at which the resource is "available", and therefore are not relevant to the statement being made in 8.10.3. In particular, I would state that "a resource is available at a URL", although it certainly can be "identified" by a URI that is not a URL. > > - Continue to refer to URI when discussing lock > > tokens. E.g. section 6.3, 6.4 > > I disagree with this comment (note that this was something in the > original message, not something from Julian's post). We should use > the term URN when discussing lock tokens. That will break existing code for no good reason. One of my repository managers uses the http: scheme to identify lock tokens. I think you may be confusing the "urn:" scheme with the concept of a URN. A URI can be both a URL and URN, so as long as you are using http: URLs that happen to have URN behavior, that is fine. In particular, although every URI in the "urn:" scheme SHOULD (or perhaps even MUST) be a URN, not every URN has the "urn:" scheme. So in general - only use URL instead of URI when we *know* it to be a URL (so for http: or https:) Sure. But we need to use the RFC-2396 definition of what is a URL, and anything that can be used to access a resource is a URL. In particular, whether or not something is a URL is not dependent on its scheme, but is dependent on whether it provides the ability to access the resource it identifies. - don't touch anything else, except for the purpose of updating from RFC2068 compliance to RFC2396 compliance I disagree. We also should use URN in all cases where we *know* something is a URN (such as a lock token). Cheers, Geoff From w3c-dist-auth-request@w3.org Sat Jul 13 13:31:57 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28427 for ; Sat, 13 Jul 2002 13:31:57 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA16997; Sat, 13 Jul 2002 13:31:22 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6DHVHP05731; Sat, 13 Jul 2002 13:31:17 -0400 (EDT) Resent-Date: Sat, 13 Jul 2002 13:31:17 -0400 (EDT) Resent-Message-Id: <200207131731.g6DHVHP05731@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6DHVFw05707 for ; Sat, 13 Jul 2002 13:31:15 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA16936 for ; Sat, 13 Jul 2002 13:31:14 -0400 Received: (qmail 11131 invoked by uid 0); 13 Jul 2002 17:30:40 -0000 Received: from pd950c3a3.dip.t-dialin.net (HELO lisa) (217.80.195.163) by mail.gmx.net (mp012-rz3) with SMTP; 13 Jul 2002 17:30:40 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG \(E-mail\)'" Date: Sat, 13 Jul 2002 19:30:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <3906C56A7BD1F54593344C05BD1374B10776196B@SUS-MA1IT01> Subject: RE: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6424 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Saturday, July 13, 2002 6:19 PM > To: 'Webdav WG (E-mail)' > Subject: RE: Issue: URI_URL, proposed changes > > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > From: Clemm, Geoff > > > > I also don't see what changes we need/expect from RFC-2396. > > The language there is quite clear. The superclass is "URI". > > The subclass of "locatable" URIs (i.e. ones that you can > > type in to a client and expect it to "locate" the specified > > resource is "URL". The subclass of "naming" URIs > > (ones that will never be shared by two "different" resources) > > is URN. > > I don't think this is supported by RFC2396. Two URNs may identify > the same resource. If you disagree, you'll have to prove that. > > I don't disagree, but I (and RFC-2396) was making the opposite point, > namely that two different resources cannot be identified by the same > URN. So if two resources have the same URN, you are guaranteed that > they are the same resource. I mis-read what you wrote, but I still disagree (now in a different way). A URI (no matter whether URN or URL) identifies a resource. So two different resources can't have the same URL either. That's by definition. > > In WebDAV, we have some URIs that we SHOULD/MUST be usable > > to locate the resource. We should call those "URLs" to emphasize > > that point. For example, the contents of the DAV:href elements > > returned in DAV:response should be URLs (or more accurately, Actually, they MUST be URLs in the same scheme as the request URI... > > URL-references). We also have some URIs which name a resource > > (in particular, lock tokens). These should be called URNs. > > I disagree. URLs are just a subset of URIs. > > We don't disagree there. RFC2518 has defined that lock tokens are identified by URIs with no restriction. An attempt to restrict lock tokens to specific URI types (are you trying to do that?) can break existing code with no benefit -- the only thing a client should do with a lock token is to remember it, and to resubmit when needed -- from it's point of view it just a string, and clients MUST not make any assumptions about the type of the URI scheme in use. > When we talk about URIs that identify WebDAV resources, we can talk > about URLs (because we know that they use the http: or https: > scheme). Otherwise, we shouldn't make any assumptions. > > There are places where the URIs are not required to identify WebDAV > resources, but which are required to be usable to access the resource. > It believe it is appropriate and desireable to use "URL" for those > places (the DAV:source URIs are examples of such a place). I disagree that the source link MUST use "locatable" resources. We may want to clarify with Roy. Example: I might want to have a source link from http://greenbytes.de/tech/webdav/rfc3253.html to urn:ietf:rfc:3253 Do you say this is wrong? > > Whether or not it is an HTTP URI/URL is not the issue here. > I believe > > that the purpose of the source property is to locate the resource, > > and therefore I believe it is appropriately called a URL. > > I think you are in disagreement with the current usage of terms, > and with the intended purpose of the source property. > > WRT to "current usage" of those terms, until it is superceded by > another RFC, I will use the definitions from RFC-2396, which in my > opinion gives those terms acceptably clear and unambiguous definitions. > WRT the intended purpose of the source property, section 13.10 of > RFC-2518 states: > > "there is typically only one destination (dst) of the link, > which is the URI where the unprocessed source of the resource > may be accessed." This is just s statement about a typical use case. It doesn't say anything about other use cases. > If something can be "accessed" at that URI, that URI is a URL, as > URLs are defined in RFC-2396. And therefore it would have been > preferable for section 13.10 to use the term "URL" here, and not "URI". So who defines whether a URI is a URN? Is urn:isbn:(some-isbn) a URN? Is it a URL? If it *is* a URN (it clearly says so :-), does it become a URL as well if I install a custom URI resolver in my system which knows about the urn:isbn: scheme? I think the concept of *partitioning* URIs into "locatable" und "naming" is bogus -- both types can be used both ways. The joint IETF/W3C URI interest group is currently trying to clarify this, and we should not to rely on outdated definitions. > Note: It is not wrong to use "URI" here, but it is just clearer to > use "URL". > > Source properties define links to other resources, and whether > these resources are identified by a URL or URN should be completely > irrelevant. > > Not if you are going to use that URI to "access" the resource. A Who says that the URI must be usable to "access" the resource? It's certainly not in the current definition. > URL is used to access a resource, while a URN only guarantees > that it names that resource. A particular URI can of course be URLs name resources as well. So are they a superset of URNs? Just wondering. > both a URL and a URI, but for the purposes of the source property, > what matters is that it can be used to access the resource, and there > is no guarantee that it names the resource. URLs are URIs. URIs *identify* resources, so they provide *identifiers* for resources. Are you saying that an "identifier" is not a "name"? > You might want to take a look at > . > > This draft is primarily about registration of URI schemes, but there > is an early section about the "confusion" in usage of the terms URI, > URL, and URN, which the authors conclude by saying that "[RFC-2396] > has not been successful in clearing up". I find this conclusion a bit > puzzling, since the main "confusion" identified by the authors is > how/whether URL and URN "partition" the URI space, when RFC-2396 > clearly states that a URI can be a URL, a URN, *or both*, and > therefore URLs and URNs *do not* partition the URI space. (I would > have thought that a reasonably careful reading of RFC-2396 > would have therefore cleared up this "confusion"). > > > 8.10.3: don't agree - resources may have alternate URIs which do > > not happen to be URLs. > > > > I disagree. This is about URIs at which the resource is > > "available". To me, being available means it is a URL, i.e. can > > be used to locate the resource. > > Yes, but it doesn't mean that there can't be a non-URL URI that > identifies > the same resource. > > Certainly there can be, but those are not URIs at which the > resource is "available", and therefore are not relevant to the > statement being made in 8.10.3. In particular, I would state > that "a resource is available at a URL", although it certainly > can be "identified" by a URI that is not a URL. Resources never are *available* at a URI. *Representations* of resources may be available. I think you are saying that any URI that can be used to locate a representation of a resource is a URL. That may be technically correct (so *I* can basically turn every URN into a URL by implementing a resolver for the scheme). However, most people clearly have a different understanding of URLs. We should try to *avoid* additional confusion, instead of adding to it. > > > - Continue to refer to URI when discussing lock > > > tokens. E.g. section 6.3, 6.4 > > > > I disagree with this comment (note that this was something in the > > original message, not something from Julian's post). We should use > > the term URN when discussing lock tokens. > > That will break existing code for no good reason. One of my repository > managers uses the http: scheme to identify lock tokens. > > I think you may be confusing the "urn:" scheme with the concept of a URN. > A URI can be both a URL and URN, so as long as > you are using http: URLs that happen to have URN behavior, that is > fine. In particular, although every URI in the > "urn:" scheme SHOULD (or perhaps even MUST) be a URN, not every > URN has the "urn:" scheme. > > So in general > > - only use URL instead of URI when we *know* it to be a URL (so for > http: or https:) > > Sure. But we need to use the RFC-2396 definition of what is a URL, > and anything that can be used to access a resource is a URL. I don't think that RFC2396 says that. For instance, "urn:isbn:" clearly is a URN scheme, but I still can use that URN to access a representation of the resource (the resource for instance being a book). > In particular, whether or not something is a URL is not dependent > on its scheme, but is dependent on whether it provides the > ability to access the resource it identifies. How would a *URI* provide that ability? The URI itself is just a name. For specific URI schemes, my computer may have software installed to resolve it, but that's it. RFC2396 characterizes a URL as a URI "that identify resources via a representation of their primary access mechanism (e.g., their network "location")", but that doesn't mean that a non-URL URI can't be used to locate the resource as well. > - don't touch anything else, except for the purpose of updating from > RFC2068 > compliance to RFC2396 compliance > > I disagree. We also should use URN in all cases where we *know* > something is a URN (such as a lock token). Well. If you agree that a HTTP URL can be used to identify a lock token, thus it *is* both a URN and a URL, could you please give an example of a HTTP URL that doesn't share these properties (thus *isn't* a URN)? From w3c-dist-auth-request@w3.org Sat Jul 13 18:13:33 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04546 for ; Sat, 13 Jul 2002 18:13:33 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA26451; Sat, 13 Jul 2002 18:12:17 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6DMCEp22141; Sat, 13 Jul 2002 18:12:14 -0400 (EDT) Resent-Date: Sat, 13 Jul 2002 18:12:14 -0400 (EDT) Resent-Message-Id: <200207132212.g6DMCEp22141@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6DMCDw22121 for ; Sat, 13 Jul 2002 18:12:13 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA26443 for ; Sat, 13 Jul 2002 18:12:13 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Sat, 13 Jul 2002 18:04:36 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <3VAGYD7J>; Sat, 13 Jul 2002 18:11:42 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B107761985@SUS-MA1IT01> From: "Clemm, Geoff" To: "'Webdav WG (E-mail)'" Date: Sat, 13 Jul 2002 18:11:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6425 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Clemm, Geoff > > ... I (and RFC-2396) was making the opposite point, namely that > two different resources cannot be identified by the same URN. So > if two resources have the same URN, you are guaranteed that they > are the same resource. I mis-read what you wrote, but I still disagree (now in a different way). A URI (no matter whether URN or URL) identifies a resource. So two different resources can't have the same URL either. That's by definition. Sure they can. Create a resource at /foo.html. Create a resource at /bar.html. These are separate resources. MOVE /foo.html to /bar.html. /bar.html now identifies a different resource. That is the semantics of a URN ... if a URN identifies a given resource at time X, it also identifies that resource (or no resource at all) at time Y. > > In WebDAV, we have some URIs that we SHOULD/MUST be usable > > to locate the resource. We should call those "URLs" to emphasize > > that point. For example, the contents of the DAV:href elements > > returned in DAV:response should be URLs (or more accurately, Actually, they MUST be URLs in the same scheme as the request URI... That is true as well, but not relevant to the current discussion. It is true that any http: URI is a URL. But in general, different URIs in a specified scheme may be URLs, URNs, both, or neither. For the "http:" scheme, all URIs are URLs and some URIs are URNs. For the "urn:" scheme, all URIs are URNs (or certainly should be), and some URIs are URLs. > > URL-references). We also have some URIs which name a resource > > (in particular, lock tokens). These should be called URNs. > > I disagree. URLs are just a subset of URIs. > > We don't disagree there. RFC2518 has defined that lock tokens are identified by URIs with no restriction. That is incorrect. The first line of section 6.4 (that defines a lock token URI) states: "The opaquelocktoken URI scheme is designed to be unique across all resources for all time." That makes an opaquelocktoken URI a URN, and disallows using non-URN URIs. An attempt to restrict lock tokens to specific URI types (are you trying to do that?) No, I have (several times :-) emphasized that whether or not a URI is a URL or URN does not require that the URI belong to a specific URI type. A URI in any scheme can be a URL, if it can be used to apply a method to the resource identified by that URI. A URI in any scheme can be a URN if it satisfies the semantics requirement of a URN. can break existing code with no benefit -- the only thing a client should do with a lock token is to remember it, and to resubmit when needed -- from it's point of view it just a string, and clients MUST not make any assumptions about the type of the URI scheme in use. And I am not suggesting that they make any such assumption. But they can (and should) make the assumption that any lock token URI is a URN (i.e. globally and uniquely identifies that resource). > When we talk about URIs that identify WebDAV resources, we can talk > about URLs (because we know that they use the http: or https: > scheme). Otherwise, we shouldn't make any assumptions. > > There are places where the URIs are not required to identify WebDAV > resources, but which are required to be usable to access the resource. > It believe it is appropriate and desireable to use "URL" for those > places (the DAV:source URIs are examples of such a place). I disagree that the source link MUST use "locatable" resources. We may want to clarify with Roy. This is an excellent example of why we should carefully use URI, URL, and URN in the spec. The statement in section 13.10 of the spec is potentially ambiguous. In particular, it states: "there is typically only one destination (dst) of the link, which is the URI where the unprocessed source of the resource may be accessed." I interpreted the "typically" to just be a qualifier of "only one". It sounds like you interpreted "typically" to also be a qualifier of the phrase following the comma (while I interpreted it as a definition of "link"). I believe my interpretation is correct, because without that, the source link is basically useless ... "here's is a URI of the source, but you can't use it for anything of interest". Example: I might want to have a source link from http://greenbytes.de/tech/webdav/rfc3253.html to urn:ietf:rfc:3253 Do you say this is wrong? Yes, it is wrong if urn:ietf:rfc:3253 is not a URL (i.e. cannot be used to apply methods such as GET and PUT to the resource that it identifies). But of course, urn:ietf:rfc:3253 easily could be a URL, in which case it would be fine. > "there is typically only one destination (dst) of the link, > which is the URI where the unprocessed source of the resource > may be accessed." This is just s statement about a typical use case. It doesn't say anything about other use cases. See above. I consider "typically" to only qualify "one", not the entire phrase following the comma as well. > If something can be "accessed" at that URI, that URI is a URL, as > URLs are defined in RFC-2396. And therefore it would have been > preferable for section 13.10 to use the term "URL" here, and not "URI". So who defines whether a URI is a URN? Whatever spec is defining the semantics of where that URI appears. If it is required to have the semantics of a URL, it is a URL. If it is required to have the semantics of a URN, it is a URN. This gives the client a vital piece of information about how it can use that URI. Is urn:isbn:(some-isbn) a URN? Is it a URL? Once again, although you can sometimes infer this from the scheme name (i.e. a urn: scheme URI should always be a URN, and an http: scheme URI should always be a URL), you can't infer the opposite, (i.e. a particular urn: scheme URI might be a URL, and a particular http: scheme URI might be a URN). If it *is* a URN (it clearly says so :-), Note that it is RFC 2141 that says so, not the fact that "urn:" happens to be the name of the URI scheme (although it would have been a pretty poor choice for a URI scheme if the URIs in that scheme weren't required to be URNs :-). does it become a URL as well if I install a custom URI resolver in my system which knows about the urn:isbn: scheme? As Larry indicated, the concepts of a URL and URN have fuzzy boundaries. If something in theory would allow you to locate something, but you don't have the locator software installed on your machine, is it still a URL? (I say, yes). If something in theory could be located, but no software has ever been written to locate it using that URI scheme, is it a URL? (I say, no). But most cases are clearer. The point is, what can a client assume. Can it assume that it should be able to apply methods to the resource through that URI? If so, it is a URL. Can it assume that this will uniquely identify a particular resource (for some sensible semantics definition of "a resource")? If so, it is a URN. I think the concept of *partitioning* URIs into "locatable" und "naming" is bogus -- both types can be used both ways. Another strawman (actually, the same strawman being raised again :-). Neither RFC-2396 nor I have ever maintained that the URI space is *partitioned* into "locatable" (URL) and "naming" (URN). In each of my messages in this thread, I have emphasized the opposite, i.e. that a URI can be a URL, a URN, both, or neither (and quoted from 2396 where it explicitly states that these concepts overlap). The joint IETF/W3C URI interest group is currently trying to clarify this, and we should not to rely on outdated definitions. Are you referring to the "classical" and "contemporary" definitions that appear in draft-mealling-uri-ig-02? If so, I strongly recommend that we stick to the definitions in 2396. I found it a bit puzzling that draft-mealling-uri-ig-02 chose to set up two (in my view, bogus) strawman definitions, rather than just quoting from 2396, which actually go it right (and had none of the confusion or problems of the ones that they made up). > URL is used to access a resource, while a URN only guarantees > that it names that resource. A particular URI can of course be URLs name resources as well. So are they a superset of URNs? Just wondering. URLs do not "name" resources in the sense of the term as used in URN. For URNs "name" means "provides a globally unique name". In general, something that "locates" a resource does not provide a "globally unique name" for that resource, so, no, a URL does not "name" a resource, and is not a superset of URNs. > both a URL and a URI, but for the purposes of the source property, > what matters is that it can be used to access the resource, and there > is no guarantee that it names the resource. URLs are URIs. URIs *identify* resources, so they provide *identifiers* for resources. Are you saying that an "identifier" is not a "name"? I am using "locate" as it is defined for URL in 2396, and "name" as it is defined for URN is 2396. These are well defined terms in this context (i.e. "locate" means "can be used to apply a method to the resource identified by the URI", and "name" means "provides a globally unique name for the resource identified by the URI"). Resources never are *available* at a URI. That will come as a surprise to the authors (and reviewers) of RFC 2518, which in section 8.10.3 (:-). In the section we have been discussing, and which I have been quoting) states: "A resource may be made available through more than one URI." *Representations* of resources may be available. I think you are saying that any URI that can be used to locate a representation of a resource is a URL. I am just using terminology in the same way it is used in 2518. One can certainly make the statement more detailed in the way you have above, but I think the 2518 usage is fine. That may be technically correct (so *I* can basically turn every URN into a URL by implementing a resolver for the scheme). And if such a resolver becomes so widespread that a client can reasonably count on it being available, it is a URL. However, most people clearly have a different understanding of URLs. We should try to *avoid* additional confusion, instead of adding to it. I think most people clearly have a different understanding of URLs because most people don't bother to read the spec that defines the term (:-). If there is some problem with the current standardized definition, then it can be fixed, but I believe the confusion arises from all the various fuzzy non-standard definitions (since the term is used by network TV anchormen, I am not surprised that there is some confusion :-). > But we need to use the RFC-2396 definition of what is a URL, > and anything that can be used to access a resource is a URL. I don't think that RFC2396 says that. That is how I interpret: "The term "Uniform Resource Locator" (URL) refers to the subset of URI that identify resources via a representation of their primary access mechanism (e.g., their network "location")"? Note no reference to what their URI scheme may or may not be. For instance, "urn:isbn:" clearly is a URN scheme, but I still can use that URN to access a representation of the resource (the resource for instance being a book). Because, as is explicitly stated by RFC 2396, a URI can be both a URL and a URN. > In particular, whether or not something is a URL is not dependent > on its scheme, but is dependent on whether it provides the > ability to access the resource it identifies. How would a *URI* provide that ability? The URI itself is just a name. Of course it is not the URI that provides that ability (a URI itself has no characteristics other than its adherence to the URI syntax). It is the semantics of the clients and servers that make a given URI be either a URL or a URN. This is clear from RFC 2396, which talks about URLs in terms of "access mechanisms". For specific URI schemes, my computer may have software installed to resolve it, but that's it. RFC2396 characterizes a URL as a URI "that identify resources via a representation of their primary access mechanism (e.g., their network "location")", but that doesn't mean that a non-URL URI can't be used to locate the resource as well. We can quibble over whether something is a URL if it provides a "secondary" access mechanism instead of a "primary" access mechanism, but I see no benefit in doing so. The key aspect of a URL (that differentiates it from a URN) is that it provides access to a resource (while a URN provides a globally unique name for a resource). > We also should use URN in all cases where we *know* something is > a URN (such as a lock token). If you agree that a HTTP URL can be used to identify a lock token, thus it *is* both a URN and a URL, could you please give an example of a HTTP URL that doesn't share these properties (thus *isn't* a URN)? Sure. http://www.webdav.org/deltav/protocol/index.html. I personally have associated that URL with different resources over time, because of various bad interactions with locking (at least, I think that was the problem). If that resource had a URN property, such as a DAV:version-history, you would have been able to notice as much. The same is true for most (probably all) resources on http://www.webdav.org (although there are some links to some http URNs in the http://www.ietf.org/ namespace. Cheers, Geoff From w3c-dist-auth-request@w3.org Sat Jul 13 19:24:10 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06078 for ; Sat, 13 Jul 2002 19:24:09 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA03010; Sat, 13 Jul 2002 19:23:16 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6DNNEQ25948; Sat, 13 Jul 2002 19:23:14 -0400 (EDT) Resent-Date: Sat, 13 Jul 2002 19:23:14 -0400 (EDT) Resent-Message-Id: <200207132323.g6DNNEQ25948@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6DNNDw25928 for ; Sat, 13 Jul 2002 19:23:13 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA03002 for ; Sat, 13 Jul 2002 19:23:13 -0400 Received: (qmail 29712 invoked by uid 0); 13 Jul 2002 23:22:41 -0000 Received: from p3ee24735.dip.t-dialin.net (HELO lisa) (62.226.71.53) by mail.gmx.net (mp002-rz3) with SMTP; 13 Jul 2002 23:22:41 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG \(E-mail\)'" Date: Sun, 14 Jul 2002 01:22:35 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B107761985@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6426 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Sunday, July 14, 2002 12:12 AM > To: 'Webdav WG (E-mail)' > Subject: RE: Issue: URI_URL, proposed changes > > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > From: Clemm, Geoff > > > > ... I (and RFC-2396) was making the opposite point, namely that > > two different resources cannot be identified by the same URN. So > > if two resources have the same URN, you are guaranteed that they > > are the same resource. > > I mis-read what you wrote, but I still disagree (now in a different > way). A URI (no matter whether URN or URL) identifies a > resource. So two different resources can't have the same URL > either. That's by definition. > > Sure they can. Create a resource at /foo.html. Create a resource at > /bar.html. These are separate resources. MOVE /foo.html to > /bar.html. /bar.html now identifies a different resource. That is > the semantics of a URN ... if a URN identifies a given resource at > time X, it also identifies that resource (or no resource at all) at > time Y. Ok. add "...at the same time". > > > URL-references). We also have some URIs which name a resource > > > (in particular, lock tokens). These should be called URNs. > > > > I disagree. URLs are just a subset of URIs. > > > > We don't disagree there. > > RFC2518 has defined that lock tokens are identified by URIs with no > restriction. > > That is incorrect. The first line of section 6.4 (that defines a lock > token URI) states: "The opaquelocktoken URI scheme is designed to be > unique across all resources for all time." That makes an > opaquelocktoken URI a URN, and disallows using non-URN URIs. Wrong. Lock tokens are defined in section 6.3. Section 6.4 defines a particular URI scheme that *can* be used to identify locks. It doesn't say that you need to use it to represent lock tokens :"This specification provides a lock token URI scheme called opaquelocktoken that meets the uniqueness requirements. However resources are free to return any URI scheme so long as it meets the uniqueness requirements." > An attempt to restrict lock tokens to specific URI types (are > you trying to do that?) > > No, I have (several times :-) emphasized that whether or not a URI > is a URL or URN does not require that the URI belong to a specific > URI type. A URI in any scheme can be a URL, if it can be used to > apply a method to the resource identified by that URI. A URI in any > scheme can be a URN if it satisfies the semantics requirement of a URN. I don't have any problem with that definition, however I'm sure that 99% of the readers will have the same definitions of URL/URN in mind when they read the spec, thus I fear unnecessary confusion. > > When we talk about URIs that identify WebDAV resources, > we can talk > > about URLs (because we know that they use the http: or https: > > scheme). Otherwise, we shouldn't make any assumptions. > > > > There are places where the URIs are not required to identify WebDAV > > resources, but which are required to be usable to access the > resource. > > It believe it is appropriate and desireable to use "URL" for those > > places (the DAV:source URIs are examples of such a place). > > I disagree that the source link MUST use "locatable" resources. We > may want to clarify with Roy. > > This is an excellent example of why we should carefully use URI, > URL, and URN in the spec. The statement in section 13.10 of the spec > is potentially ambiguous. In particular, it states: "there is > typically only one destination (dst) of the link, which is the URI > where the unprocessed source of the resource may be accessed." I > interpreted the "typically" to just be a qualifier of "only one". It > sounds like you interpreted "typically" to also be a qualifier of the > phrase following the comma (while I interpreted it as a definition of > "link"). I believe my interpretation is correct, because without > that, the source link is basically useless ... "here's is a URI of the > source, but you can't use it for anything of interest". I have stopped thinking about the current wording for the source property a long time ago. It doesn't make sense. It defines a resource property (DAV:source), which contains the name of the resource itself as an element (DAV:src). It just doesn't make sense (one of the reasons I raised the issue in the issues document). > Example: I might want to have a source link from > http://greenbytes.de/tech/webdav/rfc3253.html > to > urn:ietf:rfc:3253 > > Do you say this is wrong? > > Yes, it is wrong if urn:ietf:rfc:3253 is not a URL (i.e. cannot be > used to apply methods such as GET and PUT to the resource that it > identifies). But of course, urn:ietf:rfc:3253 easily could be a URL, > in which case it would be fine. I disagree. "urn:ietf:rfc:3253" is a URN for a resource. Actually, it is *the* URN endorsed by the IETF to identify the versioning spec. If I want to signal that a document depends on a source which is a RFC, it completely makes sense to refer to it this way. BTW: Can you define what "applicable to methods such as GET and PUT" means? Is "mailto:" a URL scheme? > > "there is typically only one destination (dst) of the link, > > which is the URI where the unprocessed source of the resource > > may be accessed." > > This is just s statement about a typical use case. It doesn't say > anything > about other use cases. > > See above. I consider "typically" to only qualify "one", not the > entire phrase following the comma as well. I disagree, but it probably makes little sense to argue about this paragraph unless we can find somebody who can explain what was intended. The DAV:source property *as defined* doesn't make sense (see above). > > If something can be "accessed" at that URI, that URI is a URL, as > > URLs are defined in RFC-2396. And therefore it would have been > > preferable for section 13.10 to use the term "URL" here, and > not "URI". > > So who defines whether a URI is a URN? > > Whatever spec is defining the semantics of where that URI appears. If > it is required to have the semantics of a URL, it is a URL. If it is > required to have the semantics of a URN, it is a URN. This gives the > client a vital piece of information about how it can use that URI. I agree that it makes sense to give the client this piece of information. I don't agree that just saying "URL" or "URN" will achieve this goal. > As Larry indicated, the concepts of a URL and URN have fuzzy > boundaries. If something in theory would allow you to locate > something, but you don't have the locator software installed on your > machine, is it still a URL? (I say, yes). If something in theory OK, can you give an example for a URN-typed URI which in *theory* can't be located by some dictionary mechanism? It's not globally unique by magic -- it usually depends on naming authorities (DNS, phone numbers), dictionaries (urn scheme, ISBN) and the like. > could be located, but no software has ever been written to locate it > using that URI scheme, is it a URL? (I say, no). But most cases are > clearer. The point is, what can a client assume. Can it assume that > it should be able to apply methods to the resource through that URI? But what is this knowledge good for? Unless the client happens to *know* the URI scheme, it won't be able to do anything useful with the URI (other than use it as identifier), even if it knows it to be a "locator". > If so, it is a URL. Can it assume that this will uniquely identify a > particular resource (for some sensible semantics definition of "a > resource")? If so, it is a URN. > > I think the concept of *partitioning* URIs into > "locatable" und "naming" is bogus -- both types can be used both ways. > > Another strawman (actually, the same strawman being raised again :-). > Neither RFC-2396 nor I have ever maintained that the URI space is > *partitioned* into "locatable" (URL) and "naming" (URN). In each of > my messages in this thread, I have emphasized the opposite, i.e. that > a URI can be a URL, a URN, both, or neither (and quoted from 2396 > where it explicitly states that these concepts overlap). Yes. However, as the ID mentioned states, people *think* that there is a partitioning. That's a problem that RFC2396bis should solve. We should stay out of this business. > > URL is used to access a resource, while a URN only guarantees > > that it names that resource. A particular URI can of course be > > URLs name resources as well. So are they a superset of URNs? Just > wondering. > > URLs do not "name" resources in the sense of the term as used > in URN. For URNs "name" means "provides a globally unique name". > In general, something that "locates" a resource does not provide > a "globally unique name" for that resource, so, no, a URL does > not "name" a resource, and is not a superset of URNs. > > > both a URL and a URI, but for the purposes of the source property, > > what matters is that it can be used to access the resource, and there > > is no guarantee that it names the resource. > > URLs are URIs. URIs *identify* resources, so they provide > *identifiers* for resources. Are you saying that an "identifier" is > not a "name"? > > I am using "locate" as it is defined for URL in 2396, and "name" as > it is defined for URN is 2396. These are well defined terms in this > context (i.e. "locate" means "can be used to apply a method to the > resource identified by the URI", and "name" means "provides a globally > unique name for the resource identified by the URI"). Again: what's the difference between "naming" (URN) and "identifying" (URI). Can you give an example of a URI that identifies, but not "names" a resource? > Resources never are *available* at a URI. > > That will come as a surprise to the authors (and reviewers) of > RFC 2518, which in section 8.10.3 (:-). In the section we have > been discussing, and which I have been quoting) states: > "A resource may be made available through more than one URI." Another thing we may want to fix. > *Representations* of resources may be available. I think you are > saying that any URI that can be used to locate a representation of > a resource is a URL. > > I am just using terminology in the same way it is used in > 2518. One can certainly make the statement more detailed in > the way you have above, but I think the 2518 usage is fine. Probably not. People may get the impression that WebDAV somehow magicallly allows to do something HTTP can't (and doesn't attempt to). HTTP's GET retrieves *representations* of resources. WebDAV doesn't change that. For instance, GET/PROPFIND followed by PUT/PROPPATCH is not guaranteed to do the same thing as COPY (even when not taking versioning/acl into account). > That may be technically correct (so *I* can basically turn every > URN into a URL by implementing a resolver for the scheme). > > And if such a resolver becomes so widespread that a client can > reasonably count on it being available, it is a URL. Who is the authority I can ask whether a particular URI scheme can "now" be considered a URL? Actually, if Microsoft decides not to support "gopher:" anymore -- does the gopher URI loose it's URL-property? > For specific URI schemes, my computer may have software installed > to resolve it, but that's it. RFC2396 characterizes a URL as a URI > "that identify resources via a representation of their primary > access mechanism (e.g., their network "location")", but that > doesn't mean that a non-URL URI can't be used to locate the > resource as well. > > We can quibble over whether something is a URL if it provides a > "secondary" > access mechanism instead of a "primary" access mechanism, but I see no > benefit in doing so. The key aspect of a URL (that differentiates it > >from a URN) is that it provides access to a resource (while a URN > provides a globally unique name for a resource). > > > We also should use URN in all cases where we *know* something is > > a URN (such as a lock token). > > If you agree that a HTTP URL can be used to identify a lock token, > thus it *is* both a URN and a URL, could you please give an example > of a HTTP URL that doesn't share these properties (thus *isn't* a > URN)? > > Sure. http://www.webdav.org/deltav/protocol/index.html. I personally > have associated that URL with different resources over time, because > of various bad interactions with locking (at least, I think that was > the problem). If that resource had a URN property, such as a > DAV:version-history, you would have been able to notice as much. > The same is true for most (probably all) resources on > http://www.webdav.org (although there are some links to some http > URNs in the http://www.ietf.org/ namespace. Well, that's partly a question of how you define a resource. Note that even though a HTTP resource is implemented inside a specific HTTP server, that doesn't necessarily mean that it changes just because internally the implementation of the resource changed. The author may have bound the name to something completely different (making it a new resource internally), but it might *still* represent the *same* resource as observable by clients. For instance, just because somebody moves his stock ticker server from a ASP to a PHP platform (new machines, new OS, new web server) doesn't mean that the URL he assigned now denotes something else. It's just the implementation that changed. (). RFC2396: "The resource is the conceptual mapping to an entity or set of entities, not necessarily the entity which corresponds to that mapping at any particular instance in time. Thus, a resource can remain constant even when its content---the entities to which it currently corresponds---changes over time, provided that the conceptual mapping is not changed in the process. " From w3c-dist-auth-request@w3.org Sun Jul 14 11:49:01 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09979 for ; Sun, 14 Jul 2002 11:49:01 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA01647; Sun, 14 Jul 2002 11:46:33 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6EFkAf06376; Sun, 14 Jul 2002 11:46:10 -0400 (EDT) Resent-Date: Sun, 14 Jul 2002 11:46:10 -0400 (EDT) Resent-Message-Id: <200207141546.g6EFkAf06376@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6EFk9w06356 for ; Sun, 14 Jul 2002 11:46:09 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA01599 for ; Sun, 14 Jul 2002 11:46:09 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Sun, 14 Jul 2002 11:38:26 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <3VAGY3W1>; Sun, 14 Jul 2002 11:45:34 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1077619AC@SUS-MA1IT01> From: "Clemm, Geoff" To: "'Webdav WG (E-mail)'" Date: Sun, 14 Jul 2002 11:45:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6427 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On the off chance that the details of this particular thread are probably becoming less interesting to anyone other than Julian and myself (:-), I'll just summarize my position: - We should adhere to the RFC-2396 definitions of URI, URL, and URN, since no problems with those definitions have been identified. I do not consider the fact that many people don't know/use those definitions to be a problem, since the "commonly held" definitions incorrectly consider URL and URN as partitioning the URI space (i.e. problems have been identified with those "commonly held" definitions). We could try to make up yet another definition (that is different from both RFC-2396 and the "commonly held" definitions) but I see no point in doing so. - We should use "URL" or "URN" in 2518bis whenever we are defining a URI that has the semantic properties of a URL or a URN (as defined by 2396). Specific responses to Julian's most recent comments embedded below. Cheers, Geoff From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > URL-references). We also have some URIs which name a resource > > > (in particular, lock tokens). These should be called URNs. > > > > I disagree. URLs are just a subset of URIs. > > > > We don't disagree there. > > RFC2518 has defined that lock tokens are identified by URIs with no > restriction. > > That is incorrect. The first line of section 6.4 (that defines a lock > token URI) states: "The opaquelocktoken URI scheme is designed to be > unique across all resources for all time." That makes an > opaquelocktoken URI a URN, and disallows using non-URN URIs. Wrong. Lock tokens are defined in section 6.3. It is true that I quoted the wrong section. But if you read section 6.3, it says the same thing, i.e.: "Lock token URIs MUST be unique across all resources for all time." That requires all lock token URIs to satisfy the definition of a URN, which defines each lock token URI to be a URN. Section 6.4 defines a particular URI scheme that *can* be used to identify locks. It doesn't say that you need to use it to represent lock tokens :"This specification provides a lock token URI scheme called opaquelocktoken that meets the uniqueness requirements. However resources are free to return any URI scheme so long as it meets the uniqueness requirements." And "meeting the uniqueness requirements" makes it a URN. > An attempt to restrict lock tokens to specific URI types (are > you trying to do that?) > > No, I have (several times :-) emphasized that whether or not a URI > is a URL or URN does not require that the URI belong to a specific > URI type. A URI in any scheme can be a URL, if it can be used to > apply a method to the resource identified by that URI. A URI in any > scheme can be a URN if it satisfies the semantics requirement of a URN. I don't have any problem with that definition, however I'm sure that 99% of the readers will have the same definitions of URL/URN in mind when they read the spec, thus I fear unnecessary confusion. Then all we have to do is explicitly repeat this definition in the terminology section of the revised version of 2518, supplemented with a reference to 2396. > This is an excellent example of why we should carefully use URI, > URL, and URN in the spec. The statement in section 13.10 of the spec > is potentially ambiguous. In particular, it states: "there is > typically only one destination (dst) of the link, which is the URI > where the unprocessed source of the resource may be accessed." I > interpreted the "typically" to just be a qualifier of "only one". It > sounds like you interpreted "typically" to also be a qualifier of the > phrase following the comma (while I interpreted it as a definition of > "link"). I believe my interpretation is correct, because without > that, the source link is basically useless ... "here's is a URI of the > source, but you can't use it for anything of interest". I have stopped thinking about the current wording for the source property a long time ago. It doesn't make sense. It defines a resource property (DAV:source), which contains the name of the resource itself as an element (DAV:src). It just doesn't make sense (one of the reasons I raised the issue in the issues document). I don't see that this needs to be a complicated issue. The DAV:src field allows you to indicate that multiple resources depend on this link, to give the client an indication of all the other resources that would be affected by authoring the DAV:dst of that link. For Web content management, an example of this would be a "template" resource from which a large number of other resources are derived. In this particular example, the number of other resources is so large that I think it unlikely that a server would ever enumerate them in the DAV:src field. Because I think this will commonly be the case, I'd be happy to deprecate the DAV:src field in the revision of 2518. I personally would also like to rename the DAV:dst element to just be a DAV:href element (for interoperation with the DAV:expand-property REPORT), but that depends on whether any clients are really using DAV:link and therefore expects DAV:dst (current indications are that there are no such clients, so it would be safe to make this change). > Example: I might want to have a source link from > http://greenbytes.de/tech/webdav/rfc3253.html > to > urn:ietf:rfc:3253 > Do you say this is wrong? > > Yes, it is wrong if urn:ietf:rfc:3253 is not a URL (i.e. cannot be > used to apply methods such as GET and PUT to the resource that it > identifies). But of course, urn:ietf:rfc:3253 easily could be a URL, > in which case it would be fine. I disagree. "urn:ietf:rfc:3253" is a URN for a resource. Actually, it is *the* URN endorsed by the IETF to identify the versioning spec. If I want to signal that a document depends on a source which is a RFC, it completely makes sense to refer to it this way. I believe the central value of the DAV:source field is that it allows the client to perform methods on the resource identified by the DAV:dst field to cause changes to the content of the resource. This value is not provided if the URI in the DAV:dst field is not a URL. Having a URI that is not a URL would not provide a mechanism for the client to effectively author the resource, which leads me to conclude that the spec should require the DAV:dst field to be a URL. BTW: Can you define what "applicable to methods such as GET and PUT" means? Is "mailto:" a URL scheme? It probably would be valuable to identify a minimal set of methods that SHOULD be applicable to the DAV:dst URL, in order to provide for interoperation. Perhaps: "Either GET/PUT or PROPFIND/PROPPATCH SHOULD be supported on the DAV:dst URL". > > "there is typically only one destination (dst) of the link, > > which is the URI where the unprocessed source of the resource > > may be accessed." ... it probably makes little sense to argue about this paragraph unless we can find somebody who can explain what was intended. The DAV:source property *as defined* doesn't make sense (see above). Do you just mean the lack of utility of the DAV:src element? That's easily resolved by deprecating the DAV:src element. Then we just rewrite that section as: "The destination (dst) of the link is the URL where an unprocessed source of the resource may be accessed. Typically there is only one DAV:dst element, but there could be multiple if the resource content is derived from multiple inputs." > Whatever spec is defining the semantics of where that URI appears. If > it is required to have the semantics of a URL, it is a URL. If it is > required to have the semantics of a URN, it is a URN. This gives the > client a vital piece of information about how it can use that URI. I agree that it makes sense to give the client this piece of information. I don't agree that just saying "URL" or "URN" will achieve this goal. Think of it as a "public service" (:-). If a large number of people are using the terms URL and URN in confusing ways, we'll be a shining example of useful and consistent usage of those terms. The W3C "URI interest group" can then focus on debating details of urn: scheme registration (:-). > As Larry indicated, the concepts of a URL and URN have fuzzy > boundaries. If something in theory would allow you to locate > something, but you don't have the locator software installed on your > machine, is it still a URL? (I say, yes). If something in theory OK, can you give an example for a URN-typed URI which in *theory* can't be located by some dictionary mechanism? It's not globally unique by magic -- it usually depends on naming authorities (DNS, phone numbers), dictionaries (urn scheme, ISBN) and the like. Exactly. As indicated earlier, something doesn't become a URN or a URL by some syntactic magic. It becomes one because the implemented client and server mechanisms make it one. > could be located, but no software has ever been written to locate it > using that URI scheme, is it a URL? (I say, no). But most cases are > clearer. The point is, what can a client assume. Can it assume that > it should be able to apply methods to the resource through that URI? But what is this knowledge good for? Unless the client happens to *know* the URI scheme, it won't be able to do anything useful with the URI (other than use it as identifier), even if it knows it to be a "locator". Of course a particular client may not have the software to access that URL, or the server that should be responsible for applying methods to that resource may not actually do so. What we are trying to avoid is having implementors misunderstand the semantics of a particular field. This gives the client and server writers essential guidance wrt what kind of URI they should allow in a particular field. With the example above, if we decide that the DAV:dst field should contain a URL, then a server should not store a urn: URI that they know is not commonly supported by clients and servers to apply methods to that resource. > Neither RFC-2396 nor I have ever maintained that the URI space is > *partitioned* into "locatable" (URL) and "naming" (URN). In each of > my messages in this thread, I have emphasized the opposite, i.e. that > a URI can be a URL, a URN, both, or neither (and quoted from 2396 > where it explicitly states that these concepts overlap). Yes. However, as the ID mentioned states, people *think* that there is a partitioning. That's a problem that RFC2396bis should solve. We should stay out of this business. I disagree. If some people are using a common term in a confusing and logically inconsistent way, and if there is a standard (that was reviewed and accepted by the IETF), then we should just emphasize in the revision of 2518 that we are using the standardized definitions (and repeat those definitions in our spec). An analogy is the term "or". In popular culture it is ambiguously used to mean either "exclusive or" or "inclusive or". This doesn't mean we can no longer use the term "or" in formal documents. It just means that we should emphasize that we are using the standard formal meaning, not the informal meaning. > I am using "locate" as it is defined for URL in 2396, and "name" as > it is defined for URN is 2396. These are well defined terms in this > context (i.e. "locate" means "can be used to apply a method to the > resource identified by the URI", and "name" means "provides a globally > unique name for the resource identified by the URI"). Again: what's the difference between "naming" (URN) and "identifying" (URI). Again: I am just using the terms as they are used in 2396. All UR*I*s "identify" a resource. All UR*N*s "name" a resource. All UR*L*s "locate" a resource. And of course, these are not the universal definitions of these terms. They are just how they are used in 2396. Can you give an example of a URI that identifies, but not "names" a resource? Just repeating the example from the previous messsage, http://www.webdav.org/deltav/index.html identifies a resource, but does not name ("provide a globally unique name for") that resource, because I have used MOVE to cause that URI to identify different resources at different times. > Resources never are *available* at a URI. > > That will come as a surprise to the authors (and reviewers) of > RFC 2518 (:-). In the section we have been discussing, and which > I have been quoting) states: "A resource may be made available > through more than one URI." Another thing we may want to fix. If it ain't broke, don't fix it (and in this case, if it ain't broke, don't break it :-). > *Representations* of resources may be available. I think you are > saying that any URI that can be used to locate a representation of > a resource is a URL. > > I am just using terminology in the same way it is used in > 2518. One can certainly make the statement more detailed in > the way you have above, but I think the 2518 usage is fine. Probably not. People may get the impression that WebDAV somehow magicallly allows to do something HTTP can't (and doesn't attempt to). HTTP's GET retrieves *representations* of resources. WebDAV doesn't change that. But WebDAV isn't just talking about GET ... it also talking about PROPFIND and others. Saying that a resource is available says that there are methods that can be applied to that URI that will not fail. In particular, some resources that are "available" do not support GET, so we are not talking about the "availability of the representation". For instance, GET/PROPFIND followed by PUT/PROPPATCH is not guaranteed to do the same thing as COPY (even when not taking versioning/acl into account). "Availability" says nothing about the semantics of successive operations. It just says that a method can be applied to that URI and succeed. > That may be technically correct (so *I* can basically turn every > URN into a URL by implementing a resolver for the scheme). > > And if such a resolver becomes so widespread that a client can > reasonably count on it being available, it is a URL. Who is the authority I can ask whether a particular URI scheme can "now" be considered a URL? Actually, if Microsoft decides not to support "gopher:" anymore -- does the gopher URI loose it's URL-property? Is indicated earlier, this is not a formally demonstrable property of a URI (such as its syntax). It is a qualitative property, and there will be grey areas. And yes, if a URI scheme is no longer widely implemented, the URIs in that scheme are no longer URLs. And similarly, if a urn: scheme is widely implemented to not provide globally unique naming, then a URI in that urn: scheme would not be a URN. The concepts of URN and URI are worthless if they just refer to some syntactic notion (e.g. "has a scheme name that begins with the characters 'u', 'r', and 'n'). > If you agree that a HTTP URL can be used to identify a lock token, > thus it *is* both a URN and a URL, could you please give an example > of a HTTP URL that doesn't share these properties (thus *isn't* a > URN)? > > Sure. http://www.webdav.org/deltav/protocol/index.html. I personally > have associated that URL with different resources over time, because > of various bad interactions with locking (at least, I think that was > the problem). If that resource had a URN property, such as a > DAV:version-history, you would have been able to notice as much. > The same is true for most (probably all) resources on > http://www.webdav.org (although there are some links to some http > URNs in the http://www.ietf.org/ namespace. Well, that's partly a question of how you define a resource. Note that even though a HTTP resource is implemented inside a specific HTTP server, that doesn't necessarily mean that it changes just because internally the implementation of the resource changed. That is of course true. Just like the concepts of a URN and URL, the concept of "object identity" has fuzzy boundaries (in all domains, not just IETF protocols). As we introduce more advanced protocol funtionality (versioning, binding), these boundaries start to get firmed up though. In particular, those protocol extensions make it clear that MOVE associates an existing resource (with a given identity) with a different URI, while COPY creates a new resource (whose identity is different from the resource that was the source of the COPY). Cheers, Geoff From w3c-dist-auth-request@w3.org Sun Jul 14 14:09:11 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13059 for ; Sun, 14 Jul 2002 14:09:11 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA18804; Sun, 14 Jul 2002 13:51:01 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6EHoq311256; Sun, 14 Jul 2002 13:50:52 -0400 (EDT) Resent-Date: Sun, 14 Jul 2002 13:50:52 -0400 (EDT) Resent-Message-Id: <200207141750.g6EHoq311256@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6EHonw11232 for ; Sun, 14 Jul 2002 13:50:49 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA18772 for ; Sun, 14 Jul 2002 13:50:48 -0400 Received: (qmail 28086 invoked by uid 0); 14 Jul 2002 17:50:46 -0000 Received: from p3ee24718.dip.t-dialin.net (HELO lisa) (62.226.71.24) by mail.gmx.net (mp007-rz3) with SMTP; 14 Jul 2002 17:50:46 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG \(E-mail\)'" Date: Sun, 14 Jul 2002 19:50:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1077619AC@SUS-MA1IT01> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6428 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Sunday, July 14, 2002 5:45 PM > To: 'Webdav WG (E-mail)' > Subject: RE: Issue: URI_URL, proposed changes > > > > On the off chance that the details of this particular thread > are probably becoming less interesting to anyone other than > Julian and myself (:-), I'll just summarize my position: > > - We should adhere to the RFC-2396 definitions of URI, URL, and URN, > since no problems with those definitions have been identified. I do > not consider the fact that many people don't know/use those > definitions to be a problem, since the "commonly held" definitions > incorrectly consider URL and URN as partitioning the URI space > (i.e. problems have been identified with those "commonly held" > definitions). We could try to make up yet another definition (that > is different from both RFC-2396 and the "commonly held" definitions) > but I see no point in doing so. > > - We should use "URL" or "URN" in 2518bis whenever we are defining a URI > that has the semantic properties of a URL or a URN (as defined by 2396). I agree, as long as the wording makes clear what is meant. > Specific responses to Julian's most recent comments embedded below. > > Cheers, > Geoff > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > > > URL-references). We also have some URIs which name a > resource > > > > (in particular, lock tokens). These should be called URNs. > > > > > > I disagree. URLs are just a subset of URIs. > > > > > > We don't disagree there. > > > > RFC2518 has defined that lock tokens are identified by > URIs with no > > restriction. > > > > That is incorrect. The first line of section 6.4 (that > defines a lock > > token URI) states: "The opaquelocktoken URI scheme is designed to be > > unique across all resources for all time." That makes an > > opaquelocktoken URI a URN, and disallows using non-URN URIs. > > Wrong. Lock tokens are defined in section 6.3. > > It is true that I quoted the wrong section. But if you read section > 6.3, it says the same thing, i.e.: "Lock token URIs MUST be unique > across all resources for all time." That requires all lock token > URIs to satisfy the definition of a URN, which defines each lock > token URI to be a URN. Yes. > Section 6.4 defines a particular URI scheme that *can* be used to > identify locks. It doesn't say that you need to use it to represent > lock tokens :"This specification provides a lock token URI scheme > called opaquelocktoken that meets the uniqueness > requirements. However resources are free to return any URI scheme > so long as it meets the uniqueness requirements." > > And "meeting the uniqueness requirements" makes it a URN. Yes. > > An attempt to restrict lock tokens to specific URI types (are > > you trying to do that?) > > > > No, I have (several times :-) emphasized that whether or not a URI > > is a URL or URN does not require that the URI belong to a specific > > URI type. A URI in any scheme can be a URL, if it can be used to > > apply a method to the resource identified by that URI. A URI in any > > scheme can be a URN if it satisfies the semantics > requirement of a URN. > > I don't have any problem with that definition, however I'm sure > that 99% of the readers will have the same definitions of URL/URN > in mind when they read the spec, thus I fear unnecessary confusion. > > Then all we have to do is explicitly repeat this definition in the > terminology section of the revised version of 2518, supplemented > with a reference to 2396. Fine with me. > > This is an excellent example of why we should carefully use URI, > > URL, and URN in the spec. The statement in section 13.10 of the spec > > is potentially ambiguous. In particular, it states: "there is > > typically only one destination (dst) of the link, which is the URI > > where the unprocessed source of the resource may be accessed." I > > interpreted the "typically" to just be a qualifier of "only one". It > > sounds like you interpreted "typically" to also be a qualifier of the > > phrase following the comma (while I interpreted it as a definition of > > "link"). I believe my interpretation is correct, because without > > that, the source link is basically useless ... "here's is a > URI of the > > source, but you can't use it for anything of interest". > > I have stopped thinking about the current wording for the > source property > a > long time ago. It doesn't make sense. It defines a resource property > (DAV:source), which contains the name of the resource itself as an > element > (DAV:src). It just doesn't make sense (one of the reasons I raised the > issue > in the issues document). > > I don't see that this needs to be a complicated issue. The DAV:src > field allows you to indicate that multiple resources depend > on this link, to give the client an indication of all the other > resources that would be affected by authoring the DAV:dst of that > link. For Web content management, an example of this would be a > "template" resource from which a large number of other resources are > derived. In this particular example, the number of other resources is > so large that I think it unlikely that a server would ever enumerate > them in the DAV:src field. Because I think this will commonly be the > case, I'd be happy to deprecate the DAV:src field in the revision of > 2518. I personally would also like to rename the DAV:dst element to > just be a DAV:href element (for interoperation with the > DAV:expand-property REPORT), but that depends on whether any clients > are really using DAV:link and therefore expects DAV:dst (current > indications are that there are no such clients, so it would be > safe to make this change). Agreed. > > Example: I might want to have a source link from > > http://greenbytes.de/tech/webdav/rfc3253.html > > to > > urn:ietf:rfc:3253 > > Do you say this is wrong? > > > > Yes, it is wrong if urn:ietf:rfc:3253 is not a URL (i.e. cannot be > > used to apply methods such as GET and PUT to the resource that it > > identifies). But of course, urn:ietf:rfc:3253 easily could be a URL, > > in which case it would be fine. > > I disagree. "urn:ietf:rfc:3253" is a URN for a resource. Actually, > it is *the* URN endorsed by the IETF to identify the versioning > spec. If I want to signal that a document depends on a source > which is a RFC, it completely makes sense to refer to it this way. > > I believe the central value of the DAV:source field is that it allows > the client to perform methods on the resource identified by the > DAV:dst field to cause changes to the content of the resource. This > value is not provided if the URI in the DAV:dst field is not a URL. > Having a URI that is not a URL would not provide a mechanism for > the client to effectively author the resource, which leads me to > conclude that the spec should require the DAV:dst field to be a URL. I don't buy that. You seem to argue that if a source for a document is not authorable (which actually is the case in my example), then it's not worth mentioning it as source. I think this is wrong. > BTW: Can you define what "applicable to methods such as GET and > PUT" means? Is "mailto:" a URL scheme? > > It probably would be valuable to identify a minimal set of methods > that SHOULD be applicable to the DAV:dst URL, in order to provide for > interoperation. Perhaps: "Either GET/PUT or PROPFIND/PROPPATCH SHOULD > be supported on the DAV:dst URL". It seems that you now require the URL to be either a http: or https: based one. What about "mid:" or "ftp:"? These schemes define locations, but do not have a concept of "methods". See Roy's comment in : "That is not relevant. The resources might just as easily be ftp or file URLs, or might only be authorable by someone with authorization or coming from a particular IP address. Identifying the source does not imply authorability on that resource, nor does it need to in order to be useful to the user." > > > "there is typically only one destination (dst) of the link, > > > which is the URI where the unprocessed source of the resource > > > may be accessed." > > ... it probably makes little sense to argue about this paragraph > unless we can find somebody who can explain what was intended. The > DAV:source property *as defined* doesn't make sense (see above). > > Do you just mean the lack of utility of the DAV:src element? That's > easily resolved by deprecating the DAV:src element. Then we just > rewrite that section as: > "The destination (dst) of the link is the URL where an unprocessed > source of the resource may be accessed. Typically there is only one > DAV:dst element, but there could be multiple if the resource content > is derived from multiple inputs." I disagree with the attempt to (now) require the source to be identified by a URL. It doesn't help the client at all. Even if the server firmly believes that a URI has "locator" quality, it can never be sure that the client agrees (== has the same resolver software installed). Except of course it happens to be an http: URL. > > could be located, but no software has ever been written to locate it > > using that URI scheme, is it a URL? (I say, no). But most cases are > > clearer. The point is, what can a client assume. Can it assume that > > it should be able to apply methods to the resource through that URI? > > But what is this knowledge good for? Unless the client happens to > *know* the URI scheme, it won't be able to do anything useful with > the URI (other than use it as identifier), even if it knows it to > be a "locator". > > Of course a particular client may not have the software to access that > URL, or the server that should be responsible for applying methods to > that resource may not actually do so. What we are trying to avoid is > having implementors misunderstand the semantics of a particular > field. This > gives the client and server writers essential guidance wrt what kind > of URI they should allow in a particular field. With the example above, Given an arbitrary URI, what is the mechanism I can apply to it to find out whether it has the URL-property? > if we decide that the DAV:dst field should contain a URL, then a server > should not store a urn: URI that they know is not commonly supported > by clients and servers to apply methods to that resource. I completely disagree, unless you can describe a sane algorithm that makes this decision. > > Resources never are *available* at a URI. > > > > That will come as a surprise to the authors (and reviewers) of > > RFC 2518 (:-). In the section we have been discussing, and which > > I have been quoting) states: "A resource may be made available > > through more than one URI." > > Another thing we may want to fix. > > If it ain't broke, don't fix it (and in this case, if it ain't broke, > don't break it :-). > > > *Representations* of resources may be available. I think you are > > saying that any URI that can be used to locate a representation of > > a resource is a URL. > > > > I am just using terminology in the same way it is used in > > 2518. One can certainly make the statement more detailed in > > the way you have above, but I think the 2518 usage is fine. > > Probably not. People may get the impression that WebDAV somehow > magicallly > allows to do something HTTP can't (and doesn't attempt to). HTTP's GET > retrieves *representations* of resources. WebDAV doesn't change that. > > But WebDAV isn't just talking about GET ... it also talking about > PROPFIND and others. Saying that a resource is available says that > there are methods that can be applied to that URI that will not fail. Maybe this definition should be added somewhere... > In particular, some resources that are "available" do not support > GET, so we are not talking about the "availability of the representation". Such as? Just because the spec doesn't define the *specific* behaviour for GET, this doesn't mean that GET should fail. Do you propose to fail an attempt to GET a representation of a VHR? If so, what HTTP response code would you propose? 204 (no content) seems to make sense, but it wouldn't be a failure code, thus the VHR *would* support GET. > For instance, GET/PROPFIND followed by PUT/PROPPATCH is not > guaranteed to do the same thing as COPY (even when not taking > versioning/acl into account). > > "Availability" says nothing about the semantics of successive operations. > It just says that a method can be applied to that URI and succeed. So it can be any method? For instance, if GET on a URI returns 404, can I say that the resource identified by "a" is "available", just because a PUT on it would succeed? > > That may be technically correct (so *I* can basically turn every > > URN into a URL by implementing a resolver for the scheme). > > > > And if such a resolver becomes so widespread that a client can > > reasonably count on it being available, it is a URL. > > Who is the authority I can ask whether a particular URI scheme can > "now" be considered a URL? Actually, if Microsoft decides not to > support "gopher:" anymore -- does the gopher URI loose it's > URL-property? > > Is indicated earlier, this is not a formally demonstrable property > of a URI (such as its syntax). It is a qualitative property, and there > will be grey areas. And yes, if a URI scheme is no longer widely > implemented, the URIs in that scheme are no longer URLs. And similarly, So what happens to URLs using that scheme that happen to be already stored in DAV:source properties? Would it be illegal for a server to keep them? How would the server know that something it accepted in the past as valid URL has lost it's URL property? > if a urn: scheme is widely implemented to not provide globally unique > naming, then a URI in that urn: scheme would not be a URN. The concepts > of URN and URI are worthless if they just refer to some syntactic > notion (e.g. "has a scheme name that begins with the characters 'u', > 'r', and 'n'). Yes. I didn't propose that interpretation. > > If you agree that a HTTP URL can be used to identify a lock token, > > thus it *is* both a URN and a URL, could you please give > an example > > of a HTTP URL that doesn't share these properties (thus *isn't* a > > URN)? > > > > Sure. http://www.webdav.org/deltav/protocol/index.html. I > personally > > have associated that URL with different resources over time, because > > of various bad interactions with locking (at least, I think that was > > the problem). If that resource had a URN property, such as a > > DAV:version-history, you would have been able to notice as much. > > The same is true for most (probably all) resources on > > http://www.webdav.org (although there are some links to some http > > URNs in the http://www.ietf.org/ namespace. > > Well, that's partly a question of how you define a resource. Note > that even though a HTTP resource is implemented inside a specific > HTTP server, that doesn't necessarily mean that it changes just > because internally the implementation of the resource changed. > > That is of course true. Just like the concepts of a URN and URL, the > concept of "object identity" has fuzzy boundaries (in all domains, > not just IETF protocols). As we introduce more advanced protocol > funtionality (versioning, binding), these boundaries start to get > firmed up though. In particular, those protocol extensions make it > clear that MOVE associates an existing resource (with a given identity) > with a different URI, while COPY creates a new resource (whose identity > is different from the resource that was the source of the COPY). It will still depend on the point of view. From the client's perspective, it's really irrelevant whether the internal implementation has changed, as long as the abstract resource identified by the URI is the same. From w3c-dist-auth-request@w3.org Mon Jul 15 06:12:22 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22069 for ; Mon, 15 Jul 2002 06:12:21 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA06555; Mon, 15 Jul 2002 06:11:00 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6FAAtK05377; Mon, 15 Jul 2002 06:10:55 -0400 (EDT) Resent-Date: Mon, 15 Jul 2002 06:10:55 -0400 (EDT) Resent-Message-Id: <200207151010.g6FAAtK05377@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6FAAtw05357 for ; Mon, 15 Jul 2002 06:10:55 -0400 (EDT) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA06538 for ; Mon, 15 Jul 2002 06:10:54 -0400 Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id TAA29555 for ; Mon, 15 Jul 2002 19:10:50 +0900 (JST) Received: from pekoe.iij.ad.jp (pekoe.iij.ad.jp [192.168.4.173]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with SMTP id SAA23792 for ; Mon, 15 Jul 2002 18:43:16 +0900 (JST) Received: (nullmailer pid 28322 invoked by uid 5292); Mon, 15 Jul 2002 09:37:39 -0000 To: w3c-dist-auth@w3.org References: MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Taisuke Yamada Date: Mon, 15 Jul 2002 18:37:38 +0900 In-Reply-To: (Jim Whitehead's message of "Tue, 9 Jul 2002 12:38:47 -0700") Message-ID: Lines: 37 User-Agent: T-gnus/6.15.6 (based on Oort Gnus v0.06) (revision 01) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1 (AOI) Subject: Re: FW: character encoding. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6429 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Hi. I assume you're having a problem with charset encoding in HTTP request-line and HTTP header. I don't know if this encoding issue has been discussed in the past, but I believe the general consensus is to use UTF-8 in any case. I think there's some notes on this issue in rfc2396 and rfc2277 (can anyone correct me?). As there is no way to transmit encoding information for HTTP request-line and HTTP header, this seems to be the only solution. Of course, the problem is that not all clients/servers actually follow this scheme - older implementation tends to transmit (or expects to receive) whatever the encoding it uses locally. This obviously causes interoperability problem when non-ASCII named resource is used. I currently get around the problem by plugging an encoding detection/conversion filter in the server I'm running. This problem was not apparent (or critical) before WebDAV, because it was not a common practice to give non-ASCII URL to web browsers. Only after the WebDAV, the Web become writable as "filesystem", and people started to use non-ASCII filenames. > Second i have a java implementation of a webdav server running on > resin (webserver). Resin allows one to specify character encoding > in the conf file. However when used with other webservers or > OS (using windows just now) it isnt possible to set the character > encoding. Therefore when my windows explorer client sends the > encoded request the server doesnt recognise it and spits out a bad > request 400. DO i now have to go and implement the character > encoding too? -- Taisuke Yamada Internet Initiative Japan Inc., Technical Planning Division From w3c-dist-auth-request@w3.org Wed Jul 17 06:30:38 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11729 for ; Wed, 17 Jul 2002 06:30:38 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA26431; Wed, 17 Jul 2002 06:29:23 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6HASjf18555; Wed, 17 Jul 2002 06:28:45 -0400 (EDT) Resent-Date: Wed, 17 Jul 2002 06:28:45 -0400 (EDT) Resent-Message-Id: <200207171028.g6HASjf18555@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6HASiw18535 for ; Wed, 17 Jul 2002 06:28:44 -0400 (EDT) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA26327 for ; Wed, 17 Jul 2002 06:28:42 -0400 Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id TAA10865 for ; Wed, 17 Jul 2002 19:28:39 +0900 (JST) Received: from pekoe.iij.ad.jp (pekoe.iij.ad.jp [192.168.4.173]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with SMTP id TAA07707 for ; Wed, 17 Jul 2002 19:28:39 +0900 (JST) Received: (nullmailer pid 27967 invoked by uid 5292); Wed, 17 Jul 2002 10:28:22 -0000 To: w3c-dist-auth@w3c.org References: MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Taisuke Yamada Date: Wed, 17 Jul 2002 19:28:21 +0900 In-Reply-To: (Taisuke Yamada's message of "Mon, 15 Jul 2002 18:37:38 +0900") Message-ID: Lines: 39 User-Agent: T-gnus/6.15.6 (based on Oort Gnus v0.06) (revision 01) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1 (AOI) Subject: Web Character Model and IRI spec (Re: FW: character encoding.) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6430 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Hi. Regarding the use of WebDAV in i18n environment, I am assuming that WebDAV spec will be updated (hopefully soon) to refer IRI and CHARMOD. IRI defines i18n-ized format of URI and CHARMOD defines how you can define/implement a spec so it can be inter- nationally deployed. Am I correct, or is this not a decided issue yet? My current concern is that these specs are taking longer than expected (no surprise as they're tackling complex problem). So by the time they arrive, it could turn out that existing implementations (with glitches in i18n) reached a critical mass and simply don't go away after all. Number of implementations supporting UTF-8 is growing, but even some of them are still not interoperable as Unicode has its own issues also (see CHARMOD). It's probably just a matter of time, but the need for a updated WebDAV spec is really wanted. I believe delay in IRI and CHARMOD would impact WebDAV heavily as people frequently use i18n URI. How does it sound to go ahead and clarify support of at least part of the IRI spec in advance, so actual implementation wouldn't be so far away from CHARMOD/IRI when set? I think clarifying URI (and its partial representation) to be %HH encoded form of normalized UTF-8 is a key issue here. References: [IRI] http://www.w3.org/International/O-URL-and-ident http://www.w3.org/International/2002/draft-duerst-iri-00.txt [CHARMOD] http://www.w3.org/TR/charmod/ Regards, -- Taisuke Yamada Internet Initiative Japan Inc., Technical Planning Division From w3c-dist-auth-request@w3.org Wed Jul 17 20:24:01 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03577 for ; Wed, 17 Jul 2002 20:24:01 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA03953; Wed, 17 Jul 2002 20:20:56 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6I0KqE04758; Wed, 17 Jul 2002 20:20:52 -0400 (EDT) Resent-Date: Wed, 17 Jul 2002 20:20:52 -0400 (EDT) Resent-Message-Id: <200207180020.g6I0KqE04758@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6I0Kpw04738 for ; Wed, 17 Jul 2002 20:20:51 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id UAA03924 for ; Wed, 17 Jul 2002 20:20:51 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 17 Jul 2002 20:19:42 -0400 (Eastern Daylight Time) Received: from ATL1VEXC006.usdom004.tco.tc ([10.158.7.207]) by atl1simr002.tco.tc with Microsoft SMTPSVC(5.0.2195.2966); Wed, 17 Jul 2002 20:19:42 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 17 Jul 2002 20:19:42 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA601736D873@ATL1VEXC006.usdom004.tco.tc> Thread-Topic: WebDAV WG Meeting minutes Thread-Index: AcIt8NUI0oAr98X5RhK7wsuYry4gQg== From: "Lisa Dusseault" To: , "Webdav WG" X-OriginalArrivalTime: 18 Jul 2002 00:19:42.0527 (UTC) FILETIME=[D0064CF0:01C22DF0] Subject: WebDAV WG Meeting minutes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6431 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22DF0.CFED7754" ------_=_NextPart_001_01C22DF0.CFED7754 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Notes: WebDAV WG meeting=20 54th IETF in Yokohama Tuesday, 9:00 am =20 Most of the meeting is summarized in these slides used: http://www.webdav.org/wg/webdav-wg-yokohama.ppt Additional discussion & summary follows by topic. =20 Interop plans=20 We plan to hold an Interop meeting in September in Santa Cruz and make it an interim WG meeting as well. =20 ACL draft Status Meeting attendees agreed that ACL draft is stabilizing nicely. Changes from 08 are not controversial. There were no objections to the idea of publishing an 09 draft and taking that to IESG last call without another WG last call waiting period. If any objections arise, we will of course go through with another WG last call. =20 RFC2518bis status and issues=20 Most of the discussion here was a review of progress and open issues. Points of note: - It was pointed out that the IF header should be pared down to areas of actual use and interoperability to go to draft status. My take is that means removing the AND and NOT constructions. - It was pointed out that the source property may not be fixable and still go to draft status. Trying to add functionality like roles and still go to draft status may be incompatible goals.=20 - New milestone: promised to try to resolve another 6-12 issues in a new draft of RFC2518 bis within 2 months. =20 Lisa =20 =20 =20 =20 ------_=_NextPart_001_01C22DF0.CFED7754 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Notes: WebDAV WG meeting

54th IETF in Yokohama

Tuesday, 9:00 am

 

Most of the meeting is summarized in these slides = used: http://www.webda= v.org/wg/webdav-wg-yokohama.ppt

Additional discussion & summary follows by = topic.

 

Interop plans

We plan to hold an Interop meeting in September in = Santa = Cruz and make it an interim WG meeting as well.

 

ACL draft Status

Meeting attendees agreed that ACL draft is = stabilizing nicely. Changes from 08 are not controversial. There were no objections = to the idea of publishing an 09 draft and taking that to IESG last call without another WG last call waiting period. If any objections arise, we will of = course go through with another WG last call.

 

RFC2518bis status and issues

Most of the discussion here was a review of progress = and open issues. Points of note:

-        = ;  It was pointed out that the IF header should be pared down to = areas of actual use and interoperability to go to draft status. My take is that = means removing the AND and NOT constructions.

-        = ;  It was pointed out that the source property may not be fixable = and still go to draft status. Trying to add functionality like roles and still go = to draft status may be incompatible goals.

-        = ;  New milestone: promised to try to resolve another 6-12 issues in = a new draft of RFC2518 bis within 2 months.

 

Lisa

 

 

 

 

=00 ------_=_NextPart_001_01C22DF0.CFED7754-- --------------InterScan_NT_MIME_Boundary-- From w3c-dist-auth-request@w3.org Thu Jul 18 11:00:15 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04077 for ; Thu, 18 Jul 2002 11:00:14 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA01712; Thu, 18 Jul 2002 10:58:38 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6IEwMr13651; Thu, 18 Jul 2002 10:58:22 -0400 (EDT) Resent-Date: Thu, 18 Jul 2002 10:58:22 -0400 (EDT) Resent-Message-Id: <200207181458.g6IEwMr13651@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6IEwLw13628 for ; Thu, 18 Jul 2002 10:58:21 -0400 (EDT) Received: from mail.cruzio.com (root@mail.cruzio.com [63.249.95.37]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA01625 for ; Thu, 18 Jul 2002 10:58:20 -0400 Received: from Tycho (dsl3-63-249-68-7.cruzio.com [63.249.68.7]) by mail.cruzio.com with SMTP id HAA03620 for ; Thu, 18 Jul 2002 07:58:19 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Thu, 18 Jul 2002 07:56:36 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FW: [Moderator Action] problems with ie Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6432 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: David Kocher [mailto:kocher@nexplore.ch] Sent: Thursday, July 18, 2002 2:42 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] problems with ie hi all i'm trying to access with ie 6.0 to a webfolder (webdav server is IIS 5.0), but i recevied an error in the ie like "not enough memory to do this process" (alert message), when i'm trying to open the webfolder (with a "dhtml-link" or with "open as webfolder" option in ie). with the ie 5.0 i have the same problem and with 2 other computers (also installed ie 6.0) too. but on other computers the webfolder (same webfolder!) works! the memory is not the problem (256MB installed) and i think, the IE version (> 5.0) has nothing to do with the error. the "IIS webfolder" is in my opinion also correct. .....what can be the problem in the ie?? thanks for any answer! (and sorry for my "school-english" ;) best regards david From w3c-dist-auth-request@w3.org Fri Jul 19 01:40:50 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22130 for ; Fri, 19 Jul 2002 01:40:50 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA15788; Fri, 19 Jul 2002 01:40:21 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6J5eBs10117; Fri, 19 Jul 2002 01:40:11 -0400 (EDT) Resent-Date: Fri, 19 Jul 2002 01:40:11 -0400 (EDT) Resent-Message-Id: <200207190540.g6J5eBs10117@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6J5e9710097 for ; Fri, 19 Jul 2002 01:40:09 -0400 (EDT) Received: from mail.cruzio.com (root@mail.cruzio.com [63.249.95.37]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA15676 for ; Fri, 19 Jul 2002 01:40:09 -0400 Received: from Tycho (dsl3-63-249-68-7.cruzio.com [63.249.68.7]) by mail.cruzio.com with SMTP id WAA22742 for ; Thu, 18 Jul 2002 22:40:07 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Thu, 18 Jul 2002 22:38:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FW: [Moderator Action] Quick WebDAV Question for WebSphere Advisor Magazine Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6433 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Ellie_Macisaac@advisor.com [mailto:Ellie_Macisaac@advisor.com] Sent: Thursday, July 18, 2002 11:52 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Quick WebDAV Question for WebSphere Advisor Magazine Hi, I'm the managing editor of WebSphere Advisor Magazine, and I'm running an article on WebDAV in my September 2002 issue. I have one quick question for you: Have the versioning capabilities already been implemented in WebDAV? I've heard they're still in progress. Do you have any idea (ballpark figure is fine; i.e., end of 2002, Q1 2003) when the versioning capabilities will be established? Unfortunately, I'm on deadline, so your quick response is much appreciated. If you'd also like to send your address, I can be sure to mail you a few copies of the magazine when it hits the streets. Thank you in advance, Ellie Ellie MacIsaac Managing Editor WebSphere Advisor Magazine Advisor Media, Inc. 858-278-5600 ****************************************************** LOTUS ADVISOR DEVCON WEBSPHERE ADVISOR DEVCON September 8 - 12, 2002 Baltimore Marriott Waterfront, Baltimore, MD Attend 2 Developer Conferences for the price of 1! http://www.Advisor.com/DevCon ****************************************************** From w3c-dist-auth-request@w3.org Fri Jul 19 01:44:58 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22229 for ; Fri, 19 Jul 2002 01:44:58 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA16312; Fri, 19 Jul 2002 01:44:40 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6J5ied10613; Fri, 19 Jul 2002 01:44:40 -0400 (EDT) Resent-Date: Fri, 19 Jul 2002 01:44:40 -0400 (EDT) Resent-Message-Id: <200207190544.g6J5ied10613@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6J5id710590 for ; Fri, 19 Jul 2002 01:44:39 -0400 (EDT) Received: from mail.cruzio.com (root@mail.cruzio.com [63.249.95.37]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA16306 for ; Fri, 19 Jul 2002 01:44:38 -0400 Received: from Tycho (dsl3-63-249-68-7.cruzio.com [63.249.68.7]) by mail.cruzio.com with SMTP id WAA27461; Thu, 18 Jul 2002 22:44:36 -0700 (PDT) From: "Jim Whitehead" To: Cc: "WebDAV" Date: Thu, 18 Jul 2002 22:42:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Subject: RE: [Moderator Action] Quick WebDAV Question for WebSphere Advisor Magazine Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6434 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Ellie, The DeltaV protocol for versioning and configuration management is now finished, and has been released as RFC 3253. Several efforts are underway to implement this specification. One of the more public efforts is the Subversion project . Xythos has implemented parts of the DeltaV specification , and I think Merant might have as well . Sambar server states that they are in-progress with their DeltaV implementation . - Jim > -----Original Message----- > From: Ellie_Macisaac@advisor.com [mailto:Ellie_Macisaac@advisor.com] > Sent: Thursday, July 18, 2002 11:52 AM > To: w3c-dist-auth@w3.org > Subject: [Moderator Action] Quick WebDAV Question for WebSphere Advisor > Magazine > > > > > Hi, > > I'm the managing editor of WebSphere Advisor Magazine, and I'm running an > article on WebDAV in my September 2002 issue. I have one quick > question for > you: Have the versioning capabilities already been implemented in WebDAV? > I've heard they're still in progress. Do you have any idea > (ballpark figure > is fine; i.e., end of 2002, Q1 2003) when the versioning capabilities will > be established? > > Unfortunately, I'm on deadline, so your quick response is much > appreciated. > If you'd also like to send your address, I can be sure to mail you a few > copies of the magazine when it hits the streets. > > Thank you in advance, > Ellie > > Ellie MacIsaac > Managing Editor > WebSphere Advisor Magazine > Advisor Media, Inc. > 858-278-5600 > > ****************************************************** > LOTUS ADVISOR DEVCON > WEBSPHERE ADVISOR DEVCON > September 8 - 12, 2002 > Baltimore Marriott Waterfront, Baltimore, MD > Attend 2 Developer Conferences for the price of 1! > http://www.Advisor.com/DevCon > ****************************************************** > > > > From w3c-dist-auth-request@w3.org Fri Jul 19 02:28:45 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01681 for ; Fri, 19 Jul 2002 02:28:45 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA20829; Fri, 19 Jul 2002 02:27:11 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6J6RAk13246; Fri, 19 Jul 2002 02:27:10 -0400 (EDT) Resent-Date: Fri, 19 Jul 2002 02:27:10 -0400 (EDT) Resent-Message-Id: <200207190627.g6J6RAk13246@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6J6R9713226 for ; Fri, 19 Jul 2002 02:27:09 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id CAA20818 for ; Fri, 19 Jul 2002 02:27:08 -0400 Received: (qmail 30404 invoked by uid 0); 19 Jul 2002 06:26:37 -0000 Received: from p3ee2474d.dip.t-dialin.net (HELO lisa) (62.226.71.77) by mail.gmx.net (mp018-rz3) with SMTP; 19 Jul 2002 06:26:37 -0000 From: "Julian Reschke" To: "Jim Whitehead" , Cc: "WebDAV" Date: Fri, 19 Jul 2002 08:26:35 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: [Moderator Action] Quick WebDAV Question for WebSphere Advisor Magazine Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6435 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Friday, July 19, 2002 7:43 AM > To: Ellie_Macisaac@advisor.com > Cc: WebDAV > Subject: RE: [Moderator Action] Quick WebDAV Question for WebSphere > Advisor Magazine > > > > Hi Ellie, > > The DeltaV protocol for versioning and configuration management is now > finished, and has been released as RFC 3253. > > Several efforts are underway to implement this specification. One of the > more public efforts is the Subversion project > . Xythos has implemented parts of > the DeltaV > specification , and I think Merant might have as > well > . > Sambar server states that they are in-progress with their DeltaV > implementation . Linear simple versioning according to RFC3253 is also shippinh in SAP Portals Enterprise Portal Server 5.0. From w3c-dist-auth-request@w3.org Sat Jul 20 10:04:43 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10455 for ; Sat, 20 Jul 2002 10:04:43 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA10867; Sat, 20 Jul 2002 10:04:01 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6KE3lt19610; Sat, 20 Jul 2002 10:03:47 -0400 (EDT) Resent-Date: Sat, 20 Jul 2002 10:03:47 -0400 (EDT) Resent-Message-Id: <200207201403.g6KE3lt19610@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6KE3k719590 for ; Sat, 20 Jul 2002 10:03:46 -0400 (EDT) Received: from scamp.www.uk.easynet.net (scamp.www.uk.easynet.net [195.40.1.60]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA10855 for ; Sat, 20 Jul 2002 10:03:45 -0400 From: charlescook@ukonline.co.uk Received: from nobody by scamp.www.uk.easynet.net with local (Exim 3.35 #1) id 17Vupf-0009TC-00 for w3c-dist-auth@w3c.org; Sat, 20 Jul 2002 15:03:39 +0100 To: w3c-dist-auth@w3c.org Message-ID: <1027173819.3d396dbb21c12@webmail.ukonline.co.uk> Date: Sat, 20 Jul 2002 15:03:39 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.7 X-Originating-IP: 198.152.44.95 X-HTTP-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 Subject: Questions on Properties in RFC 2518 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6436 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi – one issue in RFC 2518 that puzzles me is property handling. Please bear with me if I’m missing something obvious in the document. The prop element is defined as: Therefore, when making a PROPFIND request with a propname element, how do I know how to parse the names returned in the response? Is the example in section 8.1.3 sufficient definition of this, such that I can always expect a sequence of elements, the name of each element being the name of a property of the resource? Section 13 states “For DAV properties, the name of the property is also the same as the name of the XML element that contains its value.” This implies that the value might be specified some other way, for example the name of a property might be returned like this by a PROPFIND request: but the value might be returned like this for some reason: 1234 If this is the case how is it possible to write client code which can handle properties in general, for example code which could be used to write a DAV browser which displayed the properties of resources on any DAV server the browser was pointed at? Even if you assume that the list of property names for a resource can be obtained as suggested by the example in 8.1.3, how do you then know how to associate the property values returned by a PROPFIND request with these names? (Because the format of each prop element in the allprop response is not known and so you do not know where to look for the property name in each child element of the prop element containing the values.) - Charles ------------------------------------------------- This mail sent through UK Online webmail From w3c-dist-auth-request@w3.org Sat Jul 20 10:21:20 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10632 for ; Sat, 20 Jul 2002 10:21:20 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA12651; Sat, 20 Jul 2002 10:21:01 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6KEKwm20634; Sat, 20 Jul 2002 10:20:58 -0400 (EDT) Resent-Date: Sat, 20 Jul 2002 10:20:58 -0400 (EDT) Resent-Message-Id: <200207201420.g6KEKwm20634@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6KEKv720614 for ; Sat, 20 Jul 2002 10:20:57 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA12630 for ; Sat, 20 Jul 2002 10:20:56 -0400 Received: (qmail 27074 invoked by uid 0); 20 Jul 2002 14:20:25 -0000 Received: from p3ee24714.dip.t-dialin.net (HELO lisa) (62.226.71.20) by mail.gmx.net (mp016-rz3) with SMTP; 20 Jul 2002 14:20:25 -0000 From: "Julian Reschke" To: , Date: Sat, 20 Jul 2002 16:20:35 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <1027173819.3d396dbb21c12@webmail.ukonline.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Questions on Properties in RFC 2518 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6437 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of > charlescook@ukonline.co.uk > Sent: Saturday, July 20, 2002 4:04 PM > To: w3c-dist-auth@w3c.org > Subject: Questions on Properties in RFC 2518 > > > > Hi – one issue in RFC 2518 that puzzles me is > property handling. Please bear with me if I’m > missing something obvious in the document. > > The prop element is defined as: > > > > Therefore, when making a PROPFIND request with a > propname element, how do I know how to parse the > names returned in the response? Is the example in > section 8.1.3 sufficient definition of this, such > that I can always expect a sequence of elements, > the name of each element being the name of a > property of the resource? Yes. > Section 13 states “For DAV properties, the name of > the property is also the same as the name of the > XML element that contains its value.” This implies > that the value might be specified some other way, > for example the name of a property might be > returned like this by a PROPFIND request: I think this is just a misunderstanding. All properties used within the WebDAV protocol are "DAV properties" (as discussed in this section) -- they aren't limited to those listed in that section. Maybe that should be clarified. > > > but the value might be returned like this for some > reason: > > 1234 No. That's a property with the name "integer" in the namespace "DAV:", while the earlier example described a property named "foo" (in the namespace "DAV:"). > If this is the case how is it possible to write It isn't. > client code which can handle properties in > general, for example code which could be used to > write a DAV browser which displayed the properties > of resources on any DAV server the browser was > pointed at? Even if you assume that the list of > property names for a resource can be obtained as > suggested by the example in 8.1.3, how do you then > know how to associate the property values returned > by a PROPFIND request with these names? (Because > the format of each prop element in the allprop > response is not known and so you do not know where > to look for the property name in each child > element of the prop element containing the values.) From w3c-dist-auth-request@w3.org Sat Jul 20 10:24:53 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10676 for ; Sat, 20 Jul 2002 10:24:53 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA13158; Sat, 20 Jul 2002 10:24:34 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6KEOXt20764; Sat, 20 Jul 2002 10:24:33 -0400 (EDT) Resent-Date: Sat, 20 Jul 2002 10:24:33 -0400 (EDT) Resent-Message-Id: <200207201424.g6KEOXt20764@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6KEOX720741 for ; Sat, 20 Jul 2002 10:24:33 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA13143 for ; Sat, 20 Jul 2002 10:24:33 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Sat, 20 Jul 2002 10:16:39 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <3VAHC7MB>; Sat, 20 Jul 2002 10:24:02 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1078EAE41@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Sat, 20 Jul 2002 10:24:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Questions on Properties in RFC 2518 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6438 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Yes, just follow the form of the example in 8.1.3. A DTD is far too weak to specify this kind of syntactic requirement (but was pretty much all that was standardized at the time RFC 2518 was issued). The text should have made this clear, rather than relying on the example (but this situation is simple enough that the example is probably sufficient). Cheers, Geoff -----Original Message----- From: charlescook@ukonline.co.uk [mailto:charlescook@ukonline.co.uk] Sent: Saturday, July 20, 2002 10:04 AM To: w3c-dist-auth@w3c.org Subject: Questions on Properties in RFC 2518 Hi - one issue in RFC 2518 that puzzles me is property handling. Please bear with me if I'm missing something obvious in the document. The prop element is defined as: Therefore, when making a PROPFIND request with a propname element, how do I know how to parse the names returned in the response? Is the example in section 8.1.3 sufficient definition of this, such that I can always expect a sequence of elements, the name of each element being the name of a property of the resource? Section 13 states "For DAV properties, the name of the property is also the same as the name of the XML element that contains its value." This implies that the value might be specified some other way, for example the name of a property might be returned like this by a PROPFIND request: but the value might be returned like this for some reason: 1234 If this is the case how is it possible to write client code which can handle properties in general, for example code which could be used to write a DAV browser which displayed the properties of resources on any DAV server the browser was pointed at? Even if you assume that the list of property names for a resource can be obtained as suggested by the example in 8.1.3, how do you then know how to associate the property values returned by a PROPFIND request with these names? (Because the format of each prop element in the allprop response is not known and so you do not know where to look for the property name in each child element of the prop element containing the values.) - Charles ------------------------------------------------- This mail sent through UK Online webmail From w3c-dist-auth-request@w3.org Mon Jul 22 12:27:27 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11942 for ; Mon, 22 Jul 2002 12:27:27 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA19550; Mon, 22 Jul 2002 12:26:38 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6MGQDA00097; Mon, 22 Jul 2002 12:26:13 -0400 (EDT) Resent-Date: Mon, 22 Jul 2002 12:26:13 -0400 (EDT) Resent-Message-Id: <200207221626.g6MGQDA00097@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6MGQB700077 for ; Mon, 22 Jul 2002 12:26:11 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA19453 for ; Mon, 22 Jul 2002 12:26:11 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6MGPYe8082388; Mon, 22 Jul 2002 12:25:34 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6MGPWO8073190; Mon, 22 Jul 2002 12:25:32 -0400 To: "Clemm, Geoff" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Mon, 22 Jul 2002 11:48:05 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_07122002 Pre-release 2|July 12, 2002) at 07/22/2002 12:25:31 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE16DDFC536F98f9e8a93df938690918c0ABBE16DDFC536F9" Content-Disposition: inline Subject: RE: New issue (?): locktoken (12.1.2) syntax Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6439 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE16DDFC536F98f9e8a93df938690918c0ABBE16DDFC536F9 Content-type: text/plain; charset=US-ASCII << I agree with Julian that it makes more sense to have each instance of a shared lock have its own timeout value and lockowner, so I also vote to limit the number of URI's for a given lock to be exactly one. >> I agree. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com --0__=0ABBE16DDFC536F98f9e8a93df938690918c0ABBE16DDFC536F9 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

<<
I agree with Julian that it makes more sense to have
each instance of a shared lock have its own timeout value
and lockowner, so I also vote to limit the number of
URI's for a given lock to be exactly one.
>>
I agree.


------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com
--0__=0ABBE16DDFC536F98f9e8a93df938690918c0ABBE16DDFC536F9-- From w3c-dist-auth-request@w3.org Mon Jul 22 14:32:09 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25756 for ; Mon, 22 Jul 2002 14:32:09 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA20153; Mon, 22 Jul 2002 14:31:43 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6MIVbi16201; Mon, 22 Jul 2002 14:31:37 -0400 (EDT) Resent-Date: Mon, 22 Jul 2002 14:31:37 -0400 (EDT) Resent-Message-Id: <200207221831.g6MIVbi16201@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6MIVa716181 for ; Mon, 22 Jul 2002 14:31:36 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA20138 for ; Mon, 22 Jul 2002 14:31:36 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g6MIUx021566 for ; Mon, 22 Jul 2002 11:31:03 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Mon, 22 Jul 2002 11:29:18 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: message board on webdav Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6440 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: moshea@hongkong.com [mailto:moshea@hongkong.com] Sent: Monday, July 22, 2002 7:00 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] message board on webdav Hi I would like to create a message board on my website which is hosting in Webdav. Is there any resources / technical supports I could find on regarding a message board on webdav so that I have a clearer idea in doing so? Thanks and I'm looking forward to your reply Moshea --------------------------------------------- Åwªï¨Ï¥ÎHongKong.com¶l¥ó¨t²Î Thank you for using hongkong.com Email system From w3c-dist-auth-request@w3.org Mon Jul 22 15:01:22 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28369 for ; Mon, 22 Jul 2002 15:01:22 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA27155; Mon, 22 Jul 2002 15:01:05 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6MJ0sZ18598; Mon, 22 Jul 2002 15:00:54 -0400 (EDT) Resent-Date: Mon, 22 Jul 2002 15:00:54 -0400 (EDT) Resent-Message-Id: <200207221900.g6MJ0sZ18598@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6MJ0s718578 for ; Mon, 22 Jul 2002 15:00:54 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA27096 for ; Mon, 22 Jul 2002 15:00:54 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6MJ06g5128928; Mon, 22 Jul 2002 15:00:08 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6MIxaSW053882; Mon, 22 Jul 2002 12:59:37 -0600 To: "Lisa Dusseault" Cc: "Webdav WG" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Mon, 22 Jul 2002 14:44:16 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_07122002 Pre-release 2|July 12, 2002) at 07/22/2002 15:00:03 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE16DDFF545278f9e8a93df938690918c0ABBE16DDFF54527" Content-Disposition: inline Subject: issue: REMOVE_ETAG_SUPPORT_FOR_IF_HEADER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6441 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE16DDFF545278f9e8a93df938690918c0ABBE16DDFF54527 Content-type: text/plain; charset=US-ASCII I'm going to mark the REMOVE_ETAG_SUPPORT_FOR_IF_HEADER issue as approved. Someone also mentioned that AND and OR support should also be removed since interop probably hasn't been proven. Who is using AND/OR support in IF headers? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com --0__=0ABBE16DDFF545278f9e8a93df938690918c0ABBE16DDFF54527 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I'm going to mark the REMOVE_ETAG_SUPPORT_FOR_IF_HEADER issue as approved.

Someone also mentioned that AND and OR support should also be removed since interop
probably hasn't been proven. Who is using AND/OR support in IF headers?

------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com
--0__=0ABBE16DDFF545278f9e8a93df938690918c0ABBE16DDFF54527-- From w3c-dist-auth-request@w3.org Mon Jul 22 16:22:09 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05650 for ; Mon, 22 Jul 2002 16:22:08 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA14940; Mon, 22 Jul 2002 16:21:27 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6MKLN127844; Mon, 22 Jul 2002 16:21:23 -0400 (EDT) Resent-Date: Mon, 22 Jul 2002 16:21:23 -0400 (EDT) Resent-Message-Id: <200207222021.g6MKLN127844@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6MKLM727818 for ; Mon, 22 Jul 2002 16:21:22 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA14889 for ; Mon, 22 Jul 2002 16:21:22 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6MKKpe8154116 for ; Mon, 22 Jul 2002 16:20:51 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6MKKmO8071538 for ; Mon, 22 Jul 2002 16:20:49 -0400 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Mon, 22 Jul 2002 16:03:42 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_07122002 Pre-release 2|July 12, 2002) at 07/22/2002 16:20:48 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE16DDFFEF53D8f9e8a93df938690918c0ABBE16DDFFEF53D" Content-Disposition: inline Subject: RE: New RFC2518bis draft, property values after LOCK of unmapped URL Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6442 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE16DDFFEF53D8f9e8a93df938690918c0ABBE16DDFFEF53D Content-type: text/plain; charset=US-ASCII << Section 4.2: Lock-null resources removed Text mentions: "SHOULD default to reasonable, or reasonably blank, values for other properties like getcontentlanguage" I disagree: unknown properties should be treated as not being present (just like the relevant HTTP headers), NOT as blank. >> If a server creates a resource as a result of a LOCK request on an unmapped URL, I believe Julian is suggesting that if there is any doubt about what the property value should be, the property should not be created rather than set to NULL. Julian, did I get that right? Would you care to elaborate? What about a few examples? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com --0__=0ABBE16DDFFEF53D8f9e8a93df938690918c0ABBE16DDFFEF53D Content-type: text/html; charset=US-ASCII Content-Disposition: inline

<<
Section 4.2: Lock-null resources removed

Text mentions: "SHOULD default to reasonable, or reasonably blank, values
for other properties like getcontentlanguage"

I disagree: unknown properties should be treated as not being present (just
like the relevant HTTP headers), NOT as blank.
>>

If a server creates a resource as a result of a LOCK request on an unmapped URL, I believe Julian is suggesting that if there is any doubt about what the property value should be, the property should not be created rather than set to NULL.

Julian, did I get that right? Would you care to elaborate? What about a few examples?

------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com
--0__=0ABBE16DDFFEF53D8f9e8a93df938690918c0ABBE16DDFFEF53D-- From w3c-dist-auth-request@w3.org Mon Jul 22 16:48:20 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07844 for ; Mon, 22 Jul 2002 16:48:20 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA20120; Mon, 22 Jul 2002 16:48:03 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6MKm2029583; Mon, 22 Jul 2002 16:48:02 -0400 (EDT) Resent-Date: Mon, 22 Jul 2002 16:48:02 -0400 (EDT) Resent-Message-Id: <200207222048.g6MKm2029583@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6MKm1729563 for ; Mon, 22 Jul 2002 16:48:01 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA20102 for ; Mon, 22 Jul 2002 16:48:00 -0400 Received: (qmail 8305 invoked by uid 0); 22 Jul 2002 20:47:29 -0000 Received: from p3ee24746.dip.t-dialin.net (HELO lisa) (62.226.71.70) by mail.gmx.net (mp017-rz3) with SMTP; 22 Jul 2002 20:47:29 -0000 From: "Julian Reschke" To: "Jason Crawford" , Date: Mon, 22 Jul 2002 22:47:28 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C231D1.C1B47430" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: New RFC2518bis draft, property values after LOCK of unmapped URL Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6443 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C231D1.C1B47430 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I think the standard WebDAV properties MUST reflect the values of the HTTP entity headers one would get upon HEAD or GET. So it doesn't make any sense to require that a value must be present, if it's purely optional in HTTP. For instance, if a server doesn't have a content-language for a resource, it MUST NOT report it upon GET (see [1]): "If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language it is intended.". So: if you don't have the language, don't report it. A blank value is an illegal language tag. [1] http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.12 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford Sent: Monday, July 22, 2002 10:04 PM To: w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, property values after LOCK of unmapped URL << Section 4.2: Lock-null resources removed Text mentions: "SHOULD default to reasonable, or reasonably blank, values for other properties like getcontentlanguage" I disagree: unknown properties should be treated as not being present (just like the relevant HTTP headers), NOT as blank. >> If a server creates a resource as a result of a LOCK request on an unmapped URL, I believe Julian is suggesting that if there is any doubt about what the property value should be, the property should not be created rather than set to NULL. Julian, did I get that right? Would you care to elaborate? What about a few examples? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com ------=_NextPart_000_000B_01C231D1.C1B47430 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I=20 think the standard WebDAV properties MUST reflect the values of the HTTP = entity=20 headers one would get upon HEAD or GET. So it doesn't make any = sense to=20 require that a value must be present, if it's purely optional in=20 HTTP.
 
For=20 instance, if a server doesn't have a content-language for a resource, it = MUST=20 NOT report it upon GET (see [1]): "If no = Content-Language is=20 specified, the default is that the content is intended for all language=20 audiences. This might mean that the sender does not consider it to be = specific=20 to any natural language, or that the sender does not know for which = language it=20 is intended.". So: if you don't have the language, don't report it. A = blank=20 value is an illegal language tag.
 
[1] = http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.12
-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason=20 Crawford
Sent: Monday, July 22, 2002 10:04 PM
To:=20 w3c-dist-auth@w3c.org
Subject: RE: New RFC2518bis draft, = property=20 values after LOCK of unmapped URL

<<
Section 4.2: Lock-null resources removed

Text = mentions: "SHOULD=20 default to reasonable, or reasonably blank, values
for other = properties=20 like getcontentlanguage"

I disagree: unknown properties should = be=20 treated as not being present (just
like the relevant HTTP headers), = NOT as=20 blank.
>>

If a server creates a resource as a = result of=20 a LOCK request on an unmapped URL, I believe Julian is suggesting that = if=20 there is any doubt about what the property value should be, the = property=20 should not be created rather than set to NULL.

Julian, did I = get that=20 right? Would you care to elaborate? What about a few=20 examples?

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

------=_NextPart_000_000B_01C231D1.C1B47430-- From w3c-dist-auth-request@w3.org Tue Jul 23 18:01:51 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05615 for ; Tue, 23 Jul 2002 18:01:51 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA04879; Tue, 23 Jul 2002 18:00:27 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6NM02J01492; Tue, 23 Jul 2002 18:00:02 -0400 (EDT) Resent-Date: Tue, 23 Jul 2002 18:00:02 -0400 (EDT) Resent-Message-Id: <200207232200.g6NM02J01492@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6NM01701468 for ; Tue, 23 Jul 2002 18:00:01 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA04778 for ; Tue, 23 Jul 2002 18:00:01 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 23 Jul 2002 17:59:30 -0400 (Eastern Daylight Time) Received: from ATL1VEXC006.usdom004.tco.tc ([209.225.56.53]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 23 Jul 2002 17:59:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Jul 2002 17:59:29 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA601736D89A@ATL1VEXC006.usdom004.tco.tc> Thread-Topic: RE: New RFC2518bis draft, COPY / MOVE of live properities Thread-Index: AcIylEJ6kdqxgz9aQUmtIUWJwRJNzA== From: "Lisa Dusseault" To: X-OriginalArrivalTime: 23 Jul 2002 21:59:30.0152 (UTC) FILETIME=[38563E80:01C23294] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g6NM01701468 Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6444 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit If a MOVE operation MAY fail when live properties can't be continued as live properties at the destination, what should we say about when the server can allow the MOVE and when it can't? Is it entirely up to the server or should we make a recommendation? Then, if the server does fail, what error code should be returned? Lisa From w3c-dist-auth-request@w3.org Tue Jul 23 18:07:01 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05714 for ; Tue, 23 Jul 2002 18:07:01 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA05905; Tue, 23 Jul 2002 18:05:52 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6NM5ps01964; Tue, 23 Jul 2002 18:05:51 -0400 (EDT) Resent-Date: Tue, 23 Jul 2002 18:05:51 -0400 (EDT) Resent-Message-Id: <200207232205.g6NM5ps01964@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6NM5o701944 for ; Tue, 23 Jul 2002 18:05:51 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA05889 for ; Tue, 23 Jul 2002 18:05:50 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 23 Jul 2002 18:05:08 -0400 (Eastern Daylight Time) Received: from ATL1VEXC006.usdom004.tco.tc ([10.158.7.208]) by atl1simr002.tco.tc with Microsoft SMTPSVC(5.0.2195.2966); Tue, 23 Jul 2002 18:05:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Tue, 23 Jul 2002 18:05:08 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA6017371BBC@ATL1VEXC006.usdom004.tco.tc> Thread-Topic: New RFC2518bis draft, property values after LOCK of unmapped URL Thread-Index: AcIxwnAmVsTzt+uBT6q8j52B3qU/LQA0dtNg From: "Lisa Dusseault" To: "Julian Reschke" , "Jason Crawford" , X-OriginalArrivalTime: 23 Jul 2002 22:05:08.0407 (UTC) FILETIME=[01F3DC70:01C23295] Subject: RE: New RFC2518bis draft, property values after LOCK of unmapped URL Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6445 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23295.01C6A9F7" ------_=_NextPart_001_01C23295.01C6A9F7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What are other people's views on this? Should live properties for which the server doesn't have an easy value be left blank or should the property not exist? =20 My reasoning was that live properties like "getcontentlanguage" should be required, thus should exist on every WebDAV resource, even if the value must be blank. Otherwise a server can completely omit these properties and still claim compliance. =20 (Side note: If required live properties like "getcontentlanguage" can be missing on a WebDAV resource, then we need to clarify under what conditions they may be missing. I'm thinking along these lines: "If the latest client PUT request contains a Content-Language header, the value of this header MUST be preserved in the getcontentlanguage property value. If the Content-Language header is never provided, then the server MAY omit this property, or it MAY calculate a value or choose a reasonable default value.") =20 Lisa =20 -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Monday, July 22, 2002 1:47 PM To: Jason Crawford; w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, property values after LOCK of unmapped URL =20 I think the standard WebDAV properties MUST reflect the values of the HTTP entity headers one would get upon HEAD or GET. So it doesn't make any sense to require that a value must be present, if it's purely optional in HTTP. =20 For instance, if a server doesn't have a content-language for a resource, it MUST NOT report it upon GET (see [1]): "If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language it is intended.". So: if you don't have the language, don't report it. A blank value is an illegal language tag. =20 [1] http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.12 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford Sent: Monday, July 22, 2002 10:04 PM To: w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, property values after LOCK of unmapped URL << Section 4.2: Lock-null resources removed =09 Text mentions: "SHOULD default to reasonable, or reasonably blank, values for other properties like getcontentlanguage" =09 I disagree: unknown properties should be treated as not being present (just like the relevant HTTP headers), NOT as blank. >> =09 If a server creates a resource as a result of a LOCK request on an unmapped URL, I believe Julian is suggesting that if there is any doubt about what the property value should be, the property should not be created rather than set to NULL. =09 Julian, did I get that right? Would you care to elaborate? What about a few examples? =09 ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com ------_=_NextPart_001_01C23295.01C6A9F7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What are other people’s views = on this? Should live properties for which the server doesn’t have an = easy value be left blank or should the property not exist?

 

My reasoning was that live = properties like “getcontentlanguage” should be required, thus should exist = on every WebDAV resource, even if the value must be blank. Otherwise a server can completely omit these properties and still claim = compliance.

 

(Side note: If required live = properties like “getcontentlanguage” can be missing on a WebDAV resource, = then we need to clarify under what conditions they may be missing.  = I’m thinking along these lines: “If the latest client PUT request = contains a Content-Language header, the value of this header MUST be preserved in = the getcontentlanguage property value. If the Content-Language header is never provided, then = the server MAY omit this property, or it MAY calculate a value or choose a reasonable default value.”)

 

Lisa

 

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Monday, July 22, = 2002 1:47 PM
To: Jason Crawford; w3c-dist-auth@w3c.org
Subject: RE: New = RFC2518bis draft, property values after LOCK of unmapped URL

 

I think the standard WebDAV = properties MUST reflect the values of the HTTP entity headers one would get = upon HEAD or GET. So it doesn't make any sense to require that a value must be = present, if it's purely optional in HTTP.

 

For instance, if a server doesn't = have a content-language for a resource, it MUST NOT report it upon GET (see = [1]): "If no Content-Language is = specified, the default is that the content is intended for all language audiences. This = might mean that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language it is intended.". So: if you don't have the language, don't report it. A = blank value is an illegal language tag.

 

-----Original = Message-----
From: = w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford
Sent: Monday, July 22, = 2002 10:04 PM
To: = w3c-dist-auth@w3c.org
Subject: RE: New = RFC2518bis draft, property values after LOCK of unmapped URL

<<
Section 4.2: Lock-null resources removed

Text mentions: "SHOULD default to reasonable, or reasonably blank, = values
for other properties like getcontentlanguage"

I disagree: unknown properties should be treated as not being present = (just
like the relevant HTTP headers), NOT as blank.
>>

If a server creates a resource as a result of a LOCK request on an = unmapped URL, I believe Julian is suggesting that if there is any doubt about = what the property value should be, the property should not be created rather than = set to NULL.

Julian, did I get that right? Would you care to elaborate? What about a = few examples?

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

=00 ------_=_NextPart_001_01C23295.01C6A9F7-- --------------InterScan_NT_MIME_Boundary-- From w3c-dist-auth-request@w3.org Tue Jul 23 18:26:07 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06160 for ; Tue, 23 Jul 2002 18:26:07 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA09452; Tue, 23 Jul 2002 18:24:54 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6NMOrm03048; Tue, 23 Jul 2002 18:24:53 -0400 (EDT) Resent-Date: Tue, 23 Jul 2002 18:24:53 -0400 (EDT) Resent-Message-Id: <200207232224.g6NMOrm03048@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6NMOr703028 for ; Tue, 23 Jul 2002 18:24:53 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA09442 for ; Tue, 23 Jul 2002 18:24:52 -0400 Received: (qmail 15555 invoked by uid 0); 23 Jul 2002 22:24:20 -0000 Received: from pd950c3f3.dip.t-dialin.net (HELO lisa) (217.80.195.243) by mail.gmx.net (mp009-rz3) with SMTP; 23 Jul 2002 22:24:20 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "Julian Reschke" , "Jason Crawford" , Date: Wed, 24 Jul 2002 00:24:17 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C232A8.72389300" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <27889B08CAEC7049B68FAD8717BA6017371BBC@ATL1VEXC006.usdom004.tco.tc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: New RFC2518bis draft, property values after LOCK of unmapped URL Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6446 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C232A8.72389300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Lisa, I think we should just re-state that the DAV: get* properties reflect the values of the HTTP entity headers. They may be present or not. If they are present, they MUST conform to the definitions in RFC2616, in particular, they MUST NOT be blank. It doesn't make sense to require PROPFIND to return something different from GET/HEAD. If the server doesn't know the content language, that's it. Nobody is served by somebody trying to come up with a "default". Guess what: the Microsoft Webfolder client PUTs all files with a content language header of "en_US" - even on a german Windows installation. That's a bug, not a feature. Julian -----Original Message----- From: Lisa Dusseault [mailto:ldusseault@xythos.com] Sent: Wednesday, July 24, 2002 12:05 AM To: Julian Reschke; Jason Crawford; w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, property values after LOCK of unmapped URL What are other people's views on this? Should live properties for which the server doesn't have an easy value be left blank or should the property not exist? My reasoning was that live properties like "getcontentlanguage" should be required, thus should exist on every WebDAV resource, even if the value must be blank. Otherwise a server can completely omit these properties and still claim compliance. (Side note: If required live properties like "getcontentlanguage" can be missing on a WebDAV resource, then we need to clarify under what conditions they may be missing. I'm thinking along these lines: "If the latest client PUT request contains a Content-Language header, the value of this header MUST be preserved in the getcontentlanguage property value. If the Content-Language header is never provided, then the server MAY omit this property, or it MAY calculate a value or choose a reasonable default value.") Lisa -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, July 22, 2002 1:47 PM To: Jason Crawford; w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, property values after LOCK of unmapped URL I think the standard WebDAV properties MUST reflect the values of the HTTP entity headers one would get upon HEAD or GET. So it doesn't make any sense to require that a value must be present, if it's purely optional in HTTP. For instance, if a server doesn't have a content-language for a resource, it MUST NOT report it upon GET (see [1]): "If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language it is intended.". So: if you don't have the language, don't report it. A blank value is an illegal language tag. [1] http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.12 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford Sent: Monday, July 22, 2002 10:04 PM To: w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, property values after LOCK of unmapped URL << Section 4.2: Lock-null resources removed Text mentions: "SHOULD default to reasonable, or reasonably blank, values for other properties like getcontentlanguage" I disagree: unknown properties should be treated as not being present (just like the relevant HTTP headers), NOT as blank. >> If a server creates a resource as a result of a LOCK request on an unmapped URL, I believe Julian is suggesting that if there is any doubt about what the property value should be, the property should not be created rather than set to NULL. Julian, did I get that right? Would you care to elaborate? What about a few examples? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com ------=_NextPart_000_0007_01C232A8.72389300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Lisa,
 
I=20 think we should just re-state that the DAV: get* properties reflect the = values=20 of the HTTP entity headers. They may be present or not. If they are = present,=20 they MUST conform to the definitions in RFC2616, in particular, they = MUST NOT be=20 blank.
 
It=20 doesn't make sense to require PROPFIND to return something different = from=20 GET/HEAD. If the server doesn't know the content language, that's it. = Nobody is=20 served by somebody trying to come up with a = "default".
 
Guess=20 what: the Microsoft Webfolder client PUTs all files with a content = language=20 header of "en_US" - even on a german Windows installation. That's a bug, = not a=20 feature.
 
Julian
-----Original Message-----
From: Lisa Dusseault=20 [mailto:ldusseault@xythos.com]
Sent: Wednesday, July 24, = 2002 12:05=20 AM
To: Julian Reschke; Jason Crawford;=20 w3c-dist-auth@w3c.org
Subject: RE: New RFC2518bis draft, = property=20 values after LOCK of unmapped URL

What are = other=20 people’s views on this? Should live properties for which the = server doesn’t=20 have an easy value be left blank or should the property not=20 exist?

 

My = reasoning was that=20 live properties like “getcontentlanguage” should be = required, thus should=20 exist on every WebDAV resource, even if the value must be blank. = Otherwise a=20 server can completely omit these properties and still claim=20 compliance.

 

(Side note: = If=20 required live properties like “getcontentlanguage” can be = missing on a WebDAV=20 resource, then we need to clarify under what conditions they may be=20 missing.  I’m thinking along these lines: “If the = latest client PUT=20 request contains a Content-Language header, the value of this header = MUST be=20 preserved in the getcontentlanguage property value. If the = Content-Language=20 header is never provided, then the server MAY omit this property, or = it MAY=20 calculate a value or choose a reasonable default = value.”)

 

Lisa

 

-----Original=20 Message-----
From: = Julian=20 Reschke [mailto:julian.reschke@gmx.de]
Sent: Monday, July 22, 2002 = 1:47=20 PM
To: Jason = Crawford;=20 w3c-dist-auth@w3c.org
Subject: RE: New RFC2518bis = draft,=20 property values after LOCK of unmapped URL

 

I think the = standard=20 WebDAV properties MUST reflect the values of the HTTP entity = headers one=20 would get upon HEAD or GET. So it doesn't make any sense to require = that a=20 value must be present, if it's purely optional in=20 HTTP.

 

For = instance, if a=20 server doesn't have a content-language for a resource, it MUST NOT = report it=20 upon GET (see [1]): "If no=20 Content-Language is specified, the default is that the content is = intended for=20 all language audiences. This might mean that the sender does not = consider it=20 to be specific to any natural language, or that the sender does not = know for=20 which language it is intended.". So: if you don't have the language, = don't=20 report it. A blank value is an illegal language = tag.

 

[1] = http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.12

-----Original=20 Message-----
From:=20 w3c-dist-auth-request@w3.org = [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason = Crawford
Sent: Monday, July 22, 2002 = 10:04=20 PM
To:=20 w3c-dist-auth@w3c.org
Subject: RE: New RFC2518bis = draft,=20 property values after LOCK of unmapped URL

<<
Section 4.2: = Lock-null=20 resources removed

Text mentions: "SHOULD default to = reasonable, or=20 reasonably blank, values
for other properties like=20 getcontentlanguage"

I disagree: unknown properties should be = treated=20 as not being present (just
like the relevant HTTP headers), NOT = as=20 blank.
>>

If a server creates a = resource as a=20 result of a LOCK request on an unmapped URL, I believe Julian is = suggesting=20 that if there is any doubt about what the property value should be, = the=20 property should not be created rather than set to = NULL.

Julian, did I=20 get that right? Would you care to elaborate? What about a few=20 = examples?

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

------=_NextPart_000_0007_01C232A8.72389300-- From w3c-dist-auth-request@w3.org Tue Jul 23 20:10:08 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08103 for ; Tue, 23 Jul 2002 20:10:08 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA29685; Tue, 23 Jul 2002 20:09:33 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6O09Vj09358; Tue, 23 Jul 2002 20:09:31 -0400 (EDT) Resent-Date: Tue, 23 Jul 2002 20:09:31 -0400 (EDT) Resent-Message-Id: <200207240009.g6O09Vj09358@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6O09U709338 for ; Tue, 23 Jul 2002 20:09:30 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id UAA29680 for ; Tue, 23 Jul 2002 20:09:30 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 23 Jul 2002 20:08:53 -0400 (Eastern Daylight Time) Received: from ATL1VEXC006.usdom004.tco.tc ([209.225.56.53]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 23 Jul 2002 20:08:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Jul 2002 20:08:52 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA6017371BBE@ATL1VEXC006.usdom004.tco.tc> Thread-Topic: If header simplification Thread-Index: AcIyplTrMlS3IjsrQcSmH3AZDiCDBQ== From: "Lisa Dusseault" To: X-OriginalArrivalTime: 24 Jul 2002 00:08:52.0533 (UTC) FILETIME=[4B139650:01C232A6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g6O09U709338 Subject: If header simplification Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6447 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit The If header has more features than have been used in shipping clients, I believe. To move from Draft Standard to Proposed, we have to pare down the If header definition to those features for which interoperability has been shown. We need to know exactly what features clients are using: - NOT production? - ETags (I think this has already been discussed) - Multiple tagged lists per header? (AND) - Multiple tokens/tags per list? (OR) I propose the following rough text for the If header, assuming that none of the features above are being used by clients in real usage scenarios (not including Litmus or other test suites). It is intended to be a minimalist (KISS) approach to rewriting section 9.4. The text defines the If header in a backward-compatible way: any client following the definition below will send a subset of the syntax that any server implementing RFC2518 will support. Any server implementing the definition below will work with existing clients as far as I know. ----- 9.4 If Header If = "If" ":" ( 1*No-tag-list | 1*Tagged-list) No-tag-list = List Tagged-list = Resource 1*List Resource = Coded-URL List = "(" 1*State-token ")" State-token = Coded-URL Coded-URL = "<" absoluteURI ">" The If header was intended to have similar functionality to the If- Match header defined in section 14.25 of [RFC2068]. However the If header is intended for use with any URI (state token) which represents state information about a resource. A typical example of a state token is a lock token, and lock tokens are the only state tokens defined in this specification. All DAV compliant resources MUST honor the If header. The If header's purpose is to describe a series of state lists. If the state of the resource to which the header is applied does not match any of the specified state lists then the request MUST fail with a 412 (Precondition Failed). If one of the described state lists matches the state of the resource then the request may succeed. Note that the absoluteURI production is defined in [RFC2396]. 9.4.1 No-tag-list Production The No-tag-list production describes a series of state tokens. If multiple No-tag-list productions are used then one only needs to match the state of the resource for the method to be allowed to continue. If a method, due to the presence of a Depth or Destination header, is applied to multiple resources then the No-tag-list production MUST be applied to each resource the method is applied to. 9.4.1.1 Example - No-tag-list with "or" If: () () The previous header would require that any resources within the scope of the method must be locked with one or both of the lock tokens. 9.4.2 Tagged-list Production The tagged-list production scopes a list production. That is, it specifies that the lists following the resource specification only apply to the specified resource. The scope of the resource production begins with the list production immediately following the resource production and ends with the next resource production, if any. When the If header is applied to a particular resource, the Tagged- list productions MUST be searched to determine if any of the listed resources match the operand resource(s) for the current method. If none of the resource productions match the current resource then the header MUST be ignored. If one of the resource productions does match the name of the resource under consideration then the list productions following the resource production MUST be applied to the resource in the manner specified in the previous section. The same URI MUST NOT appear more than once in a resource production in an If header. 9.4.2.1 Example - Tagged List If header COPY /resource1 HTTP/1.1 Host: www.foo.bar Destination: http://www.foo.bar/resource2 If: () () In this example http://www.foo.bar/resource1 is being copied to http://www.foo.bar/resource2. When the method is first applied to http://www.foo.bar/resource1, resource1 must be in the state specified by "()", that is, it must be locked with a lock token of "locktoken:a-write-lock-token". That is the only success condition since the resource http://www.bar.bar/random never has the method applied to it (the only other resource listed in the If header) and http://www.foo.bar/resource2 is not listed in the If header. 9.4.4 Matching Function When performing If header processing, the definition of a matching state token or entity tag is as follows. Matching state token: Where there is an exact match between the state token in the If header and any state token on the resource. 9.4.5 If Header and Non-DAV Compliant Proxies Non-DAV compliant proxies will not honor the If header, since they will not understand the If header, and HTTP requires non-understood headers to be ignored. When communicating with HTTP/1.1 proxies, the "Cache-Control: no-cache" request header MUST be used so as to prevent the proxy from improperly trying to service the request from its cache. When dealing with HTTP/1.0 proxies the "Pragma: no- cache" request header MUST be used for the same reason. From w3c-dist-auth-request@w3.org Wed Jul 24 00:10:01 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13683 for ; Wed, 24 Jul 2002 00:10:01 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA26453; Wed, 24 Jul 2002 00:09:32 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6O49T719919; Wed, 24 Jul 2002 00:09:29 -0400 (EDT) Resent-Date: Wed, 24 Jul 2002 00:09:29 -0400 (EDT) Resent-Message-Id: <200207240409.g6O49T719919@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6O49R719895 for ; Wed, 24 Jul 2002 00:09:27 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA26428 for ; Wed, 24 Jul 2002 00:09:27 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6O48tg5215664; Wed, 24 Jul 2002 00:08:55 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6O48t1f018138; Wed, 24 Jul 2002 00:08:55 -0400 To: "Julian Reschke" Cc: "Julian Reschke" , "Lisa Dusseault" , w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Tue, 23 Jul 2002 23:16:11 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_07122002 Pre-release 2|July 12, 2002) at 07/24/2002 00:08:55 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE693DF9F69048f9e8a93df938690918c0ABBE693DF9F6904" Content-Disposition: inline Subject: RE: New RFC2518bis draft, property values after LOCK of unmapped URL Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6448 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE693DF9F69048f9e8a93df938690918c0ABBE693DF9F6904 Content-type: text/plain; charset=US-ASCII Although I don't have a strong opinion on this, a quick first impression is that for getXXXXX properties, if the GET request will not list the header, it probably should be missing. And if the GET response will list it, the property should be there. And if the GET response lists the value as blank, then that's the value that the corresponding property should list. With that in mind, I'd suggest the wording that Julian originally questioned also list the possibility of the property not existing. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com --0__=0ABBE693DF9F69048f9e8a93df938690918c0ABBE693DF9F6904 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Although I don't have a strong opinion on this, a quick first impression is that for getXXXXX properties, if the GET request will not list the header, it probably should be missing. And if the GET response will list it, the property should be there. And if the GET response lists the value as blank, then that's the value that the corresponding property should list.

With that in mind, I'd suggest the wording that Julian originally questioned also list the possibility of the property not existing.

J.


------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com
--0__=0ABBE693DF9F69048f9e8a93df938690918c0ABBE693DF9F6904-- From w3c-dist-auth-request@w3.org Wed Jul 24 08:24:19 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07093 for ; Wed, 24 Jul 2002 08:24:19 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA11550; Wed, 24 Jul 2002 02:46:56 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6O6ktc29303; Wed, 24 Jul 2002 02:46:55 -0400 (EDT) Resent-Date: Wed, 24 Jul 2002 02:46:55 -0400 (EDT) Resent-Message-Id: <200207240646.g6O6ktc29303@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6O6ks729283 for ; Wed, 24 Jul 2002 02:46:54 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id CAA11533 for ; Wed, 24 Jul 2002 02:46:53 -0400 Received: (qmail 21710 invoked by uid 0); 24 Jul 2002 06:46:22 -0000 Received: from p3ee24728.dip.t-dialin.net (HELO lisa) (62.226.71.40) by mail.gmx.net (mp014-rz3) with SMTP; 24 Jul 2002 06:46:22 -0000 From: "Julian Reschke" To: "Jason Crawford" , Date: Wed, 24 Jul 2002 08:46:20 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C232EE.9522B440" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Subject: RE: New RFC2518bis draft, property values after LOCK of unmapped URL Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6449 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C232EE.9522B440 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Jason, I agree. Note that one of the entity headers to be present but empty is not very likely (because that would be a RFC2616-conformance bug). -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford Sent: Wednesday, July 24, 2002 5:16 AM To: Julian Reschke Cc: Julian Reschke; Lisa Dusseault; w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, property values after LOCK of unmapped URL Although I don't have a strong opinion on this, a quick first impression is that for getXXXXX properties, if the GET request will not list the header, it probably should be missing. And if the GET response will list it, the property should be there. And if the GET response lists the value as blank, then that's the value that the corresponding property should list. With that in mind, I'd suggest the wording that Julian originally questioned also list the possibility of the property not existing. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com ------=_NextPart_000_0006_01C232EE.9522B440 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Jason,
 
I=20 agree. Note that one of the entity headers to be present but empty is = not very=20 likely (because that would be a RFC2616-conformance = bug).
 
 
-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason=20 Crawford
Sent: Wednesday, July 24, 2002 5:16 = AM
To: Julian=20 Reschke
Cc: Julian Reschke; Lisa Dusseault;=20 w3c-dist-auth@w3c.org
Subject: RE: New RFC2518bis draft, = property=20 values after LOCK of unmapped URL

Although I don't have a strong opinion on this, a quick first = impression is=20 that for getXXXXX properties, if the GET request will not list the = header, it=20 probably should be missing. And if the GET response will list it, the = property=20 should be there. And if the GET response lists the value as blank, = then that's=20 the value that the corresponding property should list.

With = that in=20 mind, I'd suggest the wording that Julian originally questioned also = list the=20 possibility of the property not=20 = existing.

J.


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

------=_NextPart_000_0006_01C232EE.9522B440-- From w3c-dist-auth-request@w3.org Wed Jul 24 08:30:18 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08734 for ; Wed, 24 Jul 2002 08:30:18 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA25189; Wed, 24 Jul 2002 08:30:01 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6OCTw421100; Wed, 24 Jul 2002 08:29:58 -0400 (EDT) Resent-Date: Wed, 24 Jul 2002 08:29:58 -0400 (EDT) Resent-Message-Id: <200207241229.g6OCTw421100@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6OCTt721079 for ; Wed, 24 Jul 2002 08:29:55 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA25156 for ; Wed, 24 Jul 2002 08:29:53 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Wed, 24 Jul 2002 08:21:47 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <3VAHHVDV>; Wed, 24 Jul 2002 08:29:20 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1078EB599@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Wed, 24 Jul 2002 08:29:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: New RFC2518bis draft, property values after LOCK of unmapped URL Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6450 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree with Julian. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Tuesday, July 23, 2002 6:24 PM To: Lisa Dusseault; Julian Reschke; Jason Crawford; w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, property values after LOCK of unmapped URL Lisa, I think we should just re-state that the DAV: get* properties reflect the values of the HTTP entity headers. They may be present or not. If they are present, they MUST conform to the definitions in RFC2616, in particular, they MUST NOT be blank. It doesn't make sense to require PROPFIND to return something different from GET/HEAD. If the server doesn't know the content language, that's it. Nobody is served by somebody trying to come up with a "default". Guess what: the Microsoft Webfolder client PUTs all files with a content language header of "en_US" - even on a german Windows installation. That's a bug, not a feature. Julian -----Original Message----- From: Lisa Dusseault [mailto:ldusseault@xythos.com] Sent: Wednesday, July 24, 2002 12:05 AM To: Julian Reschke; Jason Crawford; w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, property values after LOCK of unmapped URL What are other people's views on this? Should live properties for which the server doesn't have an easy value be left blank or should the property not exist? My reasoning was that live properties like "getcontentlanguage" should be required, thus should exist on every WebDAV resource, even if the value must be blank. Otherwise a server can completely omit these properties and still claim compliance. (Side note: If required live properties like "getcontentlanguage" can be missing on a WebDAV resource, then we need to clarify under what conditions they may be missing. I'm thinking along these lines: "If the latest client PUT request contains a Content-Language header, the value of this header MUST be preserved in the getcontentlanguage property value. If the Content-Language header is never provided, then the server MAY omit this property, or it MAY calculate a value or choose a reasonable default value.") Lisa -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, July 22, 2002 1:47 PM To: Jason Crawford; w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, property values after LOCK of unmapped URL I think the standard WebDAV properties MUST reflect the values of the HTTP entity headers one would get upon HEAD or GET. So it doesn't make any sense to require that a value must be present, if it's purely optional in HTTP. For instance, if a server doesn't have a content-language for a resource, it MUST NOT report it upon GET (see [1]): "If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language it is intended.". So: if you don't have the language, don't report it. A blank value is an illegal language tag. [1] http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.12 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford Sent: Monday, July 22, 2002 10:04 PM To: w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, property values after LOCK of unmapped URL << Section 4.2: Lock-null resources removed Text mentions: "SHOULD default to reasonable, or reasonably blank, values for other properties like getcontentlanguage" I disagree: unknown properties should be treated as not being present (just like the relevant HTTP headers), NOT as blank. >> If a server creates a resource as a result of a LOCK request on an unmapped URL, I believe Julian is suggesting that if there is any doubt about what the property value should be, the property should not be created rather than set to NULL. Julian, did I get that right? Would you care to elaborate? What about a few examples? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Jul 24 08:36:07 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10110 for ; Wed, 24 Jul 2002 08:36:07 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA27089; Wed, 24 Jul 2002 08:35:55 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6OCZt122160; Wed, 24 Jul 2002 08:35:55 -0400 (EDT) Resent-Date: Wed, 24 Jul 2002 08:35:55 -0400 (EDT) Resent-Message-Id: <200207241235.g6OCZt122160@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6OCZr722140 for ; Wed, 24 Jul 2002 08:35:53 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA27075 for ; Wed, 24 Jul 2002 08:35:52 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Wed, 24 Jul 2002 08:27:48 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <3VAHHVK3>; Wed, 24 Jul 2002 08:35:21 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1078EB59F@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Wed, 24 Jul 2002 08:35:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6451 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I don't quite understand the first part of the question. If we say that the live properties must continue live at the destination, what more do we need to say? (I.e. what situation is left ambiguous?). For the second part, a 403 (Forbidden) seems right to me. Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:ldusseault@xythos.com] Sent: Tuesday, July 23, 2002 5:59 PM To: w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities If a MOVE operation MAY fail when live properties can't be continued as live properties at the destination, what should we say about when the server can allow the MOVE and when it can't? Is it entirely up to the server or should we make a recommendation? Then, if the server does fail, what error code should be returned? Lisa From w3c-dist-auth-request@w3.org Wed Jul 24 10:22:24 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18526 for ; Wed, 24 Jul 2002 10:22:24 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA21857; Wed, 24 Jul 2002 10:21:50 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6OELng11660; Wed, 24 Jul 2002 10:21:49 -0400 (EDT) Resent-Date: Wed, 24 Jul 2002 10:21:49 -0400 (EDT) Resent-Message-Id: <200207241421.g6OELng11660@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6OELm711636 for ; Wed, 24 Jul 2002 10:21:48 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA21845 for ; Wed, 24 Jul 2002 10:21:47 -0400 Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Wed, 24 Jul 2002 16:21:04 +0200 Date: Wed, 24 Jul 2002 16:21:03 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: To: "Lisa Dusseault" From: Stefan Eissing In-Reply-To: <27889B08CAEC7049B68FAD8717BA6017371BBE@ATL1VEXC006.usdom004.tco.tc> Message-Id: <95C38786-9F10-11D6-8939-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: Re: If header simplification Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6452 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Speaking for my client code: Am Mittwoch den, 24. Juli 2002, um 02:08, schrieb Lisa Dusseault: > > The If header has more features than have been used in shipping > clients, > I believe. To move from Draft Standard to Proposed, we have to > pare down > the If header definition to those features for which interoperability > has been shown. > > We need to know exactly what features clients are using: > - NOT production? not used ;) by me. > - ETags (I think this has already been discussed) not used. > - Multiple tagged lists per header? (AND) used and needed. > - Multiple tokens/tags per list? (OR) currently not used. Our server code implements all these features. Removing the "NOT" production is Ok with me, if we need it for proven interoperability. I feel however that the "NOT" production makes the "IF" grammer more complete and see no great burden in its implementation. //Stefan > I propose the following rough text for the If header, assuming > that none > of the features above are being used by clients in real usage scenarios > (not including Litmus or other test suites). It is intended to be a > minimalist (KISS) approach to rewriting section 9.4. > The text defines the If header in a backward-compatible way: any client > following the definition below will send a subset of the syntax > that any > server implementing RFC2518 will support. Any server implementing the > definition below will work with existing clients as far as I know. > > ----- > > 9.4 If Header > > If = "If" ":" ( 1*No-tag-list | 1*Tagged-list) > No-tag-list = List > Tagged-list = Resource 1*List > Resource = Coded-URL > List = "(" 1*State-token ")" > State-token = Coded-URL > Coded-URL = "<" absoluteURI ">" > > The If header was intended to have similar functionality to the If- > Match header defined in section 14.25 of [RFC2068]. However the If > header is intended for use with any URI (state token) which > represents > state > information about a resource. A typical example of a state > token is a > lock token, and > lock tokens are the only state tokens defined in this specification. > > > > All DAV compliant resources MUST honor the If header. > > The If header's purpose is to describe a series of state lists. If > the state of the resource to which the header is applied does not > match any of the specified state lists then the request MUST fail > with a 412 (Precondition Failed). If one of the described state > lists matches the state of the resource then the request may > succeed. > > > Note that the absoluteURI production is defined in [RFC2396]. > > > 9.4.1 No-tag-list Production > > > The No-tag-list production describes a series of state tokens. > If multiple No-tag-list productions are used then one only > needs to match the state of the resource for the method to be > allowed to continue. > > If a method, due to the presence of a Depth or Destination header, > is applied to multiple resources then the No-tag-list production > MUST be applied to each resource the method is applied to. > > > 9.4.1.1 Example - No-tag-list with "or" > > If: () > () > > > The previous header would require that any resources within the > scope of the method must be locked with one or both of the lock > tokens. > > 9.4.2 Tagged-list Production > > The tagged-list production scopes a list production. That is, it > specifies that the lists following the resource specification only > apply to the specified resource. The scope of the resource > production begins with the list production immediately following the > resource production and ends with the next resource production, if > any. > > When the If header is applied to a particular resource, the Tagged- > list productions MUST be searched to determine if any of the listed > resources match the operand resource(s) for the current method. If > none of the resource productions match the current resource then the > header MUST be ignored. If one of the resource productions does > match the name of the resource under consideration then the list > productions following the resource production MUST be applied to the > resource in the manner specified in the previous section. > > > The same URI MUST NOT appear more than once in a resource production > in an If header. > > > 9.4.2.1 Example - Tagged List If header > > COPY /resource1 HTTP/1.1 > Host: www.foo.bar > Destination: http://www.foo.bar/resource2 > If: () > () > > In this example http://www.foo.bar/resource1 is being copied to > http://www.foo.bar/resource2. When the method is first applied to > http://www.foo.bar/resource1, resource1 must be in the state > specified by "()", that is, it must be > locked with a lock > token of "locktoken:a-write-lock-token". > > That is the only success condition since the resource > http://www.bar.bar/random never has the method applied to it (the > only other resource listed in the If header) and > http://www.foo.bar/resource2 is not listed in the If header. > > 9.4.4 Matching Function > > When performing If header processing, the definition of a matching > state token or entity tag is as follows. > > Matching state token: Where there is an exact match between the > state token in the If header and any state token on the resource. > > 9.4.5 If Header and Non-DAV Compliant Proxies > > Non-DAV compliant proxies will not honor the If header, since they > will not understand the If header, and HTTP requires non-understood > headers to be ignored. When communicating with HTTP/1.1 proxies, > the "Cache-Control: no-cache" request header MUST be used so as to > prevent the proxy from improperly trying to service the request from > its cache. When dealing with HTTP/1.0 proxies the "Pragma: no- > cache" request header MUST be used for the same reason. > From w3c-dist-auth-request@w3.org Wed Jul 24 13:15:55 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24746 for ; Wed, 24 Jul 2002 13:15:54 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA32121; Wed, 24 Jul 2002 13:15:22 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6OHFGw00396; Wed, 24 Jul 2002 13:15:16 -0400 (EDT) Resent-Date: Wed, 24 Jul 2002 13:15:16 -0400 (EDT) Resent-Message-Id: <200207241715.g6OHFGw00396@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6OHFF700376 for ; Wed, 24 Jul 2002 13:15:15 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA32072 for ; Wed, 24 Jul 2002 13:15:15 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 24 Jul 2002 13:14:34 -0400 (Eastern Daylight Time) Received: from ATL1VEXC006.usdom004.tco.tc ([10.158.7.208]) by atl1simr002.tco.tc with Microsoft SMTPSVC(5.0.2195.2966); Wed, 24 Jul 2002 13:14:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Jul 2002 13:14:33 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA6017371BC1@ATL1VEXC006.usdom004.tco.tc> Thread-Topic: New RFC2518bis draft, COPY / MOVE of live properities Thread-Index: AcIzD+ZEjtQK7Pa7TTuEhseDfrEcwwAJM9dw From: "Lisa Dusseault" To: "Clemm, Geoff" , X-OriginalArrivalTime: 24 Jul 2002 17:14:33.0813 (UTC) FILETIME=[9489B050:01C23335] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g6OHFF700376 Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6453 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit It depends on the precise wording of the language. One alternative is to be loose, allowing servers compliant with 2518 to still be compliant with 2518bis (with either MAY or SHOULD, I'm not sure yet): "A MOVE operation MAY fail (403 Forbidden) if the live properties of the source cannot be live properties of the destination. The server MAY remove live properties that are no longer appropriate at the destination." A stricter alternative: "All live properties on the source resource MUST become live properties on the destination resource with appropriate values and the same semantics. If the server cannot guarantee this, it MUST fail the request with 403 Forbidden." The problem with the stricter alternative is that it forbids a server from removing a live property. E.g. in collection "drafts", the property "draftstatus" (in some custom namespace) can be set by clients and the server allows certain actions on the resource based on the value of this property. Therefore "draftstatus" is a live property. When the resource is moved to the "publish" collection, "draftstatus" is no longer appropriate as a live property at all. May the server remove it? Lisa > -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@rational.com] > Sent: Wednesday, July 24, 2002 5:35 AM > To: w3c-dist-auth@w3c.org > Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities > > > I don't quite understand the first part of the question. > If we say that the live properties must continue live at > the destination, what more do we need to say? (I.e. what > situation is left ambiguous?). > > For the second part, a 403 (Forbidden) seems right to me. > > Cheers, > Geoff > > -----Original Message----- > From: Lisa Dusseault [mailto:ldusseault@xythos.com] > Sent: Tuesday, July 23, 2002 5:59 PM > To: w3c-dist-auth@w3c.org > Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities > > > > > If a MOVE operation MAY fail when live properties can't be continued as > live properties at the destination, what should we say about when the > server can allow the MOVE and when it can't? Is it entirely up to the > server or should we make a recommendation? > > Then, if the server does fail, what error code should be returned? > > Lisa From w3c-dist-auth-request@w3.org Wed Jul 24 16:16:29 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00880 for ; Wed, 24 Jul 2002 16:16:28 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA23493; Wed, 24 Jul 2002 16:15:32 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6OKFQP18604; Wed, 24 Jul 2002 16:15:26 -0400 (EDT) Resent-Date: Wed, 24 Jul 2002 16:15:26 -0400 (EDT) Resent-Message-Id: <200207242015.g6OKFQP18604@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6OKFP718580 for ; Wed, 24 Jul 2002 16:15:25 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA23427 for ; Wed, 24 Jul 2002 16:15:25 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 24 Jul 2002 16:14:47 -0400 (Eastern Daylight Time) Received: from ATL1VEXC006.usdom004.tco.tc ([10.158.7.208]) by atl1simr002.tco.tc with Microsoft SMTPSVC(5.0.2195.2966); Wed, 24 Jul 2002 16:14:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Jul 2002 16:14:45 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA6017371BC4@ATL1VEXC006.usdom004.tco.tc> Thread-Topic: Open issues with internationalization section Thread-Index: AcIeFejrV2IINAPfSOGu0UT+Uiod+AVMbN3g From: "Lisa Dusseault" To: "Julian Reschke" , X-OriginalArrivalTime: 24 Jul 2002 20:14:46.0240 (UTC) FILETIME=[C13F1E00:01C2334E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g6OKFP718580 Subject: Open issues with internationalization section Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6454 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Julian suggested: > 1) Replace > > "...encoded, at minimum, using the UTF-8 [UTF-8] encoding of the ISO > 10646 multilingual plane." > > by > > "...encoded, at minimum, using any mandatory encoding for which the > XML specification requires support." > > Note: this inclused UTF-16. Does everybody agree to extend the encoding requirements to UTF-16? Will existing clients support this if servers use it? Or do we need to be more complicated, requiring clients to support both but servers recommended to use UTF-8 unless they know the client supports both? From w3c-dist-auth-request@w3.org Wed Jul 24 16:51:07 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02355 for ; Wed, 24 Jul 2002 16:51:05 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA06879; Wed, 24 Jul 2002 16:50:31 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6OKoUN26996; Wed, 24 Jul 2002 16:50:30 -0400 (EDT) Resent-Date: Wed, 24 Jul 2002 16:50:30 -0400 (EDT) Resent-Message-Id: <200207242050.g6OKoUN26996@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6OKoS726976 for ; Wed, 24 Jul 2002 16:50:29 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA06862 for ; Wed, 24 Jul 2002 16:50:28 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 24 Jul 2002 16:49:46 -0400 (Eastern Daylight Time) Received: from ATL1VEXC006.usdom004.tco.tc ([209.225.56.53]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 24 Jul 2002 16:49:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Jul 2002 16:49:45 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA601736D8AE@ATL1VEXC006.usdom004.tco.tc> Thread-Topic: Doubt in error response Thread-Index: AcIjMSabU3YS3msNRc23tenVCbMBTwQImyQw From: "Lisa Dusseault" To: "ganesh_k" , X-OriginalArrivalTime: 24 Jul 2002 20:49:45.0939 (UTC) FILETIME=[A4C3C230:01C23353] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g6OKoS726976 Subject: RE: Doubt in error response Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6455 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit We use 412 Precondition Failed, which seems to be appropriate because having a lock is a precondition to being able to unlock. Any objections to adding that in RFC2518bis? Lisa > -----Original Message----- > From: ganesh_k [mailto:ganesh_k@infosys.com] > Sent: Thursday, July 04, 2002 1:03 AM > To: w3c-dist-auth@w3c.org > Subject: Doubt in error response > > > Hi all > What error response is the WebDAV server supposed to send if it receives > an UNLOCK request on a resource which is not locked in the first place? > Is it it 403- forbidden or method failed or something else? > > Regds > Ganesh From w3c-dist-auth-request@w3.org Wed Jul 24 17:16:27 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02877 for ; Wed, 24 Jul 2002 17:16:26 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA14688; Wed, 24 Jul 2002 17:15:28 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6OLFQA28669; Wed, 24 Jul 2002 17:15:26 -0400 (EDT) Resent-Date: Wed, 24 Jul 2002 17:15:26 -0400 (EDT) Resent-Message-Id: <200207242115.g6OLFQA28669@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6OLFQ728649 for ; Wed, 24 Jul 2002 17:15:26 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA14671 for ; Wed, 24 Jul 2002 17:15:25 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 24 Jul 2002 17:14:49 -0400 (Eastern Daylight Time) Received: from ATL1VEXC006.usdom004.tco.tc ([10.158.7.208]) by atl1simr002.tco.tc with Microsoft SMTPSVC(5.0.2195.2966); Wed, 24 Jul 2002 17:14:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Wed, 24 Jul 2002 17:14:48 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA6017371BC7@ATL1VEXC006.usdom004.tco.tc> Thread-Topic: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Thread-Index: AcIeEjP2KyXHBfllTg6TKS7O1tGuMQVREjBw From: "Lisa Dusseault" To: "Webdav WG (E-mail)" X-OriginalArrivalTime: 24 Jul 2002 21:14:48.0740 (UTC) FILETIME=[2480FE40:01C23357] Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6456 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23357.246A7F08" ------_=_NextPart_001_01C23357.246A7F08 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reducing the scope of the purpose of the source property is good in theory. However, this does not resolve the issue, because it only discusses *theoretical* interoperability. To proceed to Draft Standard, we need *actual interoperability*. =20 Are there two servers and two clients out there who have implemented the source property already? If so, we need to test them at the interop in September or online. =20 Are there two servers and two clients who would implement and use the source property in a form close to its current definition, but have not done so yet? If so, what's blocking you from actually implementing it? Is it that it is missing roles, or is something else required? =20 We can't have our cake and eat it too. We have to do the work of implementing and testing interoperability if we want to keep source and move to Draft Standard. =20 Lisa =20 -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com]=20 Sent: Thursday, June 27, 2002 12:26 PM To: Julian Reschke Cc: Clemm, Geoff; 'Webdav WG (E-mail)' Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED =20 Okay... Julian, Geoff and Roy makes 3:0. Unless I hear some dissenting opinions, it looks like we should make it clear in the spec that the dav:source property is only serving a specific purpose (2, 3, and possibly 4) and use beyond that is not interoperable. Wow... we might actually resolve this issue this time. :-) J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com ------_=_NextPart_001_01C23357.246A7F08 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reducing the scope of the purpose = of the source property is good in theory. However, this does not resolve the = issue, because it only discusses *theoretical* interoperability. To proceed to Draft Standard, we need *actual = interoperability*.

 

Are there two servers and two = clients out there who have implemented the source property already?  If so, we = need to test them at the interop in September or online.

 

Are there two servers and two = clients who would implement and use the source property in a form close to its current = definition, but have not done so yet? If so, what’s blocking you from actually implementing it?  Is it that it is missing roles, or is something = else required?

 

We can’t have our cake and = eat it too. We have to do the work of implementing and testing interoperability = if we want to keep source and move to Draft Standard.

 

Lisa

 

-----Original Message-----
From: Jason Crawford [mailto:ccjason@us.ibm.com]
Sent: Thursday, June 27, = 2002 12:26 PM
To: Julian Reschke
Cc: Clemm, Geoff; 'Webdav = WG (E-mail)'
Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED

 

Okay... Julian, Geoff and Roy makes 3:0. Unless I hear some dissenting opinions, = it looks like we should make it clear in the spec that the dav:source = property is only serving a specific purpose (2, 3, and possibly 4) and use beyond = that is not interoperable.

Wow... we might actually resolve this issue this time. :-)

J.

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

=00 ------_=_NextPart_001_01C23357.246A7F08-- --------------InterScan_NT_MIME_Boundary-- From w3c-dist-auth-request@w3.org Wed Jul 24 17:24:02 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03016 for ; Wed, 24 Jul 2002 17:24:01 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA17498; Wed, 24 Jul 2002 17:23:24 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6OLNNU29322; Wed, 24 Jul 2002 17:23:23 -0400 (EDT) Resent-Date: Wed, 24 Jul 2002 17:23:23 -0400 (EDT) Resent-Message-Id: <200207242123.g6OLNNU29322@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6OLNM729302 for ; Wed, 24 Jul 2002 17:23:22 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA17472 for ; Wed, 24 Jul 2002 17:23:22 -0400 Received: (qmail 12229 invoked by uid 0); 24 Jul 2002 21:23:08 -0000 Received: from p3ee24752.dip.t-dialin.net (HELO lisa) (62.226.71.82) by mail.gmx.net (mp008-rz3) with SMTP; 24 Jul 2002 21:23:08 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "Julian Reschke" , Date: Wed, 24 Jul 2002 23:23:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <27889B08CAEC7049B68FAD8717BA6017371BC4@ATL1VEXC006.usdom004.tco.tc> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Open issues with internationalization section Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6457 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, July 24, 2002 10:15 PM > To: Julian Reschke; w3c-dist-auth@w3c.org > Subject: Open issues with internationalization section > > > > Julian suggested: > > > 1) Replace > > > > "...encoded, at minimum, using the UTF-8 [UTF-8] encoding of the > ISO > > 10646 multilingual plane." > > > > by > > > > "...encoded, at minimum, using any mandatory encoding for which > the > > XML specification requires support." > > > > Note: this inclused UTF-16. > > Does everybody agree to extend the encoding requirements to UTF-16? Will We don't "extend" - we clarify. Any XML parser is required to support UTF-8 and UTF-16. RFC2518 requires that an implementation uses a conforming XML parser. > existing clients support this if servers use it? Or do we need to be > more complicated, requiring clients to support both but servers > recommended to use UTF-8 unless they know the client supports both? Both MUST support both, otherwise they break XML. On the other hand, it may make sense to *discourage* any other encoding (such as ISO-8859-1 or win-nnnn). From w3c-dist-auth-request@w3.org Wed Jul 24 18:12:24 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03913 for ; Wed, 24 Jul 2002 18:12:23 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA28833; Wed, 24 Jul 2002 18:11:39 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6OMBOK03060; Wed, 24 Jul 2002 18:11:24 -0400 (EDT) Resent-Date: Wed, 24 Jul 2002 18:11:24 -0400 (EDT) Resent-Message-Id: <200207242211.g6OMBOK03060@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6OMBN703036 for ; Wed, 24 Jul 2002 18:11:23 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA28760 for ; Wed, 24 Jul 2002 18:11:22 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g6OMB8005500 for ; Wed, 24 Jul 2002 15:11:08 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 24 Jul 2002 15:09:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0057_01C23324.16F995D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: 207 Multi-Status success Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6458 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0057_01C23324.16F995D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I have added billb@tibco.com to the accept2 list. - Jim -----Original Message----- From: Bill Brown [mailto:billb@tibco.com] Sent: Wednesday, July 24, 2002 2:54 PM To: 'w3c-dist-auth@w3.org' Subject: [Moderator Action] 207 Multi-Status success I recently implemented the Dav protocol for our Schema repo so it is now a Dav server....wrote all the code to handle failures for lock, delete, move, copy and proppatch, so they return a 207 multi-status response and the appropriate xml as defined by the Dav spec.....my problem is that now.....I can't find a Dav client that recognizes 207 multi-status as a "failure"....everyone I've tried, treats it as a "success"....this actually makes sense to me, since 200 level status codes have always meant "success" to me....so, if I change the code to remap the 207 multi-status and return a 412 Precondition Failed....then all the clients will treat that response status as a failure.....obviously, since 400 level codes are "client error" responses......I don't have much choice but to leave it that way..... Two questions....1) Am I completely missing something here?? and 2) Can anybody point me to a Dav client that treats the 207 multi-status as a "failure" in the appropriate cases?? thanks, bill ------=_NextPart_000_0057_01C23324.16F995D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Accidentally caught by the spam filter. I = have added billb@tibco.com to the accept2=20 list.
 
-=20 Jim
-----Original Message-----
From: Bill Brown=20 [mailto:billb@tibco.com]
Sent: Wednesday, July 24, 2002 2:54=20 PM
To: 'w3c-dist-auth@w3.org'
Subject: [Moderator = Action]=20 207 Multi-Status success

I = recently=20 implemented the Dav protocol for our Schema repo so it is now a Dav=20 server....wrote all the code to handle failures for lock, delete, move, = copy and=20 proppatch, so they return a 207 multi-status response and the = appropriate=20 xml as defined by the Dav spec.....my problem is that now.....I can't = find a Dav=20 client that recognizes 207 multi-status as a "failure"....everyone I've = tried,=20 treats it as a "success"....this actually makes sense to me, since 200 = level=20 status codes have always meant "success" to me....so, if I = change the code=20 to remap the 207 multi-status and return a 412 Precondition=20 Failed....then all the clients will treat that response status as a = failure.....obviously, since 400 level codes are "client error" = responses......I=20 don't have much choice but to leave it that way.....
 
Two = questions....1)=20 Am I completely missing something here?? and 2) Can anybody point me to = a Dav=20 client that treats the 207 multi-status as a "failure" in the = appropriate=20 cases??
 
thanks,
bill
 
------=_NextPart_000_0057_01C23324.16F995D0-- From w3c-dist-auth-request@w3.org Wed Jul 24 18:55:27 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04876 for ; Wed, 24 Jul 2002 18:55:27 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA05619; Wed, 24 Jul 2002 18:54:02 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6OMrp806913; Wed, 24 Jul 2002 18:53:51 -0400 (EDT) Resent-Date: Wed, 24 Jul 2002 18:53:51 -0400 (EDT) Resent-Message-Id: <200207242253.g6OMrp806913@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6OMrn706893 for ; Wed, 24 Jul 2002 18:53:49 -0400 (EDT) Received: from mta05-svc.ntlworld.com (mta05-svc.ntlworld.com [62.253.162.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA05567 for ; Wed, 24 Jul 2002 18:53:48 -0400 Received: from manyfish.co.uk ([62.253.142.7]) by mta05-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020724225348.JTGJ28874.mta05-svc.ntlworld.com@manyfish.co.uk> for ; Wed, 24 Jul 2002 23:53:48 +0100 Received: (from joe@localhost) by manyfish.co.uk (8.11.6/8.11.6) id g6OMrmO26880 for w3c-dist-auth@w3.org; Wed, 24 Jul 2002 23:53:48 +0100 Date: Wed, 24 Jul 2002 23:53:48 +0100 From: Joe Orton To: WebDAV Message-ID: <20020724235348.A26860@light.plus.com> Mail-Followup-To: WebDAV References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ejw@cse.ucsc.edu on Wed, Jul 24, 2002 at 03:09:21PM -0700 Subject: Re: FW: 207 Multi-Status success Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6459 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > From: Bill Brown [mailto:billb@tibco.com] > Sent: Wednesday, July 24, 2002 2:54 PM > To: 'w3c-dist-auth@w3.org' > Subject: [Moderator Action] 207 Multi-Status success > > > I recently implemented the Dav protocol for our Schema repo so it is now a > Dav server....wrote all the code to handle failures for lock, delete, move, > copy and proppatch, so they return a 207 multi-status response and the > appropriate xml as defined by the Dav spec.....my problem is that now.....I > can't find a Dav client that recognizes 207 multi-status as a > "failure"....everyone I've tried, treats it as a "success"....this actually > makes sense to me, since 200 level status codes have always meant "success" > to me....so, if I change the code to remap the 207 multi-status and return a > 412 Precondition Failed....then all the clients will treat that response > status as a failure.....obviously, since 400 level codes are "client error" > responses......I don't have much choice but to leave it that way..... > > Two questions....1) Am I completely missing something here?? and 2) Can > anybody point me to a Dav client that treats the 207 multi-status as a > "failure" in the appropriate cases?? cadaver (and any other client based on the neon library) treats a 207 response to MKCOL, DELETE, etc as an error. Regards, joe From w3c-dist-auth-request@w3.org Thu Jul 25 07:39:47 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29112 for ; Thu, 25 Jul 2002 07:39:47 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA22519; Thu, 25 Jul 2002 07:38:57 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6PBcoO26178; Thu, 25 Jul 2002 07:38:50 -0400 (EDT) Resent-Date: Thu, 25 Jul 2002 07:38:50 -0400 (EDT) Resent-Message-Id: <200207251138.g6PBcoO26178@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6PBcn726158 for ; Thu, 25 Jul 2002 07:38:49 -0400 (EDT) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA22453 for ; Thu, 25 Jul 2002 07:38:48 -0400 Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id UAA18848 for ; Thu, 25 Jul 2002 20:38:45 +0900 (JST) Received: from pekoe.iij.ad.jp (pekoe.iij.ad.jp [192.168.4.173]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with SMTP id UAA21757 for ; Thu, 25 Jul 2002 20:38:45 +0900 (JST) Received: (nullmailer pid 352 invoked by uid 5292); Thu, 25 Jul 2002 11:38:18 -0000 To: w3c-dist-auth@w3c.org References: <27889B08CAEC7049B68FAD8717BA6017371BC4@ATL1VEXC006.usdom004.tco.tc> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Taisuke Yamada Date: Thu, 25 Jul 2002 20:38:17 +0900 In-Reply-To: (Julian Reschke's message of "Wed, 24 Jul 2002 23:23:07 +0200") Message-ID: Lines: 24 User-Agent: T-gnus/6.15.6 (based on Oort Gnus v0.06) (revision 01) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1 (AOI) Subject: Re: Open issues with internationalization section Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6460 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: >> Does everybody agree to extend the encoding requirements to UTF-16? > > We don't "extend" - we clarify. Any XML parser is required to > support UTF-8 and UTF-16. RFC2518 requires that an implementation > uses a conforming XML parser. Agreed. Also, this update shouldn't cause much problem anyway, as everyone seems to have gone with UTF-8. > On the other hand, it may make sense to *discourage* any other > encoding (such as ISO-8859-1 or win-nnnn). Hmm, do you mean by MUST NOT? Banning use of other encodings in the spec sounds too aggressive to me. Simply keeping it optional (as XML does) should be effectively the same. For world-wide interoperability, it is good to have Unicode as a MUST. But why not allow use of other encodings under controlled or non-public environment? -- Taisuke Yamada Internet Initiative Japan Inc., Technical Planning Division From w3c-dist-auth-request@w3.org Thu Jul 25 07:49:40 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29264 for ; Thu, 25 Jul 2002 07:49:40 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA24167; Thu, 25 Jul 2002 07:49:16 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6PBnFV26590; Thu, 25 Jul 2002 07:49:15 -0400 (EDT) Resent-Date: Thu, 25 Jul 2002 07:49:15 -0400 (EDT) Resent-Message-Id: <200207251149.g6PBnFV26590@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6PBnF726570 for ; Thu, 25 Jul 2002 07:49:15 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA24158 for ; Thu, 25 Jul 2002 07:49:14 -0400 Received: (qmail 7299 invoked by uid 0); 25 Jul 2002 11:48:43 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp011-rz3) with SMTP; 25 Jul 2002 11:48:43 -0000 From: "Julian Reschke" To: "Taisuke Yamada" , Date: Thu, 25 Jul 2002 13:48:42 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Open issues with internationalization section Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6461 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Taisuke Yamada > Sent: Thursday, July 25, 2002 1:38 PM > To: w3c-dist-auth@w3c.org > Subject: Re: Open issues with internationalization section > > > > > >> Does everybody agree to extend the encoding requirements to UTF-16? > > > > We don't "extend" - we clarify. Any XML parser is required to > > support UTF-8 and UTF-16. RFC2518 requires that an implementation > > uses a conforming XML parser. > > Agreed. Also, this update shouldn't cause much problem anyway, as > everyone seems to have gone with UTF-8. > > > On the other hand, it may make sense to *discourage* any other > > encoding (such as ISO-8859-1 or win-nnnn). > > Hmm, do you mean by MUST NOT? Banning use of other encodings in the > spec sounds too aggressive to me. Simply keeping it optional (as XML > does) should be effectively the same. > > For world-wide interoperability, it is good to have Unicode as a MUST. > But why not allow use of other encodings under controlled or non-public > environment? Well, if a client/server uses an optional encoding (and any except UTF-8 and UTF-16 *is* optional in XML), it may have to live with the fact that the other side requests the message, so there's no guaranteed interoperability. If you control both sides, that's fine. But the whole point in *having* an open internet protocol is to take care of the case where you *don't* control both sides. From w3c-dist-auth-request@w3.org Thu Jul 25 08:09:00 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00228 for ; Thu, 25 Jul 2002 08:08:59 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA29640; Thu, 25 Jul 2002 08:08:35 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6PC8YU27451; Thu, 25 Jul 2002 08:08:34 -0400 (EDT) Resent-Date: Thu, 25 Jul 2002 08:08:34 -0400 (EDT) Resent-Message-Id: <200207251208.g6PC8YU27451@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6PC8X727428 for ; Thu, 25 Jul 2002 08:08:33 -0400 (EDT) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA29601 for ; Thu, 25 Jul 2002 08:08:33 -0400 Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id VAA19228 for ; Thu, 25 Jul 2002 21:08:31 +0900 (JST) Received: from pekoe.iij.ad.jp (pekoe.iij.ad.jp [192.168.4.173]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with SMTP id VAA25957 for ; Thu, 25 Jul 2002 21:08:31 +0900 (JST) Received: (nullmailer pid 478 invoked by uid 5292); Thu, 25 Jul 2002 12:08:03 -0000 To: w3c-dist-auth@w3c.org References: MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Taisuke Yamada Date: Thu, 25 Jul 2002 21:08:03 +0900 In-Reply-To: (Julian Reschke's message of "Thu, 25 Jul 2002 13:48:42 +0200") Message-ID: Lines: 15 User-Agent: T-gnus/6.15.6 (based on Oort Gnus v0.06) (revision 01) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1 (AOI) Subject: Re: Open issues with internationalization section Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6462 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > Well, if a client/server uses an optional encoding (and any except > UTF-8 and UTF-16 *is* optional in XML), it may have to live with > the fact that the other side requests the message, so there's no > guaranteed interoperability. Yes, and I agree with that completely. My point was leaving encodings other than UTF-(8|16) as OPTIONAL by not mentioning is good enough, because XML states it as optional. Stating it as MUST NOT in the spec is more than necessary. -- Taisuke Yamada Internet Initiative Japan Inc., Technical Planning Division From w3c-dist-auth-request@w3.org Thu Jul 25 08:59:36 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01932 for ; Thu, 25 Jul 2002 08:59:36 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA16069; Thu, 25 Jul 2002 08:59:08 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6PCx2B00568; Thu, 25 Jul 2002 08:59:02 -0400 (EDT) Resent-Date: Thu, 25 Jul 2002 08:59:02 -0400 (EDT) Resent-Message-Id: <200207251259.g6PCx2B00568@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6PCww700506 for ; Thu, 25 Jul 2002 08:58:58 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA15993 for ; Thu, 25 Jul 2002 08:58:58 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Thu, 25 Jul 2002 08:50:51 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 08:58:27 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B107A5C740@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Thu, 25 Jul 2002 08:58:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6463 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I'd prefer the stricter alternative, but I could live with the former if it said "SHOULD" instead of "MAY". Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:ldusseault@xythos.com] Sent: Wednesday, July 24, 2002 1:15 PM To: Clemm, Geoff; w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities It depends on the precise wording of the language. One alternative is to be loose, allowing servers compliant with 2518 to still be compliant with 2518bis (with either MAY or SHOULD, I'm not sure yet): "A MOVE operation MAY fail (403 Forbidden) if the live properties of the source cannot be live properties of the destination. The server MAY remove live properties that are no longer appropriate at the destination." A stricter alternative: "All live properties on the source resource MUST become live properties on the destination resource with appropriate values and the same semantics. If the server cannot guarantee this, it MUST fail the request with 403 Forbidden." The problem with the stricter alternative is that it forbids a server from removing a live property. E.g. in collection "drafts", the property "draftstatus" (in some custom namespace) can be set by clients and the server allows certain actions on the resource based on the value of this property. Therefore "draftstatus" is a live property. When the resource is moved to the "publish" collection, "draftstatus" is no longer appropriate as a live property at all. May the server remove it? Lisa > -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@rational.com] > Sent: Wednesday, July 24, 2002 5:35 AM > To: w3c-dist-auth@w3c.org > Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities > > > I don't quite understand the first part of the question. > If we say that the live properties must continue live at > the destination, what more do we need to say? (I.e. what > situation is left ambiguous?). > > For the second part, a 403 (Forbidden) seems right to me. > > Cheers, > Geoff > > -----Original Message----- > From: Lisa Dusseault [mailto:ldusseault@xythos.com] > Sent: Tuesday, July 23, 2002 5:59 PM > To: w3c-dist-auth@w3c.org > Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities > > > > > If a MOVE operation MAY fail when live properties can't be continued as > live properties at the destination, what should we say about when the > server can allow the MOVE and when it can't? Is it entirely up to the > server or should we make a recommendation? > > Then, if the server does fail, what error code should be returned? > > Lisa From w3c-dist-auth-request@w3.org Thu Jul 25 13:41:21 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14186 for ; Thu, 25 Jul 2002 13:41:21 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA02410; Thu, 25 Jul 2002 13:40:40 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6PHebj27917; Thu, 25 Jul 2002 13:40:37 -0400 (EDT) Resent-Date: Thu, 25 Jul 2002 13:40:37 -0400 (EDT) Resent-Message-Id: <200207251740.g6PHebj27917@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6PHeZ727890 for ; Thu, 25 Jul 2002 13:40:35 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA02387 for ; Thu, 25 Jul 2002 13:40:35 -0400 Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6PHdwe8127250; Thu, 25 Jul 2002 13:39:58 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay01.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6PHdto4039214; Thu, 25 Jul 2002 13:39:56 -0400 To: "Clemm, Geoff" Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Thu, 25 Jul 2002 13:30:26 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_07122002 Pre-release 2|July 12, 2002) at 07/25/2002 13:39:55 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBE692DFF387CA8f9e8a93df938690918c0ABBE692DFF387CA" Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6464 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE692DFF387CA8f9e8a93df938690918c0ABBE692DFF387CA Content-type: multipart/alternative; Boundary="1__=0ABBE692DFF387CA8f9e8a93df938690918c0ABBE692DFF387CA" --1__=0ABBE692DFF387CA8f9e8a93df938690918c0ABBE692DFF387CA Content-type: text/plain; charset=US-ASCII I also prefer the stricter version... although only for MOVE. (The second wording doesn't mention "MOVE" explicitly.) ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com "Clemm, Geoff" cc: Sent by: w3c- Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities dist-auth- request@w3.org 07/25/2002 08:58 AM I'd prefer the stricter alternative, but I could live with the former if it said "SHOULD" instead of "MAY". Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:ldusseault@xythos.com] Sent: Wednesday, July 24, 2002 1:15 PM To: Clemm, Geoff; w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities It depends on the precise wording of the language. One alternative is to be loose, allowing servers compliant with 2518 to still be compliant with 2518bis (with either MAY or SHOULD, I'm not sure yet): "A MOVE operation MAY fail (403 Forbidden) if the live properties of the source cannot be live properties of the destination. The server MAY remove live properties that are no longer appropriate at the destination." A stricter alternative: "All live properties on the source resource MUST become live properties on the destination resource with appropriate values and the same semantics. If the server cannot guarantee this, it MUST fail the request with 403 Forbidden." The problem with the stricter alternative is that it forbids a server from removing a live property. E.g. in collection "drafts", the property "draftstatus" (in some custom namespace) can be set by clients and the server allows certain actions on the resource based on the value of this property. Therefore "draftstatus" is a live property. When the resource is moved to the "publish" collection, "draftstatus" is no longer appropriate as a live property at all. May the server remove it? Lisa > -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@rational.com] > Sent: Wednesday, July 24, 2002 5:35 AM > To: w3c-dist-auth@w3c.org > Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities > > > I don't quite understand the first part of the question. > If we say that the live properties must continue live at > the destination, what more do we need to say? (I.e. what > situation is left ambiguous?). > > For the second part, a 403 (Forbidden) seems right to me. > > Cheers, > Geoff > > -----Original Message----- > From: Lisa Dusseault [mailto:ldusseault@xythos.com] > Sent: Tuesday, July 23, 2002 5:59 PM > To: w3c-dist-auth@w3c.org > Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities > > > > > If a MOVE operation MAY fail when live properties can't be continued as > live properties at the destination, what should we say about when the > server can allow the MOVE and when it can't? Is it entirely up to the > server or should we make a recommendation? > > Then, if the server does fail, what error code should be returned? > > Lisa --1__=0ABBE692DFF387CA8f9e8a93df938690918c0ABBE692DFF387CA Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I also prefer the stricter version... although only for MOVE. (The second wording doesn't mention "MOVE" explicitly.)

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

"Clemm, Geoff" <gclemm@rational.com>




          "Clemm, Geoff" <gclemm@rational.com>
          Sent by: w3c-dist-auth-request@w3.org

          07/25/2002 08:58 AM



To: w3c-dist-auth@w3c.org
cc:
Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities



I'd prefer the stricter alternative, but I could live with
the former if it said "SHOULD" instead of "MAY".

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:ldusseault@xythos.com]
Sent: Wednesday, July 24, 2002 1:15 PM
To: Clemm, Geoff; w3c-dist-auth@w3c.org
Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities


It depends on the precise wording of the language. One alternative is to
be loose, allowing servers compliant with 2518 to still be compliant
with 2518bis (with either MAY or SHOULD, I'm not sure yet):

"A MOVE operation MAY fail (403 Forbidden) if the live properties of the
source cannot be live properties of the destination. The server MAY
remove live properties that are no longer appropriate at the
destination."

A stricter alternative:

"All live properties on the source resource MUST become live properties
on the destination resource with appropriate values and the same
semantics. If the server cannot guarantee this, it MUST fail the request
with 403 Forbidden."

The problem with the stricter alternative is that it forbids a server
from removing a live property. E.g. in collection "drafts", the
property "draftstatus" (in some custom namespace) can be set by clients
and the server allows certain actions on the resource based on the value
of this property. Therefore "draftstatus" is a live property. When the
resource is moved to the "publish" collection, "draftstatus" is no
longer appropriate as a live property at all. May the server remove it?

Lisa

> -----Original Message-----
> From: Clemm, Geoff [mailto:gclemm@rational.com]
> Sent: Wednesday, July 24, 2002 5:35 AM
> To: w3c-dist-auth@w3c.org
> Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities
>
>
> I don't quite understand the first part of the question.
> If we say that the live properties must continue live at
> the destination, what more do we need to say? (I.e. what
> situation is left ambiguous?).
>
> For the second part, a 403 (Forbidden) seems right to me.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Lisa Dusseault [mailto:ldusseault@xythos.com]
> Sent: Tuesday, July 23, 2002 5:59 PM
> To: w3c-dist-auth@w3c.org
> Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities
>
>
>
>
> If a MOVE operation MAY fail when live properties can't be continued
as
> live properties at the destination, what should we say about when the
> server can allow the MOVE and when it can't? Is it entirely up to the
> server or should we make a recommendation?
>
> Then, if the server does fail, what error code should be returned?
>
> Lisa



--1__=0ABBE692DFF387CA8f9e8a93df938690918c0ABBE692DFF387CA-- --0__=0ABBE692DFF387CA8f9e8a93df938690918c0ABBE692DFF387CA Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=0ABBE692DFF387CA8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBE692DFF387CA8f9e8a93df938690918c0ABBE692DFF387CA Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=0ABBE692DFF387CA8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE692DFF387CA8f9e8a93df938690918c0ABBE692DFF387CA Content-type: image/gif; name="pic25670.gif" Content-Disposition: inline; filename="pic25670.gif" Content-ID: <30__=0ABBE692DFF387CA8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=0ABBE692DFF387CA8f9e8a93df938690918c0ABBE692DFF387CA-- From w3c-dist-auth-request@w3.org Thu Jul 25 13:54:20 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14676 for ; Thu, 25 Jul 2002 13:54:19 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA05730; Thu, 25 Jul 2002 13:53:52 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6PHrqK29829; Thu, 25 Jul 2002 13:53:52 -0400 (EDT) Resent-Date: Thu, 25 Jul 2002 13:53:52 -0400 (EDT) Resent-Message-Id: <200207251753.g6PHrqK29829@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6PHrp729809 for ; Thu, 25 Jul 2002 13:53:51 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA05721 for ; Thu, 25 Jul 2002 13:53:50 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Thu, 25 Jul 2002 13:45:43 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 13:53:18 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1078390F7@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Thu, 25 Jul 2002 13:53:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6465 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Yes, good point Jason, these constraints should only apply to MOVE, and definitely not to COPY. For COPY, I would like us to use the rfc-3253 semantics, i.e. that a COPY is semantically equivalent to a GET/PROPFIND followed by a PUT/PROPPATCH, where the PROPFIND/PROPPATCH is for all properties that can be PROPPATCH'ed at the destination. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Thursday, July 25, 2002 1:30 PM To: Clemm, Geoff Cc: w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities I also prefer the stricter version... although only for MOVE. (The second wording doesn't mention "MOVE" explicitly.) ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com "Clemm, Geoff" "Clemm, Geoff" Sent by: w3c-dist-auth-request@w3.org 07/25/2002 08:58 AM To: w3c-dist-auth@w3c.org cc: Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities I'd prefer the stricter alternative, but I could live with the former if it said "SHOULD" instead of "MAY". Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:ldusseault@xythos.com] Sent: Wednesday, July 24, 2002 1:15 PM To: Clemm, Geoff; w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities It depends on the precise wording of the language. One alternative is to be loose, allowing servers compliant with 2518 to still be compliant with 2518bis (with either MAY or SHOULD, I'm not sure yet): "A MOVE operation MAY fail (403 Forbidden) if the live properties of the source cannot be live properties of the destination. The server MAY remove live properties that are no longer appropriate at the destination." A stricter alternative: "All live properties on the source resource MUST become live properties on the destination resource with appropriate values and the same semantics. If the server cannot guarantee this, it MUST fail the request with 403 Forbidden." The problem with the stricter alternative is that it forbids a server from removing a live property. E.g. in collection "drafts", the property "draftstatus" (in some custom namespace) can be set by clients and the server allows certain actions on the resource based on the value of this property. Therefore "draftstatus" is a live property. When the resource is moved to the "publish" collection, "draftstatus" is no longer appropriate as a live property at all. May the server remove it? Lisa > -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@rational.com] > Sent: Wednesday, July 24, 2002 5:35 AM > To: w3c-dist-auth@w3c.org > Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities > > > I don't quite understand the first part of the question. > If we say that the live properties must continue live at > the destination, what more do we need to say? (I.e. what > situation is left ambiguous?). > > For the second part, a 403 (Forbidden) seems right to me. > > Cheers, > Geoff > > -----Original Message----- > From: Lisa Dusseault [mailto:ldusseault@xythos.com] > Sent: Tuesday, July 23, 2002 5:59 PM > To: w3c-dist-auth@w3c.org > Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities > > > > > If a MOVE operation MAY fail when live properties can't be continued as > live properties at the destination, what should we say about when the > server can allow the MOVE and when it can't? Is it entirely up to the > server or should we make a recommendation? > > Then, if the server does fail, what error code should be returned? > > Lisa From w3c-dist-auth-request@w3.org Thu Jul 25 14:03:25 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14906 for ; Thu, 25 Jul 2002 14:03:24 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA08484; Thu, 25 Jul 2002 14:03:00 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6PI2xB01138; Thu, 25 Jul 2002 14:02:59 -0400 (EDT) Resent-Date: Thu, 25 Jul 2002 14:02:59 -0400 (EDT) Resent-Message-Id: <200207251802.g6PI2xB01138@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6PI2w701118 for ; Thu, 25 Jul 2002 14:02:58 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA08463 for ; Thu, 25 Jul 2002 14:02:57 -0400 Received: (qmail 16487 invoked by uid 0); 25 Jul 2002 18:02:26 -0000 Received: from pd950c38b.dip.t-dialin.net (HELO lisa) (217.80.195.139) by mail.gmx.net (mp004-rz3) with SMTP; 25 Jul 2002 18:02:26 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Thu, 25 Jul 2002 20:02:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1078390F7@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6466 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Thursday, July 25, 2002 7:53 PM > To: w3c-dist-auth@w3c.org > Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities > > > > Yes, good point Jason, these constraints should only > apply to MOVE, and definitely not to COPY. > > For COPY, I would like us to use the rfc-3253 semantics, > i.e. that a COPY is semantically equivalent to a GET/PROPFIND > followed by a PUT/PROPPATCH, where the PROPFIND/PROPPATCH > is for all properties that can be PROPPATCH'ed at the destination. This won't work (in all cases). The resource may have multiple representations (depending on request headers), but a simple sequence of GET/PROPFIND-PUT/PROPPATCH will only copy one of the representations. From w3c-dist-auth-request@w3.org Thu Jul 25 14:15:30 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15383 for ; Thu, 25 Jul 2002 14:15:30 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA11159; Thu, 25 Jul 2002 14:15:03 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6PIF2902048; Thu, 25 Jul 2002 14:15:02 -0400 (EDT) Resent-Date: Thu, 25 Jul 2002 14:15:02 -0400 (EDT) Resent-Message-Id: <200207251815.g6PIF2902048@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6PIEx702012 for ; Thu, 25 Jul 2002 14:14:59 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA11134 for ; Thu, 25 Jul 2002 14:14:59 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Thu, 25 Jul 2002 14:06:52 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 14:14:28 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1078390F9@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Thu, 25 Jul 2002 14:14:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6467 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I believe this definition will work in enough cases for the implementor to be able to extrapolate what to do in those multiple-representation cases (and I'll bet is very close to how Xythos actually does implement its cross-repository MOVE). In particular, I believe we have to say something to clarify the distinction between MOVE and COPY, and that this would be a reasonable compromise between "fully defines every case" (not achievable) and "undefined" (pretty much what we have in 2518). But I'm always open to replacing it with something better! Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Thursday, July 25, 2002 2:02 PM To: Clemm, Geoff; w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Thursday, July 25, 2002 7:53 PM > To: w3c-dist-auth@w3c.org > Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities > > > > Yes, good point Jason, these constraints should only > apply to MOVE, and definitely not to COPY. > > For COPY, I would like us to use the rfc-3253 semantics, > i.e. that a COPY is semantically equivalent to a GET/PROPFIND > followed by a PUT/PROPPATCH, where the PROPFIND/PROPPATCH > is for all properties that can be PROPPATCH'ed at the destination. This won't work (in all cases). The resource may have multiple representations (depending on request headers), but a simple sequence of GET/PROPFIND-PUT/PROPPATCH will only copy one of the representations. From w3c-dist-auth-request@w3.org Thu Jul 25 17:09:48 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21430 for ; Thu, 25 Jul 2002 17:09:47 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA24762; Thu, 25 Jul 2002 17:09:26 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6PL9OH18912; Thu, 25 Jul 2002 17:09:24 -0400 (EDT) Resent-Date: Thu, 25 Jul 2002 17:09:24 -0400 (EDT) Resent-Message-Id: <200207252109.g6PL9OH18912@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6PL9N718888 for ; Thu, 25 Jul 2002 17:09:23 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA24755 for ; Thu, 25 Jul 2002 17:09:23 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g6PL94028446 for ; Thu, 25 Jul 2002 14:09:04 -0700 (PDT) From: "Jim Whitehead" To: Date: Thu, 25 Jul 2002 14:07:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: X-UCSC-CATS-MailScanner: Found to be clean Subject: RE: Open issues with internationalization section Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6468 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > "...encoded, at minimum, using any mandatory encoding for which the > XML specification requires support." > > Note: this includes UTF-16. > > Does everybody agree to extend the encoding requirements to UTF-16? I think this is a good change, though I think it would be good for 2518bis to explicitly note that this means UTF-8 and UTF-16, since the mandatory encodings specified in the XML REC are not common knowledge. I think UTF-16 use would, at present, cause multiple interoperability problems. It would be very useful to add some UTF-16 tests to the Litmus compliance test tool, to strt moving the community in the right direction. - Jim From w3c-dist-auth-request@w3.org Thu Jul 25 17:12:26 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21543 for ; Thu, 25 Jul 2002 17:12:26 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA25889; Thu, 25 Jul 2002 17:11:58 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6PLBvP19445; Thu, 25 Jul 2002 17:11:57 -0400 (EDT) Resent-Date: Thu, 25 Jul 2002 17:11:57 -0400 (EDT) Resent-Message-Id: <200207252111.g6PLBvP19445@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6PLBu719425 for ; Thu, 25 Jul 2002 17:11:56 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA25877 for ; Thu, 25 Jul 2002 17:11:56 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g6PLBm029039 for ; Thu, 25 Jul 2002 14:11:48 -0700 (PDT) From: "Jim Whitehead" To: Date: Thu, 25 Jul 2002 14:10:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <27889B08CAEC7049B68FAD8717BA601736D8AE@ATL1VEXC006.usdom004.tco.tc> X-UCSC-CATS-MailScanner: Found to be clean Subject: RE: Doubt in error response Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6469 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > We use 412 Precondition Failed, which seems to be appropriate because > having a lock is a precondition to being able to unlock. > > Any objections to adding that in RFC2518bis? This is a good error code to use in this case. - jim From w3c-dist-auth-request@w3.org Fri Jul 26 09:46:12 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19733 for ; Fri, 26 Jul 2002 09:46:12 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA10222; Fri, 26 Jul 2002 09:45:22 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6QDiqS20884; Fri, 26 Jul 2002 09:44:52 -0400 (EDT) Resent-Date: Fri, 26 Jul 2002 09:44:52 -0400 (EDT) Resent-Message-Id: <200207261344.g6QDiqS20884@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6QDip720864 for ; Fri, 26 Jul 2002 09:44:51 -0400 (EDT) Received: from notes.informed.net (charcot.informed.net [205.167.80.72]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA10146 for ; Fri, 26 Jul 2002 09:44:50 -0400 From: horner@informed.net To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Fri, 26 Jul 2002 08:23:51 -0400 X-MIMETrack: Serialize by Router on notes.informed.net/informed dot net(Release 5.0.5 |September 22, 2000) at 07/26/2002 08:23:51 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: webDAV - macromedia dreamweaver ultradev - error trying to 'put' a file Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6470 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I am running Dreamweaver UltraDev 4.01 and having difficulty trying to 'put' my files onto the remote server. (I can 'get' files.) The server is running Apache 2.0 and WebDAV. For example, while using UltraDev with my page open, I can save the file locally. But when I 'put' this file, I receive the following 2 messages: The desired action could not be completed because the server is currently unavailable or misconfigured. An error occurred - cannot put filename.php. (The server has been restarting off and on as well but I don't know the details on this.) I am not the server administrator, and am not familiar with apache or webDAV. Can anyone suggest what might be going on? or what questions I need to ask the administrator? Any help is appreciated. Note - I have also posted this on the appropriate macromedia forum. Michelle Horner Outcome Technology Associates, Inc. From w3c-dist-auth-request@w3.org Fri Jul 26 17:10:37 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08998 for ; Fri, 26 Jul 2002 17:10:37 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA04394; Fri, 26 Jul 2002 17:10:09 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6QL9vZ28110; Fri, 26 Jul 2002 17:09:57 -0400 (EDT) Resent-Date: Fri, 26 Jul 2002 17:09:57 -0400 (EDT) Resent-Message-Id: <200207262109.g6QL9vZ28110@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6QL9i727431 for ; Fri, 26 Jul 2002 17:09:44 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA04077 for ; Fri, 26 Jul 2002 17:09:43 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g6QL9P817982; Fri, 26 Jul 2002 14:09:25 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" , Date: Fri, 26 Jul 2002 14:07:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: Submitted -09 Access Control Protocol Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6471 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit A new revision (-09) of the WebDAV Access Control Protocol has been submitted to the Internet-Drafts directory, and will appear there in the next few days. In the meanwhile, it is available on the webdav.org site in multiple renditions: Text (normative rendition): http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-09.txt PDF: http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-09.pdf Word: http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-09.doc HTML: http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-09.htm Sorry, no change tracking was performed, but the -08 revision is still available in Word and PDF at: http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-08.doc http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-08.pdf You can use the built-in document compare functionality of Word and Acrobat to compare versions. After five years of development, this specification is now complete, and is ready for review by our apps. area directors, the next step prior to approval by the IESG. Yeah! - Jim From w3c-dist-auth-request@w3.org Fri Jul 26 17:31:51 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09839 for ; Fri, 26 Jul 2002 17:31:51 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA10932; Fri, 26 Jul 2002 17:31:36 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6QLVZx05706; Fri, 26 Jul 2002 17:31:35 -0400 (EDT) Resent-Date: Fri, 26 Jul 2002 17:31:35 -0400 (EDT) Resent-Message-Id: <200207262131.g6QLVZx05706@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6QLVY705682 for ; Fri, 26 Jul 2002 17:31:34 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA10921 for ; Fri, 26 Jul 2002 17:31:33 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g6QLQZ820874; Fri, 26 Jul 2002 14:26:35 -0700 (PDT) From: "Jim Whitehead" To: "Ned Freed" , "Patrik Faltstrom" Cc: "WebDAV" , Date: Fri, 26 Jul 2002 14:24:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: Please review draft-ietf-webdav-acl-09 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6472 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ned, Patrik, After five years of work, the WebDAV Working Group has completed its design and specification work on the WebDAV Access Control Protocol, specified in draft-ietf-webdav-acl-09 (submitted earlier today). The WebDAV Working Group believes that the specification has resolved known design choices, is well understood, and has sufficient interest within the WebDAV community to be generally useful. The specification has gone through three separate working group last call for comments periods, as well as a substantial review process on the acl@webdav.org and w3c-dist-auth@w3.org mailing lists. At present there are two known server implementations of the protocol, and one known client implementation (which interoperates with the server implementations), with several additional efforts underway. One of the server implementations has integrated with multiple user management repositories, including an LDAP server. As a result, we have reasonable confidence that the specification is implementable on both the client and server side, and is capable of mapping the principals used in the specification to principals managed by user management systems. WebDAV WG hereby requests that you review this specification for consideration as a Proposed Standard RFC. - Jim Whitehead Co-Chair, IETF WebDAV Working Group From w3c-dist-auth-request@w3.org Sat Jul 27 12:18:02 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04220 for ; Sat, 27 Jul 2002 12:18:02 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA29620; Sat, 27 Jul 2002 12:17:25 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6RGHBM07410; Sat, 27 Jul 2002 12:17:11 -0400 (EDT) Resent-Date: Sat, 27 Jul 2002 12:17:11 -0400 (EDT) Resent-Message-Id: <200207271617.g6RGHBM07410@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6RGH8707388 for ; Sat, 27 Jul 2002 12:17:08 -0400 (EDT) Received: from smtp1.covad.net (psmtp1.array3.laserlink.net [63.65.123.51]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA29563 for ; Sat, 27 Jul 2002 12:17:08 -0400 Received: from masinter (h-66-134-206-106.SNVACAID.covad.net [66.134.206.106]) by smtp1.covad.net (8.9.3/8.9.3) with ESMTP id MAA06900; Sat, 27 Jul 2002 12:17:03 -0400 (EDT) From: "Larry Masinter" To: Cc: "'Webdav WG \(E-mail\)'" Date: Sat, 27 Jul 2002 09:17:32 -0700 Keywords: backed-up Message-ID: <000601c23589$1d874070$6ace8642@masinter> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <27889B08CAEC7049B68FAD8717BA601736D8B9@ATL1VEXC006.usdom004.tco.tc> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Web Character Model and IRI spec (Re: FW: character encoding.) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6473 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think that it would be great if the WebDAV spec could be clear about encodings in URIs, and the relationship between the HTTP URIs used in the protocol and the XML strings used in enumerations of collections. I'm not sure you need to make a normative reference to either the IRI spec or CHARMOD to do so, if you're concerned about establishing an unnecesary schedule dependency. This is because the IRI spec doesn't actually say the things that WebDAV needs to say in order to get interoperable implementations -- what is the expected behavior of WebDAV user agents when showing strings to the users? This has been an issue in interops already, not just for I18N, but also for simple URL encoding, e.g., of file names with spaces in them. Larry From w3c-dist-auth-request@w3.org Mon Jul 29 06:51:22 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23344 for ; Mon, 29 Jul 2002 06:51:22 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA24283; Mon, 29 Jul 2002 06:50:32 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6TAnwb18666; Mon, 29 Jul 2002 06:49:58 -0400 (EDT) Resent-Date: Mon, 29 Jul 2002 06:49:58 -0400 (EDT) Resent-Message-Id: <200207291049.g6TAnwb18666@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6TAnu718642 for ; Mon, 29 Jul 2002 06:49:56 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id GAA24168 for ; Mon, 29 Jul 2002 06:49:55 -0400 Received: (qmail 2946 invoked by uid 0); 29 Jul 2002 10:49:24 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp002-rz3) with SMTP; 29 Jul 2002 10:49:24 -0000 From: "Julian Reschke" To: "Larry Masinter" , Cc: "'Webdav WG \(E-mail\)'" Date: Mon, 29 Jul 2002 12:49:22 +0200 Keywords: backed-up Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <000601c23589$1d874070$6ace8642@masinter> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Web Character Model and IRI spec (Re: FW: character encoding.) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6474 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Larry Masinter > Sent: Saturday, July 27, 2002 6:18 PM > To: tai@iij.ad.jp > Cc: 'Webdav WG (E-mail)' > Subject: RE: Web Character Model and IRI spec (Re: FW: character > encoding.) > > > > I think that it would be great if the WebDAV spec > could be clear about encodings in URIs, and the > relationship between the HTTP URIs used in the protocol > and the XML strings used in enumerations of collections. > I'm not sure you need to make a normative reference to > either the IRI spec or CHARMOD to do so, if you're concerned > about establishing an unnecesary schedule dependency. > > This is because the IRI spec doesn't actually say the > things that WebDAV needs to say in order to get interoperable > implementations -- what is the expected behavior of > WebDAV user agents when showing strings to the users? > > This has been an issue in interops already, not just > for I18N, but also for simple URL encoding, e.g., of > file names with spaces in them. OK, what do we need to specify: 1) display of member names in collections: take the last URI segment, then URL-unescape, then UTF-8-decode 2) creation of new resources: 2a) all URI segments MUST be UTF-8-decodable after URL-unescaping 2b) if the "local display name" (for instance document name when typing into file selector box) contains non-ASCII characters, it MUST be UTF-8 encoded then URL-escaped. 3) Forbid member names in collections that aren't Unicode-normalized after URL-de-escaping and UTF-8-decoding. Opinions? Julian From w3c-dist-auth-request@w3.org Mon Jul 29 08:37:57 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26990 for ; Mon, 29 Jul 2002 08:37:57 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA08260; Mon, 29 Jul 2002 08:37:45 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6TCbiv26176; Mon, 29 Jul 2002 08:37:44 -0400 (EDT) Resent-Date: Mon, 29 Jul 2002 08:37:44 -0400 (EDT) Resent-Message-Id: <200207291237.g6TCbiv26176@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6TCbg726121 for ; Mon, 29 Jul 2002 08:37:42 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA08232; Mon, 29 Jul 2002 08:37:41 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Mon, 29 Jul 2002 08:29:24 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 29 Jul 2002 08:37:09 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B107A5CCAD@SUS-MA1IT01> From: "Clemm, Geoff" To: ietf-dav-versioning@w3.org, "WebDAV (E-mail)" Date: Mon, 29 Jul 2002 08:37:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g6TCbg726121 Subject: RE: Derived objects Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6475 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit From: Marc Girod [mailto:girod@stybba.ntc.nokia.com] As far as I understood, WebDAV/Delta V is only concerned with *version control* of static components. Many web pages are however dynamically generated. One could even argue that there is a fundamental granularity problem: the grain suitable for maintenance (and for sharing) is finer than this suitable for navigation. Is there a provision to cope with this issue? The only support in WebDAV/DeltaV for derived resources is the DAV:source property, and there recently has been a significant amount of debate in the WebDAV mailing list on whether this property should be kept as is, removed, or changed. If you are interested in derived resources, it would be good if you could review this thread, and indicate whether this property would be suitable for the use cases you are concerned with, and if not, how it could be changed to be suitable. Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Jul 29 11:18:23 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03575 for ; Mon, 29 Jul 2002 11:18:22 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA25525; Mon, 29 Jul 2002 11:17:58 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6TFHsF18926; Mon, 29 Jul 2002 11:17:54 -0400 (EDT) Resent-Date: Mon, 29 Jul 2002 11:17:54 -0400 (EDT) Resent-Message-Id: <200207291517.g6TFHsF18926@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6TFHr718906 for ; Mon, 29 Jul 2002 11:17:53 -0400 (EDT) Received: from smtpout.mac.com ([204.179.120.97]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA25518 for ; Mon, 29 Jul 2002 11:17:53 -0400 Received: from smtp-relay04-en1.mac.com (smtp-relay04-en1 [10.13.10.223]) by smtpout.mac.com (8.12.1/8.10.2/1.0) with ESMTP id g6TFHl9p013203 for ; Mon, 29 Jul 2002 08:17:47 -0700 (PDT) Received: from asmtp01.mac.com (asmtp01-qfe3.mac.com [10.13.10.65]) by smtp-relay04-en1.mac.com (8.12.1/8.12.1/1.0) with ESMTP id g6TFHl72020674 for ; Mon, 29 Jul 2002 08:17:47 -0700 (PDT) Received: from [192.168.1.6] ([209.42.182.147]) by asmtp01.mac.com (Netscape Messaging Server 4.15) with ESMTP id H00NTL00.OG1; Mon, 29 Jul 2002 08:17:45 -0700 Mime-Version: 1.0 X-Sender: desoi@mail.mac.com Message-Id: Date: Mon, 29 Jul 2002 11:15:40 -0400 To: "WebDAV" From: John DeSoi Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Mac OS X Client implementation issues Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6476 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Hi, Apologies if this is not the right list for this discussion. Pointers greatly appreciated. The OS X WebDAV client appears to send the same request multiple times (on different connections). For example, it sent "PROPFIND /" 8 times to my WebDAV server when I first logged in. Is there any reasonable explanation for this? Seems like an incredible waste of resources for both sides. Is there anything I can set on the server side to prevent this? Does anyone know the appropriate place to send feedback to Apple on this? Thanks very much, John DeSoi, Ph.D. From w3c-dist-auth-request@w3.org Mon Jul 29 12:37:28 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06830 for ; Mon, 29 Jul 2002 12:37:27 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA14073; Mon, 29 Jul 2002 12:37:15 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6TGbAf05828; Mon, 29 Jul 2002 12:37:10 -0400 (EDT) Resent-Date: Mon, 29 Jul 2002 12:37:10 -0400 (EDT) Resent-Message-Id: <200207291637.g6TGbAf05828@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6TGb9705808 for ; Mon, 29 Jul 2002 12:37:09 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA14045 for ; Mon, 29 Jul 2002 12:37:08 -0400 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g6TGaaA11005 for ; Mon, 29 Jul 2002 09:36:36 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 29 Jul 2002 09:35:57 -0700 Received: from luthji.apple.com (luthji.apple.com [17.202.43.76]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g6TGaaT24868; Mon, 29 Jul 2002 09:36:36 -0700 (PDT) Date: Mon, 29 Jul 2002 09:36:13 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v540) Cc: WebDAV To: John DeSoi From: Jim Luther In-Reply-To: Message-Id: <4B854269-A311-11D6-A391-0003934B6A22@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.540) Subject: Re: Mac OS X Client implementation issues Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6477 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit John, The problem you described below has already been written up and fixed as Bug IDs #2929972 "webdavfs uses a different socket pair for each transaction" and #2986553 "statfs requests that might go to the server should be serialized" (I noticed the first problem a couple of months ago and the second a few weeks ago). However, anytime you see something you think is wrong or can be improved in the Mac OS X WebDAV file system, feel free to write up a report. The correct way to send bug reports and enhancement requests for any Apple product can be found at . The component for WebDAV file system bugs is "WebDAV FS" version "X". Thanks, Jim Luther Apple Computer, Inc. On Monday, July 29, 2002, at 08:15 AM, John DeSoi wrote: > Hi, > > Apologies if this is not the right list for this discussion. Pointers > greatly appreciated. > > The OS X WebDAV client appears to send the same request multiple times > (on different connections). For example, it sent "PROPFIND /" 8 times > to my WebDAV server when I first logged in. Is there any reasonable > explanation for this? Seems like an incredible waste of resources for > both sides. Is there anything I can set on the server side to prevent > this? Does anyone know the appropriate place to send feedback to Apple > on this? > > Thanks very much, > > > John DeSoi, Ph.D. From w3c-dist-auth-request@w3.org Tue Jul 30 07:57:42 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13598 for ; Tue, 30 Jul 2002 07:57:42 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA32210; Tue, 30 Jul 2002 07:56:42 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6UBuWs12445; Tue, 30 Jul 2002 07:56:32 -0400 (EDT) Resent-Date: Tue, 30 Jul 2002 07:56:32 -0400 (EDT) Resent-Message-Id: <200207301156.g6UBuWs12445@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6UBuU712421 for ; Tue, 30 Jul 2002 07:56:30 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA32141 for ; Tue, 30 Jul 2002 07:56:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13491; Tue, 30 Jul 2002 07:55:21 -0400 (EDT) Message-Id: <200207301155.HAA13491@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 30 Jul 2002 07:55:21 -0400 Subject: I-D ACTION:draft-ietf-webdav-acl-09.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6478 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : WebDAV Access Control Protocol Author(s) : G. Clemm, A. Hopkins, E. Sedlar, J. Whitehead Filename : draft-ietf-webdav-acl-09.txt Pages : 66 Date : 29-Jul-02 This document specifies a set of methods, headers, message bodies, properties, and reports that define Access Control extensions to the WebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such as HyperText Transfer Protocol (HTTP) method invocations) by a given principal. A lightweight representation of principals as Web resources supports integration of a wide range of user management repositories. Search operations allow discovery and manipulation of principals using human names. This document is a product of the Web Distributed Authoring and Versioning (WebDAV) working group of the Internet Engineering Task Force. Comments on this draft are welcomed, and should be addressed to the acl@webdav.org mailing list. Other related documents can be found at http://www.webdav.org/acl/, and http://www.ics.uci.edu/pub/ietf/webdav/. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-acl-09.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-acl-09.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-acl-09.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: <20020729151345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-acl-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-acl-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020729151345.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Tue Jul 30 09:47:57 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17921 for ; Tue, 30 Jul 2002 09:47:57 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA26292; Tue, 30 Jul 2002 09:47:21 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6UDlJt23130; Tue, 30 Jul 2002 09:47:19 -0400 (EDT) Resent-Date: Tue, 30 Jul 2002 09:47:19 -0400 (EDT) Resent-Message-Id: <200207301347.g6UDlJt23130@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6UDlI723110 for ; Tue, 30 Jul 2002 09:47:18 -0400 (EDT) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA26276 for ; Tue, 30 Jul 2002 09:47:17 -0400 Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id WAA01542 for ; Tue, 30 Jul 2002 22:47:15 +0900 (JST) Received: from pekoe.iij.ad.jp (pekoe.iij.ad.jp [192.168.4.173]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with SMTP id WAA11524 for ; Tue, 30 Jul 2002 22:47:14 +0900 (JST) Received: (nullmailer pid 32209 invoked by uid 5292); Tue, 30 Jul 2002 13:46:24 -0000 To: Webdav WG References: <000601c23589$1d874070$6ace8642@masinter> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Taisuke Yamada Date: Tue, 30 Jul 2002 22:46:23 +0900 In-Reply-To: (Julian Reschke's message of "Mon, 29 Jul 2002 12:49:22 +0200") Message-ID: Lines: 39 User-Agent: T-gnus/6.15.6 (based on Oort Gnus v0.06) (revision 01) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1 (AOI) Subject: Re: Web Character Model and IRI spec (Re: FW: character encoding.) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6479 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > OK, what do we need to specify: > > 1) display of member names in collections: take the last URI > segment, then URL-unescape, then UTF-8-decode > > 2) creation of new resources: > > 2a) all URI segments MUST be UTF-8-decodable after URL-unescaping > 2b) if the "local display name" (for instance document name when > typing into file selector box) contains non-ASCII characters, > it MUST be UTF-8 encoded then URL-escaped. > > 3) Forbid member names in collections that aren't > Unicode-normalized after URL-de-escaping and UTF-8-decoding. Yes, these should cover most of the requirements. But rather than specifying each case separately, it might be easier to say all strings derived from, or related to resource URI to fullfill following requirements: - All URI segments MUST be URL-escaped after converted into "normalized form" of UTF-8 string. - Each implementation MUST do the necessary conversion between above form and "local representation" of the resource (name typed in selector box, name stored on client/server filesystem, etc.). For 2b, you don't need to handle ASCII/non-ASCII cases separately since UTF-8 covers ASCII. Also, adding notes on several HTTP headers such as Destination: and Status-URI: might be needed as they seem to be protocol-specific headers. Regards, -- Taisuke Yamada Internet Initiative Japan Inc., Technical Planning Division From w3c-dist-auth-request@w3.org Wed Jul 31 00:27:55 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19921 for ; Wed, 31 Jul 2002 00:27:55 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA15894; Wed, 31 Jul 2002 00:27:34 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6V4RAv00977; Wed, 31 Jul 2002 00:27:10 -0400 (EDT) Resent-Date: Wed, 31 Jul 2002 00:27:10 -0400 (EDT) Resent-Message-Id: <200207310427.g6V4RAv00977@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6V4R8700957 for ; Wed, 31 Jul 2002 00:27:08 -0400 (EDT) Received: from cobain.capfed1.sinectis.com.ar (IDENT:root@cobain.capfed1.sinectis.com.ar [216.244.192.67]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA15780 for ; Wed, 31 Jul 2002 00:27:07 -0400 Received: from FERNANDO (modem81-tc9.capfed1.sinectis.com.ar [216.244.205.81]) by cobain.capfed1.sinectis.com.ar with SMTP id BAA03470 for ; Wed, 31 Jul 2002 01:26:46 -0300 From: "Fernando Claverino" To: Date: Wed, 31 Jul 2002 01:22:55 -0300 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C23830.CC43B450" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Subject: webdav and internet explorer Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6480 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C23830.CC43B450 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi I'm trying to do a webdav server that must be work with internet explorer and I have some dificults. Somebody knows how is exactly the sequence of messages between webdav server and ie for connect and retrive a collection of files?. For example, in the server's root I have 2 files. How is the sequence of messages for connect and retrive this 2 files to the browser (and see this like files in a folder). Or if somebody knows where is documentation, is welcome too thanks, below I write the sequence that I do: ie send: ---------------------------------------------------------------------------- - OPTIONS / HTTP/1.1 User-Agent: Microsoft Data Access Internet Publishing Provider Cache Manager Host: localhost:81 Content-Length: 0 Connection: Keep-Alive webdav server send: --------------------------------------- HTTP/1.1 200 OK DASL: DAV: 1 Public: OPTIONS, GET, HEAD, DELETE, PUT, PROPFIND Allow: OPTIONS, GET, HEAD, DELETE, PUT, PROPFIND ie send: ---------------------------------------------------------------------------- - GET /_vti_inf.html HTTP/1.1 Date: Wed, 31 Jul 2002 03:02:08 GMT MIME-Version: 1.0 Accept: */* User-Agent: Mozilla/2.0 (compatible; MS FrontPage 4.0) Host: localhost:81 Accept: auth/sicily Content-Length: 0 Connection: Keep-Alive Cache-Control: no-cache webdav send --------------------------------------- HTTP/1.1 200 OK ie send ---------------------------------------------------------------------------- - POST /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1 Date: Wed, 31 Jul 2002 03:02:08 GMT MIME-Version: 1.0 User-Agent: MSFrontPage/4.0 Host: localhost:81 Accept: auth/sicily Content-Length: 41 Content-Type: application/x-www-form-urlencoded X-Vermeer-Content-Type: application/x-www-form-urlencoded Connection: Keep-Alive Cache-Control: no-cache method=server+version%3a4%2e0%2e2%2e4715 ie send: ---------------------------------------------------------------------------- - OPTIONS / HTTP/1.1 Accept-Language: es-ar, en-us;q=0.2 User-Agent: Microsoft Data Access Internet Publishing Provider DAV 1.1 Host: localhost:81 Content-Length: 0 Connection: Keep-Alive webdav send --------------------------------------- HTTP/1.1 200 OK DASL: DAV: 1 Public: OPTIONS, GET, HEAD, DELETE, PUT, PROPFIND Allow: OPTIONS, GET, HEAD, DELETE, PUT, PROPFIND ie send ---------------------------------------------------------------------------- - PROPFIND / HTTP/1.1 Accept-Language: es-ar, en-us;q=0.2 Content-Type: text/xml Translate: f Content-Length: 0 Depth: 0 User-Agent: Microsoft Data Access Internet Publishing Provider DAV 1.1 Host: localhost:81 Connection: Keep-Alive webdav send --------------------------------------- HTTP/1.1 207 Multi-Status Server: Microsoft-IIS/5.0 Date: Wed, 31 Jul 2002 01:15:47 GMT Content-Location: http://localhost:81/ Content-Type: text/xml Transfer-Encoding: chunked http://localhost: 81/HTTP/1.1 200 OK02001 -04-26T20:25:44.568Zcluboha< a:ge tetag>"a0ccc7271638c21:19177"Tue, 30 Jul 2002 22:12:12 GMT0 1application/o ctet-stream --------------------------------------- Cierro al socket que habla ------=_NextPart_000_0000_01C23830.CC43B450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi
 
I'm = trying to do a=20 webdav server that must be work with internet explorer and I have some=20 dificults. Somebody knows how is exactly the sequence of messages = between webdav=20 server and ie for connect and retrive a collection of files?. For=20 example, in the server's root I have 2 files. How is the sequence = of=20 messages for connect and retrive this 2 files to the browser (and see = this like=20 files in a folder).
Or if = somebody knows=20 where is documentation, is welcome too
 
thanks,
 
 
below = I write the=20 sequence that I do:
 
 
ie=20 send:
----------------------------------------------= -------------------------------
OPTIONS=20 / HTTP/1.1
User-Agent: Microsoft Data Access Internet Publishing = Provider=20 Cache Manager
Host: localhost:81
Content-Length: 0
Connection:=20 Keep-Alive
 
webdav server=20 send:
---------------------------------------
HTTP/1.1 200=20 OK
DASL: <DAV:sql>
DAV: 1
Public: OPTIONS, GET, HEAD, = DELETE,=20 PUT, PROPFIND
Allow: OPTIONS, GET, HEAD, DELETE, PUT, = PROPFIND
 
ie=20 send:
----------------------------------------------------------------= -------------
GET=20 /_vti_inf.html HTTP/1.1
Date: Wed, 31 Jul 2002 03:02:08 = GMT
MIME-Version:=20 1.0
Accept: */*
User-Agent: Mozilla/2.0 (compatible; MS FrontPage=20 4.0)
Host: localhost:81
Accept: auth/sicily
Content-Length:=20 0
Connection: Keep-Alive
Cache-Control: no-cache
 
webdav send
---------------------------------------
HTTP/1.1 200 = OK
 
ie=20 send
----------------------------------------------------------------= -------------
POST=20 /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1
Date: Wed, 31 Jul 2002 03:02:08 = GMT
MIME-Version: 1.0
User-Agent: MSFrontPage/4.0
Host:=20 localhost:81
Accept: auth/sicily
Content-Length: = 41
Content-Type:=20 application/x-www-form-urlencoded
X-Vermeer-Content-Type:=20 application/x-www-form-urlencoded
Connection: = Keep-Alive
Cache-Control:=20 no-cache
 
method=3Dserver+version%3a4%2e0%2e2%2e4715
 
ie send:
----------------------------------------------------------------= -------------
OPTIONS=20 / HTTP/1.1
Accept-Language: es-ar, en-us;q=3D0.2
User-Agent: = Microsoft Data=20 Access Internet Publishing Provider DAV 1.1
Host:=20 localhost:81
Content-Length: 0
Connection: Keep-Alive
 
webdav send
---------------------------------------
HTTP/1.1 200 = OK
DASL:=20 <DAV:sql>
DAV: 1
Public: OPTIONS, GET, HEAD, DELETE, PUT,=20 PROPFIND
Allow: OPTIONS, GET, HEAD, DELETE, PUT, = PROPFIND
 
ie=20 send
----------------------------------------------------------------= -------------
PROPFIND=20 / HTTP/1.1
Accept-Language: es-ar, en-us;q=3D0.2
Content-Type:=20 text/xml
Translate: f
Content-Length: 0
Depth: 0
User-Agent: = Microsoft Data Access Internet Publishing Provider DAV 1.1
Host:=20 localhost:81
Connection: Keep-Alive
 
webdav send
---------------------------------------
HTTP/1.1 207=20 Multi-Status
Server: Microsoft-IIS/5.0
Date: Wed, 31 Jul 2002 = 01:15:47=20 GMT
Content-Location: http://localhost:81/
Content-Type:=20 text/xml
Transfer-Encoding: chunked
 

<?xml = version=3D"1.0"?><a:multistatus=20 xmlns:b=3D"urn:uuid:c2f41010-65b3-11d1-a29f-00
aa00c14882/" = xmlns:c=3D"xml:"=20 xmlns:a=3D"DAV:"><a:response><a:href>http://localhost:
= 81/</a:href><a:propstat><a:status>HTTP/1.1=20 200 OK</a:status><a:prop><a:getconten
tlength=20 b:dt=3D"int">0</a:getcontentlength><a:creationdate=20 b:dt=3D"dateTime.tz">2001
-04-26T20:25:44.568Z</a:creationdate&g= t;<a:displayname>cluboha</a:displayname><a:ge
tetag>= "a0ccc7271638c21:19177"</a:getetag><a:getlastmodified=20 b:dt=3D"dateTime.rfc11
23">Tue, 30 Jul 2002 22:12:12=20 GMT</a:getlastmodified><a:resourcetype><a:collecti
on/&= gt;</a:resourcetype><a:supportedlock/><a:ishidden=20 b:dt=3D"boolean">0</a:ishidden>
<a:iscollection=20 b:dt=3D"boolean">1</a:iscollection><a:getcontenttype>appli= cation/o
ctet-stream</a:getcontenttype></a:prop></a:pro= pstat></a:response></a:multistatus
>
---------------= ------------------------
Cierro=20 al socket que habla
------=_NextPart_000_0000_01C23830.CC43B450-- From w3c-dist-auth-request@w3.org Wed Jul 31 08:03:57 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22500 for ; Wed, 31 Jul 2002 08:03:57 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA19506; Wed, 31 Jul 2002 08:02:46 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6VC2dV09571; Wed, 31 Jul 2002 08:02:39 -0400 (EDT) Resent-Date: Wed, 31 Jul 2002 08:02:39 -0400 (EDT) Resent-Message-Id: <200207311202.g6VC2dV09571@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6VC2c709551 for ; Wed, 31 Jul 2002 08:02:38 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA19476 for ; Wed, 31 Jul 2002 08:02:38 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Wed, 31 Jul 2002 07:54:16 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Wed, 31 Jul 2002 08:02:07 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B107A5D29A@SUS-MA1IT01> From: "Clemm, Geoff" To: "'Webdav WG (E-mail)'" Date: Wed, 31 Jul 2002 08:02:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6481 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: It appears below that Julian and I agree on most aspects of this issue, with the only remaining question being "what kind of URI should be placed in a DAV:dst field". I believe that the answer will always be somewhat vague, and of the form "a URI that the user can effectively use to author (i.e. modify the content of) the resource". In order to author a resource via the DAV:dst URI, minimally, you have to locate the resource (i.e. the URI must be a URL), but further, you then need to be able to modify/author that resource once you've located it (but we don't have an acronym for an "authorable resource"). I also believe that it would be valuable to have a standard property that identifies a URN for a resource, and that is one goal of the binding spec (which we should be able to finish up as soon as we have the ACL spec wrapped up). In particular, the binding spec introduces the DAV:urn property for this purpose. I wouldn't want the DAV:source property confused with the DAV:urn property. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Sunday, July 14, 2002 1:51 PM To: Clemm, Geoff; 'Webdav WG (E-mail)' Subject: RE: Issue: URI_URL, proposed changes > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Sunday, July 14, 2002 5:45 PM > To: 'Webdav WG (E-mail)' > Subject: RE: Issue: URI_URL, proposed changes > > > > On the off chance that the details of this particular thread > are probably becoming less interesting to anyone other than > Julian and myself (:-), I'll just summarize my position: > > - We should adhere to the RFC-2396 definitions of URI, URL, and URN, > since no problems with those definitions have been identified. I do > not consider the fact that many people don't know/use those > definitions to be a problem, since the "commonly held" definitions > incorrectly consider URL and URN as partitioning the URI space > (i.e. problems have been identified with those "commonly held" > definitions). We could try to make up yet another definition (that > is different from both RFC-2396 and the "commonly held" definitions) > but I see no point in doing so. > > - We should use "URL" or "URN" in 2518bis whenever we are defining a URI > that has the semantic properties of a URL or a URN (as defined by 2396). I agree, as long as the wording makes clear what is meant. > Specific responses to Julian's most recent comments embedded below. > > Cheers, > Geoff > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > > > URL-references). We also have some URIs which name a > resource > > > > (in particular, lock tokens). These should be called URNs. > > > > > > I disagree. URLs are just a subset of URIs. > > > > > > We don't disagree there. > > > > RFC2518 has defined that lock tokens are identified by > URIs with no > > restriction. > > > > That is incorrect. The first line of section 6.4 (that > defines a lock > > token URI) states: "The opaquelocktoken URI scheme is designed to be > > unique across all resources for all time." That makes an > > opaquelocktoken URI a URN, and disallows using non-URN URIs. > > Wrong. Lock tokens are defined in section 6.3. > > It is true that I quoted the wrong section. But if you read section > 6.3, it says the same thing, i.e.: "Lock token URIs MUST be unique > across all resources for all time." That requires all lock token > URIs to satisfy the definition of a URN, which defines each lock > token URI to be a URN. Yes. > Section 6.4 defines a particular URI scheme that *can* be used to > identify locks. It doesn't say that you need to use it to represent > lock tokens :"This specification provides a lock token URI scheme > called opaquelocktoken that meets the uniqueness > requirements. However resources are free to return any URI scheme > so long as it meets the uniqueness requirements." > > And "meeting the uniqueness requirements" makes it a URN. Yes. > > An attempt to restrict lock tokens to specific URI types (are > > you trying to do that?) > > > > No, I have (several times :-) emphasized that whether or not a URI > > is a URL or URN does not require that the URI belong to a specific > > URI type. A URI in any scheme can be a URL, if it can be used to > > apply a method to the resource identified by that URI. A URI in any > > scheme can be a URN if it satisfies the semantics > requirement of a URN. > > I don't have any problem with that definition, however I'm sure > that 99% of the readers will have the same definitions of URL/URN > in mind when they read the spec, thus I fear unnecessary confusion. > > Then all we have to do is explicitly repeat this definition in the > terminology section of the revised version of 2518, supplemented > with a reference to 2396. Fine with me. > > This is an excellent example of why we should carefully use URI, > > URL, and URN in the spec. The statement in section 13.10 of the spec > > is potentially ambiguous. In particular, it states: "there is > > typically only one destination (dst) of the link, which is the URI > > where the unprocessed source of the resource may be accessed." I > > interpreted the "typically" to just be a qualifier of "only one". It > > sounds like you interpreted "typically" to also be a qualifier of the > > phrase following the comma (while I interpreted it as a definition of > > "link"). I believe my interpretation is correct, because without > > that, the source link is basically useless ... "here's is a > URI of the > > source, but you can't use it for anything of interest". > > I have stopped thinking about the current wording for the > source property > a > long time ago. It doesn't make sense. It defines a resource property > (DAV:source), which contains the name of the resource itself as an > element > (DAV:src). It just doesn't make sense (one of the reasons I raised the > issue > in the issues document). > > I don't see that this needs to be a complicated issue. The DAV:src > field allows you to indicate that multiple resources depend > on this link, to give the client an indication of all the other > resources that would be affected by authoring the DAV:dst of that > link. For Web content management, an example of this would be a > "template" resource from which a large number of other resources are > derived. In this particular example, the number of other resources is > so large that I think it unlikely that a server would ever enumerate > them in the DAV:src field. Because I think this will commonly be the > case, I'd be happy to deprecate the DAV:src field in the revision of > 2518. I personally would also like to rename the DAV:dst element to > just be a DAV:href element (for interoperation with the > DAV:expand-property REPORT), but that depends on whether any clients > are really using DAV:link and therefore expects DAV:dst (current > indications are that there are no such clients, so it would be > safe to make this change). Agreed. > > Example: I might want to have a source link from > > http://greenbytes.de/tech/webdav/rfc3253.html > > to > > urn:ietf:rfc:3253 > > Do you say this is wrong? > > > > Yes, it is wrong if urn:ietf:rfc:3253 is not a URL (i.e. cannot be > > used to apply methods such as GET and PUT to the resource that it > > identifies). But of course, urn:ietf:rfc:3253 easily could be a URL, > > in which case it would be fine. > > I disagree. "urn:ietf:rfc:3253" is a URN for a resource. Actually, > it is *the* URN endorsed by the IETF to identify the versioning > spec. If I want to signal that a document depends on a source > which is a RFC, it completely makes sense to refer to it this way. > > I believe the central value of the DAV:source field is that it allows > the client to perform methods on the resource identified by the > DAV:dst field to cause changes to the content of the resource. This > value is not provided if the URI in the DAV:dst field is not a URL. > Having a URI that is not a URL would not provide a mechanism for > the client to effectively author the resource, which leads me to > conclude that the spec should require the DAV:dst field to be a URL. I don't buy that. You seem to argue that if a source for a document is not authorable (which actually is the case in my example), then it's not worth mentioning it as source. I think this is wrong. > BTW: Can you define what "applicable to methods such as GET and > PUT" means? Is "mailto:" a URL scheme? > > It probably would be valuable to identify a minimal set of methods > that SHOULD be applicable to the DAV:dst URL, in order to provide for > interoperation. Perhaps: "Either GET/PUT or PROPFIND/PROPPATCH SHOULD > be supported on the DAV:dst URL". It seems that you now require the URL to be either a http: or https: based one. What about "mid:" or "ftp:"? These schemes define locations, but do not have a concept of "methods". See Roy's comment in : "That is not relevant. The resources might just as easily be ftp or file URLs, or might only be authorable by someone with authorization or coming from a particular IP address. Identifying the source does not imply authorability on that resource, nor does it need to in order to be useful to the user." > > > "there is typically only one destination (dst) of the link, > > > which is the URI where the unprocessed source of the resource > > > may be accessed." > > ... it probably makes little sense to argue about this paragraph > unless we can find somebody who can explain what was intended. The > DAV:source property *as defined* doesn't make sense (see above). > > Do you just mean the lack of utility of the DAV:src element? That's > easily resolved by deprecating the DAV:src element. Then we just > rewrite that section as: > "The destination (dst) of the link is the URL where an unprocessed > source of the resource may be accessed. Typically there is only one > DAV:dst element, but there could be multiple if the resource content > is derived from multiple inputs." I disagree with the attempt to (now) require the source to be identified by a URL. It doesn't help the client at all. Even if the server firmly believes that a URI has "locator" quality, it can never be sure that the client agrees (== has the same resolver software installed). Except of course it happens to be an http: URL. > > could be located, but no software has ever been written to locate it > > using that URI scheme, is it a URL? (I say, no). But most cases are > > clearer. The point is, what can a client assume. Can it assume that > > it should be able to apply methods to the resource through that URI? > > But what is this knowledge good for? Unless the client happens to > *know* the URI scheme, it won't be able to do anything useful with > the URI (other than use it as identifier), even if it knows it to > be a "locator". > > Of course a particular client may not have the software to access that > URL, or the server that should be responsible for applying methods to > that resource may not actually do so. What we are trying to avoid is > having implementors misunderstand the semantics of a particular > field. This > gives the client and server writers essential guidance wrt what kind > of URI they should allow in a particular field. With the example above, Given an arbitrary URI, what is the mechanism I can apply to it to find out whether it has the URL-property? > if we decide that the DAV:dst field should contain a URL, then a server > should not store a urn: URI that they know is not commonly supported > by clients and servers to apply methods to that resource. I completely disagree, unless you can describe a sane algorithm that makes this decision. > > Resources never are *available* at a URI. > > > > That will come as a surprise to the authors (and reviewers) of > > RFC 2518 (:-). In the section we have been discussing, and which > > I have been quoting) states: "A resource may be made available > > through more than one URI." > > Another thing we may want to fix. > > If it ain't broke, don't fix it (and in this case, if it ain't broke, > don't break it :-). > > > *Representations* of resources may be available. I think you are > > saying that any URI that can be used to locate a representation of > > a resource is a URL. > > > > I am just using terminology in the same way it is used in > > 2518. One can certainly make the statement more detailed in > > the way you have above, but I think the 2518 usage is fine. > > Probably not. People may get the impression that WebDAV somehow > magicallly > allows to do something HTTP can't (and doesn't attempt to). HTTP's GET > retrieves *representations* of resources. WebDAV doesn't change that. > > But WebDAV isn't just talking about GET ... it also talking about > PROPFIND and others. Saying that a resource is available says that > there are methods that can be applied to that URI that will not fail. Maybe this definition should be added somewhere... > In particular, some resources that are "available" do not support > GET, so we are not talking about the "availability of the representation". Such as? Just because the spec doesn't define the *specific* behaviour for GET, this doesn't mean that GET should fail. Do you propose to fail an attempt to GET a representation of a VHR? If so, what HTTP response code would you propose? 204 (no content) seems to make sense, but it wouldn't be a failure code, thus the VHR *would* support GET. > For instance, GET/PROPFIND followed by PUT/PROPPATCH is not > guaranteed to do the same thing as COPY (even when not taking > versioning/acl into account). > > "Availability" says nothing about the semantics of successive operations. > It just says that a method can be applied to that URI and succeed. So it can be any method? For instance, if GET on a URI returns 404, can I say that the resource identified by "a" is "available", just because a PUT on it would succeed? > > That may be technically correct (so *I* can basically turn every > > URN into a URL by implementing a resolver for the scheme). > > > > And if such a resolver becomes so widespread that a client can > > reasonably count on it being available, it is a URL. > > Who is the authority I can ask whether a particular URI scheme can > "now" be considered a URL? Actually, if Microsoft decides not to > support "gopher:" anymore -- does the gopher URI loose it's > URL-property? > > Is indicated earlier, this is not a formally demonstrable property > of a URI (such as its syntax). It is a qualitative property, and there > will be grey areas. And yes, if a URI scheme is no longer widely > implemented, the URIs in that scheme are no longer URLs. And similarly, So what happens to URLs using that scheme that happen to be already stored in DAV:source properties? Would it be illegal for a server to keep them? How would the server know that something it accepted in the past as valid URL has lost it's URL property? > if a urn: scheme is widely implemented to not provide globally unique > naming, then a URI in that urn: scheme would not be a URN. The concepts > of URN and URI are worthless if they just refer to some syntactic > notion (e.g. "has a scheme name that begins with the characters 'u', > 'r', and 'n'). Yes. I didn't propose that interpretation. > > If you agree that a HTTP URL can be used to identify a lock token, > > thus it *is* both a URN and a URL, could you please give > an example > > of a HTTP URL that doesn't share these properties (thus *isn't* a > > URN)? > > > > Sure. http://www.webdav.org/deltav/protocol/index.html. I > personally > > have associated that URL with different resources over time, because > > of various bad interactions with locking (at least, I think that was > > the problem). If that resource had a URN property, such as a > > DAV:version-history, you would have been able to notice as much. > > The same is true for most (probably all) resources on > > http://www.webdav.org (although there are some links to some http > > URNs in the http://www.ietf.org/ namespace. > > Well, that's partly a question of how you define a resource. Note > that even though a HTTP resource is implemented inside a specific > HTTP server, that doesn't necessarily mean that it changes just > because internally the implementation of the resource changed. > > That is of course true. Just like the concepts of a URN and URL, the > concept of "object identity" has fuzzy boundaries (in all domains, > not just IETF protocols). As we introduce more advanced protocol > funtionality (versioning, binding), these boundaries start to get > firmed up though. In particular, those protocol extensions make it > clear that MOVE associates an existing resource (with a given identity) > with a different URI, while COPY creates a new resource (whose identity > is different from the resource that was the source of the COPY). It will still depend on the point of view. From the client's perspective, it's really irrelevant whether the internal implementation has changed, as long as the abstract resource identified by the URI is the same. From w3c-dist-auth-request@w3.org Wed Jul 31 13:31:52 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08897 for ; Wed, 31 Jul 2002 13:31:52 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA13778; Wed, 31 Jul 2002 13:31:34 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6VHV9C11921; Wed, 31 Jul 2002 13:31:09 -0400 (EDT) Resent-Date: Wed, 31 Jul 2002 13:31:09 -0400 (EDT) Resent-Message-Id: <200207311731.g6VHV9C11921@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6VHV6711897 for ; Wed, 31 Jul 2002 13:31:06 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA13612 for ; Wed, 31 Jul 2002 13:31:06 -0400 Received: (qmail 25776 invoked by uid 0); 31 Jul 2002 17:30:34 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp008-rz3) with SMTP; 31 Jul 2002 17:30:34 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG \(E-mail\)'" Date: Wed, 31 Jul 2002 19:30:34 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B107A5D29A@SUS-MA1IT01> Subject: RE: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6482 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Wednesday, July 31, 2002 2:02 PM > To: 'Webdav WG (E-mail)' > Subject: RE: Issue: URI_URL, proposed changes > > > > It appears below that Julian and I agree on most aspects of > this issue, with the only remaining question being "what kind > of URI should be placed in a DAV:dst field". > > I believe that the answer will always be somewhat vague, and > of the form "a URI that the user can effectively use to > author (i.e. modify the content of) the resource". Yes, that's vague, and I don't think this is a problem. > In order to author a resource via the DAV:dst URI, > minimally, you have to locate the resource (i.e. the I don't agree that it's a requirement that the resource being referred to must be authorable. For a server, it's almost impossible to decide which kinds of URIs are useful to an authoring client. So I wouldn't restrict them at all. > ... From w3c-dist-auth-request@w3.org Wed Jul 31 14:28:38 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12051 for ; Wed, 31 Jul 2002 14:28:37 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA01068; Wed, 31 Jul 2002 14:28:24 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6VISJB18171; Wed, 31 Jul 2002 14:28:19 -0400 (EDT) Resent-Date: Wed, 31 Jul 2002 14:28:19 -0400 (EDT) Resent-Message-Id: <200207311828.g6VISJB18171@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6VISI718151 for ; Wed, 31 Jul 2002 14:28:18 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA01041 for ; Wed, 31 Jul 2002 14:28:18 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Wed, 31 Jul 2002 14:19:55 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Wed, 31 Jul 2002 14:27:46 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B107839119@SUS-MA1IT01> From: "Clemm, Geoff" To: "'Webdav WG (E-mail)'" Date: Wed, 31 Jul 2002 14:27:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6483 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: So how can you in any sense "use the URI to effectively author the resource" (which you agree below is the purpose of the DAV:dst field) if you can't even locate the resource identified by the URI? Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: w3c-dist-auth-request@w3.org > > It appears below that Julian and I agree on most aspects of > this issue, with the only remaining question being "what kind > of URI should be placed in a DAV:dst field". > > I believe that the answer will always be somewhat vague, and > of the form "a URI that the user can effectively use to > author (i.e. modify the content of) the resource". Yes, that's vague, and I don't think this is a problem. > In order to author a resource via the DAV:dst URI, > minimally, you have to locate the resource (i.e. the I don't agree that it's a requirement that the resource being referred to must be authorable. For a server, it's almost impossible to decide which kinds of URIs are useful to an authoring client. So I wouldn't restrict them at all. > ... From w3c-dist-auth-request@w3.org Wed Jul 31 14:34:39 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12284 for ; Wed, 31 Jul 2002 14:34:39 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA03981; Wed, 31 Jul 2002 14:34:32 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6VIYV118633; Wed, 31 Jul 2002 14:34:31 -0400 (EDT) Resent-Date: Wed, 31 Jul 2002 14:34:31 -0400 (EDT) Resent-Message-Id: <200207311834.g6VIYV118633@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6VIYU718609 for ; Wed, 31 Jul 2002 14:34:30 -0400 (EDT) Received: from localhost.wakasoft.com (64-60-92-50.cust.telepacific.net [64.60.92.50]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA03965 for ; Wed, 31 Jul 2002 14:34:29 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.wakasoft.com (8.12.4/8.12.4) with ESMTP id g6VIYHpp001585; Wed, 31 Jul 2002 11:34:17 -0700 (PDT) Date: Wed, 31 Jul 2002 11:34:17 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "Clemm, Geoff" , "'Webdav WG \(E-mail\)'" To: "Julian Reschke" From: "Roy T. Fielding" In-Reply-To: Message-Id: <1EC33B09-A4B4-11D6-8895-000393753936@apache.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Subject: Re: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6484 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit >> In order to author a resource via the DAV:dst URI, >> minimally, you have to locate the resource (i.e. the > > I don't agree that it's a requirement that the resource being referred to > must be authorable. For a server, it's almost impossible to decide which > kinds of URIs are useful to an authoring client. So I wouldn't restrict > them > at all. Right. It would also be useful to be able to tell the authoring client which sources are not authorable by them, but the best we can do is give the client a URI that they may or may not be able to author. The primary purpose of the source link is to provide metadata about the resource to the user of the authoring client. Cheers, Roy T. Fielding, Chief Scientist, Day Software (roy.fielding@day.com) Chairman, The Apache Software Foundation (fielding@apache.org) From w3c-dist-auth-request@w3.org Wed Jul 31 15:11:16 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13852 for ; Wed, 31 Jul 2002 15:11:16 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA16138; Wed, 31 Jul 2002 15:11:02 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6VJB1122124; Wed, 31 Jul 2002 15:11:01 -0400 (EDT) Resent-Date: Wed, 31 Jul 2002 15:11:01 -0400 (EDT) Resent-Message-Id: <200207311911.g6VJB1122124@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6VJB0722104 for ; Wed, 31 Jul 2002 15:11:00 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA16114 for ; Wed, 31 Jul 2002 15:10:59 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Wed, 31 Jul 2002 15:02:36 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Wed, 31 Jul 2002 15:10:28 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B10783911B@SUS-MA1IT01> From: "Clemm, Geoff" To: "'Webdav WG (E-mail)'" Date: Wed, 31 Jul 2002 15:10:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6485 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: According to RFC2518, the primary purpose of the source link is specifically that it "identifies the resource that contains the unprocessed source of the link's source" (RFC2518, 13.10). Furthermore "there is typically only one destination (dst) of the link, which is the URI where the unprocessed source of the resource may be accessed." Thus it not only identifies the unprocessed source, but it typically allows you to access it at that URI. Furthermore, in the section 5.4 motivating the DAV:source property, it is stated: "if remote editing of the source resource(s) is desired, the source resource(s) should be given a location in the URI namespace." This provides further motivation for understanding the DAV:source property as intended to identify the location in the URI namespace for editing. So perhaps this just a question of guidance to a DAV:src implementor: - Best: Provide an authorable URL (where of course both READ and WRITE privileges are controlled by the ACL of the resource at that URL) - Better than nothing: Provide a URL, where you can at least view the unprocessed source, or information about the unprocessed source. - Just slightly better than nothing: A URI that identifies the unprocessed source, but does let you either access it there (either for READ or WRITE). Cheers, Geoff -----Original Message----- From: Roy T. Fielding [mailto:fielding@apache.org] >> In order to author a resource via the DAV:dst URI, >> minimally, you have to locate the resource (i.e. the > > I don't agree that it's a requirement that the resource being referred to > must be authorable. For a server, it's almost impossible to decide which > kinds of URIs are useful to an authoring client. So I wouldn't restrict > them > at all. Right. It would also be useful to be able to tell the authoring client which sources are not authorable by them, but the best we can do is give the client a URI that they may or may not be able to author. The primary purpose of the source link is to provide metadata about the resource to the user of the authoring client. Cheers, Roy T. Fielding, Chief Scientist, Day Software (roy.fielding@day.com) Chairman, The Apache Software Foundation (fielding@apache.org) From w3c-dist-auth-request@w3.org Wed Jul 31 15:15:24 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14007 for ; Wed, 31 Jul 2002 15:15:23 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA17838; Wed, 31 Jul 2002 15:15:15 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6VJFD422977; Wed, 31 Jul 2002 15:15:13 -0400 (EDT) Resent-Date: Wed, 31 Jul 2002 15:15:13 -0400 (EDT) Resent-Message-Id: <200207311915.g6VJFD422977@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6VJFD722957 for ; Wed, 31 Jul 2002 15:15:13 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA17817 for ; Wed, 31 Jul 2002 15:15:12 -0400 Received: (qmail 21287 invoked by uid 0); 31 Jul 2002 19:14:38 -0000 Received: from pd950c39e.dip.t-dialin.net (HELO lisa) (217.80.195.158) by mail.gmx.net (mp012-rz3) with SMTP; 31 Jul 2002 19:14:38 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG \(E-mail\)'" Date: Wed, 31 Jul 2002 21:14:35 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B107839119@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6486 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Wednesday, July 31, 2002 8:28 PM > To: 'Webdav WG (E-mail)' > Subject: RE: Issue: URI_URL, proposed changes > > > > So how can you in any sense "use the URI to effectively > author the resource" (which you agree below is the purpose of > the DAV:dst field) if you can't even locate the resource > identified by the URI? As I said before, even a URN (for instance identifying a book or a RFC) may be a useful piece of information. I can't change *that* resource (at least not using HTTP), but it may be useful to know that the destination resource depends on it. From w3c-dist-auth-request@w3.org Wed Jul 31 15:26:01 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14442 for ; Wed, 31 Jul 2002 15:26:01 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA21177; Wed, 31 Jul 2002 15:25:55 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6VJPtQ24070; Wed, 31 Jul 2002 15:25:55 -0400 (EDT) Resent-Date: Wed, 31 Jul 2002 15:25:55 -0400 (EDT) Resent-Message-Id: <200207311925.g6VJPtQ24070@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6VJPs724050 for ; Wed, 31 Jul 2002 15:25:54 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA21157 for ; Wed, 31 Jul 2002 15:25:54 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Wed, 31 Jul 2002 15:17:31 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Wed, 31 Jul 2002 15:25:22 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B10783911D@SUS-MA1IT01> From: "Clemm, Geoff" To: "'Webdav WG (E-mail)'" Date: Wed, 31 Jul 2002 15:25:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6487 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Arghh. Bad proofreading ... Below it should say "DAV:source implementor", not "DAV:src implementor", and more significantly (although probably obviously), it should say: "but does not let you access it there (either for READ or WRITE)", not "but does let you either access it there (either for READ or WRITE)". Sorry about that. Cheers, Geoff -----Original Message----- From: Clemm, Geoff [mailto:gclemm@Rational.Com] Sent: Wednesday, July 31, 2002 3:10 PM To: 'Webdav WG (E-mail)' Subject: RE: Issue: URI_URL, proposed changes According to RFC2518, the primary purpose of the source link is specifically that it "identifies the resource that contains the unprocessed source of the link's source" (RFC2518, 13.10). Furthermore "there is typically only one destination (dst) of the link, which is the URI where the unprocessed source of the resource may be accessed." Thus it not only identifies the unprocessed source, but it typically allows you to access it at that URI. Furthermore, in the section 5.4 motivating the DAV:source property, it is stated: "if remote editing of the source resource(s) is desired, the source resource(s) should be given a location in the URI namespace." This provides further motivation for understanding the DAV:source property as intended to identify the location in the URI namespace for editing. So perhaps this just a question of guidance to a DAV:src implementor: - Best: Provide an authorable URL (where of course both READ and WRITE privileges are controlled by the ACL of the resource at that URL) - Better than nothing: Provide a URL, where you can at least view the unprocessed source, or information about the unprocessed source. - Just slightly better than nothing: A URI that identifies the unprocessed source, but does let you either access it there (either for READ or WRITE). Cheers, Geoff -----Original Message----- From: Roy T. Fielding [mailto:fielding@apache.org] >> In order to author a resource via the DAV:dst URI, >> minimally, you have to locate the resource (i.e. the > > I don't agree that it's a requirement that the resource being referred to > must be authorable. For a server, it's almost impossible to decide which > kinds of URIs are useful to an authoring client. So I wouldn't restrict > them > at all. Right. It would also be useful to be able to tell the authoring client which sources are not authorable by them, but the best we can do is give the client a URI that they may or may not be able to author. The primary purpose of the source link is to provide metadata about the resource to the user of the authoring client. Cheers, Roy T. Fielding, Chief Scientist, Day Software (roy.fielding@day.com) Chairman, The Apache Software Foundation (fielding@apache.org) From w3c-dist-auth-request@w3.org Wed Jul 31 18:29:12 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20630 for ; Wed, 31 Jul 2002 18:29:12 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA00743; Wed, 31 Jul 2002 18:28:56 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g6VMSs009767; Wed, 31 Jul 2002 18:28:54 -0400 (EDT) Resent-Date: Wed, 31 Jul 2002 18:28:54 -0400 (EDT) Resent-Message-Id: <200207312228.g6VMSs009767@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g6VMSq709743 for ; Wed, 31 Jul 2002 18:28:52 -0400 (EDT) Received: from e1.ny.us.ibm.com. (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA00730 for ; Wed, 31 Jul 2002 18:28:51 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com. (8.12.2/8.12.2) with ESMTP id g6VMSDbW060574; Wed, 31 Jul 2002 18:28:13 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6VMSB32132870; Wed, 31 Jul 2002 18:28:11 -0400 To: "Clemm, Geoff" Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Wed, 31 Jul 2002 18:11:45 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_07122002 Pre-release 2|July 12, 2002) at 07/31/2002 18:28:10 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBE694DFEA3D848f9e8a93df938690918c0ABBE694DFEA3D84" Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6488 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE694DFEA3D848f9e8a93df938690918c0ABBE694DFEA3D84 Content-type: multipart/alternative; Boundary="1__=0ABBE694DFEA3D848f9e8a93df938690918c0ABBE694DFEA3D84" --1__=0ABBE694DFEA3D848f9e8a93df938690918c0ABBE694DFEA3D84 Content-type: text/plain; charset=US-ASCII I support Geoff's proposal. COPY seems like a difficult species to define, and what Geoff proposes below seem like the best definition that we are likely to come up with. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com "Clemm, Geoff" cc: Sent by: w3c- Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities dist-auth- request@w3.org 07/25/2002 02:14 PM I believe this definition will work in enough cases for the implementor to be able to extrapolate what to do in those multiple-representation cases (and I'll bet is very close to how Xythos actually does implement its cross-repository MOVE). In particular, I believe we have to say something to clarify the distinction between MOVE and COPY, and that this would be a reasonable compromise between "fully defines every case" (not achievable) and "undefined" (pretty much what we have in 2518). But I'm always open to replacing it with something better! Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Thursday, July 25, 2002 2:02 PM To: Clemm, Geoff; w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Thursday, July 25, 2002 7:53 PM > To: w3c-dist-auth@w3c.org > Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities > > > > Yes, good point Jason, these constraints should only > apply to MOVE, and definitely not to COPY. > > For COPY, I would like us to use the rfc-3253 semantics, > i.e. that a COPY is semantically equivalent to a GET/PROPFIND > followed by a PUT/PROPPATCH, where the PROPFIND/PROPPATCH > is for all properties that can be PROPPATCH'ed at the destination. This won't work (in all cases). The resource may have multiple representations (depending on request headers), but a simple sequence of GET/PROPFIND-PUT/PROPPATCH will only copy one of the representations. --1__=0ABBE694DFEA3D848f9e8a93df938690918c0ABBE694DFEA3D84 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I support Geoff's proposal. COPY seems like a difficult species to define, and what Geoff proposes below seem like the best definition that we are likely to come up with.

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

"Clemm, Geoff" <gclemm@rational.com>




          "Clemm, Geoff" <gclemm@rational.com>
          Sent by: w3c-dist-auth-request@w3.org

          07/25/2002 02:14 PM



To: w3c-dist-auth@w3c.org
cc:
Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities



I believe this definition will work in enough cases for the
implementor to be able to extrapolate what to do in those
multiple-representation cases (and I'll bet is very close to how
Xythos actually does implement its cross-repository MOVE).

In particular, I believe we have to say something to clarify the
distinction between MOVE and COPY, and that this would be a reasonable
compromise between "fully defines every case" (not achievable) and
"undefined" (pretty much what we have in 2518). But I'm always open
to replacing it with something better!

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Thursday, July 25, 2002 2:02 PM
To: Clemm, Geoff; w3c-dist-auth@w3c.org
Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities



> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Thursday, July 25, 2002 7:53 PM
> To: w3c-dist-auth@w3c.org
> Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities
>
>
>
> Yes, good point Jason, these constraints should only
> apply to MOVE, and definitely not to COPY.
>
> For COPY, I would like us to use the rfc-3253 semantics,
> i.e. that a COPY is semantically equivalent to a GET/PROPFIND
> followed by a PUT/PROPPATCH, where the PROPFIND/PROPPATCH
> is for all properties that can be PROPPATCH'ed at the destination.

This won't work (in all cases).

The resource may have multiple representations (depending on request
headers), but a simple sequence of GET/PROPFIND-PUT/PROPPATCH will only copy
one of the representations.



--1__=0ABBE694DFEA3D848f9e8a93df938690918c0ABBE694DFEA3D84-- --0__=0ABBE694DFEA3D848f9e8a93df938690918c0ABBE694DFEA3D84 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=0ABBE694DFEA3D848f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBE694DFEA3D848f9e8a93df938690918c0ABBE694DFEA3D84 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=0ABBE694DFEA3D848f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE694DFEA3D848f9e8a93df938690918c0ABBE694DFEA3D84 Content-type: image/gif; name="pic05238.gif" Content-Disposition: inline; filename="pic05238.gif" Content-ID: <30__=0ABBE694DFEA3D848f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=0ABBE694DFEA3D848f9e8a93df938690918c0ABBE694DFEA3D84--