From w3c-dist-auth-request@w3.org Thu Feb 1 18:58:38 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15015 for ; Thu, 1 Feb 2001 18:58:36 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA23236; Thu, 1 Feb 2001 18:44:26 -0500 (EST) Resent-Date: Thu, 1 Feb 2001 18:44:26 -0500 (EST) Resent-Message-Id: <200102012344.SAA23236@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA23215 for ; Thu, 1 Feb 2001 18:44:22 -0500 (EST) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA15045 for ; Thu, 1 Feb 2001 18:44:17 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id PAA26141 for w3c-dist-auth@w3.org; Thu, 1 Feb 2001 15:45:25 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Thu, 1 Feb 2001 15:45:25 -0800 From: Greg Stein To: w3c-dist-auth@w3.org Message-ID: <20010201154524.B26044@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: [OT] webdav.org sponsorship Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4623 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Hi all, Historically, webdav.org has been hosted at my hosue over a T1 in Washington, and a DSL connection here in California. Last October the DSL went down, and I'm still waiting on PacBell for a new one (don't ask). In the meantime, webdav.org has been running temporarily at an ISP where a friend works. For longer term stability, I've been considering a move of webdav.org to a real hosting facility. I've already had a couple offers for rackspace and bandwidth, but I am missing the hardware. Thus, this query... I'm looking for somebody to sponsor the purchase of a 1U rackmount Linux server. In return, I will gladly place a logo and link from the webdav.org homepage. The link can be to a sponsor page on webdav.org or directly to wherever you'd like. If anybody is interested and would like to discuss this some more, please send me private email at gstein@lyra.org. Thank you, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Feb 5 18:11:49 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20275 for ; Mon, 5 Feb 2001 18:11:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA29495; Mon, 5 Feb 2001 17:50:06 -0500 (EST) Resent-Date: Mon, 5 Feb 2001 17:50:06 -0500 (EST) Resent-Message-Id: <200102052250.RAA29495@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA29472 for ; Mon, 5 Feb 2001 17:50:02 -0500 (EST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA26463 for ; Mon, 5 Feb 2001 17:50:01 -0500 Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Feb 2001 14:49:26 -0800 (Pacific Standard Time) Received: by inet-imc-02.redmond.corp.microsoft.com with Internet Mail Service (5.5.2653.19) id <1DHDJB5P>; Mon, 5 Feb 2001 14:49:25 -0800 Message-ID: <24A715275661C8428C00432EFCA5CB7C13C64E@red-msg-02.redmond.corp.microsoft.com> From: Brian Morin To: "'w3c-dist-auth@w3.org'" Date: Mon, 5 Feb 2001 14:49:18 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: Question for the XML gurus Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4624 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: We recently tried to load the IIS 5.0 response text to a propfind in MSXML and had trouble parsing the getlastmodified property. It appears that MSXML does not accept "dateTime.rfc1123" as a legal value for the attribute "b:dt" where b="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/". Changing dt attribute to the dav namespace seemed to fixed the problem (would you do this since dateTime.rfc1123 was a DAV data type and not under defined under the b namespace?.) Is the problem the way IIS 5.0 is representing the date format? Is there a more correct way? and/or Is the problem that MSXML doesn't understand the "dateTime.rfc1123" format? Should it? Here is a abreviated dump of the request and response in question: PROPFIND /dav HTTP/1.1 Content-Type: text/xml Depth: 1 Content-Length: 489 User-Agent: Microsoft Data Access Internet Publishing Provider DAV Host: bmorin5 Connection: Keep-Alive HTTP/1.1 207 Multi-Status Server: Microsoft-IIS/5.0 Date: Mon, 05 Feb 2001 21:33:52 GMT Content-Location: http://bmorin5/dav/ Content-Type: text/xml Transfer-Encoding: chunked http://bmorin5/dav/ HTTP/1.1 200 OK 0 application/octet-stream 2000-03-31T02:48:03.598Z Thu, 31 Aug 2000 20:57:45 GMT 0 1 dav .... Thanks, Brian Morin Development Lead .NET Services From w3c-dist-auth-request@w3.org Tue Feb 6 22:15:19 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA08831 for ; Tue, 6 Feb 2001 22:15:18 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA08018; Tue, 6 Feb 2001 22:05:18 -0500 (EST) Resent-Date: Tue, 6 Feb 2001 22:05:18 -0500 (EST) Resent-Message-Id: <200102070305.WAA08018@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA07976 for ; Tue, 6 Feb 2001 22:05:12 -0500 (EST) Received: from shell.tsoft.com (root@shell.tsoft.com [198.144.192.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA20322; Tue, 6 Feb 2001 22:05:11 -0500 Received: from BEAVER (m206-141.dsl.tsoft.com [198.144.206.141]) by shell.tsoft.com (8.8.7/8.8.7) with SMTP id TAA03661; Tue, 6 Feb 2001 19:05:09 -0800 (PST) Reply-To: From: "Lisa Dusseault" To: "W3c-Dist-Auth@W3. Org" Cc: "Ietf-Dav-Versioning@W3. Org" Date: Tue, 6 Feb 2001 19:04:17 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Properties, ETags and versions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4625 X-Loop: w3c-dist-auth@w3.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 never seen a clear resolution on whether property changes ought to result in ETag changes or not, although it's been discussed in the past on and off the main list. This is really a core WebDAV issue, but I'm cc'ing the versioning list because the versioning model seems to suggest a particular model. First I'll tediously recap all the various arguments I've heard/used so far... jump to the conclusions if you wish! Arguments for changing ETag when properties change -------------------------------------------------- In versioning, when any of the regular dead properties of a resource change, a new version is created. Thus, a new version might have exactly the same body as the previous version, only one or more property value is changed. This suggests that at least some properties are considered part of the resource itself. More strongly, it pretty well forces the ETag to change, doesn't it? Um, or does it? What about the Etag on the VCR, anyway? The implementation architecture argument: a server may store properties inside the file which also contains the resource body, and use information about this file (e.g. last-changed stamp) to create the ETag. This kind of architecture does not easily allow the ETag to remain the same when the properties change. The sophisticated WebDAV client argument: for sophisticated WebDAV clients that do something like backup or replication, and care very much about properties, there's currently no way to tell if the property set has changed. It would be desirable for this kind of client if some kind of indication changed, so that the client could tell when it's not necessary to download properties at all (in most backup/replication scenarios, no changes at all is the common case, so it makes sense to optimise). Arguments for keeping ETag same when properties change ------------------------------------------------------ Frequently-changing properties argument: It's pretty clear that one could define resource properties which should NOT result in the ETag changing. E.g. a custom calculated property like "last-accessed-date" or "last-accessed-by" should not result in a change in the Etag every time the resource is accessed. So maybe it's easier not to change the ETag for any property changes. The principle of 'least surprise' and efficiency for existing HTTP clients: Since many WebDAV resources seem to be widely accessed by HTTP clients, it would be a shame to force them to download a new body for a WebDAV resource if only the properties change. The HTTP client expects the body to change when the ETag changes, and performs unnecessary work if the ETag changes when the body does not. This argument also holds true for the bulk of existing WebDAV clients which, as far as I can tell, do not store properties locally and thus are more efficient if the ETag stays the same when properties change. In other words, most existing WebDAV clients don't care about knowing when properties change. The precedent argument: Neither xythos nor mod_dav changes the etag when it gets a PROPPATCH. I don't know about other servers. The implementation architecture argument, from the opposite side: a server may store properties somewhere outside the file, and use the file information (e.g. last-changed stamp) to create the ETag. This kind of architecture does not easily allow the ETag to change when the properties change. Arguments for doing nothing --------------------------- Implementations have already done one thing or the other. It's too late. The most we could require of servers would be something like "SHOULD NOT" change the etag, or maybe even weaker. Arguments for doing Something ----------------------------- Clients should at least be able to tell whether they can count on the ETag changing when properties change. Conclusions ----------- My suggestion is to add a _client_ requirement to the WebDAV proposed standard when it gets updated. E.g. "WebDAV clients MUST NOT rely on the ETag changing in order to know when properties on the resource have changed." This is a pretty conservative suggestion, since it's pretty clear when looking at existing WebDAV server implementations, that clients can't rely on the ETag changing when props change anyway. Putting such a statement in the spec just makes it clear, and avoids client developers having to test various servers to try to find out, or making poor assumptions. Given this, I don't think it's necessary to make any requirement on servers. Servers are free to do whatever is most efficient or easiest, as long as the ETag changes in the way required by RFC2616. Versioning may want to address this issue separately. Since changing dead properties creates a new version, I would assume the ETag would change. A regular HTTP client doing a GET on such a VCR would see a new ETag even if the body has not changed. However, my assumption may be wrong, thus, please clarify in DeltaV! If clients need to know reliably when properties _do_ change (backup and replication scenarios come to mind), we could get together and invent some kind of ETag-analog for properties. I'd be interested in this kind of feature, but I don't expect it's within the scope of any work currently being undertaken by the working groups. Lisa Dusseault From w3c-dist-auth-request@w3.org Wed Feb 7 15:28:50 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08270 for ; Wed, 7 Feb 2001 15:28:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA16443; Wed, 7 Feb 2001 15:18:45 -0500 (EST) Resent-Date: Wed, 7 Feb 2001 15:18:45 -0500 (EST) Resent-Message-Id: <200102072018.PAA16443@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA16423 for ; Wed, 7 Feb 2001 15:18:41 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA16698 for ; Wed, 7 Feb 2001 15:18:41 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA29507 for ; Wed, 7 Feb 2001 12:18:45 -0800 (PST) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 7 Feb 2001 12:18:00 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: WebDAV WG meeting at Minneapolis IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4626 X-Loop: w3c-dist-auth@w3.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 Working Group will be holding a meeting at the Minneapolis IETF meeting, IETF-50. The week of the meeting is March 18-23, 2001, and we do not yet currently know the specific day of the WebDAV meeting. Registration and hotel information can be found on the IETF Web site, at: http://www.ietf.org/meetings/IETF-50.html From past experience, you *definitely* want to be in a hotel connected to the walkway system ;-) - Jim From w3c-dist-auth-request@w3.org Wed Feb 7 15:34:23 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08335 for ; Wed, 7 Feb 2001 15:34:22 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA16601; Wed, 7 Feb 2001 15:23:55 -0500 (EST) Resent-Date: Wed, 7 Feb 2001 15:23:55 -0500 (EST) Resent-Message-Id: <200102072023.PAA16601@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA16571 for ; Wed, 7 Feb 2001 15:23:51 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA17275 for ; Wed, 7 Feb 2001 15:23:51 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA01089 for ; Wed, 7 Feb 2001 12:23:55 -0800 (PST) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 7 Feb 2001 12:23:10 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: IETF-50 I-D submission deadline Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4627 X-Loop: w3c-dist-auth@w3.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 deadline for submission of Internet-Drafts for consideration at the IETF-50 meeting in Minneapolis is 23 February at 5pm EST. - Jim From w3c-dist-auth-request@w3.org Wed Feb 7 15:58:45 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08636 for ; Wed, 7 Feb 2001 15:58:44 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA17398; Wed, 7 Feb 2001 15:46:07 -0500 (EST) Resent-Date: Wed, 7 Feb 2001 15:46:07 -0500 (EST) Resent-Message-Id: <200102072046.PAA17398@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA17361 for ; Wed, 7 Feb 2001 15:45:57 -0500 (EST) Received: from localhost.localdomain ([216.52.68.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA19186; Wed, 7 Feb 2001 15:45:55 -0500 Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f17Kpbk08089; Wed, 7 Feb 2001 15:51:37 -0500 Message-ID: <3A81B558.3CAE7BCA@ecal.com> Date: Wed, 07 Feb 2001 15:51:36 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: "W3c-Dist-Auth@W3. Org" CC: "Ietf-Dav-Versioning@W3. Org" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Properties, ETags and versions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4628 X-Loop: w3c-dist-auth@w3.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 Dusseault wrote: > Versioning may want to address this issue separately. Since changing > dead properties creates a new version, I would assume the ETag would > change. A regular HTTP client doing a GET on such a VCR would see a new > ETag even if the body has not changed. ...which is probably a Bad Thing, since ETags are used for cache validation. What's worse, a little extra complication for the people editing the site or a lot of extra load for the servers as people read the site? -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |You! Out of the gene pool! | |francis@ecal.com| | \==============================================================/ From w3c-dist-auth-request@w3.org Sat Feb 10 00:45:33 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10498 for ; Sat, 10 Feb 2001 00:45:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA05299; Sat, 10 Feb 2001 00:34:48 -0500 (EST) Resent-Date: Sat, 10 Feb 2001 00:34:48 -0500 (EST) Resent-Message-Id: <200102100534.AAA05299@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA05278 for ; Sat, 10 Feb 2001 00:34:39 -0500 (EST) 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 AAA29811 for ; Sat, 10 Feb 2001 00:34:39 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id AAA120836 for ; Sat, 10 Feb 2001 00:33:02 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id AAA170548 for ; Sat, 10 Feb 2001 00:30:32 -0500 Importance: Normal To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Sat, 10 Feb 2001 00:25:24 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.6a |January 17, 2001) at 02/10/2001 12:34:02 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Properties, ETags and versions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4629 X-Loop: w3c-dist-auth@w3.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 response to Lisa and John's note... http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0052.html http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0055.html I tend to agree with Lisa and John. Just to reiterate another way... We should probably treat GET etags as denoting changes in the result of response to a GET. In the case of a live/dynamic resource... we'd still follow this rule. Such a resource has two URL's. One to access the source code of the resource and another to access the product/output of the resource. I would suggest that each URL treat the ETag in a way that is consistant with the GET response for that URL. -- I'm not sure if I want to suggest this for the getetag property though. Different values depending on what URL you are using? As Lisa said... someone can make a proposal for properties that goes beyond this. I can imagine all kinds of innovative stuff, but I would recommend that be defered until WebDAV ver 2. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Sat Feb 10 05:25:25 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA24976 for ; Sat, 10 Feb 2001 05:25:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA09837; Sat, 10 Feb 2001 05:07:34 -0500 (EST) Resent-Date: Sat, 10 Feb 2001 05:07:34 -0500 (EST) Resent-Message-Id: <200102101007.FAA09837@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA09817 for ; Sat, 10 Feb 2001 05:07:26 -0500 (EST) 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 FAA14161 for ; Sat, 10 Feb 2001 05:07:23 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id CAA31603; Sat, 10 Feb 2001 02:09:06 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Sat, 10 Feb 2001 02:09:06 -0800 From: Greg Stein To: Dennis Craig , dav-dev@lyra.org Cc: w3c-dist-auth@w3.org Message-ID: <20010210020906.H26044@lyra.org> Mail-Followup-To: Dennis Craig , dav-dev@lyra.org, w3c-dist-auth@w3.org References: <3A84C4C6.C5005E9C@ultradns.com> <3A84EF26.5065A7B7@ics.uci.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3A84EF26.5065A7B7@ics.uci.edu>; from jfeise@ics.uci.edu on Fri, Feb 09, 2001 at 11:35:02PM -0800 X-URL: http://www.lyra.org/greg/ Subject: Re: [dav-dev] Ampersands in file problem using win2k Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4630 X-Loop: w3c-dist-auth@w3.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 Fri, Feb 09, 2001 at 11:35:02PM -0800, Joachim Feise wrote: > Dennis Craig wrote: > > > > Has anyone experienced truncating of filenames when viewing files though > > win2k web folders? > > > > A user has a filename with an ampersand on the server and windows > > truncates it all the way to the ampersand. > > > > ex: file on server: my_dog_&_cat.txt > > file on windows: my_dog_ > > > > Hence the above is seen as an unknown file type and theres also a file > > not found error when any manipulation of that file is attempted. > > This seems to be a problem with the Microsoft XML parser. > I get a similar problem in DAV Explorer, which uses an early version of > the MS parser. > It seems that the parser doesn't like the & which the server sends. > Running DAV Explorer in the debugger, I actually get two tags, one with > the part before the ampersand, the other one with the part following it. I was about to ask "which server are you talking to?" because I knew mod_dav returned the values appropriately. Didn't figure on a client problem :-) The other possibility is that I'm mistaken in assuming that & is the correct substitution for an ampersand in an element. I could see an argument being made that the URL should be encoded using %26 for the ampersand. I'm copying the main WebDAV mailing list for feedback on this point. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Feb 12 11:55:36 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14693 for ; Mon, 12 Feb 2001 11:55:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA19149; Mon, 12 Feb 2001 11:41:51 -0500 (EST) Resent-Date: Mon, 12 Feb 2001 11:41:51 -0500 (EST) Resent-Message-Id: <200102121641.LAA19149@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA19122 for ; Mon, 12 Feb 2001 11:41:40 -0500 (EST) Received: from localhost.localdomain ([216.52.68.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA12050 for ; Mon, 12 Feb 2001 11:41:39 -0500 Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f1CGlOG29133; Mon, 12 Feb 2001 11:47:24 -0500 Message-ID: <3A88139A.1CD24AF8@ecal.com> Date: Mon, 12 Feb 2001 11:47:22 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: w3c-dist-auth@w3.org CC: dav-dev@lyra.org References: <3A84C4C6.C5005E9C@ultradns.com> <3A84EF26.5065A7B7@ics.uci.edu> <20010210020906.H26044@lyra.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dav-dev] Ampersands in file problem using win2k Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4631 X-Loop: w3c-dist-auth@w3.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 Greg Stein wrote: > The other possibility is that I'm mistaken in assuming that & is the > correct substitution for an ampersand in an element. I could see an > argument being made that the URL should be encoded using %26 for the > ampersand. That sounds worth a try, at least, since HTTP URLs generally don't have & in the filename part of the URL. Using the & encoding means that it'll be protected from the XML parser, but then the application will see an & in the filename. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |I'm not imaginary. I'm ontologically challenged.| |francis@ecal.com| | \=================================================================/ From w3c-dist-auth-request@w3.org Tue Feb 13 17:52:55 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02126 for ; Tue, 13 Feb 2001 17:52:52 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA02080; Tue, 13 Feb 2001 17:36:14 -0500 (EST) Resent-Date: Tue, 13 Feb 2001 17:36:14 -0500 (EST) Resent-Message-Id: <200102132236.RAA02080@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA02056 for ; Tue, 13 Feb 2001 17:36:09 -0500 (EST) Received: from andora.wiggenout.com ([216.102.212.250]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA18343 for ; Tue, 13 Feb 2001 17:36:03 -0500 Received: from lyta ([192.168.0.3]) by andora.wiggenout.com (8.9.3/8.8.7) with SMTP id PAA17733 for ; Tue, 13 Feb 2001 15:48:56 -0800 From: "Kevin Wiggen" To: Date: Tue, 13 Feb 2001 14:36:10 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: OPTIONS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4632 X-Loop: w3c-dist-auth@w3.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 Another from the line of "null resource" vrs "lock null resource" vrs a "resource". While implementing OPTIONS and PUT (with LOCKS) a few things need to be specified in 2518. The problem is handling requests to resources that don't exist. The following are some use-cases: 1) /foo is a directory with no contents. OPTIONS to /foo returns a 200 with the appropriate headers OPTIONS to /foo/bar returns?? 200 or 404?? OPTIONS to /foo/bar/fee returns a 404 2) /foo is a directory with no contents and is locked depth infinity PUT to /foo/bar, does this require a tagged list for the lock token specifying /foo or will un untagged list work as well. Yes I have raised number 2 before. I think the key here is whether or not a "null resource" is considered an entity on the server or not. Since OPTIONS in 2068 states "the OPTIONS request applies only to the options that are available when communicating with that resource." Thus to get a 200 response a resource must exist!!! Is the intent of 2518 to create "lock null resources" AND "null resources" where the "null resource" is defined as a resource that does not exist but the parent does???? Thus OPTIONS and LOCKS work differently than if a "null resource" is not a real resource and thus simply returns 404 to Webdav requests. Thoughts?? Kevin From w3c-dist-auth-request@w3.org Tue Feb 13 18:51:01 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02840 for ; Tue, 13 Feb 2001 18:50:58 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA06022; Tue, 13 Feb 2001 18:41:13 -0500 (EST) Resent-Date: Tue, 13 Feb 2001 18:41:13 -0500 (EST) Resent-Message-Id: <200102132341.SAA06022@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA06002 for ; Tue, 13 Feb 2001 18:41:09 -0500 (EST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA23999 for ; Tue, 13 Feb 2001 18:41:09 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA161624; Tue, 13 Feb 2001 18:40:04 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id SAA65868; Tue, 13 Feb 2001 18:37:29 -0500 Importance: Normal To: "Kevin Wiggen" Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Tue, 13 Feb 2001 18:39:29 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.6a |January 17, 2001) at 02/13/2001 06:41:05 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: lock tagging Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4633 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I'm going to leave item (1) from Kevin's post for another thread. I do have an opinion on (2)... << 2) /foo is a directory with no contents and is locked depth infinity PUT to /foo/bar, does this require a tagged list for the lock token specifying /foo or will un untagged list work as well. >> My preference is for the server to ignore the URL provided with the lock token in the tagged IF header. Although I can dream up a case where it is valuable to correctly specify at what URL a lock is located, I think for the most part the server just needs to verify that the client has the lock token for all the locks that come into play for the requested operation. I might change my mind on the above statement in a few weeks after digging though the spec again, but I think that if we disagree with what I said above, we need to clearly define the scenarios where URL checking is important and then clearly define the semantics of the URL checking to match that. But at the moment, I don't see URL verification as important. Other opinions? J. From w3c-dist-auth-request@w3.org Wed Feb 14 09:59:16 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00986 for ; Wed, 14 Feb 2001 09:59:16 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA06596; Wed, 14 Feb 2001 09:49:05 -0500 (EST) Resent-Date: Wed, 14 Feb 2001 09:49:05 -0500 (EST) Resent-Message-Id: <200102141449.JAA06596@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA06558 for ; Wed, 14 Feb 2001 09:49:01 -0500 (EST) Received: from outside (e23.nc.us.ibm.com [32.97.136.229]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA32611 for ; Wed, 14 Feb 2001 09:49:00 -0500 Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208]) by outside (8.9.3/8.9.3) with ESMTP id JAA10846 for ; Wed, 14 Feb 2001 09:43:29 -0600 Received: from d04nm303.raleigh.ibm.com (d04nm203.raleigh.ibm.com [9.67.228.40]) by southrelay01.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id JAA44310 for ; Wed, 14 Feb 2001 09:48:57 -0500 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Jim Amsden" Date: Wed, 14 Feb 2001 09:44:51 -0500 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 02/14/2001 09:48:58 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: lock tagging Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4634 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: 2) /foo is a directory with no contents and is locked depth infinity PUT to /foo/bar, does this require a tagged list for the lock token specifying /foo or will un untagged list work as well. The lock token is required because /foo is locked, and PUT to /foo/bar adds a new member. It doesn't matter if the collection is empty or not, depth infinity or not. Depth infinity only means that /foo/bar inherits the lock. The tag list is only needed if the request must provide different lock tokens for more than one resource. In this case, only /foo needs a lock token, so an untagged list will work too. From w3c-dist-auth-request@w3.org Wed Feb 14 14:19:31 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13678 for ; Wed, 14 Feb 2001 14:19:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA12345; Wed, 14 Feb 2001 14:06:44 -0500 (EST) Resent-Date: Wed, 14 Feb 2001 14:06:44 -0500 (EST) Resent-Message-Id: <200102141906.OAA12345@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA12325 for ; Wed, 14 Feb 2001 14:06:39 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA32764 for ; Wed, 14 Feb 2001 14:06:39 -0500 Received: from Tycho (dhcp-55-180.cse.ucsc.edu [128.114.55.180]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id LAA04813 for ; Wed, 14 Feb 2001 11:06:38 -0800 (PST) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 14 Feb 2001 11:05:48 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FW: Copying a file from local computer to the server Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4636 X-Loop: w3c-dist-auth@w3.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 sent to the -request address. - Jim -----Original Message----- From: El?bieta Angielska [mailto:Elzbieta.Angielska@rodan.pl] Sent: Wednesday, February 14, 2001 6:46 AM To: w3c-dist-auth-request@w3.org Subject: Copying a file from local computer to the server Hi, I'm building an internet application using jsp and servlets on IBM WebSphere v3.5 with IBM HTTP Server and mod_dav. In this application the user has a form in the browser, she enters a path to the file on her local computer and some data describing this file. What I need to do on submit action is to send the data from the form and copy attached file from the local computer to the proper directory on the server. Does anyone have a piece of code in java doing anything like that? I'm not even sure if mod_dav enables copying file from the local computer to the server. I know, that there is something like DAV4J, and it includes some java api to web_dav operations, but as far as I know it works only on nt. How to use mod_dav in servlets? Thanks in advance for any answers. Ela From w3c-dist-auth-request@w3.org Wed Feb 14 14:33:48 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14174 for ; Wed, 14 Feb 2001 14:33:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA12973; Wed, 14 Feb 2001 14:23:46 -0500 (EST) Resent-Date: Wed, 14 Feb 2001 14:23:46 -0500 (EST) Resent-Message-Id: <200102141923.OAA12973@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA12953 for ; Wed, 14 Feb 2001 14:23:38 -0500 (EST) Received: from localhost.localdomain (thibault.org [207.8.144.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA01981 for ; Wed, 14 Feb 2001 14:23:37 -0500 Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f1EJSnh03867; Wed, 14 Feb 2001 14:28:50 -0500 Message-ID: <3A8ADC71.CD51D317@ecal.com> Date: Wed, 14 Feb 2001 14:28:49 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: Elzbieta.Angielska@rodan.pl CC: WebDAV WG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: FW: Copying a file from local computer to the server Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4637 X-Loop: w3c-dist-auth@w3.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 Whitehead wrote: > In this application the user has a form in the browser, she enters a > path to the file on her local computer and some data describing this > file. > What I need to do on submit action is to send the data from the form and > copy attached file from the local computer to the proper directory on > the server. You don't need (client-side) Java or DAV for this; you just need form-based file upload. http://developer.netscape.com/docs/manuals/htmlguid/tags10.htm#1312487 -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Due to circumstances beyond your control, you| |francis@ecal.com|are master of your fate, and captain of your | | |soul. | \==============================================================/ From w3c-dist-auth-request@w3.org Wed Feb 14 15:08:20 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15377 for ; Wed, 14 Feb 2001 15:08:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA11042; Wed, 14 Feb 2001 10:55:14 -0500 (EST) Resent-Date: Wed, 14 Feb 2001 10:55:14 -0500 (EST) Resent-Message-Id: <200102141555.KAA11042@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA11009 for ; Wed, 14 Feb 2001 10:55:04 -0500 (EST) Received: from localhost.localdomain (thibault.org [207.8.144.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA09933 for ; Wed, 14 Feb 2001 10:55:04 -0500 Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f1EG0Qh02499 for ; Wed, 14 Feb 2001 11:00:26 -0500 Message-ID: <3A8AAB99.D245DFB7@ecal.com> Date: Wed, 14 Feb 2001 11:00:25 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: OPTIONS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4635 X-Loop: w3c-dist-auth@w3.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 Kevin Wiggen wrote: > 1) /foo is a directory with no contents. > OPTIONS to /foo returns a 200 with the appropriate headers > OPTIONS to /foo/bar returns?? 200 or 404?? > OPTIONS to /foo/bar/fee returns a 404 [...] > Since OPTIONS > in 2068 (Side note: you want 2616, which obsoletes 2068.) > states "the OPTIONS request applies only to the options that are > available when communicating with that resource." Thus to get a 200 > response a resource must exist!!! Well, let's see. Consider PUT, for example; obviously, you can PUT to a resource which does not exist (in the sense that GET would return 404). Therefore, it is useful for OPTIONS to be able to tell you that PUT is allowed on that resource. ...OK, let's see. Running against Apache, if I do OPTIONS against a non-existent resource (in a non-existent directory), I get a 200, with the expected data. GET against the same resource returns 404; SMURF against that resource returns 405. To me, this seems reasonable. I believe that *all* resources exist. A resource is an object whose methods are HTTP methods; you can issue an HTTP method against any Request-URI in the server's namespace; the server will respond. By definition, the response is the result of that object's method. Therefore, there is an object named by that Request-URI. Note that 2616, section 10.4.5, defines 404 as meaning, "The server has not found anything matching the Request-URI". This is *not* the same as saying that the specified resource does not exist. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"Call me a Nervous Nellie, but I am concerned| |francis@ecal.com|about the sale of nuclear arms in my general | | |neighborhood." -- Dave Barry | \==============================================================/ From w3c-dist-auth-request@w3.org Fri Feb 16 23:13:09 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16168 for ; Fri, 16 Feb 2001 23:13:08 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA27076; Fri, 16 Feb 2001 23:02:45 -0500 (EST) Resent-Date: Fri, 16 Feb 2001 23:02:45 -0500 (EST) Resent-Message-Id: <200102170402.XAA27076@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA27052 for ; Fri, 16 Feb 2001 23:02:35 -0500 (EST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA19098 for ; Fri, 16 Feb 2001 23:02:34 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id XAA287490 for ; Fri, 16 Feb 2001 23:01:25 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id WAA50058 for ; Fri, 16 Feb 2001 22:58:47 -0500 Importance: Normal To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Fri, 16 Feb 2001 21:59:51 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.6a |January 17, 2001) at 02/16/2001 11:02:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: OPTIONS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4638 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: See Kevin's note below. Does anyone have a client that depends on individual resource (including null resources) to return different values for the OPTIONS method? Does anyone have a client that has *any* expectations for what the OPTIONS method returns that might be URI specific or that alternately assumes that what is true for one resource is true for some others? Does anyone have a server that would be unduly burdened by needing to return URI specific results to OPTIONS requests? I'll modify the spec accordingly, but I need people to speak up if they would be negatively impacted if the spec took any particular stance on this. (If your answer to this is that you don't use OPTIONS, then just reply to me directly and I'll sumarize for later.) Thanks, J. "Kevin Wiggen" (by way of "Ralph R. Swick" )@w3.org on 02/15/2001 12:49:18 AM Sent by: ietf-dav-versioning-request@w3.org To: ietf-dav-versioning@w3.org cc: Subject: RE: OPTIONS [freed from spam trap -rrs] Date: Wed, 14 Feb 2001 21:51:47 -0500 (EST) From: "Kevin Wiggen" To: "John Stracke" Cc: , Message-ID: Subject: [Moderator Action] RE: OPTIONS The real question on OPTIONS is now, should a server be sending back a different OPTIONS answer per resource. In other words, does a server look at the resource that has been requested and answer appropriately. I am CCing the DeltaV group as I have been told this is exactly what they are proposing. Thus an "intelligent" options request could look that a resource is not a directory and thus return: Allow: GET, HEAD, POST, OPTIONS, TRACE, PROPFIND, COPY, SEARCH, PROPPATCH, LOCK, UNLOCK, PUT, DELELTE, MOVE notice no MKCOL If we are going to make OPTIONS useful to all clients, 2518 should define it a MUST for a server to return an intelligent OPTIONS response, otherwise a client will never be able to depend on the information. Some Apache Examples: OPTIONS on any resource (existent or not) on Apache returns a 200 with a Allow: GET, HEAD, OPTIONS, TRACE Thus one could argue that following suit, a Webdav server for any resource (existent or not) could respond: Allow: GET, HEAD, POST, OPTIONS, TRACE, PROPFIND, COPY, SEARCH, PROPPATCH, LOCK, UNLOCK, MKCOL, PUT, DELETE, MOVE Should Webdav 2518 state that a server MUST not do the above but intelligently respond to an OPTIONS request? If servers are then required to respond intelligently, what does that mean? Does an OPTIONS to a non-existent resource without a parent simply return: Allow: OPTIONS Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of John Stracke Sent: Wednesday, February 14, 2001 8:00 AM To: w3c-dist-auth@w3.org Subject: Re: OPTIONS Kevin Wiggen wrote: > 1) /foo is a directory with no contents. > OPTIONS to /foo returns a 200 with the appropriate headers > OPTIONS to /foo/bar returns?? 200 or 404?? > OPTIONS to /foo/bar/fee returns a 404 [...] > Since OPTIONS > in 2068 (Side note: you want 2616, which obsoletes 2068.) > states "the OPTIONS request applies only to the options that are > available when communicating with that resource." Thus to get a 200 > response a resource must exist!!! Well, let's see. Consider PUT, for example; obviously, you can PUT to a resource which does not exist (in the sense that GET would return 404). Therefore, it is useful for OPTIONS to be able to tell you that PUT is allowed on that resource. ...OK, let's see. Running against Apache, if I do OPTIONS against a non-existent resource (in a non-existent directory), I get a 200, with the expected data. GET against the same resource returns 404; SMURF against that resource returns 405. To me, this seems reasonable. I believe that *all* resources exist. A resource is an object whose methods are HTTP methods; you can issue an HTTP method against any Request-URI in the server's namespace; the server will respond. By definition, the response is the result of that object's method. Therefore, there is an object named by that Request-URI. Note that 2616, section 10.4.5, defines 404 as meaning, "The server has not found anything matching the Request-URI". This is *not* the same as saying that the specified resource does not exist. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"Call me a Nervous Nellie, but I am concerned| |francis@ecal.com|about the sale of nuclear arms in my general | | |neighborhood." -- Dave Barry | \==============================================================/ From w3c-dist-auth-request@w3.org Sat Feb 17 00:03:51 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16937 for ; Sat, 17 Feb 2001 00:03:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA27722; Fri, 16 Feb 2001 23:51:39 -0500 (EST) Resent-Date: Fri, 16 Feb 2001 23:51:39 -0500 (EST) Resent-Message-Id: <200102170451.XAA27722@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA27688 for ; Fri, 16 Feb 2001 23:51:29 -0500 (EST) Received: from shell.tsoft.com (root@shell.tsoft.com [198.144.192.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA22013; Fri, 16 Feb 2001 23:51:27 -0500 Received: from BEAVER (m206-141.dsl.tsoft.com [198.144.206.141]) by shell.tsoft.com (8.8.7/8.8.7) with SMTP id UAA02650; Fri, 16 Feb 2001 20:51:20 -0800 (PST) Reply-To: From: "Lisa Dusseault" To: "Jason Crawford" , , "Ietf-Dav-Versioning@W3. Org" Date: Fri, 16 Feb 2001 20:50:24 -0800 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: OPTIONS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4639 X-Loop: w3c-dist-auth@w3.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 versioning draft specifies extremely case-by-case response to OPTIONS. I think the OPTIONS response in DeltaV can even vary depending on the state of a resource at one point in time vs. another. E.g. if a resource can be turned into a "version-controlled resource", then OPTIONS should show the VERSION-CONTROL method, to indicate that it can be converted. Obviously that kind of design presupposes that OPTIONS depends on precisely what resource is named in the URL. lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Friday, February 16, 2001 7:00 PM > To: w3c-dist-auth@w3.org > Subject: RE: OPTIONS > > > > > > See Kevin's note below. > > Does anyone have a client that depends on individual resource > (including > null resources) to return different values for the OPTIONS method? > > Does anyone have a client that has *any* expectations for > what the OPTIONS > method returns that might be URI specific or that alternately > assumes that > what is true for one resource is true for some others? > > Does anyone have a server that would be unduly burdened by needing to > return URI specific results to OPTIONS requests? > > I'll modify the spec accordingly, but I need people to speak > up if they > would be negatively impacted if the spec took any particular stance on > this. (If your answer to this is that you don't use > OPTIONS, then just > reply to me directly and I'll sumarize for later.) > > Thanks, > > J. > > > > "Kevin Wiggen" (by way of "Ralph R. Swick" > )@w3.org on 02/15/2001 12:49:18 AM > > Sent by: ietf-dav-versioning-request@w3.org > > > To: ietf-dav-versioning@w3.org > cc: > Subject: RE: OPTIONS > > > > [freed from spam trap -rrs] > > Date: Wed, 14 Feb 2001 21:51:47 -0500 (EST) > From: "Kevin Wiggen" > To: "John Stracke" > Cc: , > Message-ID: > Subject: [Moderator Action] RE: OPTIONS > > The real question on OPTIONS is now, should a server be sending back a > different OPTIONS answer per resource. In other words, does > a server look > at the resource that has been requested and answer > appropriately. I am > CCing the DeltaV group as I have been told this is exactly > what they are > proposing. > > Thus an "intelligent" options request could look that a > resource is not a > directory and thus return: > Allow: GET, HEAD, POST, OPTIONS, TRACE, PROPFIND, COPY, > SEARCH, PROPPATCH, > LOCK, UNLOCK, PUT, DELELTE, MOVE > > notice no MKCOL > > If we are going to make OPTIONS useful to all clients, 2518 > should define > it > a MUST for a server to return an intelligent OPTIONS > response, otherwise a > client will never be able to depend on the information. > > Some Apache Examples: > OPTIONS on any resource (existent or not) on Apache returns a > 200 with a > Allow: GET, HEAD, OPTIONS, TRACE > > Thus one could argue that following suit, a Webdav server for > any resource > (existent or not) could respond: Allow: GET, HEAD, POST, > OPTIONS, TRACE, > PROPFIND, COPY, SEARCH, PROPPATCH, LOCK, UNLOCK, MKCOL, PUT, > DELETE, MOVE > > Should Webdav 2518 state that a server MUST not do the above but > intelligently respond to an OPTIONS request? > > If servers are then required to respond intelligently, what > does that mean? > Does an OPTIONS to a non-existent resource without a parent > simply return: > Allow: OPTIONS > > Kevin > > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of John Stracke > Sent: Wednesday, February 14, 2001 8:00 AM > To: w3c-dist-auth@w3.org > Subject: Re: OPTIONS > > > Kevin Wiggen wrote: > > > 1) /foo is a directory with no contents. > > OPTIONS to /foo returns a 200 with the appropriate headers > > OPTIONS to /foo/bar returns?? 200 or 404?? > > OPTIONS to /foo/bar/fee returns a 404 > > [...] > > > Since OPTIONS > > in 2068 > > (Side note: you want 2616, which obsoletes 2068.) > > > states "the OPTIONS request applies only to the options that are > > available when communicating with that resource." Thus to get a 200 > > response a resource must exist!!! > > Well, let's see. Consider PUT, for example; obviously, you > can PUT to a > resource which does not exist (in the sense that GET would > return 404). > Therefore, it is useful for OPTIONS to be able to tell you that PUT is > allowed > on that resource. > > ...OK, let's see. Running against Apache, if I > do OPTIONS > against > a non-existent resource (in a non-existent directory), I get > a 200, with > the > expected data. GET against the same resource returns 404; > SMURF against > that > resource returns 405. > > To me, this seems reasonable. I believe that *all* resources > exist. A > resource is an object whose methods are HTTP methods; you can > issue an HTTP > method against any Request-URI in the server's namespace; the > server will > respond. By definition, the response is the result of that object's > method. > Therefore, there is an object named by that Request-URI. > Note that 2616, > section 10.4.5, defines 404 as meaning, "The server has not > found anything > matching the Request-URI". This is *not* the same as saying that the > specified > resource does not exist. > > -- > /==============================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own.| > |Chief Scientist |=============================================| > |eCal Corp. |"Call me a Nervous Nellie, but I am concerned| > |francis@ecal.com|about the sale of nuclear arms in my general | > | |neighborhood." -- Dave Barry | > \==============================================================/ > > > From w3c-dist-auth-request@w3.org Sat Feb 17 04:42:39 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02371 for ; Sat, 17 Feb 2001 04:42:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA01964; Sat, 17 Feb 2001 04:34:30 -0500 (EST) Resent-Date: Sat, 17 Feb 2001 04:34:30 -0500 (EST) Resent-Message-Id: <200102170934.EAA01964@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA01930 for ; Sat, 17 Feb 2001 04:34:24 -0500 (EST) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA05918; Sat, 17 Feb 2001 04:34:17 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id BAA29790; Sat, 17 Feb 2001 01:36:39 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Sat, 17 Feb 2001 01:36:38 -0800 From: Greg Stein To: w3c-dist-auth@w3.org, ietf-dav-versioning@w3.org Message-ID: <20010217013638.B27443@lyra.org> Mail-Followup-To: w3c-dist-auth@w3.org, ietf-dav-versioning@w3.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from ccjason@us.ibm.com on Fri, Feb 16, 2001 at 09:59:51PM -0500 X-URL: http://www.lyra.org/greg/ Subject: Re: OPTIONS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4640 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: mod_dav returns different values for the OPTIONS request based on the resource identified. (so no, I won't be "unduly burdened" :-) I don't envision changing that, as I believe the "OPTIONS means server options" concept (as stated before on the DeltaV list) is bogus. OPTIONS is sent to a particular resource. Use OPTIONS * to get server information. [ this has come up on DeltaV before: I say OPTIONS ought to take a Depth: header; the rebuttal was that it didn't make sense since OPTIONS referred to server capabilities. phphtt. no. ] The SVN client expects information on a per-resource basis. I don't want to know if the server has SVN capabilities; I want to know if *that* resource is under SVN control. It is silly to take any other position. Just go read S9.2 of RFC 2616: "... request for information ... on the request/response chain identified by the Request-URI." and "If the Request-URI is not an asterisk, ... applies only ... when communicating with that resource." Cheers, -g p.s. note that, in the example below, Apache doesn't handle OPTIONS well at all. I consider it a problem with Apache's *default* handling of OPTIONS. mod_dav takes particular care to return the correct information for resources under its control. I plan to fix the defaulting handling in Apache 2.0. On Fri, Feb 16, 2001 at 09:59:51PM -0500, Jason Crawford wrote: > > > > See Kevin's note below. > > Does anyone have a client that depends on individual resource (including > null resources) to return different values for the OPTIONS method? > > Does anyone have a client that has *any* expectations for what the OPTIONS > method returns that might be URI specific or that alternately assumes that > what is true for one resource is true for some others? > > Does anyone have a server that would be unduly burdened by needing to > return URI specific results to OPTIONS requests? > > I'll modify the spec accordingly, but I need people to speak up if they > would be negatively impacted if the spec took any particular stance on > this. (If your answer to this is that you don't use OPTIONS, then just > reply to me directly and I'll sumarize for later.) > > Thanks, > > J. > > > > "Kevin Wiggen" (by way of "Ralph R. Swick" > )@w3.org on 02/15/2001 12:49:18 AM > > Sent by: ietf-dav-versioning-request@w3.org > > > To: ietf-dav-versioning@w3.org > cc: > Subject: RE: OPTIONS > > > > [freed from spam trap -rrs] > > Date: Wed, 14 Feb 2001 21:51:47 -0500 (EST) > From: "Kevin Wiggen" > To: "John Stracke" > Cc: , > Message-ID: > Subject: [Moderator Action] RE: OPTIONS > > The real question on OPTIONS is now, should a server be sending back a > different OPTIONS answer per resource. In other words, does a server look > at the resource that has been requested and answer appropriately. I am > CCing the DeltaV group as I have been told this is exactly what they are > proposing. > > Thus an "intelligent" options request could look that a resource is not a > directory and thus return: > Allow: GET, HEAD, POST, OPTIONS, TRACE, PROPFIND, COPY, SEARCH, PROPPATCH, > LOCK, UNLOCK, PUT, DELELTE, MOVE > > notice no MKCOL > > If we are going to make OPTIONS useful to all clients, 2518 should define > it > a MUST for a server to return an intelligent OPTIONS response, otherwise a > client will never be able to depend on the information. > > Some Apache Examples: > OPTIONS on any resource (existent or not) on Apache returns a 200 with a > Allow: GET, HEAD, OPTIONS, TRACE > > Thus one could argue that following suit, a Webdav server for any resource > (existent or not) could respond: Allow: GET, HEAD, POST, OPTIONS, TRACE, > PROPFIND, COPY, SEARCH, PROPPATCH, LOCK, UNLOCK, MKCOL, PUT, DELETE, MOVE > > Should Webdav 2518 state that a server MUST not do the above but > intelligently respond to an OPTIONS request? > > If servers are then required to respond intelligently, what does that mean? > Does an OPTIONS to a non-existent resource without a parent simply return: > Allow: OPTIONS > > Kevin > > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of John Stracke > Sent: Wednesday, February 14, 2001 8:00 AM > To: w3c-dist-auth@w3.org > Subject: Re: OPTIONS > > > Kevin Wiggen wrote: > > > 1) /foo is a directory with no contents. > > OPTIONS to /foo returns a 200 with the appropriate headers > > OPTIONS to /foo/bar returns?? 200 or 404?? > > OPTIONS to /foo/bar/fee returns a 404 > > [...] > > > Since OPTIONS > > in 2068 > > (Side note: you want 2616, which obsoletes 2068.) > > > states "the OPTIONS request applies only to the options that are > > available when communicating with that resource." Thus to get a 200 > > response a resource must exist!!! > > Well, let's see. Consider PUT, for example; obviously, you can PUT to a > resource which does not exist (in the sense that GET would return 404). > Therefore, it is useful for OPTIONS to be able to tell you that PUT is > allowed > on that resource. > > ...OK, let's see. Running against Apache, if I do OPTIONS > against > a non-existent resource (in a non-existent directory), I get a 200, with > the > expected data. GET against the same resource returns 404; SMURF against > that > resource returns 405. > > To me, this seems reasonable. I believe that *all* resources exist. A > resource is an object whose methods are HTTP methods; you can issue an HTTP > method against any Request-URI in the server's namespace; the server will > respond. By definition, the response is the result of that object's > method. > Therefore, there is an object named by that Request-URI. Note that 2616, > section 10.4.5, defines 404 as meaning, "The server has not found anything > matching the Request-URI". This is *not* the same as saying that the > specified > resource does not exist. > > -- > /==============================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own.| > |Chief Scientist |=============================================| > |eCal Corp. |"Call me a Nervous Nellie, but I am concerned| > |francis@ecal.com|about the sale of nuclear arms in my general | > | |neighborhood." -- Dave Barry | > \==============================================================/ > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sat Feb 17 15:37:34 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06932 for ; Sat, 17 Feb 2001 15:37:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA11575; Sat, 17 Feb 2001 15:28:20 -0500 (EST) Resent-Date: Sat, 17 Feb 2001 15:28:20 -0500 (EST) Resent-Message-Id: <200102172028.PAA11575@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA11541 for ; Sat, 17 Feb 2001 15:28:15 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA12362; Sat, 17 Feb 2001 15:28:14 -0500 Received: from Tycho (dhcp-172-37.ucsc.edu [128.114.172.37]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA10068; Sat, 17 Feb 2001 12:28:16 -0800 (PST) From: "Jim Whitehead" To: , Date: Sat, 17 Feb 2001 12:27:25 -0800 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: <20010217013638.B27443@lyra.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: OPTIONS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4641 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Just go read S9.2 of RFC 2616: "... request for information ... on the > request/response chain identified by the Request-URI." and "If the > Request-URI is not an asterisk, ... applies only ... when > communicating with > that resource." > I concur -- it's pretty clear that OPTIONS in HTTP/1.1 is per-resource, unless the Request-URI is "*". It's fairly typical for Web servers to have different capabilities in different parts of their namespace. Note that this doesn't necessarily mean that a server must perform a query for each OPTIONS request -- you could, for example, have OPTIONS code that handles a portion of the namespace. DeltaV could also add some constraints as well, such as, if you support VERSION-CONTROL at one level of a namespace hierarchy, all sub-collections also must support VERSION-CONTROL. So, this would allow clients to avoid sending some kinds of OPTIONS requests, if efficiency is a concern. - Jim From w3c-dist-auth-request@w3.org Mon Feb 19 08:33:49 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03786 for ; Mon, 19 Feb 2001 08:33:44 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA07827; Mon, 19 Feb 2001 08:19:16 -0500 (EST) Resent-Date: Mon, 19 Feb 2001 08:19:16 -0500 (EST) Resent-Message-Id: <200102191319.IAA07827@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA07789 for ; Mon, 19 Feb 2001 08:19:11 -0500 (EST) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA10274 for ; Mon, 19 Feb 2001 08:19:09 -0500 Received: (qmail 15427 invoked by uid 0); 19 Feb 2001 13:18:13 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp001-rz3) with SMTP; 19 Feb 2001 13:18:13 -0000 From: "Julian F. Reschke" To: Date: Mon, 19 Feb 2001 14:21:16 +0100 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: Status of draft-ietf-webdav-redirectref-protocol-02.txt etc Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4642 X-Loop: w3c-dist-auth@w3.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, what's the status of draft-ietf-webdav-redirectref-protocol-02.txt? It has expired six months ago, and I couldn't find any updates... Julian From w3c-dist-auth-request@w3.org Mon Feb 19 14:12:29 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12253 for ; Mon, 19 Feb 2001 14:12:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA28868; Mon, 19 Feb 2001 13:56:03 -0500 (EST) Resent-Date: Mon, 19 Feb 2001 13:56:03 -0500 (EST) Resent-Message-Id: <200102191856.NAA28868@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA28848 for ; Mon, 19 Feb 2001 13:55:58 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA09883 for ; Mon, 19 Feb 2001 13:55:58 -0500 Received: from Tycho (dhcp-172-37.ucsc.edu [128.114.172.37]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA09079; Mon, 19 Feb 2001 10:55:58 -0800 (PST) From: "Jim Whitehead" To: "Julian F. Reschke" , Date: Mon, 19 Feb 2001 10:55:05 -0800 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 V5.50.4133.2400 Importance: Normal Subject: RE: Status of draft-ietf-webdav-redirectref-protocol-02.txt etc Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4643 X-Loop: w3c-dist-auth@w3.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 Julian, This protocol is currently in a state of development hiatus. It has successfully gone through a working group last call for comments period, and is awaiting a revision based on those last call comments. I estimate this revision task will take approximately a week. I am currently estimating that this draft will get revised, and submitted to the IESG for approval, this summer (July/August). The same applies to the bindings protocol, and to the ordered collections protocol as well. - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian F. Reschke > Sent: Monday, February 19, 2001 5:21 AM > To: w3c-dist-auth@w3.org > Subject: Status of draft-ietf-webdav-redirectref-protocol-02.txt etc > > > Hi, > > what's the status of draft-ietf-webdav-redirectref-protocol-02.txt? It has > expired six months ago, and I couldn't find any updates... > > Julian > From w3c-dist-auth-request@w3.org Mon Feb 19 15:49:37 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14401 for ; Mon, 19 Feb 2001 15:49:35 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA03456; Mon, 19 Feb 2001 15:38:49 -0500 (EST) Resent-Date: Mon, 19 Feb 2001 15:38:49 -0500 (EST) Resent-Message-Id: <200102192038.PAA03456@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA03418 for ; Mon, 19 Feb 2001 15:38:42 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA19291; Mon, 19 Feb 2001 15:38:41 -0500 Received: from Tycho (dhcp-172-37.ucsc.edu [128.114.172.37]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA20216; Mon, 19 Feb 2001 12:38:45 -0800 (PST) From: "Jim Whitehead" To: "WebDAV WG" , Date: Mon, 19 Feb 2001 12:37:51 -0800 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: Schedule information for Minneapolis IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4644 X-Loop: w3c-dist-auth@w3.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 OK, the WebDAV and DeltaV working group meeting slots have been assigned in the *Draft* schedule for the Minneapolis IETF. At present, the meeting slots are: WebDAV: Thursday, March 22, 2001: 9AM-11:30AM DeltaV: Thursday, March 22, 2001: 3:30PM-5:30PM Please note that the meeting days and times are subject to change (that's what "Draft" implies), although a change in day would be pretty atypical. The entire Draft Agenda for the Minneapolis IETF can be found at: http://www.ietf.org/meetings/agenda_50.txt Information on the Minneapolis IETF meeting, including registration, hotel, and venue information, can be found at: http://www.ietf.org/meetings/IETF-50.html - Jim From w3c-dist-auth-request@w3.org Wed Feb 21 00:56:30 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06218 for ; Wed, 21 Feb 2001 00:56:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA18981; Wed, 21 Feb 2001 00:45:53 -0500 (EST) Resent-Date: Wed, 21 Feb 2001 00:45:53 -0500 (EST) Resent-Message-Id: <200102210545.AAA18981@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA18961 for ; Wed, 21 Feb 2001 00:45:49 -0500 (EST) Received: from laxmls02.socal.rr.com (laxmls02.socal.rr.com [24.30.163.11]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA07691 for ; Wed, 21 Feb 2001 00:45:48 -0500 Received: from tradestation (sc-66-27-139-41.socal.rr.com [66.27.139.41]) by laxmls02.socal.rr.com (8.11.1/8.11.1) with SMTP id f1L5jln13335 for ; Tue, 20 Feb 2001 21:45:47 -0800 (PST) Message-ID: <00c801c09bc9$967118e0$0200a8c0@tradestation> From: "NewsNet2000" To: Date: Tue, 20 Feb 2001 21:46:07 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C5_01C09B86.880A8E50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: Loosing teeth over APACHE 1.3.17 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4645 X-Loop: w3c-dist-auth@w3.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_00C5_01C09B86.880A8E50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I cant seem to get APACHE 1.3.17 Linux to allow WRITING. Ive searched = the web and despite a few HOW-TO's, I cant get webDAV to work write. Has anyone experienced the same with APACHE? Is there any good sites for setup for ISP's? Thank you in advance=20 mj@newsnet2000.com ------=_NextPart_000_00C5_01C09B86.880A8E50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I cant seem to get APACHE 1.3.17 Linux = to allow=20 WRITING. Ive searched the web and despite a few HOW-TO's, I cant get = webDAV to=20 work write.
 
Has anyone experienced the same with=20 APACHE?
Is there any good sites for setup for=20 ISP's?
 
Thank you in advance
mj@newsnet2000.com
------=_NextPart_000_00C5_01C09B86.880A8E50-- From w3c-dist-auth-request@w3.org Wed Feb 21 06:46:27 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22603 for ; Wed, 21 Feb 2001 06:46:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA28760; Wed, 21 Feb 2001 06:35:13 -0500 (EST) Resent-Date: Wed, 21 Feb 2001 06:35:13 -0500 (EST) Resent-Message-Id: <200102211135.GAA28760@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA28668 for ; Wed, 21 Feb 2001 06:35:07 -0500 (EST) Received: from platinum1.cambridge.scr.slb.com (platinum1.cambridge.scr.slb.com [134.32.103.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA00688 for ; Wed, 21 Feb 2001 06:35:05 -0500 Received: from cambridge.scr.slb.com (dhcp101-240 [134.32.101.240]) by platinum1.cambridge.scr.slb.com (8.11.1/8.11.1/NC.V1.5) with ESMTP id f1LBYrU07096; Wed, 21 Feb 2001 11:34:53 GMT Message-ID: <3A93A7E6.3480E78@cambridge.scr.slb.com> Date: Wed, 21 Feb 2001 11:35:02 +0000 From: Steve Sharp X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: NewsNet2000 CC: w3c-dist-auth@w3.org References: <00c801c09bc9$967118e0$0200a8c0@tradestation> Content-Type: multipart/alternative; boundary="------------E667C11C4F2CEB07830EE8E8" Subject: Re: Loosing teeth over APACHE 1.3.17 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4646 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --------------E667C11C4F2CEB07830EE8E8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We use Apache 1.3.17 (on solaris tho) here with mod_dav i assume thats what you mean ? we allow some of our users to "publish" and use WebFolders to manage some of the files... I had a problem a while back with the DAV database file beeing owned by the wrong user, this caused a similar problem... "Dav locks could not be engaged....." Hope this helps, -Steve NewsNet2000 wrote: > I cant seem to get APACHE 1.3.17 Linux to allow WRITING. Ive searched > the web and despite a few HOW-TO's, I cant get webDAV to work > write. Has anyone experienced the same with APACHE?Is there any good > sites for setup for ISP's? Thank you in advancemj@newsnet2000.com --------------E667C11C4F2CEB07830EE8E8 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit We use Apache 1.3.17 (on solaris tho) here with mod_dav i assume thats what you mean ?

we allow some of our users to "publish" and use WebFolders to manage some of the files...
I had a problem a while back with the DAV database file beeing owned by the wrong user, this caused a similar problem... "Dav locks could not be engaged....."

Hope this helps,

-Steve

NewsNet2000 wrote:

I cant seem to get APACHE 1.3.17 Linux to allow WRITING. Ive searched the web and despite a few HOW-TO's, I cant get webDAV to work write. Has anyone experienced the same with APACHE?Is there any good sites for setup for ISP's? Thank you in advancemj@newsnet2000.com
--------------E667C11C4F2CEB07830EE8E8-- From w3c-dist-auth-request@w3.org Wed Feb 21 06:57:45 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22843 for ; Wed, 21 Feb 2001 06:57:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA29487; Wed, 21 Feb 2001 06:47:47 -0500 (EST) Resent-Date: Wed, 21 Feb 2001 06:47:47 -0500 (EST) Resent-Message-Id: <200102211147.GAA29487@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA29467 for ; Wed, 21 Feb 2001 06:47:43 -0500 (EST) Received: from Mail.MeepZor.Com (IDENT:root@i.meepzor.com [204.146.167.214]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA01688 for ; Wed, 21 Feb 2001 06:47:43 -0500 Received: from Golux.Com (dsl-64-192-128-105.telocity.com [64.192.128.105]) by Mail.MeepZor.Com (8.8.7/8.8.7) with ESMTP id GAA12080; Wed, 21 Feb 2001 06:56:20 -0500 Message-ID: <3A93AB79.9F1E1991@Golux.Com> Date: Wed, 21 Feb 2001 06:50:17 -0500 From: Rodent of Unusual Size Organization: The Apache Software Foundation X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: NewsNet2000 CC: w3c-dist-auth@w3.org References: <00c801c09bc9$967118e0$0200a8c0@tradestation> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Loosing teeth over APACHE 1.3.17 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4647 X-Loop: w3c-dist-auth@w3.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 NewsNet2000 wrote: > > I cant seem to get APACHE 1.3.17 Linux to allow WRITING. Ive > searched the web and despite a few HOW-TO's, I cant get webDAV > to work write. Check out webdav.org, and email Greg Stein . -- #ken P-)} Ken Coar Apache Software Foundation "Apache Server for Dummies" "Apache Server Unleashed" From w3c-dist-auth-request@w3.org Wed Feb 21 15:16:26 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08488 for ; Wed, 21 Feb 2001 15:16:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA28235; Wed, 21 Feb 2001 14:58:17 -0500 (EST) Resent-Date: Wed, 21 Feb 2001 14:58:17 -0500 (EST) Resent-Message-Id: <200102211958.OAA28235@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA28211 for ; Wed, 21 Feb 2001 14:58:12 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA24993 for ; Wed, 21 Feb 2001 14:58:12 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id LAA16805 for ; Wed, 21 Feb 2001 11:58:08 -0800 (PST) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 21 Feb 2001 11:57:21 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Preliminary agenda for WebDAV WG Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4648 X-Loop: w3c-dist-auth@w3.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 Here are my current thoughts on the agenda for the WebDAV WG meeting at the Minneapolis IETF: - Open issues in the ACL specification I suspect most issues in this specification will have been resolved on the ACL mailing list before the IETF meeting, but if not, we'll make time for this. - Property registration (Dennis Hamilton) Discussion of the issues inherent in registration of WebDAV properties. - Open issues in RFC 2518 We'll start marching down the RFC 2518 issues list, and resolve as many issues as possible. - Reviving DASL When to do this, who wants to work on it, in what venue, etc. I'm also hoping to have one or more breakout sessions for WebDAV dedicated to the resolution of RFC 2518 issues. From w3c-dist-auth-request@w3.org Fri Feb 23 23:20:27 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01901 for ; Fri, 23 Feb 2001 23:20:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA23439; Fri, 23 Feb 2001 23:09:46 -0500 (EST) Resent-Date: Fri, 23 Feb 2001 23:09:46 -0500 (EST) Resent-Message-Id: <200102240409.XAA23439@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA23403 for ; Fri, 23 Feb 2001 23:09:36 -0500 (EST) 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 XAA32713; Fri, 23 Feb 2001 23:09:35 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id XAA146908; Fri, 23 Feb 2001 23:08:27 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id XAA39094; Fri, 23 Feb 2001 23:05:40 -0500 Importance: Normal To: , X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Fri, 23 Feb 2001 23:09:18 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.6a |January 17, 2001) at 02/23/2001 11:09:32 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: OPTIONS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4649 X-Loop: w3c-dist-auth@w3.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 concur -- it's pretty clear that OPTIONS in HTTP/1.1 is per-resource, unless the Request-URI is "*". It's fairly typical for Web servers to have different capabilities in different parts of their namespace. >> So do we want 2518 to say anything or leave this for HTTP/1.1? It sounds to me that all the questions asked here about OPTIONS in the last two weeks are probably best left to the HTTP/1.1 spec. (I just wish that spec said more.) J. From w3c-dist-auth-request@w3.org Mon Feb 26 13:26:57 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20070 for ; Mon, 26 Feb 2001 13:26:56 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA02954; Mon, 26 Feb 2001 13:18:00 -0500 (EST) Resent-Date: Mon, 26 Feb 2001 13:18:00 -0500 (EST) Resent-Message-Id: <200102261818.NAA02954@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA02934 for ; Mon, 26 Feb 2001 13:17:56 -0500 (EST) Received: from infonuovo.com (ntmail1.lightrealm.com [216.122.10.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA04427 for ; Mon, 26 Feb 2001 13:17:55 -0500 Received: from centro (2Cust78.tnt4.sea1.da.uu.net [63.36.223.78]) by infonuovo.com (8.8.7/8.8.5) with SMTP id JAA00483; Mon, 26 Feb 2001 09:59:16 -0800 (PST) Reply-To: From: "Dennis E. Hamilton" To: "Jim Whitehead" Cc: "WebDAV WG" Date: Mon, 26 Feb 2001 10:19:36 -0800 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 V5.50.4133.2400 Importance: Normal Subject: RE: Preliminary agenda for WebDAV WG Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4650 X-Loop: w3c-dist-auth@w3.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, Just a reminder that I have a conflict in Seattle for March 21-23 and won't be at IETF 50. I will have initiated mailing-list discussion on the property registration subproject well before the March 18 start of the IETF meeting, and I expect to have the gathering of requirements and people's sense of this well underway by then. Some earlier on-list discussion around property descriptions also needs to be taken into account. My proposal is to maintain the schedule that you have already established in the DAV Project description and have an initial I-D in March. I will post more and have solicited discussion and input by Friday, March 9. This week I am clearing my desk of other things plus reading all of the material I have scrounged from the web so far. Just so I am not leaving a big question mark in the space, I will also say a little more about my volunteering to pull together the Property Registration subproject in the next day or two. -- Dennis AIIM DMware Technical Coordinator AIIM DMware http://www.infonuovo.com/dmware ODMA Support http://www.infonuovo.com/odma ------------------ Dennis E. Hamilton tel. +1-425-793-0283 mailto:orcmid@email.com fax. +1-425-430-8189 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead Sent: Wednesday, February 21, 2001 11:57 To: WebDAV WG Subject: Preliminary agenda for WebDAV WG Here are my current thoughts on the agenda for the WebDAV WG meeting at the Minneapolis IETF: - Open issues in the ACL specification I suspect most issues in this specification will have been resolved on the ACL mailing list before the IETF meeting, but if not, we'll make time for this. - Property registration (Dennis Hamilton) Discussion of the issues inherent in registration of WebDAV properties. - Open issues in RFC 2518 We'll start marching down the RFC 2518 issues list, and resolve as many issues as possible. - Reviving DASL When to do this, who wants to work on it, in what venue, etc. I'm also hoping to have one or more breakout sessions for WebDAV dedicated to the resolution of RFC 2518 issues. From w3c-dist-auth-request@w3.org Tue Feb 27 07:50:06 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06107 for ; Tue, 27 Feb 2001 07:50:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA12242; Tue, 27 Feb 2001 07:41:35 -0500 (EST) Resent-Date: Tue, 27 Feb 2001 07:41:35 -0500 (EST) Resent-Message-Id: <200102271241.HAA12242@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA12222 for ; Tue, 27 Feb 2001 07:41:32 -0500 (EST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA25583 for ; Tue, 27 Feb 2001 07:41:31 -0500 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA155988 for ; Tue, 27 Feb 2001 07:36:48 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.11.2/NCO v4.95) with ESMTP id f1RCfJD80848 for ; Tue, 27 Feb 2001 07:41:19 -0500 To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Steve K Speicher" Date: Tue, 27 Feb 2001 07:41:47 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 02/27/2001 07:41:19 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Clarification on DAV server enforcing locks for PUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4651 X-Loop: w3c-dist-auth@w3.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 reading RFC2518 section 6.7 "Usage Considerations", I think I'm reading conflicting statements: Paragraph 4 reads: "...it cannot force all clients to use locking because it must be comparatible with HTTP clients that don't comprehend locking" Paragraph 5 reads: "WebDAV servers that support locking can reduce the likelihood that clients will accidentally overwrite each other's changes by requireing clients to lock resource before modifying them..." So can (or should) a DAV server enforce locking? Thanks, Steve Speicher (919) 254-0645 sspeiche@us.ibm.com From w3c-dist-auth-request@w3.org Tue Feb 27 08:03:53 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06584 for ; Tue, 27 Feb 2001 08:03:52 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA12750; Tue, 27 Feb 2001 07:56:16 -0500 (EST) Resent-Date: Tue, 27 Feb 2001 07:56:16 -0500 (EST) Resent-Message-Id: <200102271256.HAA12750@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA12727 for ; Tue, 27 Feb 2001 07:56:12 -0500 (EST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA26704 for ; Tue, 27 Feb 2001 07:56:11 -0500 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA145914 for ; Tue, 27 Feb 2001 07:51:29 -0600 Received: from d04nm303.raleigh.ibm.com (d04nm303.raleigh.ibm.com [9.67.228.168]) by southrelay02.raleigh.ibm.com (8.11.2/NCO v4.95) with ESMTP id f1RCtxD64904 for ; Tue, 27 Feb 2001 07:56:00 -0500 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Jim Amsden" Date: Tue, 27 Feb 2001 07:52:53 -0500 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 02/27/2001 07:56:00 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Clarification on DAV server enforcing locks for PUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4652 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Steve, There's no contradiction here. The first sentence says a WebDAV server can't require all clients to use locking. The second one says that if a resource is locked, then updates that don't include the lock token must fail. That doesn't mean that clients issuing update requests without a lock token will succeed on these locked resources, only that they may succeed on unlocked resources. "Steve K Speicher" To: w3c-dist-auth@w3.org Subject: Clarification on DAV server enforcing locks for PUT 02/27/2001 07:41 AM In reading RFC2518 section 6.7 "Usage Considerations", I think I'm reading conflicting statements: Paragraph 4 reads: "...it cannot force all clients to use locking because it must be comparatible with HTTP clients that don't comprehend locking" Paragraph 5 reads: "WebDAV servers that support locking can reduce the likelihood that clients will accidentally overwrite each other's changes by requireing clients to lock resource before modifying them..." So can (or should) a DAV server enforce locking? Thanks, Steve Speicher (919) 254-0645 sspeiche@us.ibm.com From w3c-dist-auth-request@w3.org Wed Feb 28 18:58:50 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02199 for ; Wed, 28 Feb 2001 18:58:50 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA29888; Wed, 28 Feb 2001 18:43:37 -0500 (EST) Resent-Date: Wed, 28 Feb 2001 18:43:37 -0500 (EST) Resent-Message-Id: <200102282343.SAA29888@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA29868 for ; Wed, 28 Feb 2001 18:43:33 -0500 (EST) Received: from ladon.host4u.net (ladon.host4u.net [216.71.64.24]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA12929 for ; Wed, 28 Feb 2001 18:43:32 -0500 Received: from win2k (CBL012.pool012.CH001-riverside.dhcp.hs.earthlink.net [209.178.119.12]) by ladon.host4u.net (8.8.5/8.8.5) with SMTP id RAA03506 for ; Wed, 28 Feb 2001 17:40:33 -0600 Message-ID: <001001c0a1e1$8761eff0$0c77b2d1@win2k> From: "John Glavin" To: Date: Wed, 28 Feb 2001 15:52:37 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C0A19E.78D9D3A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: UTF-8 Encoding Question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4653 X-Loop: w3c-dist-auth@w3.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_000D_01C0A19E.78D9D3A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have a Windows webdav client (WebDrive) and I am trying to add support = for special characters in file names like "Umlaut =FC". Most DAV = servers will return filenames in a PROPFIND request that are encoded in = either UTF-8 or ISO-8859 (Latin). This generally works fine, I can tell = what character set is used and use the proper encoding scheme. For example IIS will return the file name Magn=FCs.txt (note the '=FC' = umlat) as=20 href: Magn%C3%BCs.txt This is UTF-8 Encoding. Another server may use ISO-8859 which will list it as href: Magn%FCs.txt Where %FC is hex for 252 the Umlat character. = This is also fine. But I run into a problem with the mydocsonline.com DAV server which says = it is using UTF-8 Encoding but returns the href as href: Magn%FCs.txt This is not UTF-8 encoded, because characters > = 0x80 in UTF-8 will be encoded in a multibyte sequence. This is normal = ISO-8859 (Latin) Encoding. In this case I am not sure what to do. I use the Windows API call = MultiByteToWideChar function but I need to tell it to use either UTF-8 = or ANSI code pages. For the mydocsonline server I need to use ANSI = however they are telling me to use UTF-8 and using UTF-8 wont work.=20 When I use Webfolders it works properly on the mydocsonline server and = somehow knows to not use UTF-8 decoding. Does anyone have any idea why = it works or how I could really detect which code page to use ? Thanks, John Glavin RiverFront Software john@webdrive.com http://www.webdrive.com ------=_NextPart_000_000D_01C0A19E.78D9D3A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have a Windows webdav client = (WebDrive) and I am=20 trying to add support for special characters in file names like "Umlaut=20 =FC".  Most DAV servers will return filenames in a PROPFIND request = that are=20 encoded in either UTF-8 or ISO-8859 (Latin).  This generally works = fine, I=20 can tell what character set is used and use the proper encoding=20 scheme.
 
For example  IIS will return the = file name=20 Magn=FCs.txt  (note the '=FC' umlat) as
href: =20 Magn%C3%BCs.txt      This is UTF-8=20 Encoding.
 
Another server may use ISO-8859 which = will list it=20 as
href: = Magn%FCs.txt    Where %FC=20 is hex for 252 the Umlat character.  This is also = fine.
 
But I run into a problem with the = mydocsonline.com=20 DAV server which says it is using UTF-8 Encoding but returns the href=20 as
href:=20 Magn%FCs.txt      This is not UTF-8 = encoded,=20 because characters > 0x80 in UTF-8 will be encoded in a multibyte=20 sequence.  This is normal ISO-8859 (Latin) Encoding.
 
In this case I am not sure what to = do.  I use=20 the Windows API call MultiByteToWideChar function but I need to tell it = to use=20 either UTF-8 or ANSI code pages.  For the mydocsonline server I = need to use=20 ANSI however they are telling me to use UTF-8 and using UTF-8 wont work. =
 
When I use Webfolders it works properly = on the=20 mydocsonline server and somehow knows to not use UTF-8 decoding.  = Does=20 anyone have any idea why it works or how I could really detect which = code page=20 to use ?
 
Thanks,
John Glavin
RiverFront = Software
john@webdrive.com
http://www.webdrive.com
=
 
 
------=_NextPart_000_000D_01C0A19E.78D9D3A0-- From w3c-dist-auth-request@w3.org Wed Feb 28 20:13:55 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04348 for ; Wed, 28 Feb 2001 20:13:50 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA02558; Wed, 28 Feb 2001 19:54:10 -0500 (EST) Resent-Date: Wed, 28 Feb 2001 19:54:10 -0500 (EST) Resent-Message-Id: <200103010054.TAA02558@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA02534 for ; Wed, 28 Feb 2001 19:54:04 -0500 (EST) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA18039 for ; Wed, 28 Feb 2001 19:54:00 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id QAA06162; Wed, 28 Feb 2001 16:54:15 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Wed, 28 Feb 2001 16:54:15 -0800 From: Greg Stein To: John Glavin Cc: w3c-dist-auth@w3.org Message-ID: <20010228165415.N2297@lyra.org> Mail-Followup-To: John Glavin , w3c-dist-auth@w3.org References: <001001c0a1e1$8761eff0$0c77b2d1@win2k> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <001001c0a1e1$8761eff0$0c77b2d1@win2k>; from john@riverfrontsoftware.com on Wed, Feb 28, 2001 at 03:52:37PM -0800 X-URL: http://www.lyra.org/greg/ Subject: Re: UTF-8 Encoding Question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4654 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: We just had a discussion related to this on mod_dav's mailing list. On Wed, Feb 28, 2001 at 03:52:37PM -0800, John Glavin wrote: >... > But I run into a problem with the mydocsonline.com DAV server which says > it is using UTF-8 Encoding but returns the href as href: Magn%FCs.txt > This is not UTF-8 encoded, because characters > 0x80 in UTF-8 will be > encoded in a multibyte sequence. This is normal ISO-8859 (Latin) Encoding. There are two references to UTF-8 in the response: the Content-Type header and the XML document header: Content-Type: text/xml; charset="utf-8" Both of these refer to the *response body*. In that sense, all characters in the body are properly UTF-8 encoded. The URL itself is in its "escaped" form. See sections 2.4.2 of RFC 2396 for more info. Section 2.1 covers the general problem of UTF-8 encodings for URLs. To be more concrete. Section 2.1 defines two types of characters: "URI characters", and "original characters". The "utf-8" above refers to the URI characters since that is what is sitting in the body of the response. The % escaping will give you a set of octets. The question then becomes, "what encoding will transform those octets into the 'original' characters?" At the moment, you do not have enough information to do that. There is no attribute or header or other item that you can inspect for that. > In this case I am not sure what to do. I use the Windows API call > MultiByteToWideChar function but I need to tell it to use either UTF-8 or > ANSI code pages. For the mydocsonline server I need to use ANSI however > they are telling me to use UTF-8 and using UTF-8 wont work. > > When I use Webfolders it works properly on the mydocsonline server and > somehow knows to not use UTF-8 decoding. Does anyone have any idea why it > works or how I could really detect which code page to use ? I think your statement about it "working" for some servers, and not working for mydocsonline (which is based on an early mod_dav; the current mod_dav has the same issue, tho) is based on a presumption that the character set for the URI characters == the charset of the original characters. That assumption is being made by servers and clients today. In mod_dav's case, we take the URI's (unescaped) octets and simply save the resource under that name. We then return it using the same octet sequence (properly escaped). The net effect is that we keep the same encoding of the "original characters" for the client. Of course, the problem arises when one client saves using a UTF-8 encoding and another reads as Latin-1. But mod_dav does not have enough information from the client to decode the URL into (say) Unicode, and save that. If it could, then we could always return a UTF-8 encoding for the original characters (although we would still have no way to tell that encoding to the client; clients would just continue to assume the response encoding matches that encoding and it would *happen* to match). To be really clear, let's go with a little diagram here: Unicode resource name ("original characters") | [ UTF-8 encoding ] | URI octet sequence | [ URI %-escaping ] | Returned URI ("URI characters") But another totally legal scenario is: Latin-1 resource name ("original characters") | [ identity (no) encoding ] | URI octet sequence | [ URI %-escaping ] | Returned URI ("URI characters") There is nothing in the response body to indicate which of the above two forms is occurring. Similarly, there is nothing in the request body to indicate which was used for the Request-URI. Because of the latter, servers are just as broken if they make an assumption about how to decode from the URI octets into original characters. mod_dav does not attempt to decode/encode between octets and original characters. It just keeps them as octets. But that does imply that the encoding used by the client when it stored the resource better be the same encoding used when accessing the resource and the same decoding used for a PROPFIND result. RFC 2396, section 2.1 explicitly punts this issue to a future date. It seems that I recall an internet draft, or even possibly a new RFC, but I'm not immediately aware of it. Cheers, -g -- Greg Stein, http://www.lyra.org/