From w3c-dist-auth-request@w3.org Thu Mar 1 01:57:22 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 BAA18181 for ; Thu, 1 Mar 2001 01:57:22 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA11712; Thu, 1 Mar 2001 01:48:15 -0500 (EST) Resent-Date: Thu, 1 Mar 2001 01:48:15 -0500 (EST) Resent-Message-Id: <200103010648.BAA11712@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 BAA11691 for ; Thu, 1 Mar 2001 01:48:08 -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 BAA09665 for ; Thu, 1 Mar 2001 01:48:07 -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 AAA24356; Thu, 1 Mar 2001 00:44:56 -0600 Message-ID: <000c01c0a21c$d3fed090$0c77b2d1@win2k> From: "John Glavin" To: "Greg Stein" , "John Glavin" Cc: References: <001001c0a1e1$8761eff0$0c77b2d1@win2k> <20010228165415.N2297@lyra.org> Date: Wed, 28 Feb 2001 22:57:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: Re: UTF-8 Encoding Question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4655 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks, this makes sense now. I guess what I can do is see if the URI contains a valid UTF-8 sequence and if it does then assume it's UTF-8 encoded. I got the following text from RFC-2279 UTF-8 strings can be fairly reliably recognized as such by a simple algorithm, i.e. the probability that a string of characters in any other encoding appears as valid UTF-8 is low, diminishing with increasing string length. Webfolders must be doing something similar to this since it understands both UTF-8 and Latin-1. John Glavin RiverFront Software john@webdrive.com http://www.webdrive.com ----- Original Message ----- From: "Greg Stein" To: "John Glavin" Cc: Sent: Wednesday, February 28, 2001 4:54 PM Subject: Re: UTF-8 Encoding Question > 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/ From w3c-dist-auth-request@w3.org Thu Mar 1 03:41:00 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 DAA28339 for ; Thu, 1 Mar 2001 03:40:55 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA13666; Thu, 1 Mar 2001 03:33:54 -0500 (EST) Resent-Date: Thu, 1 Mar 2001 03:33:54 -0500 (EST) Resent-Message-Id: <200103010833.DAA13666@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 DAA13645 for ; Thu, 1 Mar 2001 03:33:40 -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 DAA16638 for ; Thu, 1 Mar 2001 03:33:36 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id AAA06937; Thu, 1 Mar 2001 00:33:55 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Thu, 1 Mar 2001 00:33:55 -0800 From: Greg Stein To: John Glavin , w3c-dist-auth@w3.org Message-ID: <20010301003355.Y2297@lyra.org> Mail-Followup-To: John Glavin , w3c-dist-auth@w3.org References: <001001c0a1e1$8761eff0$0c77b2d1@win2k> <20010228165415.N2297@lyra.org> <000c01c0a21c$d3fed090$0c77b2d1@win2k> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <000c01c0a21c$d3fed090$0c77b2d1@win2k>; from john@riverfrontsoftware.com on Wed, Feb 28, 2001 at 10:57:05PM -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/4656 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: That would be a good heuristic for handling this. We could augment the DAV:href element with an optional attribute, like this: http://some.host/Magn%FCs.txt and http://some.host/C%C3%A9sar.txt That will help within the responses (if a server supplies it, then you don't have to guess; otherwise, fall back to your heuristic). We'd still need a way to determine the original charset of the Request-URI, though, to fully solve the problem. JimW: can we list this as an "Issue" for RFC 2518? Cheers, -g On Wed, Feb 28, 2001 at 10:57:05PM -0800, John Glavin wrote: > Thanks, this makes sense now. I guess what I can do is see if the URI > contains a valid UTF-8 sequence and if it does then assume it's UTF-8 > encoded. I got the following text from RFC-2279 > > UTF-8 strings can be fairly reliably recognized as such by a > simple algorithm, i.e. the probability that a string of characters > in any other encoding appears as valid UTF-8 is low, diminishing > with increasing string length. > > Webfolders must be doing something similar to this since it understands both > UTF-8 and Latin-1. > > John Glavin > RiverFront Software > john@webdrive.com > http://www.webdrive.com > > > ----- Original Message ----- > From: "Greg Stein" > To: "John Glavin" > Cc: > Sent: Wednesday, February 28, 2001 4:54 PM > Subject: Re: UTF-8 Encoding Question > > > > 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/ -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Mar 1 09:17: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 JAA04538 for ; Thu, 1 Mar 2001 09:17:08 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA25251; Thu, 1 Mar 2001 09:10:59 -0500 (EST) Resent-Date: Thu, 1 Mar 2001 09:10:59 -0500 (EST) Resent-Message-Id: <200103011410.JAA25251@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 JAA25231 for ; Thu, 1 Mar 2001 09:10:55 -0500 (EST) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA10315 for ; Thu, 1 Mar 2001 09:10:54 -0500 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id JAA02796; Thu, 1 Mar 2001 09:10:18 -0500 Received: from 153.dhcp.stg.opentext.com(192.168.194.153) by krusty.wl.opentext.com via smap (V2.1) id xmab02715; Thu, 1 Mar 01 09:10:14 -0500 From: "Dylan Barrell" To: "Greg Stein" , "John Glavin" , Date: Thu, 1 Mar 2001 09:10:22 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20010301003355.Y2297@lyra.org> Subject: RE: UTF-8 Encoding Question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4657 X-Loop: w3c-dist-auth@w3.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 Why, if webDAV is an extension of HTTP and HTTP specifies that the default character set is ISO-8859-1 unless specified in the header, should it therefore not be possible for the server to determine the character set from the request header? --Dylan From w3c-dist-auth-request@w3.org Thu Mar 1 10:11:02 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 KAA06520 for ; Thu, 1 Mar 2001 10:11:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA26953; Thu, 1 Mar 2001 10:03:22 -0500 (EST) Resent-Date: Thu, 1 Mar 2001 10:03:22 -0500 (EST) Resent-Message-Id: <200103011503.KAA26953@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 KAA26923 for ; Thu, 1 Mar 2001 10:03:16 -0500 (EST) Received: from localhost.localdomain ([216.52.68.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA18910 for ; Thu, 1 Mar 2001 10:03:15 -0500 Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f21F9Wf08945 for ; Thu, 1 Mar 2001 10:09:32 -0500 Message-ID: <3A9E5988.8B55416F@ecal.com> Date: Thu, 01 Mar 2001 09:15: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 References: <001001c0a1e1$8761eff0$0c77b2d1@win2k> <20010228165415.N2297@lyra.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: UTF-8 Encoding Question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4658 X-Loop: w3c-dist-auth@w3.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: > 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. draft-masinter-url-i18n-07.txt -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |You buttered your bread, now lie in it. | |francis@ecal.com| | \==============================================================/ From w3c-dist-auth-request@w3.org Thu Mar 1 10:21:18 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 KAA06926 for ; Thu, 1 Mar 2001 10:21:17 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA27638; Thu, 1 Mar 2001 10:14:48 -0500 (EST) Resent-Date: Thu, 1 Mar 2001 10:14:48 -0500 (EST) Resent-Message-Id: <200103011514.KAA27638@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 KAA27618 for ; Thu, 1 Mar 2001 10:14:44 -0500 (EST) Received: from server1.software-ag.de (server1.software-ag.de [193.26.194.2]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA20781 for ; Thu, 1 Mar 2001 10:14:39 -0500 Message-ID: <2B1792E820ACD411AD5A00508BF9A3FC01410104@daemsg03.software-ag.de> From: "Pill, Juergen" To: "'w3c-dist-auth@w3.org'" Date: Thu, 1 Mar 2001 16:14:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: unlock question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4659 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: What should a Webdav enabled server return in case of the unlock method and a provided lock token, which does not exist (for this resource)? Assuming the resource is already locked, would it be OK to return a 204 (no content) or would be an error message better (which one)? Best regards Juergen Pill From w3c-dist-auth-request@w3.org Thu Mar 1 12:08:58 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 MAA11008 for ; Thu, 1 Mar 2001 12:08:57 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA03418; Thu, 1 Mar 2001 11:58:28 -0500 (EST) Resent-Date: Thu, 1 Mar 2001 11:58:28 -0500 (EST) Resent-Message-Id: <200103011658.LAA03418@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 LAA03398 for ; Thu, 1 Mar 2001 11:58:24 -0500 (EST) Received: from smtp-relay-1.Adobe.COM (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA31904 for ; Thu, 1 Mar 2001 11:58:21 -0500 Received: from inner-relay-2.Adobe.COM (inner-relay-2.corp.adobe.com [153.32.1.52]) by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id JAA03835 for ; Thu, 1 Mar 2001 09:01:29 -0800 (PST) Received: from mailsj-v1.corp.adobe.com by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id IAA27980; Thu, 1 Mar 2001 08:57:41 -0800 (PST) Received: from [192.168.1.6] ([130.248.188.64]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id G9J34C00.958; Thu, 1 Mar 2001 08:57:48 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: <001001c0a1e1$8761eff0$0c77b2d1@win2k> References: <001001c0a1e1$8761eff0$0c77b2d1@win2k> Date: Thu, 1 Mar 2001 08:57:47 -0500 To: "John Glavin" From: "Dan Brotsky" Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: UTF-8 Encoding Question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4660 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 3:52 PM -0800 2/28/01, 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. As Greg pointed out on dav-dev, it's very important *not* to confuse the "UTF-8 encoding" explicitly employed for the XML response bodies with any possible "UTF-8 encoding" of non-ascii characters in the URLs in these bodies (before they are %-escaped). XML bodies are explicitly encoded, but this encoding does NOT apply to any URL segments that are %-encoded *inside* the XML bodies. The fact that URLs, in and of themselves, do not indicate the encoding used for their path segments is a known issue in the HTTP community, and is specifically referred to in several specs. At this point, it is pretty much up to clients and servers to agree on conventions about what encoding will be used in such path segments. There seem to be two common appraches: 1. No encoding is done at all. The platform-specific character set components of a filename are viewed as an octet stream and are then %-encoded directly into the URL. Since many platform-specific character sets are very close to ISO 8859-1 (ISO Latin 1), this often looks like the client or server is using an ISO 8859-1 encoding of these segments, but it's often just the platform encoding. 2. Encoding is done by translating the platform-specific character set components of a filename into Unicode, and then UTF-8 (or sometimes ISO 8859-1) encoding that Unicode into an octet stream which is then %-encoded for use in an URL. The advantage of approach 2 [in the case where UTF-8 is used], as I outlined in an earlier message to dav-dev, is that clients and servers with different platform character sets but who are both capable of encoding certain characters can unambiguously communicate about filenames that contain those characters. This is increasingly important in today's global net community as wide-character-capable clients with divergent platform character sets proliferate. I am encouraged to see that many of the "big" browser clients (IE and Netscape) are beginning to use UTF-8 encodings of platform character sets in the URLs they generate and to understand UTF-8 encodings in URLs they receive. It would be nice to see the prevalent DAV servers (such as mod_dav) take approach #2 with UTF-8 as well. (Approach #2 using ISO 8859-1 has far fewer advantages, since ISO 8859-1 encodes a very restricted subset of Unicode.) dan From w3c-dist-auth-request@w3.org Thu Mar 1 14:19:22 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 OAA18710 for ; Thu, 1 Mar 2001 14:19:21 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA07342; Thu, 1 Mar 2001 13:53:58 -0500 (EST) Resent-Date: Thu, 1 Mar 2001 13:53:58 -0500 (EST) Resent-Message-Id: <200103011853.NAA07342@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 NAA07300 for ; Thu, 1 Mar 2001 13:53:53 -0500 (EST) Received: from andora.wiggenout.com ([216.102.212.250]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA10290; Thu, 1 Mar 2001 13:53:51 -0500 Received: from lyta ([192.168.0.3]) by andora.wiggenout.com (8.9.3/8.8.7) with SMTP id MAA00945; Thu, 1 Mar 2001 12:07:19 -0800 From: "Kevin Wiggen" To: "Jason Crawford" , , Date: Thu, 1 Mar 2001 10:53:10 -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) In-Reply-To: Importance: Normal 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/4661 X-Loop: w3c-dist-auth@w3.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 do not think the HTTP spec says enough, and for OPTIONS to be useful to clients, I think we need to specify what the behavior is. It's useful to look at a few use cases and discuss what the server should respond. Take for instance: /foo is an empty directory OPTIONS /foo Allow: GET, HEAD, POST, OPTIONS, TRACE, PROPFIND, COPY, SEARCH If the /foo is writeable add PROPPATCH, LOCK, UNLOCK OPTIONS /foo/bar Allow: OPTIONS If /foo is writeable add MKCOL, PUT, LOCK OPTIONS /foo/bar/fee Allow: OPTIONS This is one way of handling the OPTIONS, I can think of other permutations that might make sense. Again for this to be truly useful information to a client, I believe we need to state what a server should respond with to a client in each case. Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford Sent: Friday, February 23, 2001 8:09 PM To: w3c-dist-auth@w3.org; ietf-dav-versioning@w3.org Subject: RE: OPTIONS << 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 Thu Mar 1 14:27:22 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 OAA19087 for ; Thu, 1 Mar 2001 14:27:20 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA08609; Thu, 1 Mar 2001 14:13:09 -0500 (EST) Resent-Date: Thu, 1 Mar 2001 14:13:09 -0500 (EST) Resent-Message-Id: <200103011913.OAA08609@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 OAA08585 for ; Thu, 1 Mar 2001 14:12:59 -0500 (EST) Received: from localhost.localdomain ([216.52.68.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA12371 for ; Thu, 1 Mar 2001 14:12:58 -0500 Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f21JJ7f09943 for ; Thu, 1 Mar 2001 14:19:07 -0500 Message-ID: <3A9EA0A9.10C3A439@ecal.com> Date: Thu, 01 Mar 2001 14:19:05 -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: UTF-8 Encoding Question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4662 X-Loop: w3c-dist-auth@w3.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 Dylan Barrell wrote: > Why, if webDAV is an extension of HTTP and HTTP specifies that the default > character set is ISO-8859-1 unless specified in the header, should it > therefore not be possible for the server to determine the character set from > the request header? Because the charset applies to the message body, not the request-URI. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |If God had not given us duct tape, it would have| |francis@ecal.com|been necessary to invent it. | \=================================================================/ From w3c-dist-auth-request@w3.org Thu Mar 1 14:53: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 OAA20153 for ; Thu, 1 Mar 2001 14:53:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA10039; Thu, 1 Mar 2001 14:46:10 -0500 (EST) Resent-Date: Thu, 1 Mar 2001 14:46:10 -0500 (EST) Resent-Message-Id: <200103011946.OAA10039@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 OAA10016 for ; Thu, 1 Mar 2001 14:46:01 -0500 (EST) Received: from smtp-relay-1.Adobe.COM (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA16901 for ; Thu, 1 Mar 2001 14:45:58 -0500 Received: from inner-relay-2.Adobe.COM (inner-relay-2.corp.adobe.com [153.32.1.52]) by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id LAA03211 for ; Thu, 1 Mar 2001 11:49:07 -0800 (PST) Received: from mailsj-v1.corp.adobe.com by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id LAA19460; Thu, 1 Mar 2001 11:45:19 -0800 (PST) Received: from [153.32.35.102] ([153.32.35.102]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id G9JAVP00.3G0; Thu, 1 Mar 2001 11:45:25 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com (Unverified) Message-Id: In-Reply-To: <20010301003355.Y2297@lyra.org> References: <001001c0a1e1$8761eff0$0c77b2d1@win2k> <20010228165415.N2297@lyra.org> <000c01c0a21c$d3fed090$0c77b2d1@win2k> <20010301003355.Y2297@lyra.org> Date: Thu, 1 Mar 2001 10:35:51 -0500 To: Greg Stein From: "Dan Brotsky" Cc: w3c-dist-auth@w3.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: UTF-8 Encoding Question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4663 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 12:33 AM -0800 3/1/01, Greg Stein wrote: >That would be a good heuristic for handling this. > >We could augment the DAV:href element with an optional attribute, like this: > > D:original-charset="iso-8859-1">http://some.host/Magn%FCs.txt >and > http://some.host/C%C3%A9sar.txt > >That will help within the responses (if a server supplies it, then you don't >have to guess; otherwise, fall back to your heuristic). This certainly would be a helpful thing for servers to say to clients (although maybe in some other way), and I second your request to JimW about adding it as an issue. > We'd still need a >way to determine the original charset of the Request-URI, though, to fully >solve the problem. I think there's a slightly different way to approach this, especially since (in general) there's no way to determine the original charset of the client request. 1. In situations where a returned URI in the response was present in the client request, I think the server really has to return it exactly as it was submitted. Otherwise a lot of clients are going to get really confused, because for sure they're just looking for what they sent and not expecting to get into all sorts of "oh it's really the same in canonical form" discussions. 2. In situations where a returned URI in the response is not in the original request, the server is free to use whatever encoding it's going to use for path segments, and it can tell the client what is (either specifically as in Greg's proposal above or more generally via an OPTIONS setting or some such). As both clients and servers get smarter about this issue, then presumably the distinction between these cases starts going away (and it becomes less important for servers to say what encoding they're using for path segments). But on the way there this approach allows for backward compatibility with existing clients that are unaware of these issues without servers having to guess. And it has the added advantage of not breaking any client/server combinations that currently work. dan From w3c-dist-auth-request@w3.org Thu Mar 1 14:56: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 OAA20255 for ; Thu, 1 Mar 2001 14:56:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA10084; Thu, 1 Mar 2001 14:46:23 -0500 (EST) Resent-Date: Thu, 1 Mar 2001 14:46:23 -0500 (EST) Resent-Message-Id: <200103011946.OAA10084@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 OAA10056 for ; Thu, 1 Mar 2001 14:46:17 -0500 (EST) Received: from smtp-relay-2.Adobe.COM (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA16923 for ; Thu, 1 Mar 2001 14:46:14 -0500 Received: from inner-relay-2.Adobe.COM (inner-relay-2.corp.adobe.com [153.32.1.52]) by smtp-relay-2.Adobe.COM (8.8.6) with ESMTP id LAA27334 for ; Thu, 1 Mar 2001 11:50:01 -0800 (PST) Received: from mailsj-v1.corp.adobe.com by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id LAA19478; Thu, 1 Mar 2001 11:45:27 -0800 (PST) Received: from [153.32.35.102] ([153.32.35.102]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id G9JAVY00.7FV; Thu, 1 Mar 2001 11:45:34 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com (Unverified) Message-Id: In-Reply-To: References: Date: Thu, 1 Mar 2001 10:47:50 -0500 To: "Dylan Barrell" From: "Dan Brotsky" Cc: "Greg Stein" , "John Glavin" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: UTF-8 Encoding Question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4664 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 9:10 AM -0800 3/1/01, Dylan Barrell wrote: >Why, if webDAV is an extension of HTTP and HTTP specifies that the default >character set is ISO-8859-1 unless specified in the header, should it >therefore not be possible for the server to determine the character set from >the request header? The character set of the *body* and the character set of the *request url* are entirely different things. The HTTP spec does not specify a default character set for path-segments or other segments in URLs, and the various URL/URI specs (as currently officially updated) don't do this either. dan From w3c-dist-auth-request@w3.org Thu Mar 1 15:12:46 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 PAA20953 for ; Thu, 1 Mar 2001 15:12:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA10991; Thu, 1 Mar 2001 15:05:15 -0500 (EST) Resent-Date: Thu, 1 Mar 2001 15:05:15 -0500 (EST) Resent-Message-Id: <200103012005.PAA10991@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 PAA10961 for ; Thu, 1 Mar 2001 15:05:08 -0500 (EST) Received: from localhost.localdomain ([216.52.68.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA20124 for ; Thu, 1 Mar 2001 15:05:07 -0500 Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f21KBOf10139 for ; Thu, 1 Mar 2001 15:11:24 -0500 Message-ID: <3A9EACEA.A3E38DD6@ecal.com> Date: Thu, 01 Mar 2001 15:11: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 References: <001001c0a1e1$8761eff0$0c77b2d1@win2k> <20010228165415.N2297@lyra.org> <000c01c0a21c$d3fed090$0c77b2d1@win2k> <20010301003355.Y2297@lyra.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: UTF-8 Encoding Question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4665 X-Loop: w3c-dist-auth@w3.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 Dan Brotsky wrote: > > http://some.host/C%C3%A9sar.txt > > This certainly would be a helpful thing for servers to say to clients > (although maybe in some other way), and I second your request to JimW > about adding it as an issue. It might be better to wait and see whether IRIs take off (; broadly, the approach is to define that IRIs are like URLs, but in Unicode; to use an IRI in a context that demands a URL, you encode it in UTF-8, then apply %-encoding as normal). No sense creating two separate mechanisms to solve the same problem. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Never underestimate the power of human | |francis@ecal.com|stupidity. --I forget who | \==============================================================/ From w3c-dist-auth-request@w3.org Thu Mar 1 16:06:35 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 QAA23041 for ; Thu, 1 Mar 2001 16:06:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA13643; Thu, 1 Mar 2001 15:51:30 -0500 (EST) Resent-Date: Thu, 1 Mar 2001 15:51:30 -0500 (EST) Resent-Message-Id: <200103012051.PAA13643@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 PAA13603 for ; Thu, 1 Mar 2001 15:51:23 -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 PAA25310; Thu, 1 Mar 2001 15:51:23 -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 PAA60718; Thu, 1 Mar 2001 15:50:12 -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 PAA71054; Thu, 1 Mar 2001 15:47:22 -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: Thu, 1 Mar 2001 15:38:23 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.6a |January 17, 2001) at 03/01/2001 03:51:18 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/4666 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree that rfc2616 doesn't say nearly enough about OPTIONS and Allow:. I do wish it would say for example if OPTIONS should list GET on a resource that will return 404 Not Found for a GET on that URI. Or not list GET. Or if OPTIONS itself should return 404. (As per jigsaw.) That would give us a feel for the philosophy behind OPTIONS. Their current philosophy seems to be to say little about OPTIONS and that's why I suggested that we do the same. Anyone else have any opinions on this J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Mar 1 16:40: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 QAA24730 for ; Thu, 1 Mar 2001 16:40:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA15205; Thu, 1 Mar 2001 16:30:50 -0500 (EST) Resent-Date: Thu, 1 Mar 2001 16:30:50 -0500 (EST) Resent-Message-Id: <200103012130.QAA15205@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 QAA15185 for ; Thu, 1 Mar 2001 16:30:46 -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 QAA29008 for ; Thu, 1 Mar 2001 16:29:29 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id NAA08874; Thu, 1 Mar 2001 13:27:42 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Thu, 1 Mar 2001 13:27:41 -0800 From: Greg Stein To: "Pill, Juergen" Cc: "'w3c-dist-auth@w3.org'" Message-ID: <20010301132741.W2297@lyra.org> Mail-Followup-To: "Pill, Juergen" , "'w3c-dist-auth@w3.org'" References: <2B1792E820ACD411AD5A00508BF9A3FC01410104@daemsg03.software-ag.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <2B1792E820ACD411AD5A00508BF9A3FC01410104@daemsg03.software-ag.de>; from Juergen.Pill@softwareag.com on Thu, Mar 01, 2001 at 04:14:35PM +0100 X-URL: http://www.lyra.org/greg/ Subject: Re: unlock question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4667 X-Loop: w3c-dist-auth@w3.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 Thu, Mar 01, 2001 at 04:14:35PM +0100, Pill, Juergen wrote: > > What should a Webdav enabled server return in case of the unlock method and > a provided lock token, which does not exist (for this resource)? > Assuming the resource is already locked, would it be OK to return a 204 (no > content) or would be an error message better (which one)? mod_dav returns 400 (Bad Request) whether the resource has other locks on it or not. The client should have submitted an UNLOCK with a proper lock token. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Mar 1 17:23:04 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 RAA26323 for ; Thu, 1 Mar 2001 17:23:03 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA16392; Thu, 1 Mar 2001 17:10:05 -0500 (EST) Resent-Date: Thu, 1 Mar 2001 17:10:05 -0500 (EST) Resent-Message-Id: <200103012210.RAA16392@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 RAA16364 for ; Thu, 1 Mar 2001 17:09:55 -0500 (EST) Received: from smtp-relay-1.Adobe.COM (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA00459 for ; Thu, 1 Mar 2001 17:09:54 -0500 Received: from inner-relay-1.Adobe.COM (inner-relay-1.corp.adobe.com [153.32.1.51]) by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id OAA22654 for ; Thu, 1 Mar 2001 14:13:02 -0800 (PST) Received: from mailsj-v1.corp.adobe.com by inner-relay-1.Adobe.COM (8.8.5) with ESMTP id OAA07511; Thu, 1 Mar 2001 14:08:30 -0800 (PST) Received: from [153.32.35.102] ([153.32.35.102]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id G9JHJL00.CMH; Thu, 1 Mar 2001 14:09:21 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: <3A9EACEA.A3E38DD6@ecal.com> References: <001001c0a1e1$8761eff0$0c77b2d1@win2k> <20010228165415.N2297@lyra.org> <000c01c0a21c$d3fed090$0c77b2d1@win2k> <20010301003355.Y2297@lyra.org> <3A9EACEA.A3E38DD6@ecal.com> Date: Thu, 1 Mar 2001 14:09:20 -0500 To: John Stracke From: "Dan Brotsky" Cc: w3c-dist-auth@w3.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: UTF-8 Encoding Question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4668 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 3:11 PM -0500 3/1/01, John Stracke wrote: >Dan Brotsky wrote: > >> > >D:original-charset="utf-8">http://some.host/C%C3%A9sar.txt >> >> This certainly would be a helpful thing for servers to say to clients >> (although maybe in some other way), and I second your request to JimW >> about adding it as an issue. > >It might be better to wait and see whether IRIs take off >(; broadly, the approach is to >define that IRIs >are like URLs, but in Unicode; to use an IRI in a context that >demands a URL, you >encode it in UTF-8, then apply %-encoding as normal). No sense creating two >separate mechanisms to solve the same problem. I'm a big fan of IRI's (as you can tell from my earlier emails) but I think the issue here is the one of what to do when clients submit URIs with other encodings that the server returns to them in a body. Even when servers go to IRI discipline for URLs they generate, they shouldn't necessarily break clients who expect to get back what they asked for :^). Here's another way of phrasing this issue that makes it not be about encoding: The DAV spec says that it is *resources* that have properties, not *urls*, and that many different urls can refer to the same resource. When a client requests info about a resource by using a particular URL, but the server sends back information about a resource named by another URL, what guarantees does the client have about the returned URL: 1. Is it guaranteed to refer, in the context of this response, to the resource that the client asked about in the request? 2. Is it guaranteed *always* to refer to that same resource? (In some sense, is there the same info in this response that one could glean from a permanent redirect?) In this formulation, note that differences in %-escaping conventions can lead to different URLs that encode the same octet-stream. Are there special conventions that apply in this case? dan From w3c-dist-auth-request@w3.org Thu Mar 1 18:03:40 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 SAA27549 for ; Thu, 1 Mar 2001 18:03:35 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA17751; Thu, 1 Mar 2001 17:52:40 -0500 (EST) Resent-Date: Thu, 1 Mar 2001 17:52:40 -0500 (EST) Resent-Message-Id: <200103012252.RAA17751@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 RAA17731 for ; Thu, 1 Mar 2001 17:52:36 -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 RAA04145 for ; Thu, 1 Mar 2001 17:51:35 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id OAA09227; Thu, 1 Mar 2001 14:49:10 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Thu, 1 Mar 2001 14:49:09 -0800 From: Greg Stein To: Dan Brotsky Cc: w3c-dist-auth@w3.org Message-ID: <20010301144909.F2297@lyra.org> Mail-Followup-To: Dan Brotsky , w3c-dist-auth@w3.org References: <2B1792E820ACD411AD5A00508BF9A3FC01410104@daemsg03.software-ag.de> <20010301132741.W2297@lyra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from dbrotsky@Adobe.COM on Thu, Mar 01, 2001 at 02:13:43PM -0500 X-URL: http://www.lyra.org/greg/ Subject: Re: unlock question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4669 X-Loop: w3c-dist-auth@w3.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 Thu, Mar 01, 2001 at 02:13:43PM -0500, Dan Brotsky wrote: > >On Thu, Mar 01, 2001 at 04:14:35PM +0100, Pill, Juergen wrote: > >> > >> What should a Webdav enabled server return in case of the unlock method and > >> a provided lock token, which does not exist (for this resource)? > >> Assuming the resource is already locked, would it be OK to return a 204 (no > >> content) or would be an error message better (which one)? > > > >mod_dav returns 400 (Bad Request) whether the resource has other locks on it > >or not. The client should have submitted an UNLOCK with a proper lock token. > > > >Cheers, > >-g > > Greg, > > Why not 412? I thought servers were always supposed to return 412 to > requests that provided invalid state preconditions? The Lock-Token: header is not a precondition. It is an input parameter to the UNLOCK method. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Mar 1 20:39: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 UAA00941 for ; Thu, 1 Mar 2001 20:39:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA23238; Thu, 1 Mar 2001 20:32:26 -0500 (EST) Resent-Date: Thu, 1 Mar 2001 20:32:26 -0500 (EST) Resent-Message-Id: <200103020132.UAA23238@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 UAA23218 for ; Thu, 1 Mar 2001 20:32:21 -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 UAA16674 for ; Thu, 1 Mar 2001 20:32:20 -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 UAA143020; Thu, 1 Mar 2001 20:31:10 -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 UAA76796; Thu, 1 Mar 2001 20:28:19 -0500 Importance: Normal To: Greg Stein Cc: Dan Brotsky , w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Thu, 1 Mar 2001 20:14:26 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.6a |January 17, 2001) at 03/01/2001 08:32:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: unlock question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4670 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Greg, Does mod_dav destroy the lock if you don't specify a URL, just the lock-token? For example... UNLOCK * J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Mar 1 21:47:42 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 VAA03194 for ; Thu, 1 Mar 2001 21:47:40 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA25796; Thu, 1 Mar 2001 21:41:29 -0500 (EST) Resent-Date: Thu, 1 Mar 2001 21:41:29 -0500 (EST) Resent-Message-Id: <200103020241.VAA25796@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 VAA25776 for ; Thu, 1 Mar 2001 21:41:25 -0500 (EST) Received: from mx01-a.netapp.com ([198.95.226.53]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA21177 for ; Thu, 1 Mar 2001 21:41:24 -0500 Received: from frejya.corp.netapp.com (frejya.corp.netapp.com [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f222eoG23011 for ; Thu, 1 Mar 2001 18:40:50 -0800 (PST) Received: from ussvlexc01.corp.netapp.com (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f222enr20211 for ; Thu, 1 Mar 2001 18:40:49 -0800 (PST) Received: by ussvlexc01.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Mar 2001 18:40:48 -0800 Message-ID: From: "Benn, Paul" To: "'w3c-dist-auth@w3.org'" Date: Thu, 1 Mar 2001 18:41:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: trouble connecting to IIS5 from OS X PB Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4671 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Sorry if this isn't really the right place to ask this question..... In experimenting with WebDAV, we can connect to an IIS 5 machine from every MS client that we've tried. When we attempt from OS X, we get the error: "The operation could not be completed because the item could not be found." Could we have a configuration error or is there something known to be broken in OS X PB? Thanks for any advice. Paul Here's a trace: Hello World! Arguments given: Arg # 1: pbmac2.cap File signature: GMBU Frame: 1 client -> server 1077 ____S_ Frame: 2 server -> client 1077 _A__S_ Frame: 3 client -> server 1077 _A____ Frame: 4 client -> server 1077 _AP___ OPTIONS / HTTP/1.1 User-Agent: fetch/1.0 Darwin/1.2 (Power Macintosh) Accept: */* Host: clab-c1-21.win2ktest.lab.netapp.com:80 Frame: 5 server -> client 1077 _AP___ HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Thu, 01 Mar 2001 22:46:33 GMT MS-Author-Via: DAV Content-Length: 0 Accept-Ranges: none DASL: DAV: 1, 2 Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH Allow: OPTIONS, TRACE, GET, HEAD, DELETE, COPY, MOVE, PROPFIND, PROPPATCH, SEARCH, MKCOL, LOCK, UNLOCK Cache-Control: private Frame: 6 client -> server 1077 _AP___ PROPFIND / HTTP/1.1 User-Agent: fetch/1.0 Darwin/1.2 (Power Macintosh) Accept: */* Host: clab-c1-21.win2ktest.lab.netapp.com:80 Depth: 0 Frame: 7 server -> client 1077 _AP___ HTTP/1.1 411 Length Required Server: Microsoft-IIS/5.0 Date: Thu, 01 Mar 2001 22:46:33 GMT Connection: close Content-Type: text/html Content-Length: 50 Frame: 8 server -> client 1077 _AP__F

HTTP/1.1 411 Length Required

Frame: 9 client -> server 1077 _A____ Frame: 10 client -> server 1077 _A___F Frame: 11 server -> client 1077 _A____ Goodbye. From w3c-dist-auth-request@w3.org Fri Mar 2 14:21: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 OAA13916 for ; Fri, 2 Mar 2001 14:21:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA28310; Fri, 2 Mar 2001 14:13:28 -0500 (EST) Resent-Date: Fri, 2 Mar 2001 14:13:28 -0500 (EST) Resent-Message-Id: <200103021913.OAA28310@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 OAA28272 for ; Fri, 2 Mar 2001 14:13:05 -0500 (EST) Received: from smtp-relay-1.Adobe.COM (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA04920 for ; Fri, 2 Mar 2001 14:13:04 -0500 Received: from inner-relay-1.Adobe.COM (inner-relay-1.corp.adobe.com [153.32.1.51]) by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id LAA04877 for ; Fri, 2 Mar 2001 11:16:11 -0800 (PST) Received: from mailsj-v1.corp.adobe.com by inner-relay-1.Adobe.COM (8.8.5) with ESMTP id LAA21186; Fri, 2 Mar 2001 11:11:37 -0800 (PST) Received: from [192.168.1.8] ([130.248.188.66]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id G9L40S00.SM6; Fri, 2 Mar 2001 11:12:28 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: <20010301144909.F2297@lyra.org> References: <2B1792E820ACD411AD5A00508BF9A3FC01410104@daemsg03.software-ag.de> <20010301132741.W2297@lyra.org> <20010301144909.F2297@lyra.org> Date: Fri, 2 Mar 2001 11:12:23 -0800 To: Greg Stein From: "Dan Brotsky" Cc: w3c-dist-auth@w3.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: unlock question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4672 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 2:49 PM -0800 3/1/01, Greg Stein wrote: > > >mod_dav returns 400 (Bad Request) whether the resource has other >locks on it >> >or not. The client should have submitted an UNLOCK with a proper >>lock token. >> > >> >Cheers, >> >-g >> >> Greg, >> >> Why not 412? I thought servers were always supposed to return 412 to >> requests that provided invalid state preconditions? > >The Lock-Token: header is not a precondition. It is an input parameter to >the UNLOCK method. Sorry I wasn't clear enough. I wasn't contesting that 400 is a valid response. I was trying to ask you for your design rationale in choosing to return 400 rather than 412. One of the problems I have with the spec is that it's very vague about specific error responses in some situations, and very precise in others, with no apparent rationale. For example, it specifically says that 412 must be returned when the server can't honor the type of lock request a client makes, but says nothing about which error should be returned in the case of a missing (or incorrect) token with unlock. In general, it's a lot easier to write clients if known modes of failure that relate to the semantics of the request get specific error returns. In this particular case, the spec is very clear in section 7.6 that all methods which "interact with" (interpreted as "change") a write-locked resource must include an IF header specifying the lock token. If the lock token is missing, they are to get a 412 (since it's an IF). Unfortunately, the example for UNLOCK does not show any such IF header, so presumably the LOCK-TOKEN header is supposed to be doing double duty here (both specifying what to unlock and specifying the required precondition for every "interacting" method). Thus a missing or incorrect lock token might well receive a 412. This would have some advantages for clients, since it could be specifically interpreted as meaning "that's the wrong lock token" but 400 could mean anything. Note that there's a separate issue here for servers that support non-exclusive locks and also support write locks. The issue is that both LOCK and UNLOCK are clearly "interacting methods" in the sense of section 7.6, but UNLOCK is not shown to need an IF header. If a server issues a write lock on a resource that has some other kind of non-exclusive lock on it, then it ought to reject an unlock for that other kind of lock if the UNLOCK call doesn't specify an IF header with the token of the write lock. But then why shouldn't it reject an UNLOCK of the write lock itself if it doesn't have such an IF header? JimW: Can you add these issues (maybe as one issue) to the issues list? 1. Does UNLOCK require IF header specifying applicable write lock token? 2. UNLOCK should return 412 if valid lock token is not supplied as UNLOCK-TOKEN. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 888-461-0237 2-way pager email: From w3c-dist-auth-request@w3.org Fri Mar 2 16:52: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 QAA21191 for ; Fri, 2 Mar 2001 16:52:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA05317; Fri, 2 Mar 2001 16:42:49 -0500 (EST) Resent-Date: Fri, 2 Mar 2001 16:42:49 -0500 (EST) Resent-Message-Id: <200103022142.QAA05317@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 QAA05297 for ; Fri, 2 Mar 2001 16:42:42 -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 QAA19677 for ; Fri, 2 Mar 2001 16:42:39 -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 QAA80956; Fri, 2 Mar 2001 16:41:23 -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 QAA17444; Fri, 2 Mar 2001 16:38:32 -0500 Importance: Normal To: "Dan Brotsky" Cc: Greg Stein , w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Fri, 2 Mar 2001 16:37:11 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.6a |January 17, 2001) at 03/02/2001 04:42:30 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: unlock question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4673 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > 1. Does UNLOCK require IF header specifying applicable write lock token? I've tentitively added this as...UNLOCK_NEEDS_IF_HEADER I believe that the current behavior is appropriate in that the only thing the server needs to verify is that the client is aware of that lock and the requestor is the principal that owns it. If the client is explicitly requesting that the lock be destroyed, the client obviously knows about the lock and it's redundant to ask them to provide it in a second header. I think we need to treat the IF header not as a way for the server to confirm that the client knows about a lock, but (as documented) a way for a client to put a precondition on an request. If you look at the documentation for the IF header, this is the only thing it talks about. And if the server needs to verify that a client knows about a lock, it should be adequate for the client to mention the lock in a any documented headers that we enumerate to verify that the client knows about the lock. > 2. UNLOCK should return 412 if valid lock token is not supplied as > UNLOCK-TOKEN. I've tentatively added this as...UNLOCK_WITHOUT_GOOD_TOKEN J. From w3c-dist-auth-request@w3.org Fri Mar 2 17:27: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 RAA22585 for ; Fri, 2 Mar 2001 17:27:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA06979; Fri, 2 Mar 2001 17:21:57 -0500 (EST) Resent-Date: Fri, 2 Mar 2001 17:21:57 -0500 (EST) Resent-Message-Id: <200103022221.RAA06979@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 RAA06954 for ; Fri, 2 Mar 2001 17:21:48 -0500 (EST) Received: from localhost.localdomain ([216.52.68.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA23294 for ; Fri, 2 Mar 2001 17:21:48 -0500 Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f22MRxq13595; Fri, 2 Mar 2001 17:28:00 -0500 Message-ID: <3A9FAA12.6504AE55@ecal.com> Date: Fri, 02 Mar 2001 09:11:30 -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: "Benn, Paul" CC: "'w3c-dist-auth@w3.org'" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: trouble connecting to IIS5 from OS X PB Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4674 X-Loop: w3c-dist-auth@w3.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 "Benn, Paul" wrote: > PROPFIND / HTTP/1.1 User-Agent: fetch/1.0 Darwin/1.2 (Power Macintosh) > Accept: */* Host: clab-c1-21.win2ktest.lab.netapp.com:80 Depth: 0 Frame: 7 > server -> client 1077 _AP___ > HTTP/1.1 411 Length Required Seems pretty clear: IIS5 wants a Content-Length: 0 if you don't have a message body. This seems awkward, but I'm not actually sure it violates the specs. 2518/8.1 says: A client may choose not to submit a request body. An empty PROPFIND request body MUST be treated as a request for the names and values of all properties. But in 2616/4.4 (which discusses how to determine the length of the body), the only way I see to infer that no body is present is to know that the message MUST NOT have a body (e.g., if it's a GET request or a HEAD response), or else to see that the server closed the connection after the message (does not work for requests). So I think IIS5 is probably within its rights to require Content-Length: 0...though I personally would have written it to be more forgiving, and assume that no Content-Length: and no Transfer-Encoding: implies no body. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Think of it as evolution in action. | |francis@ecal.com| | \==============================================================/ From w3c-dist-auth-request@w3.org Fri Mar 2 17:54:28 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 RAA23581 for ; Fri, 2 Mar 2001 17:54:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA07701; Fri, 2 Mar 2001 17:45:42 -0500 (EST) Resent-Date: Fri, 2 Mar 2001 17:45:42 -0500 (EST) Resent-Message-Id: <200103022245.RAA07701@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 RAA07679 for ; Fri, 2 Mar 2001 17:45:33 -0500 (EST) Received: from mx01-a.netapp.com ([198.95.226.53]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA25154 for ; Fri, 2 Mar 2001 17:45:30 -0500 Received: from frejya.corp.netapp.com (frejya.corp.netapp.com [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f22MipG06817 for ; Fri, 2 Mar 2001 14:44:51 -0800 (PST) Received: from ussvlexc06.corp.netapp.com (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f22Mipi04880 for ; Fri, 2 Mar 2001 14:44:51 -0800 (PST) Received: by ussvlexc06.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Mar 2001 14:44:50 -0800 Message-ID: From: "Benn, Paul" To: "'w3c-dist-auth@w3.org'" Date: Fri, 2 Mar 2001 14:45:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: trouble connecting to IIS5 from OS X PB Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4676 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Perhaps this is an OSX-ism which will be fixed when it is released this month..?? -----Original Message----- From: John Stracke [mailto:francis@ecal.com] Sent: Friday, March 02, 2001 6:12 AM To: Benn, Paul Cc: 'w3c-dist-auth@w3.org' Subject: Re: trouble connecting to IIS5 from OS X PB But in 2616/4.4 (which discusses how to determine the length of the body), the only way I see to infer that no body is present is to know that the message MUST NOT have a body (e.g., if it's a GET request or a HEAD response), or else to see that the server closed the connection after the message (does not work for requests). So I think IIS5 is probably within its rights to require Content-Length: 0...though I personally would have written it to be more forgiving, and assume that no Content-Length: and no Transfer-Encoding: implies no body. From w3c-dist-auth-request@w3.org Fri Mar 2 17:54: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 RAA23592 for ; Fri, 2 Mar 2001 17:54:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA07609; Fri, 2 Mar 2001 17:45:10 -0500 (EST) Resent-Date: Fri, 2 Mar 2001 17:45:10 -0500 (EST) Resent-Message-Id: <200103022245.RAA07609@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 RAA07522 for ; Fri, 2 Mar 2001 17:44:59 -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 RAA25072 for ; Fri, 2 Mar 2001 17:44:52 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id OAA03324; Fri, 2 Mar 2001 14:45:00 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Fri, 2 Mar 2001 14:44:59 -0800 From: Greg Stein To: "Benn, Paul" , warner.c@apple.com Cc: "'w3c-dist-auth@w3.org'" Message-ID: <20010302144459.L2297@lyra.org> Mail-Followup-To: "Benn, Paul" , warner.c@apple.com, "'w3c-dist-auth@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 paul.benn@netapp.com on Thu, Mar 01, 2001 at 06:41:19PM -0800 X-URL: http://www.lyra.org/greg/ Subject: Re: trouble connecting to IIS5 from OS X PB Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4675 X-Loop: w3c-dist-auth@w3.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 bug in the MacOS X client DAV library. When it does a PROPFIND, it doesn't send a Content-Length (as you can see below). A friend of mine at Adobe just ran into this a week or two ago during some interoperability testing, but I thought it was just their URLAccess library (rather than a general issue). The rules on Content-Length are specified in section 4.4 of RFC 2616. If a C-L isn't provided, then Apache happens to use a length==0 and assume there is no body (i.e. if there is, then it'll monkey up the next request). IIS returns 411. Both are valid approaches. My Adobe friend just manually inserted a Content-Length: 0 in the request header when operating on the MacOS platform. That is doable from code, of course; if their webdavfs doesn't do it (I can't tell what you're using to talk to the IIS5 box), then you're stuck. Cheers, -g On Thu, Mar 01, 2001 at 06:41:19PM -0800, Benn, Paul wrote: > Sorry if this isn't really the right place to ask this question..... In > experimenting with WebDAV, we can connect to an IIS 5 machine from every MS > client that we've tried. When we attempt from OS X, we get the error: "The > operation could not be completed because the item could not be found." > Could we have a configuration error or is there something known to be broken > in OS X PB? > > Thanks for any advice. > > Paul > > > Here's a trace: > > Hello World! > Arguments given: > Arg # 1: pbmac2.cap > File signature: GMBU > Frame: 1 client -> server 1077 ____S_ > Frame: 2 server -> client 1077 _A__S_ > Frame: 3 client -> server 1077 _A____ > Frame: 4 client -> server 1077 _AP___ > OPTIONS / HTTP/1.1 User-Agent: fetch/1.0 Darwin/1.2 (Power Macintosh) > Accept: */* Host: clab-c1-21.win2ktest.lab.netapp.com:80 Frame: 5 server -> > client 1077 _AP___ > HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Thu, 01 Mar 2001 22:46:33 > GMT MS-Author-Via: DAV Content-Length: 0 Accept-Ranges: none DASL: > DAV: 1, 2 Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, > MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH Allow: OPTIONS, TRACE, GET, > HEAD, DELETE, COPY, MOVE, PROPFIND, PROPPATCH, SEARCH, MKCOL, LOCK, UNLOCK > Cache-Control: private Frame: 6 client -> server 1077 _AP___ > PROPFIND / HTTP/1.1 User-Agent: fetch/1.0 Darwin/1.2 (Power Macintosh) > Accept: */* Host: clab-c1-21.win2ktest.lab.netapp.com:80 Depth: 0 Frame: 7 > server -> client 1077 _AP___ > HTTP/1.1 411 Length Required Server: Microsoft-IIS/5.0 Date: Thu, 01 Mar > 2001 22:46:33 GMT Connection: close Content-Type: text/html Content-Length: > 50 Frame: 8 server -> client 1077 _AP__F >

HTTP/1.1 411 Length Required

Frame: 9 client -> server > 1077 _A____ > Frame: 10 client -> server 1077 _A___F > Frame: 11 server -> client 1077 _A____ > Goodbye. -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Mar 2 17:55: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 RAA23687 for ; Fri, 2 Mar 2001 17:55:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA07864; Fri, 2 Mar 2001 17:49:15 -0500 (EST) Resent-Date: Fri, 2 Mar 2001 17:49:15 -0500 (EST) Resent-Message-Id: <200103022249.RAA07864@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 RAA07840 for ; Fri, 2 Mar 2001 17:49:07 -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 RAA25536 for ; Fri, 2 Mar 2001 17:49:02 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id OAA03333; Fri, 2 Mar 2001 14:49:25 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Fri, 2 Mar 2001 14:49:25 -0800 From: Greg Stein To: Jason Crawford Cc: w3c-dist-auth@w3.org Message-ID: <20010302144925.M2297@lyra.org> Mail-Followup-To: Jason Crawford , w3c-dist-auth@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 Thu, Mar 01, 2001 at 08:14:26PM -0500 X-URL: http://www.lyra.org/greg/ Subject: Re: unlock question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4677 X-Loop: w3c-dist-auth@w3.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 Thu, Mar 01, 2001 at 08:14:26PM -0500, Jason Crawford wrote: > Greg, > Does mod_dav destroy the lock if you don't specify a URL, just the > lock-token? For example... > > UNLOCK * Nope. Only "OPTIONS *" is recognized. The above construct returns 404. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Mar 2 18:14:21 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 SAA24297 for ; Fri, 2 Mar 2001 18:14:18 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA08800; Fri, 2 Mar 2001 18:08:00 -0500 (EST) Resent-Date: Fri, 2 Mar 2001 18:08:00 -0500 (EST) Resent-Message-Id: <200103022308.SAA08800@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 SAA08776 for ; Fri, 2 Mar 2001 18:07:52 -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 SAA27035 for ; Fri, 2 Mar 2001 18:07:46 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id PAA03349; Fri, 2 Mar 2001 15:08:15 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Fri, 2 Mar 2001 15:08:14 -0800 From: Greg Stein To: Dan Brotsky Cc: w3c-dist-auth@w3.org Message-ID: <20010302150814.N2297@lyra.org> Mail-Followup-To: Dan Brotsky , w3c-dist-auth@w3.org References: <2B1792E820ACD411AD5A00508BF9A3FC01410104@daemsg03.software-ag.de> <20010301132741.W2297@lyra.org> <20010301144909.F2297@lyra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from dbrotsky@Adobe.COM on Fri, Mar 02, 2001 at 11:12:23AM -0800 X-URL: http://www.lyra.org/greg/ Subject: Re: unlock question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4678 X-Loop: w3c-dist-auth@w3.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, Mar 02, 2001 at 11:12:23AM -0800, Dan Brotsky wrote: > At 2:49 PM -0800 3/1/01, Greg Stein wrote: > > > >mod_dav returns 400 (Bad Request) whether the resource has other > >locks on it > >> >or not. The client should have submitted an UNLOCK with a proper > >>lock token. > >> > > >> >Cheers, > >> >-g > >> > >> Greg, > >> > >> Why not 412? I thought servers were always supposed to return 412 to > >> requests that provided invalid state preconditions? > > > >The Lock-Token: header is not a precondition. It is an input parameter to > >the UNLOCK method. > > Sorry I wasn't clear enough. I wasn't contesting that 400 is a valid > response. I was trying to ask you for your design rationale in > choosing to return 400 rather than 412. As I explained :-) ... The lock token is an input parameter to the UNLOCK method. If you don't supply a valid token, then you've sent in a bad request. The If: header is used to specify a precondition for the operation. If the precondition specified by the If: fails, then you get a 412. UNLOCK operations use the Lock-Token as the parameter, not an If: header. If it *did* use the If: header, then how could you know which locktoken to unlock if multiple were present? What if you wanted to assert a different locktoken than the one that you're intending to unlock? Thus, the Lock-Token is required for UNLOCK, and the If: header is just that: an assertion. Based on all that, an UNLOCK with an unknown locktoken (well, unknown on that resource) will generate a 400. If the UNLOCK contains an If: header, and the assertion(s) in the If: header fail, then you'll get a 412. If the If: header fails *and* you have a bad locktoken, then you'll get either a 400 or a 412 based on various internal conditions (specifically: a 400 if the resource has no locks, a 412 if the resource has locks but the If: assertion(s) fail). > One of the problems I have with the spec is that it's very vague > about specific error responses in some situations, and very precise > in others, with no apparent rationale. For example, it specifically > says that 412 must be returned when the server can't honor the type > of lock request a client makes, but says nothing about which error > should be returned in the case of a missing (or incorrect) token with > unlock. In general, it's a lot easier to write clients if known > modes of failure that relate to the semantics of the request get > specific error returns. Agreed. > In this particular case, the spec is very clear in section 7.6 that > all methods which "interact with" (interpreted as "change") a > write-locked resource must include an IF header specifying the lock > token. I can understand how it can be read that way, but disagree with it. I don't see an UNLOCK as changing the resource. The UNLOCK will alter some live properties, but live props are defined as changeable at any time, so I don't see them as "part of" the resource. > If the lock token is missing, they are to get a 412 (since > it's an IF). Not entirely true. The If: header doesn't have to make an assertion on the resource identified by the Request-URI. The locktoken present in the If: header might not be on the requested resource, it might be on something else altogether. Thus, the If: header could pass, but none of the locktokens mentioned in the If: header are present on the requested resource. > Unfortunately, the example for UNLOCK does not show any > such IF header, so presumably the LOCK-TOKEN header is supposed to be > doing double duty here (both specifying what to unlock and specifying > the required precondition for every "interacting" method). The Lock-Token is not specifying a precondition. It is specifying a parameter to the UNLOCK method. Only the If: header specifies preconditions to the execution of a method. If the parameter is invalid, then you get a 400. >... > Note that there's a separate issue here for servers that support > non-exclusive locks and also support write locks. The issue is that > both LOCK and UNLOCK are clearly "interacting methods" in the sense > of section 7.6, I wouldn't say "clearly" :-) > but UNLOCK is not shown to need an IF header. If a > server issues a write lock on a resource that has some other kind of > non-exclusive lock on it, then it ought to reject an unlock for that > other kind of lock if the UNLOCK call doesn't specify an IF header > with the token of the write lock. The locks do not interact like that. You cannot install a lock that prevents another lock from being removed. Locks are about preventing change to the body and to (dead and some live) properties. >... > 1. Does UNLOCK require IF header specifying applicable write lock token? Adding an issue is certainly fine, but I'd answer this with "no". > 2. UNLOCK should return 412 if valid lock token is not supplied as > UNLOCK-TOKEN. I disagree. I believe the current behavior in mod_dav is correct, but am certainly willing to listen to why it may be wrong. See above for my reasoning about the current behavior. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Mar 2 18:35:43 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 SAA24633 for ; Fri, 2 Mar 2001 18:35:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA09264; Fri, 2 Mar 2001 18:25:15 -0500 (EST) Resent-Date: Fri, 2 Mar 2001 18:25:15 -0500 (EST) Resent-Message-Id: <200103022325.SAA09264@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 SAA09243 for ; Fri, 2 Mar 2001 18:25:10 -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 SAA28452 for ; Fri, 2 Mar 2001 18:25:06 -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 PAA03988 for ; Fri, 2 Mar 2001 15:25:10 -0800 (PST) From: "Jim Whitehead" To: "WebDAV WG" Date: Fri, 2 Mar 2001 15:24:09 -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: cgi-client for DAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4679 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Frans Dondorp [mailto:frans@ch.twi.tudelft.nl] Sent: Thursday, March 01, 2001 2:17 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] cgi-client for DAV A question from a DAV-newcomer: Does anyone know where I can find example code from which I can deduce a technique to get to a DAV-server (mod_dav) through a cgi-program? The problem I am dealing with is that I need to build a website as an interface to a DAV-server, where people can work with the files on the server and with the metadata of these files. Some sort of BSCW-thingy, but in this case with decent support for metadata. How do I use DAV-methods from within a browser? Using a form which calls a cgi-script which writes the correct headers is a solution, but not an elegant one. I'd rather call these methods directly, but how do I get around the problem of writing out those headers? And how do I include the XML-requestbody in a decent way?
and then what? Sincerely, Frans Dondorp Delft University of Technology From w3c-dist-auth-request@w3.org Fri Mar 2 19:07:24 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 TAA25138 for ; Fri, 2 Mar 2001 19:07:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA09719; Fri, 2 Mar 2001 18:52:54 -0500 (EST) Resent-Date: Fri, 2 Mar 2001 18:52:54 -0500 (EST) Resent-Message-Id: <200103022352.SAA09719@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 SAA09699 for ; Fri, 2 Mar 2001 18:52:50 -0500 (EST) Received: from smtp-relay-1.Adobe.COM (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA30494 for ; Fri, 2 Mar 2001 18:52:48 -0500 Received: from inner-relay-1.Adobe.COM (inner-relay-1.corp.adobe.com [153.32.1.51]) by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id PAA16708 for ; Fri, 2 Mar 2001 15:55:49 -0800 (PST) Received: from mailsj-v1.corp.adobe.com by inner-relay-1.Adobe.COM (8.8.5) with ESMTP id PAA08316; Fri, 2 Mar 2001 15:51:09 -0800 (PST) Received: from [192.168.1.8] ([130.248.188.66]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id G9LGYN00.KY4; Fri, 2 Mar 2001 15:51:59 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: References: Date: Fri, 2 Mar 2001 15:51:18 -0800 To: "Jason Crawford" From: "Dan Brotsky" Cc: w3c-dist-auth@w3.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: unlock question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4680 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 4:37 PM -0500 3/2/01, Jason Crawford wrote: > > 1. Does UNLOCK require IF header specifying applicable write lock token? > >I've tentitively added this as...UNLOCK_NEEDS_IF_HEADER > >I believe that the current behavior is appropriate in that the only thing >the server needs to verify is that the client is aware of that lock and the >requestor is the principal that owns it. If the client is explicitly >requesting that the lock be destroyed, the client obviously knows about the >lock and it's redundant to ask them to provide it in a second header. I agree that the current behavior is fine when the lock that would go in the IF header is the one that is in the LOCK-TOKEN header. > I >think we need to treat the IF header not as a way for the server to confirm >that the client knows about a lock, but (as documented) a way for a client >to put a precondition on an request. If you look at the documentation for >the IF header, this is the only thing it talks about. And if the server >needs to verify that a client knows about a lock, it should be adequate for >the client to mention the lock in a any documented headers that we >enumerate to verify that the client knows about the lock. I agree. The issue is when there is more than one lock that applies to the resource. Then I believe that the write lock needs to be specified in the IF header when an unlock is done on one of the other kinds of locks. In general I find the spec weak around the requirements on non-exclusive lock handling. > > 2. UNLOCK should return 412 if valid lock token is not supplied as >> UNLOCK-TOKEN. > >I've tentatively added this as...UNLOCK_WITHOUT_GOOD_TOKEN Thanks! Is there a more current version of the issues document than the one posted at http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html ? That one shows a last update of 7/2000 and there was another issue I had raised in September that I wasn't sure had made it on. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 888-461-0237 2-way pager email: From w3c-dist-auth-request@w3.org Fri Mar 2 19:58: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 TAA25735 for ; Fri, 2 Mar 2001 19:58:20 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA10666; Fri, 2 Mar 2001 19:52:50 -0500 (EST) Resent-Date: Fri, 2 Mar 2001 19:52:50 -0500 (EST) Resent-Message-Id: <200103030052.TAA10666@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 TAA10643 for ; Fri, 2 Mar 2001 19:52:46 -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 TAA02195 for ; Fri, 2 Mar 2001 19:52:45 -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 TAA126926 for ; Fri, 2 Mar 2001 19:51:42 -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 TAA18128 for ; Fri, 2 Mar 2001 19:48:44 -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, 2 Mar 2001 19:45:28 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.6a |January 17, 2001) at 03/02/2001 07:52:42 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: UTF-8 Encoding Question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4681 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > JimW: can we list this as an "Issue" for RFC 2518? It's now listed as URL_ENCODING_ISSUES and references this discussion. Let's go ahead and resolve this. From w3c-dist-auth-request@w3.org Fri Mar 2 20:35: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 UAA26075 for ; Fri, 2 Mar 2001 20:35:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA11556; Fri, 2 Mar 2001 20:29:31 -0500 (EST) Resent-Date: Fri, 2 Mar 2001 20:29:31 -0500 (EST) Resent-Message-Id: <200103030129.UAA11556@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 UAA11529 for ; Fri, 2 Mar 2001 20:29:25 -0500 (EST) Received: from smtp-relay-2.Adobe.COM (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA04640 for ; Fri, 2 Mar 2001 20:29:24 -0500 Received: from inner-relay-2.Adobe.COM (inner-relay-2.corp.adobe.com [153.32.1.52]) by smtp-relay-2.Adobe.COM (8.8.6) with ESMTP id RAA12730 for ; Fri, 2 Mar 2001 17:33:10 -0800 (PST) Received: from mailsj-v1.corp.adobe.com by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id RAA02710; Fri, 2 Mar 2001 17:28:36 -0800 (PST) Received: from [192.168.1.8] ([130.248.188.66]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id G9LLFV00.I9S; Fri, 2 Mar 2001 17:28:43 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: <20010302150814.N2297@lyra.org> References: <2B1792E820ACD411AD5A00508BF9A3FC01410104@daemsg03.software-ag.de> <20010301132741.W2297@lyra.org> <20010301144909.F2297@lyra.org> <20010302150814.N2297@lyra.org> Date: Fri, 2 Mar 2001 17:28:01 -0800 To: Greg Stein From: "Dan Brotsky" Cc: w3c-dist-auth@w3.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: unlock question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4682 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 3:08 PM -0800 3/2/01, Greg Stein wrote: >On Fri, Mar 02, 2001 at 11:12:23AM -0800, Dan Brotsky wrote: >> At 2:49 PM -0800 3/1/01, Greg Stein wrote: >> > > >mod_dav returns 400 (Bad Request) whether the resource has other >> >locks on it >> >> >or not. The client should have submitted an UNLOCK with a proper >> >>lock token. >> >> > >> >> >Cheers, >> >> >-g >> >> >> >> Greg, >> >> >> >> Why not 412? I thought servers were always supposed to return 412 to >> >> requests that provided invalid state preconditions? >> > >> >The Lock-Token: header is not a precondition. It is an input parameter to >> >the UNLOCK method. >> >> Sorry I wasn't clear enough. I wasn't contesting that 400 is a valid >> response. I was trying to ask you for your design rationale in >> choosing to return 400 rather than 412. > >As I explained :-) ... The lock token is an input parameter to the UNLOCK >method. If you don't supply a valid token, then you've sent in a bad >request. > >The If: header is used to specify a precondition for the operation. If the >precondition specified by the If: fails, then you get a 412. But you can get 412 in many other cases, not just as a result of a failed IF. (For example, if the server doesn't have the kind of lock you want.) It is clearly a (conceptual) precondition of unlocking a given lock that you have it. So I don't think returning 412 if you don't is much of a stretch. And it has the advantage of saying exactly why you failed. Clients that get 400-series errors back are often interested in recovering and trying again. Returning a 412 in this (eventually :^) specified case would allow a client to know they've actually lost their lock rather than made some other error, so they can recover without (for example) having to do lock discovery. >UNLOCK operations use the Lock-Token as the parameter, not an If: header. If >it *did* use the If: header, then how could you know which locktoken to >unlock if multiple were present? What if you wanted to assert a different >locktoken than the one that you're intending to unlock? Thus, the Lock-Token >is required for UNLOCK, and the If: header is just that: an assertion. I agree with all this. I'm not suggesting that we change UNLOCK to use IF to specify the "what to unlock." The interesting thing here is that this is completely symmetric with LOCK, which *does* specify the token in an IF (for renewal). I think there's another issue here entirely: ISSUE - Lock Renewal should specify the lock to renew with a LOCK-TOKEN header, not an IF header. Reasoning: If you have multiple locks on a resource, then you might specify more than one of them in the IF. How does the server know then which one to renew? >Based on all that, an UNLOCK with an unknown locktoken (well, unknown on >that resource) will generate a 400. > >If the UNLOCK contains an If: header, and the assertion(s) in the If: header >fail, then you'll get a 412. If the If: header fails *and* you have a bad >locktoken, then you'll get either a 400 or a 412 based on various internal >conditions (specifically: a 400 if the resource has no locks, a 412 if the >resource has locks but the If: assertion(s) fail). So consider the request UNLOCK /url ... LOCK-TOKEN: IF: If I have the resource locked with , this will succeed. If I've lost the lock and noone else has relocked, then I get a 400. But if I've lost the lock and someone else has locked, then I get a 412. This seems like an unnecessary assymetry, and confusing for a client. Putting this another way, I'm arguing that I should *always* get a 412 in this situation, whether or not I specify the IF header. Because ultimately what's going on is exactly that the LOCK-TOKEN header is claiming the same thing that an IF header would: that I have this lock! If I don't, then I should get a 412. > > In this particular case, the spec is very clear in section 7.6 that >> all methods which "interact with" (interpreted as "change") a > > write-locked resource must include an IF header specifying the lock >> token. > >I can understand how it can be read that way, but disagree with it. I don't >see an UNLOCK as changing the resource. The UNLOCK will alter some live >properties, but live props are defined as changeable at any time, so I don't >see them as "part of" the resource. To see that UNLOCK changes the resource, consider a lock-null resource. Unlocking it makes it go away. (I can come up with other examples, but that's the one that requires the least context.) > > If the lock token is missing, they are to get a 412 (since >> it's an IF). > >Not entirely true. The If: header doesn't have to make an assertion on the >resource identified by the Request-URI. The locktoken present in the If: >header might not be on the requested resource, it might be on something else >altogether. Thus, the If: header could pass, but none of the locktokens >mentioned in the If: header are present on the requested resource. And the spec mandates that a 412 should be returned in exactly that case. The spec is saying that if a resource is locked then you *must* present the token that locks that resource in order to modify it. It's not saying you get a 412 because the IF fails, it's saying you get a 412 because the precondition that you specify the lock token has failed. To see this, suppose I've locked a resource /url and gotten back. If I execute PUT /url ... IF: (NOT ) then I should get a 412 back. Not because the IF failed (it hasn't), but because I haven't presented in an IF. > > Unfortunately, the example for UNLOCK does not show any >> such IF header, so presumably the LOCK-TOKEN header is supposed to be >> doing double duty here (both specifying what to unlock and specifying >> the required precondition for every "interacting" method). > >The Lock-Token is not specifying a precondition. It is specifying a >parameter to the UNLOCK method. Only the If: header specifies preconditions >to the execution of a method. I "misspoke", sorry. I shouldn't have said "specifying the required precondition" but instead "presenting the lock token as required in section 7.6". But your point about the IF header is interesting, and I'm not sure I agree. I believe my reading of the spec is that "a precondition of executing an interacting method against a write-locked resource is that the lock token must be presented." In the case of PUT, etc., this precondition is being met by the use of an IF header. In the case of UNLOCK, it's being met by the use of a LOCK-TOKEN header. I believe the function of the IF header is for *clients* to specify *additional* preconditions on the execution of a method *other* than those mandated by the spec. In this reading, the use of the IF header for presenting a lock token in order to *satisfy* a spec precondition is a little confusing, but since such presentation is also useful as a client-generated precondition (only do this if I still have this lock) it makes sense. > >If the parameter is invalid, then you get a 400. > >>... >> Note that there's a separate issue here for servers that support >> non-exclusive locks and also support write locks. The issue is that >> both LOCK and UNLOCK are clearly "interacting methods" in the sense >> of section 7.6, > >I wouldn't say "clearly" :-) Touche :^). But see above: I think LOCK and UNLOCK are "arguably" such methods. > >> but UNLOCK is not shown to need an IF header. If a >> server issues a write lock on a resource that has some other kind of >> non-exclusive lock on it, then it ought to reject an unlock for that >> other kind of lock if the UNLOCK call doesn't specify an IF header >> with the token of the write lock. > >The locks do not interact like that. You cannot install a lock that prevents >another lock from being removed. Locks are about preventing change to the >body and to (dead and some live) properties. Sure you can. The semantics of locks are completely determined by the server, as long as they are consistent with the mandated semantics of write locks in the spec. To see this, consider a file system with read locks and write locks, where read locks can be upgraded to write locks. A natural mapping for this through a DAV server would be to have separate non-exclusive read locks and exclusive write locks. A user might apply for a read-lock and get . Then he applies for a write lock. The system upgrades his read lock to a write lock and returns . Now it's perfectly OK for the user to release the write lock and retain the read lock (which is why they have different tokens), but if he tries the natural thing: UNLOCK /url ... LOCK-TOKEN: the system is likely to reply 412 because he needed to say IF: so the system would know he was releasing only the read part of the lock but knew he still had the write lock. (And it might well *refuse* to release the read lock at all until the write lock was gone.) All of this is completely consistent with the spec, because locks are about preventing whatever the server says they should prevent (as long as, in the write-lock case, that includes the content and dead properties and certain live properties). > >... >> 1. Does UNLOCK require IF header specifying applicable write lock token? > >Adding an issue is certainly fine, but I'd answer this with "no". I think we agree about this, by the way. But I'd definitely suggest we change LOCK refresh to use LOCK-TOKEN to present the token rather than IF. So I think it's still worth discussing. > >> 2. UNLOCK should return 412 if valid lock token is not supplied as >> UNLOCK-TOKEN. > >I disagree. I believe the current behavior in mod_dav is correct, but am >certainly willing to listen to why it may be wrong. See above for my >reasoning about the current behavior. Thanks for reading this far, then! dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 888-461-0237 2-way pager email: From w3c-dist-auth-request@w3.org Fri Mar 2 23:17: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 XAA00756 for ; Fri, 2 Mar 2001 23:17:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA14354; Fri, 2 Mar 2001 23:11:56 -0500 (EST) Resent-Date: Fri, 2 Mar 2001 23:11:56 -0500 (EST) Resent-Message-Id: <200103030411.XAA14354@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 XAA14323 for ; Fri, 2 Mar 2001 23:11:51 -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 XAA13786 for ; Fri, 2 Mar 2001 23:11:50 -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 XAA41148; Fri, 2 Mar 2001 23:10:37 -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 XAA55714; Fri, 2 Mar 2001 23:07:45 -0500 Importance: Normal To: "Dan Brotsky" Cc: Greg Stein , w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Fri, 2 Mar 2001 23:01:36 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.6a |January 17, 2001) at 03/02/2001 11:11:43 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: unlock question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4683 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << The interesting thing here is that this is completely symmetric with LOCK, which *does* specify the token in an IF (for renewal). I think there's another issue here entirely: ISSUE - Lock Renewal should specify the lock to renew with a LOCK-TOKEN header, not an IF header. Reasoning: If you have multiple locks on a resource, then you might specify more than one of them in the IF. How does the server know then which one to renew? >> I agree. I think that is a very poor design decision in the spec. It's going on the list. << So consider the request UNLOCK /url ... LOCK-TOKEN: IF: If I have the resource locked with , this will succeed. If I've lost the lock and noone else has relocked, then I get a 400. But if I've lost the lock and someone else has locked, then I get a 412. This seems like an unnecessary assymetry, and confusing for a client. >> First let me say that I intuitively prefer that the IF header checking should occur before the method specific checks. I don't think rfc2518 says what it requires, but my preference would be in conflict with the IF-MATCH header spec after which we say the IF header is modeled. Although it's not my preference, below I'll assume the IF header is not checked first because that's what you've assumed. But we should decide what semantics we want and update the spec, right? Anyway, onward... If you didn't include the IF: header, then I think 400 would be what returned as you indicated. Although returning 400 seems to bother you, I think returning something other than 412 is potentially valuable since the possibility of three well defined error statuses allow the client to easily distinguish between the three situations you mentioned. << Putting this another way, I'm arguing that I should *always* get a 412 in this situation, whether or not I specify the IF header. Because ultimately what's going on is exactly that the LOCK-TOKEN header is claiming the same thing that an IF header would: that I have this lock! If I don't, then I should get a 412. >> Whether or not you have the IF header? Hmmm. This argument could be extended to many things I think since almost every 4xx error code is a conceptual precondition fault. I don't think either option is much better than the other. 400 is a pretty generic error so unless the text after the status code clarifies, it doesn't provide a lot of information about the error and could be ambiguous with other types of errors. Saying an error is a pre-req error is saying more about it, but not much more. And returning 412 if the implicit lock check failed would create an amgibuity with the situation where the IF header was actually doing an etag check and the client would like to know if it's etag check failed or the implicit lock check failed. Neither options seems great, but I'd think returning 400 is better of the two. At least we know with 412 (I hope) that the status indicates that the client driven check failed and not something else. << To see that UNLOCK changes the resource, consider a lock-null resource. Unlocking it makes it go away. (I can come up with other examples, but that's the one that requires the least context.) >> I agree with Greg. We've had long discussions about locking that we suspended in Dec 99 so that we could devote time to other issues. Despite the wording of things like the IF header documentation, in those discussions we all agreed that the lock really isn't meant to change the resource. It just acts on the resource and/or the URI. And the case of null lock resources is odd ball. It's very controversial and likely is going to need conceptual revision even if the actual outward behavior doesn't change. << And the spec mandates that a 412 should be returned in exactly that case. The spec is saying that if a resource is locked then you *must* present the token that locks that resource in order to modify it. It's not saying you get a 412 because the IF fails, it's saying you get a 412 because the precondition that you specify the lock token has failed. To see this, suppose I've locked a resource /url and gotten back. If I execute PUT /url ... IF: (NOT ) then I should get a 412 back. Not because the IF failed (it hasn't), but because I haven't presented in an IF. >> Assuming the IF header is checked second... You are right is so far as that the implicit check for the locks before doing a PUT would fail. But I think you'd get "423 Locked" response though not a "412 Precondition Failed". I'm not sure I'm getting your point unless it is that everything is a pre-condition check and should return "412 Precondition Failed". I'm sceptical of that. I feel that 412 Precondition Failed is largely intended for optional client driven checks like IF:, IF-MATCH, etc. << I believe the function of the IF header is for *clients* to specify *additional* preconditions on the execution of a method *other* than those mandated by the spec. In this reading, the use of the IF header for presenting a lock token in order to *satisfy* a spec precondition is a little confusing, but since such presentation is also useful as a client-generated precondition (only do this if I still have this lock) it makes sense. >> I agree. The IF header should be reserved for client-directed checks. There should be a seperate header for presenting our tokens for the sake of generic lock checking. Perhaps call it "Locks-Held:". No double or triple duty for the IF header. J. From w3c-dist-auth-request@w3.org Sat Mar 3 14:38: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 OAA23713 for ; Sat, 3 Mar 2001 14:38:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA03933; Sat, 3 Mar 2001 14:30:46 -0500 (EST) Resent-Date: Sat, 3 Mar 2001 14:30:46 -0500 (EST) Resent-Message-Id: <200103031930.OAA03933@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 OAA03909 for ; Sat, 3 Mar 2001 14:30:41 -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 OAA06918 for ; Sat, 3 Mar 2001 14:30:37 -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 NAA17518 for ; Sat, 3 Mar 2001 13:26:23 -0600 Message-ID: <000c01c0a419$b453c3a0$0c77b2d1@win2k> From: "John Glavin" To: References: Date: Sat, 3 Mar 2001 11:39:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: Do any DAV servers support DBCS/MBCS ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4684 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I know IIS supports Unicode when URL's are encoded in UTF-8, but does any DAV server out there understand DBCS/MBCS ? DBCS/MBCS: double byte or multi byte character set used for far east languages (Japanese, Chinese, Korean). It's a mix of single byte and multibyte characters. The multi-byte characters are encoding as two bytes with a lead and trail byte. DBCS strings have to be parsed by software that knows about DBCS because some special characters like backslash can appear in the trail byte which could confuse some software when parsing path's for example. John Glavin RiverFront Software john@webdrive.com http://www.webdrive.com From w3c-dist-auth-request@w3.org Sat Mar 3 21:50:14 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 VAA00839 for ; Sat, 3 Mar 2001 21:50:11 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA11823; Sat, 3 Mar 2001 21:43:20 -0500 (EST) Resent-Date: Sat, 3 Mar 2001 21:43:20 -0500 (EST) Resent-Message-Id: <200103040243.VAA11823@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 VAA11802 for ; Sat, 3 Mar 2001 21:43:16 -0500 (EST) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA02415 for ; Sat, 3 Mar 2001 21:43:15 -0500 Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id SAA27634 for ; Sat, 3 Mar 2001 18:42:59 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Sat, 3 Mar 2001 18:42:59 -0800 Received: from miobuild (miobuild.apple.com [17.202.40.169]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id SAA17859; Sat, 3 Mar 2001 18:42:58 -0800 (PST) Message-Id: <200103040242.SAA17859@scv2.apple.com> Date: Sat, 3 Mar 2001 18:42:16 -0800 From: Clark Warner Content-Type: text/plain; format=flowed; charset=us-ascii Cc: Clark Warner To: "'w3c-dist-auth@w3.org'" X-Mailer: Apple Mail (2.387) In-Reply-To: Mime-Version: 1.0 (Apple Message framework v387) Content-Transfer-Encoding: 7bit Subject: Re: trouble connecting to IIS5 from OS X PB Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4685 X-Loop: w3c-dist-auth@w3.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 Mac OS X, webdavfs has been updated. It now actually sends a PROPFIND body a request the specific properties that it is interested in and thus sends the content-length as well. I think there is still one case with a bug, however. Does anyone know of a public IIS5 webdav server that I can test against ? - Clark On Friday, March 2, 2001, at 02:45 PM, Benn, Paul wrote: > Perhaps this is an OSX-ism which will be fixed when it is released this > month..?? > > -----Original Message----- > From: John Stracke [mailto:francis@ecal.com] > Sent: Friday, March 02, 2001 6:12 AM > To: Benn, Paul > Cc: 'w3c-dist-auth@w3.org' > Subject: Re: trouble connecting to IIS5 from OS X PB > > But in 2616/4.4 (which discusses how to determine the length of the > body), > the > only way I see to infer that no body is present is to know that the > message > MUST NOT have a body (e.g., if it's a GET request or a HEAD response), > or > else > to see that the server closed the connection after the message (does not > work > for requests). So I think IIS5 is probably within its rights to require > Content-Length: 0...though I personally would have written it to be more > forgiving, and assume that no Content-Length: and no Transfer-Encoding: > implies > no body. > Clark H. Warner Manager CoreOS File Systems Engineering warner.c@apple.com -------------------------------- From w3c-dist-auth-request@w3.org Sun Mar 4 15:20: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 PAA15159 for ; Sun, 4 Mar 2001 15:20:30 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA28553; Sun, 4 Mar 2001 15:12:06 -0500 (EST) Resent-Date: Sun, 4 Mar 2001 15:12:06 -0500 (EST) Resent-Message-Id: <200103042012.PAA28553@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 PAA28532 for ; Sun, 4 Mar 2001 15:11:54 -0500 (EST) Received: from matrixmail.matrix-one.com (matrixone.com [4.17.165.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA06689 for ; Sun, 4 Mar 2001 15:11:53 -0500 Received: from kdyer by kdyer (8.10.1/8.10.1) with SMTP id f24KBLZ05527; Sun, 4 Mar 2001 15:11:21 -0500 (EST) Reply-To: From: "Kevin Dyer" To: "John Glavin" , Date: Sun, 4 Mar 2001 15:11:21 -0500 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.4522.1200 In-Reply-To: <000c01c0a419$b453c3a0$0c77b2d1@win2k> Subject: RE: Do any DAV servers support DBCS/MBCS ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4686 X-Loop: w3c-dist-auth@w3.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 All, This brings up the RFC2047 / RFC2184 / RFC2231 encoding vs RCF2279 UTF-8 encoding. Do we need to support both? kevin > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of John Glavin > Sent: Saturday, March 03, 2001 2:40 PM > To: w3c-dist-auth@w3.org > Subject: Do any DAV servers support DBCS/MBCS ? > > > I know IIS supports Unicode when URL's are encoded in UTF-8, but does any > DAV server out there understand DBCS/MBCS ? > > DBCS/MBCS: double byte or multi byte character set used for far east > languages (Japanese, Chinese, Korean). It's a mix of single byte and > multibyte characters. The multi-byte characters are encoding as two bytes > with a lead and trail byte. DBCS strings have to be parsed by software that > knows about DBCS because some special characters like backslash can appear > in the trail byte which could confuse some software when parsing path's for > example. > > John Glavin > RiverFront Software > john@webdrive.com > http://www.webdrive.com > > ____________________________________________ Kevin J. Dyer Sr. Technologist, Product Management kevin.dyer@matrixone.com TEL: 978-322-2011 FAX: 978-441-0071 MOBILE: 978-314-9855 MatrixOne, Inc. Two Executive Drive Chelmsford, MA 01824 USA www.matrixone.com The First in Intelligent Collaborative Commerce ____________________________________________ From w3c-dist-auth-request@w3.org Sun Mar 4 22:39:43 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 WAA19569 for ; Sun, 4 Mar 2001 22:39:42 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA12136; Sun, 4 Mar 2001 22:32:52 -0500 (EST) Resent-Date: Sun, 4 Mar 2001 22:32:52 -0500 (EST) Resent-Message-Id: <200103050332.WAA12136@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 WAA12116 for ; Sun, 4 Mar 2001 22:32:48 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-38038.rational.com [192.229.38.38]) by tux.w3.org (8.9.3/8.9.3) with SMTP id WAA05512 for ; Sun, 4 Mar 2001 22:32:43 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Sun, 04 Mar 2001 22:42:29 -0500 (Eastern Standard Time) Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sun, 4 Mar 2001 22:42:29 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B10238F9FB@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Sun, 4 Mar 2001 22:42:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: unlock question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4687 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I believe one problem is that the 412 status is basically a grab-bag of error conditions, that varies from method to method. The "pre-condition failed" definition is an admission of the grab-bag nature of a 412, since any error condition can be interpreted as some kind of pre-condition failure. Restricting to If header failure would have been good, but is not what 2518 says (it throws in keepalive and Overwrite:false behavior). But I believe we can minimize the confusion if we rigidly restrict 412 to be the minimum required by 2518 (i.e. If header, keepalive failure, and Overwrite:false failure). For everything else that you might be tempted to use 412 for, use either 403 (Forbidden) if the client cannot change the resource to make the request succeed, and 409 (Conflict) if it can change the resource to make the request succeed. Greg: 2616 states that 400 (Bad Request) means "malformed syntax". I believe that it is pretty clear that submitting the wrong lock token with an UNLOCK is not a "malformed syntax", and therefore mod_dav should not be returning a 400 in this case. I'd use 403 (Forbidden). Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] << The interesting thing here is that this is completely symmetric with LOCK, which *does* specify the token in an IF (for renewal). I think there's another issue here entirely: ISSUE - Lock Renewal should specify the lock to renew with a LOCK-TOKEN header, not an IF header. Reasoning: If you have multiple locks on a resource, then you might specify more than one of them in the IF. How does the server know then which one to renew? >> I agree. I think that is a very poor design decision in the spec. It's going on the list. << So consider the request UNLOCK /url ... LOCK-TOKEN: IF: If I have the resource locked with , this will succeed. If I've lost the lock and noone else has relocked, then I get a 400. But if I've lost the lock and someone else has locked, then I get a 412. This seems like an unnecessary assymetry, and confusing for a client. >> First let me say that I intuitively prefer that the IF header checking should occur before the method specific checks. I don't think rfc2518 says what it requires, but my preference would be in conflict with the IF-MATCH header spec after which we say the IF header is modeled. Although it's not my preference, below I'll assume the IF header is not checked first because that's what you've assumed. But we should decide what semantics we want and update the spec, right? Anyway, onward... If you didn't include the IF: header, then I think 400 would be what returned as you indicated. Although returning 400 seems to bother you, I think returning something other than 412 is potentially valuable since the possibility of three well defined error statuses allow the client to easily distinguish between the three situations you mentioned. << Putting this another way, I'm arguing that I should *always* get a 412 in this situation, whether or not I specify the IF header. Because ultimately what's going on is exactly that the LOCK-TOKEN header is claiming the same thing that an IF header would: that I have this lock! If I don't, then I should get a 412. >> Whether or not you have the IF header? Hmmm. This argument could be extended to many things I think since almost every 4xx error code is a conceptual precondition fault. I don't think either option is much better than the other. 400 is a pretty generic error so unless the text after the status code clarifies, it doesn't provide a lot of information about the error and could be ambiguous with other types of errors. Saying an error is a pre-req error is saying more about it, but not much more. And returning 412 if the implicit lock check failed would create an amgibuity with the situation where the IF header was actually doing an etag check and the client would like to know if it's etag check failed or the implicit lock check failed. Neither options seems great, but I'd think returning 400 is better of the two. At least we know with 412 (I hope) that the status indicates that the client driven check failed and not something else. << To see that UNLOCK changes the resource, consider a lock-null resource. Unlocking it makes it go away. (I can come up with other examples, but that's the one that requires the least context.) >> I agree with Greg. We've had long discussions about locking that we suspended in Dec 99 so that we could devote time to other issues. Despite the wording of things like the IF header documentation, in those discussions we all agreed that the lock really isn't meant to change the resource. It just acts on the resource and/or the URI. And the case of null lock resources is odd ball. It's very controversial and likely is going to need conceptual revision even if the actual outward behavior doesn't change. << And the spec mandates that a 412 should be returned in exactly that case. The spec is saying that if a resource is locked then you *must* present the token that locks that resource in order to modify it. It's not saying you get a 412 because the IF fails, it's saying you get a 412 because the precondition that you specify the lock token has failed. To see this, suppose I've locked a resource /url and gotten back. If I execute PUT /url ... IF: (NOT ) then I should get a 412 back. Not because the IF failed (it hasn't), but because I haven't presented in an IF. >> Assuming the IF header is checked second... You are right is so far as that the implicit check for the locks before doing a PUT would fail. But I think you'd get "423 Locked" response though not a "412 Precondition Failed". I'm not sure I'm getting your point unless it is that everything is a pre-condition check and should return "412 Precondition Failed". I'm sceptical of that. I feel that 412 Precondition Failed is largely intended for optional client driven checks like IF:, IF-MATCH, etc. << I believe the function of the IF header is for *clients* to specify *additional* preconditions on the execution of a method *other* than those mandated by the spec. In this reading, the use of the IF header for presenting a lock token in order to *satisfy* a spec precondition is a little confusing, but since such presentation is also useful as a client-generated precondition (only do this if I still have this lock) it makes sense. >> I agree. The IF header should be reserved for client-directed checks. There should be a seperate header for presenting our tokens for the sake of generic lock checking. Perhaps call it "Locks-Held:". No double or triple duty for the IF header. J. From w3c-dist-auth-request@w3.org Mon Mar 5 03:33: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 DAA08869 for ; Mon, 5 Mar 2001 03:33:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA18346; Mon, 5 Mar 2001 03:27:31 -0500 (EST) Resent-Date: Mon, 5 Mar 2001 03:27:31 -0500 (EST) Resent-Message-Id: <200103050827.DAA18346@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 DAA18310 for ; Mon, 5 Mar 2001 03:27:21 -0500 (EST) Received: from mutley.ebuilt.net (nat.ebuilt.net [209.216.43.20]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA24658 for ; Mon, 5 Mar 2001 03:27:20 -0500 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f258RDu19957 for ; Mon, 5 Mar 2001 00:27:13 -0800 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f258RCC19876; Mon, 5 Mar 2001 00:27:12 -0800 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f258OQg07420; Mon, 5 Mar 2001 00:24:26 -0800 Date: Mon, 5 Mar 2001 00:24:26 -0800 From: "Roy T. Fielding" To: "Clemm, Geoff" Cc: w3c-dist-auth@w3.org Message-ID: <20010305002426.H7192@waka.ebuilt.net> References: <3906C56A7BD1F54593344C05BD1374B10238F9FB@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13-current-20010115i In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10238F9FB@SUS-MA1IT01>; from gclemm@rational.com on Sun, Mar 04, 2001 at 10:42:39PM -0500 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: unlock question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4688 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > 2616 states that 400 (Bad Request) means "malformed syntax". > I believe that it is pretty clear that submitting > the wrong lock token with an UNLOCK is not a "malformed > syntax", and therefore mod_dav should not be returning > a 400 in this case. I'd use 403 (Forbidden). I would use 423 (Locked). 412 should not have been used at all. 423 is sufficient to indicate that the lock token is not what the server was looking for. ....Roy From w3c-dist-auth-request@w3.org Mon Mar 5 11:39:52 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 LAA20527 for ; Mon, 5 Mar 2001 11:39:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA07632; Mon, 5 Mar 2001 11:16:05 -0500 (EST) Resent-Date: Mon, 5 Mar 2001 11:16:05 -0500 (EST) Resent-Message-Id: <200103051616.LAA07632@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 LAA07612 for ; Mon, 5 Mar 2001 11:15:57 -0500 (EST) Received: from localhost.localdomain ([216.52.68.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA31928 for ; Mon, 5 Mar 2001 11:15:56 -0500 Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f25GMJN01597 for ; Mon, 5 Mar 2001 11:22:19 -0500 Message-ID: <3AA3BD3B.6A2221F5@ecal.com> Date: Mon, 05 Mar 2001 11:22:19 -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: Do any DAV servers support DBCS/MBCS ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4689 X-Loop: w3c-dist-auth@w3.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 Dyer wrote: > This brings up the RFC2047 / RFC2184 / RFC2231 > encoding vs RCF2279 UTF-8 encoding. Do we need to > support both? OK, 2047 (updated by 2184 and 2231) is for non-ASCII content in headers, not in the body. 2616 refers to 2047; 2616/2.2 says: Words of *TEXT MAY contain characters from character sets other than ISO- 8859-1 [22] only when encoded according to the rules of RFC 2047 [14]. To me, that says any HTTP/1.1 implementation needs to (SHOULD? MUST?) support 2047 (presumably, as updated by 2231, since that predates 2616). However, TEXT "is only used for descriptive field contents and values that are not intended to be interpreted by the message parser" (2616/2.2, again); it apparently does not apply to URIs. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |But how do we know destroying the Van Allen belt| |francis@ecal.com|will kill all life on Earth if we don't try it? | \=================================================================/ From w3c-dist-auth-request@w3.org Mon Mar 5 17:18:32 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 RAA07191 for ; Mon, 5 Mar 2001 17:18:32 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA00444; Mon, 5 Mar 2001 17:00:35 -0500 (EST) Resent-Date: Mon, 5 Mar 2001 17:00:35 -0500 (EST) Resent-Message-Id: <200103052200.RAA00444@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 RAA00422 for ; Mon, 5 Mar 2001 17:00:30 -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 RAA06589 for ; Mon, 5 Mar 2001 17:00:25 -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 OAA17807 for ; Mon, 5 Mar 2001 14:00:28 -0800 (PST) From: "Jim Whitehead" To: "WebDAV WG" Date: Mon, 5 Mar 2001 13:59:25 -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: FW: webDAV - web authoring or flexible two-way web interface ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4690 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I've added Stuart to the accept2 list, so future emails will get sent through to the list. - Jim -----Original Message----- From: Connelly, Stuart [mailto:sconnelly@ordsvy.gov.uk] Sent: Monday, March 05, 2001 6:38 AM To: 'w3c-dist-auth@w3.org' Subject: [Moderator Action] webDAV - web authoring or flexible two-way web interface ? Can I use this forum to ask a dumb question? Already have.... Say I have a large database of geographic features; points/lines/areas. All features have a unique id. The supply of data to read access clients is based on a cgi script executing a query and then returning dynamic content. (e.g. All objects in a given rectangle). Now I want to give clients the ability to update this database via the web. One method would be to define lock/transaction interfaces that embed information within HTTP POST messages. (I think this is termed RPC-via-POST?). Perhaps another method would be to use the WebDAV extensions. But reading the WebDAV information on the web it isn't clear if WebDAV can be used for dynamic web pages - it all seems geared-up for editing of text pages. Am I barking up the wrong tree in looking at WebDAV? Out of my depth but not drowning yet, Stuart Connelly From w3c-dist-auth-request@w3.org Mon Mar 5 20:04: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 UAA12523 for ; Mon, 5 Mar 2001 20:04:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA05449; Mon, 5 Mar 2001 19:58:23 -0500 (EST) Resent-Date: Mon, 5 Mar 2001 19:58:23 -0500 (EST) Resent-Message-Id: <200103060058.TAA05449@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 TAA05429 for ; Mon, 5 Mar 2001 19:58:18 -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 TAA21160 for ; Mon, 5 Mar 2001 19:58:18 -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 QAA02722 for ; Mon, 5 Mar 2001 16:58:23 -0800 (PST) From: "Jim Whitehead" To: "WebDAV WG" Date: Mon, 5 Mar 2001 16:57:18 -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: Updated issues list Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4691 X-Loop: w3c-dist-auth@w3.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 revv'ed the publically accessible issues list at: http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html Thank you Jason for capturing the issues that have come up in recent list discussion. - Jim From w3c-dist-auth-request@w3.org Mon Mar 5 21:24:52 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 VAA14167 for ; Mon, 5 Mar 2001 21:24:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA07879; Mon, 5 Mar 2001 21:18:04 -0500 (EST) Resent-Date: Mon, 5 Mar 2001 21:18:04 -0500 (EST) Resent-Message-Id: <200103060218.VAA07879@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 VAA07856 for ; Mon, 5 Mar 2001 21:17:58 -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 VAA27755 for ; Mon, 5 Mar 2001 21:17:57 -0500 Received: from beaver (speedy.rtfm.com [198.144.206.141] (may be forged)) by shell.tsoft.com (8.8.7/8.8.7) with SMTP id SAA22712; Mon, 5 Mar 2001 18:17:47 -0800 (PST) From: "Lisa Dusseault" To: , "WebDAV WG" Date: Mon, 5 Mar 2001 18:16:48 -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.00.2919.6700 Importance: Normal In-Reply-To: Subject: RE: webDAV - web authoring or flexible two-way web interface ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4692 X-Loop: w3c-dist-auth@w3.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 looked at applications like this in the past. Since WebDAV can have a list of properties and values for every resource, one can treat a directory full of resources much the same as a table in a database. I don't really understand the architecture of your database, but you could map it to web resources like this: - give every unique id a unique URL - Allow users to PROPPATCH that unique URL with new point/line/area data - Allow users to PROPFIND those items?? SEARCH?? You can still build your dynamic web pages exactly the way they work now. WebDAV is intended to interact nicely with dynamic web pages; the hard part is to "get" the source of the dynamic web page, to edit that source rather than the finished output. Different web servers do this in different ways, I believe. I'm not sure what benefit WebDAV would bring you in this scenario, though. It doesn't sound like you need to edit the source of the dynamic web pages, it sounds like you need to make changes to the databaase only. Do users need to be able to browse the list of IDs with a client like Windows Explorer? Probably not. Do they need to be able to lock a unique id/entry before editing it? Maybe WebDAV would help there... Overall, it sounds like HTML forms are simpler for solving your problem than WebDAV, unless there are features of WebdAV that help you out in other ways. There are also umpteen products for connecting databases to the web in much the manner you describe -- they may even help automatically build the HTML forms to some extent. These products do not need nor use WebDAV in general. lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Monday, March 05, 2001 1:59 PM > To: WebDAV WG > Subject: FW: webDAV - web authoring or flexible two-way web interface ? > > > Accidentally caught by the spam filter. I've added Stuart to the accept2 > list, so future emails will get sent through to the list. > > - Jim > > -----Original Message----- > From: Connelly, Stuart [mailto:sconnelly@ordsvy.gov.uk] > Sent: Monday, March 05, 2001 6:38 AM > To: 'w3c-dist-auth@w3.org' > Subject: [Moderator Action] webDAV - web authoring or flexible two-way > web interface ? > > > > Can I use this forum to ask a dumb question? Already have.... > > Say I have a large database of geographic features; > points/lines/areas. All > features have a unique id. The supply of data to read access clients is > based on a cgi script executing a query and then returning > dynamic content. > (e.g. All objects in a given rectangle). > > Now I want to give clients the ability to update this database > via the web. > One method would be to define lock/transaction interfaces that embed > information within HTTP POST messages. (I think this is termed > RPC-via-POST?). > > Perhaps another method would be to use the WebDAV extensions. But reading > the WebDAV information on the web it isn't clear if WebDAV can be used for > dynamic web pages - it all seems geared-up for editing of text pages. Am I > barking up the wrong tree in looking at WebDAV? > > Out of my depth but not drowning yet, > > Stuart Connelly > From w3c-dist-auth-request@w3.org Tue Mar 6 09:45:44 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 JAA13277 for ; Tue, 6 Mar 2001 09:45:42 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA26844; Tue, 6 Mar 2001 09:22:20 -0500 (EST) Resent-Date: Tue, 6 Mar 2001 09:22:20 -0500 (EST) Resent-Message-Id: <200103061422.JAA26844@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 JAA26824 for ; Tue, 6 Mar 2001 09:22:16 -0500 (EST) Received: from rooster.ordsvy.gov.uk (rooster.ordsvy.gov.uk [193.117.128.23]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA17189 for ; Tue, 6 Mar 2001 09:22:12 -0500 Message-Id: <3951D6A730CBD211BFA800805FA7BC4D02807E15@ordsvy.gov.uk> From: "Connelly, Stuart" To: "'w3c-dist-auth@w3.org'" Date: Tue, 6 Mar 2001 14:20:54 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: webDAV - web authoring or flexible two-way web interface Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4693 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Thank you Lisa. You are right in thinking that I need to make changes to the database only. Data would be exchanged in the XML standard for geographic information (OpenGIS GML). The data is geometric so clients would need 2-D line editing functionality in the browser, much like a mini CAD application. Both locking and access control are essential. At first glance it seemed that webDAV would help here because of the webDAV LOCK / UNLOCK HTTP extensions and access control protocols. I could create a mapping between the database objects and URLs easily enough at the server. But this imposes restrictions on client. Clients would need to know the object IDs before locking - it is has to be specified as part of the URL in the LOCK request. From the clients perspective a lock request would be "lock all objects in this area" with the area specified and the object IDS not. I guess I could get webDAV to work for my application but I'm beginning to see that it's not the most appropriate technology. Stuart From w3c-dist-auth-request@w3.org Wed Mar 7 18:32:04 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 SAA27342 for ; Wed, 7 Mar 2001 18:32:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA16691; Wed, 7 Mar 2001 18:23:31 -0500 (EST) Resent-Date: Wed, 7 Mar 2001 18:23:31 -0500 (EST) Resent-Message-Id: <200103072323.SAA16691@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 SAA16667 for ; Wed, 7 Mar 2001 18:23:25 -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 SAA16689 for ; Wed, 7 Mar 2001 18:23:25 -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 PAA16684 for ; Wed, 7 Mar 2001 15:23:31 -0800 (PST) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 7 Mar 2001 15:22:24 -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: FW: Problem w/ Web folder components Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4694 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I have added Irene Ooi's email address to the accept2 filter. - Jim -----Original Message----- From: Irene Ooi [mailto:IOoi@engenia.com] Sent: Wednesday, March 07, 2001 1:21 PM To: 'w3c-dist-auth@w3.org' Subject: [Moderator Action] Problem w/ Web folder components Hi! I am a QA Engineer from Engenia Software, Inc. Recently, I have performed some tests on WebDAV using different version of IE 5.0+ w/ the following OS: Win 98, 2000, and NT. I had came across some problems. I hope your team can help me. Below are my test steps, results and questions. Thank you, Irene Test Steps: 1. Setup a WebDAV server 2. Setup Web folders for each desktop computers. Test Results: Computer # OS IE version Comment ----------------- ------ --------------------------------- -------------------------------------------------------------- 1. 98 5.0.2919.6307 Pass 2. (laptop) 98 5.0.2919.6307 Fail -- Looking for Web Folder components 3. 98 5.5 Pass 4. NT 5.0.2919.6307CO Pass 5. NT 5.0.2919.6307CO Fail -- Looking for Web Folder components 6. NT 5.50.4522.1800 Pass 7. 2000 5.0.2920.0000 Pass Comment: For the computer # 2 and 5, I can open a file, test.doc (MS Word 2000 document), in Web folder, but I can NOT open this same file thru IE browser. Below are the messages that I got: IE Install on Demand To display this page correctly, you need to download or install the following components: Web Folder. I have upgraded one of the computer above from IE 5.0 to IE 5.5. After upgrading, I no longer has this problem. Questions: It seems like the computer # 2 and 5 are missing Web Folder components. 1. Do you know what components that I am missing? From w3c-dist-auth-request@w3.org Thu Mar 8 20:05: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 UAA19124 for ; Thu, 8 Mar 2001 20:04:57 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA19305; Thu, 8 Mar 2001 19:54:35 -0500 (EST) Resent-Date: Thu, 8 Mar 2001 19:54:35 -0500 (EST) Resent-Message-Id: <200103090054.TAA19305@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 TAA19270 for ; Thu, 8 Mar 2001 19:54:28 -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 TAA31368; Thu, 8 Mar 2001 19:54:27 -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 QAA23094; Thu, 8 Mar 2001 16:54:32 -0800 (PST) From: "Jim Whitehead" To: "WebDAV WG" , Date: Thu, 8 Mar 2001 16:53:26 -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: DAVers guide to the Minneapolis IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4695 X-Loop: w3c-dist-auth@w3.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 following is a brief guide to WebDAV and DeltaV activities at the Minneapolis IETF meeting. For location, hotel, and registration information for the IETF meeting, see: http://www.ietf.org/meetings/IETF-50.html Wednesday, March 21 ------------------- 1:00-3:00 :: Informal WebDAV meeting to discuss RFC 2518 open issues. Location: TBD, look on IETF message board Thursday, March 22 ------------------ 9:00-11:30 :: WebDAV Working Group meeting Location: Rochester room, Minneapolis Hilton and Towers 11:30-5:00 :: DeltaV Design Team Meeting Location: TBD (will be announced during WebDAV WG meeting) Friday, March 23 ---------------- 9:00-11:30 :: DeltaV Working Group meeting Location: Rochester room, Minneapolis Hilton and Towers 11:30-3:00 :: DeltaV Design Team meeting Location: TBD (will be announced in DeltaV WG meeting) The Minneapolis Hilton and Towers is located at: 1001 Marquette Avenue Minneapolis, MN 55403 USA Note that the IETF message board is a bulletin board typically located near the registration counter. Also, if you have not yet made your hotel arrangements, I recommend doing so pronto. I had significant difficulty finding a hotel when I made my arrangements last week... - Jim From w3c-dist-auth-request@w3.org Thu Mar 8 20:06: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 UAA19193 for ; Thu, 8 Mar 2001 20:06:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA19432; Thu, 8 Mar 2001 19:58:26 -0500 (EST) Resent-Date: Thu, 8 Mar 2001 19:58:26 -0500 (EST) Resent-Message-Id: <200103090058.TAA19432@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 TAA19412 for ; Thu, 8 Mar 2001 19:58:22 -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 TAA31662 for ; Thu, 8 Mar 2001 19:58:21 -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 QAA23927 for ; Thu, 8 Mar 2001 16:58:27 -0800 (PST) From: "Jim Whitehead" To: "WebDAV WG" Date: Thu, 8 Mar 2001 16:57:20 -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: FW: Re: UTF-8 Encoding Question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4696 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I've added Larry's acm.org email address to the accept2 list. - Jim -----Original Message----- From: Larry Masinter [mailto:LMM@acm.org] Sent: Thursday, March 08, 2001 4:47 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Re: UTF-8 Encoding Question For URL_ENCODING_ISSUES, please consider http://www.ietf.org/internet-drafts/draft-masinter-url-i18n-07.txt Thanks, Larry -- http://larry.masinter.net From w3c-dist-auth-request@w3.org Fri Mar 9 03:36:42 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 DAA10014 for ; Fri, 9 Mar 2001 03:36:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA00793; Fri, 9 Mar 2001 03:31:13 -0500 (EST) Resent-Date: Fri, 9 Mar 2001 03:31:13 -0500 (EST) Resent-Message-Id: <200103090831.DAA00793@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 DAA00770 for ; Fri, 9 Mar 2001 03:31:01 -0500 (EST) Received: from mbox.mm.se (mbox.mm.se [193.13.144.59]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA00914 for ; Fri, 9 Mar 2001 03:30:55 -0500 Received: from [193.13.144.25] ([193.13.144.25] verified) by mbox.mm.se (CommuniGate Pro SMTP 3.4.1) with ESMTP id 3073880 for w3c-dist-auth@w3.org; Fri, 09 Mar 2001 09:30:48 +0100 User-Agent: Microsoft-Entourage/9.0.2509 Date: Fri, 09 Mar 2001 09:29:46 +0100 From: Max Elander To: WebDAV-listan Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id DAA00770 Subject: Security and WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4697 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by www19.w3.org id DAA00793 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA10014 Hi! I have been lurking on the list for a couple of weeks now and thought I¹d come out of the shadows to ask a question that I haven¹t seen anyone else addressing: How about security? I understand that as DAV uses http as the underlying protocol, I can use SSL as a way to enhance security, and realms on my server to exclude unwanted visitors. What I am more interested in is if there is any support in current clients for more rigorous security, eg RSA encryption or similar approaches? If I use a webclient such as IE or Netscape the answer is rather obvious, but how is it with webfolders in Windows, how will it work in Mac OS X, does Adobe support it in Photoshop and InDesign, has Microsoft done anything like that in Office 2000, Office XP and so forth? If this is a topic on another list, please let me know. Regards, Max Elander (Content Manager, AcadeMedia World) From w3c-dist-auth-request@w3.org Fri Mar 9 09:46:13 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 JAA15345 for ; Fri, 9 Mar 2001 09:46:08 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA16100; Fri, 9 Mar 2001 09:38:29 -0500 (EST) Resent-Date: Fri, 9 Mar 2001 09:38:29 -0500 (EST) Resent-Message-Id: <200103091438.JAA16100@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 JAA16076 for ; Fri, 9 Mar 2001 09:38:24 -0500 (EST) Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA02659 for ; Fri, 9 Mar 2001 09:38:23 -0500 Received: (qmail 17291 invoked from network); 9 Mar 2001 14:38:18 -0000 Received: from pluto.hosting4u.net (HELO globalprime.com) (209.15.2.26) by mail-gate.hosting4u.net with SMTP; 9 Mar 2001 14:38:18 -0000 Received: from jimk ([168.215.112.19]) by globalprime.com ; Fri, 09 Mar 2001 08:38:15 -0600 From: "Jim" To: "WebDAV-listan" Date: Fri, 9 Mar 2001 09:35:17 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Subject: RE: Security and WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4698 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by www19.w3.org id JAA16100 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA15345 Hi, I've been lurking too and I saw your post. Before I got off and say that SSL can still take care of all your needs, can you be more specific about which RSA security protocols you are interested in? SSL supports pretty much the same authentication and encryption options that IPSec does without all the nasty, messy NAT issues. If you run all your TCP connections under/over SSL, it would address your webfolders question as well. Furthermore, it is feasibly possible to run SSL in both directions, therefore providing authentication of the clients. Regards, Jim -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Max Elander Sent: Friday, March 09, 2001 3:30 AM To: WebDAV-listan Subject: Security and WebDAV Hi! I have been lurking on the list for a couple of weeks now and thought I¹d come out of the shadows to ask a question that I haven¹t seen anyone else addressing: How about security? I understand that as DAV uses http as the underlying protocol, I can use SSL as a way to enhance security, and realms on my server to exclude unwanted visitors. What I am more interested in is if there is any support in current clients for more rigorous security, eg RSA encryption or similar approaches? If I use a webclient such as IE or Netscape the answer is rather obvious, but how is it with webfolders in Windows, how will it work in Mac OS X, does Adobe support it in Photoshop and InDesign, has Microsoft done anything like that in Office 2000, Office XP and so forth? If this is a topic on another list, please let me know. Regards, Max Elander (Content Manager, AcadeMedia World) From w3c-dist-auth-request@w3.org Fri Mar 9 11:46: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 LAA21745 for ; Fri, 9 Mar 2001 11:46:28 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA20402; Fri, 9 Mar 2001 11:37:09 -0500 (EST) Resent-Date: Fri, 9 Mar 2001 11:37:09 -0500 (EST) Resent-Message-Id: <200103091637.LAA20402@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 LAA20381 for ; Fri, 9 Mar 2001 11:37:03 -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 LAA17180 for ; Fri, 9 Mar 2001 11:37:02 -0500 Received: from beaver (speedy.rtfm.com [198.144.206.141] (may be forged)) by shell.tsoft.com (8.8.7/8.8.7) with SMTP id IAA02321; Fri, 9 Mar 2001 08:36:24 -0800 (PST) From: "Lisa Dusseault" To: "Max Elander" , "WebDAV-listan" Date: Fri, 9 Mar 2001 08:35:24 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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.00.2919.6700 Importance: Normal Subject: RE: Security and WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4699 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by www19.w3.org id LAA20402 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA21745 "SSL or RSA" is a category error. SSL is a protocol that uses various encryption algorithms. RSA is the key exchange and digital signature algorithm most commonly used by SSL. What exactly is it you're trying to do that you think that SSL can't do? For more information on the interaction between HTTP and SSL, check out RFC 2817 and RFC 2818 or a book on SSL (the two SSL books are Rescorla and Thomas). I don't know for sure, but I can make some reasonable surmises about how Web Folders works. If it uses the same internet layer that other MS applications do, and I'm fairly certain it does, then it will recognize URLs that are for HTTP over SSL ("https:") and act accordingly. I do know Web Folders will prompt the user for a username/password if it attempts to access protected resources on a server and gets the right error back. It should work the same in any other WebDAV client on any platform. The use of HTTP with SSL is a well-understood problem with an interoperable standards-based solution. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Max Elander > Sent: Friday, March 09, 2001 12:30 AM > To: WebDAV-listan > Subject: Security and WebDAV > > > Hi! > > I have been lurking on the list for a couple of weeks now and thought I¹d > come out of the shadows to ask a question that I haven¹t seen anyone else > addressing: > > How about security? I understand that as DAV uses http as the underlying > protocol, I can use SSL as a way to enhance security, and realms on my > server to exclude unwanted visitors. > > What I am more interested in is if there is any support in current clients > for more rigorous security, eg RSA encryption or similar approaches? > > If I use a webclient such as IE or Netscape the answer is rather obvious, > but how is it with webfolders in Windows, how will it work in Mac > OS X, does > Adobe support it in Photoshop and InDesign, has Microsoft done > anything like > that in Office 2000, Office XP and so forth? > > If this is a topic on another list, please let me know. > > Regards, Max Elander > (Content Manager, AcadeMedia World) From w3c-dist-auth-request@w3.org Tue Mar 13 15:12:12 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 PAA27540 for ; Tue, 13 Mar 2001 15:12:11 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA04714; Tue, 13 Mar 2001 15:03:53 -0500 (EST) Resent-Date: Tue, 13 Mar 2001 15:03:53 -0500 (EST) Resent-Message-Id: <200103132003.PAA04714@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 PAA04691 for ; Tue, 13 Mar 2001 15:03:48 -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 PAA00318 for ; Tue, 13 Mar 2001 15:03:48 -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 MAA02041 for ; Tue, 13 Mar 2001 12:03:52 -0800 (PST) From: "Jim Whitehead" To: "WebDAV WG" Date: Tue, 13 Mar 2001 12:02:43 -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: FW: OASIS -- Security Assertions Markup Language (SAML) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4700 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I've added Edwin's email address to the accept2 list, so future email from this address will not get through. - Jim -----Original Message----- From: DeSouza, Edwin [mailto:edesouza@jamcracker.com] Sent: Monday, March 12, 2001 5:29 PM To: 'w3c-dist-auth@w3.org' Subject: [Moderator Action] OASIS -- Security Assertions Markup Language (SAML) Hi DAVers, DAV is Distributed Authoring and Versioning. So, you may be interested in SAML -- whose goal is to provide a standard mechanism to "securely work across an ecosystem of independent websites". SAML Home: http://www.oasis-open.org/committees/security/ Discussions (most activity is in the UseCase list): http://www.oasis-open.org/committees/security/#mailinglists Finally, you may be particularly interested in the Distributed Session Management draft input: http://www.oasis-open.org/committees/security/docs/draft-orchard-itml-sessio n-00.pdf Regards, Edwin. From w3c-dist-auth-request@w3.org Thu Mar 15 05:27: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 FAA28026 for ; Thu, 15 Mar 2001 05:27:36 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA00110; Thu, 15 Mar 2001 05:13:36 -0500 (EST) Resent-Date: Thu, 15 Mar 2001 05:13:36 -0500 (EST) Resent-Message-Id: <200103151013.FAA00110@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 FAA00088 for ; Thu, 15 Mar 2001 05:13:32 -0500 (EST) Received: from smtp-relay-1.Adobe.COM (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA04985 for ; Thu, 15 Mar 2001 05:13:31 -0500 Received: from inner-relay-1.Adobe.COM (inner-relay-1.corp.adobe.com [153.32.1.51]) by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id CAA29878 for ; Thu, 15 Mar 2001 02:16:39 -0800 (PST) Received: from mail-hamburg.eur.Adobe.COM by inner-relay-1.Adobe.COM (8.8.5) with ESMTP id CAA09152; Thu, 15 Mar 2001 02:12:07 -0800 (PST) Received: by mail-hamburg.eur.Adobe.COM (8.7.5) with ESMTP id LAA03707; Thu, 15 Mar 2001 11:07:41 +0100 (MET) Message-ID: <3AB095A9.80024A0C@adobe.com> Date: Thu, 15 Mar 2001 11:12:57 +0100 From: Hartmut Warncke X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: WebDAV WG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Retrieving the lockdiscovery property from a non locked resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4701 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, if '/a.html' is a resource which is *not* locked and the client sends a ... ... on that resource, the mod_dav server responds witth a: /a.html HTTP/1.1 200 OK ... So, mod_dav sends an empty lockdiscovery element. IIS responds with: ... /a.html HTTP/1.1 200 OK ... So, IIS sends no lockdiscovery property at all. In RFC2518; section 8.1 I found the following sentence: "A request to retrieve the value of a property which does not exist is an error and MUST be noted, if the response uses a multistatus XML element, with a response XML element which contains a 404 (Not Found) status value." Does this sentence applies only to user-defined properties and not to DAV build-in properties like the lockdiscovery property? What is the correct server behaviour? Best, Hartmut From w3c-dist-auth-request@w3.org Thu Mar 15 08:32: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 IAA29049 for ; Thu, 15 Mar 2001 08:32:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA06058; Thu, 15 Mar 2001 08:21:42 -0500 (EST) Resent-Date: Thu, 15 Mar 2001 08:21:42 -0500 (EST) Resent-Message-Id: <200103151321.IAA06058@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 IAA06034 for ; Thu, 15 Mar 2001 08:21:37 -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 IAA20392 for ; Thu, 15 Mar 2001 08:21:37 -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 IAA102936 for ; Thu, 15 Mar 2001 08:16:37 -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 f2FDLTb81928 for ; Thu, 15 Mar 2001 08:21:29 -0500 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Jim Amsden" Date: Thu, 15 Mar 2001 08:22:24 -0500 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 03/15/2001 08:21:29 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Retrieving the lockdiscovery property from a non locked resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4702 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Hartmut, DAV:lockdiscovery is a live property that always exists for every resource that supports locking. So mod_dav is correct in returning the empty property given that there are no locks. I suppose IIS could be considered correct too as there isn't that much difference between an empty element and no element in this case. Hartmut Warncke M> cc: Sent by: Subject: Retrieving the lockdiscovery property from a non w3c-dist-auth-requ locked resource est@w3.org 03/15/2001 05:12 AM Hi all, if '/a.html' is a resource which is *not* locked and the client sends a ... ... on that resource, the mod_dav server responds witth a: /a.html HTTP/1.1 200 OK ... So, mod_dav sends an empty lockdiscovery element. IIS responds with: ... /a.html HTTP/1.1 200 OK ... So, IIS sends no lockdiscovery property at all. In RFC2518; section 8.1 I found the following sentence: "A request to retrieve the value of a property which does not exist is an error and MUST be noted, if the response uses a multistatus XML element, with a response XML element which contains a 404 (Not Found) status value." Does this sentence applies only to user-defined properties and not to DAV build-in properties like the lockdiscovery property? What is the correct server behaviour? Best, Hartmut From w3c-dist-auth-request@w3.org Thu Mar 15 10:02:32 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 KAA00730 for ; Thu, 15 Mar 2001 10:02:32 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA10065; Thu, 15 Mar 2001 09:45:38 -0500 (EST) Resent-Date: Thu, 15 Mar 2001 09:45:38 -0500 (EST) Resent-Message-Id: <200103151445.JAA10065@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 JAA10045 for ; Thu, 15 Mar 2001 09:45:32 -0500 (EST) Received: from localhost.localdomain ([216.52.68.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA29329 for ; Thu, 15 Mar 2001 09:45:28 -0500 Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2FEq6M07600 for ; Thu, 15 Mar 2001 09:52:06 -0500 Message-ID: <3AB0CB7F.66D245D9@ecal.com> Date: Thu, 15 Mar 2001 09:02:40 -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: WebDAV WG References: <3AB095A9.80024A0C@adobe.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Retrieving the lockdiscovery property from a non locked resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4703 X-Loop: w3c-dist-auth@w3.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 Hartmut Warncke wrote: > "A request to retrieve the value of a property which does not exist is > an error and MUST be noted, if the response uses a multistatus XML > element, with a response XML element which contains a 404 (Not Found) > status value." It looks like the server implementors decided that lockdiscovery exists on all class 2 DAV resources. Otherwise, you wouldn't be able to tell the difference between "resource has no locks" and "resource does not exist". I don't see anything in 2518 to specify it, though. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |You know that logic puzzle with the fox, the | |francis@ecal.com|goose and the grain? What kind of farmer owns a| | |*fox*? | \================================================================/ From w3c-dist-auth-request@w3.org Mon Mar 19 10:51:00 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 KAA13353 for ; Mon, 19 Mar 2001 10:50:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA21299; Mon, 19 Mar 2001 10:40:05 -0500 (EST) Resent-Date: Mon, 19 Mar 2001 10:40:05 -0500 (EST) Resent-Message-Id: <200103191540.KAA21299@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 KAA21271 for ; Mon, 19 Mar 2001 10:39:59 -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 KAA07928 for ; Mon, 19 Mar 2001 10:39:59 -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 KAA120298; Mon, 19 Mar 2001 10:38:42 -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 KAA83320; Mon, 19 Mar 2001 10:35:41 -0500 Importance: Normal To: John Stracke Cc: WebDAV WG X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Mon, 19 Mar 2001 00:14:38 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.6a |January 17, 2001) at 03/19/2001 10:39:55 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Retrieving the lockdiscovery property from a non locked resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4704 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Do we want to modify the spec to specify what behavior we expect? << It looks like the server implementors decided that lockdiscovery exists on all class 2 DAV resources. Otherwise, you wouldn't be able to tell the difference between "resource has no locks" and "resource does not exist". I don't see anything in 2518 to specify it, though. >> From w3c-dist-auth-request@w3.org Mon Mar 19 18:22:00 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 SAA25472 for ; Mon, 19 Mar 2001 18:21:58 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA13147; Mon, 19 Mar 2001 18:02:24 -0500 (EST) Resent-Date: Mon, 19 Mar 2001 18:02:24 -0500 (EST) Resent-Message-Id: <200103192302.SAA13147@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 SAA13107 for ; Mon, 19 Mar 2001 18:02:17 -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 SAA31738 for ; Mon, 19 Mar 2001 18:02:17 -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 PAA25784 for ; Mon, 19 Mar 2001 15:02:20 -0800 (PST) From: "Jim Whitehead" To: "WebDAV WG" Date: Mon, 19 Mar 2001 15:01:07 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01C0B085.6CF10E50" 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: The prospective future of WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4705 X-Loop: w3c-dist-auth@w3.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_002F_01C0B085.6CF10E50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I've added Daniel's email address to the accept2 list, so future emails from him will go through to the list. He's not on the list (as far as I know), so you should include him in any replies. - Jim -----Original Message----- From: Daniel BODEA [mailto:dali@dali-designs.com] Sent: Saturday, March 17, 2001 9:46 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] The prospective future of WebDAV Good evening from Paris, I am working on the draft of an article that will handle the future interoperation of systems and protocols on the Internet. Concerning DAV, my specific question is... Windows and the Office Pack are already integrating Web Folders and WebDAV as a network based file handling system, so growing it to a fully functional File System is the next natural step. Are there trends or is there any incipient project sketch for the integration of DAV as a *nix transparent file system like NFS or SMB? Should this be done, the maturity of the DAV protocol and its spreading among the user community could be greatly augmented. Comment or criticise, but please make a CC to dali@dali-designs.com Thank you, Daniel Bodea ------=_NextPart_000_002F_01C0B085.6CF10E50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Accidentally caught by the spam filter. I've = added=20 Daniel's email address to the accept2 list, so future emails from him = will go=20 through to the list.  He's not on the list (as far as I know), so = you=20 should include him in any replies.
 
-=20 Jim
 
 
-----Original Message-----
From: Daniel BODEA=20 [mailto:dali@dali-designs.com]
Sent: Saturday, March 17, 2001 = 9:46=20 AM
To: w3c-dist-auth@w3.org
Subject: [Moderator = Action] The=20 prospective future of WebDAV

Good evening from Paris,
 
I am working on the draft of an = article that=20 will handle the future interoperation of systems and protocols on = the=20 Internet. Concerning DAV, my specific question is... Windows and the = Office Pack=20 are already integrating Web Folders and WebDAV as a network based file = handling=20 system, so growing it to a fully functional File System is=20 the next natural step. Are there trends or is there any = incipient=20 project sketch for the integration of DAV as a *nix transparent file = system like=20 NFS or SMB? Should this be done, the maturity of the DAV protocol and = its=20 spreading among the user community could be greatly = augmented.
 
Comment or criticise, but = please make a CC to=20 dali@dali-designs.com
 
Thank you,
Daniel Bodea
------=_NextPart_000_002F_01C0B085.6CF10E50-- From w3c-dist-auth-request@w3.org Mon Mar 19 20:53: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 UAA29599 for ; Mon, 19 Mar 2001 20:53:44 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA20599; Mon, 19 Mar 2001 20:47:06 -0500 (EST) Resent-Date: Mon, 19 Mar 2001 20:47:06 -0500 (EST) Resent-Message-Id: <200103200147.UAA20599@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 UAA20579 for ; Mon, 19 Mar 2001 20:47:01 -0500 (EST) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA15398 for ; Mon, 19 Mar 2001 20:46:49 -0500 Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id RAA16808 for ; Mon, 19 Mar 2001 17:46:33 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 19 Mar 2001 17:46:33 -0800 Received: from miobuild (miobuild.apple.com [17.202.40.169]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id RAA21181; Mon, 19 Mar 2001 17:46:32 -0800 (PST) Message-Id: <200103200146.RAA21181@scv2.apple.com> Date: Mon, 19 Mar 2001 17:43:25 -0800 From: Clark Warner Content-Type: text/plain; format=flowed; charset=iso-8859-1 Cc: WebDAV WG To: dali@dali-designs.com X-Mailer: Apple Mail (2.387) In-Reply-To: Mime-Version: 1.0 (Apple Message framework v387) X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id UAA20579 Subject: Re: FW: The prospective future of WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4706 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by www19.w3.org id UAA20599 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA29599 Indeed, Mac OS X will ship with a WebDAV client file system. A preliminary version shipped in Mac OS X Beta. On Monday, March 19, 2001, at 03:01 PM, Jim Whitehead wrote: > Accidentally caught by the spam filter. I've added Daniel's email > address to the accept2 list, so future emails from him will go through > to the list.  He's not on the list (as far as I know), so you should > include him in any replies. >   > - Jim >   >   > -----Original Message----- > From: Daniel BODEA [mailto:dali@dali-designs.com] > Sent: Saturday, March 17, 2001 9:46 AM > To: w3c-dist-auth@w3.org > Subject: [Moderator Action] The prospective future of WebDAV > > Good evening from Paris, >   > I am working on the draft of an article that will handle the > future interoperation of systems and protocols on the Internet. > Concerning DAV, my specific question is... Windows and the Office Pack > are already integrating Web Folders and WebDAV as a network based file > handling system, so growing it to a fully functional File System is > the next natural step. Are there trends or is there any incipient > project sketch for the integration of DAV as a *nix transparent file > system like NFS or SMB? Should this be done, the maturity of the DAV > protocol and its spreading among the user community could be greatly > augmented. >   > Comment or criticise, but please make a CC to dali@dali-designs.com >   > Thank you, > Daniel Bodea Clark H. Warner Manager CoreOS File Systems Engineering warner.c@apple.com -------------------------------- From w3c-dist-auth-request@w3.org Tue Mar 20 01:29: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 BAA12357 for ; Tue, 20 Mar 2001 01:29:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA00027; Tue, 20 Mar 2001 01:23:07 -0500 (EST) Resent-Date: Tue, 20 Mar 2001 01:23:07 -0500 (EST) Resent-Message-Id: <200103200623.BAA00027@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 BAA00007 for ; Tue, 20 Mar 2001 01:23:02 -0500 (EST) Received: from smtp-relay-1.Adobe.COM (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA03076 for ; Tue, 20 Mar 2001 01:23:02 -0500 Received: from inner-relay-1.Adobe.COM (inner-relay-1.corp.adobe.com [153.32.1.51]) by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id WAA24828 for ; Mon, 19 Mar 2001 22:26:09 -0800 (PST) Received: from mailsj-v1.corp.adobe.com by inner-relay-1.Adobe.COM (8.8.5) with ESMTP id WAA22576; Mon, 19 Mar 2001 22:21:38 -0800 (PST) Received: from dbrotsky ([130.248.193.11]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id GAHGDH00.6MY for ; Mon, 19 Mar 2001 22:22:29 -0800 Message-Id: <4.2.2.20010319221955.01468cb0@mailsj.corp.adobe.com> X-Sender: dbrotsky@mailsj.corp.adobe.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 19 Mar 2001 22:21:58 -0800 To: w3c-dist-auth@w3c.org From: "Dan Brotsky" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id BAA00007 Subject: LOCK of resource in non-existent collection & 409 response Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4707 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by www19.w3.org id BAA00027 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA12357 (I sent this last July, but there was no discussion and it doesn't appear on the issues list. So I'm resending in an attempt to get it on the issues list. -dan) In the discussion of PUT, MKCOL, COPY, and MOVE it is made very clear that attempting to create a resource not all of whose parent collections exist MUST result in a 409 response. But in the discussion of LOCK there is no such requirement. Why? At first I thought that perhaps the intent was to allow reserving a particular name, and only if that name was available (i.e., the lock succeeded) would the client create the intermediate collections. But this scenario, aside from its doubtful utility, seems to contradict the language of section 7.4 which says that a (write-)lock-null resource MUST appear as a member of its parent collection (which doesn't exist in this case). I realize that the 409 response is already mandated when an attempt to lock an existing collection (other than at depth 0) conflicts with existing locks on members (at some level). But there is no possible confusion between this use of 409 and the one I am proposing. So I propose the following clarifications: 1. In section 8.10.1, add the following paragraph: A LOCK request on a non-existent resource without an appropriately scoped parent collection MUST fail with a 409 (Conflict) response whose body is empty. 2. In section 8.10.7 add the following: 409 (Conflict) ­ Case 1. A non-existent resource cannot be locked at the destination until one or more intermediate collections have been created. There MUST be no response body. Case 2. A LOCK request (depth > 0) on an existing collection would conflict with existing locks on members of the collection. The response body SHOULD be a multi-status indicating the members in conflict. dan Dan Brotsky, Adobe Systems From w3c-dist-auth-request@w3.org Tue Mar 20 11:44:22 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 LAA12681 for ; Tue, 20 Mar 2001 11:44:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA01342; Tue, 20 Mar 2001 11:28:47 -0500 (EST) Resent-Date: Tue, 20 Mar 2001 11:28:47 -0500 (EST) Resent-Message-Id: <200103201628.LAA01342@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 LAA01317 for ; Tue, 20 Mar 2001 11:28:42 -0500 (EST) Received: from mail.wayport.net (mail.wayport.net [216.12.231.53]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA01879 for ; Tue, 20 Mar 2001 11:28:41 -0500 Received: from Tycho (dhcp64-134-126-229.sjcc.sjc.wayport.net [64.134.126.229]) by mail.wayport.net (8.10.1/8.10.1) with SMTP id f2KGRe316436 for ; Tue, 20 Mar 2001 10:27:40 -0600 (CST) From: "Jim Whitehead" To: "WebDAV WG" Date: Tue, 20 Mar 2001 08:27:02 -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: FW: DAV:supportedlock in IIS, was RE: Bug in WebDAV draft of April 1, 1998? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4708 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I've added to the accept2 list, so future emails from Julian will go straight through to the list. - Jim -----Original Message----- From: Julian F. Reschke [mailto:julian.reschke@greenbytes.de] Sent: Tuesday, March 20, 2001 6:50 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] DAV:supportedlock in IIS, was RE: Bug in WebDAV draft of April 1, 1998? re: : Seems that IIS actually still behaves this way... From w3c-dist-auth-request@w3.org Tue Mar 20 11:54: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 LAA13131 for ; Tue, 20 Mar 2001 11:54:39 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA02345; Tue, 20 Mar 2001 11:45:44 -0500 (EST) Resent-Date: Tue, 20 Mar 2001 11:45:44 -0500 (EST) Resent-Message-Id: <200103201645.LAA02345@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 LAA02324 for ; Tue, 20 Mar 2001 11:45:28 -0500 (EST) Received: from alcatraz.babcockbrown.com (alcatraz.babcockbrown.com [208.1.254.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA04091 for ; Tue, 20 Mar 2001 11:45:23 -0500 Received: from sausalito.babcockbrown.com (sausalito.babcockbrown.com [208.1.254.13]) by alcatraz.babcockbrown.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06514; Tue, 20 Mar 2001 08:43:47 +0800 (GMT) Received: from bay.babcockbrown.com (localhost [127.0.0.1]) by sausalito.babcockbrown.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03924; Tue, 20 Mar 2001 08:45:00 +0800 (GMT) Received: from babcockbrown.com by bay.babcockbrown.com (8.8.8+Sun/SMI-SVR4) id IAA27293; Tue, 20 Mar 2001 08:45:38 -0800 (PST) Message-ID: <3AB78964.F487058F@babcockbrown.com> Date: Tue, 20 Mar 2001 08:46:28 -0800 From: Ian Stoba X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Clark Warner CC: dali@dali-designs.com, WebDAV WG References: <200103200146.RAA21181@scv2.apple.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: FW: The prospective future of WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4709 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm not familiar with the details of the implementation, but Apple's iTools product for Mac OS 9.x also appears to use WebDAV. Clark Warner wrote: > Indeed, Mac OS X will ship with a WebDAV client file system. A > preliminary version shipped in Mac OS X Beta. > > On Monday, March 19, 2001, at 03:01 PM, Jim Whitehead wrote: > > > Accidentally caught by the spam filter. I've added Daniel's email > > address to the accept2 list, so future emails from him will go through > > to the list. He's not on the list (as far as I know), so you should > > include him in any replies. > > > > - Jim > > > > > > -----Original Message----- > > From: Daniel BODEA [mailto:dali@dali-designs.com] > > Sent: Saturday, March 17, 2001 9:46 AM > > To: w3c-dist-auth@w3.org > > Subject: [Moderator Action] The prospective future of WebDAV > > > > Good evening from Paris, > > > > I am working on the draft of an article that will handle the > > future interoperation of systems and protocols on the Internet. > > Concerning DAV, my specific question is... Windows and the Office Pack > > are already integrating Web Folders and WebDAV as a network based file > > handling system, so growing it to a fully functional File System is > > the next natural step. Are there trends or is there any incipient > > project sketch for the integration of DAV as a *nix transparent file > > system like NFS or SMB? Should this be done, the maturity of the DAV > > protocol and its spreading among the user community could be greatly > > augmented. > > > > Comment or criticise, but please make a CC to dali@dali-designs.com > > > > Thank you, > > Daniel Bodea > > Clark H. Warner > Manager > CoreOS File Systems Engineering > warner.c@apple.com > -------------------------------- From w3c-dist-auth-request@w3.org Tue Mar 20 12:01: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 MAA13517 for ; Tue, 20 Mar 2001 12:01:56 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA02898; Tue, 20 Mar 2001 11:55:07 -0500 (EST) Resent-Date: Tue, 20 Mar 2001 11:55:07 -0500 (EST) Resent-Message-Id: <200103201655.LAA02898@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 LAA02861 for ; Tue, 20 Mar 2001 11:54:59 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-38032.rational.com [192.229.38.32]) by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA05144 for ; Tue, 20 Mar 2001 11:54:59 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Tue, 20 Mar 2001 11:55:00 -0500 (Eastern Standard Time) Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Mar 2001 11:55:00 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E22F8@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Tue, 20 Mar 2001 11:54:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id LAA02861 Subject: RE: LOCK of resource in non-existent collection & 409 response Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4710 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by www19.w3.org id LAA02898 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA13517 From: Dan Brotsky [mailto:dbrotsky@Adobe.COM] In the discussion of PUT, MKCOL, COPY, and MOVE it is made very clear that attempting to create a resource not all of whose parent collections exist MUST result in a 409 response. But in the discussion of LOCK there is no such requirement. Why? Probably the authors felt it wasn't necessary to restate this requirement (but I'm just guessing). At first I thought that perhaps the intent was to allow reserving a particular name, and only if that name was available (i.e., the lock succeeded) would the client create the intermediate collections. But this scenario, aside from its doubtful utility, seems to contradict the language of section 7.4 which says that a (write-)lock-null resource MUST appear as a member of its parent collection (which doesn't exist in this case). Yes, my interpretation is also that this is disallowed, because of the language of 7.4. I realize that the 409 response is already mandated when an attempt to lock an existing collection (other than at depth 0) conflicts with existing locks on members (at some level). But there is no possible confusion between this use of 409 and the one I am proposing. So I propose the following clarifications: 1. In section 8.10.1, add the following paragraph: A LOCK request on a non-existent resource without an appropriately scoped parent collection MUST fail with a 409 (Conflict) response whose body is empty. The 409 response is fine, but the requirement that the body be empty is not. RFC 2616 states: "The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required." 2. In section 8.10.7 add the following: 409 (Conflict) ­ Case 1. A non-existent resource cannot be locked at the destination until one or more intermediate collections have been created. There MUST be no response body. OK, except for last sentence which should be deleted. Case 2. A LOCK request (depth > 0) on an existing collection would conflict with existing locks on members of the collection. The response body SHOULD be a multi-status indicating the members in conflict. OK by me. Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Mar 20 12:57: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 MAA15855 for ; Tue, 20 Mar 2001 12:57:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA06092; Tue, 20 Mar 2001 12:50:03 -0500 (EST) Resent-Date: Tue, 20 Mar 2001 12:50:03 -0500 (EST) Resent-Message-Id: <200103201750.MAA06092@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 MAA06069 for ; Tue, 20 Mar 2001 12:49:53 -0500 (EST) Received: from localhost.localdomain (pcp000702pcs.wireless.meeting.ietf.org [135.222.64.202]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA11753 for ; Tue, 20 Mar 2001 12:49:53 -0500 Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2KHueZ05862; Tue, 20 Mar 2001 12:56:40 -0500 Message-ID: <3AB783AA.DE62DF13@ecal.com> Date: Tue, 20 Mar 2001 10:22:02 -0600 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: WebDAV WG CC: dali@dali-designs.com References: <200103200146.RAA21181@scv2.apple.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: FW: The prospective future of WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4711 X-Loop: w3c-dist-auth@w3.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 Clark Warner wrote: > Indeed, Mac OS X will ship with a WebDAV client file system. A > preliminary version shipped in Mac OS X Beta. Is it included in Darwin? -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Rope is rope, and string is string, and never| |francis@ecal.com|the twine shall meet. | \==============================================================/ From w3c-dist-auth-request@w3.org Tue Mar 20 13:02: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 NAA16194 for ; Tue, 20 Mar 2001 13:02:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA06203; Tue, 20 Mar 2001 12:52:26 -0500 (EST) Resent-Date: Tue, 20 Mar 2001 12:52:26 -0500 (EST) Resent-Message-Id: <200103201752.MAA06203@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 MAA06180 for ; Tue, 20 Mar 2001 12:52:20 -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 MAA12019 for ; Tue, 20 Mar 2001 12:52:10 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id JAA17546 for w3c-dist-auth@w3c.org; Tue, 20 Mar 2001 09:51:55 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Tue, 20 Mar 2001 09:51:55 -0800 From: Greg Stein To: w3c-dist-auth@w3c.org Message-ID: <20010320095155.W27539@lyra.org> Mail-Followup-To: w3c-dist-auth@w3c.org References: <3906C56A7BD1F54593344C05BD1374B1018E22F8@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1018E22F8@SUS-MA1IT01>; from gclemm@rational.com on Tue, Mar 20, 2001 at 11:54:51AM -0500 X-URL: http://www.lyra.org/greg/ Subject: Re: LOCK of resource in non-existent collection & 409 response Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4712 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by www19.w3.org id MAA06203 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA16194 On Tue, Mar 20, 2001 at 11:54:51AM -0500, Clemm, Geoff wrote: >... > So I propose the following clarifications: > > 1. In section 8.10.1, add the following paragraph: > > A LOCK request on a non-existent resource without an appropriately > scoped parent collection MUST fail with a 409 (Conflict) response > whose body is empty. > > The 409 response is fine, but the requirement that the body be empty > is not. RFC 2616 states: >... > 2. In section 8.10.7 add the following: > > 409 (Conflict) ­ Case 1. A non-existent resource cannot be locked > at the destination until one or more intermediate collections have > been created. There MUST be no response body. > > OK, except for last sentence which should be deleted. > > Case 2. A LOCK request (depth > 0) on an existing collection would > conflict with existing locks on members of the collection. The > response body SHOULD be a multi-status indicating the members in > conflict. > > OK by me. I'm with Geoff. It all looks fine, except for the "no body" thing. (and I'll note mod_dav actually barfs with a 500 in this scenario) Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Mar 20 15:47:44 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 PAA24223 for ; Tue, 20 Mar 2001 15:47:42 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA17238; Tue, 20 Mar 2001 15:40:04 -0500 (EST) Resent-Date: Tue, 20 Mar 2001 15:40:04 -0500 (EST) Resent-Message-Id: <200103202040.PAA17238@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 PAA17216 for ; Tue, 20 Mar 2001 15:39:55 -0500 (EST) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA30299 for ; Tue, 20 Mar 2001 15:39:54 -0500 Received: by zcamail04.zca.compaq.com (Postfix, from userid 12345) id B86521D2; Tue, 20 Mar 2001 12:40:39 -0800 (PST) Received: from exchou-gh02.cca.cpqcorp.net (exchou-gh02.cca.cpqcorp.net [16.110.248.202]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 3637F2BE; Tue, 20 Mar 2001 12:40:39 -0800 (PST) Received: by exchou-gh02.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Tue, 20 Mar 2001 14:39:15 -0600 Message-ID: From: "Wang, Pin-Chieh" To: "Greg Stein (E-mail)" Cc: "'w3c-dist-auth@w3c.org'" Date: Tue, 20 Mar 2001 14:39:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Subject: Mod_dav Build Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4713 X-Loop: w3c-dist-auth@w3.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 Greg, I build mod_dav-1.0.2-1.3.6 with Apache_1.3.14 I used the ./configure --with-apxs=/usr/local/apache/bin/apxs make make install seems to be o.k. But when I run start apache I got "Can't load /usr/local/apache/libexec/libdav.so into server : undefined symbol: XML_SetElementHandler" The file libdav.so does exist. Any body can explain why? Thanks PC Wang From w3c-dist-auth-request@w3.org Tue Mar 20 17:13: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 RAA28083 for ; Tue, 20 Mar 2001 17:13:28 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA22312; Tue, 20 Mar 2001 16:55:42 -0500 (EST) Resent-Date: Tue, 20 Mar 2001 16:55:42 -0500 (EST) Resent-Message-Id: <200103202155.QAA22312@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 QAA22281 for ; Tue, 20 Mar 2001 16:55:34 -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 QAA07563 for ; Tue, 20 Mar 2001 16:55:32 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id NAA23363; Tue, 20 Mar 2001 13:55:13 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Tue, 20 Mar 2001 13:55:13 -0800 From: Greg Stein To: "Wang, Pin-Chieh" Cc: "'w3c-dist-auth@w3c.org'" Message-ID: <20010320135512.D27539@lyra.org> Mail-Followup-To: "Wang, Pin-Chieh" , "'w3c-dist-auth@w3c.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 Pin-Chieh.Wang@compaq.com on Tue, Mar 20, 2001 at 02:39:13PM -0600 X-URL: http://www.lyra.org/greg/ Subject: Re: Mod_dav Build Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4714 X-Loop: w3c-dist-auth@w3.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 Tue, Mar 20, 2001 at 02:39:13PM -0600, Wang, Pin-Chieh wrote: > Hi Greg, > I build mod_dav-1.0.2-1.3.6 with Apache_1.3.14 > I used the ./configure --with-apxs=/usr/local/apache/bin/apxs > make > make install > > seems to be o.k. > But when I run start apache I got "Can't load > /usr/local/apache/libexec/libdav.so into server : undefined symbol: > XML_SetElementHandler" > The file libdav.so does exist. > > Any body can explain why? Did you build your Apache without Expat in it? If so, then you'll need to reconfigure mod_dav to use an external Expat library (--with-expat=...) Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Mar 21 04:05: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 EAA09255 for ; Wed, 21 Mar 2001 04:05:32 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA15896; Wed, 21 Mar 2001 03:55:21 -0500 (EST) Resent-Date: Wed, 21 Mar 2001 03:55:21 -0500 (EST) Resent-Message-Id: <200103210855.DAA15896@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 DAA15872 for ; Wed, 21 Mar 2001 03:55:15 -0500 (EST) Received: from aviion.univ-lemans.fr (aviion.univ-lemans.fr [195.221.244.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA26403 for ; Wed, 21 Mar 2001 03:55:13 -0500 Received: from christine ([194.214.59.5]) by aviion.univ-lemans.fr (8.11.2/jtpda-5.3.3) with SMTP id f2L8sRm06611 for ; Wed, 21 Mar 2001 09:54:31 +0100 (MET) Message-Id: <200103210854.f2L8sRm06611@aviion.univ-lemans.fr> X-Sender: delannoy@aviion.univ-lemans.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 21 Mar 2001 09:44:45 +0100 To: w3c-dist-auth@w3c.org From: Paul Delannoy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: DAV's Web page in French Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4715 X-Loop: w3c-dist-auth@w3.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 ! I am glad to announce a new URL for DAV's publicity, in French : http://www.univ-lemans.fr/~delannoy/DAV I wrote this page arround a translation of WebRFM, the free product from Yoram Last for managing Unix/Linus accounts. I want (i hope !) your reactions, suggests, and so on. Hope That Help Paul Delannoy 42 rue du Millau 44300 NANTES 33-0240301814 http://www.univ-lemans.fr/~delannoy From w3c-dist-auth-request@w3.org Wed Mar 21 12:05: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 MAA00528 for ; Wed, 21 Mar 2001 12:05:35 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA16007; Wed, 21 Mar 2001 11:49:06 -0500 (EST) Resent-Date: Wed, 21 Mar 2001 11:49:06 -0500 (EST) Resent-Message-Id: <200103211649.LAA16007@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 LAA15987 for ; Wed, 21 Mar 2001 11:49:02 -0500 (EST) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA09309 for ; Wed, 21 Mar 2001 11:49:01 -0500 Received: by zcamail04.zca.compaq.com (Postfix, from userid 12345) id D7DDD144; Wed, 21 Mar 2001 08:49:42 -0800 (PST) Received: from exchou-gh02.cca.cpqcorp.net (exchou-gh02.cca.cpqcorp.net [16.110.248.202]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 9427D172 for ; Wed, 21 Mar 2001 08:49:42 -0800 (PST) Received: by exchou-gh02.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Wed, 21 Mar 2001 10:48:19 -0600 Message-ID: From: "Wang, Pin-Chieh" To: "'w3c-dist-auth@w3c.org'" Date: Wed, 21 Mar 2001 10:48:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain Subject: RE: Mod_dav Build Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4716 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Hi, I have some problem building mod_dav into Apache, Looking at the instruction page it require Expat modules, But I only find expat-lite coming with Apache_1.3.14. (The instruction says Expat is included in Apache_1.3.9 or newer version) Any body know, is "Expat" the same as "expat-lite"? or I need to install Expat in addition of expat-lite. Since I don't want to include unnecessary packages. Thanks PC Wang From w3c-dist-auth-request@w3.org Wed Mar 21 16:49: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 QAA16619 for ; Wed, 21 Mar 2001 16:49:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA00618; Wed, 21 Mar 2001 16:29:24 -0500 (EST) Resent-Date: Wed, 21 Mar 2001 16:29:24 -0500 (EST) Resent-Message-Id: <200103212129.QAA00618@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 QAA00598 for ; Wed, 21 Mar 2001 16:29:18 -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 QAA07199 for ; Wed, 21 Mar 2001 16:29:14 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id NAA24631; Wed, 21 Mar 2001 13:29:10 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Wed, 21 Mar 2001 13:29:10 -0800 From: Greg Stein To: "Wang, Pin-Chieh" Cc: "'w3c-dist-auth@w3c.org'" , dav-dev@lyra.org Message-ID: <20010321132909.F27539@lyra.org> Mail-Followup-To: "Wang, Pin-Chieh" , "'w3c-dist-auth@w3c.org'" , dav-dev@lyra.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 Pin-Chieh.Wang@compaq.com on Wed, Mar 21, 2001 at 10:48:16AM -0600 X-URL: http://www.lyra.org/greg/ Subject: Re: Mod_dav Build Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4717 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: [ the correct mailing list for mod_dav is dav-dev@lyra.org ] On Wed, Mar 21, 2001 at 10:48:16AM -0600, Wang, Pin-Chieh wrote: > > Hi, > > I have some problem building mod_dav into Apache, Looking at the instruction > page it require Expat modules, > But I only find expat-lite coming with Apache_1.3.14. (The instruction says > Expat is included in Apache_1.3.9 or newer version) > > Any body know, is "Expat" the same as "expat-lite"? It is the same, and mod_dav will automatically detect it and use it. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Mar 21 17:54: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 RAA20433 for ; Wed, 21 Mar 2001 17:54:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA02671; Wed, 21 Mar 2001 17:39:19 -0500 (EST) Resent-Date: Wed, 21 Mar 2001 17:39:19 -0500 (EST) Resent-Message-Id: <200103212239.RAA02671@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 RAA02646 for ; Wed, 21 Mar 2001 17:39:13 -0500 (EST) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA13616 for ; Wed, 21 Mar 2001 17:39:11 -0500 Received: by zcamail04.zca.compaq.com (Postfix, from userid 12345) id 0D72F294; Wed, 21 Mar 2001 14:40:02 -0800 (PST) Received: from exchou-gh02.cca.cpqcorp.net (exchou-gh02.cca.cpqcorp.net [16.110.248.202]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id AB0B3371; Wed, 21 Mar 2001 14:40:01 -0800 (PST) Received: by exchou-gh02.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Wed, 21 Mar 2001 16:38:38 -0600 Message-ID: From: "Wang, Pin-Chieh" To: "'Greg Stein'" Cc: "'w3c-dist-auth@w3c.org'" , dav-dev@lyra.org Date: Wed, 21 Mar 2001 16:38:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain Subject: RE: Mod_dav Build Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4718 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: The mod_dav did not resolve it. I finally resolved this by download the expat from the web, rebuild from the source and copy .h and .so into proper directory. (I am using Linux 7.0/Apache 1.3.14/with mod_perl-1.25 build with DSO) My next question is how I am going to test if this is working? Thanks PC [ the correct mailing list for mod_dav is dav-dev@lyra.org ] On Wed, Mar 21, 2001 at 10:48:16AM -0600, Wang, Pin-Chieh wrote: > > Hi, > > I have some problem building mod_dav into Apache, Looking at the instruction > page it require Expat modules, > But I only find expat-lite coming with Apache_1.3.14. (The instruction says > Expat is included in Apache_1.3.9 or newer version) > > Any body know, is "Expat" the same as "expat-lite"? It is the same, and mod_dav will automatically detect it and use it. Cheers, -g From w3c-dist-auth-request@w3.org Wed Mar 21 21:24:47 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 VAA01706 for ; Wed, 21 Mar 2001 21:24:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA07780; Wed, 21 Mar 2001 21:10:03 -0500 (EST) Resent-Date: Wed, 21 Mar 2001 21:10:03 -0500 (EST) Resent-Message-Id: <200103220210.VAA07780@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 VAA07758 for ; Wed, 21 Mar 2001 21:09:54 -0500 (EST) Received: from usrsrv1.meeting.ietf.org (smtp.meeting.ietf.org [135.222.20.40]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA31218 for ; Wed, 21 Mar 2001 21:09:54 -0500 Received: from Tycho (pcp000658pcs.wireless.meeting.ietf.org [135.222.64.158]) by usrsrv1.meeting.ietf.org (8.11.2/8.11.2) with SMTP id f2M29Wt14003; Wed, 21 Mar 2001 20:09:32 -0600 (CST) From: "Jim Whitehead" To: "Dan Brotsky" , , Date: Wed, 21 Mar 2001 18:08:25 -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 In-Reply-To: <4.2.2.20010319221955.01468cb0@mailsj.corp.adobe.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: DAV Issues list updated Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4719 X-Loop: w3c-dist-auth@w3.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 added the issues raised by Dan Brotsky and Hatmut Warncke to the issues list: http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html > (I sent this last July, but there was no discussion and it > doesn't appear on the issues list. So I'm resending in an > attempt to get it on the issues list. -dan) Sorry about this -- this must have been a victim of my PhD dissertation writing efforts. - Jim From w3c-dist-auth-request@w3.org Fri Mar 23 10:59:56 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 KAA20720 for ; Fri, 23 Mar 2001 10:59:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA24812; Fri, 23 Mar 2001 10:41:45 -0500 (EST) Resent-Date: Fri, 23 Mar 2001 10:41:45 -0500 (EST) Resent-Message-Id: <200103231541.KAA24812@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 KAA24792 for ; Fri, 23 Mar 2001 10:41:41 -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 KAA29563 for ; Fri, 23 Mar 2001 10:41:38 -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 KAA70050 for ; Fri, 23 Mar 2001 10:36:19 -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 f2NFfKZ115682 for ; Fri, 23 Mar 2001 10:41:20 -0500 Importance: Normal To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Steve K Speicher" Date: Fri, 23 Mar 2001 10:42:48 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 03/23/2001 10:41:20 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Why MKCOL/PUT can't automatically create ancestor collections? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4720 X-Loop: w3c-dist-auth@w3.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 understand that in RFC2518 that it clearly states that for MKCOL "..all ancestors MUST already exist, or the method MUST fail..." Why is this? I can't find the rationale for not allowing the server to automatically create ancestor collections if needed for PUT/MKCOL request and return "201 Created". Just wasn't sure why this is a MUST requirement instead of a SHOULD, MAY, ... Thanks, Steve From w3c-dist-auth-request@w3.org Fri Mar 23 11:21:35 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 LAA22158 for ; Fri, 23 Mar 2001 11:21:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA26385; Fri, 23 Mar 2001 11:07:29 -0500 (EST) Resent-Date: Fri, 23 Mar 2001 11:07:29 -0500 (EST) Resent-Message-Id: <200103231607.LAA26385@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 LAA26359 for ; Fri, 23 Mar 2001 11:07:23 -0500 (EST) Received: from usrsrv1.meeting.ietf.org (smtp.meeting.ietf.org [135.222.20.40]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA32079 for ; Fri, 23 Mar 2001 11:07:22 -0500 Received: from beaver (pcp000640pcs.wireless.meeting.ietf.org [135.222.64.140]) by usrsrv1.meeting.ietf.org (8.11.2/8.11.2) with SMTP id f2NG72t17608; Fri, 23 Mar 2001 10:07:02 -0600 (CST) From: "Lisa Dusseault" To: "Steve K Speicher" , Date: Fri, 23 Mar 2001 08:05:59 -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.00.2919.6700 Subject: RE: Why MKCOL/PUT can't automatically create ancestor collections? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4721 X-Loop: w3c-dist-auth@w3.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 My opinion on this is that guessing what the intentions of the client might be can often go wrong. The server cannot tell if the user intended to type "foo/myfile.txt" or "food/myfile.txt" into the dialog box. Thus, a simple typo might result in unintended results. (And with delete permissions separate from write permissions, the user might not be able to clean up their mistake). I'd also point out that a WebDAV client is perfectly capable of doing this automatically for the user if that is a desirable feature: the client can receive the error message and resend a MKCOL followed by the original request (or the client software may already be aware that the target directory probably does not exist). If the server enforces the automatic creation of the parent directory it takes away the flexibility of the client to do this or not. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Steve K Speicher > Sent: Friday, March 23, 2001 7:43 AM > To: w3c-dist-auth@w3.org > Subject: Why MKCOL/PUT can't automatically create ancestor collections? > > > I understand that in RFC2518 that it clearly states that for MKCOL "..all > ancestors MUST already exist, or the method MUST fail..." > > Why is this? I can't find the rationale for not allowing the server to > automatically create ancestor collections if needed for PUT/MKCOL request > and return "201 Created". Just wasn't sure why this is a MUST requirement > instead of a SHOULD, MAY, ... > > Thanks, > Steve From w3c-dist-auth-request@w3.org Fri Mar 23 11:34:47 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 LAA23078 for ; Fri, 23 Mar 2001 11:34:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA27394; Fri, 23 Mar 2001 11:24:20 -0500 (EST) Resent-Date: Fri, 23 Mar 2001 11:24:20 -0500 (EST) Resent-Message-Id: <200103231624.LAA27394@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 LAA27367 for ; Fri, 23 Mar 2001 11:24:13 -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 LAA01270 for ; Fri, 23 Mar 2001 11:24:10 -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 LAA63878 for ; Fri, 23 Mar 2001 11:19:00 -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 f2NGO1Z122522 for ; Fri, 23 Mar 2001 11:24:02 -0500 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Jim Amsden" Date: Fri, 23 Mar 2001 11:18:34 -0500 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 03/23/2001 11:24:02 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Why MKCOL/PUT can't automatically create ancestor collections? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4722 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I think the reasoning was the same for PUT, PROPPATCH, etc. You don't want the server creating namespaces as the side effect of an operation. MKCOL and DELETE make namespace manipulations explicit. This prevents erroneously typed URLs from creating spurious namespaces. I understand that in RFC2518 that it clearly states that for MKCOL "..all ancestors MUST already exist, or the method MUST fail..." Why is this? I can't find the rationale for not allowing the server to automatically create ancestor collections if needed for PUT/MKCOL request and return "201 Created". Just wasn't sure why this is a MUST requirement instead of a SHOULD, MAY, ... Thanks, Steve From w3c-dist-auth-request@w3.org Fri Mar 23 11:43: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 LAA23639 for ; Fri, 23 Mar 2001 11:43:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA27845; Fri, 23 Mar 2001 11:28:36 -0500 (EST) Resent-Date: Fri, 23 Mar 2001 11:28:36 -0500 (EST) Resent-Message-Id: <200103231628.LAA27845@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 LAA27801 for ; Fri, 23 Mar 2001 11:28:29 -0500 (EST) Received: from usrsrv1.meeting.ietf.org (smtp.meeting.ietf.org [135.222.20.40]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA01699 for ; Fri, 23 Mar 2001 11:28:24 -0500 Received: from Tycho (pcp000658pcs.wireless.meeting.ietf.org [135.222.64.158]) by usrsrv1.meeting.ietf.org (8.11.2/8.11.2) with SMTP id f2NGSJt17694 for ; Fri, 23 Mar 2001 10:28:19 -0600 (CST) From: "Jim Whitehead" To: "WebDAV WG" Date: Fri, 23 Mar 2001 08:27:11 -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: FW: [Moderator Action] webdav Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4724 X-Loop: w3c-dist-auth@w3.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 accidentally caught by the spam filter. - Jim -----Original Message----- From: Meyyappan Somasundaram [mailto:msomasundaram@kovair.com] Sent: Thursday, March 22, 2001 8:54 PM To: 'w3c-dist-auth@w3.org' Subject: [Moderator Action] webdav Hello Webdav doesn't behave like Windows Explorer. The folder icon does not open when double clicked on it. It is confusing because the user wouldn't know which folder he/she is in in. is there any solution fro this bye bye have nice day From w3c-dist-auth-request@w3.org Fri Mar 23 11:44: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 LAA23738 for ; Fri, 23 Mar 2001 11:44:52 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA28365; Fri, 23 Mar 2001 11:32:21 -0500 (EST) Resent-Date: Fri, 23 Mar 2001 11:32:21 -0500 (EST) Resent-Message-Id: <200103231632.LAA28365@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 LAA28342 for ; Fri, 23 Mar 2001 11:32:14 -0500 (EST) Received: from usrsrv1.meeting.ietf.org (smtp.meeting.ietf.org [135.222.20.40]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA02268 for ; Fri, 23 Mar 2001 11:32:14 -0500 Received: from Tycho (pcp000658pcs.wireless.meeting.ietf.org [135.222.64.158]) by usrsrv1.meeting.ietf.org (8.11.2/8.11.2) with SMTP id f2NGW8t17711; Fri, 23 Mar 2001 10:32:08 -0600 (CST) From: "Jim Whitehead" To: "Meyyappan Somasundaram" , Cc: Date: Fri, 23 Mar 2001 08:31: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 In-Reply-To: <936091CF9671D4118BEF00508BAC4B0C3FA3DF@kovsjexchange.kovair.com> Subject: RE: [Moderator Action] Webdav Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4725 X-Loop: w3c-dist-auth@w3.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 Meyyappan, These are issues with the WebDAV implementation of one vendor (Microsoft), and are not an issue with the protocol itself. This mailing list is only for discussions of the protocol. I recommend that you contact the vendor directly concerning these issues. - Jim Meyyappan Somasundaram writes: > In Webdav , when I click '+' to expand a folder, not all the subfolders > always appear. Often, it's only the folders that I have visited in the > right-side of Windows Explorer that show up on the left-side, under the > parent folder. > is there any soolution for this > Webdav doesn't behave like Windows Explorer. The folder icon does not open > when double clicked on it. It is confusing because the user wouldn't know > which folder he/she is in in. > is there any solution fro this From w3c-dist-auth-request@w3.org Fri Mar 23 11:45: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 LAA23793 for ; Fri, 23 Mar 2001 11:45:35 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA27793; Fri, 23 Mar 2001 11:28:28 -0500 (EST) Resent-Date: Fri, 23 Mar 2001 11:28:28 -0500 (EST) Resent-Message-Id: <200103231628.LAA27793@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 LAA27773 for ; Fri, 23 Mar 2001 11:28:24 -0500 (EST) Received: from usrsrv1.meeting.ietf.org (smtp.meeting.ietf.org [135.222.20.40]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA01696 for ; Fri, 23 Mar 2001 11:28:24 -0500 Received: from Tycho (pcp000658pcs.wireless.meeting.ietf.org [135.222.64.158]) by usrsrv1.meeting.ietf.org (8.11.2/8.11.2) with SMTP id f2NGSJt17691 for ; Fri, 23 Mar 2001 10:28:19 -0600 (CST) From: "Jim Whitehead" To: "WebDAV WG" Date: Fri, 23 Mar 2001 08:27:11 -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: FW: [Moderator Action] Webdav Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4723 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I've added to the accept2 list for the WebDAV mailing list. - Jim -----Original Message----- From: Meyyappan Somasundaram [mailto:msomasundaram@kovair.com] Sent: Thursday, March 22, 2001 8:53 PM To: 'w3c-dist-auth@w3.org' Subject: [Moderator Action] Webdav Hello I have a problem in webdav In Webdav , when I click '+' to expand a folder, not all the subfolders always appear. Often, it's only the folders that I have visited in the right-side of Windows Explorer that show up on the left-side, under the parent folder. is there any soolution for this waiting for u r reply From w3c-dist-auth-request@w3.org Mon Mar 26 20:54: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 UAA24767 for ; Mon, 26 Mar 2001 20:54:56 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA05576; Mon, 26 Mar 2001 20:47:48 -0500 (EST) Resent-Date: Mon, 26 Mar 2001 20:47:48 -0500 (EST) Resent-Message-Id: <200103270147.UAA05576@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 UAA05555 for ; Mon, 26 Mar 2001 20:47:43 -0500 (EST) Received: from pimout1-int.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA10095 for ; Mon, 26 Mar 2001 20:47:43 -0500 Received: from Tycho (ip-20-14-22.albany.navipath.net [64.20.14.22]) by pimout1-int.prodigy.net (8.11.0/8.11.0) with SMTP id f2R1lbn154848 for ; Mon, 26 Mar 2001 20:47:38 -0500 From: "Jim Whitehead" To: "WebDAV WG" Date: Mon, 26 Mar 2001 17:46:23 -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: FW: Why not an encapsulation for DAV over standard HTTP 1.0 or 1.1 without required server extension ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4726 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I've added to the accept2 list, so future emails will go through to the list. - Jim -----Original Message----- From: Philippe Verdy [mailto:verdy_p@wanadoo.fr] Sent: Monday, March 26, 2001 1:26 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Why not an encapsulation for DAV over standard HTTP 1.0 or 1.1 without required server extension ? There's a big problem with WebDAV : it requires HTTP server extensions such as: - new methods: MKCOL, PUT, FINDPROP, DELETE, COPY, MOVE, DELETE, LOCK, UNLOCK - too many new responses It causes many problems to users: - It is unlikely that many web servers will be upgraded to support them. - The protocol does not fit well on many HTTP proxies - Many web hosting companies that use a shared server won't accept to add such extensions (the same ones refuse to implement the so-called FrontPage extension for security reasons) - Users are restricted to publish their web site via FTP only But: - PHP works on classic HTTP 1.0 and 1.1 servers without HTTP extension for DAV - PHP is considered very secure (enough to let web hosting companies accept PHP scripts from their users), and accepted as a valid server extension (and it is already ported to many environments and for many web server implementations) - PHP has a strong support from both users and web hosting companies and has enough capabilities to support a protocol like DAV. This makes DAV implementation possible through a single DAV-compliant script written in PHP. - The PHP DAV script can be updated by users themselves and can easily follow the new standards for DAV, without requiring any change on the web server (the web server will just need to support at least a basic version of PHP3). Users can simply upload the new PHP DAV script using a single FTP transfer to their own account (the PHP script would also contain the name of a user-provided parameter file, which could be also uploaded with FTP, and the name of the DAV script resource if it has to be write-protected from DAV itself). - Other scripting extensions may also be used alternatively to PHP in the future, if such scripting languages are accepted. So why not extending the draft specification of DAV, to allow an encapsulation of the current DAV specification in a single XML request that would contain the DAV method requested and the required credentials ? People would then post to http://webserver/~user/dav/post.php, using POST methods, in multipart/mixed format when posting resource contents, and the answers to the DAV request would not depend on HTTP server responses (the DAV response sould be in the XML response resulting from the HTTP POST request). this would be done instead of specifying the default http://webserver/ address for the main DAV implementation. Additionally, the multipart/mixed format could be used to accelerate the transfer of multiple resources, by using a single chunked multipart/mixed request. I also suggest that the protocol includes the HELP method, to get the list of accepted DAV methods (like it currently exists in FTP), so that a client can query the capabilities of the DAV server (does it support lock/unlock methods ? and so on...) and so that the client can adapt to future versions of the DAV protocol. Note that the same server could then host several versions of the DAV protocol, because each user could choose and upload the implementation he needs to work with its own DAV-aware client. I personnally think it's a very bad idea to link the DAV protocol to the HTTP protocol itself. And there's a way make both coexist separately... From w3c-dist-auth-request@w3.org Mon Mar 26 21:32:22 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 VAA25568 for ; Mon, 26 Mar 2001 21:32:18 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA07168; Mon, 26 Mar 2001 21:25:31 -0500 (EST) Resent-Date: Mon, 26 Mar 2001 21:25:31 -0500 (EST) Resent-Message-Id: <200103270225.VAA07168@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 VAA07135 for ; Mon, 26 Mar 2001 21:25:24 -0500 (EST) Received: from pimout1-int.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA12773 for ; Mon, 26 Mar 2001 21:25:24 -0500 Received: from Tycho (ip-67-66-89.albany.navipath.net [216.67.66.89]) by pimout1-int.prodigy.net (8.11.0/8.11.0) with SMTP id f2R2Ovn62908 for ; Mon, 26 Mar 2001 21:24:57 -0500 From: "Jim Whitehead" To: "WebDAV WG" Date: Mon, 26 Mar 2001 18:23:43 -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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Why not an encapsulation for DAV over standard HTTP 1.0 or 1.1 without required server extension ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4727 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > There's a big problem with WebDAV : it requires HTTP server > extensions such as: > - new methods: MKCOL, PUT, FINDPROP, DELETE, COPY, MOVE, DELETE, LOCK, > UNLOCK > - too many new responses First, a clarification. The HTTP/1.1 specification (RFC 2616, which you haven't read) specifies the methods DELETE and PUT. The WebDAV Distributed Authoring specification (RFC 2518) specifies MKCOL, COPY, MOVE, LOCK, UNLOCK, PROPFIND (FINDPROP isn't in RFC 2518) and PROPPATCH. Second, the entire point of WebDAV was to define a set of HTTP extensions for distributed authoring. To do this, we decided to take advantage of HTTP's designed-in paths of extensibility, namely creating additional methods and response codes. If you talk to Roy Fielding or Henrik Nielsen, you'll find that HTTP was intentionally designed to be extended by adding new methods and new status codes. Doing this is not a problem. > It causes many problems to users: > - It is unlikely that many web servers will be upgraded to support them. In fact, the market leading Web servers already support the protocol. Microsoft's IIS 5 and the mod_dav module for Apache both support WebDAV. IIS and Apache togther account for 75%+ of Web sites on the Internet (according to Netcraft). > - The protocol does not fit well on many HTTP proxies HTTP proxies that do not implement the HTTP/1.1 protocol correctly may have problems passing through WebDAV methods. In my view, this is a temporary problem with the existing installed base of HTTP proxies. > - Many web hosting companies that use a shared server won't accept to add > such extensions (the same ones refuse to implement the so-called FrontPage > extension for security reasons) WebDAV can be significantly more secure than FTP for remote site update, since WebDAV implementations typically do not give users a login account (and many FTP servers do). > - Users are restricted to publish their web site via FTP only WebDAV can easily be used as an alternative to FTP. > But: > - PHP works on classic HTTP 1.0 and 1.1 servers without HTTP extension for > DAV > - PHP is considered very secure (enough to let web hosting > companies accept > PHP scripts from their users), and accepted as a valid server > extension (and > it is already ported to many environments and for many web server > implementations) > - PHP has a strong support from both users and web hosting > companies and has > enough capabilities to support a protocol like DAV. This makes DAV > implementation possible through a single DAV-compliant script written in > PHP. > - The PHP DAV script can be updated by users themselves and can easily > follow the new standards for DAV, without requiring any change on the web > server (the web server will just need to support at least a basic > version of > PHP3). Users can simply upload the new PHP DAV script using a single FTP > transfer to their own account (the PHP script would also contain > the name of > a user-provided parameter file, which could be also uploaded with FTP, and > the name of the DAV script resource if it has to be > write-protected from DAV > itself). > - Other scripting extensions may also be used alternatively to PHP in the > future, if such scripting languages are accepted. > > So why not extending the draft specification of DAV, to allow an > encapsulation of the current DAV specification in a single XML > request that > would contain the DAV method requested and the required credentials ? I'm not an expert on PHP, so take this with a grain of salt. Typically security policies are based on the kind of operations supported by a protocol. If a server doesn't want to support remote writing and namespace manipulation, it won't matter how the protocol is marshalled: as PHP, as XML sent via POST, or some other way -- the server operator will disable the facility if they do not want their users accessing the capability. You might be able to take advantage of a small 2-3 year window while proxy and firewall vendors catch up to the new capability, but in the end the ability to prevent the undesired operations will be added, and administrators will shut down the avenue of access. So, DAV over PHP seems like it would gain a minor 2-3 year advantage at best. Accomplishing this would take a lot of work. And at the end of it all, existing DAV applications wouldn't be able to interoperate with a DAV over PHP server. To me it seems like much less work to try and address some of the DAV shortcomings (certainly upgrading a proxy server is much easier than figuring out how to re-marshall the protocol elements). > People would then post to http://webserver/~user/dav/post.php, using POST > methods, in multipart/mixed format when posting resource contents, and the > answers to the DAV request would not depend on HTTP server responses (the > DAV response sould be in the XML response resulting from the HTTP POST > request). this would be done instead of specifying the default > http://webserver/ address for the main DAV implementation. > > Additionally, the multipart/mixed format could be used to accelerate the > transfer of multiple resources, by using a single chunked multipart/mixed > request. > > I also suggest that the protocol includes the HELP method, to get the list > of accepted DAV methods (like it currently exists in FTP), so > that a client > can query the capabilities of the DAV server (does it support lock/unlock > methods ? and so on...) and so that the client can adapt to > future versions > of the DAV protocol. Note that the same server could then host several > versions of the DAV protocol, because each user could choose and > upload the > implementation he needs to work with its own DAV-aware client. This capability is covered by the OPTIONS method in HTTP. > I personnally think it's a very bad idea to link the DAV protocol to the > HTTP protocol itself. And there's a way make both coexist separately... I disagree. As evidence of the benefits of the DAV-as-HTTP approach, I present the list of existing HTTP clients and servers at http://www.ics.uci.edu/pub/ietf/webdav/. - Jim From w3c-dist-auth-request@w3.org Tue Mar 27 04:56:07 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 EAA16126 for ; Tue, 27 Mar 2001 04:56:07 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA22038; Tue, 27 Mar 2001 04:50:31 -0500 (EST) Resent-Date: Tue, 27 Mar 2001 04:50:31 -0500 (EST) Resent-Message-Id: <200103270950.EAA22038@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 EAA22015 for ; Tue, 27 Mar 2001 04:50:26 -0500 (EST) Received: from tamaris.wanadoo.fr (smtp-rt-12.wanadoo.fr [193.252.19.60]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA15607 for ; Tue, 27 Mar 2001 04:50:24 -0500 Received: from villosa.wanadoo.fr (193.252.19.122) by tamaris.wanadoo.fr; 27 Mar 2001 11:49:53 +0200 Received: from hppve (193.253.243.44) by villosa.wanadoo.fr; 27 Mar 2001 11:49:52 +0200 Message-ID: <004d01c0b6a2$eacaf2a0$2101a8c0@hppve> From: "Philippe Verdy" To: References: Date: Tue, 27 Mar 2001 11:47:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: RE: Why not an encapsulation for DAV over standard HTTP 1.0 or 1.1 without required server extension ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4728 X-Loop: w3c-dist-auth@w3.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 Your answer is informative, but it still does not solve the problem of seb servers that only implement the basic methods: GET, HEAD, OPTIONS, and TRACE. A simple test on many web servers (despite they are using a recent Apache version with mod_perl extension, and even with mod_php allowed), will reveal that most of web servers used by web hosting providers do not allow any DAV protocol because of these limitation: To test it, just use the following telnet session to the HTTP port of the webserver: >> Request: telnet www.webhostingprovider.net 80 OPTIONS / HTTP/1.1 Host: www.webhostingprovider.net >> Answer: HTTP/1.1 200 OK Date: Tue, 27 Mar 2001 08:11:50 GMT Server: Apache/1.3.12 (Unix) Debian/GNU mod_modperl/1.24 Content-Length: 0 Allow: GET, HEAD, OPTIONS, TRACE This (sample) session clearly indicates that DAV cannot work on that webserver, because the required methods are not implemented and I really think that most web hosting providers won't change the current rules of publishing via FTP only... Note that to test the presence of a POST method, you have to find a resource that accepts such posts. Classic default resources for paths only have a default .html file that does not support POST. But, if the default ressource pointed by the home directory is a file like index.php3 which could perform useful actions on POSTS or on other methods, you will see the following result for the same request: >> Answer: HTTP/1.1 200 OK Date: Tue, 27 Mar 2001 08:11:50 GMT Server: Apache/1.3.12 (Unix) Debian/GNU mod_modperl/1.24 Content-Length: 0 Allow: GET, HEAD, POST, OPTIONS, TRACE And thus, there is still no support for other methods, and users are sticked not to use DAV at all, despite they could use an encapsulation of it using POST requests (publishing a web page could also be performed using standard HTML forms which would send the result with the POST method). I think personally that a light version of DAV without HTTP server extension is possible now, without modifying the server to enable new HTTP extensions, and without changing the core of DAV. If the conceptors of DAV do not want to implement it, users will do it themselves ! Your answer suggests me that I could form a group to implement an encapsulation of DAV over POST, using a simple encapsulation of XML requests within a new XML container that specifies the method documented by DAV, such that the following session example to PUT a resource on the web server, using a POST-encapsulation: >> Request from client to the script run at web server: POST /myaccount/scripts/postDAV.php Host: www.provider.com Content-Type: multipart/mixed; boundary="-----=NextPart:postDAV-----" Content-Length: 0 -----=NextPart:postDAV----- Content-Part: request Content-Type: text/xml; encoding=UTF-8 Content-Transfer-Encoding: 8bit Content-Length: xxx myownlogin XYZdf5ggrv 123456-8F3C-83FE0012 -----=NextPart:postDAV----- Content-Part: body Content-Type: text/html; encoding=iso8859-1 Content-Transfer-Encoding: 8bit Content-Length: xxx ... ... -----=NextPart:postDAV----- >> Answer from the script run at web server: HTTP/1.1 200 OK Date: Tue, 27 Mar 2001 08:11:50 GMT Server: Apache/1.3.12 (Unix) Debian/GNU mod_modperl/1.24 Content-Length: 0 ETag: "9DB189-FC02-38A40031" Content-Type: multipart/mixed ; boundary="-----=NextPart:postDAV-----" Content-Length: 0 -----=NextPart:postDAV----- Content-Part: answer Content-Type: text/xml; encoding=UTF-8 Content-Transfer-Encoding: 8bit Content-Length: xxx 123456-8F3C-83FE0012 -----=NextPart:postDAV----- Content-Part: body Content-Type: text/html; encoding=iso8859-1 Content-Transfer-Encoding: 8bit Content-Length: xxx WebDAV Answer - HTTP/1.1 200 OK

WebDAV Answer

Your request:

PUT /myresource-to-publish.html HTTP/1.1

Tag: 123456-8F3C-83FE0012

Has returned with the following status:

HTTP/1.1 200 OK

The resource has been accepted and is now online.

-----=NextPart:postDAV----- From w3c-dist-auth-request@w3.org Tue Mar 27 05:26: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 FAA16389 for ; Tue, 27 Mar 2001 05:26:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA23584; Tue, 27 Mar 2001 05:21:04 -0500 (EST) Resent-Date: Tue, 27 Mar 2001 05:21:04 -0500 (EST) Resent-Message-Id: <200103271021.FAA23584@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 FAA23473 for ; Tue, 27 Mar 2001 05:20:51 -0500 (EST) Received: from camelia.wanadoo.fr (smtp-rt-10.wanadoo.fr [193.252.19.59]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA18018 for ; Tue, 27 Mar 2001 05:20:51 -0500 Received: from citronier.wanadoo.fr (193.252.19.222) by camelia.wanadoo.fr; 27 Mar 2001 12:20:20 +0200 Received: from hppve (193.253.243.44) by citronier.wanadoo.fr; 27 Mar 2001 12:19:53 +0200 Message-ID: <005101c0b6a7$14523760$2101a8c0@hppve> From: "Philippe Verdy" To: References: <004d01c0b6a2$eacaf2a0$2101a8c0@hppve> Date: Tue, 27 Mar 2001 12:17:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: RE: Why not an encapsulation for DAV over standard HTTP 1.0 or 1.1 without required server extension ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4729 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sorry for the 2 typos in the sample in the sample session at end of my previous message: - The 1st line with POST in the request lacks a " HTTP/1.1" protocol version specifier at end - The element in the XML of the request should terminate with and not An important remark: The sample session would work through existing HTTP proxies which, despite Jim said, will persist in their current implementation for much more than 2 years and cause much problems to network administrators who cannot change their implementation easily (there are hardware proxies that are sold still now, that still only implement the basic HTTP 1.0 or 1.1 protocol, with no support for HTTP extensions)... The problem is more general than WebDAV: this will affect all attempts to support HTTP extensions using the RFC published by the W3C. But I think that an encapsulation like the one I propose, can provide a gateway for such extensions that are not supported for now by existing hardware and software solutions: the problem can be solved not within the network, but at both ends. My solution can be viewed as a tunnel to support any future HTTP extension, and I think it has many important applications: a client could first try to use the HTTP extension directly, but if that fails, it could retry using an HTTP encapsulation as well... So the XML model that I propose could be more generic so that the XML namespace it uses can accept all future HTTP extensions. From w3c-dist-auth-request@w3.org Tue Mar 27 06:20:14 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 GAA16746 for ; Tue, 27 Mar 2001 06:20:14 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA24930; Tue, 27 Mar 2001 06:11:22 -0500 (EST) Resent-Date: Tue, 27 Mar 2001 06:11:22 -0500 (EST) Resent-Message-Id: <200103271111.GAA24930@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 GAA24910 for ; Tue, 27 Mar 2001 06:11:18 -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 GAA21471 for ; Tue, 27 Mar 2001 06:11:12 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id DAA08349; Tue, 27 Mar 2001 03:11:33 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Tue, 27 Mar 2001 03:11:33 -0800 From: Greg Stein To: Philippe Verdy Cc: w3c-dist-auth@w3.org Message-ID: <20010327031133.Y27539@lyra.org> Mail-Followup-To: Philippe Verdy , w3c-dist-auth@w3.org References: <004d01c0b6a2$eacaf2a0$2101a8c0@hppve> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <004d01c0b6a2$eacaf2a0$2101a8c0@hppve>; from verdy_p@wanadoo.fr on Tue, Mar 27, 2001 at 11:47:20AM +0200 X-URL: http://www.lyra.org/greg/ Subject: Re: Why not an encapsulation for DAV over standard HTTP 1.0 or 1.1 without required server extension ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4730 X-Loop: w3c-dist-auth@w3.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 Tue, Mar 27, 2001 at 11:47:20AM +0200, Philippe Verdy wrote: >... > A simple test on many web servers (despite they are using a recent Apache > version with mod_perl extension, and even with mod_php allowed), will reveal > that most of web servers used by web hosting providers do not allow any DAV > protocol because of these limitation: Okay, so you're suggesting that, say, Apache users cannot use DAV because they don't have mod_dav installed. Fair enough, and entirely true. Then, you go on to state that your PHP-based solution will solve the problem. Not at all. I would still need to install that on my system. All you've done is changed "install mod_dav" to "install PHP and this script". That doesn't help anything. >... > I think personally that a light version of DAV without HTTP server extension > is possible now, without modifying the server to enable new HTTP extensions, > and without changing the core of DAV. You *still* have to modify the server to enable your tunneled protocol. > If the conceptors of DAV do not want > to implement it, users will do it themselves ! Fine. Please feel free. Implement it to your heart's content. I don't see Microsoft changing their clients (Web Folders, Office, etc). I don't see Joe Orton upgrading his clients. I doubt gnome-vfs will switch. I can't see Adobe changing all of their clients to use it. etc etc. DAV has widespread buy-in in its current form. Which users do you believe *want* this kind of change? And which users will be writing the code to make the change? > Your answer suggests me that I could form a group to implement an > encapsulation of DAV over POST, You sure can. Nobody can prevent you from doing such a thing. I just don't see that you'll get any buy-in to the approach. The only benefit to the tunneling approach is proxy/firewall navigation. In my experience, that has impacted relatively few people. I also believe Jim is incorrect with his "2 years" timeline. Proxies started updating their code about two years ago. Many proxies are now DAV-capable and are being deployed. Again, it is rare that I see a problem report due to a proxy problem. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Mar 27 06:55: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 GAA17015 for ; Tue, 27 Mar 2001 06:55:50 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA25510; Tue, 27 Mar 2001 06:49:30 -0500 (EST) Resent-Date: Tue, 27 Mar 2001 06:49:30 -0500 (EST) Resent-Message-Id: <200103271149.GAA25510@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 GAA25488 for ; Tue, 27 Mar 2001 06:49:26 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA23939 for ; Tue, 27 Mar 2001 06:49:25 -0500 Disposition-notification-to: Bruce Williams Received: from midnightwork ([64.166.108.126]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0GAU009O7U5W4O@mta5.snfc21.pbi.net> for w3c-dist-auth@w3.org; Tue, 27 Mar 2001 03:49:10 -0800 (PST) Date: Tue, 27 Mar 2001 03:49:06 -0800 From: Bruce Williams To: Jim Whitehead Cc: w3c-dist-auth@w3.org Reply-to: Bruce Williams Message-id: <003901c0b6b3$f0279120$a302fea9@midnightwork> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 References: X-Priority: 3 Subject: Re: Why not an encapsulation for DAV over standard HTTP 1.0 or 1.1 without required server extension ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4731 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit As someone who is not-so-involved (hee hee - an asset?) in WebDAV that I have a lot invested in the curent structure, may I comment? WebDAV is going to be used where and by the "people who use it". ( duh ) If a website or app has WebDAV as a part of it's function, then they write the code or install the mod_dav or whatever. I am making light of this in a kidding way, because the problem stated is just not that serious. The use of WebDAV in a practical manner by an organization has more serious implications than installing a mod ( like influencing vendor/app choices, training, etc ). Bruce Williams --------------------------------------------------- I love deadlines. I like the whooshing sound they make as they fly by. Douglas Adams ----- Original Message ----- From: "Jim Whitehead" To: "WebDAV WG" Sent: Monday, March 26, 2001 5:46 PM Subject: FW: Why not an encapsulation for DAV over standard HTTP 1.0 or 1.1 without required server extension ? > Accidentally caught by the spam filter. I've added to > the accept2 list, so future emails will go through to the list. > > - Jim > > -----Original Message----- > From: Philippe Verdy [mailto:verdy_p@wanadoo.fr] > Sent: Monday, March 26, 2001 1:26 PM > To: w3c-dist-auth@w3.org > Subject: [Moderator Action] Why not an encapsulation for DAV over > standard HTTP 1.0 or 1.1 without required server extension ? > > > There's a big problem with WebDAV : it requires HTTP server extensions such > as: > - new methods: MKCOL, PUT, FINDPROP, DELETE, COPY, MOVE, DELETE, LOCK, > UNLOCK > - too many new responses > > It causes many problems to users: > - It is unlikely that many web servers will be upgraded to support them. > - The protocol does not fit well on many HTTP proxies > - Many web hosting companies that use a shared server won't accept to add > such extensions (the same ones refuse to implement the so-called FrontPage > extension for security reasons) > - Users are restricted to publish their web site via FTP only > > But: > - PHP works on classic HTTP 1.0 and 1.1 servers without HTTP extension for > DAV > - PHP is considered very secure (enough to let web hosting companies accept > PHP scripts from their users), and accepted as a valid server extension (and > it is already ported to many environments and for many web server > implementations) > - PHP has a strong support from both users and web hosting companies and has > enough capabilities to support a protocol like DAV. This makes DAV > implementation possible through a single DAV-compliant script written in > PHP. > - The PHP DAV script can be updated by users themselves and can easily > follow the new standards for DAV, without requiring any change on the web > server (the web server will just need to support at least a basic version of > PHP3). Users can simply upload the new PHP DAV script using a single FTP > transfer to their own account (the PHP script would also contain the name of > a user-provided parameter file, which could be also uploaded with FTP, and > the name of the DAV script resource if it has to be write-protected from DAV > itself). > - Other scripting extensions may also be used alternatively to PHP in the > future, if such scripting languages are accepted. > > So why not extending the draft specification of DAV, to allow an > encapsulation of the current DAV specification in a single XML request that > would contain the DAV method requested and the required credentials ? > > People would then post to http://webserver/~user/dav/post.php, using POST > methods, in multipart/mixed format when posting resource contents, and the > answers to the DAV request would not depend on HTTP server responses (the > DAV response sould be in the XML response resulting from the HTTP POST > request). this would be done instead of specifying the default > http://webserver/ address for the main DAV implementation. > > Additionally, the multipart/mixed format could be used to accelerate the > transfer of multiple resources, by using a single chunked multipart/mixed > request. > > I also suggest that the protocol includes the HELP method, to get the list > of accepted DAV methods (like it currently exists in FTP), so that a client > can query the capabilities of the DAV server (does it support lock/unlock > methods ? and so on...) and so that the client can adapt to future versions > of the DAV protocol. Note that the same server could then host several > versions of the DAV protocol, because each user could choose and upload the > implementation he needs to work with its own DAV-aware client. > > I personnally think it's a very bad idea to link the DAV protocol to the > HTTP protocol itself. And there's a way make both coexist separately... > > > From w3c-dist-auth-request@w3.org Tue Mar 27 10:54: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 KAA20708 for ; Tue, 27 Mar 2001 10:54:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA05033; Tue, 27 Mar 2001 10:44:43 -0500 (EST) Resent-Date: Tue, 27 Mar 2001 10:44:43 -0500 (EST) Resent-Message-Id: <200103271544.KAA05033@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 KAA05008 for ; Tue, 27 Mar 2001 10:44:38 -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 KAA17627 for ; Tue, 27 Mar 2001 10:44:36 -0500 Received: (qmail 21842 invoked by uid 0); 27 Mar 2001 15:44:05 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mail08) with SMTP; 27 Mar 2001 15:44:05 -0000 From: "Julian F. Reschke" To: Date: Tue, 27 Mar 2001 17:44:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Importance: Normal In-reply-to: Subject: redirect references resource bodies (draft 02) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4732 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, the redirect references draft says that a redirect reference resource may have a body: . However, MKRESOURCE will create empty resources: , and PUT with Apply-To-Redirect-Ref header set will replace the redirect ref resource by a regular resource: . So, how can I create a redirect ref *with* a body? Julian From w3c-dist-auth-request@w3.org Tue Mar 27 13:42: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 NAA25670 for ; Tue, 27 Mar 2001 13:42:20 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA14423; Tue, 27 Mar 2001 13:26:23 -0500 (EST) Resent-Date: Tue, 27 Mar 2001 13:26:23 -0500 (EST) Resent-Message-Id: <200103271826.NAA14423@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 NAA14403 for ; Tue, 27 Mar 2001 13:26:17 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-38032.rational.com [192.229.38.32]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA03693 for ; Tue, 27 Mar 2001 13:26:17 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Tue, 27 Mar 2001 13:26:55 -0500 (Eastern Standard Time) Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Mar 2001 13:26:55 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E2304@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Tue, 27 Mar 2001 13:26:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: redirect references resource bodies (draft 02) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4733 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree this is a bug in the protocol. I would suggest getting rid of section 6.2, or at least changing it to say that it will "add a body to the redirect reference. Cheers, Geoff -----Original Message----- From: Julian F. Reschke [mailto:julian.reschke@gmx.de] Sent: Tuesday, March 27, 2001 10:44 AM To: w3c-dist-auth@w3c.org Subject: redirect references resource bodies (draft 02) Hi, the redirect references draft says that a redirect reference resource may have a body: . However, MKRESOURCE will create empty resources: , and PUT with Apply-To-Redirect-Ref header set will replace the redirect ref resource by a regular resource: . So, how can I create a redirect ref *with* a body? Julian From w3c-dist-auth-request@w3.org Wed Mar 28 02:23: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 CAA08536 for ; Wed, 28 Mar 2001 02:23:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA23111; Wed, 28 Mar 2001 02:09:50 -0500 (EST) Resent-Date: Wed, 28 Mar 2001 02:09:50 -0500 (EST) Resent-Message-Id: <200103280709.CAA23111@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 CAA23086 for ; Wed, 28 Mar 2001 02:09:44 -0500 (EST) Received: from smtp-relay-2.Adobe.COM (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA08270 for ; Wed, 28 Mar 2001 02:09:44 -0500 Received: from inner-relay-2.Adobe.COM (inner-relay-2.corp.adobe.com [153.32.1.52]) by smtp-relay-2.Adobe.COM (8.8.6) with ESMTP id XAA13604 for ; Tue, 27 Mar 2001 23:13:49 -0800 (PST) Received: from mailsj-v1.corp.adobe.com by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id XAA20313; Tue, 27 Mar 2001 23:09:03 -0800 (PST) Received: from larrypad ([130.248.185.16]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with SMTP id GAWBVB00.PDR for ; Tue, 27 Mar 2001 23:09:11 -0800 From: "Larry Masinter" To: Date: Tue, 27 Mar 2001 23:09:04 -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: <003901c0b6b3$f0279120$a302fea9@midnightwork> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Why not an encapsulation for DAV over standard HTTP 1.0 or 1.1 without required server extension ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4734 X-Loop: w3c-dist-auth@w3.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 decision to use separate methods instead of just POST (which I think was the original question) was arrived at after a lengthy discussion; the first record I can find is from October 1996: http://lists.w3.org/Archives/Public/w3c-dist-auth/1996OctDec/subject.html#25 Note that SOAP takes a different view; it only uses POST. I don't think the considerations have changed substantially, except perhaps that we're talking about using other headers and/or message body elements rather than content-type to do method dispatching. Larry -- http://larry.masinter.net From w3c-dist-auth-request@w3.org Wed Mar 28 05:00: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 FAA18622 for ; Wed, 28 Mar 2001 05:00:28 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA28479; Wed, 28 Mar 2001 04:54:27 -0500 (EST) Resent-Date: Wed, 28 Mar 2001 04:54:27 -0500 (EST) Resent-Message-Id: <200103280954.EAA28479@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 EAA28447 for ; Wed, 28 Mar 2001 04:54:22 -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 EAA21873 for ; Wed, 28 Mar 2001 04:54:21 -0500 Received: (qmail 17949 invoked by uid 0); 28 Mar 2001 09:53:43 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp006-rz3) with SMTP; 28 Mar 2001 09:53:43 -0000 From: "Julian F. Reschke" To: "Clemm, Geoff" , Date: Wed, 28 Mar 2001 11:53:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1018E2304@SUS-MA1IT01> Subject: RE: redirect references resource bodies (draft 02) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4735 X-Loop: w3c-dist-auth@w3.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, Geoff has also pointed me to http://www.ics.uci.edu/pub/ietf/webdav/collection/redirect-issues.html which of course had this issue already listed. However, the content of this document seems to indicate that the redirect draft will change drastically (when the next comes out), for instance it seems that MKRESOURCE will go away completely and will be replaced by MKREF. Yes, I am aware of the fact that Internet Drafts are work-in-progress. However, I am currently adding experimental redirect ref support to a WebDAV server and would like to get some opinions about what's the best way to proceed: a) use draft 02, taking clarifications from the issues list where feasible, b) implement a vendor-specific method (which then would be replaced by whatever the next draft defines)? Or is there a preliminary version of the next draft which could be used as a better implementation guideline? Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Tuesday, March 27, 2001 8:27 PM > To: w3c-dist-auth@w3c.org > Subject: RE: redirect references resource bodies (draft 02) > > > I agree this is a bug in the protocol. I would > suggest getting rid of section 6.2, or at least > changing it to say that it will "add a body to the > redirect reference. > > Cheers, > Geoff > > -----Original Message----- > From: Julian F. Reschke [mailto:julian.reschke@gmx.de] > Sent: Tuesday, March 27, 2001 10:44 AM > To: w3c-dist-auth@w3c.org > Subject: redirect references resource bodies (draft 02) > > > Hi, > > the redirect references draft says that a redirect reference resource may > have a body: > > f-protocol > -02.html#rfc.section.4.p.5>. > > However, MKRESOURCE will create empty resources: > > f-protocol > -02.html#rfc.section.5.1.p.9>, > > and PUT with Apply-To-Redirect-Ref header set will replace the > redirect ref > resource by a regular resource: > > . So, how can I create a redirect ref *with* a body? Julian From w3c-dist-auth-request@w3.org Wed Mar 28 22:35:14 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 WAA23538 for ; Wed, 28 Mar 2001 22:35:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA19569; Wed, 28 Mar 2001 22:28:52 -0500 (EST) Resent-Date: Wed, 28 Mar 2001 22:28:52 -0500 (EST) Resent-Message-Id: <200103290328.WAA19569@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 WAA19549 for ; Wed, 28 Mar 2001 22:28:48 -0500 (EST) Received: from pimout2-int.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA30136 for ; Wed, 28 Mar 2001 22:28:48 -0500 Received: from Tycho (A010-1020.HRBG.splitrock.net [63.254.26.4]) by pimout2-int.prodigy.net (8.11.0/8.11.0) with SMTP id f2T3Sjr114778; Wed, 28 Mar 2001 22:28:45 -0500 From: "Jim Whitehead" To: "Julian F. Reschke" , Date: Wed, 28 Mar 2001 19:27:29 -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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: redirect references resource bodies (draft 02) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4736 X-Loop: w3c-dist-auth@w3.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 > However, the content of this document seems to indicate that the redirect > draft will change drastically (when the next comes out), for instance it > seems that MKRESOURCE will go away completely and will be > replaced by MKREF. > > Yes, I am aware of the fact that Internet Drafts are work-in-progress. > However, I am currently adding experimental redirect ref support > to a WebDAV server and would like to get some opinions about what's the best way to > proceed: > > a) use draft 02, taking clarifications from the issues list where > feasible, This is my recommendation. > b) implement a vendor-specific method (which then would be replaced by > whatever the next draft defines)? Please don't! > Or is there a preliminary version of the next draft which could > be used as a better implementation guideline? There is not, at present, another draft underway. - Jim From w3c-dist-auth-request@w3.org Fri Mar 30 00:46: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 AAA19027 for ; Fri, 30 Mar 2001 00:46:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA25262; Fri, 30 Mar 2001 00:04:19 -0500 (EST) Resent-Date: Fri, 30 Mar 2001 00:04:19 -0500 (EST) Resent-Message-Id: <200103300504.AAA25262@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 AAA25242 for ; Fri, 30 Mar 2001 00:04:14 -0500 (EST) Received: from pimout2-int.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA09162; Fri, 30 Mar 2001 00:04:14 -0500 Received: from Tycho (A010-0262.STCO.splitrock.net [209.156.35.8]) by pimout2-int.prodigy.net (8.11.0/8.11.0) with SMTP id f2U54Br73662; Fri, 30 Mar 2001 00:04:11 -0500 From: "Jim Whitehead" To: "WebDAV WG" , Date: Thu, 29 Mar 2001 21:02:55 -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: FW: WebDAV URI Scheme - http://www.ietf.org/rfc/rfc2518.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4737 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter -- I've added timbl@w3.org to the accept2 list, so future emails from Tim will go straight through to the list. - Jim -----Original Message----- From: Tim Berners-Lee [mailto:timbl@w3.org] Sent: Thursday, March 29, 2001 11:35 AM To: w3c-dist-auth@w3.org; w3c-policy@apps.ietf.org Cc: w3t-arch group Subject: [Moderator Action] WebDAV URI Scheme - http://www.ietf.org/rfc/rfc2518.txt I have never formally made a comment about RFC2518's http://www.ietf.org/rfc/rfc2518.txt DAV: URI space but I do now. I only recently noticed that it invents two completely new URIabuse one of the weakest points of the web, the flat highest level space of URI schemes. The URI scheme name if the root of the URI system, and DNS's TLDs being some way below it. Imagine the fuss there would have been if WebDAV had introduced a TLD! This is a little like introducing an amendment to the constitution to allow change the admission to town museums. It is being done at entirely the wrong level. I am quite appalled at this abuse of URIspace, and schemes. It is quite inappropriate for a specification to am inclined to suggest that the specification be updated to use a URI which the working group has in its power to allocate (such as http://www.w3.org/2001/dav or http://www.ietf.org/2001/dav) This would entail all code being rewritten over time to accept first both and then only this space. The tedious process of cleaning up this debris in the web's front hall should begin now. Looking at ftp://ftp.isi.edu/in-notes/iana/assignments/url-schemes we find that there is *another* space reserved: opaquelocktoken At least this is a real space of identifiers. It would be preferable as a question of overall architecture to make this a separate specification, as it is quite general uuid: with knobs on. In fact, as there is no spec linking ISO-11578 UUIDs to the uuid: scheme registered with IANA. There should, in my opinion, be such a specification. There is a fundamental mistake that the URI scheme which is very general is being specified as only applying to a particular class of object. opaquelocktoken: would be quire reusable as a piece of technology if it didn't have such an unnecessary restriction. _______________________________________ I would like to suggest in the future that any new URI scheme be resisted by W3C TAG and IESG unless there really is a new space with new well defined properties being defined. It should then be put through a review by IETF and W3C at least, at the start of the design process. Tim From w3c-dist-auth-request@w3.org Fri Mar 30 00:58:44 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 AAA20565 for ; Fri, 30 Mar 2001 00:58:44 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA27817; Fri, 30 Mar 2001 00:52:37 -0500 (EST) Resent-Date: Fri, 30 Mar 2001 00:52:37 -0500 (EST) Resent-Message-Id: <200103300552.AAA27817@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 AAA27793 for ; Fri, 30 Mar 2001 00:52:31 -0500 (EST) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA12941; Fri, 30 Mar 2001 00:52:30 -0500 Received: from gmgw02.oraclecorp.com (gmgw02.us.oracle.com [130.35.60.248]) by inet-mail3.oracle.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f2U5nef06703; Thu, 29 Mar 2001 21:49:40 -0800 (PST) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by gmgw02.oraclecorp.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f2U5puo15630; Thu, 29 Mar 2001 21:51:56 -0800 (PST) From: "Eric Sedlar" To: "WebDAV WG" , Date: Thu, 29 Mar 2001 21:46:29 -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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Subject: RE: WebDAV URI Scheme - http://www.ietf.org/rfc/rfc2518.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4738 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I don't think anyone would dispute that the "DAV:" hack should be fixed in the next version of RFC2518. Now that XML namespaces are stabilized, there is no excuse for non-compliance in the way the DAV namespace is defined. I assume that Jim has this on his list of to-dos. Jim? > > -----Original Message----- > From: Tim Berners-Lee [mailto:timbl@w3.org] > Sent: Thursday, March 29, 2001 11:35 AM > To: w3c-dist-auth@w3.org; w3c-policy@apps.ietf.org > Cc: w3t-arch group > Subject: [Moderator Action] WebDAV URI Scheme - > http://www.ietf.org/rfc/rfc2518.txt > > > I have never formally made a comment about RFC2518's > http://www.ietf.org/rfc/rfc2518.txt > DAV: URI space but I do now. > > I only recently noticed that it invents two completely new URIabuse one of > the weakest points of the web, the flat > highest level space of URI schemes. The URI scheme name > if the root of the URI system, and DNS's TLDs being some > way below it. Imagine the fuss there would have been > if WebDAV had introduced a TLD! This is a little like > introducing an amendment to the constitution to allow > change the admission to town museums. It is being done > at entirely the wrong level. > > I am quite appalled at this abuse of URIspace, and > schemes. It is quite inappropriate for a specification to > > am inclined to suggest that the specification be updated to > use a URI which the working group has in its power to allocate > (such as http://www.w3.org/2001/dav or http://www.ietf.org/2001/dav) > This would entail all code being rewritten over time to accept first > both and then only this space. The tedious process of cleaning up > this debris in the web's front hall should begin now. > > Looking at ftp://ftp.isi.edu/in-notes/iana/assignments/url-schemes > we find that there is *another* space reserved: > > opaquelocktoken > > At least this is a real space of identifiers. It would be preferable > as a question of overall architecture to make this a separate > specification, as it is quite general uuid: with knobs on. > In fact, as there is no spec linking ISO-11578 UUIDs to the uuid: > scheme registered with IANA. There should, in my opinion, > be such a specification. > > There is a fundamental mistake that the URI scheme which is very general > is being specified as only applying to a particular class of object. > opaquelocktoken: would be quire reusable as a piece of technology > if it didn't have such an unnecessary restriction. > > _______________________________________ > > I would like to suggest in the future that any new URI scheme > be resisted by W3C TAG and IESG unless there really > is a new space with new well defined properties being defined. > It should then be put through a review by IETF and W3C at least, > at the start of the design process. > > Tim > > > > > From w3c-dist-auth-request@w3.org Fri Mar 30 07:38: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 HAA11383 for ; Fri, 30 Mar 2001 07:38:30 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA17433; Fri, 30 Mar 2001 07:28:10 -0500 (EST) Resent-Date: Fri, 30 Mar 2001 07:28:10 -0500 (EST) Resent-Message-Id: <200103301228.HAA17433@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 HAA17413 for ; Fri, 30 Mar 2001 07:28:05 -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 HAA13426 for ; Fri, 30 Mar 2001 07:28:04 -0500 Received: (qmail 4374 invoked by uid 0); 30 Mar 2001 12:27:32 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp021-rz3) with SMTP; 30 Mar 2001 12:27:32 -0000 From: "Julian F. Reschke" To: "WebDAV WG" Date: Fri, 30 Mar 2001 14:27:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Importance: Normal Subject: RE: WebDAV URI Scheme - http://www.ietf.org/rfc/rfc2518.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4739 X-Loop: w3c-dist-auth@w3.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, it's easy to agree that the namespaceUri was badly chosen -- however I really don't see all servers and clients being converted to support two namespace names. Couldn't this be "fixed" easier by registering "DAV:" as an URI scheme (looking at , it's listed already...). Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Friday, March 30, 2001 7:03 AM > To: WebDAV WG; timbl@w3.org > Subject: FW: WebDAV URI Scheme - http://www.ietf.org/rfc/rfc2518.txt > > > Accidentally caught by the spam filter -- I've added timbl@w3.org to the > accept2 list, so future emails from Tim will go straight through to the > list. > > - Jim > > -----Original Message----- > From: Tim Berners-Lee [mailto:timbl@w3.org] > Sent: Thursday, March 29, 2001 11:35 AM > To: w3c-dist-auth@w3.org; w3c-policy@apps.ietf.org > Cc: w3t-arch group > Subject: [Moderator Action] WebDAV URI Scheme - > http://www.ietf.org/rfc/rfc2518.txt > > > I have never formally made a comment about RFC2518's > http://www.ietf.org/rfc/rfc2518.txt > DAV: URI space but I do now. > > I only recently noticed that it invents two completely new URIabuse one of > the weakest points of the web, the flat > highest level space of URI schemes. The URI scheme name > if the root of the URI system, and DNS's TLDs being some > way below it. Imagine the fuss there would have been > if WebDAV had introduced a TLD! This is a little like > introducing an amendment to the constitution to allow > change the admission to town museums. It is being done > at entirely the wrong level. > > I am quite appalled at this abuse of URIspace, and > schemes. It is quite inappropriate for a specification to > > am inclined to suggest that the specification be updated to > use a URI which the working group has in its power to allocate > (such as http://www.w3.org/2001/dav or http://www.ietf.org/2001/dav) > This would entail all code being rewritten over time to accept first > both and then only this space. The tedious process of cleaning up > this debris in the web's front hall should begin now. > > Looking at ftp://ftp.isi.edu/in-notes/iana/assignments/url-schemes > we find that there is *another* space reserved: > > opaquelocktoken > > At least this is a real space of identifiers. It would be preferable > as a question of overall architecture to make this a separate > specification, as it is quite general uuid: with knobs on. > In fact, as there is no spec linking ISO-11578 UUIDs to the uuid: > scheme registered with IANA. There should, in my opinion, > be such a specification. > > There is a fundamental mistake that the URI scheme which is very general > is being specified as only applying to a particular class of object. > opaquelocktoken: would be quire reusable as a piece of technology > if it didn't have such an unnecessary restriction. > > _______________________________________ > > I would like to suggest in the future that any new URI scheme > be resisted by W3C TAG and IESG unless there really > is a new space with new well defined properties being defined. > It should then be put through a review by IETF and W3C at least, > at the start of the design process. > > Tim > > > >