From w3c-dist-auth-request@w3.org Wed Jun 5 12:11: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 MAA04903 for ; Wed, 5 Jun 2002 12:11: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 MAA17134; Wed, 5 Jun 2002 12:07:08 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g55G6Ip25540; Wed, 5 Jun 2002 12:06:18 -0400 (EDT) Resent-Date: Wed, 5 Jun 2002 12:06:18 -0400 (EDT) Resent-Message-Id: <200206051606.g55G6Ip25540@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 g55G6H225520 for ; Wed, 5 Jun 2002 12:06: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 MAA16744 for ; Wed, 5 Jun 2002 12:06:17 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 05 Jun 2002 12:04:57 -0400 (Eastern Daylight Time) Received: from moose ([216.36.77.241]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 5 Jun 2002 12:04:56 -0400 From: "Lisa Dusseault" To: "'Carlos Martinez-Mascarua'" , Date: Wed, 5 Jun 2002 09:05:57 -0700 Message-ID: <001301c20caa$e1b1ba50$7801a8c0@moose> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <001501c207ec$d5fcb560$0201a8c0@casita> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 05 Jun 2002 16:04:56.0828 (UTC) FILETIME=[BC9E9BC0:01C20CAA] Subject: RE: Multiple servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6273 X-Loop: 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_000_0014_01C20C70.3552E250" ------=_NextPart_000_0014_01C20C70.3552E250 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit There should be no obstacles to developing a server farm where files are kept consistent between machines. Xythos WebFile Server provides an existence proof. The WebDAV standard does not address these issues, however. The standard does not cover server-to-server communication or data storage. It is left up to the server implementor to ensure consistency in whatever manner is most appropriate. Lisa -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Carlos Martinez-Mascarua Sent: Thursday, May 30, 2002 8:15 AM To: w3c-dist-auth@w3.org Cc: Carlos.Mascarua@esca.com Subject: Multiple servers Hi, I would like to know if there is any part of DAV that is related to the issues arising when a server farm is in place; the idea is that each server is completely independent, and there is a mechanism that will keep the files consistent between them (using file-level synchronization). The problem is: Can locking properties be made consistent among the servers providing files through DAV? I hope this is the right forum for this question. Sincerely, Carlos Martinez-Mascarua ------=_NextPart_000_0014_01C20C70.3552E250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
There=20 should be no obstacles to developing a server farm where files are kept=20 consistent between machines.  Xythos WebFile Server provides an = existence=20 proof. 
 
The=20 WebDAV standard does not address these issues, however.  The = standard does=20 not cover server-to-server communication or data storage. It is left up = to the=20 server implementor to ensure consistency in whatever manner is most=20 appropriate.
 
Lisa
-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Carlos=20 Martinez-Mascarua
Sent: Thursday, May 30, 2002 8:15 = AM
To:=20 w3c-dist-auth@w3.org
Cc: = Carlos.Mascarua@esca.com
Subject:=20 Multiple servers

Hi,
 
I would like to know if there is any = part of DAV=20 that is related to the issues arising when a server farm is in place; = the idea=20 is that each server is completely independent, and there is a = mechanism that=20 will keep the files consistent between them (using file-level=20 synchronization).
 
The problem is: Can locking = properties be made=20 consistent among the servers providing files through DAV?
 
I hope this is the right forum for = this=20 question.
 
Sincerely,
 
Carlos=20 Martinez-Mascarua
------=_NextPart_000_0014_01C20C70.3552E250-- --------------InterScan_NT_MIME_Boundary-- From w3c-dist-auth-request@w3.org Wed Jun 5 13:57: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 NAA09336 for ; Wed, 5 Jun 2002 13:57: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 NAA21067; Wed, 5 Jun 2002 13:56:01 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g55Hu0m16008; Wed, 5 Jun 2002 13:56:00 -0400 (EDT) Resent-Date: Wed, 5 Jun 2002 13:56:00 -0400 (EDT) Resent-Message-Id: <200206051756.g55Hu0m16008@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 g55Htw215984 for ; Wed, 5 Jun 2002 13:55:58 -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 NAA21064 for ; Wed, 5 Jun 2002 13:55:58 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 05 Jun 2002 13:55:28 -0400 (Eastern Daylight Time) Received: from moose ([216.36.77.241]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 5 Jun 2002 13:55:27 -0400 From: "Lisa Dusseault" To: "Webdav WG \(E-mail\)" Date: Wed, 5 Jun 2002 10:56:45 -0700 Message-ID: <005701c20cba$5c2e3e20$7801a8c0@moose> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0058_01C20C7F.AFCF6620" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 05 Jun 2002 17:55:27.0679 (UTC) FILETIME=[2CEA2CF0:01C20CBA] Subject: FW: I-D ACTION:draft-presuhn-nmwebdav-00.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6274 X-Loop: 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_0058_01C20C7F.AFCF6620 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This may not be directly applicable to most regulars of this list, but it's an interesting potential use of WebDAV. Lisa -----Original Message----- From: nsyracus@cnri.reston.va.us [mailto:nsyracus@cnri.reston.va.us]On Behalf Of Internet-Drafts@ietf.org Sent: Monday, June 03, 2002 4:39 AM To: IETF-Announce: Cc: disman@dorothy.bmc.com; eos@ops.ietf.org; snmpv3@lists.tislabs.com Subject: I-D ACTION:draft-presuhn-nmwebdav-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Applying WebDAV (Web Distributed Authoring and Versioning)to Network Configuration Management Problems Author(s) : R. Presuhn Filename : draft-presuhn-nmwebdav-00.txt Pages : 12 Date : 31-May-02 This memo examines the potential of using WWW Distributed Authoring and Versioning (WebDAV) technologies to address the problems of network configuration management. It reviews requirements and issues that have been identified in IETF network configuration management and operator requirements discussions, matching these requirements and issues with various WebDAV facilities. It concludes by identifying areas for further exploration. Comments are welcomed, both from the Operations and Management Area in general, and from participants in the webdav and deltav working groups in particular. Please send comments to the author at randy_presuhn@bmc.com. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-presuhn-nmwebdav-00.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-presuhn-nmwebdav-00.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-presuhn-nmwebdav-00.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_000_0058_01C20C7F.AFCF6620 Content-Type: Message/External-body; name="ATT00191.dat" Content-Disposition: attachment; filename="ATT00191.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20020531143844.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-presuhn-nmwebdav-00.txt ------=_NextPart_000_0058_01C20C7F.AFCF6620 Content-Type: Message/External-body; name="draft-presuhn-nmwebdav-00.txt" Content-Disposition: attachment; filename="draft-presuhn-nmwebdav-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20020531143844.I-D@ietf.org> ------=_NextPart_000_0058_01C20C7F.AFCF6620-- From w3c-dist-auth-request@w3.org Wed Jun 5 15:49: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 PAA15056 for ; Wed, 5 Jun 2002 15:49: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 PAA15102; Wed, 5 Jun 2002 15:49:28 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g55JnRi26809; Wed, 5 Jun 2002 15:49:27 -0400 (EDT) Resent-Date: Wed, 5 Jun 2002 15:49:27 -0400 (EDT) Resent-Message-Id: <200206051949.g55JnRi26809@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 g55JnQ226789 for ; Wed, 5 Jun 2002 15:49:26 -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 PAA15088 for ; Wed, 5 Jun 2002 15:49:26 -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 g55Jo2X21007 for ; Wed, 5 Jun 2002 12:50:02 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 5 Jun 2002 12:48:17 -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 Subject: Yokohama, Japan, IETF-54 meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6275 X-Loop: 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 The WebDAV WG will be meeting at the Yokohama IETF, July 14-19, 2002. At present, WebDAV WG is scheduled to meet from 9-11:30AM, on Tuesday, July 16. For further details about the IETF meeting, including details on registration, location, and the most recent schedule: http://www.ietf.org/meetings/IETF-54.html Likely topics of discussion at the meeting: * open issues in RFC 2518 * access control protocol issues, if the draft has not yet been sent to the IESG * DAV Searching and Locating * Bindings (time permitting) - Jim From w3c-dist-auth-request@w3.org Fri Jun 7 01:42: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 BAA08906 for ; Fri, 7 Jun 2002 01:42: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 BAA01867; Fri, 7 Jun 2002 01:41:08 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g575eGh01027; Fri, 7 Jun 2002 01:40:16 -0400 (EDT) Resent-Date: Fri, 7 Jun 2002 01:40:16 -0400 (EDT) Resent-Message-Id: <200206070540.g575eGh01027@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 g575eF201007 for ; Fri, 7 Jun 2002 01:40:15 -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 BAA01757 for ; Fri, 7 Jun 2002 01:40:14 -0400 Received: from Tycho (dsl3-63-249-68-7.cruzio.com [63.249.68.7]) by mail.cruzio.com with SMTP id WAA07340 for ; Thu, 6 Jun 2002 22:39:37 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Thu, 6 Jun 2002 22:38:27 -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 Subject: FW: implementation of webDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6276 X-Loop: 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: Kris Gorrepati [mailto:kris@zesati-samsung.com] Sent: Wednesday, June 05, 2002 8:13 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] implementation of webDAV Zesati is a web-native product lifecycle management application that is used by engineering/manufacturing companies. We are implementing webDAV and require help in implementing webDAV on a J2EE server. Please contact Krishna Gorrepati at 248-396-8821 or email at kris@zesati.com for more information. Cheers Kris http://www.zesati.com From w3c-dist-auth-request@w3.org Sun Jun 9 10:44: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 KAA02059 for ; Sun, 9 Jun 2002 10:44: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 KAA24646; Sun, 9 Jun 2002 10:43:09 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g59Eh2E29213; Sun, 9 Jun 2002 10:43:02 -0400 (EDT) Resent-Date: Sun, 9 Jun 2002 10:43:02 -0400 (EDT) Resent-Message-Id: <200206091443.g59Eh2E29213@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 g59Eh1229193 for ; Sun, 9 Jun 2002 10:43: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 KAA24638 for ; Sun, 9 Jun 2002 10:43:00 -0400 Received: (qmail 28631 invoked by uid 0); 9 Jun 2002 14:42:29 -0000 Received: from p3ee2477a.dip.t-dialin.net (HELO lisa) (62.226.71.122) by mail.gmx.net (mp016-rz3) with SMTP; 9 Jun 2002 14:42:29 -0000 From: "Julian Reschke" To: "Alan Kent" , "WebDAV" Date: Sun, 9 Jun 2002 16:42:32 +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: <20020530085919.B28975@io.mds.rmit.edu.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: What is DASL for? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6279 X-Loop: 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 Alan Kent > Sent: Thursday, May 30, 2002 12:59 AM > To: WebDAV > Subject: What is DASL for? > > > > This might sound like a very naive question, but I am trying to understand > the use cases for DASL. That is, what sorts of problems are people trying > to solve? Being an open framework to drop any sort of query you like into > it to me does not improve interoperability in the long term. > > ... > > Hence my question of what is the goal: > > * To enable searching of content? (Similar goals to say google) It's important to understand that DASL consists of a) a framework for the HTTP SEARCH method, enabling different kinds of query grammars, and b) one specific (and mandatory) query grammar, specialized in searching on WebDAV properties (it has a single function for content matching, but this is optional). > * To enable searching through a file system to find files that match > certain properties (more like "Find Files" under windows") in a > way that is faster than the client doing PROPFIND etc on each > individual file. Definitively. > If the latter, I would implement the query engine without using indexes, > and just do the file system walk at the server end and check the various > conditions to find matching resources. Well, that's up to you. Even if a DAV:basicsearch query affects both dead (stored) and live (computed) properties, it may be able to come up with a better query strategy that does not require a tree walk. See for instance Elias' paper at [1]. [1] From w3c-dist-auth-request@w3.org Sun Jun 9 11:36: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 KAA02058 for ; Sun, 9 Jun 2002 10:44: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 KAA24664; Sun, 9 Jun 2002 10:43:14 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g59EhDO29247; Sun, 9 Jun 2002 10:43:14 -0400 (EDT) Resent-Date: Sun, 9 Jun 2002 10:43:14 -0400 (EDT) Resent-Message-Id: <200206091443.g59EhDO29247@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 g59EhC229227 for ; Sun, 9 Jun 2002 10:43:12 -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 KAA24659 for ; Sun, 9 Jun 2002 10:43:12 -0400 Received: (qmail 11998 invoked by uid 0); 9 Jun 2002 10:42:40 -0000 Received: from p3ee2477a.dip.t-dialin.net (HELO lisa) (62.226.71.122) by mail.gmx.net (mp001-rz3) with SMTP; 9 Jun 2002 10:42:40 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Webdav WG \(E-mail\)'" Cc: "'Julian Reschke'" , "'Joe Orton'" Date: Sun, 9 Jun 2002 12:42: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: <002f01c20f4b$6905d930$f8cb90c6@moose> 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/6280 X-Loop: 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 Lisa, thanks for compiling this list of issues. I agree that we need to think about them, but I'm not sure that we have to *solve* them all. Sometimes a problem just is too complex to be solved completely in the first (or actually, second) attempt, and it makes sense to concentrate on the subset of issues that's simpler and well understood... > From: Lisa Dusseault [mailto:ldusseault@xythos.com] > Sent: Sunday, June 09, 2002 2:20 AM > To: 'Webdav WG (E-mail)' > Cc: 'Julian Reschke'; 'Joe Orton' > Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > > > I've been thinking more about the source property problem. It's > deeper than > it looks. Here are *some* of the problems, the things that are not > specified. More are sure to be found as we start answering the initial > questions: > > 1. Must the resources pointed to by the SOURCE header be > WebDAV-compatible? a) What is the definition of a "WebDAV-compatible" resource? Being the member of a WebDAV collection? b) I'm tempted to say: no. > 2. Must the source property point to ALL the files involved in > producing the > result? Be careful here -- there could be data files as well as source > code, libraries, build files, etc. I don't think that's feasible. > 3. When the source property points to multiple files, what role > does each of > them play? The one defined in the role attribute (if present). > 4. Clearly in order to get the source code for a dynamic resource, the > client must do a GET to the URL(s) in the source header. But what URL > should the client send PUT to? Does PROPFIND address the source > code or the > output? Source and dynamic resources are different resources with separate URLs. All HTTP/WebDAV methods operate on the respective request URLs. See , section 6.2.3. > 5. What does it mean when a dynamically-generated resource is the > source for > a COPY request? Is it different when it's the source for a MOVE request? I think that's open to discussion. For COPY, it seems it would make sense to require that the newly created resource must behave as the original resource, so it should still be a dynamic resource, and have the same source links. MOVE obviously MUST move the resource -- and if this can't be done by the server, the request must fail. > 6. How does a client *create* dynamically-generated Web pages? > Think of all > the problems with that - where should the client upload new source files? > How can the client specify what URL in the main repository is actually an > invocation to handle this dynamic resource? Right now I'd say that's server-specifc. Depending on how dynamic resources are implemented, it's hard to see how there can be a generic way to author them. > 7. How does a client add a new source file to an existing set of source > files? E.g. assume I want to modify a JSP to call a new object in a new > library. That library is not on the server yet. How do I upload > it? Where Again, I think this is server-specific. The server may allow you to PUT the file anywhere, or at a specific location. And of course a server may allow PROPPATCH on the source-set property. > to? How do I indicate to the server that it's a source file and not a > content file? What's the difference? > 8. How do I configure the server's classpath? How do I get it to compile? Out of scope. I agree that it would be interesting to see how the source-set property can be applied to a Servlet engine, and to come up with interoperable ways to author servlets... > I don't think that Julian's proposal goes very far towards a complete > solution. As it stands, it addresses only part of #3, in that it > provides a > syntax for describing roles, though it does not specify what the > roles are, > which is clearly necessary for interoperable implementations. Moreover, it Well. Please then enumerate all roles we'll need for interoperability. If you think RFC2518+ needs to do this, we are free to assign names, qnames or URIs to these roles and we are done. I personally don't think we should get into that business (at least not now). > creates a significant new dependency on XLink, a non-trivial > specification. I agree that XLink itself is non-trivial. But we depend only on a very small subset of XLink (simple links), and not using this subset makes our own work harder, not simpler (because we would have to duplicate the work done in this recommendation). For those who haven't looked at XLink, here's what we depend on: - a well-defined namespace - two attributes (role and href) > In view of the problems that remain to be solved I don't think > that XLink is > bringing enough to the party to justify the additional complexity. Could you please explain where you see *additional* complexity? Usually, reusing existing methodology *simplifies* a specification. Using the same line of argument one could say that using XML causes additional complexity, and therefore WebDAV should have used a simpler marshalling format. > That said, instead of getting bogged down in syntax, I'd like to see us > figure out what the abstract semantics of a new solution would be (see > questions 1-8 above). Once we've got that stuff nailed down we can worry > about how to encode it on the wire. In view of the complexity we already > know about, I suspect this is going to turn out to be a > significant project. It depends on what we want. a) Just fix the source property defined RFC2518 for inclusion in RFC2518bis? That was my understanding. b) Completely solve the problem of remote authoring? That's hard. Julian From w3c-dist-auth-request@w3.org Sun Jun 9 12:40: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 MAA05132 for ; Sun, 9 Jun 2002 12:40: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 UAA21702; Sat, 8 Jun 2002 20:19:34 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g590JXe11890; Sat, 8 Jun 2002 20:19:33 -0400 (EDT) Resent-Date: Sat, 8 Jun 2002 20:19:33 -0400 (EDT) Resent-Message-Id: <200206090019.g590JXe11890@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 g590JT211866 for ; Sat, 8 Jun 2002 20:19: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 UAA21653 for ; Sat, 8 Jun 2002 20:19:29 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Sat, 08 Jun 2002 20:18:50 -0400 (Eastern Daylight Time) Received: from moose ([198.144.203.248]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 8 Jun 2002 20:18:49 -0400 From: "Lisa Dusseault" To: "'Webdav WG \(E-mail\)'" Cc: "'Julian Reschke'" , "'Joe Orton'" Date: Sat, 8 Jun 2002 17:20:06 -0700 Message-ID: <002f01c20f4b$6905d930$f8cb90c6@moose> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 09 Jun 2002 00:18:49.0880 (UTC) FILETIME=[3A88C180:01C20F4B] Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6278 X-Loop: 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've been thinking more about the source property problem. It's deeper than it looks. Here are *some* of the problems, the things that are not specified. More are sure to be found as we start answering the initial questions: 1. Must the resources pointed to by the SOURCE header be WebDAV-compatible? 2. Must the source property point to ALL the files involved in producing the result? Be careful here -- there could be data files as well as source code, libraries, build files, etc. 3. When the source property points to multiple files, what role does each of them play? 4. Clearly in order to get the source code for a dynamic resource, the client must do a GET to the URL(s) in the source header. But what URL should the client send PUT to? Does PROPFIND address the source code or the output? 5. What does it mean when a dynamically-generated resource is the source for a COPY request? Is it different when it's the source for a MOVE request? 6. How does a client *create* dynamically-generated Web pages? Think of all the problems with that - where should the client upload new source files? How can the client specify what URL in the main repository is actually an invocation to handle this dynamic resource? 7. How does a client add a new source file to an existing set of source files? E.g. assume I want to modify a JSP to call a new object in a new library. That library is not on the server yet. How do I upload it? Where to? How do I indicate to the server that it's a source file and not a content file? 8. How do I configure the server's classpath? How do I get it to compile? I don't think that Julian's proposal goes very far towards a complete solution. As it stands, it addresses only part of #3, in that it provides a syntax for describing roles, though it does not specify what the roles are, which is clearly necessary for interoperable implementations. Moreover, it creates a significant new dependency on XLink, a non-trivial specification. In view of the problems that remain to be solved I don't think that XLink is bringing enough to the party to justify the additional complexity. That said, instead of getting bogged down in syntax, I'd like to see us figure out what the abstract semantics of a new solution would be (see questions 1-8 above). Once we've got that stuff nailed down we can worry about how to encode it on the wire. In view of the complexity we already know about, I suspect this is going to turn out to be a significant project. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Wednesday, May 15, 2002 3:53 AM > To: Joe Orton; Webdav WG (E-mail) > Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Joe Orton > > Sent: Wednesday, May 15, 2002 12:32 PM > > To: Webdav WG (E-mail) > > Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > > > > > > On Wed, May 15, 2002 at 01:19:00AM +0200, Julian Reschke wrote: > > > > I just thought it was unnecessary to have to depend on > yet another > > > > specification for something this simple. > > > > > > What do you mean by "depend"? We just reuse two standard > attribute names > > > (xlink:href and xlink:role). That's what XLink is for -- if every > > > spec/document/protocol designer would take this position, it > > wouldn't make > > > any sense to try to come up with common vocabularies for this. > > > > I just mean it's annoying to have to go and read Yet > Another XSpec to > > find out how to implement WebDAV. If the DAV spec can > explain that the > > xlink:href attribute must contain a URI-reference, and that > xlink:role > > is entirely optional, then it's not really a problem. > > OK, I'll try to come up with the right wording. > > > ... > > > So again, why not just use the Xlink [1] compatible syntax that > > I proposed > > > back in October [2]: > > > > > > xmlns:xlink="http://www.w3.org/1999/xlink"> > > > > > > > > xlink:role="UriDescribingTheRole" xml:lang="en">source > file > > > > > xlink:role="UriDescribingTheRole" xml:lang="en">library > file > > > > > xlink:role="UriDescribingTheRole" > xml:lang="en">makefile > > > > > > > > > > > > What's wrong with it? It fulfills all requirements and uses W3C > > specs where > > > applicable. > > > > It does mean requiring that clients resolve XML namespaces > on attribute > > names, which hasn't be necessary so far to implement a DAV > client (in my > > experience anyway); possible interoperability issues there. > > A DAV client *must* use an XML namespace aware parser anyway. > Do you say > that there are parser that do support namespaces on elements, > but don't on > attributes? > > > I'll implement this source-set proposal sometime this week > hopefully, > > given that nobody else objects to using XLink. > > Sounds great. > From w3c-dist-auth-request@w3.org Sun Jun 9 13:36: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 MAA05131 for ; Sun, 9 Jun 2002 12:40: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 SAA11538; Sat, 8 Jun 2002 18:30:38 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g58MTth10425; Sat, 8 Jun 2002 18:29:55 -0400 (EDT) Resent-Date: Sat, 8 Jun 2002 18:29:55 -0400 (EDT) Resent-Message-Id: <200206082229.g58MTth10425@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 g58MTs210405 for ; Sat, 8 Jun 2002 18:29:54 -0400 (EDT) Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23]) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA11419 for ; Sat, 8 Jun 2002 18:29:53 -0400 Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Sat, 08 Jun 2002 18:29:22 -0400 (Eastern Daylight Time) Received: from moose ([198.144.203.248]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 8 Jun 2002 18:29:21 -0400 From: "Lisa Dusseault" To: "Webdav WG \(E-mail\)" Date: Sat, 8 Jun 2002 15:30:40 -0700 Message-ID: <002d01c20f3c$1f9b96e0$f8cb90c6@moose> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 08 Jun 2002 22:29:21.0676 (UTC) FILETIME=[EF945CC0:01C20F3B] Subject: Support for 102 Processing Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6277 X-Loop: 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 Has interoperability been shown for the 102 Processing response? Do any servers send this status response? Do any clients accept it (all *should*, but I'd like confirming answers). Lisa From w3c-dist-auth-request@w3.org Sun Jun 9 14: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 OAA05981 for ; Sun, 9 Jun 2002 14: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 OAA27561; Sun, 9 Jun 2002 14:05:58 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g59I5tI21741; Sun, 9 Jun 2002 14:05:55 -0400 (EDT) Resent-Date: Sun, 9 Jun 2002 14:05:55 -0400 (EDT) Resent-Message-Id: <200206091805.g59I5tI21741@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 g59I5s221721 for ; Sun, 9 Jun 2002 14: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 OAA27553 for ; Sun, 9 Jun 2002 14:05:54 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Sun, 09 Jun 2002 14:05:11 -0400 (Eastern Daylight Time) Received: from moose ([198.144.203.248]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 9 Jun 2002 14:05:09 -0400 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Webdav WG \(E-mail\)'" Date: Sun, 9 Jun 2002 11:06:26 -0700 Message-ID: <000301c20fe0$603a9c60$f8cb90c6@moose> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 09 Jun 2002 18:05:10.0214 (UTC) FILETIME=[31C8F660:01C20FE0] Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6281 X-Loop: 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 I can explain some of my concerns better in response... > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Sunday, June 09, 2002 3:43 AM ... > all. Sometimes a > problem just is too complex to be solved completely in the first (or > actually, second) attempt, and it makes sense to concentrate > on the subset > of issues that's simpler and well understood... That's true. A list of agreed requirements might be a good start here. It seems to me that the point of the exercise is to specify a standard to allow clients to interoperably author dynamic content as well as static content. These questions are intended to address what I consider the minimal feature set required to author dynamic content. If implementors have to invent private extensions to get these features then it's not clear why we bother specifying anything along these lines at all. > > 1. Must the resources pointed to by the SOURCE header be > > WebDAV-compatible? > > a) What is the definition of a "WebDAV-compatible" resource? Being the > member of a WebDAV collection? > > b) I'm tempted to say: no. If an OPTIONS response for the resource includes the DAV: header with level 1 or 2 support, it's a WebDAV resource. If the answer is "no it's not a WebDAV resource", then how is authoring of the dynamic content possible? > > 2. Must the source property point to ALL the files involved in > > producing the > > result? Be careful here -- there could be data files as > well as source > > code, libraries, build files, etc. > > I don't think that's feasible. If it's not possible to view and edit or replace all the files involved in producing the result, then how is it possible to authoring dynamic content? > > 4. Clearly in order to get the source code for a dynamic > resource, the > > client must do a GET to the URL(s) in the source header. > But what URL > > should the client send PUT to? Does PROPFIND address the source > > code or the > > output? > > Source and dynamic resources are different resources with > separate URLs. All > HTTP/WebDAV methods operate on the respective request URLs. Compare with the next question/answer to see the inconsistency with this position. > > 5. What does it mean when a dynamically-generated resource is the > > source for > > a COPY request? Is it different when it's the source for a > MOVE request? > > I think that's open to discussion. For COPY, it seems it > would make sense to > require that the newly created resource must behave as the original > resource, so it should still be a dynamic resource, and have > the same source > links. MOVE obviously MUST move the resource -- and if this > can't be done by > the server, the request must fail. All right, now we see the inconsistency. Say we have a dynamic resource, "foo", and the server reports that there's only one source file, "foo-source". If all methods operate on the respective request URIs, that means that a COPY request to foo must operate on the dynamically-generated content, not the source. So wouldn't that mean that a snapshot of foo is copied to the destination? It wouldn't be a dynamic resource. Fair enough. Presumably we can COPY foo-source to get a second dynamic resource. But what happens if you MOVE foo? Does it operate only on a snapshot of the dynamic resource? What does that mean? > > > 6. How does a client *create* dynamically-generated Web pages? > > Think of all > > the problems with that - where should the client upload new > source files? > > How can the client specify what URL in the main repository > is actually an > > invocation to handle this dynamic resource? > > Right now I'd say that's server-specifc. Depending on how > dynamic resources > are implemented, it's hard to see how there can be a generic > way to author > them. > > > 7. How does a client add a new source file to an existing > set of source > > files? E.g. assume I want to modify a JSP to call a new > object in a new > > library. That library is not on the server yet. How do I upload > > it? Where > > Again, I think this is server-specific. The server may allow > you to PUT the > file anywhere, or at a specific location. And of course a > server may allow > PROPPATCH on the source-set property. Seems to me both 6 and 7 are essential features. I don't understand how authoring dynamic content is supposed to work unless we offer them. > > > to? How do I indicate to the server that it's a source file > and not a > > content file? > > What's the difference? A new source file is a new file which will be interpreted or compiled by the server in order to produce dynamic content. By "content file" I meant static Web page, or regular resource. How can the client create a new source file and let the server know it's supposed to interpret or compile it? > > solution. As it stands, it addresses only part of #3, in that it > > provides a > > syntax for describing roles, though it does not specify what the > > roles are, > > which is clearly necessary for interoperable > implementations. Moreover, it > > Well. Please then enumerate all roles we'll need for > interoperability. If > you think RFC2518+ needs to do this, we are free to assign > names, qnames or > URIs to these roles and we are done. I personally don't think > we should get > into that business (at least not now). If we don't specify roles then we've got a framework, not a protocol and the result will be that every server will define their own set of roles that each client will have to know about, which is an interoperability disaster. I agree that for the WG to specify a set of roles is a non-trivial problem, but that's what's required for a standard. > > In view of the problems that remain to be solved I don't think > > that XLink is > > bringing enough to the party to justify the additional complexity. > > Could you please explain where you see *additional* > complexity? Usually, > reusing existing methodology *simplifies* a specification. The idea isn't primarily to simplify the specification but rather to make the implementor's life easier. With some modest additional effort we could invent something that would be vastly simpler for the implementor to grok and not require a dependency on some other specification. > Using the same line of argument one could say that using XML causes > additional complexity, and therefore WebDAV should have used a simpler > marshalling format. As always, there's a balance between the benefits of not having to reinvent something and the additional complexity of importing something that wasn't designed for the specific purpose you're using it for. In my view, using XML falls on one side of this line and XLink on the other. > It depends on what we want. > > a) Just fix the source property defined RFC2518 for inclusion > in RFC2518bis? > That was my understanding. What "fix" means depends on what you think is broken. It's not clear to me why you think that the only thing that's broken is that there's no way to communicate roles. And if that is what's broken, I don't understand why you think having a placeholder for private roles does the job. Lisa From w3c-dist-auth-request@w3.org Sun Jun 9 15:02: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 PAA06465 for ; Sun, 9 Jun 2002 15:02: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 PAA00384; Sun, 9 Jun 2002 15:01:51 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g59J1oU23777; Sun, 9 Jun 2002 15:01:50 -0400 (EDT) Resent-Date: Sun, 9 Jun 2002 15:01:50 -0400 (EDT) Resent-Message-Id: <200206091901.g59J1oU23777@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 g59J1n223753 for ; Sun, 9 Jun 2002 15:01: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 PAA00380 for ; Sun, 9 Jun 2002 15:01:48 -0400 Received: (qmail 12263 invoked by uid 0); 9 Jun 2002 19:01:16 -0000 Received: from p3ee24821.dip.t-dialin.net (HELO lisa) (62.226.72.33) by mail.gmx.net (mp016-rz3) with SMTP; 9 Jun 2002 19:01:16 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Webdav WG \(E-mail\)'" Date: Sun, 9 Jun 2002 21:01:05 +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) Importance: Normal In-Reply-To: <000301c20fe0$603a9c60$f8cb90c6@moose> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6282 X-Loop: 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, June 09, 2002 8:06 PM > To: 'Julian Reschke'; 'Webdav WG (E-mail)' > Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > > > > I think I can explain some of my concerns better in response... > > .. > > > > 1. Must the resources pointed to by the SOURCE header be > > > WebDAV-compatible? > > > > a) What is the definition of a "WebDAV-compatible" resource? Being the > > member of a WebDAV collection? > > > > b) I'm tempted to say: no. > > If an OPTIONS response for the resource includes the DAV: header > with level > 1 or 2 support, it's a WebDAV resource. If the answer is "no it's not a > WebDAV resource", then how is authoring of the dynamic content possible? I fear this isn't a definition at all. RFC2518 says that upon OPTIONS, the DAV header must be returned for WebDAV compliant resources. It does NOT define what a WebDAV compliant resource actually is (isn't this on our issues list)? So if your question was: "must every source resource report the DAV header upon OPTIONS?", I'd say: no. I'm not even sure I'd require that it must be an HTTP resource. > > > 2. Must the source property point to ALL the files involved in > > > producing the > > > result? Be careful here -- there could be data files as > > well as source > > > code, libraries, build files, etc. > > > > I don't think that's feasible. > > If it's not possible to view and edit or replace all the files involved in > producing the result, then how is it possible to authoring > dynamic content? It may not be possible. It may not be necessary. Take a simple example: we've got a dynamic resource that depends on an XML source file and an XSLT transformation. Only the the XML source file is available for direct editing, the XSLT is not. Why would this be a scenario that shouldn't be supported? > > > 4. Clearly in order to get the source code for a dynamic > > resource, the > > > client must do a GET to the URL(s) in the source header. > > But what URL > > > should the client send PUT to? Does PROPFIND address the source > > > code or the > > > output? > > > > Source and dynamic resources are different resources with > > separate URLs. All > > HTTP/WebDAV methods operate on the respective request URLs. > > Compare with the next question/answer to see the inconsistency with this > position. I don't think this is inconsistent or something that can be negotiated. This is the nature of the HTTP protocol. > > > 5. What does it mean when a dynamically-generated resource is the > > > source for > > > a COPY request? Is it different when it's the source for a > > MOVE request? > > > > I think that's open to discussion. For COPY, it seems it > > would make sense to > > require that the newly created resource must behave as the original > > resource, so it should still be a dynamic resource, and have > > the same source > > links. MOVE obviously MUST move the resource -- and if this > > can't be done by > > the server, the request must fail. > > All right, now we see the inconsistency. Say we have a dynamic resource, > "foo", and the server reports that there's only one source file, > "foo-source". > > If all methods operate on the respective request URIs, that means that a > COPY request to foo must operate on the dynamically-generated content, not No. It must operate on the request URL, thus on the dynamic *resource*, not it's content. > the source. So wouldn't that mean that a snapshot of foo is copied to the > destination? It wouldn't be a dynamic resource. Fair enough. No, I don't think this is what it means. > Presumably we > can COPY foo-source to get a second dynamic resource. But what happens if > you MOVE foo? Does it operate only on a snapshot of the dynamic resource? > What does that mean? MOVE moves the resource. If it's a dynamic resource, so it must be after the MOVE. If this isn't possible, the MOVE MUST fail. > > > 6. How does a client *create* dynamically-generated Web pages? > > > Think of all > > > the problems with that - where should the client upload new > > source files? > > > How can the client specify what URL in the main repository > > is actually an > > > invocation to handle this dynamic resource? > > > > Right now I'd say that's server-specifc. Depending on how > > dynamic resources > > are implemented, it's hard to see how there can be a generic > > way to author > > them. > > > > > 7. How does a client add a new source file to an existing > > set of source > > > files? E.g. assume I want to modify a JSP to call a new > > object in a new > > > library. That library is not on the server yet. How do I upload > > > it? Where > > > > Again, I think this is server-specific. The server may allow > > you to PUT the > > file anywhere, or at a specific location. And of course a > > server may allow > > PROPPATCH on the source-set property. > > Seems to me both 6 and 7 are essential features. I don't understand how > authoring dynamic content is supposed to work unless we offer them. I don't see how you can achieve this. There are so many ways to setup/program servers to generate dynamic resources (ASP, PHP, CGI, Cocoon, Servlets, ...), how can a single protocol define a *generic* way to set them up? I strongly disagree that we need to solve this problem (now). > > > to? How do I indicate to the server that it's a source file > > and not a > > > content file? > > > > What's the difference? > > A new source file is a new file which will be interpreted or > compiled by the > server in order to produce dynamic content. By "content file" I meant > static Web page, or regular resource. How can the client create a new > source file and let the server know it's supposed to interpret or compile > it? I still don't see the difference. Being the source of a link isn't anything special for a resource. Is setting up new dynamic resources a desirable feature for remote authoring? Yes. Does it need to be resolved in terms of the source-set property? I don't think so. > > > solution. As it stands, it addresses only part of #3, in that it > > > provides a > > > syntax for describing roles, though it does not specify what the > > > roles are, > > > which is clearly necessary for interoperable > > implementations. Moreover, it > > > > Well. Please then enumerate all roles we'll need for > > interoperability. If > > you think RFC2518+ needs to do this, we are free to assign > > names, qnames or > > URIs to these roles and we are done. I personally don't think > > we should get > > into that business (at least not now). > > If we don't specify roles then we've got a framework, not a > protocol and the > result will be that every server will define their own set of roles that > each client will have to know about, which is an interoperability > disaster. > I agree that for the WG to specify a set of roles is a > non-trivial problem, > but that's what's required for a standard. I strongly disagree. In fact, I'd say that the WebDAV should not attempt to define these roles. What these roles are heavily depends on the type of your server, and there's no way how we can define every conceivable role. > > > In view of the problems that remain to be solved I don't think > > > that XLink is > > > bringing enough to the party to justify the additional complexity. > > > > Could you please explain where you see *additional* > > complexity? Usually, > > reusing existing methodology *simplifies* a specification. > > The idea isn't primarily to simplify the specification but rather to make > the implementor's life easier. With some modest additional effort we could > invent something that would be vastly simpler for the implementor to grok > and not require a dependency on some other specification. OK, every implementor already has to have understood the mechanics of xml:lang, right? I just don't understand why you consider it a problem to understand the two new attributes xlink:href or xlink:role as well? Details, please. > > Using the same line of argument one could say that using XML causes > > additional complexity, and therefore WebDAV should have used a simpler > > marshalling format. > > As always, there's a balance between the benefits of not having > to reinvent > something and the additional complexity of importing something that wasn't > designed for the specific purpose you're using it for. In my It was *exactly* defined for this purpose: to specify links to other resources and to augment them with additional information. > view, using XML > falls on one side of this line and XLink on the other. > > > It depends on what we want. > > > > a) Just fix the source property defined RFC2518 for inclusion > > in RFC2518bis? > > That was my understanding. > What "fix" means depends on what you think is broken. It's not clear to me > why you think that the only thing that's broken is that there's no way to > communicate roles. And if that is what's broken, I don't > understand why you > think having a placeholder for private roles does the job. What I think is broken is: 1) the wording and the examples in RFC2518, 2) the fact that there's no standard place to specify a role, 3) that a client doesn't have any useful information that would allow it to classify/label the various links. My proposal adresses all these issues. In particular, a client will always be able to label the role, even if xlink:role isn't present or not recognized (because there's a human-readable label for the role). I think the requirement for an exhaustive list of roles essentially makes this protocol feature impossible to specify. So again: are we trying to revise the source property for RFC2518bis, or are we talking about something for later specs? In the former case, I think we have all we need. Julian From w3c-dist-auth-request@w3.org Mon Jun 10 06:04: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 GAA26931 for ; Mon, 10 Jun 2002 06:04: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 GAA01258; Mon, 10 Jun 2002 06:04:06 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5AA3nS07433; Mon, 10 Jun 2002 06:03:49 -0400 (EDT) Resent-Date: Mon, 10 Jun 2002 06:03:49 -0400 (EDT) Resent-Message-Id: <200206101003.g5AA3nS07433@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 g5AA3l207413 for ; Mon, 10 Jun 2002 06:03: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 GAA01234 for ; Mon, 10 Jun 2002 06:03: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 ; Mon, 10 Jun 2002 12:03:17 +0200 Date: Mon, 10 Jun 2002 12:03:21 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "Webdav WG \(E-mail\)" To: "Lisa Dusseault" From: Stefan Eissing In-Reply-To: <002d01c20f3c$1f9b96e0$f8cb90c6@moose> Message-Id: <4B4D00A3-7C59-11D6-8EC3-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: Support for 102 Processing Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6283 X-Loop: 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 Am Sonntag den, 9. Juni 2002, um 00:30, schrieb Lisa Dusseault: > > Has interoperability been shown for the 102 Processing response? > Do any > servers send this status response? Do any clients accept it (all > *should*, > but I'd like confirming answers). Good questions. Yes we should, but we do not (neither send nor accept). Also, during interop testing we never encountered a server sending a 102. //Stefan From w3c-dist-auth-request@w3.org Mon Jun 10 12:27: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 MAA11807 for ; Mon, 10 Jun 2002 12:27: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 MAA19542; Mon, 10 Jun 2002 12:26:57 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5AGQpQ21619; Mon, 10 Jun 2002 12:26:51 -0400 (EDT) Resent-Date: Mon, 10 Jun 2002 12:26:51 -0400 (EDT) Resent-Message-Id: <200206101626.g5AGQpQ21619@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 g5AGQn221593 for ; Mon, 10 Jun 2002 12:26:49 -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 MAA19507 for ; Mon, 10 Jun 2002 12:26:49 -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 g5AGQmk21779 for ; Mon, 10 Jun 2002 09:26:48 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 10 Jun 2002 09:26:47 -0700 Received: from luthji (luthji.apple.com [17.202.43.76]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g5AGQli19673 for ; Mon, 10 Jun 2002 09:26:47 -0700 (PDT) Date: Mon, 10 Jun 2002 09:26:46 -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@w3c.org Content-Transfer-Encoding: 7bit In-Reply-To: <002d01c20f3c$1f9b96e0$f8cb90c6@moose> Message-Id: X-Mailer: Apple Mail (2.482) Subject: Re: Support for 102 Processing Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6284 X-Loop: 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 Our client does not accept it at this time. And yes, it should. I haven't seen a server respond with it. - Jim On Saturday, June 8, 2002, at 03:30 PM, Lisa Dusseault wrote: > > > Has interoperability been shown for the 102 Processing response? Do any > servers send this status response? Do any clients accept it (all > *should*, > but I'd like confirming answers). > > Lisa From w3c-dist-auth-request@w3.org Mon Jun 10 15:16: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 PAA20361 for ; Mon, 10 Jun 2002 15:16: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 PAA19354; Mon, 10 Jun 2002 15:15:21 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5AJFJM03593; Mon, 10 Jun 2002 15:15:19 -0400 (EDT) Resent-Date: Mon, 10 Jun 2002 15:15:19 -0400 (EDT) Resent-Message-Id: <200206101915.g5AJFJM03593@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 g5AJFI203573 for ; Mon, 10 Jun 2002 15:15:18 -0400 (EDT) Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA19349 for ; Mon, 10 Jun 2002 15:15:17 -0400 Received: from manyfish.co.uk ([62.253.142.7]) by mta01-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020610191516.OEET28297.mta01-svc.ntlworld.com@manyfish.co.uk> for ; Mon, 10 Jun 2002 20:15:16 +0100 Received: (from joe@localhost) by manyfish.co.uk (8.11.6/8.11.6) id g5AJBk609499 for w3c-dist-auth@w3c.org; Mon, 10 Jun 2002 20:11:46 +0100 Date: Mon, 10 Jun 2002 20:11:46 +0100 From: Joe Orton To: w3c-dist-auth@w3c.org Message-ID: <20020610201146.A9419@light.plus.com> Mail-Followup-To: w3c-dist-auth@w3c.org References: <002d01c20f3c$1f9b96e0$f8cb90c6@moose> 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 luther.j@apple.com on Mon, Jun 10, 2002 at 09:26:46AM -0700 Subject: Re: Support for 102 Processing Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6285 X-Loop: 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 Mon, Jun 10, 2002 at 09:26:46AM -0700, Jim Luther wrote: > Our client does not accept it at this time. And yes, it should. > > I haven't seen a server respond with it. "102 processing" is really little different from any other intermediate 1xx response: it's a MUST requirement that an HTTP/1.1 client accepts intermediate 1xx responses. IIS sends unsolicited "100 continue" responses sometimes. joe From w3c-dist-auth-request@w3.org Tue Jun 11 11: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 LAA28681 for ; Tue, 11 Jun 2002 11:13: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 LAA30527; Tue, 11 Jun 2002 11:03:33 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5BF2kG10285; Tue, 11 Jun 2002 11:02:46 -0400 (EDT) Resent-Date: Tue, 11 Jun 2002 11:02:46 -0400 (EDT) Resent-Message-Id: <200206111502.g5BF2kG10285@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 g5BF2j210264 for ; Tue, 11 Jun 2002 11:02:45 -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 LAA29918 for ; Tue, 11 Jun 2002 11:02:45 -0400 Received: from 192.168.200.82 by bosvwl01.infy.com (InterScan E-Mail VirusWall NT); Tue, 11 Jun 2002 10:57:16 -0400 Received: from BLRKECIMR01.ad.infosys.com ([192.168.200.58]) by INDHUBBHS02.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 11 Jun 2002 20:33:19 +0530 Received: from kecmsg04.ad.infosys.com ([192.168.117.9]) by BLRKECIMR01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 11 Jun 2002 20:33:19 +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-8859-1" Date: Tue, 11 Jun 2002 20:33:19 +0530 Message-ID: <1BD922A62552D411B48A00D0B7472375042F732E@kecmsg04.ad.infosys.com> Thread-Index: AcIRWR8gXQD4PNR7SFCFiAejJAQi1A== From: "Rajiv A V" To: X-OriginalArrivalTime: 11 Jun 2002 15:03:19.0423 (UTC) FILETIME=[1F45E0F0:01C21159] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g5BF2j210264 Subject: [w3c-dist-auth] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6286 X-Loop: 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, I have a very trival issue in the use of lock tokens. reading about the use of lock tokens from the RFC it seems that a process (user)should be aware of the resources he is deleting. But let us assume that my client fetches lock tokens (performs lock discovery) on a need basis. Now assume that I want to delete a folder resource inside which I have some stuff that I have locked myself. I have 2 ways to implement it a) dont delete the resouce since the user hasnt seen the resource yet and wait for the user to see all the resources that he has locked (effectively meaning that then he has a lock token for all the needed resources because thats when the lock discovery is done) b) when i recieve that detail from the server that tells me that some resouce is locked, just inform the user that there are locks inside the folder. then on user confirmation the client would interally fetch all the lock tokens for resources that are locked inside the folder and goes ahead with the delete. this would be transparent to the user but the user knows that he is deleting resources that he has a lock on. I know this is a implementation issue but please let me know which is the right way to do it and would be more webdav compliant. thanks and regards, rajiv From w3c-dist-auth-request@w3.org Tue Jun 11 11:33: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 LAA29263 for ; Tue, 11 Jun 2002 11:33: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 LAA08139; Tue, 11 Jun 2002 11:20:40 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5BFKef17461; Tue, 11 Jun 2002 11:20:40 -0400 (EDT) Resent-Date: Tue, 11 Jun 2002 11:20:40 -0400 (EDT) Resent-Message-Id: <200206111520.g5BFKef17461@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 g5BFKd217441 for ; Tue, 11 Jun 2002 11:20:39 -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 LAA08110 for ; Tue, 11 Jun 2002 11:20:39 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Tue, 11 Jun 2002 11:14:25 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 11:20:07 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B279@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Tue, 11 Jun 2002 11:20: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: [w3c-dist-auth] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6287 X-Loop: 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: In normal practice, you should not be "stealing" lock tokens, even if the lock token was taken out by another process owned by "you". You should leave the resource alone until the process that took out the lock has released the lock. In an exceptional case, where the process that took out the lock has died before releasing the lock (and lock timeouts are not automatically releasing the lock), you can attempt to "steal" the lock tokens, but this should be an exceptional case, done only after explicit confirmation by the user ("yes, I want to override these locks"). Cheers, Geoff -----Original Message----- From: Rajiv A V [mailto:rajiv_av@infosys.com] Sent: Tuesday, June 11, 2002 11:03 AM To: w3c-dist-auth@w3c.org Subject: [w3c-dist-auth] Hi, I have a very trival issue in the use of lock tokens. reading about the use of lock tokens from the RFC it seems that a process (user)should be aware of the resources he is deleting. But let us assume that my client fetches lock tokens (performs lock discovery) on a need basis. Now assume that I want to delete a folder resource inside which I have some stuff that I have locked myself. I have 2 ways to implement it a) dont delete the resouce since the user hasnt seen the resource yet and wait for the user to see all the resources that he has locked (effectively meaning that then he has a lock token for all the needed resources because thats when the lock discovery is done) b) when i recieve that detail from the server that tells me that some resouce is locked, just inform the user that there are locks inside the folder. then on user confirmation the client would interally fetch all the lock tokens for resources that are locked inside the folder and goes ahead with the delete. this would be transparent to the user but the user knows that he is deleting resources that he has a lock on. I know this is a implementation issue but please let me know which is the right way to do it and would be more webdav compliant. thanks and regards, rajiv From w3c-dist-auth-request@w3.org Tue Jun 11 13:10: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 NAA03571 for ; Tue, 11 Jun 2002 13:10: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 MAA20353; Tue, 11 Jun 2002 12:58:18 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5BGwHx25302; Tue, 11 Jun 2002 12:58:17 -0400 (EDT) Resent-Date: Tue, 11 Jun 2002 12:58:17 -0400 (EDT) Resent-Message-Id: <200206111658.g5BGwHx25302@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 g5BGwF225276 for ; Tue, 11 Jun 2002 12:58: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 MAA20327 for ; Tue, 11 Jun 2002 12:58:15 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 11 Jun 2002 12:57:17 -0400 (Eastern Daylight Time) Received: from moose ([216.36.77.241]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Jun 2002 12:57:16 -0400 From: "Lisa Dusseault" To: "'Rajiv A V'" , Date: Tue, 11 Jun 2002 09:58:38 -0700 Message-ID: <006001c21169$3c917880$7801a8c0@moose> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0061_01C2112E.9032A080" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <1BD922A62552D411B48A00D0B7472375042F732E@kecmsg04.ad.infosys.com> X-MS-TNEF-Correlator: 000000003BB703D689545647AF3271739CD664C284522C00 X-OriginalArrivalTime: 11 Jun 2002 16:57:16.0837 (UTC) FILETIME=[0AB07550:01C21169] Subject: RE: [w3c-dist-auth] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6288 X-Loop: 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_0061_01C2112E.9032A080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Do not simply rely on fetching lock tokens with the lockdiscovery property. Your client will risk deleting locks which have been created by other WebDAV software used by the same user. For example, if your client deletes a lock which the user's Microsoft Word software created, Microsoft Word will be unable to save the file and will give the user an error. This means that all WebDAV client software must keep and maintain its own list of what resources it has locked. The only exception is when you can prompt the user to ask "Is it OK to remove the lock on this resource? Are you sure it isn't being locked by another process?" Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Rajiv A V > Sent: Tuesday, June 11, 2002 8:03 AM > To: w3c-dist-auth@w3c.org > Subject: [w3c-dist-auth] > > > Hi, > I have a very trival issue in the use of lock tokens. > reading about the use of lock tokens from the RFC it seems > that a process (user)should be aware of the resources he is > deleting. But let us assume that my client fetches lock > tokens (performs lock discovery) on a need basis. Now assume > that I want to delete a folder resource inside which I have > some stuff that I have locked myself. I have 2 ways to implement it > > a) dont delete the resouce since the user hasnt seen the > resource yet and wait for the user to see all the resources > that he has locked (effectively meaning that then he has a > lock token for all the needed resources because thats when > the lock discovery is done) > b) when i recieve that detail from the server that tells me > that some resouce is locked, just inform the user that there > are locks inside the folder. then on user confirmation > the client would interally fetch all the lock tokens for > resources that are locked inside the folder and goes ahead > with the delete. this would be transparent to the user but > the user knows that he is deleting resources that he has a lock on. > > I know this is a implementation issue but please let me know > which is the right way to do it and would be more webdav compliant. > > thanks and regards, > rajiv > ------=_NextPart_000_0061_01C2112E.9032A080 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IigQAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHBgALAAkAOgAAAAIALwEB A5AGAOgJAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAAXAAAAW3czYy1kaXN0LWF1dGhdIDxub25lPgAAAgFxAAEAAAAWAAAAAcIRaTt2 xB7kt3syR+6UDizOkaNBqAAAAgEdDAEAAAAbAAAAU01UUDpMRFVTU0VBVUxUQFhZVEhPUy5DT00A AAsAAQ4AAAAAQAAGDgCcaiRpEcIBAgEKDgEAAAAYAAAAAAAAADu3A9aJVFZHrzJxc5zWZMLCgAAA AwAUDgEAAAALAB8OAQAAAAIBCRABAAAA2AUAANQFAACTCgAATFpGda6eGdkDAAoAcmNwZzEyNeIy A0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2 MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAUDMLCQFkMzYWUAumIESwbyBubwVAAJBtC1CceSAY IB2hAiAgZhQgExPQC4BnIBewY2sgOHRvawnwBCAD8HRoaR8gaGUe02QEAAWgdisEkB2wcANgcASQ dHkQLiAgWQhhIGNstwiQAjAfkWwDIAUQcx8QfQEAbBQgHqYfgR6QE9AgcxPgIMAgYgnhIgAYIGE9 DrBkJLAeAR/xBcBXZVBiREFWHVBvAYB3OwrAIBB1FBAlcx/yc2HrB4AnEnIhkUYFsQ7AJ/CRC1Bl LCAGkCB5Idl7IyMHkWEe1CQUH/IoMif9BCBNDeADYCaSJhAFsCVwfyaXJRUpUCxtIoMkwCcQbr8B oCNAHyEn0SSRH/JmAxDnIBAAcC9FZ2kwpSgyMVF9KNByA2AoYAqiCoQKgFT/HpAEIAeABiIfwCVA KtAioXcmJSIVJpdtJyAFQB9QZX5wMVMAwAuAAZALgClgdPkEIG93A6AiIDbxJqAkAe808RggJpAI cGMHkR+wJGH/BCAe4gmAM10gEAIgHaEOwPs58AUwaR4hNEEkECThKaH/IgADkSERHYAFQDJHMFE6 cMkfECJJOhNPSzBCGCB/BGAwpR7jHiEfwDRBOZY/7yGgBxAgED2CcwhwIBA6MfkEAG4nBUAkwB6m JWQAcEclxCEROfFzPyIzakxFBABhM2o+IC1Hwk8vBRAx8C/wAyBNRZFhZ1ZlR8NHRkYDYTofkDOE Yy0gcXQtYXUfwFotGCBxClA28EBKQC5VBbBnR0ZbN7FsHzA6k0pPS1ldTwOgQmUT4IpsKYBPKYBS YWoyAHkQwCBWR0YGYAIwSiBU0UtRZGF5KVBKL+AgECwxMSlQAdAwFEA4OtQwMxDATUdGVEzgSjyF S5FjS8pTdWJqBZDFUOFbTQtdIDwdIFHA5j5HRld+SGkpUEdGIaCuSSRkKuAgw3QFEHZIcf8EAQpQ KWBBUicDOQIe6SGQ/0dGJSEgcB6xAaAIYD5XXC3HHkADYR/jUkZDOiIUEJ9AUAQhR1U01EVGICgo Mugpc2gIYGwlcTFBJtP/OREf8jmYIAE0QUdGIyYhkP5CXmEjQScRPyFC8CgBNNP+bR2wIhUeUweR HuNhZx9EdighQQIQcmExHuMgdyl/HhIq4FHAJWI6cAQAIZBO/ziAZ2Zha1nQJtAiUTBRKmT/KtEC EGNwEoE5lltxAJABAL8kBVnVR0YmkCgBNvB1ASD/bmYkc0Q1aDAUEE9AIZBZ1f8UQCbQdKAwQh1y QFAiQh+w9Vd+YWwQZAIhb1ZkZ3DB/QCQbnDBMkc6YTYSJNIf8vtdOHCFeWcRMWMLcGixBbH/Pnph ATUTZGxhayABOmhiwP8BEVXBMgEdoTRyHqI00x/x/wOggIUq4EdGHuh9Q36WbIL/JWE5mCTAPcBe 0jTSPRVhaE9A1SB4NEF4EWUpR0Zi62wQPTNpHcFjCJAwozTx/wEAN/EDIGAHKEEgwYKlHeD+bDRS YVxys3kWNEE6pClQ/mo24guAatI+aYLFJvF3Z/8m8SO0cPWUVTDTcAMhkIMD7x4hMoMFoJEwaWrw JUA8wv+IGiIWY1M30QSQNSEdsB5T/36HX0sFsXt+NLaTZSVhcPXzlNgxU2dvKrIgAF3QV+f/H6cq ZJVyPQJjVlqwAHEKsXciQjBRMkdiXmGIGjKDa/0dIHc0tWVEIyebzYNXQPX/M1VX2FnQpLJBZDRB KuB2J/+W1Fsko2IpITpwIBFnESgBv6lzn3ckIzRBZGNIMGgiYX9RYG8jdgF8pWNWBGAm8Xf/JjBR UE/gBaAdgQcwAjCoT100wm4j4TFiGCBnCxFzvixZOFmhmQBPwVd8fbYgHgBCEAEAAABDAAAAPDFC RDkyMkE2MjU1MkQ0MTFCNDhBMDBEMEI3NDcyMzc1MDQyRjczMkVAa2VjbXNnMDQuYWQuaW5mb3N5 cy5jb20+AAADAAlZAQAAAAsAFoAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwAYgAggBgAA AAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAB6ACCAGAAAAAADAAAAAAAAARgAAAABShQAAfW4BAAMA IoAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAHgBMgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUA AAEAAAAEAAAAOS4wAAsATYAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAACwBRgAggBgAAAAAA wAAAAAAAAEYAAAAADoUAAAAAAAADAFKACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAVIAI IAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAAgH4DwEAAAAQAAAAO7cD1olUVkevMnFznNZkwgIB +g8BAAAAEAAAADu3A9aJVFZHrzJxc5zWZMICAfsPAQAAAHAAAAAAAAAAOKG7EAXlEBqhuwgAKypW wgAAbXNwc3QuZGxsAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XERvY3VtZW50cyBhbmQgU2V0dGlu Z3NcbGlzYVxNeSBEb2N1bWVudHNcbGR1c3NlYXVsdC5wc3QAAwD+DwUAAAADAA00/TcAAAIBfwAB AAAAMQAAADAwMDAwMDAwM0JCNzAzRDY4OTU0NTY0N0FGMzI3MTczOUNENjY0QzI4NDUyMkMwMAAA AAADAAYQeNvl+gMABxCzBgAAAwAQEAAAAAADABEQAQAAAB4ACBABAAAAZQAAAERPTk9UU0lNUExZ UkVMWU9ORkVUQ0hJTkdMT0NLVE9LRU5TV0lUSFRIRUxPQ0tESVNDT1ZFUllQUk9QRVJUWVlPVVJD TElFTlRXSUxMUklTS0RFTEVUSU5HTE9DS1NXSElDSEgAAAAAtLQ= ------=_NextPart_000_0061_01C2112E.9032A080-- From w3c-dist-auth-request@w3.org Tue Jun 11 22:16: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 WAA20099 for ; Tue, 11 Jun 2002 22:16: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 WAA12677; Tue, 11 Jun 2002 22:15:18 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5C2EoC05341; Tue, 11 Jun 2002 22:14:50 -0400 (EDT) Resent-Date: Tue, 11 Jun 2002 22:14:50 -0400 (EDT) Resent-Message-Id: <200206120214.g5C2EoC05341@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 g5C2Em205301 for ; Tue, 11 Jun 2002 22:14:48 -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 WAA12525 for ; Tue, 11 Jun 2002 22:14:48 -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 g5C2Elk10880 for ; Tue, 11 Jun 2002 19:14:47 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 11 Jun 2002 19:14:47 -0700 Received: from luthji (luthji.apple.com [17.202.43.76]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g5C2ElX19534 for ; Tue, 11 Jun 2002 19:14:47 -0700 (PDT) Date: Tue, 11 Jun 2002 19:14:47 -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@w3c.org Content-Transfer-Encoding: 7bit In-Reply-To: <20020610201146.A9419@light.plus.com> Message-Id: <2AFBB946-7DAA-11D6-8678-0003934B6A22@apple.com> X-Mailer: Apple Mail (2.482) Subject: Re: Support for 102 Processing Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6289 X-Loop: 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 It already handled "100 continue" so I changed it to handle other 1xx responses. - Jim On Monday, June 10, 2002, at 12:11 PM, Joe Orton wrote: > > On Mon, Jun 10, 2002 at 09:26:46AM -0700, Jim Luther wrote: >> Our client does not accept it at this time. And yes, it should. >> >> I haven't seen a server respond with it. > > "102 processing" is really little different from any other intermediate > 1xx response: it's a MUST requirement that an HTTP/1.1 client accepts > intermediate 1xx responses. > > IIS sends unsolicited "100 continue" responses sometimes. > > joe From w3c-dist-auth-request@w3.org Wed Jun 12 13:21: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 NAA05688 for ; Wed, 12 Jun 2002 13:21: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 NAA27032; Wed, 12 Jun 2002 13:20:41 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5CHKcv29977; Wed, 12 Jun 2002 13:20:38 -0400 (EDT) Resent-Date: Wed, 12 Jun 2002 13:20:38 -0400 (EDT) Resent-Message-Id: <200206121720.g5CHKcv29977@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 g5CHKZ229920 for ; Wed, 12 Jun 2002 13:20:35 -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 NAA27007 for ; Wed, 12 Jun 2002 13:20:35 -0400 Received: (qmail 21265 invoked by uid 0); 12 Jun 2002 17:20:03 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp015-rz3) with SMTP; 12 Jun 2002 17:20:03 -0000 From: "Julian Reschke" To: Date: Wed, 12 Jun 2002 19:20:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8B279@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: Bug in MS webfolder client: Content-Language header when PUTting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6290 X-Loop: 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, another bug report regarding Microsoft's webfolder client (posted here so that it's archived in the mailing list archives): When creating files on a WebDAV server, the clients submits a "Content-Language" header with the PUT request (on my machine: always "en-us"), even though the content language isn't known (and obviously may be different). This can trick a WebDAV server to persist this information (and to return it as DAV:getcontentlanguage property). Is anybody aware of a fix or workaround for this problem (other than ignoring the content language header for specific user agents)? Julian From w3c-dist-auth-request@w3.org Wed Jun 12 16:05: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 QAA11427 for ; Wed, 12 Jun 2002 16:05: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 QAA06949; Wed, 12 Jun 2002 16:04:28 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5CK4Rt17922; Wed, 12 Jun 2002 16:04:27 -0400 (EDT) Resent-Date: Wed, 12 Jun 2002 16:04:27 -0400 (EDT) Resent-Message-Id: <200206122004.g5CK4Rt17922@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 g5CK4O217855 for ; Wed, 12 Jun 2002 16:04:24 -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 QAA06910 for ; Wed, 12 Jun 2002 16:04:24 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.wakasoft.com (8.12.4/8.12.4) with ESMTP id g5CK4aMe000444; Wed, 12 Jun 2002 13:04:36 -0700 (PDT) Date: Wed, 12 Jun 2002 13:04:35 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "'Julian Reschke'" , "'Webdav WG \(E-mail\)'" To: "Lisa Dusseault" From: "Roy T. Fielding" In-Reply-To: <000301c20fe0$603a9c60$f8cb90c6@moose> Message-Id: <9E37A634-7E3F-11D6-B747-000393753936@apache.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6291 X-Loop: 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 >>> 1. Must the resources pointed to by the SOURCE header be >>> WebDAV-compatible? >> >> a) What is the definition of a "WebDAV-compatible" resource? Being the >> member of a WebDAV collection? >> >> b) I'm tempted to say: no. > > If an OPTIONS response for the resource includes the DAV: header with > level > 1 or 2 support, it's a WebDAV resource. If the answer is "no it's not a > WebDAV resource", then how is authoring of the dynamic content possible? 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. >>> 2. Must the source property point to ALL the files involved in >>> producing the result? Be careful here -- there could be data files as >> well as source >>> code, libraries, build files, etc. >> >> I don't think that's feasible. > > If it's not possible to view and edit or replace all the files involved in > producing the result, then how is it possible to authoring dynamic > content? How is it possible to author an e-mail message when some of the message header fields are generated? That question is simply not relevant to the issue of identifying the source of dynamic content when the server does have a URI for that content. >>> 4. Clearly in order to get the source code for a dynamic resource, the >>> client must do a GET to the URL(s) in the source header. But what URL >>> should the client send PUT to? Does PROPFIND address the source >>> code or the output? >> >> Source and dynamic resources are different resources with >> separate URLs. All >> HTTP/WebDAV methods operate on the respective request URLs. > > Compare with the next question/answer to see the inconsistency with this > position. They are different resources. The effects of a particular method on any particular resource are defined by that resource. The source for one resource may itself be a dynamic content resource with its own source URI. >>> 5. What does it mean when a dynamically-generated resource is the >>> source for >>> a COPY request? Is it different when it's the source for a MOVE >>> request? If that isn't already defined by RFC 2518, then it isn't defined for any resource. There is no distinction on the Web between dynamic and static content. >> >> I think that's open to discussion. For COPY, it seems it >> would make sense to >> require that the newly created resource must behave as the original >> resource, so it should still be a dynamic resource, and have >> the same source >> links. MOVE obviously MUST move the resource -- and if this >> can't be done by >> the server, the request must fail. > > All right, now we see the inconsistency. Say we have a dynamic resource, > "foo", and the server reports that there's only one source file, > "foo-source". > > If all methods operate on the respective request URIs, that means that a > COPY request to foo must operate on the dynamically-generated content, not > the source. So wouldn't that mean that a snapshot of foo is copied to the > destination? It wouldn't be a dynamic resource. Fair enough. Presumably > we > can COPY foo-source to get a second dynamic resource. But what happens if > you MOVE foo? Does it operate only on a snapshot of the dynamic resource? > What does that mean? Why is this confusing? If a resource does not allow COPY, then it would not respond to COPY with 200. There is no magic being done behind the curtains. What does COPY mean for RFC 2518? It means the same thing for both dynamic and generated resource -- there is no difference between the two. Some resources will simply not allow COPY or MOVE. That is why it is NECESSARY to point to the source of the resources, since those other resources are the ones that usually can be copied or moved. >>> 6. How does a client *create* dynamically-generated Web pages? Think of >>> all >>> the problems with that - where should the client upload new source >>> files? >>> How can the client specify what URL in the main repository is actually >>> an >>> invocation to handle this dynamic resource? >> >> Right now I'd say that's server-specifc. Depending on how dynamic >> resources >> are implemented, it's hard to see how there can be a generic way to >> author >> them. There are many ways in which a namespace can be constructed on a server. The user creating a service generally knows what they are doing or are following the instructions provided to them by the server owner. >>> 7. How does a client add a new source file to an existing set of source >>> files? E.g. assume I want to modify a JSP to call a new object in a new >>> library. That library is not on the server yet. How do I upload >>> it? Where >> >> Again, I think this is server-specific. The server may allow you to PUT >> the >> file anywhere, or at a specific location. And of course a server may >> allow >> PROPPATCH on the source-set property. > > Seems to me both 6 and 7 are essential features. I don't understand how > authoring dynamic content is supposed to work unless we offer them. The degree to which the server's implementation space is itself a WebDAV- enabled name space is dependent on the particular site configuration and none of our business. If they are authorable, the user will be able to author them. There is no need, nor any desire, for such security-sensitive activities to be automatically handled by authoring tools. >>> to? How do I indicate to the server that it's a source file and not a >>> content file? >> >> What's the difference? > > A new source file is a new file which will be interpreted or compiled by > the > server in order to produce dynamic content. By "content file" I meant > static Web page, or regular resource. How can the client create a new > source file and let the server know it's supposed to interpret or compile > it? The server will either already know how to interpret its name space or the client will author (via another URL) the appropriate configuration or binding needed to enable the dynamic resource. ....Roy From w3c-dist-auth-request@w3.org Wed Jun 12 16:22: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 QAA12000 for ; Wed, 12 Jun 2002 16:22: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 QAA14350; Wed, 12 Jun 2002 16:21:28 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5CKLNv25781; Wed, 12 Jun 2002 16:21:23 -0400 (EDT) Resent-Date: Wed, 12 Jun 2002 16:21:23 -0400 (EDT) Resent-Message-Id: <200206122021.g5CKLNv25781@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 g5CKLM225758 for ; Wed, 12 Jun 2002 16:21:22 -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 QAA14297 for ; Wed, 12 Jun 2002 16:21:22 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Wed, 12 Jun 2002 16:15:05 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 16:20:50 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B287@SUS-MA1IT01> From: "Clemm, Geoff" To: "'Webdav WG (E-mail)'" Date: Wed, 12 Jun 2002 16:20:49 -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/6292 X-Loop: 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 Greg on all these issues. The DAV:source field provides a valuable standardized redirection to the "thing you have to modify in order to get the thing you are looking at to change". In many cases, it will be sufficient to bring the source resource into your editor, make some changes, save it, and refresh the page for the resource you were originally looking at. In more complicated scenarios, it at least points you to the right neighborhood, and you (or your client) can take advantage of any knowledge you have about how authoring is done in that scenario. This is an extremely valuable function that can be done with just a standard way of storing the "source" pointers. From my perspective, even the "role" field is a valuable, but not essential addition. Cheers, Geoff P.S. And lest anyone forget (:-), I would want the href (and role info, if we standardize on it) to appear in XML elements, not in attributes, for compatibility with current WebDAV marshalling. -----Original Message----- From: Roy T. Fielding [mailto:fielding@apache.org] Sent: Wednesday, June 12, 2002 4:05 PM To: Lisa Dusseault Cc: 'Julian Reschke'; 'Webdav WG (E-mail)' Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED >>> 1. Must the resources pointed to by the SOURCE header be >>> WebDAV-compatible? >> >> a) What is the definition of a "WebDAV-compatible" resource? Being the >> member of a WebDAV collection? >> >> b) I'm tempted to say: no. > > If an OPTIONS response for the resource includes the DAV: header with > level > 1 or 2 support, it's a WebDAV resource. If the answer is "no it's not a > WebDAV resource", then how is authoring of the dynamic content possible? 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. >>> 2. Must the source property point to ALL the files involved in >>> producing the result? Be careful here -- there could be data files as >> well as source >>> code, libraries, build files, etc. >> >> I don't think that's feasible. > > If it's not possible to view and edit or replace all the files involved in > producing the result, then how is it possible to authoring dynamic > content? How is it possible to author an e-mail message when some of the message header fields are generated? That question is simply not relevant to the issue of identifying the source of dynamic content when the server does have a URI for that content. >>> 4. Clearly in order to get the source code for a dynamic resource, the >>> client must do a GET to the URL(s) in the source header. But what URL >>> should the client send PUT to? Does PROPFIND address the source >>> code or the output? >> >> Source and dynamic resources are different resources with >> separate URLs. All >> HTTP/WebDAV methods operate on the respective request URLs. > > Compare with the next question/answer to see the inconsistency with this > position. They are different resources. The effects of a particular method on any particular resource are defined by that resource. The source for one resource may itself be a dynamic content resource with its own source URI. >>> 5. What does it mean when a dynamically-generated resource is the >>> source for >>> a COPY request? Is it different when it's the source for a MOVE >>> request? If that isn't already defined by RFC 2518, then it isn't defined for any resource. There is no distinction on the Web between dynamic and static content. >> >> I think that's open to discussion. For COPY, it seems it >> would make sense to >> require that the newly created resource must behave as the original >> resource, so it should still be a dynamic resource, and have >> the same source >> links. MOVE obviously MUST move the resource -- and if this >> can't be done by >> the server, the request must fail. > > All right, now we see the inconsistency. Say we have a dynamic resource, > "foo", and the server reports that there's only one source file, > "foo-source". > > If all methods operate on the respective request URIs, that means that a > COPY request to foo must operate on the dynamically-generated content, not > the source. So wouldn't that mean that a snapshot of foo is copied to the > destination? It wouldn't be a dynamic resource. Fair enough. Presumably > we > can COPY foo-source to get a second dynamic resource. But what happens if > you MOVE foo? Does it operate only on a snapshot of the dynamic resource? > What does that mean? Why is this confusing? If a resource does not allow COPY, then it would not respond to COPY with 200. There is no magic being done behind the curtains. What does COPY mean for RFC 2518? It means the same thing for both dynamic and generated resource -- there is no difference between the two. Some resources will simply not allow COPY or MOVE. That is why it is NECESSARY to point to the source of the resources, since those other resources are the ones that usually can be copied or moved. >>> 6. How does a client *create* dynamically-generated Web pages? Think of >>> all >>> the problems with that - where should the client upload new source >>> files? >>> How can the client specify what URL in the main repository is actually >>> an >>> invocation to handle this dynamic resource? >> >> Right now I'd say that's server-specifc. Depending on how dynamic >> resources >> are implemented, it's hard to see how there can be a generic way to >> author >> them. There are many ways in which a namespace can be constructed on a server. The user creating a service generally knows what they are doing or are following the instructions provided to them by the server owner. >>> 7. How does a client add a new source file to an existing set of source >>> files? E.g. assume I want to modify a JSP to call a new object in a new >>> library. That library is not on the server yet. How do I upload >>> it? Where >> >> Again, I think this is server-specific. The server may allow you to PUT >> the >> file anywhere, or at a specific location. And of course a server may >> allow >> PROPPATCH on the source-set property. > > Seems to me both 6 and 7 are essential features. I don't understand how > authoring dynamic content is supposed to work unless we offer them. The degree to which the server's implementation space is itself a WebDAV- enabled name space is dependent on the particular site configuration and none of our business. If they are authorable, the user will be able to author them. There is no need, nor any desire, for such security-sensitive activities to be automatically handled by authoring tools. >>> to? How do I indicate to the server that it's a source file and not a >>> content file? >> >> What's the difference? > > A new source file is a new file which will be interpreted or compiled by > the > server in order to produce dynamic content. By "content file" I meant > static Web page, or regular resource. How can the client create a new > source file and let the server know it's supposed to interpret or compile > it? The server will either already know how to interpret its name space or the client will author (via another URL) the appropriate configuration or binding needed to enable the dynamic resource. ....Roy From w3c-dist-auth-request@w3.org Wed Jun 12 17:08: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 RAA13080 for ; Wed, 12 Jun 2002 17:08: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 RAA02425; Wed, 12 Jun 2002 17:08:00 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5CL7x717075; Wed, 12 Jun 2002 17:07:59 -0400 (EDT) Resent-Date: Wed, 12 Jun 2002 17:07:59 -0400 (EDT) Resent-Message-Id: <200206122107.g5CL7x717075@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 g5CL7w217055 for ; Wed, 12 Jun 2002 17:07:58 -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 RAA02400 for ; Wed, 12 Jun 2002 17:07:57 -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 g5CL7ug07829 for ; Wed, 12 Jun 2002 14:07:56 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 12 Jun 2002 14:07:20 -0700 Received: from luthji (luthji.apple.com [17.202.43.76]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id g5CL7tD20001 for ; Wed, 12 Jun 2002 14:07:55 -0700 (PDT) Date: Wed, 12 Jun 2002 14:07:55 -0700 Mime-Version: 1.0 (Apple Message framework v482) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Jim Luther To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 7bit Message-Id: <771FB218-7E48-11D6-8678-0003934B6A22@apple.com> X-Mailer: Apple Mail (2.482) Subject: DAV Header and extend Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6293 X-Loop: 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 Back in May 2000, there was a discussion at of how extend was defined in the DAV header definition: DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend] The consensus of that thread seemed to be that extend should be defined: extend = Coded-URL | token However, the issue is still listed as an open issue. Why did I bring this up? Because I finally found an Apache 2.0 server I could test against to determine why our WebDAV client gave read-only access to those servers. The problem was caused by a combination of the Coded-URL in the DAV Header from the Apache 2 server and a bug in our code that handles DAV headers. To fix this problem, I need to handle the DAV header correctly. To handle it correctly, I need extend to be defined. At this point, I guess I'll write my code to handle extend as defined above. However, it would be nice if this issue could be closed so that I don't have to worry about someone else throwing something new into the DAV header in the future that my code can't handle. - Jim From w3c-dist-auth-request@w3.org Wed Jun 12 17:17:49 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 RAA13381 for ; Wed, 12 Jun 2002 17:17:49 -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 RAA05590; Wed, 12 Jun 2002 17:15:28 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5CLFRh20951; Wed, 12 Jun 2002 17:15:27 -0400 (EDT) Resent-Date: Wed, 12 Jun 2002 17:15:27 -0400 (EDT) Resent-Message-Id: <200206122115.g5CLFRh20951@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 g5CLFR220928 for ; Wed, 12 Jun 2002 17:15:27 -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 RAA05578 for ; Wed, 12 Jun 2002 17:15:26 -0400 Received: (qmail 9013 invoked by uid 0); 12 Jun 2002 21:14:55 -0000 Received: from p3ee24708.dip.t-dialin.net (HELO lisa) (62.226.71.8) by mail.gmx.net (mp006-rz3) with SMTP; 12 Jun 2002 21:14:55 -0000 From: "Julian Reschke" To: "Jim Luther" , Date: Wed, 12 Jun 2002 23:14:58 +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: <771FB218-7E48-11D6-8678-0003934B6A22@apple.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: DAV Header and extend Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6294 X-Loop: 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 Jim, given the fact that Apache already uses this extension syntax, we're probably stuck with it. However, I hereby claim that extending the DAV: header with private extensions is entirely unnecessary, and that RFC2518bis should discourage this. Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Luther > Sent: Wednesday, June 12, 2002 11:08 PM > To: w3c-dist-auth@w3c.org > Subject: DAV Header and extend > > > > Back in May 2000, there was a discussion at > > of how extend was defined in the DAV header definition: > > DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend] > > The consensus of that thread seemed to be that extend should be defined: > > extend = Coded-URL | token > > However, the issue is still listed as an open issue. > > Why did I bring this up? Because I finally found an Apache 2.0 server I > could test against to determine why our WebDAV client gave read-only > access to those servers. The problem was caused by a combination of the > Coded-URL in the DAV Header from the Apache 2 server and a bug in our > code that handles DAV headers. To fix this problem, I need to handle the > DAV header correctly. To handle it correctly, I need extend to be > defined. > > At this point, I guess I'll write my code to handle extend as defined > above. However, it would be nice if this issue could be closed so that I > don't have to worry about someone else throwing something new into the > DAV header in the future that my code can't handle. > > - Jim > From w3c-dist-auth-request@w3.org Fri Jun 14 18:59: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 SAA18809 for ; Fri, 14 Jun 2002 18:59: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 SAA19675; Fri, 14 Jun 2002 18:58:25 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5EMvrx13171; Fri, 14 Jun 2002 18:57:53 -0400 (EDT) Resent-Date: Fri, 14 Jun 2002 18:57:53 -0400 (EDT) Resent-Message-Id: <200206142257.g5EMvrx13171@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 g5EMvp213151 for ; Fri, 14 Jun 2002 18:57: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 SAA19597 for ; Fri, 14 Jun 2002 18:57:51 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Fri, 14 Jun 2002 18:57:10 -0400 (Eastern Daylight Time) Received: from moose ([198.144.203.248]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Jun 2002 18:57:09 -0400 From: "Lisa Dusseault" To: "'Julian Reschke'" Cc: "Webdav WG \(E-mail\)" Date: Fri, 14 Jun 2002 15:58:25 -0700 Message-ID: <009a01c213f6$fe7b2100$f8cb90c6@moose> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: Importance: Normal X-OriginalArrivalTime: 14 Jun 2002 22:57:09.0661 (UTC) FILETIME=[D0412CD0:01C213F6] Subject: RE: Bug in MS webfolder client: Content-Language header when PUTting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6295 X-Loop: 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 Have you investigated whether Web Folders submits a Content-Language header with a different value if the user's system language is not "en-us"? It may be that the user's system language is the closed Web Folders can get to knowing the language of the file. If that is the case, then I would think it would be wrong of the WebDAV server to ignore the value. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Wednesday, June 12, 2002 10:20 AM > To: w3c-dist-auth@w3c.org > Subject: Bug in MS webfolder client: Content-Language header when > PUTting > > > > Hi, > > another bug report regarding Microsoft's webfolder client > (posted here so > that it's archived in the mailing list archives): > > When creating files on a WebDAV server, the clients submits a > "Content-Language" header with the PUT request (on my machine: always > "en-us"), even though the content language isn't known (and > obviously may be > different). This can trick a WebDAV server to persist this > information (and > to return it as DAV:getcontentlanguage property). > > Is anybody aware of a fix or workaround for this problem (other than > ignoring the content language header for specific user agents)? > > Julian > From w3c-dist-auth-request@w3.org Sat Jun 15 02:20: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 CAA03546 for ; Sat, 15 Jun 2002 02:20: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 CAA30452; Sat, 15 Jun 2002 02:20:08 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5F6K1o03604; Sat, 15 Jun 2002 02:20:01 -0400 (EDT) Resent-Date: Sat, 15 Jun 2002 02:20:01 -0400 (EDT) Resent-Message-Id: <200206150620.g5F6K1o03604@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 g5F6K0203557 for ; Sat, 15 Jun 2002 02:20:00 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id CAA30404 for ; Sat, 15 Jun 2002 02:19:59 -0400 Received: (qmail 27641 invoked by uid 0); 15 Jun 2002 06:19:28 -0000 Received: from p3ee24714.dip.t-dialin.net (HELO lisa) (62.226.71.20) by mail.gmx.net (mp009-rz3) with SMTP; 15 Jun 2002 06:19:28 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" Cc: "Webdav WG \(E-mail\)" Date: Sat, 15 Jun 2002 08:19: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) In-Reply-To: <009a01c213f6$fe7b2100$f8cb90c6@moose> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Bug in MS webfolder client: Content-Language header when PUTting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6296 X-Loop: 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: Saturday, June 15, 2002 12:58 AM > To: 'Julian Reschke' > Cc: Webdav WG (E-mail) > Subject: RE: Bug in MS webfolder client: Content-Language header when > PUTting > > > > Have you investigated whether Web Folders submits a > Content-Language header > with a different value if the user's system language is not > "en-us"? It may May system's language indeed is not "en-us", but that's what the client is submitting. > be that the user's system language is the closed Web Folders can get to > knowing the language of the file. > > If that is the case, then I would think it would be wrong of the WebDAV > server to ignore the value. It would still be the wrong value. A system default is not good enough. If a client doesn't know the content language, it MUST not submit it. From w3c-dist-auth-request@w3.org Sat Jun 15 11:39:44 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 LAA10222 for ; Sat, 15 Jun 2002 11:39: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 LAA18824; Sat, 15 Jun 2002 11:38:58 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5FFct929744; Sat, 15 Jun 2002 11:38:55 -0400 (EDT) Resent-Date: Sat, 15 Jun 2002 11:38:55 -0400 (EDT) Resent-Message-Id: <200206151538.g5FFct929744@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 g5FFcr229724 for ; Sat, 15 Jun 2002 11:38:53 -0400 (EDT) Received: from cpimssmtpu12.email.msn.com (cpimssmtpu12.email.msn.com [207.46.181.87]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA18772 for ; Sat, 15 Jun 2002 11:38:53 -0400 Received: from centro ([63.231.38.27]) by cpimssmtpu12.email.msn.com with Microsoft SMTPSVC(5.0.2195.4905); Sat, 15 Jun 2002 08:37:36 -0700 Reply-To: From: "Dennis E. Hamilton" To: "Julian Reschke" , "Lisa Dusseault" Cc: "Webdav WG \(E-mail\)" Date: Sat, 15 Jun 2002 08:38:19 -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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 15 Jun 2002 15:37:36.0173 (UTC) FILETIME=[92D805D0:01C21482] Subject: RE: Bug in MS webfolder client: Content-Language header when PUTting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6297 X-Loop: 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, system language should not be assumed for content. My system language is en-us, my date-time preference is ISO ("yyyy-mm-dd-hh:mm -0700" 24-hour local time), my Internet language preferences are (1) Italian and then (2) English (American). My settings for menus and windows are Italian. At the moment I have content on my machine in English (mostly American, both transatlantic flavors), Italian, Spanish, German and Japanese. I have some files in Russian and a variety of central European languages -- intermixed. This is happening more and more. The system language setting is not a reliable indicator of content language. I think it is better to say nothing than to assume something based on the coincidence of a default that actually has little technical relationship to content. I think the architectural principle that applies here is one of not solving problems that are not ones we created. Compensating for a problem that arises elsewhere (a practice that has led to no end of troubles with mail servers) at a point where there is inadequate information is, in my experience, an open invitation to system disintegration. -- Dennis -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke Sent: Friday, June 14, 2002 23:20 To: Lisa Dusseault; 'Julian Reschke' Cc: Webdav WG (E-mail) Subject: RE: Bug in MS webfolder client: Content-Language header when PUTting > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Saturday, June 15, 2002 12:58 AM > To: 'Julian Reschke' > Cc: Webdav WG (E-mail) > Subject: RE: Bug in MS webfolder client: Content-Language header when > PUTting > > > > Have you investigated whether Web Folders submits a > Content-Language header > with a different value if the user's system language is not > "en-us"? It may May system's language indeed is not "en-us", but that's what the client is submitting. > be that the user's system language is the closed Web Folders can get to > knowing the language of the file. > > If that is the case, then I would think it would be wrong of the WebDAV > server to ignore the value. It would still be the wrong value. A system default is not good enough. If a client doesn't know the content language, it MUST not submit it. From w3c-dist-auth-request@w3.org Mon Jun 17 19:47: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 TAA23660 for ; Mon, 17 Jun 2002 19:47: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 TAA06317; Mon, 17 Jun 2002 19:46:24 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5HNjri08008; Mon, 17 Jun 2002 19:45:53 -0400 (EDT) Resent-Date: Mon, 17 Jun 2002 19:45:53 -0400 (EDT) Resent-Message-Id: <200206172345.g5HNjri08008@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 g5HNjp207984 for ; Mon, 17 Jun 2002 19:45:51 -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 TAA06204 for ; Mon, 17 Jun 2002 19:45:51 -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 g5HNjnk04834 for ; Mon, 17 Jun 2002 16:45:49 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 17 Jun 2002 16:45:49 -0700 Received: from luthji (luthji.apple.com [17.202.43.76]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g5HNjjX00689 for ; Mon, 17 Jun 2002 16:45:48 -0700 (PDT) Date: Mon, 17 Jun 2002 16:45:44 -0700 Mime-Version: 1.0 (Apple Message framework v482) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Jim Luther To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 7bit Message-Id: <574F11EC-824C-11D6-9679-0003934B6A22@apple.com> X-Mailer: Apple Mail (2.482) Subject: Collections and Request-URIs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6298 X-Loop: 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 RFC 2518, section 5.2 says: "There is a standing convention that when a collection is referred to by its name without a trailing slash, the trailing slash is automatically appended. Due to this, a resource may accept a URI without a trailing "/" to point to a collection. In this case it SHOULD return a content-location header in the response pointing to the URI ending with the "/". For example, if a client invokes a method on http://foo.bar/blah (no trailing slash), the resource http://foo.bar/blah/ (trailing slash) may respond as if the operation were invoked on it, and should return a content-location header with http://foo.bar/blah/ in it. In general clients SHOULD use the "/" form of collection names." It looks to me like the "standing convention" doesn't match the BNF. RFC 2616, section 5.1.2 gives this rule for the Request-URI in the Request-Line: Request-URI = "*" | absoluteURI | abs_path | authority and RFC 2396, section 3 gives these rules for abs_path and path_segments: abs_path = "/" path_segments path_segments = segment *( "/" segment ) So by my reading, abs_path should not have a trailing slash. Did I miss something? If not, I think the WebDAV spec should say that servers MUST handle Request-URIs to collections without the trail slash. Anyway, trailing slashes issue causes an interoperability problem for our WebDAV file system and Apache 2.0 servers. Since Mac OS X's WebDAV file system doesn't know if the end path component passed to it is a collection or non-collection resource, it doesn't put a trailing slash on the Request-URI. This works on all servers except for Apache 2 which sends us a "301 Moved Permanently" response. We don't redirect because the HTTP spec (RFC 2616, section 10.3.2) says: "If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued." Hmmm... WebDAV file system can't confirm it with the user because it's a file system which doesn't do user interaction. I guess that I could compare the URI in the 301 response to see if it's the same as what I sent except for the trailing slash and retry the request. However, that would double the number of PROPFIND for collection transactions we send to Apache 2 servers and I'm trying to cut the number of transactions from our client, not increase them. Apparently, Microsoft WebFolders had the same problem with Apache 2. Here's what we found in httpd.conf: # # The following directive disables redirects on non-GET requests for # a directory that does not include the trailing slash. This fixes a # problem with Microsoft WebFolders which does not appropriately handle # redirects for folders with DAV methods. # BrowserMatch "Microsoft Data Access Internet Publishing Provider" redirect-carefully BrowserMatch "^WebDrive" redirect-carefully So if we add a similar line: BrowserMatch "^WebDAVFS" redirect-carefully to Apache's httpd.conf file to do a redirect-carefully for our User-Agent, our client works great with Apache 2 DAV servers. - Jim Luther From w3c-dist-auth-request@w3.org Tue Jun 18 02:18: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 CAA08208 for ; Tue, 18 Jun 2002 02:18: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 CAA32275; Tue, 18 Jun 2002 02:17:39 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5I6HXl02983; Tue, 18 Jun 2002 02:17:33 -0400 (EDT) Resent-Date: Tue, 18 Jun 2002 02:17:33 -0400 (EDT) Resent-Message-Id: <200206180617.g5I6HXl02983@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 g5I6HV202963 for ; Tue, 18 Jun 2002 02:17: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 CAA32253 for ; Tue, 18 Jun 2002 02:17:31 -0400 Received: (qmail 24822 invoked by uid 0); 18 Jun 2002 06:16:55 -0000 Received: from p3ee2472d.dip.t-dialin.net (HELO lisa) (62.226.71.45) by mail.gmx.net (mp010-rz3) with SMTP; 18 Jun 2002 06:16:55 -0000 From: "Julian Reschke" To: "Jim Luther" , Date: Tue, 18 Jun 2002 08:16:58 +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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <574F11EC-824C-11D6-9679-0003934B6A22@apple.com> Subject: RE: Collections and Request-URIs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6299 X-Loop: 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 Luther > Sent: Tuesday, June 18, 2002 1:46 AM > To: w3c-dist-auth@w3c.org > Subject: Collections and Request-URIs > > > > RFC 2518, section 5.2 says: > > "There is a standing convention that when a collection is referred to by > its name without a trailing slash, the trailing slash is automatically > appended. Due to this, a resource may accept a URI without a > trailing "/" to point to a collection. In this case it SHOULD return a > content-location header in the response pointing to the URI ending with > the "/". For example, if a client invokes a method on > http://foo.bar/blah (no trailing slash), the resource > http://foo.bar/blah/ (trailing slash) may respond as if the operation > were invoked on it, and should return a content-location header with > http://foo.bar/blah/ in it. In general clients SHOULD use the "/" form > of collection names." > > It looks to me like the "standing convention" doesn't match the BNF. RFC > 2616, section 5.1.2 gives this rule for the Request-URI in the > Request-Line: > > Request-URI = "*" | absoluteURI | abs_path | authority > > and RFC 2396, section 3 gives these rules for abs_path and path_segments: > > abs_path = "/" path_segments > path_segments = segment *( "/" segment ) > > So by my reading, abs_path should not have a trailing slash. Did I miss > something? If not, I think the WebDAV spec should say that servers MUST > handle Request-URIs to collections without the trail slash. However: segment = *pchar *( ";" param ) param = *pchar pchar = unreserved | escaped | ":" | "@" | "&" | "=" | "+" | "$" | "," ([1]) and "The second convention is a BNF-like grammar, used to define the formal URI syntax. The grammar is that of [RFC822], except that "|" is used to designate alternatives. Briefly, rules are separated from definitions by an equal "=", indentation is used to continue a rule definition over more than one line, literals are quoted with "", parentheses "(" and ")" are used to group elements, optional elements are enclosed in "[" and "]" brackets, and elements may be preceded with * to designate n or more repetitions of the following element; n defaults to 0." ([2]). So it seems that "segment" may be empty. Julian [1] [2] From w3c-dist-auth-request@w3.org Tue Jun 18 07:50: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 HAA13617 for ; Tue, 18 Jun 2002 07:50: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 HAA21951; Tue, 18 Jun 2002 07:49:58 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5IBnpo13850; Tue, 18 Jun 2002 07:49:51 -0400 (EDT) Resent-Date: Tue, 18 Jun 2002 07:49:51 -0400 (EDT) Resent-Message-Id: <200206181149.g5IBnpo13850@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 g5IBnn213827 for ; Tue, 18 Jun 2002 07:49:49 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA21925 for ; Tue, 18 Jun 2002 07:49:49 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Tue, 18 Jun 2002 07:43:18 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Jun 2002 07:49:18 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B10731939A@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Tue, 18 Jun 2002 07:49:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Collections and Request-URIs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6300 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree with Julian (i.e. that trailing slashes are allowed by the syntax), but I also have argued vigorously that the RFC-2518 "guidance" is incorrect, and the next revision of RFC-2518 should simply state "a URI with a trailing slash SHOULD identify the same resource as the URI with the trailing slash removed". Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Tuesday, June 18, 2002 2:17 AM To: Jim Luther; w3c-dist-auth@w3c.org Subject: RE: Collections and Request-URIs > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Luther > Sent: Tuesday, June 18, 2002 1:46 AM > To: w3c-dist-auth@w3c.org > Subject: Collections and Request-URIs > > > > RFC 2518, section 5.2 says: > > "There is a standing convention that when a collection is referred to by > its name without a trailing slash, the trailing slash is automatically > appended. Due to this, a resource may accept a URI without a > trailing "/" to point to a collection. In this case it SHOULD return a > content-location header in the response pointing to the URI ending with > the "/". For example, if a client invokes a method on > http://foo.bar/blah (no trailing slash), the resource > http://foo.bar/blah/ (trailing slash) may respond as if the operation > were invoked on it, and should return a content-location header with > http://foo.bar/blah/ in it. In general clients SHOULD use the "/" form > of collection names." > > It looks to me like the "standing convention" doesn't match the BNF. RFC > 2616, section 5.1.2 gives this rule for the Request-URI in the > Request-Line: > > Request-URI = "*" | absoluteURI | abs_path | authority > > and RFC 2396, section 3 gives these rules for abs_path and path_segments: > > abs_path = "/" path_segments > path_segments = segment *( "/" segment ) > > So by my reading, abs_path should not have a trailing slash. Did I miss > something? If not, I think the WebDAV spec should say that servers MUST > handle Request-URIs to collections without the trail slash. However: segment = *pchar *( ";" param ) param = *pchar pchar = unreserved | escaped | ":" | "@" | "&" | "=" | "+" | "$" | "," ([1]) and "The second convention is a BNF-like grammar, used to define the formal URI syntax. The grammar is that of [RFC822], except that "|" is used to designate alternatives. Briefly, rules are separated from definitions by an equal "=", indentation is used to continue a rule definition over more than one line, literals are quoted with "", parentheses "(" and ")" are used to group elements, optional elements are enclosed in "[" and "]" brackets, and elements may be preceded with * to designate n or more repetitions of the following element; n defaults to 0." ([2]). So it seems that "segment" may be empty. Julian [1] [2] From w3c-dist-auth-request@w3.org Tue Jun 18 10:48:03 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 KAA20290 for ; Tue, 18 Jun 2002 10:48:03 -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 KAA12657; Tue, 18 Jun 2002 10:46:57 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5IEjqw03988; Tue, 18 Jun 2002 10:45:52 -0400 (EDT) Resent-Date: Tue, 18 Jun 2002 10:45:52 -0400 (EDT) Resent-Message-Id: <200206181445.g5IEjqw03988@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 g5IEjo203968 for ; Tue, 18 Jun 2002 10:45:50 -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 KAA11354 for ; Tue, 18 Jun 2002 10:45:48 -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 g5IEjlA00834 for ; Tue, 18 Jun 2002 07:45:47 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 18 Jun 2002 07:45:11 -0700 Received: from luthji (luthji.apple.com [17.202.43.76]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id g5IEjlD10579 for ; Tue, 18 Jun 2002 07:45:47 -0700 (PDT) Date: Tue, 18 Jun 2002 07:45:47 -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@w3c.org Content-Transfer-Encoding: 7bit In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10731939A@SUS-MA1IT01> Message-Id: <133339C7-82CA-11D6-82D1-0003934B6A22@apple.com> X-Mailer: Apple Mail (2.482) Subject: Re: Collections and Request-URIs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6301 X-Loop: 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 Thanks for the clarification, Julian. On Tuesday, June 18, 2002, at 04:49 AM, Clemm, Geoff wrote: > I agree with Julian (i.e. that trailing slashes are allowed by > the syntax), but I also have argued vigorously that the RFC-2518 > "guidance" is incorrect, and the next revision of RFC-2518 should > simply state "a URI with a trailing slash SHOULD identify the > same resource as the URI with the trailing slash removed". > > Cheers, > Geoff I'd argue that it must state "a URI with a trailing slash MUST identify the same resource as the URI with the trailing slash removed". Using SHOULD would leave it up to the server to do whatever, and would make the rules for a PROFIND Request-Line different than the rules in RFC 2616 for Request-Line. (In general, I dislike seeing SHOULD and MAY in specifications when the subject of particular rule isn't optional.) - Jim From w3c-dist-auth-request@w3.org Tue Jun 18 12:07: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 MAA24569 for ; Tue, 18 Jun 2002 12:07: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 MAA15481; Tue, 18 Jun 2002 12:06:48 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5IG6lp11242; Tue, 18 Jun 2002 12:06:47 -0400 (EDT) Resent-Date: Tue, 18 Jun 2002 12:06:47 -0400 (EDT) Resent-Message-Id: <200206181606.g5IG6lp11242@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 g5IG6k211218 for ; Tue, 18 Jun 2002 12:06:46 -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 MAA15475 for ; Tue, 18 Jun 2002 12:06:45 -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 g5IG5NfW001980 for ; Tue, 18 Jun 2002 09:05:24 -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 g5IG3GQG029652 for ; Tue, 18 Jun 2002 09:03:16 -0700 (PDT) Received: from dan.local.brotsky.com ([130.248.184.150]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GXWSQC00.2WA; Tue, 18 Jun 2002 09:06:12 -0700 Date: Tue, 18 Jun 2002 09:06:08 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: w3c-dist-auth@w3c.org To: "Clemm, Geoff" From: Dan Brotsky In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10731939A@SUS-MA1IT01> Message-Id: <4D25A832-82D5-11D6-8260-0003931036B4@adobe.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Subject: Re: Collections and Request-URIs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6302 X-Loop: 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 Tuesday, June 18, 2002, at 04:49 AM, Clemm, Geoff wrote: > I agree with Julian (i.e. that trailing slashes are allowed by > the syntax), but I also have argued vigorously that the RFC-2518 > "guidance" is incorrect, and the next revision of RFC-2518 should > simply state "a URI with a trailing slash SHOULD identify the > same resource as the URI with the trailing slash removed". But do you also want this to be the case for non-collection resources? Perhaps you mean "if a URI that ends in a trailing slash identifies a DAV-compliant collection resource, then the same URI with the trailing slash removed SHOULD identify the same resource." I would actually go for MUST in that case, although such a change would break some existing servers. dan From w3c-dist-auth-request@w3.org Tue Jun 18 12:43: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 MAA26096 for ; Tue, 18 Jun 2002 12:43: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 MAA23527; Tue, 18 Jun 2002 12:42:53 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5IGgrn13760; Tue, 18 Jun 2002 12:42:53 -0400 (EDT) Resent-Date: Tue, 18 Jun 2002 12:42:53 -0400 (EDT) Resent-Message-Id: <200206181642.g5IGgrn13760@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 g5IGgq213737 for ; Tue, 18 Jun 2002 12:42:52 -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 MAA23505 for ; Tue, 18 Jun 2002 12:42:52 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Tue, 18 Jun 2002 12:36:19 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Jun 2002 12:42:20 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B2B5@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Tue, 18 Jun 2002 12:42:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Collections and Request-URIs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6303 X-Loop: 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, I would want the statement to hold, independent of what kind of resource (if any) is currently identified by that URI. I also would prefer a MUST over a SHOULD. Cheers, Geoff -----Original Message----- From: Dan Brotsky [mailto:dbrotsky@adobe.com] Sent: Tuesday, June 18, 2002 12:06 PM To: Clemm, Geoff Cc: w3c-dist-auth@w3c.org Subject: Re: Collections and Request-URIs On Tuesday, June 18, 2002, at 04:49 AM, Clemm, Geoff wrote: > I agree with Julian (i.e. that trailing slashes are allowed by > the syntax), but I also have argued vigorously that the RFC-2518 > "guidance" is incorrect, and the next revision of RFC-2518 should > simply state "a URI with a trailing slash SHOULD identify the > same resource as the URI with the trailing slash removed". But do you also want this to be the case for non-collection resources? Perhaps you mean "if a URI that ends in a trailing slash identifies a DAV-compliant collection resource, then the same URI with the trailing slash removed SHOULD identify the same resource." I would actually go for MUST in that case, although such a change would break some existing servers. dan From w3c-dist-auth-request@w3.org Tue Jun 18 12:54: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 MAA26453 for ; Tue, 18 Jun 2002 12: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 MAA26103; Tue, 18 Jun 2002 12:53:40 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5IGrTq15112; Tue, 18 Jun 2002 12:53:29 -0400 (EDT) Resent-Date: Tue, 18 Jun 2002 12:53:29 -0400 (EDT) Resent-Message-Id: <200206181653.g5IGrTq15112@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 g5IGrR215088 for ; Tue, 18 Jun 2002 12:53:28 -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 MAA25985 for ; Tue, 18 Jun 2002 12:53:27 -0400 Received: (qmail 25583 invoked by uid 0); 18 Jun 2002 16:52:56 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp009-rz3) with SMTP; 18 Jun 2002 16:52:56 -0000 From: "Julian Reschke" To: "Jim Luther" , Date: Tue, 18 Jun 2002 18:52:55 +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: <574F11EC-824C-11D6-9679-0003934B6A22@apple.com> Importance: Normal Subject: RE: Collections and Request-URIs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6304 X-Loop: 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, just did a few tests: - Adobe Golive follows the 301 redirect without asking the user - XML Spy always submits the folder URL without trailing / (no matter what you enter), and reports the 301 as error Also interesting: - the default config for Apache 2.0.36 disables this behaviour for both the Microsoft webfolder client and the WebDrive client: # The following directive disables redirects on non-GET requests for # a directory that does not include the trailing slash. This fixes a # problem with Microsoft WebFolders which does not appropriately handle # redirects for folders with DAV methods. # BrowserMatch "Microsoft Data Access Internet Publishing Provider" redirect-carefully BrowserMatch "^WebDrive" redirect-carefully > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Luther > Sent: Tuesday, June 18, 2002 1:46 AM > To: w3c-dist-auth@w3c.org > Subject: Collections and Request-URIs > > > > RFC 2518, section 5.2 says: > > "There is a standing convention that when a collection is referred to by > its name without a trailing slash, the trailing slash is automatically > appended. Due to this, a resource may accept a URI without a > trailing "/" to point to a collection. In this case it SHOULD return a > content-location header in the response pointing to the URI ending with > the "/". For example, if a client invokes a method on > http://foo.bar/blah (no trailing slash), the resource > http://foo.bar/blah/ (trailing slash) may respond as if the operation > were invoked on it, and should return a content-location header with > http://foo.bar/blah/ in it. In general clients SHOULD use the "/" form > of collection names." > > It looks to me like the "standing convention" doesn't match the BNF. RFC > 2616, section 5.1.2 gives this rule for the Request-URI in the > Request-Line: > > Request-URI = "*" | absoluteURI | abs_path | authority > > and RFC 2396, section 3 gives these rules for abs_path and path_segments: > > abs_path = "/" path_segments > path_segments = segment *( "/" segment ) > > So by my reading, abs_path should not have a trailing slash. Did I miss > something? If not, I think the WebDAV spec should say that servers MUST > handle Request-URIs to collections without the trail slash. > > > Anyway, trailing slashes issue causes an interoperability problem for > our WebDAV file system and Apache 2.0 servers. Since Mac OS X's WebDAV > file system doesn't know if the end path component passed to it is a > collection or non-collection resource, it doesn't put a trailing slash > on the Request-URI. This works on all servers except for Apache 2 which > sends us a "301 Moved Permanently" response. We don't redirect because > the HTTP spec (RFC 2616, section 10.3.2) says: > > "If the 301 status code is received in response to a request other than > GET or HEAD, the user agent MUST NOT automatically redirect the request > unless it can be confirmed by the user, since this might change the > conditions under which the request was issued." > > Hmmm... WebDAV file system can't confirm it with the user because it's a > file system which doesn't do user interaction. I guess that I could > compare the URI in the 301 response to see if it's the same as what I > sent except for the trailing slash and retry the request. However, that > would double the number of PROPFIND for collection transactions we send > to Apache 2 servers and I'm trying to cut the number of transactions > >from our client, not increase them. > > Apparently, Microsoft WebFolders had the same problem with Apache 2. > Here's what we found in httpd.conf: > > # > # The following directive disables redirects on non-GET requests for > # a directory that does not include the trailing slash. > This fixes a > # problem with Microsoft WebFolders which does not > appropriately handle > # redirects for folders with DAV methods. > # > BrowserMatch "Microsoft Data Access Internet Publishing Provider" > redirect-carefully > BrowserMatch "^WebDrive" redirect-carefully > > So if we add a similar line: > > BrowserMatch "^WebDAVFS" redirect-carefully > > to Apache's httpd.conf file to do a redirect-carefully for our > User-Agent, our client works great with Apache 2 DAV servers. > > - Jim Luther > From w3c-dist-auth-request@w3.org Tue Jun 18 13:04: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 NAA26708 for ; Tue, 18 Jun 2002 13:04: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 NAA29106; Tue, 18 Jun 2002 13:04:08 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5IH47q16910; Tue, 18 Jun 2002 13:04:08 -0400 (EDT) Resent-Date: Tue, 18 Jun 2002 13:04:08 -0400 (EDT) Resent-Message-Id: <200206181704.g5IH47q16910@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 g5IH47216890 for ; Tue, 18 Jun 2002 13:04:07 -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 NAA29088 for ; Tue, 18 Jun 2002 13:04:06 -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 ; Tue, 18 Jun 2002 19:04:03 +0200 Date: Tue, 18 Jun 2002 19:04:02 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: w3c-dist-auth@w3c.org To: Dan Brotsky From: Stefan Eissing In-Reply-To: <4D25A832-82D5-11D6-8260-0003931036B4@adobe.com> Message-Id: <63EFA314-82DD-11D6-82E7-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: Collections and Request-URIs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6305 X-Loop: 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 Am Dienstag den, 18. Juni 2002, um 18:06, schrieb Dan Brotsky: > > On Tuesday, June 18, 2002, at 04:49 AM, Clemm, Geoff wrote: >> I agree with Julian (i.e. that trailing slashes are allowed by >> the syntax), but I also have argued vigorously that the RFC-2518 >> "guidance" is incorrect, and the next revision of RFC-2518 should >> simply state "a URI with a trailing slash SHOULD identify the >> same resource as the URI with the trailing slash removed". > > But do you also want this to be the case for non-collection > resources? Perhaps you mean "if a URI that ends in a trailing > slash identifies a DAV-compliant collection resource, then the > same URI with the trailing slash removed SHOULD identify the same > resource." I would actually go for MUST in that case, although > such a change would break some existing servers. > > dan I think the current approach in RFC 2518 works just fine, e.g. to indicate in the Content-Location that this entity is really located somewhere else. It worked until Apache 2.0 and I do not see any benefit in the new 301 for PROPFIND behaviour. Lack of deep insight on my part most likely. But even if /a and /a/ is the same from WebDAV point of view, there are a lot of common use cases where GET on /a/b will return 301/302 to /a/b/ no matter what WebDAV has to say about it. The good old index.html trick... //Stefan From w3c-dist-auth-request@w3.org Tue Jun 18 18:35:49 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 SAA07109 for ; Tue, 18 Jun 2002 18:35:49 -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 SAA06066; Tue, 18 Jun 2002 18:35:10 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5IMZ8816701; Tue, 18 Jun 2002 18:35:08 -0400 (EDT) Resent-Date: Tue, 18 Jun 2002 18:35:08 -0400 (EDT) Resent-Message-Id: <200206182235.g5IMZ8816701@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 g5IMZ3216570 for ; Tue, 18 Jun 2002 18:35:03 -0400 (EDT) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA05969 for ; Tue, 18 Jun 2002 18:35:02 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id PAA03477; Tue, 18 Jun 2002 15:37:04 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Tue, 18 Jun 2002 15:37:04 -0700 From: Greg Stein To: Jim Luther Cc: w3c-dist-auth@w3c.org, fielding@apache.org Message-ID: <20020618153704.F1848@lyra.org> Mail-Followup-To: Jim Luther , w3c-dist-auth@w3c.org, fielding@apache.org References: <574F11EC-824C-11D6-9679-0003934B6A22@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <574F11EC-824C-11D6-9679-0003934B6A22@apple.com>; from luther.j@apple.com on Mon, Jun 17, 2002 at 04:45:44PM -0700 X-URL: http://www.lyra.org/greg/ Subject: Re: Collections and Request-URIs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6306 X-Loop: 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 Mon, Jun 17, 2002 at 04:45:44PM -0700, Jim Luther wrote: >... > So by my reading, abs_path should not have a trailing slash. Did I miss > something? If not, I think the WebDAV spec should say that servers MUST > handle Request-URIs to collections without the trail slash. As mentioned previously, the trailing-slash form matches the BNF. > Anyway, trailing slashes issue causes an interoperability problem for > our WebDAV file system and Apache 2.0 servers. Since Mac OS X's WebDAV > file system doesn't know if the end path component passed to it is a > collection or non-collection resource, it doesn't put a trailing slash > on the Request-URI. This works on all servers except for Apache 2 which > sends us a "301 Moved Permanently" response. We don't redirect because > the HTTP spec (RFC 2616, section 10.3.2) says: > > "If the 301 status code is received in response to a request other than > GET or HEAD, the user agent MUST NOT automatically redirect the request > unless it can be confirmed by the user, since this might change the > conditions under which the request was issued." Roy Fielding has previous stated that RFC 2616's language is incorrect. The spec is supposed to allow things like PROPFIND. I forget the exact terminology that Roy used (i.e. was it "*all* idempotent methods"? or something else), but PROPFIND was among them. This topic was extensively discussed on the Apache development list when we added that redirection code (actually, we fixed a bug that prevented the "proper" behavior of redirecting for all methods). That was when Roy chimed in about RFC 2616 being slightly incorrect, that a redirection is legal, that Apache 2.0 "should" go ahead and redirect, and that the clients who are *not* following the redirect are simply broken. And given that the non-following clients are "broken", we went ahead and made the default behavior to do the redirection, and called out the broken clients in the standard distribution of httpd.conf. >... > # > # The following directive disables redirects on non-GET requests for > # a directory that does not include the trailing slash. This fixes a > # problem with Microsoft WebFolders which does not appropriately handle > # redirects for folders with DAV methods. > # > BrowserMatch "Microsoft Data Access Internet Publishing Provider" > redirect-carefully > BrowserMatch "^WebDrive" redirect-carefully > > So if we add a similar line: > > BrowserMatch "^WebDAVFS" redirect-carefully > > to Apache's httpd.conf file to do a redirect-carefully for our > User-Agent, our client works great with Apache 2 DAV servers. My response would be "fix your client. do the redirect." :-) If that is going to be impossible to do, then I can add that line to httpd.conf. But I'm reluctant to just start adding stuff. Your client really is "broken" (for some definition thereof :-) if it isn't following the 301. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Jun 18 18:51: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 SAA07518 for ; Tue, 18 Jun 2002 18:51: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 SAA10663; Tue, 18 Jun 2002 18:51:15 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5IMpFE17856; Tue, 18 Jun 2002 18:51:15 -0400 (EDT) Resent-Date: Tue, 18 Jun 2002 18:51:15 -0400 (EDT) Resent-Message-Id: <200206182251.g5IMpFE17856@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 g5IMpE217836 for ; Tue, 18 Jun 2002 18:51:14 -0400 (EDT) Received: from cs.utep.edu (mail.cs.utep.edu [129.108.5.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA10635 for ; Tue, 18 Jun 2002 18:51:14 -0400 From: lakshmi@cs.utep.edu Received: from chameleon (chameleon [129.108.5.52]) by cs.utep.edu (8.11.3/8.11.3) with ESMTP id g5IMp9m27498 for ; Tue, 18 Jun 2002 16:51:09 -0600 (MDT) Date: Tue, 18 Jun 2002 16:51:08 -0600 (MDT) X-Sender: To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: remote access of DOM data Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6307 X-Loop: 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: Hello: Can WEBDAV protocol be used to access a DOM data remotely thanks! Lakshmi From w3c-dist-auth-request@w3.org Tue Jun 18 19:22:44 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 TAA08279 for ; Tue, 18 Jun 2002 19:22: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 TAA18182; Tue, 18 Jun 2002 19:22:05 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5INM4v19586; Tue, 18 Jun 2002 19:22:04 -0400 (EDT) Resent-Date: Tue, 18 Jun 2002 19:22:04 -0400 (EDT) Resent-Message-Id: <200206182322.g5INM4v19586@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 g5INM3219562 for ; Tue, 18 Jun 2002 19:22:03 -0400 (EDT) Received: from mdea100.wakasoft.com (mdea100.eng.uci.edu [128.200.66.100]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA18164 for ; Tue, 18 Jun 2002 19:22:02 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.wakasoft.com (8.12.4/8.12.4) with ESMTP id g5INMTMe008865; Tue, 18 Jun 2002 16:22:29 -0700 (PDT) Date: Tue, 18 Jun 2002 16:22:29 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: Jim Luther , w3c-dist-auth@w3c.org To: Greg Stein From: "Roy T. Fielding" In-Reply-To: <20020618153704.F1848@lyra.org> Message-Id: <422455F1-8312-11D6-9ED7-000393753936@apache.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Subject: Re: Collections and Request-URIs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6308 X-Loop: 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 >> Anyway, trailing slashes issue causes an interoperability problem for >> our WebDAV file system and Apache 2.0 servers. Since Mac OS X's WebDAV >> file system doesn't know if the end path component passed to it is a >> collection or non-collection resource, it doesn't put a trailing slash >> on the Request-URI. This works on all servers except for Apache 2 which >> sends us a "301 Moved Permanently" response. We don't redirect because >> the HTTP spec (RFC 2616, section 10.3.2) says: >> >> "If the 301 status code is received in response to a request other than >> GET or HEAD, the user agent MUST NOT automatically redirect the request >> unless it can be confirmed by the user, since this might change the >> conditions under which the request was issued." > > Roy Fielding has previous stated that RFC 2616's language is incorrect. > The > spec is supposed to allow things like PROPFIND. I forget the exact > terminology that Roy used (i.e. was it "*all* idempotent methods"? or > something else), but PROPFIND was among them. Please see the official errata: http://world.std.com/~lawrence/http_errata.html#saferedirect > This topic was extensively discussed on the Apache development list when > we > added that redirection code (actually, we fixed a bug that prevented the > "proper" behavior of redirecting for all methods). That was when Roy > chimed > in about RFC 2616 being slightly incorrect, that a redirection is legal, > that Apache 2.0 "should" go ahead and redirect, and that the clients who > are > *not* following the redirect are simply broken. > > And given that the non-following clients are "broken", we went ahead and > made the default behavior to do the redirection, and called out the broken > clients in the standard distribution of httpd.conf. That is correct. And, BTW, RFC 2518 is in fact incorrect in the paragraph quoted, something which I stated numerous times when it was a draft. There are no known examples of HTTP servers for which the URI without a slash is the SAME RESOURCE as the URI with a slash. Automatically providing two different URI for the same resource, particularly when they cross hierarchical syntax, instantly doubles the application name space (bad for IR and QA) and creates holes in access control. That is why ALL general HTTP servers provide PERMANENT REDIRECTS from a WRONG URL to a better URL for the sake of stupid authors of broken references. They have never been the same resource on any server for which I have ever had readable code. It is completely idiotic for the protocol standard to state that a very expensive network round-trip correction needed because of indirect stupidity on the part of the server in providing the wrong URL to the client, or because clients have been encouraged to remove the trailing slash because some moron in UI thought it looked better without the slash, can be "worked around" by ignoring the difference between the two resources. Any WebDAV server that does not return a redirect in that situation is a bad HTTP server. A WebDAV client cannot assume anything about the nature of the URI, since there is absolutely no requirement in HTTP that two URI that differ only by the trailing slash are in fact the same resource. An HTTP server cannot ignore the difference because the content of a representation is interpreted in relation to the URI that was used to access that resource. Likewise, it often cannot ignore the difference because an HTTP server consists of many interoperating components that are configured according to the URI name space being accessed, not necessarily all within the same machine. Therefore, the ONLY interoperable behavior when faced with a slashless collection request is to perform an external redirect, even if that means existing WebDAV clients will puke and die. A WebDAV client must therefore handle the redirect. 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 Jun 19 01:20:35 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 BAA14982 for ; Wed, 19 Jun 2002 01:20:35 -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 BAA19591; Wed, 19 Jun 2002 01:19:38 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5J5Jan16807; Wed, 19 Jun 2002 01:19:36 -0400 (EDT) Resent-Date: Wed, 19 Jun 2002 01:19:36 -0400 (EDT) Resent-Message-Id: <200206190519.g5J5Jan16807@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 g5J5JY216787 for ; Wed, 19 Jun 2002 01: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 BAA19581 for ; Wed, 19 Jun 2002 01:19:34 -0400 Received: (qmail 10139 invoked by uid 0); 19 Jun 2002 05:19:03 -0000 Received: from pd950c249.dip.t-dialin.net (HELO lisa) (217.80.194.73) by mail.gmx.net (mp016-rz3) with SMTP; 19 Jun 2002 05:19:03 -0000 From: "Julian Reschke" To: Cc: "Jim Luther" , "Roy T. Fielding" , "Greg Stein" Date: Wed, 19 Jun 2002 07:19:04 +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: <422455F1-8312-11D6-9ED7-000393753936@apache.org> Subject: RE: Collections and Request-URIs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6309 X-Loop: 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, first of all I really have a problem with the language here. WebDAV clients that implement RFC2518 and RFC2616 (minus erratum published in March 2001) *to the letter* suddenly are called "broken". It's good that the erratum for RFC2616 allows clients to follow the redirect automatically. However, I think the following issues remain: 1) Roy says: > That is correct. And, BTW, RFC 2518 is in fact incorrect in the paragraph > quoted, something which I stated numerous times when it was a draft. > There are no known examples of HTTP servers for which the URI without a > slash is the SAME RESOURCE as the URI with a slash. Automatically > providing two different URI for the same resource, particularly when > they cross hierarchical syntax, instantly doubles the application > name space (bad for IR and QA) and creates holes in access control. > That is why ALL general HTTP servers provide PERMANENT REDIRECTS > >from a WRONG URL to a better URL for the sake of stupid authors of > broken references. They have never been the same resource on any > server for which I have ever had readable code. In this case this needs to be put on the RFC2518 issues list. 2) In the particular case of moddav2, we're stuck with a situation where an additional roundtrip is required to PROPFIND information about a resource (if it's not known in advance to be a collection). I'm still interested in an approch where the roundtip can be avoided. 3) WebDAV's namespace model is not completely compatible to HTTPs: every WebDAV compliant URL namespace conforms to RFC2616, but not the other way round. That's a fact the WebDAV WG has to deal with. In particular: Given a collection /a and HTTP resources "/a/b" and "/a/b/" (where "/a/b" and "/a/b/" are NOT the same resource) -- what should a PROPFIND on /a with depth 1 report? I can think of (a) it should fail (because "/a" isn't a WebDAV compliant collection), (b) it silently suppresses the response element for "/a/b" or (c) it reports both. Looking at RFC2518, section 5.2 [1], (c) seems to be possible but I'm sure that few WebDAV clients are prepared to handle this. Is anybody aware of a WebDAV server that *does* dinstinguish between "/a/b" and "/a/b/" and behaves as described in (c)? (Can I configure Apache2/moddav to handle this situation?). Feedback appreciated, Julian [1] From w3c-dist-auth-request@w3.org Wed Jun 19 03:33: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 DAA10010 for ; Wed, 19 Jun 2002 03:33: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 DAA08033; Wed, 19 Jun 2002 03:31:58 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5J7Vug25918; Wed, 19 Jun 2002 03:31:56 -0400 (EDT) Resent-Date: Wed, 19 Jun 2002 03:31:56 -0400 (EDT) Resent-Message-Id: <200206190731.g5J7Vug25918@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 g5J7Vs225898 for ; Wed, 19 Jun 2002 03:31: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 DAA08003 for ; Wed, 19 Jun 2002 03:31:54 -0400 Received: (qmail 16583 invoked by uid 0); 19 Jun 2002 07:31:22 -0000 Received: from pd950c249.dip.t-dialin.net (HELO lisa) (217.80.194.73) by mail.gmx.net (mp013-rz3) with SMTP; 19 Jun 2002 07:31:22 -0000 From: "Julian Reschke" To: Date: Wed, 19 Jun 2002 09:31:24 +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: WebDAV XML handling vs. external entities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6310 X-Loop: 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, there was recently an xml-dev thread about security problems allowing arbitrary XML in protocols (see for instance [1]). As WebDAV doesn't need resolution of external entities / DTD validation, I'd suggest to specfiy that servers and clients MUST NOT resolve external entities, that is, MUST reject any WebDAV protocol message that contains external entities. Feedback appreciated. [1] From w3c-dist-auth-request@w3.org Wed Jun 19 17:32: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 RAA04221 for ; Wed, 19 Jun 2002 17:32: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 RAA22651; Wed, 19 Jun 2002 17:32:08 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5JLVfs02059; Wed, 19 Jun 2002 17:31:41 -0400 (EDT) Resent-Date: Wed, 19 Jun 2002 17:31:41 -0400 (EDT) Resent-Message-Id: <200206192131.g5JLVfs02059@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 g5JLVdw02039 for ; Wed, 19 Jun 2002 17:31:39 -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 RAA22422 for ; Wed, 19 Jun 2002 17:31:39 -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 g5JLVVu28683; Wed, 19 Jun 2002 14:31:31 -0700 (PDT) From: "Jim Whitehead" To: "Julian Reschke" , Date: Wed, 19 Jun 2002 14:30:13 -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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: WebDAV XML handling vs. external entities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6311 X-Loop: 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 > there was recently an xml-dev thread about security problems allowing > arbitrary XML in protocols (see for instance [1]). This topic is also discussed in RFC 2518, in Section 17.7 (Implications of XML External Entities). > As WebDAV doesn't need resolution of external entities / DTD > validation, I'd suggest to specfiy that servers and clients MUST NOT > resolve external entities, that is, MUST reject any WebDAV protocol > message that contains external entities. In RFC 2518, we didn't go so far as to outlaw external entities, since (a) it didn't seem that likely they would ever get shipped across the wire, and (b) they might be useful for extensibility. But, after several years of implementation, I don't know of any uses of XML external entities, so I'd be fine with prohibiting them. - Jim From w3c-dist-auth-request@w3.org Wed Jun 19 17:44: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 RAA04437 for ; Wed, 19 Jun 2002 17:44: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 RAA25312; Wed, 19 Jun 2002 17:44:00 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5JLhxu03752; Wed, 19 Jun 2002 17:43:59 -0400 (EDT) Resent-Date: Wed, 19 Jun 2002 17:43:59 -0400 (EDT) Resent-Message-Id: <200206192143.g5JLhxu03752@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 g5JLhww03729 for ; Wed, 19 Jun 2002 17:43: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 RAA25303 for ; Wed, 19 Jun 2002 17:43:58 -0400 Received: (qmail 8963 invoked by uid 0); 19 Jun 2002 21:43:26 -0000 Received: from p3ee2470b.dip.t-dialin.net (HELO lisa) (62.226.71.11) by mail.gmx.net (mp007-rz3) with SMTP; 19 Jun 2002 21:43:26 -0000 From: "Julian Reschke" To: "Jim Whitehead" , "Julian Reschke" , Date: Wed, 19 Jun 2002 23:43:25 +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: WebDAV XML handling vs. external entities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6312 X-Loop: 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: Jim Whitehead [mailto:ejw@cse.ucsc.edu] > Sent: Wednesday, June 19, 2002 11:30 PM > To: Julian Reschke; w3c-dist-auth@w3c.org > Subject: RE: WebDAV XML handling vs. external entities > > > > there was recently an xml-dev thread about security problems allowing > > arbitrary XML in protocols (see for instance [1]). > > This topic is also discussed in RFC 2518, in Section 17.7 (Implications of > XML External Entities). Indeed. Missed that part :-) > > As WebDAV doesn't need resolution of external entities / DTD > > validation, I'd suggest to specfiy that servers and clients MUST NOT > > resolve external entities, that is, MUST reject any WebDAV protocol > > message that contains external entities. > > In RFC 2518, we didn't go so far as to outlaw external entities, since (a) > it didn't seem that likely they would ever get shipped across the > wire, and > (b) they might be useful for extensibility. But, after several years of > implementation, I don't know of any uses of XML external > entities, so I'd be > fine with prohibiting them. It think we should clarify. Right now, existing servers seem to either ignore the external entitiy (mod_dav) or report an error (IIS). I think the former is wrong because it means that part of the request wasn't parsed, so the request shouldn't be executed. For the sake of clarity, I think it would be a good thing to recommend that servers should fail the request. Julian From w3c-dist-auth-request@w3.org Wed Jun 19 23:05: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 XAA09683 for ; Wed, 19 Jun 2002 23:05: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 XAA12771; Wed, 19 Jun 2002 23:04:52 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5K34om28398; Wed, 19 Jun 2002 23:04:50 -0400 (EDT) Resent-Date: Wed, 19 Jun 2002 23:04:50 -0400 (EDT) Resent-Message-Id: <200206200304.g5K34om28398@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 g5K34mw28378 for ; Wed, 19 Jun 2002 23:04:48 -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 XAA12764 for ; Wed, 19 Jun 2002 23:04:48 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Wed, 19 Jun 2002 22:58:13 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jun 2002 23:04:17 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B10731990F@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Wed, 19 Jun 2002 23:04:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Collections and Request-URIs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6313 X-Loop: 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: Roy T. Fielding [mailto:fielding@apache.org] ... the ONLY interoperable behavior when faced with a slashless collection request is to perform an external redirect, even if that means existing WebDAV clients will puke and die. I would have thought that interoperability should take into account reality (:-). I can see why you wouldn't want the spec to require that a server treat identically URIs with and without a trailing slash, but I cannot see on what basis you would require a server to not make this equivalence. A client cannot count on them being different resources, since the mapping of URIs to resources is up to the server, but if a server decided to map trailing URIs with and without a trailing slash to the same resource, it should be free to do so. For that matter, if it wanted to map every URL in its URL space to the same resource, it should be free to do so (although it probably wouldn't be an especially popular web site unless that was a really interesting resource :-). Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Jun 20 16:31: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 QAA12055 for ; Thu, 20 Jun 2002 16:31: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 QAA18501; Thu, 20 Jun 2002 16:30:28 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5KKTcO24105; Thu, 20 Jun 2002 16:29:38 -0400 (EDT) Resent-Date: Thu, 20 Jun 2002 16:29:38 -0400 (EDT) Resent-Message-Id: <200206202029.g5KKTcO24105@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 g5KKTaw24078 for ; Thu, 20 Jun 2002 16:29:36 -0400 (EDT) Received: from sna-036.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 QAA18132 for ; Thu, 20 Jun 2002 16:29:35 -0400 Received: from sna-036 (localhost [127.0.0.1]) by localhost.wakasoft.com (8.12.4/8.12.4) with ESMTP id g5KKDq3X001426; Thu, 20 Jun 2002 13:13:52 -0700 (PDT) Date: Thu, 20 Jun 2002 13:13:48 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: w3c-dist-auth@w3c.org To: "Clemm, Geoff" From: "Roy T. Fielding" In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10731990F@SUS-MA1IT01> Message-Id: <3AE2EE84-848A-11D6-A7CE-000393753936@apache.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Subject: Re: Collections and Request-URIs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6314 X-Loop: 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, June 19, 2002, at 08:04 PM, Clemm, Geoff wrote: > From: Roy T. Fielding [mailto:fielding@apache.org] > > ... the ONLY interoperable behavior when faced with a slashless > collection request is to perform an external redirect, even if that > means existing WebDAV clients will puke and die. > > I would have thought that interoperability should take into account > reality (:-). Operations must fail safe rather than operating unsafe. I should have forced the client to puke and die -- it would have been fixed faster. > I can see why you wouldn't want the spec to require that a server > treat identically URIs with and without a trailing slash, but I cannot > see on what basis you would require a server to not make this > equivalence. A client cannot count on them being different > resources, since the mapping of URIs to resources is up to the > server, but if a server decided to map trailing URIs with and without > a trailing slash to the same resource, it should be free to do so. For > that matter, if it wanted to map every URL in its URL space to the > same resource, it should be free to do so (although it probably > wouldn't be an especially popular web site unless that was a really > interesting resource :-). You aren't thinking at the right scale. An "origin server" is a role played in the communication between client and server over HTTP. The trivial case is that there is one server and one client, each residing within one process and fully aware of the entire request-handling process. The most common case is a general HTTP server consisting of an array of resource handlers that are invoked according to a configurable set of conditions based on elements of the request. In the complex case, an origin server consists of a hierarchy of HTTP servers that are selected based on elements of the request, each of which in turn is made up of configurable modules ... The point being that, if the request URI needs to change in order to handle the request correctly (meaning with the correct server selection, module selection, and access control checks), a redirect to the correct URI is necessary because the general-purpose HTTP server cannot know whether it is the entire origin server or just one cog within a complex assortment of HTTP servers. Furthermore, because the hierarchy change to the URI will change the interpretation of relative URI, none of the intermediary servers can step in the way of the external redirect before it gets to the client. Yes, it is certainly possible for an HTTP server to treat both as the same resource and not perform a redirect. However, such software is a bad HTTP server because it is trading-off a temporary inconvenience for a potential security hole and a source of broken links. None of this is an issue for WebDAV if collections are presented to the client with the correct URL, ending with a slash. The only time this does not occur on a regular basis is when the representation of a collection fails to use the correct URL in its own references. Under normal circumstances, the only time that a WebDAV client will need to request the wrong URL is when it is typed into the client by hand on the very first entry of a Save As dialog. I don't give a rat's ass if that one case results in a redirect, and neither does the user. ....Roy From w3c-dist-auth-request@w3.org Thu Jun 20 23:30: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 XAA20550 for ; Thu, 20 Jun 2002 23:30: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 XAA02924; Thu, 20 Jun 2002 23:30:11 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5L3U6x18738; Thu, 20 Jun 2002 23:30:06 -0400 (EDT) Resent-Date: Thu, 20 Jun 2002 23:30:06 -0400 (EDT) Resent-Message-Id: <200206210330.g5L3U6x18738@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 g5L3U4w18699 for ; Thu, 20 Jun 2002 23:30:04 -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 XAA02880 for ; Thu, 20 Jun 2002 23:30:04 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Thu, 20 Jun 2002 23:23:26 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Jun 2002 23:29:33 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1074A5050@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Thu, 20 Jun 2002 23:29:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Collections and Request-URIs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6315 X-Loop: 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 think anybody was proposing that an intermediary server that is just forwarding the request along would make the decision about whether trailing slashes are semantically meaningful. It would just forward the URL along to the server that is actually going to perform the requested method. But the server that is actually performing the requested method should feel free to ignore trailing slashes, if that is the semantics that it wants to provide. Cheers, Geoff -----Original Message----- From: Roy T. Fielding [mailto:fielding@apache.org] Sent: Thursday, June 20, 2002 4:14 PM To: Clemm, Geoff Cc: w3c-dist-auth@w3c.org Subject: Re: Collections and Request-URIs On Wednesday, June 19, 2002, at 08:04 PM, Clemm, Geoff wrote: > From: Roy T. Fielding [mailto:fielding@apache.org] > > ... the ONLY interoperable behavior when faced with a slashless > collection request is to perform an external redirect, even if that > means existing WebDAV clients will puke and die. > > I would have thought that interoperability should take into account > reality (:-). Operations must fail safe rather than operating unsafe. I should have forced the client to puke and die -- it would have been fixed faster. > I can see why you wouldn't want the spec to require that a server > treat identically URIs with and without a trailing slash, but I cannot > see on what basis you would require a server to not make this > equivalence. A client cannot count on them being different > resources, since the mapping of URIs to resources is up to the > server, but if a server decided to map trailing URIs with and without > a trailing slash to the same resource, it should be free to do so. For > that matter, if it wanted to map every URL in its URL space to the > same resource, it should be free to do so (although it probably > wouldn't be an especially popular web site unless that was a really > interesting resource :-). You aren't thinking at the right scale. An "origin server" is a role played in the communication between client and server over HTTP. The trivial case is that there is one server and one client, each residing within one process and fully aware of the entire request-handling process. The most common case is a general HTTP server consisting of an array of resource handlers that are invoked according to a configurable set of conditions based on elements of the request. In the complex case, an origin server consists of a hierarchy of HTTP servers that are selected based on elements of the request, each of which in turn is made up of configurable modules ... The point being that, if the request URI needs to change in order to handle the request correctly (meaning with the correct server selection, module selection, and access control checks), a redirect to the correct URI is necessary because the general-purpose HTTP server cannot know whether it is the entire origin server or just one cog within a complex assortment of HTTP servers. Furthermore, because the hierarchy change to the URI will change the interpretation of relative URI, none of the intermediary servers can step in the way of the external redirect before it gets to the client. Yes, it is certainly possible for an HTTP server to treat both as the same resource and not perform a redirect. However, such software is a bad HTTP server because it is trading-off a temporary inconvenience for a potential security hole and a source of broken links. None of this is an issue for WebDAV if collections are presented to the client with the correct URL, ending with a slash. The only time this does not occur on a regular basis is when the representation of a collection fails to use the correct URL in its own references. Under normal circumstances, the only time that a WebDAV client will need to request the wrong URL is when it is typed into the client by hand on the very first entry of a Save As dialog. I don't give a rat's ass if that one case results in a redirect, and neither does the user. ....Roy From w3c-dist-auth-request@w3.org Fri Jun 21 14:56: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 OAA27164 for ; Fri, 21 Jun 2002 14:56: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 OAA00391; Fri, 21 Jun 2002 14:55:39 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5LIt2q27015; Fri, 21 Jun 2002 14:55:02 -0400 (EDT) Resent-Date: Fri, 21 Jun 2002 14:55:02 -0400 (EDT) Resent-Message-Id: <200206211855.g5LIt2q27015@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 g5LIt1w26992 for ; Fri, 21 Jun 2002 14:55:01 -0400 (EDT) Received: from sna-036.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 OAA00315 for ; Fri, 21 Jun 2002 14:55:00 -0400 Received: from sna-036 (localhost [127.0.0.1]) by sna-036.wakasoft.com (8.12.4/8.12.4) with ESMTP id g5LIriNE000738; Fri, 21 Jun 2002 11:53:44 -0700 (PDT) Date: Fri, 21 Jun 2002 11:53:44 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: w3c-dist-auth@w3c.org To: "Clemm, Geoff" From: "Roy T. Fielding" In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1074A5050@SUS-MA1IT01> Message-Id: <35EDD9E0-8548-11D6-B3A8-000393753936@apache.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Subject: Re: Collections and Request-URIs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6316 X-Loop: 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 Thursday, June 20, 2002, at 08:29 PM, Clemm, Geoff wrote: > I don't think anybody was proposing that an intermediary server > that is just forwarding the request along would make the decision > about whether trailing slashes are semantically meaningful. > It would just forward the URL along to the server that is actually > going to perform the requested method. But the server that is > actually performing the requested method should feel free to ignore > trailing slashes, if that is the semantics that it wants to provide. It cannot do so because it doesn't know whether or not the other server is gating requests based on that difference. ....Roy From w3c-dist-auth-request@w3.org Mon Jun 24 14:00:35 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 OAA21276 for ; Mon, 24 Jun 2002 14:00:35 -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 NAA12301; Mon, 24 Jun 2002 13:59:26 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5OHwU407717; Mon, 24 Jun 2002 13:58:30 -0400 (EDT) Resent-Date: Mon, 24 Jun 2002 13:58:30 -0400 (EDT) Resent-Message-Id: <200206241758.g5OHwU407717@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 g5OHwRw07697 for ; Mon, 24 Jun 2002 13:58:27 -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 NAA12059 for ; Mon, 24 Jun 2002 13:58:26 -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 g5OHvae8026092; Mon, 24 Jun 2002 13:57:37 -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 g5OHvXE70670; Mon, 24 Jun 2002 13:57:33 -0400 To: "Clemm, Geoff" Cc: "'Webdav WG (E-mail)'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Mon, 24 Jun 2002 13:56:51 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_05312002 Pre-release 2|May 31, 2002) at 06/24/2002 13:57:32 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE171DFCB39258f9e8a93df938690918c0ABBE171DFCB3925" Content-Disposition: inline Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6317 X-Loop: 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__=0ABBE171DFCB39258f9e8a93df938690918c0ABBE171DFCB3925 Content-type: text/plain; charset=US-ASCII I've spent some time trying to list the questions brought up in this discussion and the answers offered. I can post that list later. In building the list I found Lisa's questions interesting. For the most part the questions in the first half of Lisa's note [1] seem to be answered, but Lisa's later questions about mapping did not seem to be. The mapping issues seem to be an important issue for the source property, and the answer can vary from server to server. Are answers also hinted that the client has to know how the server does mappings, as they do now, but if that is our answer, then I'm not sure why we are defining the DAV:source property. [1] http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0170.html Can everyone do a mental reset and review why we have a source property? I assume the following questions (and perhaps more) need to be answered (by the DAV:source property). I don't think it's acceptable to say that the answer varies and that the client just know the mapping function. I've explained why above. I think we need to perhaps admit that the answer will vary from server to server, but that some aspect of WebDAV (presumably the DAV:source property) tells the client how to get the job done. 1) An author wants to create a dynamic web page using an implementation he has. The URL where he wants the dynamic content served is currently unmapped. Where does he PUT the implementation to create the mapping? (I'm assuming an automatic mapping process.) 2) An author wants to browse the code he submitted as an implementation of a resource. At what URL does the author do the GET? (I think we answer this with DAV:source.) 3) A dynamic page is being served at a given URL. The author wants to update the implementation of that dynamic resource. Where does he PUT the updated implementation? (I think we've answered the basic form of this question via the dav:source propety. Questions like whether the update will be refelcted immediately can be answered later.) 4) An author wants to no longer serve dynamic content at a specific URL. What URL does the author DELETE? 5) Make sure the answers to the above question still work in concept for resources that would list multiple DAV:source resources. 6) Make sure the answers to the questions above don't cause problems for servers that require explicit client controlled mapping operations. I'm sure I've missed some other fundamental questions, but the 4+2 above seem like a good easy to understand start. I do think it's acceptable to say that DAV:source only solves 2 & 3 and we'll solve the other questions later. In doing so, in the spec we can clarify what DAV:source is NOT doing so that it doesn't get misused. We also should mentally envision how we'd solve the other problems to insure that what we are doing now will not prevent us from solving the remaining problems later. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com --0__=0ABBE171DFCB39258f9e8a93df938690918c0ABBE171DFCB3925 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I've spent some time trying to list the questions brought up in this discussion and the answers offered. I can post that list later.

In building the list I found Lisa's questions interesting. For the most part the questions in the first half of Lisa's note [1] seem to be answered, but Lisa's later questions about mapping did not seem to be. The mapping issues seem to be an important issue for the source property, and the answer can vary from server to server. Are answers also hinted that the client has to know how the server does mappings, as they do now, but if that is our answer, then I'm not sure why we are defining the DAV:source property.

[1] http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0170.html

Can everyone do a mental reset and review why we have a source property?

I assume the following questions (and perhaps more) need to be answered (by the DAV:source property). I don't think it's acceptable to say that the answer varies and that the client just know the mapping function. I've explained why above. I think we need to perhaps admit that the answer will vary from server to server, but that some aspect of WebDAV (presumably the DAV:source property) tells the client how to get the job done.

1) An author wants to create a dynamic web page using an implementation he has. The URL where he wants the dynamic content served is currently unmapped. Where does he PUT the implementation to create the mapping? (I'm assuming an automatic mapping process.)

2) An author wants to browse the code he submitted as an implementation of a resource. At what URL does the author do the GET? (I think we answer this with DAV:source.)

3) A dynamic page is being served at a given URL. The author wants to update the implementation of that dynamic resource. Where does he PUT the updated implementation? (I think we've answered the basic form of this question via the dav:source propety. Questions like whether the update will be refelcted immediately can be answered later.)

4) An author wants to no longer serve dynamic content at a specific URL. What URL does the author DELETE?

5) Make sure the answers to the above question still work in concept for resources that would list multiple DAV:source resources.

6) Make sure the answers to the questions above don't cause problems for servers that require explicit client controlled mapping operations.

I'm sure I've missed some other fundamental questions, but the 4+2 above seem like a good easy to understand start.

I do think it's acceptable to say that DAV:source only solves 2 & 3 and we'll solve the other questions later. In doing so, in the spec we can clarify what DAV:source is NOT doing so that it doesn't get misused. We also should mentally envision how we'd solve the other problems to insure that what we are doing now will not prevent us from solving the remaining problems later.

J.

------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com
--0__=0ABBE171DFCB39258f9e8a93df938690918c0ABBE171DFCB3925-- From w3c-dist-auth-request@w3.org Mon Jun 24 18:20: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 SAA04974 for ; Mon, 24 Jun 2002 18:20: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 SAA03689; Mon, 24 Jun 2002 18:20:22 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5OMKGM01584; Mon, 24 Jun 2002 18:20:16 -0400 (EDT) Resent-Date: Mon, 24 Jun 2002 18:20:16 -0400 (EDT) Resent-Message-Id: <200206242220.g5OMKGM01584@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 g5OMKFw01560 for ; Mon, 24 Jun 2002 18:20:15 -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 SAA03666 for ; Mon, 24 Jun 2002 18:20:15 -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 g5OMJUg5101402; Mon, 24 Jun 2002 18:19: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 g5OMJRE43282; Mon, 24 Jun 2002 18:19:27 -0400 To: "Julian Reschke" Cc: "Jim Whitehead" , w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Mon, 24 Jun 2002 18:09:29 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_05312002 Pre-release 2|May 31, 2002) at 06/24/2002 18:19:27 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE171DFEA25E38f9e8a93df938690918c0ABBE171DFEA25E3" Content-Disposition: inline Subject: RE: WebDAV XML handling vs. external entities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6318 X-Loop: 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__=0ABBE171DFEA25E38f9e8a93df938690918c0ABBE171DFEA25E3 Content-type: text/plain; charset=US-ASCII << It think we should clarify. Right now, existing servers seem to either ignore the external entitiy (mod_dav) or report an error (IIS). I think the former is wrong because it means that part of the request wasn't parsed, so the request shouldn't be executed. For the sake of clarity, I think it would be a good thing to recommend that servers should fail the request. >> Opinions? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com --0__=0ABBE171DFEA25E38f9e8a93df938690918c0ABBE171DFEA25E3 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

<<
It think we should clarify. Right now, existing servers seem to either
ignore the external entitiy (mod_dav) or report an error (IIS). I think the
former is wrong because it means that part of the request wasn't parsed, so
the request shouldn't be executed. For the sake of clarity, I think it would
be a good thing to recommend that servers should fail the request.
>>

Opinions?


------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com
--0__=0ABBE171DFEA25E38f9e8a93df938690918c0ABBE171DFEA25E3-- From w3c-dist-auth-request@w3.org Mon Jun 24 22:52: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 WAA11397 for ; Mon, 24 Jun 2002 22:52: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 WAA18027; Mon, 24 Jun 2002 22:51:38 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5P2pOU18560; Mon, 24 Jun 2002 22:51:24 -0400 (EDT) Resent-Date: Mon, 24 Jun 2002 22:51:24 -0400 (EDT) Resent-Message-Id: <200206250251.g5P2pOU18560@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 g5P2pMw18540 for ; Mon, 24 Jun 2002 22:51:22 -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 WAA17936 for ; Mon, 24 Jun 2002 22:51:22 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Mon, 24 Jun 2002 22:44:34 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jun 2002 22:50:51 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1074A56AA@SUS-MA1IT01> From: "Clemm, Geoff" To: "'Webdav WG (E-mail)'" Date: Mon, 24 Jun 2002 22:50:50 -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/6319 X-Loop: 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 2 and 3 are sufficiently important use cases to support the DAV:source protocol element. I think one can make a reasonable case that 4 is also handled by DAV:source (i.e. it is a reasonable extension of 3). Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Monday, June 24, 2002 1:57 PM To: Clemm, Geoff Cc: 'Webdav WG (E-mail)' Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED I've spent some time trying to list the questions brought up in this discussion and the answers offered. I can post that list later. In building the list I found Lisa's questions interesting. For the most part the questions in the first half of Lisa's note [1] seem to be answered, but Lisa's later questions about mapping did not seem to be. The mapping issues seem to be an important issue for the source property, and the answer can vary from server to server. Are answers also hinted that the client has to know how the server does mappings, as they do now, but if that is our answer, then I'm not sure why we are defining the DAV:source property. [1] http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0170.html Can everyone do a mental reset and review why we have a source property? I assume the following questions (and perhaps more) need to be answered (by the DAV:source property). I don't think it's acceptable to say that the answer varies and that the client just know the mapping function. I've explained why above. I think we need to perhaps admit that the answer will vary from server to server, but that some aspect of WebDAV (presumably the DAV:source property) tells the client how to get the job done. 1) An author wants to create a dynamic web page using an implementation he has. The URL where he wants the dynamic content served is currently unmapped. Where does he PUT the implementation to create the mapping? (I'm assuming an automatic mapping process.) 2) An author wants to browse the code he submitted as an implementation of a resource. At what URL does the author do the GET? (I think we answer this with DAV:source.) 3) A dynamic page is being served at a given URL. The author wants to update the implementation of that dynamic resource. Where does he PUT the updated implementation? (I think we've answered the basic form of this question via the dav:source propety. Questions like whether the update will be refelcted immediately can be answered later.) 4) An author wants to no longer serve dynamic content at a specific URL. What URL does the author DELETE? 5) Make sure the answers to the above question still work in concept for resources that would list multiple DAV:source resources. 6) Make sure the answers to the questions above don't cause problems for servers that require explicit client controlled mapping operations. I'm sure I've missed some other fundamental questions, but the 4+2 above seem like a good easy to understand start. I do think it's acceptable to say that DAV:source only solves 2 & 3 and we'll solve the other questions later. In doing so, in the spec we can clarify what DAV:source is NOT doing so that it doesn't get misused. We also should mentally envision how we'd solve the other problems to insure that what we are doing now will not prevent us from solving the remaining problems later. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Tue Jun 25 08:30: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 IAA02609 for ; Tue, 25 Jun 2002 08:30: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 IAA28431; Tue, 25 Jun 2002 08:29:32 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5PCTPf29393; Tue, 25 Jun 2002 08:29:25 -0400 (EDT) Resent-Date: Tue, 25 Jun 2002 08:29:25 -0400 (EDT) Resent-Message-Id: <200206251229.g5PCTPf29393@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 g5PCTMw29373 for ; Tue, 25 Jun 2002 08:29:22 -0400 (EDT) Received: from kurgan.lyra.org (kurgan.lyra.org [198.144.203.198]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA28409 for ; Tue, 25 Jun 2002 08:29:21 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id FAA18999 for w3c-dist-auth@w3.org; Tue, 25 Jun 2002 05:32:07 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Tue, 25 Jun 2002 05:32:07 -0700 From: Greg Stein To: w3c-dist-auth@w3.org Message-ID: <20020625053207.C18589@lyra.org> Mail-Followup-To: w3c-dist-auth@w3.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i X-URL: http://www.lyra.org/greg/ Subject: fyi: webdav.org scheduled downtime Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6320 X-Loop: 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: The webdav.org hardware needs to be moved from its current location in San Francisco, down to San Jose (*). It will be offline starting around 8pm PDT (that is UTC -0700) on Tuesday, June 25, and should come back online about three hours later. If you have any questions or concerns, please feel free to send me an email. Cheers, -g (*) AboveNet is closing its colocation facility in San Fran, so the box is moving to the AboveNet facility in San Jose. They gave us very little notice... sigh. -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Jun 26 14:38:35 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 OAA04769 for ; Wed, 26 Jun 2002 14:38:35 -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 OAA12232; Wed, 26 Jun 2002 14:37:41 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5QIb1f03058; Wed, 26 Jun 2002 14:37:01 -0400 (EDT) Resent-Date: Wed, 26 Jun 2002 14:37:01 -0400 (EDT) Resent-Message-Id: <200206261837.g5QIb1f03058@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 g5QIb0w03038 for ; Wed, 26 Jun 2002 14:37:00 -0400 (EDT) Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA12033 for ; Wed, 26 Jun 2002 14:36:59 -0400 Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 26 Jun 2002 14:36:29 -0400 (Eastern Daylight Time) Received: from moose ([216.36.77.241]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 26 Jun 2002 14:36:28 -0400 From: "Lisa Dusseault" To: "Webdav WG \(E-mail\)" Date: Wed, 26 Jun 2002 11:37:48 -0700 Message-ID: <002401c21d40$935f1630$7801a8c0@moose> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 26 Jun 2002 18:36:28.0894 (UTC) FILETIME=[629687E0:01C21D40] Subject: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6321 X-Loop: 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 This issue is described in more detail in "http://www.webdav.org/wg/rfcdev/issues.htm". Basically, Larry Masinter suggested that the use of URI vs. URL is not ideal in RFC2518. If I understand the problem, it seems the term URL is used appropriately wherever it is used. However, the term URI is used too often, at times when the term URL would be more appropriate. Here is what I propose to do to fix that, on a case-by-case basis. The first two cases are the only changes, the rest are cases where I propose to continue the current usage. I wanted to list all the cases, both for changing and for continuing, so you can point out if I've missed any cases. - 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 . - 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. - Continue to define the element in section 12.3 as containing a URI, because to do otherwise would change the specificaiton, not clarify it. Likewise for , and elements. - Continue to define the property name as a URI in section 16. - Continue to use the term URI in IANA considerations, where the property name and lock token URIs are discussed. - 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. Lisa From w3c-dist-auth-request@w3.org Wed Jun 26 15:43: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 PAA07921 for ; Wed, 26 Jun 2002 15:43: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 PAA30036; Wed, 26 Jun 2002 15:42:57 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5QJguG07532; Wed, 26 Jun 2002 15:42:56 -0400 (EDT) Resent-Date: Wed, 26 Jun 2002 15:42:56 -0400 (EDT) Resent-Message-Id: <200206261942.g5QJguG07532@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 g5QJgsw07508 for ; Wed, 26 Jun 2002 15:42: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 PAA30025 for ; Wed, 26 Jun 2002 15:42:53 -0400 Received: (qmail 28271 invoked by uid 0); 26 Jun 2002 19:42:22 -0000 Received: from pd950c389.dip.t-dialin.net (HELO lisa) (217.80.195.137) by mail.gmx.net (mp001-rz3) with SMTP; 26 Jun 2002 19:42:22 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "Webdav WG \(E-mail\)" Date: Wed, 26 Jun 2002 21:42:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <002401c21d40$935f1630$7801a8c0@moose> Importance: Normal Subject: RE: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6322 X-Loop: 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 convinced that this change is important. A URL is a URI. We just need to be clear about when a URI actually happens to be a *WebDAV* URI. That being said: > - Continue to define the property name as a URI in section 16. That section needs to be fixed anyway -- property names do not have URLs or URIs. Period. This should be put onto the issues list (Jim?). > ... > > 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. There maybe a deadline for draft submissions before the IETF meeting, but does that mean that a new RFC2518bis draft needs to be submitted at all? I would have hoped that before a new draft is submitted, the issues *introduced* by the submission of the previous draft are actually resolved (or at least discussed). See and From w3c-dist-auth-request@w3.org Wed Jun 26 17:33: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 RAA11960 for ; Wed, 26 Jun 2002 17:33: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 RAA21605; Wed, 26 Jun 2002 17:33:11 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5QLXAV14917; Wed, 26 Jun 2002 17:33:10 -0400 (EDT) Resent-Date: Wed, 26 Jun 2002 17:33:10 -0400 (EDT) Resent-Message-Id: <200206262133.g5QLXAV14917@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 g5QLX9w14897 for ; Wed, 26 Jun 2002 17:33: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 RAA21595 for ; Wed, 26 Jun 2002 17:33:08 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Wed, 26 Jun 2002 17:26:15 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Jun 2002 17:32:37 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B2FA@SUS-MA1IT01> From: "Clemm, Geoff" To: "Webdav WG (E-mail)" Date: Wed, 26 Jun 2002 17:32:36 -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/6323 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I support the "upgrade" from "URI" to "URL", whenever we can do so. A URL is a URI, but a URI is not always a URL, so saying that something is a URL has added meaning, and is worth saying whenever it is true and doesn't conflict with accepted usage. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Wednesday, June 26, 2002 3:42 PM To: Lisa Dusseault; Webdav WG (E-mail) Subject: RE: Issue: URI_URL, proposed changes I'm not convinced that this change is important. A URL is a URI. We just need to be clear about when a URI actually happens to be a *WebDAV* URI. That being said: > - Continue to define the property name as a URI in section 16. That section needs to be fixed anyway -- property names do not have URLs or URIs. Period. This should be put onto the issues list (Jim?). > ... > > 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. There maybe a deadline for draft submissions before the IETF meeting, but does that mean that a new RFC2518bis draft needs to be submitted at all? I would have hoped that before a new draft is submitted, the issues *introduced* by the submission of the previous draft are actually resolved (or at least discussed). See and From w3c-dist-auth-request@w3.org Wed Jun 26 18:44: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 SAA14250 for ; Wed, 26 Jun 2002 18:44: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 SAA03139; Wed, 26 Jun 2002 18:43:27 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5QMhQB19903; Wed, 26 Jun 2002 18:43:26 -0400 (EDT) Resent-Date: Wed, 26 Jun 2002 18:43:26 -0400 (EDT) Resent-Message-Id: <200206262243.g5QMhQB19903@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 g5QMhOw19879 for ; Wed, 26 Jun 2002 18:43:24 -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 SAA03129 for ; Wed, 26 Jun 2002 18:43:24 -0400 Received: (qmail 19239 invoked by uid 0); 26 Jun 2002 22:42:53 -0000 Received: from pd950c389.dip.t-dialin.net (HELO lisa) (217.80.195.137) by mail.gmx.net (mp011-rz3) with SMTP; 26 Jun 2002 22:42:53 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "Webdav WG \(E-mail\)" Date: Thu, 27 Jun 2002 00:42:53 +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 In-Reply-To: <002401c21d40$935f1630$7801a8c0@moose> Importance: Normal Subject: RE: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6324 X-Loop: 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 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 Jun 27 01:21: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 BAA23479 for ; Thu, 27 Jun 2002 01:21: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 BAA18608; Thu, 27 Jun 2002 01:20:50 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5R5KXC12136; Thu, 27 Jun 2002 01:20:33 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 01:20:33 -0400 (EDT) Resent-Message-Id: <200206270520.g5R5KXC12136@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 g5R5KWw12116 for ; Thu, 27 Jun 2002 01:20:32 -0400 (EDT) Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23]) by tux.w3.org (8.9.3/8.9.3) with SMTP id BAA18573 for ; Thu, 27 Jun 2002 01:20:32 -0400 Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Thu, 27 Jun 2002 01:20:01 -0400 (Eastern Daylight Time) Received: from moose ([198.144.203.249]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 27 Jun 2002 01:20:00 -0400 From: "Lisa Dusseault" To: "Webdav WG \(E-mail\)" Date: Wed, 26 Jun 2002 22:21:24 -0700 Message-ID: <000501c21d9a$7baa90a0$f9cb90c6@moose> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 27 Jun 2002 05:20:00.0986 (UTC) FILETIME=[493033A0:01C21D9A] Subject: New RFC2518bis draft Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6325 X-Loop: 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 version of the 2518bis is available. I'll submit it to the Internet-Drafts people shortly (to make the drafts cutoff). There is a Word doc version as well as the txt version -- the Word doc version should have revision marks available. Alternatively, you can take a look at the "RFC2518 Changes.doc" link to see a list of every change I've made and which of Jason's issues it's related to. Lisa From w3c-dist-auth-request@w3.org Thu Jun 27 08:32:56 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 IAA14553 for ; Thu, 27 Jun 2002 08:32: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 IAA17026; Thu, 27 Jun 2002 08:32:21 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RCWIJ21157; Thu, 27 Jun 2002 08:32:18 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 08:32:18 -0400 (EDT) Resent-Message-Id: <200206271232.g5RCWIJ21157@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 g5RCWGw21137 for ; Thu, 27 Jun 2002 08:32:16 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA16997 for ; Thu, 27 Jun 2002 08:32:15 -0400 Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Thu, 27 Jun 2002 14:31:36 +0200 Date: Thu, 27 Jun 2002 14:31:35 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "Lisa Dusseault" , "Webdav WG \(E-mail\)" , LMM@acm.org To: "Julian Reschke" From: Stefan Eissing In-Reply-To: Message-Id: 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: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6326 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit As 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 Jun 27 11:55: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 LAA26333 for ; Thu, 27 Jun 2002 11:55: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 LAA06968; Thu, 27 Jun 2002 11:52:33 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RFqVI07611; Thu, 27 Jun 2002 11:52:31 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 11:52:31 -0400 (EDT) Resent-Message-Id: <200206271552.g5RFqVI07611@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 g5RFqTw07591 for ; Thu, 27 Jun 2002 11:52:29 -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 LAA06960 for ; Thu, 27 Jun 2002 11:52:29 -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 g5RFppg5079684; Thu, 27 Jun 2002 11: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 g5RFpmm113318; Thu, 27 Jun 2002 11:51:49 -0400 To: "Clemm, Geoff" Cc: "'Webdav WG (E-mail)'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Thu, 27 Jun 2002 11:44:56 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_05312002 Pre-release 2|May 31, 2002) at 06/27/2002 11:51:48 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE176DFC7242B8f9e8a93df938690918c0ABBE176DFC7242B" Content-Disposition: inline Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6327 X-Loop: 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__=0ABBE176DFC7242B8f9e8a93df938690918c0ABBE176DFC7242B Content-type: text/plain; charset=US-ASCII > I agree that 2 and 3 are sufficiently important use cases > to support the DAV:source protocol element. Noted. > I think one > can make a reasonable case that 4 is also handled by > DAV:source (i.e. it is a reasonable extension of 3). Four. That's the items that says we need a way to know what URI to delete to remove the mapping of this resource at this URI. I think that would require a bit more discussion... but we can do that now... If a resource has multiple sources listed, we'd need to designate which one is the one that causes the deletion at this URI. That's why I suggested that a single resource be able to have multiple roles. I was envisioning a DELETE role... among others. Is this reasonable? There is also the case of a dynamic resourse that is mapped to at URI via some manual/explicit process. An example would be some servlet engines I've seen. There is a registry that says that a certain class handles requests at a certain URL. There must be other examples. I assume in these servers, it's an unmapping process that's really what is wanted.... not necessarily the destruction of the implementation of the resource at that URI. In this case, the resource to delete might vary. 1) The URI itself might be deletable. 2) The server might create a virutual resource just for the purpose of giving the clieting something to delete to cause the unmapping. 3) The server might have some other process for unmapping the resource and not support the DELETE method to do the unmapping of that resource. Is all of the a reasonable analysis? If so, do we allow case (3)? If so, what do we suggest the server should do to denote behavior (3)? J. --0__=0ABBE176DFC7242B8f9e8a93df938690918c0ABBE176DFC7242B Content-type: text/html; charset=US-ASCII Content-Disposition: inline

> I agree that 2 and 3 are sufficiently important use cases
> to support the DAV:source protocol element.
Noted.

> I think one
> can make a reasonable case that 4 is also handled by
> DAV:source (i.e. it is a reasonable extension of 3).
Four. That's the items that says we need a way to
know what URI to delete to remove the mapping of this
resource at this URI.

I think that would require a bit more discussion... but
we can do that now...

If a resource has multiple sources listed, we'd need to
designate which one is the one that causes the deletion
at this URI. That's why I suggested that a single
resource be able to have multiple roles. I was
envisioning a DELETE role... among others.

Is this reasonable?

There is also the case of a dynamic resourse that is
mapped to at URI via some manual/explicit process. An
example would be some servlet engines I've seen. There
is a registry that says that a certain class handles
requests at a certain URL. There must be other examples.
I assume in these servers, it's an unmapping process
that's really what is wanted.... not necessarily
the destruction of the implementation of the resource
at that URI.

In this case, the resource to delete might vary.

1) The URI itself might be deletable.
2) The server might create a virutual resource just for
the purpose of giving the clieting something to delete
to cause the unmapping.
3) The server might have some other process for unmapping
the resource and not support the DELETE method to do
the unmapping of that resource.

Is all of the a reasonable analysis? If so, do we allow
case (3)? If so, what do we suggest the server should
do to denote behavior (3)?

J. --0__=0ABBE176DFC7242B8f9e8a93df938690918c0ABBE176DFC7242B-- From w3c-dist-auth-request@w3.org Thu Jun 27 12:15: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 MAA28371 for ; Thu, 27 Jun 2002 12:15: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 MAA12273; Thu, 27 Jun 2002 12:14:50 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RGEnV10074; Thu, 27 Jun 2002 12:14:49 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 12:14:49 -0400 (EDT) Resent-Message-Id: <200206271614.g5RGEnV10074@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 g5RGEmw10050 for ; Thu, 27 Jun 2002 12:14:48 -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 MAA12267 for ; Thu, 27 Jun 2002 12:14:48 -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 g5RGCPg5058488; Thu, 27 Jun 2002 12:12: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 g5RGCNm97488; Thu, 27 Jun 2002 12:12:23 -0400 To: "Julian Reschke" Cc: "Lisa Dusseault" , "Webdav WG \(E-mail\)" , w3c-dist-auth-request@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Thu, 27 Jun 2002 11:52:49 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_05312002 Pre-release 2|May 31, 2002) at 06/27/2002 12:12:23 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE176DFC54B528f9e8a93df938690918c0ABBE176DFC54B52" Content-Disposition: inline Subject: RE: RFC2518bis: xml:lang (2.6) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6328 X-Loop: 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__=0ABBE176DFC54B528f9e8a93df938690918c0ABBE176DFC54B52 Content-type: text/plain; charset=US-ASCII I agree with Geoff and Julian that the 2518bis wording is not right because it specifies a specific location for that attribute. http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0318.html I also acknowledge that it's not easy to come up with a wording for this behavior. Sorry Lisa :-) J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com --0__=0ABBE176DFC54B528f9e8a93df938690918c0ABBE176DFC54B52 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I agree with Geoff and Julian that the 2518bis wording is not right because it specifies a specific location for that attribute.

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

I also acknowledge that it's not easy to come up with a wording for this behavior. Sorry Lisa :-)

J.

------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com
--0__=0ABBE176DFC54B528f9e8a93df938690918c0ABBE176DFC54B52-- From w3c-dist-auth-request@w3.org Thu Jun 27 12:35: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 MAA29840 for ; Thu, 27 Jun 2002 12:35: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 MAA16821; Thu, 27 Jun 2002 12:34:52 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RGYob11532; Thu, 27 Jun 2002 12:34:50 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 12:34:50 -0400 (EDT) Resent-Message-Id: <200206271634.g5RGYob11532@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 g5RGYnw11512 for ; Thu, 27 Jun 2002 12:34:49 -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 MAA16809 for ; Thu, 27 Jun 2002 12:34:49 -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 g5RGWwg5227338; Thu, 27 Jun 2002 12:32:58 -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 g5RGWum139558; Thu, 27 Jun 2002 12:32:56 -0400 To: "Lisa Dusseault" Cc: "Webdav WG \(E-mail\)" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Thu, 27 Jun 2002 12:25:03 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_05312002 Pre-release 2|May 31, 2002) at 06/27/2002 12:32:55 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE176DFCA57FA8f9e8a93df938690918c0ABBE176DFCA57FA" Content-Disposition: inline Subject: Re: New RFC2518bis draft, LOCK_REFRESH_BY_METHODS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6329 X-Loop: 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__=0ABBE176DFCA57FA8f9e8a93df938690918c0ABBE176DFCA57FA Content-type: text/plain; charset=US-ASCII The current wording is difficult to understand. I'd suggest that the wording be changed from... The timeout counter SHOULD NOT be restarted any time an owner of the lock sends a method to any member of the lock, including unsupported methods, or methods which are unsuccessful. However the lock MUST be refreshed if a refresh LOCK method is successfully received. To simply say... The timeout counter SHOULD only be restarted if a refresh LOCK method is successfully received. If you like, we can mention that this is a change from 2518. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com --0__=0ABBE176DFCA57FA8f9e8a93df938690918c0ABBE176DFCA57FA Content-type: text/html; charset=US-ASCII Content-Disposition: inline

The current wording is difficult to understand. I'd suggest that the wording be changed from...

The timeout counter SHOULD NOT be restarted any time an owner of the lock sends a method to any member of the lock, including unsupported methods, or methods which are unsuccessful. However the lock MUST be refreshed if a refresh LOCK method is successfully received.

To simply say...

The timeout counter SHOULD only be restarted if a refresh LOCK method is successfully received.

If you like, we can mention that this is a change from 2518.

------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com
--0__=0ABBE176DFCA57FA8f9e8a93df938690918c0ABBE176DFCA57FA-- From w3c-dist-auth-request@w3.org Thu Jun 27 12:48: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 MAA00604 for ; Thu, 27 Jun 2002 12:48: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 MAA19035; Thu, 27 Jun 2002 12:47:03 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RGl2812337; Thu, 27 Jun 2002 12:47:02 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 12:47:02 -0400 (EDT) Resent-Message-Id: <200206271647.g5RGl2812337@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 g5RGl1w12317 for ; Thu, 27 Jun 2002 12:47: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 MAA19028 for ; Thu, 27 Jun 2002 12:47:01 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Thu, 27 Jun 2002 12:46:25 -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); Thu, 27 Jun 2002 12:46:24 -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.4712.0 Date: Thu, 27 Jun 2002 12:46:24 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA601736D803@ATL1VEXC006.usdom004.tco.tc> Thread-topic: New RFC2518bis draft, LOCK_REFRESH_BY_METHODS thread-index: AcId+Om+7JFwNoQ3T8uPvJk52C1LcQAAPC/w From: "Lisa Dusseault" To: "Jason Crawford" Cc: X-OriginalArrivalTime: 27 Jun 2002 16:46:24.0798 (UTC) FILETIME=[2CA733E0:01C21DFA] Subject: RE: New RFC2518bis draft, LOCK_REFRESH_BY_METHODS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6330 X-Loop: 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_01C21DFA.2CA6E57F" ------_=_NextPart_001_01C21DFA.2CA6E57F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not so sure about the wording you suggest. It drops the requirement that the lock MUST be refreshed if a refresh LOCk method is successful. How about this: =20 "The timeout counter MUST be restarted if a refresh LOCK request is successful. The timeout counter SHOULD NOT be restarted at any other time." =20 Lisa =20 -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com]=20 Sent: Thursday, June 27, 2002 8:25 AM To: Lisa Dusseault Cc: Webdav WG (E-mail) Subject: Re: New RFC2518bis draft, LOCK_REFRESH_BY_METHODS =20 The current wording is difficult to understand. I'd suggest that the wording be changed from... The timeout counter SHOULD NOT be restarted any time an owner of the lock sends a method to any member of the lock, including unsupported methods, or methods which are unsuccessful. However the lock MUST be refreshed if a refresh LOCK method is successfully received. To simply say... The timeout counter SHOULD only be restarted if a refresh LOCK method is successfully received. If you like, we can mention that this is a change from 2518. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com ------_=_NextPart_001_01C21DFA.2CA6E57F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not so sure about the = wording you suggest. It drops the requirement that the lock MUST be refreshed if = a refresh LOCk method is successful.  How about = this:

 

“The timeout counter MUST be restarted if a refresh LOCK request is successful.  The timeout = counter SHOULD NOT be restarted at any other time.”

 

Lisa

 

-----Original = Message-----
From: Jason Crawford [mailto:ccjason@us.ibm.com]
Sent: Thursday, June 27, = 2002 8:25 AM
To: Lisa Dusseault
Cc: Webdav WG = (E-mail)
Subject: Re: New = RFC2518bis draft, LOCK_REFRESH_BY_METHODS

 

The current wording is difficult to = understand. I'd suggest that the wording be changed from...

The timeout counter SHOULD NOT be restarted any time an owner of the = lock sends a method to any member of the lock, including unsupported methods, or = methods which are unsuccessful. However the lock MUST be refreshed if a refresh = LOCK method is successfully received.

To simply say...

The timeout counter SHOULD only be restarted if a refresh LOCK method is successfully received.

If you like, we can mention that this is a change from 2518.

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

=00 ------_=_NextPart_001_01C21DFA.2CA6E57F-- --------------InterScan_NT_MIME_Boundary-- From w3c-dist-auth-request@w3.org Thu Jun 27 12:53:44 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 MAA01018 for ; Thu, 27 Jun 2002 12:53: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 MAA20132; Thu, 27 Jun 2002 12:52:25 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RGqOM12924; Thu, 27 Jun 2002 12:52:24 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 12:52:24 -0400 (EDT) Resent-Message-Id: <200206271652.g5RGqOM12924@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 g5RGqNw12904 for ; Thu, 27 Jun 2002 12:52:23 -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 MAA20112 for ; Thu, 27 Jun 2002 12:52:23 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Thu, 27 Jun 2002 12:51:41 -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, 27 Jun 2002 12:51:41 -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.4712.0 Date: Thu, 27 Jun 2002 12:51:41 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA6017371B99@ATL1VEXC006.usdom004.tco.tc> Thread-topic: RFC2518bis: xml:lang (2.6) thread-index: AcId9jhYMVQAatczQPmCsM5XLkvyKAABBrxg From: "Lisa Dusseault" To: "Jason Crawford" , "Julian Reschke" Cc: "Webdav WG (E-mail)" X-OriginalArrivalTime: 27 Jun 2002 16:51:41.0237 (UTC) FILETIME=[E943F650:01C21DFA] Subject: RE: RFC2518bis: xml:lang (2.6) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6331 X-Loop: 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_01C21DFA.E9390D08" ------_=_NextPart_001_01C21DFA.E9390D08 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A specific location for the lang attribute is good. It is more tightly constrained, which makes it easier for both clients and servers to handle XML with property values. =20 Please explain why it is important to be flexible in this case. Also, if the lang attribute must be legal in more than one location, explain if there is any semantic difference between the multiple locations. Also, explain what happens if the lang attribute is present in multiple locations scoped to the same property, particularly if it has different values in different locations! =20 If some servers will be slightly incompatible with RFC2518bis because of making the location specific, I understand that's undesirable. However, I think in the long run it will make interoperability more likely for this feature, and the benefits will outweigh the costs. =20 Lisa =20 -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com]=20 Sent: Thursday, June 27, 2002 7:53 AM To: Julian Reschke Cc: Lisa Dusseault; Webdav WG (E-mail); w3c-dist-auth-request@w3.org Subject: RE: RFC2518bis: xml:lang (2.6) =20 I agree with Geoff and Julian that the 2518bis wording is not right because it specifies a specific location for that attribute. http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0318.html I also acknowledge that it's not easy to come up with a wording for this behavior. Sorry Lisa :-) J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com ------_=_NextPart_001_01C21DFA.E9390D08 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A specific location for the lang = attribute is good.  It is more tightly constrained, which makes it easier for = both clients and servers to handle XML with property = values.

 

Please explain why it is important = to be flexible in this case. Also, if the lang attribute must be legal in more = than one location, explain if there is any semantic difference between the = multiple locations.  Also, explain what happens if the lang attribute is = present in multiple locations scoped to the same property, particularly if it has different values in different locations!

 

If some servers will be slightly incompatible with RFC2518bis because of making the location specific, I understand that’s undesirable. However, I think in the long run it = will make interoperability more likely for this feature, and the benefits = will outweigh the costs.

 

Lisa

 

-----Original = Message-----
From: Jason Crawford [mailto:ccjason@us.ibm.com]
Sent: Thursday, June 27, = 2002 7:53 AM
To: Julian Reschke
Cc: Lisa Dusseault; = Webdav WG (E-mail); w3c-dist-auth-request@w3.org
Subject: RE: RFC2518bis: = xml:lang (2.6)

 

I agree with Geoff and Julian that the = 2518bis wording is not right because it specifies a specific location for that = attribute.

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

I also acknowledge that it's not easy to come up with a wording for this behavior. Sorry Lisa :-)

J.

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

=00 ------_=_NextPart_001_01C21DFA.E9390D08-- --------------InterScan_NT_MIME_Boundary-- From w3c-dist-auth-request@w3.org Thu Jun 27 13:26:44 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 NAA02791 for ; Thu, 27 Jun 2002 13:26: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 NAA25519; Thu, 27 Jun 2002 13:25:52 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RHPor17531; Thu, 27 Jun 2002 13:25:50 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 13:25:50 -0400 (EDT) Resent-Message-Id: <200206271725.g5RHPor17531@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 g5RHPmw17507 for ; Thu, 27 Jun 2002 13:25:48 -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 NAA25504 for ; Thu, 27 Jun 2002 13:25:48 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Thu, 27 Jun 2002 13:18:53 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 13:25:17 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B300@SUS-MA1IT01> From: "Clemm, Geoff" To: "Webdav WG (E-mail)" Date: Thu, 27 Jun 2002 13:25:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: New RFC2518bis draft, LOCK_REFRESH_BY_METHODS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6332 X-Loop: 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 sounds good to me. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Thursday, June 27, 2002 12:25 PM To: Lisa Dusseault Cc: Webdav WG (E-mail) Subject: Re: New RFC2518bis draft, LOCK_REFRESH_BY_METHODS The current wording is difficult to understand. I'd suggest that the wording be changed from... The timeout counter SHOULD NOT be restarted any time an owner of the lock sends a method to any member of the lock, including unsupported methods, or methods which are unsuccessful. However the lock MUST be refreshed if a refresh LOCK method is successfully received. To simply say... The timeout counter SHOULD only be restarted if a refresh LOCK method is successfully received. If you like, we can mention that this is a change from 2518. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Jun 27 13:29: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 NAA02908 for ; Thu, 27 Jun 2002 13:29: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 NAA26197; Thu, 27 Jun 2002 13:28:15 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RHSFR17944; Thu, 27 Jun 2002 13:28:15 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 13:28:15 -0400 (EDT) Resent-Message-Id: <200206271728.g5RHSFR17944@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 g5RHSCw17924 for ; Thu, 27 Jun 2002 13:28:12 -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 NAA26143 for ; Thu, 27 Jun 2002 13:28:11 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Thu, 27 Jun 2002 13:21:16 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 13:27:40 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B301@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Thu, 27 Jun 2002 13:27:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21DFF.F00CC570" Subject: RE: New RFC2518bis draft, LOCK_REFRESH_BY_METHODS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6333 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21DFF.F00CC570 Content-Type: text/plain Yes, I agree that is better. Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:ldusseault@xythos.com] Sent: Thursday, June 27, 2002 12:46 PM To: Jason Crawford Cc: w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, LOCK_REFRESH_BY_METHODS I'm not so sure about the wording you suggest. It drops the requirement that the lock MUST be refreshed if a refresh LOCk method is successful. How about this: "The timeout counter MUST be restarted if a refresh LOCK request is successful. The timeout counter SHOULD NOT be restarted at any other time." Lisa -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Thursday, June 27, 2002 8:25 AM To: Lisa Dusseault Cc: Webdav WG (E-mail) Subject: Re: New RFC2518bis draft, LOCK_REFRESH_BY_METHODS The current wording is difficult to understand. I'd suggest that the wording be changed from... The timeout counter SHOULD NOT be restarted any time an owner of the lock sends a method to any member of the lock, including unsupported methods, or methods which are unsuccessful. However the lock MUST be refreshed if a refresh LOCK method is successfully received. To simply say... The timeout counter SHOULD only be restarted if a refresh LOCK method is successfully received. If you like, we can mention that this is a change from 2518. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com ------_=_NextPart_001_01C21DFF.F00CC570 Content-Type: text/html
Yes, I agree that is better.
 
Cheers,
Geoff
-----Original Message-----
From: Lisa Dusseault [mailto:ldusseault@xythos.com]
Sent: Thursday, June 27, 2002 12:46 PM
To: Jason Crawford
Cc: w3c-dist-auth@w3c.org
Subject: RE: New RFC2518bis draft, LOCK_REFRESH_BY_METHODS

I’m not so sure about the wording you suggest. It drops the requirement that the lock MUST be refreshed if a refresh LOCk method is successful.  How about this:

 

“The timeout counter MUST be restarted if a refresh LOCK request is successful.  The timeout counter SHOULD NOT be restarted at any other time.”

 

Lisa

 

-----Original Message-----
From: Jason Crawford [mailto:ccjason@us.ibm.com]
Sent: Thursday, June 27, 2002 8:25 AM
To: Lisa Dusseault
Cc: Webdav WG (E-mail)
Subject: Re: New RFC2518bis draft, LOCK_REFRESH_BY_METHODS

 

The current wording is difficult to understand. I'd suggest that the wording be changed from...

The timeout counter SHOULD NOT be restarted any time an owner of the lock sends a method to any member of the lock, including unsupported methods, or methods which are unsuccessful. However the lock MUST be refreshed if a refresh LOCK method is successfully received.

To simply say...

The timeout counter SHOULD only be restarted if a refresh LOCK method is successfully received.

If you like, we can mention that this is a change from 2518.

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

------_=_NextPart_001_01C21DFF.F00CC570-- From w3c-dist-auth-request@w3.org Thu Jun 27 13:55: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 NAA04630 for ; Thu, 27 Jun 2002 13:55: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 NAA32746; Thu, 27 Jun 2002 13:54:53 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RHsqo21698; Thu, 27 Jun 2002 13:54:52 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 13:54:52 -0400 (EDT) Resent-Message-Id: <200206271754.g5RHsqo21698@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 g5RHsow21674 for ; Thu, 27 Jun 2002 13:54:50 -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 NAA32740 for ; Thu, 27 Jun 2002 13:54:50 -0400 Received: (qmail 18089 invoked by uid 0); 27 Jun 2002 17:54:18 -0000 Received: from p3ee2476f.dip.t-dialin.net (HELO lisa) (62.226.71.111) by mail.gmx.net (mp004-rz3) with SMTP; 27 Jun 2002 17:54:18 -0000 From: "Julian Reschke" To: "Webdav WG \(E-mail\)" Date: Thu, 27 Jun 2002 19:54:17 +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: <27889B08CAEC7049B68FAD8717BA6017371B99@ATL1VEXC006.usdom004.tco.tc> Importance: Normal Subject: RE: RFC2518bis: xml:lang (2.6) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6334 X-Loop: 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 don't buy that argument. The XML spec clearly states what the scope of xml:lang is (the containing element and all descendants). If WebDAV wants to override this rule, there should be a better rational than "it's too much work implementing what the XML spec says". Regarding your questions: > Please explain why it is important to be flexible in this case I think it is important that XML-based specifications do not override XML's rules without good reason. In this case, I haven't seen one yet. > Also, if the lang attribute must be legal in more than one location, explain if there is any semantic difference between the multiple locations. For each DAV:prop element, there's only one xml:lang declaration in scope. It is completely irrelevant to which attribute it is attached. > Also, explain what happens if the lang attribute is present in multiple locations scoped to the same property, particularly if it has different values in different locations! Can't happen with the given scoping rules. > If some servers will be slightly incompatible with RFC2518bis because of making the location specific, I understand that's undesirable. However, I think in the long run it will make interoperability more likely for this feature, and the benefits will outweigh the costs. I think this argument works both directions. The only problem with the current spec is that it's silent on the issue, *possibly* causing interop problems for people not reading the XML spec properly. The non-intrusive fix to this is to clarify how the scoping rules defined in the XML spec apply to property values, NOT to change those. Julian -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault Sent: Thursday, June 27, 2002 6:52 PM To: Jason Crawford; Julian Reschke Cc: Webdav WG (E-mail) Subject: RE: RFC2518bis: xml:lang (2.6) A specific location for the lang attribute is good. It is more tightly constrained, which makes it easier for both clients and servers to handle XML with property values. Please explain why it is important to be flexible in this case. Also, if the lang attribute must be legal in more than one location, explain if there is any semantic difference between the multiple locations. Also, explain what happens if the lang attribute is present in multiple locations scoped to the same property, particularly if it has different values in different locations! If some servers will be slightly incompatible with RFC2518bis because of making the location specific, I understand that's undesirable. However, I think in the long run it will make interoperability more likely for this feature, and the benefits will outweigh the costs. Lisa -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Thursday, June 27, 2002 7:53 AM To: Julian Reschke Cc: Lisa Dusseault; Webdav WG (E-mail); w3c-dist-auth-request@w3.org Subject: RE: RFC2518bis: xml:lang (2.6) I agree with Geoff and Julian that the 2518bis wording is not right because it specifies a specific location for that attribute. http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0318.html I also acknowledge that it's not easy to come up with a wording for this behavior. Sorry Lisa :-) J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Jun 27 13:56: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 NAA04675 for ; Thu, 27 Jun 2002 13:56: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 NAA00426; Thu, 27 Jun 2002 13:55:38 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RHtbi21790; Thu, 27 Jun 2002 13:55:37 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 13:55:37 -0400 (EDT) Resent-Message-Id: <200206271755.g5RHtbi21790@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 g5RHtaw21757 for ; Thu, 27 Jun 2002 13:55:36 -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 NAA00415 for ; Thu, 27 Jun 2002 13:55:36 -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 g5RHste8081294; Thu, 27 Jun 2002 13:54:56 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5RHsrm100300; Thu, 27 Jun 2002 13:54:53 -0400 To: "Lisa Dusseault" Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Thu, 27 Jun 2002 13:05:26 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_05312002 Pre-release 2|May 31, 2002) at 06/27/2002 13:54:53 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE176DFCE670F8f9e8a93df938690918c0ABBE176DFCE670F" Content-Disposition: inline Subject: Re: New RFC2518bis draft, XML_NOT_VALID Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6335 X-Loop: 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__=0ABBE176DFCE670F8f9e8a93df938690918c0ABBE176DFCE670F Content-type: text/plain; charset=US-ASCII I think the current text could be improved by changing "legal XML may not" to be "legal WebDAV XML might not". This avoids the use of "may not" which has a somewhat different meaning. I'm suggesting inserting "WebDAV" there just to be a bit clearer although I think one can improve on that suggestion also. "A DTD is provided in Appendix 1. However, legal XML may not be valid according to this DTD, because unknown XML elements may appear in WebDAV syntax without making the syntax illegal." becomes "A DTD is provided in Appendix 1. However, legal WebDAV XML might not be valid according to this DTD, because unknown XML elements may appear in WebDAV syntax without making the syntax illegal." ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com --0__=0ABBE176DFCE670F8f9e8a93df938690918c0ABBE176DFCE670F Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I think the current text could be improved by changing "legal XML may not" to be "legal WebDAV XML might not". This avoids the use of "may not" which has a somewhat different meaning. I'm suggesting inserting "WebDAV" there just to be a bit clearer although I think one can improve on that suggestion also.

"A DTD is provided in Appendix 1. However, legal XML may not be valid according to this DTD, because unknown XML elements may appear in WebDAV syntax without making the syntax illegal."

becomes

"A DTD is provided in Appendix 1. However, legal WebDAV XML might not be valid according to this DTD, because unknown XML elements may appear in WebDAV syntax without making the syntax illegal."

------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com
--0__=0ABBE176DFCE670F8f9e8a93df938690918c0ABBE176DFCE670F-- From w3c-dist-auth-request@w3.org Thu Jun 27 13:57: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 NAA04784 for ; Thu, 27 Jun 2002 13:57: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 NAA00855; Thu, 27 Jun 2002 13:56:50 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RHunW22047; Thu, 27 Jun 2002 13:56:49 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 13:56:49 -0400 (EDT) Resent-Message-Id: <200206271756.g5RHunW22047@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 g5RHumw22027 for ; Thu, 27 Jun 2002 13:56:48 -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 NAA00840 for ; Thu, 27 Jun 2002 13:56:48 -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 g5RHsug5166880; Thu, 27 Jun 2002 13:54:56 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5RHsrm110654; Thu, 27 Jun 2002 13:54:53 -0400 To: "Lisa Dusseault" Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Thu, 27 Jun 2002 13:09:23 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_05312002 Pre-release 2|May 31, 2002) at 06/27/2002 13:54:53 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE176DFCD9F358f9e8a93df938690918c0ABBE176DFCD9F35" Content-Disposition: inline Subject: RE: New RFC2518bis draft, LOCK_REFRESH_BY_METHODS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6337 X-Loop: 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__=0ABBE176DFCD9F358f9e8a93df938690918c0ABBE176DFCD9F35 Content-type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoN Cjw8DQrigJxUaGUgdGltZW91dCBjb3VudGVyIE1VU1QgYmUgcmVzdGFydGVkIGlmIGEgcmVmcmVz aCBMT0NLIHJlcXVlc3QgaXMNCnN1Y2Nlc3NmdWwuICBUaGUgdGltZW91dCBjb3VudGVyIFNIT1VM RCBOT1QgYmUgcmVzdGFydGVkIGF0IGFueSBvdGhlcg0KdGltZS7igJ0NCj4+DQoNCkZpbmUgYnkg bWUuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KUGhvbmU6 IDkxNC03ODQtNzU2OSwgICBjY2phc29uQHVzLmlibS5jb20NCg0KDQo= --0__=0ABBE176DFCD9F358f9e8a93df938690918c0ABBE176DFCD9F35 Content-type: text/html; charset=UTF-8 Content-Disposition: inline Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHk+DQo8cD48Zm9udCBjb2xvcj0iIzAwMDA4MCIgZmFjZT0iQXJpYWwiPiZsdDsm bHQ7PC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDgwIiBmYWNlPSJBcmlhbCI+4oCcVGhl IHRpbWVvdXQgY291bnRlciBNVVNUIGJlIHJlc3RhcnRlZCBpZiBhIHJlZnJlc2ggTE9DSyByZXF1 ZXN0IGlzIHN1Y2Nlc3NmdWwuICBUaGUgdGltZW91dCBjb3VudGVyIFNIT1VMRCBOT1QgYmUgcmVz dGFydGVkIGF0IGFueSBvdGhlciB0aW1lLuKAnTwvZm9udD48YnI+DQomZ3Q7Jmd0Ozxicj4NCjxi cj4NCkZpbmUgYnkgbWUuPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPg0KUGhvbmU6IDkxNC03ODQtNzU2OSwgICBjY2phc29uQHVzLmlibS5j b208YnI+DQoNCjx1bD4NCjx1bD48L3VsPg0KPC91bD4NCjwvYm9keT48L2h0bWw+ --0__=0ABBE176DFCD9F358f9e8a93df938690918c0ABBE176DFCD9F35-- From w3c-dist-auth-request@w3.org Thu Jun 27 14:01: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 OAA05123 for ; Thu, 27 Jun 2002 14:01: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 OAA02006; Thu, 27 Jun 2002 14:00:27 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RI0Q222676; Thu, 27 Jun 2002 14:00:26 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 14:00:26 -0400 (EDT) Resent-Message-Id: <200206271800.g5RI0Q222676@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 g5RI0Ow22652 for ; Thu, 27 Jun 2002 14:00:24 -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 OAA01991 for ; Thu, 27 Jun 2002 14:00:24 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Thu, 27 Jun 2002 13:59:51 -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); Thu, 27 Jun 2002 13:59:51 -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.4712.0 Date: Thu, 27 Jun 2002 13:59:51 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA601736D805@ATL1VEXC006.usdom004.tco.tc> Thread-topic: New RFC2518bis draft, LOCK_URL_WITH_NO_PARENT_COLLECTION thread-index: AcIeA9gQaKbm8z6iRSa6zG3F1dRi0wAAIMpA From: "Lisa Dusseault" To: "Jason Crawford" Cc: X-OriginalArrivalTime: 27 Jun 2002 17:59:51.0310 (UTC) FILETIME=[6F2392E0:01C21E04] Subject: RE: New RFC2518bis draft, LOCK_URL_WITH_NO_PARENT_COLLECTION Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6338 X-Loop: 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_01C21E04.6F264346" ------_=_NextPart_001_01C21E04.6F264346 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is the standard wording throughout 2518, cut-and-pasted into the new status paragraph. Do you think the wording should change throughout? I think it's sufficiently clear although not optimally clear. =20 lisa =20 -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com]=20 Sent: Thursday, June 27, 2002 10:44 AM To: Lisa Dusseault Cc: w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, LOCK_URL_WITH_NO_PARENT_COLLECTION =20 I think there is a word missing in the new text. I suspect it's "parent" although that by itself doesn't quite fit either. 409 (Conflict) - A resource cannot be created at the destination until one or more intermediate [parent] collections have been created. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com ------_=_NextPart_001_01C21E04.6F264346 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is the standard wording = throughout 2518, cut-and-pasted into the new status paragraph.  Do you think = the wording should change throughout?  I think it’s sufficiently clear = although not optimally clear.

 

lisa

 

-----Original = Message-----
From: Jason Crawford [mailto:ccjason@us.ibm.com]
Sent: Thursday, June 27, = 2002 10:44 AM
To: Lisa Dusseault
Cc: = w3c-dist-auth@w3c.org
Subject: RE: New = RFC2518bis draft, LOCK_URL_WITH_NO_PARENT_COLLECTION

 

I think there is a word missing in the new = text. I suspect it's "parent" although that by itself doesn't quite = fit either.

409 (Conflict) – A resource cannot be created at the destination = until one or more intermediate [parent] collections have been created.


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

=00 ------_=_NextPart_001_01C21E04.6F264346-- --------------InterScan_NT_MIME_Boundary-- From w3c-dist-auth-request@w3.org Thu Jun 27 14:04: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 OAA05358 for ; Thu, 27 Jun 2002 14:04: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 OAA03033; Thu, 27 Jun 2002 14:04:04 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RI44m22997; Thu, 27 Jun 2002 14:04:04 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 14:04:04 -0400 (EDT) Resent-Message-Id: <200206271804.g5RI44m22997@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 g5RI42w22977 for ; Thu, 27 Jun 2002 14:04:02 -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 OAA03010 for ; Thu, 27 Jun 2002 14:04:02 -0400 Received: (qmail 14220 invoked by uid 0); 27 Jun 2002 18:03:39 -0000 Received: from p3ee2476f.dip.t-dialin.net (HELO lisa) (62.226.71.111) by mail.gmx.net (mp011-rz3) with SMTP; 27 Jun 2002 18:03:39 -0000 From: "Julian Reschke" To: "Julian Reschke" , "Webdav WG \(E-mail\)" Date: Thu, 27 Jun 2002 20:03:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Subject: RE: RFC2518bis: xml:lang (2.6) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6339 X-Loop: 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 Julian Reschke > Sent: Thursday, June 27, 2002 7:54 PM > To: Webdav WG (E-mail) > Subject: RE: RFC2518bis: xml:lang (2.6) > .. > > For each DAV:prop element, there's only one xml:lang declaration in scope. > It is completely irrelevant to which attribute it is attached. Sorry: It is completely irrelevant to which *element* it is attached. From w3c-dist-auth-request@w3.org Thu Jun 27 14:06: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 OAA05562 for ; Thu, 27 Jun 2002 14:06: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 OAA03615; Thu, 27 Jun 2002 14:06:15 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RI6Em23544; Thu, 27 Jun 2002 14:06:14 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 14:06:14 -0400 (EDT) Resent-Message-Id: <200206271806.g5RI6Em23544@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 g5RI6Dw23524 for ; Thu, 27 Jun 2002 14:06: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 OAA03606 for ; Thu, 27 Jun 2002 14:06:12 -0400 Received: (qmail 18976 invoked by uid 0); 27 Jun 2002 18:05:41 -0000 Received: from p3ee2476f.dip.t-dialin.net (HELO lisa) (62.226.71.111) by mail.gmx.net (mp004-rz3) with SMTP; 27 Jun 2002 18:05:41 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Lisa Dusseault" Cc: Date: Thu, 27 Jun 2002 20:05:41 +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: Importance: Normal Subject: RE: New RFC2518bis draft, XML_NOT_VALID Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6340 X-Loop: 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 Actually, things are worse. Legal WebXML *will* not be valid according to the DTD. The reason being that "legal WebDAV XML" uses elements in the "DAV:" namespace, while DTDs are fundamentally incompatible with XML namespaces. Julian -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford Sent: Thursday, June 27, 2002 7:05 PM To: Lisa Dusseault Cc: w3c-dist-auth@w3c.org Subject: Re: New RFC2518bis draft, XML_NOT_VALID I think the current text could be improved by changing "legal XML may not" to be "legal WebDAV XML might not". This avoids the use of "may not" which has a somewhat different meaning. I'm suggesting inserting "WebDAV" there just to be a bit clearer although I think one can improve on that suggestion also. "A DTD is provided in Appendix 1. However, legal XML may not be valid according to this DTD, because unknown XML elements may appear in WebDAV syntax without making the syntax illegal." becomes "A DTD is provided in Appendix 1. However, legal WebDAV XML might not be valid according to this DTD, because unknown XML elements may appear in WebDAV syntax without making the syntax illegal." ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Jun 27 14:16: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 OAA06190 for ; Thu, 27 Jun 2002 14: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 OAA05399; Thu, 27 Jun 2002 14:15:18 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RIFHY24588; Thu, 27 Jun 2002 14:15:17 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 14:15:17 -0400 (EDT) Resent-Message-Id: <200206271815.g5RIFHY24588@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 g5RIFGw24568 for ; Thu, 27 Jun 2002 14:15:16 -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 OAA05392 for ; Thu, 27 Jun 2002 14:15:15 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.wakasoft.com (8.12.4/8.12.4) with ESMTP id g5RID5hZ000544; Thu, 27 Jun 2002 11:13:06 -0700 (PDT) Date: Thu, 27 Jun 2002 11:13:05 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "'Webdav WG (E-mail)'" To: "Jason Crawford" From: "Roy T. Fielding" In-Reply-To: Message-Id: <86A9237C-89F9-11D6-BE63-000393753936@apache.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6341 X-Loop: 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 assume the following questions (and perhaps more) need to be answered > (by the DAV:source property). I don't think it's acceptable to say that > the answer varies and that the client just know the mapping function. > I've explained why above. I think we need to perhaps admit that the > answer will vary from server to server, but that some aspect of WebDAV > (presumably the DAV:source property) tells the client how to get the job > done. > > 1) An author wants to create a dynamic web page using an implementation > he has. The URL where he wants the dynamic content served is currently > unmapped. Where does he PUT the implementation to create the mapping? (I' > m assuming an automatic mapping process.) It will depend on the server. That is true of all name creation activities, whether they be static or dynamic. > 2) An author wants to browse the code he submitted as an implementation > of a resource. At what URL does the author do the GET? (I think we answer > this with DAV:source.) The source property tells the client where to go next. > 3) A dynamic page is being served at a given URL. The author wants to > update the implementation of that dynamic resource. Where does he PUT the > updated implementation? (I think we've answered the basic form of this > question via the dav:source propety. Questions like whether the update > will be refelcted immediately can be answered later.) The dynamic content resource will point to other resources that the client might be interested in authoring to change the content of both resources. If the server is capable of handling PUT on a "dynamic content" resource, then it may also support direct editing of the resource. Day Software's products support that kind of editing, but as far as the client is concerned it is just performing methods on a WebDAV resource. There is no difference between the two EXCEPT that there are some circumstances when the client needs to be encouraged to go elsewhere (such as when the author wishes to edit a presentation template). The principles are the same. A source property is merely a mechanism to supply metadata for a relationship between two or more resources. > 4) An author wants to no longer serve dynamic content at a specific URL. > What URL does the author DELETE? The URL they want to DELETE, which, depending on the implementation, may result in a suggestion to the author that they need to DELETE some other resource instead (or as well). > 5) Make sure the answers to the above question still work in concept for > resources that would list multiple DAV:source resources. They work for resources in general. > 6) Make sure the answers to the questions above don't cause problems for > servers that require explicit client controlled mapping operations. A server that requires explicit name bindings will naturally require operations on those bindings that make them explicit. > I'm sure I've missed some other fundamental questions, but the 4+2 above > seem like a good easy to understand start. > > I do think it's acceptable to say that DAV:source only solves 2 & 3 and > we'll solve the other questions later. In doing so, in the spec we can > clarify what DAV:source is NOT doing so that it doesn't get misused. We > also should mentally envision how we'd solve the other problems to insure > that what we are doing now will not prevent us from solving the remaining > problems later. The purpose of the source property is to allow a WebDAV-able resource to supply information to an authoring client regarding the nature of its underlying implementation by providing links to other resources that make up that implementation. That's all. It doesn't need to do anything more to justify its existence. ....Roy From w3c-dist-auth-request@w3.org Thu Jun 27 14:25: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 OAA06761 for ; Thu, 27 Jun 2002 14:25: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 OAA08068; Thu, 27 Jun 2002 14:24:08 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RIO7M25649; Thu, 27 Jun 2002 14:24:07 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 14:24:07 -0400 (EDT) Resent-Message-Id: <200206271824.g5RIO7M25649@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 g5RIO6w25625 for ; Thu, 27 Jun 2002 14:24:06 -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 OAA08059 for ; Thu, 27 Jun 2002 14:24:05 -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 g5RIMdpL024629 for ; Thu, 27 Jun 2002 11:22:39 -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 g5RIKUQG012633 for ; Thu, 27 Jun 2002 11:20:31 -0700 (PDT) Received: from dan.local.brotsky.com ([130.248.182.3]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GYDN3500.1YK for ; Thu, 27 Jun 2002 11:23:29 -0700 Date: Thu, 27 Jun 2002 11:23:31 -0700 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: Dan Brotsky To: w3c-dist-auth@w3c.org In-Reply-To: <27889B08CAEC7049B68FAD8717BA601736D803@ATL1VEXC006.usdom004.tco.tc> Message-Id: X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g5RIO6w25625 Subject: Re: New RFC2518bis draft, LOCK_REFRESH_BY_METHODS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6342 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit I like Lisa's latest proposal. I have two concern, based on no experience but just reading the text: 1. is it clear that REFRESH on any resource controlled by the lock (not just the URI in the original request) refreshes the counter? 2. is it clear that server policy is allowed to refresh the lock for its own reasons? Perhaps the following wording is true to the original but slightly clearer on these points? 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. dan On Thursday, June 27, 2002, at 09:46 AM, Lisa Dusseault wrote: > I’m not so sure about the wording you suggest. It drops the requirement > that the lock MUST be refreshed if a refresh LOCk method is > successful.  How about this: > >   > > “The timeout counter MUST be restarted if a refresh LOCK request is > successful.  The timeout counter SHOULD NOT be restarted at any other > time.” > >   > > Lisa > >   > > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Thursday, June 27, 2002 8:25 AM > To: Lisa Dusseault > Cc: Webdav WG (E-mail) > Subject: Re: New RFC2518bis draft, LOCK_REFRESH_BY_METHODS > >   > > The current wording is difficult to understand. I'd suggest that the > wording be changed from... > > The timeout counter SHOULD NOT be restarted any time an owner of the > lock sends a method to any member of the lock, including unsupported > methods, or methods which are unsuccessful. However the lock MUST be > refreshed if a refresh LOCK method is successfully received. > > To simply say... > > The timeout counter SHOULD only be restarted if a refresh LOCK method > is successfully received. > > If you like, we can mention that this is a change from 2518. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > From w3c-dist-auth-request@w3.org Thu Jun 27 14:26: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 OAA06857 for ; Thu, 27 Jun 2002 14:26: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 OAA08434; Thu, 27 Jun 2002 14:25:18 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RIPHq25938; Thu, 27 Jun 2002 14:25:17 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 14:25:17 -0400 (EDT) Resent-Message-Id: <200206271825.g5RIPHq25938@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 g5RIPHw25918 for ; Thu, 27 Jun 2002 14:25:17 -0400 (EDT) Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA08422 for ; Thu, 27 Jun 2002 14:25:16 -0400 Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27]) by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id g5RIP9g28822 for ; Thu, 27 Jun 2002 11:25:09 -0700 (PDT) Message-ID: <3D1B5857.2050904@cse.ucsc.edu> Date: Thu, 27 Jun 2002 11:24:23 -0700 From: Elias Sinderson Organization: Baskin School of Engineering - UCSC User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.0) Gecko/20020611 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: w3c-dist-auth@w3c.org References: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: New RFC2518bis draft, LOCK_REFRESH_BY_METHODS To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6343 X-Loop: 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 Jason Crawford wrote: > << > “The timeout counter MUST be restarted if a refresh LOCK request is > successful. The timeout counter SHOULD NOT be restarted at any other time.†> >> > > Fine by me. This seems quite clear to me also. Elias From w3c-dist-auth-request@w3.org Thu Jun 27 14:35: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 OAA07529 for ; Thu, 27 Jun 2002 14:35: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 OAA10529; Thu, 27 Jun 2002 14:32:56 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RIWtp26714; Thu, 27 Jun 2002 14:32:55 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 14:32:55 -0400 (EDT) Resent-Message-Id: <200206271832.g5RIWtp26714@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 g5RIWsw26690 for ; Thu, 27 Jun 2002 14:32: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 OAA10493 for ; Thu, 27 Jun 2002 14:32:54 -0400 Received: (qmail 29040 invoked by uid 0); 27 Jun 2002 18:32:22 -0000 Received: from p3ee2476f.dip.t-dialin.net (HELO lisa) (62.226.71.111) by mail.gmx.net (mp006-rz3) with SMTP; 27 Jun 2002 18:32:22 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Clemm, Geoff" Cc: "'Webdav WG \(E-mail\)'" Date: Thu, 27 Jun 2002 20:32:22 +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: Importance: Normal Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6344 X-Loop: 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 1) This is clearly server-defined. I can imagine all kinds of mechanisms for *creating* a dynamic resource, for instance PUTting an empty resource with a specific content type, then setting a few server-specific live properties. However, I can't imagine how RFC2518 could possibly define a method that can be applied to all types of servers. 2) DAV:source 3) Whether the change of the source resource(s) is reflected immediately again clearly is implementation specific. 4) The URL they want to delete. Whether this is allowed and has the desired effect again is implementation specific. 5) Yes. 6) Yes. Now I hear people saying: "if all of this is implementation specific -- where's interoperability"? That's basically asking RFC2518 to define a complete protocol for authoring dynamic content on *any* type of server -- and this clearly isn't realistic at all. The DAV:source property (when fixed :-) is clearly useful as defined. It doesn't *need* to solve all these other problems. If people are interested in working on a draft that defines authoring of dynamic content on *specific* servers, that's *also* an interesting project, but it doesn't belong in RFC2518bis (no more than in RFC2616). Julian -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford Sent: Monday, June 24, 2002 7:57 PM To: Clemm, Geoff Cc: 'Webdav WG (E-mail)' Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED I've spent some time trying to list the questions brought up in this discussion and the answers offered. I can post that list later. In building the list I found Lisa's questions interesting. For the most part the questions in the first half of Lisa's note [1] seem to be answered, but Lisa's later questions about mapping did not seem to be. The mapping issues seem to be an important issue for the source property, and the answer can vary from server to server. Are answers also hinted that the client has to know how the server does mappings, as they do now, but if that is our answer, then I'm not sure why we are defining the DAV:source property. [1] http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0170.html Can everyone do a mental reset and review why we have a source property? I assume the following questions (and perhaps more) need to be answered (by the DAV:source property). I don't think it's acceptable to say that the answer varies and that the client just know the mapping function. I've explained why above. I think we need to perhaps admit that the answer will vary from server to server, but that some aspect of WebDAV (presumably the DAV:source property) tells the client how to get the job done. 1) An author wants to create a dynamic web page using an implementation he has. The URL where he wants the dynamic content served is currently unmapped. Where does he PUT the implementation to create the mapping? (I'm assuming an automatic mapping process.) 2) An author wants to browse the code he submitted as an implementation of a resource. At what URL does the author do the GET? (I think we answer this with DAV:source.) 3) A dynamic page is being served at a given URL. The author wants to update the implementation of that dynamic resource. Where does he PUT the updated implementation? (I think we've answered the basic form of this question via the dav:source propety. Questions like whether the update will be refelcted immediately can be answered later.) 4) An author wants to no longer serve dynamic content at a specific URL. What URL does the author DELETE? 5) Make sure the answers to the above question still work in concept for resources that would list multiple DAV:source resources. 6) Make sure the answers to the questions above don't cause problems for servers that require explicit client controlled mapping operations. I'm sure I've missed some other fundamental questions, but the 4+2 above seem like a good easy to understand start. I do think it's acceptable to say that DAV:source only solves 2 & 3 and we'll solve the other questions later. In doing so, in the spec we can clarify what DAV:source is NOT doing so that it doesn't get misused. We also should mentally envision how we'd solve the other problems to insure that what we are doing now will not prevent us from solving the remaining problems later. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Jun 27 14:37: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 OAA07678 for ; Thu, 27 Jun 2002 14:37: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 OAA11437; Thu, 27 Jun 2002 14:36:09 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RIa8J27013; Thu, 27 Jun 2002 14:36:08 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 14:36:08 -0400 (EDT) Resent-Message-Id: <200206271836.g5RIa8J27013@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 g5RIa7w26993 for ; Thu, 27 Jun 2002 14:36:07 -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 OAA11393 for ; Thu, 27 Jun 2002 14:36:07 -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 g5RIZPe8075368; Thu, 27 Jun 2002 14:35:26 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5RIZNm51514; Thu, 27 Jun 2002 14:35:23 -0400 To: "Lisa Dusseault" Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Thu, 27 Jun 2002 14:28:46 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_05312002 Pre-release 2|May 31, 2002) at 06/27/2002 14:35:22 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE176DFF6D89C8f9e8a93df938690918c0ABBE176DFF6D89C" Content-Disposition: inline Subject: RE: New RFC2518bis draft, LOCK_URL_WITH_NO_PARENT_COLLECTION Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6345 X-Loop: 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__=0ABBE176DFF6D89C8f9e8a93df938690918c0ABBE176DFF6D89C Content-type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoN Cjw8DQpUaGlzIGlzIHRoZSBzdGFuZGFyZCB3b3JkaW5nIHRocm91Z2hvdXQgMjUxOCwgY3V0LWFu ZC1wYXN0ZWQgaW50byB0aGUgbmV3DQpzdGF0dXMgcGFyYWdyYXBoLiAgRG8geW91IHRoaW5rIHRo ZSB3b3JkaW5nIHNob3VsZCBjaGFuZ2UgdGhyb3VnaG91dD8gIEkNCnRoaW5rIGl04oCZcyBzdWZm aWNpZW50bHkgY2xlYXIgYWx0aG91Z2ggbm90IG9wdGltYWxseSBjbGVhci4NCj4+DQoNCk15IG1p c3Rha2UuICAgJ1RpbWUgdG8gZ2V0IHNvbWUgbmV3IGdsYXNzZXMuICAgWW91IGNhbiBsZWF2ZSBp dCBhcyBpdCBpcy4NCjotKQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClBob25lOiA5MTQtNzg0LTc1NjksICAgY2NqYXNvbkB1cy5pYm0uY29t --0__=0ABBE176DFF6D89C8f9e8a93df938690918c0ABBE176DFF6D89C Content-type: text/html; charset=UTF-8 Content-Disposition: inline Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHk+DQo8cD48Zm9udCBjb2xvcj0iIzAwMDA4MCIgZmFjZT0iQXJpYWwiPiZsdDsm bHQ7PC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMDgwIiBmYWNlPSJBcmlhbCI+VGhpcyBp cyB0aGUgc3RhbmRhcmQgd29yZGluZyB0aHJvdWdob3V0IDI1MTgsIGN1dC1hbmQtcGFzdGVkIGlu dG8gdGhlIG5ldyBzdGF0dXMgcGFyYWdyYXBoLiAgRG8geW91IHRoaW5rIHRoZSB3b3JkaW5nIHNo b3VsZCBjaGFuZ2UgdGhyb3VnaG91dD8gIEkgdGhpbmsgaXTigJlzIHN1ZmZpY2llbnRseSBjbGVh ciBhbHRob3VnaCBub3Qgb3B0aW1hbGx5IGNsZWFyLjwvZm9udD48YnI+DQo8Zm9udCBjb2xvcj0i IzAwMDA4MCIgZmFjZT0iQXJpYWwiPiZndDsmZ3Q7PC9mb250Pjxicj4NCjxicj4NCk15IG1pc3Rh a2UuICAgJ1RpbWUgdG8gZ2V0IHNvbWUgbmV3IGdsYXNzZXMuICAgWW91IGNhbiBsZWF2ZSBpdCBh cyBpdCBpcy4gIDotKTxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxicj4NClBob25lOiA5MTQtNzg0LTc1NjksICAgY2NqYXNvbkB1cy5pYm0uY29t PGJyPg0KPC9ib2R5PjwvaHRtbD4= --0__=0ABBE176DFF6D89C8f9e8a93df938690918c0ABBE176DFF6D89C-- From w3c-dist-auth-request@w3.org Thu Jun 27 14: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 OAA08075 for ; Thu, 27 Jun 2002 14: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 OAA12349; Thu, 27 Jun 2002 14:41:16 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RIf5227726; Thu, 27 Jun 2002 14:41:05 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 14:41:05 -0400 (EDT) Resent-Message-Id: <200206271841.g5RIf5227726@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 g5RIf5w27706 for ; Thu, 27 Jun 2002 14:41:05 -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 OAA12284 for ; Thu, 27 Jun 2002 14:41:04 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Thu, 27 Jun 2002 14:40:30 -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); Thu, 27 Jun 2002 14:40:30 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Thu, 27 Jun 2002 14:40:30 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA6017371B9A@ATL1VEXC006.usdom004.tco.tc> Thread-topic: RFC2518bis: xml:lang (2.6) thread-index: AcIeBBQlmC8vd9ABSW6dcOT2gBgpBAAAO+HQ From: "Lisa Dusseault" To: "Julian Reschke" Cc: X-OriginalArrivalTime: 27 Jun 2002 18:40:30.0107 (UTC) FILETIME=[1CC676B0:01C21E0A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g5RIf5w27706 Subject: RE: RFC2518bis: xml:lang (2.6) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6346 X-Loop: 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 OK, so it looks like we may need some language explaining that due to the definition of xml:lang, it can't appear more than once in the same scope. That's a good simplification. I still think it's wise to say where the xml:lang attribute must appear in order for the server to know that it must be stored along with the property. I don't think it's enough to say that any xml:lang whose scope includes the property value counts. Some XML parsers could put "xml:lang" on the root element of the document by default, even when that language value is actually inappropriate to the language value of certain properties. I do not believe the server should store that value in that case. Lisa -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Thursday, June 27, 2002 10:54 AM To: Webdav WG (E-mail) Subject: RE: RFC2518bis: xml:lang (2.6) I don't buy that argument. The XML spec clearly states what the scope of xml:lang is (the containing element and all descendants). If WebDAV wants to override this rule, there should be a better rational than "it's too much work implementing what the XML spec says". Regarding your questions: > Please explain why it is important to be flexible in this case I think it is important that XML-based specifications do not override XML's rules without good reason. In this case, I haven't seen one yet. > Also, if the lang attribute must be legal in more than one location, explain if there is any semantic difference between the multiple locations. For each DAV:prop element, there's only one xml:lang declaration in scope. It is completely irrelevant to which attribute it is attached. > Also, explain what happens if the lang attribute is present in multiple locations scoped to the same property, particularly if it has different values in different locations! Can't happen with the given scoping rules. > If some servers will be slightly incompatible with RFC2518bis because of making the location specific, I understand that's undesirable. However, I think in the long run it will make interoperability more likely for this feature, and the benefits will outweigh the costs. I think this argument works both directions. The only problem with the current spec is that it's silent on the issue, *possibly* causing interop problems for people not reading the XML spec properly. The non-intrusive fix to this is to clarify how the scoping rules defined in the XML spec apply to property values, NOT to change those. Julian -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault Sent: Thursday, June 27, 2002 6:52 PM To: Jason Crawford; Julian Reschke Cc: Webdav WG (E-mail) Subject: RE: RFC2518bis: xml:lang (2.6) A specific location for the lang attribute is good. It is more tightly constrained, which makes it easier for both clients and servers to handle XML with property values. Please explain why it is important to be flexible in this case. Also, if the lang attribute must be legal in more than one location, explain if there is any semantic difference between the multiple locations. Also, explain what happens if the lang attribute is present in multiple locations scoped to the same property, particularly if it has different values in different locations! If some servers will be slightly incompatible with RFC2518bis because of making the location specific, I understand that's undesirable. However, I think in the long run it will make interoperability more likely for this feature, and the benefits will outweigh the costs. Lisa -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Thursday, June 27, 2002 7:53 AM To: Julian Reschke Cc: Lisa Dusseault; Webdav WG (E-mail); w3c-dist-auth-request@w3.org Subject: RE: RFC2518bis: xml:lang (2.6) I agree with Geoff and Julian that the 2518bis wording is not right because it specifies a specific location for that attribute. http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0318.html I also acknowledge that it's not easy to come up with a wording for this behavior. Sorry Lisa :-) J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Jun 27 14:52: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 OAA08813 for ; Thu, 27 Jun 2002 14:52:10 -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 OAA13977; Thu, 27 Jun 2002 14:51:24 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RIpNw28568; Thu, 27 Jun 2002 14:51:23 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 14:51:23 -0400 (EDT) Resent-Message-Id: <200206271851.g5RIpNw28568@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 g5RIpMw28548 for ; Thu, 27 Jun 2002 14:51: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 OAA13965 for ; Thu, 27 Jun 2002 14:51:22 -0400 Received: (qmail 7372 invoked by uid 0); 27 Jun 2002 18:50:50 -0000 Received: from p3ee2476f.dip.t-dialin.net (HELO lisa) (62.226.71.111) by mail.gmx.net (mp014-rz3) with SMTP; 27 Jun 2002 18:50:50 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "Julian Reschke" Cc: Date: Thu, 27 Jun 2002 20:50:51 +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: <27889B08CAEC7049B68FAD8717BA6017371B9A@ATL1VEXC006.usdom004.tco.tc> Importance: Normal Subject: RE: RFC2518bis: xml:lang (2.6) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6347 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Lisa Dusseault [mailto:ldusseault@xythos.com] > Sent: Thursday, June 27, 2002 8:41 PM > To: Julian Reschke > Cc: w3c-dist-auth@w3c.org > Subject: RE: RFC2518bis: xml:lang (2.6) > > > OK, so it looks like we may need some language explaining that due to > the definition of xml:lang, it can't appear more than once in the same > scope. That's a good simplification. Well, the *attribute* xml:lang can appear more than once, but each and every *element* is always only in the scope of one specific xml:lang attribute. XML: "The intent declared with xml:lang is considered to apply to all attributes and content of the element where it is specified, unless overridden with an instance of xml:lang on another element within that content." In XPath-spec: the closest xml:lang attribute on "ancestor-or-self". > I still think it's wise to say where the xml:lang attribute must appear > in order for the server to know that it must be stored along with the > property. I don't think it's enough to say that any xml:lang whose It must be stored when it's present. So if xml:lang is in scope (no matter where), it needs to be stored with the property. I agree that RFC2518 should be clearer about this. > scope includes the property value counts. Some XML parsers could put > "xml:lang" on the root element of the document by default, even when No compliant XML parser will place an xml:lang anywhere unless explicitly asked to do that. Reporting xml:lang on the root element when it wasn't present in the parsed document clearly would be a parser bug. > that language value is actually inappropriate to the language value of > certain properties. I do not believe the server should store that value If it's inappropriate where it was sent, then it shouldn't have been sent. If it hasn't been sent and is reported by the XML parser nevertheless, that's a bug in the parser. > in that case. Julian From w3c-dist-auth-request@w3.org Thu Jun 27 14:55: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 NAA04674 for ; Thu, 27 Jun 2002 13:56: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 NAA00434; Thu, 27 Jun 2002 13:55:38 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RHtcp21809; Thu, 27 Jun 2002 13:55:38 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 13:55:38 -0400 (EDT) Resent-Message-Id: <200206271755.g5RHtcp21809@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 g5RHtbw21774 for ; Thu, 27 Jun 2002 13:55:37 -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 NAA00417 for ; Thu, 27 Jun 2002 13:55:37 -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 g5RHsue8081296; Thu, 27 Jun 2002 13:54:56 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5RHssm100302; Thu, 27 Jun 2002 13:54:54 -0400 To: "Lisa Dusseault" Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Thu, 27 Jun 2002 13:44:27 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_05312002 Pre-release 2|May 31, 2002) at 06/27/2002 13:54:53 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE176DFF2A0038f9e8a93df938690918c0ABBE176DFF2A003" Content-Disposition: inline Subject: RE: New RFC2518bis draft, LOCK_URL_WITH_NO_PARENT_COLLECTION Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6336 X-Loop: 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__=0ABBE176DFF2A0038f9e8a93df938690918c0ABBE176DFF2A003 Content-type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoN CkkgdGhpbmsgdGhlcmUgaXMgYSB3b3JkIG1pc3NpbmcgaW4gdGhlIG5ldyB0ZXh0LiAgSSBzdXNw ZWN0IGl0J3MgInBhcmVudCINCmFsdGhvdWdoIHRoYXQgYnkgaXRzZWxmIGRvZXNuJ3QgcXVpdGUg Zml0IGVpdGhlci4NCg0KNDA5IChDb25mbGljdCkg4oCTIEEgcmVzb3VyY2UgY2Fubm90IGJlIGNy ZWF0ZWQgYXQgdGhlIGRlc3RpbmF0aW9uIHVudGlsIG9uZQ0Kb3IgbW9yZSBpbnRlcm1lZGlhdGUg W3BhcmVudF0gY29sbGVjdGlvbnMgaGF2ZSBiZWVuIGNyZWF0ZWQuDQoNCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpQaG9uZTogOTE0LTc4NC03NTY5LCAgIGNj amFzb25AdXMuaWJtLmNvbQ== --0__=0ABBE176DFF2A0038f9e8a93df938690918c0ABBE176DFF2A003 Content-type: text/html; charset=UTF-8 Content-Disposition: inline Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHk+DQo8cD5JIHRoaW5rIHRoZXJlIGlzIGEgd29yZCBtaXNzaW5nIGluIHRoZSBu ZXcgdGV4dC4gIEkgc3VzcGVjdCBpdCdzICZxdW90O3BhcmVudCZxdW90OyBhbHRob3VnaCB0aGF0 IGJ5IGl0c2VsZiBkb2Vzbid0IHF1aXRlIGZpdCBlaXRoZXIuPGJyPg0KPGJyPg0KNDA5IChDb25m bGljdCkg4oCTIEEgcmVzb3VyY2UgY2Fubm90IGJlIGNyZWF0ZWQgYXQgdGhlIGRlc3RpbmF0aW9u IHVudGlsIG9uZSBvciBtb3JlIGludGVybWVkaWF0ZSBbcGFyZW50XSBjb2xsZWN0aW9ucyBoYXZl IGJlZW4gY3JlYXRlZC48YnI+DQo8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08YnI+DQpQaG9uZTogOTE0LTc4NC03NTY5LCAgIGNjamFzb25AdXMu aWJtLmNvbTxicj4NCjwvYm9keT48L2h0bWw+ --0__=0ABBE176DFF2A0038f9e8a93df938690918c0ABBE176DFF2A003-- From w3c-dist-auth-request@w3.org Thu Jun 27 15:17: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 PAA10333 for ; Thu, 27 Jun 2002 15:17: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 PAA19456; Thu, 27 Jun 2002 15:16:25 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RJGOD29983; Thu, 27 Jun 2002 15:16:24 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 15:16:24 -0400 (EDT) Resent-Message-Id: <200206271916.g5RJGOD29983@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 g5RJGNw29956 for ; Thu, 27 Jun 2002 15:16:23 -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 PAA19442 for ; Thu, 27 Jun 2002 15:16:23 -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 g5RJFqe8045700 for ; Thu, 27 Jun 2002 15:15: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 g5RJFom93788 for ; Thu, 27 Jun 2002 15:15:50 -0400 To: "Roy T. Fielding" Cc: "'Webdav WG (E-mail)'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Thu, 27 Jun 2002 15:13:02 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_05312002 Pre-release 2|May 31, 2002) at 06/27/2002 15:15:50 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE176DFF4F9218f9e8a93df938690918c0ABBE176DFF4F921" Content-Disposition: inline Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6348 X-Loop: 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__=0ABBE176DFF4F9218f9e8a93df938690918c0ABBE176DFF4F921 Content-type: text/plain; charset=US-ASCII > > 3) A dynamic page is being served at a given URL. The author wants to > > update the implementation of that dynamic resource. Where does he PUT the > > updated implementation? (I think we've answered the basic form of this > > question via the dav:source propety. Questions like whether the update > > will be refelcted immediately can be answered later.) > The dynamic content resource will point to other resources that the client > might be interested in authoring to change the content of both resources. Agreed :-) > If the server is capable of handling PUT on a "dynamic content" resource, > then it may also support direct editing of the resource. Day Software's > products support that kind of editing, but as far as the client is > concerned > it is just performing methods on a WebDAV resource. There is no difference > between the two EXCEPT that there are some circumstances when the client > needs to be encouraged to go elsewhere (such as when the author wishes to > edit a presentation template). The principles are the same. A source > property is merely a mechanism to supply metadata for a relationship > between two or more resources. It's not central to the point of your posting as a whole, but I'll comment on this part. I think you're suggesting that the source property could point at the resource itself. I agree in prinical this can be done, but it does create another issue that we would then want to clarify. Is the source property telling you where you can GET the source... or where you can PUT it. Obviously if you do a GET on the dynamic resource itself, you will not get the source of the implementation. Given your comment, we should probably be clear about that. > > 4) An author wants to no longer serve dynamic content at a specific URL. > > What URL does the author DELETE? > The URL they want to DELETE, which, depending on the implementation, may > result in a suggestion to the author that they need to DELETE some other > resource instead (or as well). Okay. And what is the mechanism for the server to do the "suggesting"? (I assume it's a mechanism that distinguishs between redirects that require user confirmation and those that don't.) > > 6) Make sure the answers to the questions above don't cause problems for > > servers that require explicit client controlled mapping operations. > A server that requires explicit name bindings will naturally require > operations on those bindings that make them explicit. Obviously if it didn't require it this might be yet another advantage to a design. Anyway... I understand that you're saying it's not important in your opinion. > The purpose of the source property is to allow a WebDAV-able resource to > supply information to an authoring client regarding the nature of its > underlying implementation by providing links to other resources that > make up that implementation. That's all. It doesn't need to do anything > more to justify its existence. I'll take it to mean that just supporting 2 & 3 (& possibly 4) is fine with you. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com --0__=0ABBE176DFF4F9218f9e8a93df938690918c0ABBE176DFF4F921 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

> > 3) A dynamic page is being served at a given URL. The author wants to
> > update the implementation of that dynamic resource. Where does he PUT the
> > updated implementation? (I think we've answered the basic form of this
> > question via the dav:source propety. Questions like whether the update
> > will be refelcted immediately can be answered later.)
> The dynamic content resource will point to other resources that the client
> might be interested in authoring to change the content of both resources.

Agreed :-)

> If the server is capable of handling PUT on a "dynamic content" resource,
> then it may also support direct editing of the resource. Day Software's
> products support that kind of editing, but as far as the client is
> concerned
> it is just performing methods on a WebDAV resource. There is no difference
> between the two EXCEPT that there are some circumstances when the client
> needs to be encouraged to go elsewhere (such as when the author wishes to
> edit a presentation template). The principles are the same. A source
> property is merely a mechanism to supply metadata for a relationship
> between two or more resources.

It's not central to the point of your posting as a whole, but I'll comment on
this part. I think you're suggesting that the source property could point at
the resource itself. I agree in prinical this can be done, but it does create
another issue that we would then want to clarify.

Is the source property telling you where you can GET the source... or where you
can PUT it. Obviously if you do a GET on the dynamic resource itself, you will
not get the source of the implementation. Given your comment, we should probably
be clear about that.


> > 4) An author wants to no longer serve dynamic content at a specific URL.
> > What URL does the author DELETE?

> The URL they want to DELETE, which, depending on the implementation, may
> result in a suggestion to the author that they need to DELETE some other
> resource instead (or as well).

Okay. And what is the mechanism for the server to do the "suggesting"? (I
assume it's a mechanism that distinguishs between redirects that require
user confirmation and those that don't.)

> > 6) Make sure the answers to the questions above don't cause problems for
> > servers that require explicit client controlled mapping operations.
> A server that requires explicit name bindings will naturally require
> operations on those bindings that make them explicit.
Obviously if it didn't require it this might be yet another advantage to a
design. Anyway... I understand that you're saying it's not important
in your opinion.

> The purpose of the source property is to allow a WebDAV-able resource to
> supply information to an authoring client regarding the nature of its
> underlying implementation by providing links to other resources that
> make up that implementation. That's all. It doesn't need to do anything
> more to justify its existence.
I'll take it to mean that just supporting 2 & 3 (& possibly 4) is fine with
you.




------------------------------------------
Phone: 914-784-7569, ccjason@us.ibm.com
--0__=0ABBE176DFF4F9218f9e8a93df938690918c0ABBE176DFF4F921-- From w3c-dist-auth-request@w3.org Thu Jun 27 15:36: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 PAA11458 for ; Thu, 27 Jun 2002 15:36: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 PAA24514; Thu, 27 Jun 2002 15:35:59 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RJZwV03633; Thu, 27 Jun 2002 15:35:58 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 15:35:58 -0400 (EDT) Resent-Message-Id: <200206271935.g5RJZwV03633@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 g5RJZvw03613 for ; Thu, 27 Jun 2002 15:35: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 PAA24509 for ; Thu, 27 Jun 2002 15:35:56 -0400 Received: (qmail 14117 invoked by uid 0); 27 Jun 2002 19:35:25 -0000 Received: from p3ee2476f.dip.t-dialin.net (HELO lisa) (62.226.71.111) by mail.gmx.net (mp002-rz3) with SMTP; 27 Jun 2002 19:35:25 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Roy T. Fielding" Cc: "'Webdav WG \(E-mail\)'" Date: Thu, 27 Jun 2002 21:35:24 +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: Importance: Normal Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6350 X-Loop: 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 Jason Crawford >Sent: Thursday, June 27, 2002 9:13 PM >To: Roy T. Fielding >Cc: 'Webdav WG (E-mail)' >Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > > ... >> If the server is capable of handling PUT on a "dynamic content" resource, >> then it may also support direct editing of the resource. Day Software's >> products support that kind of editing, but as far as the client is >> concerned >> it is just performing methods on a WebDAV resource. There is no difference >> between the two EXCEPT that there are some circumstances when the client >> needs to be encouraged to go elsewhere (such as when the author wishes to >> edit a presentation template). The principles are the same. A source >> property is merely a mechanism to supply metadata for a relationship >> between two or more resources. > >It's not central to the point of your posting as a whole, but I'll comment on >this part. I think you're suggesting that the source property could point at >the resource itself. I agree in prinical this can be done, but it does create I don't think he did. >>another issue that we would then want to clarify. > >Is the source property telling you where you can GET the source... or where you >can PUT it. Obviously if you do a GET on the dynamic resource itself, you will >not get the source of the implementation. Given your comment, we should probably >be clear about that. The source property lists sources. It doesn't tell you anything about whether the dynamic resource supports PUT, and what effect that would have. Note also that source resources may be dynamic resources as well. >> > 4) An author wants to no longer serve dynamic content at a specific URL. >> > What URL does the author DELETE? > >> The URL they want to DELETE, which, depending on the implementation, may >> result in a suggestion to the author that they need to DELETE some other >> resource instead (or as well). > >Okay. And what is the mechanism for the server to do the "suggesting"? (I >assume it's a mechanism that distinguishs between redirects that require >user confirmation and those that don't.) Good point. Roy, did you have any specific (existing) mechanism in mind? From w3c-dist-auth-request@w3.org Thu Jun 27 15:37: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 PAA11488 for ; Thu, 27 Jun 2002 15:37: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 PAA24655; Thu, 27 Jun 2002 15:36:42 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RJafM03709; Thu, 27 Jun 2002 15:36:41 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 15:36:41 -0400 (EDT) Resent-Message-Id: <200206271936.g5RJafM03709@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 g5RJaew03689 for ; Thu, 27 Jun 2002 15:36:40 -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 PAA24634 for ; Thu, 27 Jun 2002 15:36:40 -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 g5RJa2e8091264; Thu, 27 Jun 2002 15:36:02 -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 g5RJa0m30216; Thu, 27 Jun 2002 15:36:00 -0400 To: "Julian Reschke" Cc: "Clemm, Geoff" , "'Webdav WG \(E-mail\)'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Thu, 27 Jun 2002 15:26:23 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_05312002 Pre-release 2|May 31, 2002) at 06/27/2002 15:35:59 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE176DFFA75798f9e8a93df938690918c0ABBE176DFFA7579" Content-Disposition: inline Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6351 X-Loop: 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__=0ABBE176DFFA75798f9e8a93df938690918c0ABBE176DFFA7579 Content-type: text/plain; charset=US-ASCII 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 --0__=0ABBE176DFFA75798f9e8a93df938690918c0ABBE176DFFA7579 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

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
--0__=0ABBE176DFFA75798f9e8a93df938690918c0ABBE176DFFA7579-- From w3c-dist-auth-request@w3.org Thu Jun 27 16:20: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 QAA13892 for ; Thu, 27 Jun 2002 16:20: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 PAA21007; Thu, 27 Jun 2002 15:19:04 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RJJ3901991; Thu, 27 Jun 2002 15:19:03 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 15:19:03 -0400 (EDT) Resent-Message-Id: <200206271919.g5RJJ3901991@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 g5RJJ2w01971 for ; Thu, 27 Jun 2002 15:19:02 -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 PAA20992 for ; Thu, 27 Jun 2002 15:18:59 -0400 Received: (qmail 4854 invoked by uid 0); 27 Jun 2002 19:18:23 -0000 Received: from p3ee2476f.dip.t-dialin.net (HELO lisa) (62.226.71.111) by mail.gmx.net (mp013-rz3) with SMTP; 27 Jun 2002 19:18:23 -0000 From: "Julian Reschke" To: Date: Thu, 27 Jun 2002 21:18:22 +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: Importance: Normal Subject: open issues with section 16 (IANA considerations) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6349 X-Loop: 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 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. 2) Replace "...as well as the XML "encoding" attribute..:" by "...as well as XML declarations..." 3) Replace " XML uses either IANA registered language tags (see [RFC1766]) or ISO 639 language tags [ISO-639] in the "xml:lang" attribute of an XML element to identify the language of its content and attributes." by a reference to the appropriate section of the XML spec (no need to repeat the information here, especially not if it's not precise :-). 4) Replace "Similarly, though the names of XML elements used in this specification are English names encoded in UTF-8, these names are not visible to the user, and hence do not need to support multiple character set encodings. " by "XML names used in this specification are always marshalled inside XML request/responses, and thus benefit from XML's encoding support. 5) Replace "The name of a property defined on a resource is a URI. Although some applications (e.g., a generic property viewer) will display property URIs directly to their users, it is expected that the typical application will use a fixed set of properties, and will provide a mapping from the property name URI to a human-readable field when displaying the property name to a user. It is only in the case where the set of properties is not known ahead of time that an application need display a property name URI to a user. We recommend that applications provide human-readable property names wherever feasible." by "WebDAV properties are identified by qualified XML names (pairs of namespace name and local name). Although some applications (e.g., a generic property viewer) will display the property's qualified names directly to their users, it is expected that the typical application will use a fixed set of properties, and will provide a mapping from the qualified name to a human-readable field when displaying the property name to a user. It is only in the case where the set of properties is not known ahead of time that an application need display a property name to a user. We recommend that applications provide human-readable property names wherever feasible." From w3c-dist-auth-request@w3.org Thu Jun 27 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 RAA17300 for ; Thu, 27 Jun 2002 17:29: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 RAA14499; Thu, 27 Jun 2002 17:29:23 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5RLTMh11396; Thu, 27 Jun 2002 17:29:22 -0400 (EDT) Resent-Date: Thu, 27 Jun 2002 17:29:22 -0400 (EDT) Resent-Message-Id: <200206272129.g5RLTMh11396@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 g5RLTKw11372 for ; Thu, 27 Jun 2002 17:29:20 -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 RAA14490 for ; Thu, 27 Jun 2002 17:29:20 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.wakasoft.com (8.12.4/8.12.4) with ESMTP id g5RLMxhZ000753; Thu, 27 Jun 2002 14:23:00 -0700 (PDT) Date: Thu, 27 Jun 2002 14:22:59 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "Jason Crawford" , "'Webdav WG \(E-mail\)'" To: "Julian Reschke" From: "Roy T. Fielding" In-Reply-To: Message-Id: <0E230DA2-8A14-11D6-A329-000393753936@apache.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6352 X-Loop: 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 >>> If the server is capable of handling PUT on a "dynamic content" >>> resource, >>> then it may also support direct editing of the resource. Day Software's >>> products support that kind of editing, but as far as the client is >>> concerned >>> it is just performing methods on a WebDAV resource. There is no >>> difference >>> between the two EXCEPT that there are some circumstances when the client >>> needs to be encouraged to go elsewhere (such as when the author wishes >>> to >>> edit a presentation template). The principles are the same. A source >>> property is merely a mechanism to supply metadata for a relationship >>> between two or more resources. >> >> It's not central to the point of your posting as a whole, but I'll >> comment on >> this part. I think you're suggesting that the source property could >> point at >> the resource itself. I agree in prinical this can be done, but it does >> create > > I don't think he did. No, I was not suggesting that a resource would point to itself as a source -- it already gives that information to the client via the methods allowed on itself. What I was suggesting is that there is no such thing as a resource type. Resources simply allow or do not allow methods, and link to or do not link to other sources. It is a web. The job of the client is to let the author know that this web exists when it encounters a resource with links to sources. >>>> 4) An author wants to no longer serve dynamic content at a specific >>>> URL. >>>> What URL does the author DELETE? >> >>> The URL they want to DELETE, which, depending on the implementation, may >>> result in a suggestion to the author that they need to DELETE some other >>> resource instead (or as well). >> >> Okay. And what is the mechanism for the server to do the "suggesting"? (I >> assume it's a mechanism that distinguishs between redirects that require >> user confirmation and those that don't.) > > Good point. Roy, did you have any specific (existing) mechanism in mind? A redirection. There is no such thing as a redirected DELETE that doesn't require user confirmation. However, if the client accesses a resource using WebDAV and that resource does not allow DELETE and that resource does have a source link, then isn't it reasonable for the client to ask the user if they would really like to delete the source resource instead? Client implementations can figure that one out for themselves. ....Roy From w3c-dist-auth-request@w3.org Fri Jun 28 10:35: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 KAA28585 for ; Fri, 28 Jun 2002 10:35: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 KAA24608; Fri, 28 Jun 2002 10:34:37 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5SEYZJ08700; Fri, 28 Jun 2002 10:34:35 -0400 (EDT) Resent-Date: Fri, 28 Jun 2002 10:34:35 -0400 (EDT) Resent-Message-Id: <200206281434.g5SEYZJ08700@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 g5SEYYw08680 for ; Fri, 28 Jun 2002 10:34: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 KAA24580 for ; Fri, 28 Jun 2002 10:34:33 -0400 Received: (qmail 25148 invoked by uid 0); 28 Jun 2002 14:33:56 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp016-rz3) with SMTP; 28 Jun 2002 14:33:56 -0000 From: "Julian Reschke" To: "'Webdav WG \(E-mail\)'" Date: Fri, 28 Jun 2002 16:33: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) Importance: Normal In-Reply-To: <0E230DA2-8A14-11D6-A329-000393753936@apache.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6353 X-Loop: 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 Roy T. Fielding > Sent: Thursday, June 27, 2002 11:23 PM > To: Julian Reschke > Cc: Jason Crawford; 'Webdav WG (E-mail)' > Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > > .. > > >> Okay. And what is the mechanism for the server to do the > "suggesting"? (I > >> assume it's a mechanism that distinguishs between redirects > that require > >> user confirmation and those that don't.) > > > > Good point. Roy, did you have any specific (existing) mechanism in mind? > > A redirection. There is no such thing as a redirected DELETE that doesn't > require user confirmation. However, if the client accesses a resource > using WebDAV and that resource does not allow DELETE and that resource > does have a source link, then isn't it reasonable for the client to ask > the user if they would really like to delete the source resource instead? > Client implementations can figure that one out for themselves. Granted, but this would only work well if there's only one source resource, right? From w3c-dist-auth-request@w3.org Fri Jun 28 14:18: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 OAA11786 for ; Fri, 28 Jun 2002 14:18: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 OAA06327; Fri, 28 Jun 2002 14:17:26 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5SIHJl29361; Fri, 28 Jun 2002 14:17:19 -0400 (EDT) Resent-Date: Fri, 28 Jun 2002 14:17:19 -0400 (EDT) Resent-Message-Id: <200206281817.g5SIHJl29361@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 g5SIHHw29337 for ; Fri, 28 Jun 2002 14:17:17 -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 OAA06261 for ; Fri, 28 Jun 2002 14:17:17 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.wakasoft.com (8.12.4/8.12.4) with ESMTP id g5SIHuhZ001242; Fri, 28 Jun 2002 11:17:56 -0700 (PDT) Date: Fri, 28 Jun 2002 11:17:56 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "'Webdav WG \(E-mail\)'" To: "Julian Reschke" From: "Roy T. Fielding" In-Reply-To: Message-Id: <5E80DE60-8AC3-11D6-966C-000393753936@apache.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6354 X-Loop: 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 redirection. There is no such thing as a redirected DELETE that doesn' >> t >> require user confirmation. However, if the client accesses a resource >> using WebDAV and that resource does not allow DELETE and that resource >> does have a source link, then isn't it reasonable for the client to ask >> the user if they would really like to delete the source resource instead? >> Client implementations can figure that one out for themselves. > > Granted, but this would only work well if there's only one source > resource, > right? 300 Multiple Choices. ....Roy From w3c-dist-auth-request@w3.org Fri Jun 28 18:53: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 SAA26973 for ; Fri, 28 Jun 2002 18:53: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 SAA01526; Fri, 28 Jun 2002 18:52:30 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5SMobf23290; Fri, 28 Jun 2002 18:50:37 -0400 (EDT) Resent-Date: Fri, 28 Jun 2002 18:50:37 -0400 (EDT) Resent-Message-Id: <200206282250.g5SMobf23290@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 g5SMoaw23269 for ; Fri, 28 Jun 2002 18:50: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 SAA01344 for ; Fri, 28 Jun 2002 18:50:35 -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 g5SMoPi07000 for ; Fri, 28 Jun 2002 15:50:25 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 28 Jun 2002 15:48:58 -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 X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: Re: Collections and Request-URIs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6355 X-Loop: 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. I have added to the accept2 list, so future email from Geoff Alexander will go straight through to the list. Please cc Geoff on your reply, since it's unclear whether he's subscribed to the list. - Jim -----Original Message----- From: Geoff Alexander [mailto:gdlxn@us.ibm.com] Sent: Friday, June 28, 2002 2:44 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Re: Collections and Request-URIs On Mon, 17 Jun 2002 16:45:44 -0700, Jim Luther wrote: RFC 2518, section 5.2 says: "There is a standing convention that when a collection is referred to by its name without a trailing slash, the trailing slash is automatically appended. Due to this, a resource may accept a URI without a trailing "/" to point to a collection. In this case it SHOULD return a content-location header in the response pointing to the URI ending with the "/". For example, if a client invokes a method on http://foo.bar/blah (no trailing slash), the resource http://foo.bar/blah/ (trailing slash) may respond as if the operation were invoked on it, and should return a content-location header with http://foo.bar/blah/ in it. In general clients SHOULD use the "/" form of collection names." We are developing a WebDAV server and have encountered interoperability problem with request on collections in which the resource does not have a trailing slash. Where do things stand on this issue? Our testing indicates that the above does not work in the real world. For example, both IE 5 and Netscape 4.7 do not properly process relative references in response to a GET request on a collection without the trailing slash.. I guess one could say that IE and Netscape only support the HTTP protocol and not WebDAV protocol, but then our server would have to determine whether the request was HTTP or WebDAV (which is not a workable solution). Also, we have encountered interoperability problem with other WebDAV clients. I see three possible solutions: 1. Treat the collection URI with out a trailing slash the same as same URI with a trailing slash and include a Content-Location header with "corrected" URI in the response. 2. Perform a a redirect by sending a 301 Moved Permanently response on safe requests such as GET, HEAD, OPTIONS, and PROPFIND (Where can we find the definitive list of the safe WebDAV and Delta-V safe methods?) and treat a collection URI with out a trailing slash the same as same URI with a trailing slash for unsafe requests. 3. Perform a redirect by sending a 301 Moved Permanently response on all requests. It seems that all of three of the solutions result in interoperability problems with some WebDAV clients. So what is a WebDAV server writer to do? 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 Sun Jun 30 01:10: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 BAA13842 for ; Sun, 30 Jun 2002 01:10: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 BAA06916; Sun, 30 Jun 2002 01:08:29 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5U57R105110; Sun, 30 Jun 2002 01:07:27 -0400 (EDT) Resent-Date: Sun, 30 Jun 2002 01:07:27 -0400 (EDT) Resent-Message-Id: <200206300507.g5U57R105110@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 g5U57Qw05079 for ; Sun, 30 Jun 2002 01:07:26 -0400 (EDT) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA05950 for ; Sun, 30 Jun 2002 01:07:26 -0400 Received: from mail.cruzio.com (mail.cruzio.com [63.249.95.37]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA03026 for ; Sun, 30 Jun 2002 00:15:50 -0400 (EDT) Received: from Tycho (dsl3-63-249-68-7.cruzio.com [63.249.68.7]) by mail.cruzio.com with SMTP id VAA11105 for ; Sat, 29 Jun 2002 21:15:44 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Sat, 29 Jun 2002 21:14:14 -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 Subject: FW: User home directories Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6356 X-Loop: 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: Dan Levy [mailto:danlevy@island.liu.se] Sent: Saturday, June 29, 2002 9:14 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] User home directories Hi all, I'm currently looking in to using some webdav solution to let our users access thier home catalogues on our system. Basically Solaris 8 on ufs disks with user data in yp. Nowing that file sharing via samba and webdav is a bad thing I still would like to give it a try. My questions are: Is this possible? If not will it ever be? Which webserver have this capability? If I run on Apache I will have to run it as root and even then I doubt he will access the files as the logged in user... /Dan Levy Systems Administrator Linköping University From w3c-dist-auth-request@w3.org Sun Jun 30 01:25: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 BAA14064 for ; Sun, 30 Jun 2002 01:25: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 BAA11528; Sun, 30 Jun 2002 01:24:41 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5U5OeI08998; Sun, 30 Jun 2002 01:24:40 -0400 (EDT) Resent-Date: Sun, 30 Jun 2002 01:24:40 -0400 (EDT) Resent-Message-Id: <200206300524.g5U5OeI08998@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 g5U5Obw08978 for ; Sun, 30 Jun 2002 01:24:37 -0400 (EDT) Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.111]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA11515 for ; Sun, 30 Jun 2002 01:24:37 -0400 Received: from e2.ny.us.ibm.com (e2.esmtp.ibm.com [9.14.6.102]) by admin.esmtp.ibm.com (8.12.2/8.12.2) with ESMTP id g5TM6eO0135742 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Sat, 29 Jun 2002 18:06:41 -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 g5TM6Xe8126294; Sat, 29 Jun 2002 18: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 g5TM6Up125848; Sat, 29 Jun 2002 18:06:30 -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: Sat, 29 Jun 2002 18:06:15 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_05312002 Pre-release 2|May 31, 2002) at 06/29/2002 18:06:30 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE174DFEB6FB78f9e8a93df938690918c0ABBE174DFEB6FB7" Content-Disposition: inline Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6357 X-Loop: 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__=0ABBE174DFEB6FB78f9e8a93df938690918c0ABBE174DFEB6FB7 Content-type: text/plain; charset=US-ASCII 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 --0__=0ABBE174DFEB6FB78f9e8a93df938690918c0ABBE174DFEB6FB7 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

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
--0__=0ABBE174DFEB6FB78f9e8a93df938690918c0ABBE174DFEB6FB7-- From w3c-dist-auth-request@w3.org Sun Jun 30 04:09:35 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 EAA25219 for ; Sun, 30 Jun 2002 04:09: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 EAA32127; Sun, 30 Jun 2002 04:08:50 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5U88mW22537; Sun, 30 Jun 2002 04:08:48 -0400 (EDT) Resent-Date: Sun, 30 Jun 2002 04:08:48 -0400 (EDT) Resent-Message-Id: <200206300808.g5U88mW22537@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 g5U88jw22513 for ; Sun, 30 Jun 2002 04:08:45 -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 EAA32110 for ; Sun, 30 Jun 2002 04:08:45 -0400 Received: (qmail 1633 invoked by uid 0); 30 Jun 2002 08:08:13 -0000 Received: from pd950c389.dip.t-dialin.net (HELO lisa) (217.80.195.137) by mail.gmx.net (mp014-rz3) with SMTP; 30 Jun 2002 08:08:13 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Clemm, Geoff" Cc: Date: Sun, 30 Jun 2002 10:08:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6358 X-Loop: 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 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 Jun 30 17:40: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 RAA12239 for ; Sun, 30 Jun 2002 17:40: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 RAA17878; Sun, 30 Jun 2002 17:39:22 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g5ULdFa02183; Sun, 30 Jun 2002 17:39:15 -0400 (EDT) Resent-Date: Sun, 30 Jun 2002 17:39:15 -0400 (EDT) Resent-Message-Id: <200206302139.g5ULdFa02183@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 g5ULdDw02163 for ; Sun, 30 Jun 2002 17:39: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 RAA17867 for ; Sun, 30 Jun 2002 17:39:13 -0400 Received: (qmail 3751 invoked by uid 0); 30 Jun 2002 21:38:41 -0000 Received: from pd950c24c.dip.t-dialin.net (HELO lisa) (217.80.194.76) by mail.gmx.net (mp001-rz3) with SMTP; 30 Jun 2002 21:38:41 -0000 From: "Julian Reschke" To: Date: Sun, 30 Jun 2002 23:39:18 +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: New RFC2518bis draft Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6359 X-Loop: 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 reviewed the changes document and have the following comments/concerns: Section 2.1: Clarification on use of DAV: namespace Replace "...SHOULD NOT be used in the request or response body of a versioning method unless that XML element..." by "...SHOULD NOT be used in the request or response method body unless that XML element..." Maybe we should also state that servers MAY reject attempts to delete or set any property in the DAV: namespace which it doesn't know about. 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. Section 3.2: XML may not be valid Replace "However, legal XML may not be valid according to this DTD, because unknown XML elements may appear in WebDAV syntax without making the syntax illegal." by "However, legal XML will not be valid according to this DTD, because unknown XML elements may appear in WebDAV syntax without making the syntax illegal, and DTDs are fundamentally incompatible with XML namespace processing." 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." Section 3.8: Properties are live/protected Note: will need to add definitions for "live" and "protected" 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. Section 4.3: allprop deprecated STRONG disagreement. May I politely ask to answer my concerns raised in February (). 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? 2) If we did, the wording "octet-by-octet" doesn't make sense (because we're talking of property values) 3) However, I don't think we have agreement on this. Do you really want to get dead copies of ACL or deltaV properties when copying from one part of your server namespace to another????