From w3c-dist-auth-request@w3.org Mon Jun 4 18:37:15 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 SAA20725 for ; Mon, 4 Jun 2001 18:37:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA28009; Mon, 4 Jun 2001 18:33:00 -0400 (EDT) Resent-Date: Mon, 4 Jun 2001 18:33:00 -0400 (EDT) Resent-Message-Id: <200106042233.SAA28009@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 SAA27989 for ; Mon, 4 Jun 2001 18:32:54 -0400 (EDT) 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 SAA13865 for ; Mon, 4 Jun 2001 18:32:48 -0400 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 PAA07394 for ; Mon, 4 Jun 2001 15:32:53 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Mon, 4 Jun 2001 15:30:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: FW: [Moderator Action] about implement webDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4975 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I have added to the accept2 list for the WebDAV working group. - Jim -----Original Message----- From: Tao Wan [mailto:want@us.ibm.com] Sent: Monday, June 04, 2001 10:08 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] about implement webDAV Hello everyone, I am a graduate student of NMSU. I am working on my research " implement webDAV support on top of our centent management system." I check out the article " webDAV project" writen by Jonathan Shapiro, Shao Rong and Marc Eaddy online. It is very useful for me. But there is no any images in that article online. please check this site: http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/WebDAV/webdav.htm l if you happen to keep that paper. could you please send me these two Figures so that I can read it completely. Thank you very much. Best Regards, tao From w3c-dist-auth-request@w3.org Mon Jun 4 19:17: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 TAA21269 for ; Mon, 4 Jun 2001 19:17:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA00557; Mon, 4 Jun 2001 19:15:50 -0400 (EDT) Resent-Date: Mon, 4 Jun 2001 19:15:50 -0400 (EDT) Resent-Message-Id: <200106042315.TAA00557@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 TAA00536 for ; Mon, 4 Jun 2001 19:15:44 -0400 (EDT) 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 TAA16908 for ; Mon, 4 Jun 2001 19:15:44 -0400 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 QAA16389; Mon, 4 Jun 2001 16:15:43 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" , Date: Mon, 4 Jun 2001 16:13:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: [Moderator Action] about implement webDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4976 X-Loop: w3c-dist-auth@w3.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 check out the article " webDAV project" writen by Jonathan Shapiro, Shao > Rong and Marc Eaddy online. It is very useful for me. > But there is no any images in that article online. please check this site: > http://www.cs.columbia.edu/~hgs/teaching/ais/1998/projects/WebDAV/ > webdav.html Well, I don't have the figures for this paper. However, this project implemented a very early draft of the WebDAV protocol, and so I'd be hesitant to draw too many conclusions from it. In particular, there are now several WebDAV servers that implement RFC 2518 that contain full source code (mod_dav & DAV4J being two), and they are probably a better starting point than this older work. - Jim From w3c-dist-auth-request@w3.org Tue Jun 5 13:50: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 NAA27130 for ; Tue, 5 Jun 2001 13:50:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA02697; Tue, 5 Jun 2001 12:30:12 -0400 (EDT) Resent-Date: Tue, 5 Jun 2001 12:30:12 -0400 (EDT) Resent-Message-Id: <200106051630.MAA02697@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 MAA02677 for ; Tue, 5 Jun 2001 12:30:06 -0400 (EDT) Received: from megapathdsl.net (snowbird.megapath.net [216.200.176.7]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA13980 for ; Tue, 5 Jun 2001 12:30:04 -0400 Received: from [216.36.75.57] (HELO beaver) by megapathdsl.net (CommuniGate Pro SMTP 3.4.3) with SMTP id 25471944 for w3c-dist-auth@w3.org; Tue, 05 Jun 2001 09:28:21 -0700 From: "Lisa Dusseault" To: Date: Tue, 5 Jun 2001 09:28:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: Logic for extending text XML elements Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4977 X-Loop: w3c-dist-auth@w3.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 run into a minor issue relating to XML syntax and WebDAV extensibility. I'm parsing: http://myserver.com/ Since an XML element can legally contain both text and elements (e.g.

Hello sailor!

), it's conceivable that in the future the element could be extended to have: http://myserver.com/ 123486 more-stuff RFC 2518 says: "All DAV compliant resources MUST ignore any unknown XML element and all its children encountered while processing a DAV method that uses XML as its command language." That would indicate that I should ignore the element. I can do that. But what does "ignore" mean? - Do I treat it as a separator so that "http://myserver.com/" is one text child of DAV:href and "more-stuff" is another text child? How do I know which one to treat as the URL, particularly if they both look like urls? - Do I conceptually remove the ignored element? That would leave with a single text child containing white space, approximately: "http://myserver.com/ more-stuff". Since all this is rather ugly, I'd most like to have a sentence added to RFC 2518 (section 14?) that states at a minimum that "text elements should NOT have their syntax extended by adding XML elements because this is unlikely to be backward-compatible." I think we already instinctively follow this guideline, but it's hard to write solid code based on guesses and predictions that aren't written down. Any other proposals or insights? lisa From w3c-dist-auth-request@w3.org Tue Jun 5 14:02:54 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 OAA27481 for ; Tue, 5 Jun 2001 14:02:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA14826; Tue, 5 Jun 2001 13:56:57 -0400 (EDT) Resent-Date: Tue, 5 Jun 2001 13:56:57 -0400 (EDT) Resent-Message-Id: <200106051756.NAA14826@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 NAA14794 for ; Tue, 5 Jun 2001 13:56:49 -0400 (EDT) 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 NAA27596 for ; Tue, 5 Jun 2001 13:56:48 -0400 Received: from gmgw02.us.oracle.com (gmgw02.us.oracle.com [130.35.249.110]) by inet-mail3.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f55Hqmv21057; Tue, 5 Jun 2001 10:52:49 -0700 (PDT) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by gmgw02.us.oracle.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f55HuAj05546; Tue, 5 Jun 2001 10:56:10 -0700 (PDT) From: "Eric Sedlar" To: "Lisa Dusseault" , Date: Tue, 5 Jun 2001 10:48:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: RE: Logic for extending text XML elements Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4980 X-Loop: w3c-dist-auth@w3.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 exactly sure what you mean by container, but you can't extend simpleType XML elements to become complexType ones (which can contain subelements) in XML schema via the Schema inheritance mechanism, so rather than updating the DTD/Schema, the correct answer to me is to use inheritance of XML datatypes to get the restriction you want and NOT change existing datatypes. > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Tuesday, June 05, 2001 10:50 AM > To: Eric Sedlar; w3c-dist-auth@w3.org > Subject: RE: Logic for extending text XML elements > > > I see what you mean, however as we extend WebDAV we frequently update the > XML Schema/DTD. E.g. we are considering taking propfind and adding an > element to a container that coudln't previously hold > that element. > What's the difference between that and updating the schema for an element > that contains strings? > > Adding new elements to containers that already hold XML elements > seems like > A Good Way to extend DAV. > Adding new elements to containers that previously only held text > seems like > A Bad Way to extend DAV. If there's consensus on this, perhaps we could > state as much. > > lisa > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar > > Sent: Tuesday, June 05, 2001 10:00 AM > > To: w3c-dist-auth@w3.org > > Subject: RE: Logic for extending text XML elements > > > > > > The XML schema for should be defined as a simple type (like > > "anyURI", which subclasses "string"), which disallows element children. > > I assume the DTD says the same thing (I'm not as familiar with DTD). > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > > Sent: Tuesday, June 05, 2001 9:29 AM > > > To: w3c-dist-auth@w3.org > > > Subject: Logic for extending text XML elements > > > > > > > > > I've run into a minor issue relating to XML syntax and WebDAV > > > extensibility. > > > > > > I'm parsing: > > > http://myserver.com/ > > > > > > Since an XML element can legally contain both text and elements (e.g. > > >

Hello sailor!

), it's conceivable that in the > future the > > > element could be extended to have: > > > > > > http://myserver.com/ > > > 123486 > > > more-stuff > > > > > > > > > RFC 2518 says: > > > "All DAV compliant resources MUST ignore any unknown XML > element and > > > all its children encountered while processing a DAV method > that uses > > > XML as its command language." > > > > > > That would indicate that I should ignore the element. > > I can do > > > that. But what does "ignore" mean? > > > - Do I treat it as a separator so that "http://myserver.com/" > > is one text > > > child of DAV:href and "more-stuff" is another text child? > How do I know > > > which one to treat as the URL, particularly if they both look > like urls? > > > - Do I conceptually remove the ignored element? That would leave > > > with a single text child containing white space, > > approximately: > > > "http://myserver.com/ more-stuff". > > > > > > Since all this is rather ugly, I'd most like to have a sentence > > > added to RFC > > > 2518 (section 14?) that states at a minimum that "text elements > > should NOT > > > have their syntax extended by adding XML elements because this > > is unlikely > > > to be backward-compatible." I think we already instinctively > > follow this > > > guideline, but it's hard to write solid code based on guesses and > > > predictions that aren't written down. > > > > > > Any other proposals or insights? > > > > > > lisa > > > > > > > > From w3c-dist-auth-request@w3.org Tue Jun 5 14:04: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 OAA27520 for ; Tue, 5 Jun 2001 14:04:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA13994; Tue, 5 Jun 2001 13:51:20 -0400 (EDT) Resent-Date: Tue, 5 Jun 2001 13:51:20 -0400 (EDT) Resent-Message-Id: <200106051751.NAA13994@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 NAA13974 for ; Tue, 5 Jun 2001 13:51:13 -0400 (EDT) Received: from megapathdsl.net (snowbird.megapath.net [216.200.176.7]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA26595 for ; Tue, 5 Jun 2001 13:51:12 -0400 Received: from [216.36.75.57] (HELO beaver) by megapathdsl.net (CommuniGate Pro SMTP 3.4.3) with SMTP id 25486754; Tue, 05 Jun 2001 10:49:19 -0700 From: "Lisa Dusseault" To: "Eric Sedlar" , Date: Tue, 5 Jun 2001 10:49:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: RE: Logic for extending text XML elements Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4979 X-Loop: w3c-dist-auth@w3.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 see what you mean, however as we extend WebDAV we frequently update the XML Schema/DTD. E.g. we are considering taking propfind and adding an element to a container that coudln't previously hold that element. What's the difference between that and updating the schema for an element that contains strings? Adding new elements to containers that already hold XML elements seems like A Good Way to extend DAV. Adding new elements to containers that previously only held text seems like A Bad Way to extend DAV. If there's consensus on this, perhaps we could state as much. lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar > Sent: Tuesday, June 05, 2001 10:00 AM > To: w3c-dist-auth@w3.org > Subject: RE: Logic for extending text XML elements > > > The XML schema for should be defined as a simple type (like > "anyURI", which subclasses "string"), which disallows element children. > I assume the DTD says the same thing (I'm not as familiar with DTD). > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Tuesday, June 05, 2001 9:29 AM > > To: w3c-dist-auth@w3.org > > Subject: Logic for extending text XML elements > > > > > > I've run into a minor issue relating to XML syntax and WebDAV > > extensibility. > > > > I'm parsing: > > http://myserver.com/ > > > > Since an XML element can legally contain both text and elements (e.g. > >

Hello sailor!

), it's conceivable that in the future the > > element could be extended to have: > > > > http://myserver.com/ > > 123486 > > more-stuff > > > > > > RFC 2518 says: > > "All DAV compliant resources MUST ignore any unknown XML element and > > all its children encountered while processing a DAV method that uses > > XML as its command language." > > > > That would indicate that I should ignore the element. > I can do > > that. But what does "ignore" mean? > > - Do I treat it as a separator so that "http://myserver.com/" > is one text > > child of DAV:href and "more-stuff" is another text child? How do I know > > which one to treat as the URL, particularly if they both look like urls? > > - Do I conceptually remove the ignored element? That would leave > > with a single text child containing white space, > approximately: > > "http://myserver.com/ more-stuff". > > > > Since all this is rather ugly, I'd most like to have a sentence > > added to RFC > > 2518 (section 14?) that states at a minimum that "text elements > should NOT > > have their syntax extended by adding XML elements because this > is unlikely > > to be backward-compatible." I think we already instinctively > follow this > > guideline, but it's hard to write solid code based on guesses and > > predictions that aren't written down. > > > > Any other proposals or insights? > > > > lisa > > > > From w3c-dist-auth-request@w3.org Tue Jun 5 14:23: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 OAA27798 for ; Tue, 5 Jun 2001 14:23:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA08386; Tue, 5 Jun 2001 13:07:42 -0400 (EDT) Resent-Date: Tue, 5 Jun 2001 13:07:42 -0400 (EDT) Resent-Message-Id: <200106051707.NAA08386@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 NAA08362 for ; Tue, 5 Jun 2001 13:07:35 -0400 (EDT) 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 NAA19195 for ; Tue, 5 Jun 2001 13:07:35 -0400 Received: from gmgw02.us.oracle.com (gmgw02.us.oracle.com [130.35.249.110]) by inet-mail3.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f55H3av21520 for ; Tue, 5 Jun 2001 10:03:36 -0700 (PDT) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by gmgw02.us.oracle.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f55H6wj15740 for ; Tue, 5 Jun 2001 10:06:58 -0700 (PDT) From: "Eric Sedlar" To: Date: Tue, 5 Jun 2001 09:59:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: RE: Logic for extending text XML elements Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4978 X-Loop: w3c-dist-auth@w3.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 XML schema for should be defined as a simple type (like "anyURI", which subclasses "string"), which disallows element children. I assume the DTD says the same thing (I'm not as familiar with DTD). > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, June 05, 2001 9:29 AM > To: w3c-dist-auth@w3.org > Subject: Logic for extending text XML elements > > > I've run into a minor issue relating to XML syntax and WebDAV > extensibility. > > I'm parsing: > http://myserver.com/ > > Since an XML element can legally contain both text and elements (e.g. >

Hello sailor!

), it's conceivable that in the future the > element could be extended to have: > > http://myserver.com/ > 123486 > more-stuff > > > RFC 2518 says: > "All DAV compliant resources MUST ignore any unknown XML element and > all its children encountered while processing a DAV method that uses > XML as its command language." > > That would indicate that I should ignore the element. I can do > that. But what does "ignore" mean? > - Do I treat it as a separator so that "http://myserver.com/" is one text > child of DAV:href and "more-stuff" is another text child? How do I know > which one to treat as the URL, particularly if they both look like urls? > - Do I conceptually remove the ignored element? That would leave > with a single text child containing white space, approximately: > "http://myserver.com/ more-stuff". > > Since all this is rather ugly, I'd most like to have a sentence > added to RFC > 2518 (section 14?) that states at a minimum that "text elements should NOT > have their syntax extended by adding XML elements because this is unlikely > to be backward-compatible." I think we already instinctively follow this > guideline, but it's hard to write solid code based on guesses and > predictions that aren't written down. > > Any other proposals or insights? > > lisa > > From w3c-dist-auth-request@w3.org Tue Jun 5 15:21: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 PAA28766 for ; Tue, 5 Jun 2001 15:20:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA16961; Tue, 5 Jun 2001 14:13:13 -0400 (EDT) Resent-Date: Tue, 5 Jun 2001 14:13:13 -0400 (EDT) Resent-Message-Id: <200106051813.OAA16961@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 OAA16865 for ; Tue, 5 Jun 2001 14:13:05 -0400 (EDT) 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 OAA29382 for ; Tue, 5 Jun 2001 14:13:05 -0400 Received: (qmail 27815 invoked by uid 0); 5 Jun 2001 18:12:28 -0000 Received: from p3ee24649.dip.t-dialin.net (HELO lisa) (62.226.70.73) by mail.gmx.net (mp020-rz3) with SMTP; 5 Jun 2001 18:12:28 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , Date: Tue, 5 Jun 2001 20:12:27 +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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: RE: Logic for extending text XML elements Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4981 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, June 05, 2001 6:29 PM > To: w3c-dist-auth@w3.org > Subject: Logic for extending text XML elements > > > I've run into a minor issue relating to XML syntax and WebDAV > extensibility. > > I'm parsing: > http://myserver.com/ > > Since an XML element can legally contain both text and elements (e.g. >

Hello sailor!

), it's conceivable that in the future the > element could be extended to have: > > http://myserver.com/ > 123486 > more-stuff > > > RFC 2518 says: > "All DAV compliant resources MUST ignore any unknown XML element and > all its children encountered while processing a DAV method that uses > XML as its command language." > > That would indicate that I should ignore the element. I can do > that. But what does "ignore" mean? > - Do I treat it as a separator so that "http://myserver.com/" is one text > child of DAV:href and "more-stuff" is another text child? How do I know > which one to treat as the URL, particularly if they both look like urls? > - Do I conceptually remove the ignored element? That would leave > with a single text child containing white space, approximately: > "http://myserver.com/ more-stuff". I think this makes the most sense. You could also define it as - remove unknown child elements, - use DOM's normalize() method (or equivalent in your API) - use the value of the resulting text node > Since all this is rather ugly, I'd most like to have a sentence > added to RFC > 2518 (section 14?) that states at a minimum that "text elements should NOT > have their syntax extended by adding XML elements because this is unlikely > to be backward-compatible." I think we already instinctively follow this > guideline, but it's hard to write solid code based on guesses and > predictions that aren't written down. I agree it's ugly, but maybe it needs to be done nevertheless. How about just describing the "correct" way to get the text value? From w3c-dist-auth-request@w3.org Tue Jun 5 18:52: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 SAA01019 for ; Tue, 5 Jun 2001 18:52:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA07112; Tue, 5 Jun 2001 17:54:06 -0400 (EDT) Resent-Date: Tue, 5 Jun 2001 17:54:06 -0400 (EDT) Resent-Message-Id: <200106052154.RAA07112@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 RAA07088 for ; Tue, 5 Jun 2001 17:54:00 -0400 (EDT) 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 RAA20626 for ; Tue, 5 Jun 2001 17:54:00 -0400 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 OAA08630 for ; Tue, 5 Jun 2001 14:53:59 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Tue, 5 Jun 2001 14:51:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: IETF-51,London, UK, August 5-10 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4982 X-Loop: w3c-dist-auth@w3.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 FYI, The WebDAV working group will be holding a meeting at the London IETF meeting, IETF-51, August 5-10, 2001. At present I do not the precise day and time of the meeting -- I will let the working group know once I do. I personally will not be present at this meeting, however Lisa Dusseault has graciously agreed to be Chair at this meeting in my absense. Registration and hotel information is available online, at: http://www.ietf.org/meetings/IETF-51.html It is my understanding that the DeltaV working group will also be meeting at IETF-51 as well. - Jim From w3c-dist-auth-request@w3.org Wed Jun 6 12:26: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 MAA04602 for ; Wed, 6 Jun 2001 12:26:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA24457; Wed, 6 Jun 2001 11:03:10 -0400 (EDT) Resent-Date: Wed, 6 Jun 2001 11:03:10 -0400 (EDT) Resent-Message-Id: <200106061503.LAA24457@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 LAA24393 for ; Wed, 6 Jun 2001 11:02:54 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37067.rational.com [192.229.37.67]) by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA11478; Wed, 6 Jun 2001 11:02:54 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 06 Jun 2001 11:06:54 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Jun 2001 11:06:54 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1033E59E6@SUS-MA1IT01> From: "Clemm, Geoff" To: acl@webdav.org, ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org Date: Wed, 6 Jun 2001 11:06:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: "nothing left to cut" (was: Re: [ACL] Owner issues) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4983 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: There are several very different issues here. The "cut until there is nothing left to cut" refers to protocol semantics (i.e. what a server is required to do), *not* the text in the protocol document. It is of course essential to supplement the normative statements (i.e. those with a "MUST") with as much descriptive text as is necessary to make the meaning clear. In particular, with descriptive text, it is better to err on the side of "too much" than "too little". So the criteria for descriptive text is "keep adding as long as the net clarity of the document is increased". (But there are additions that can decrease the net clarity of the document, so the criteria is not just "add as much as possible"). I believe that "minimizing the protocol semantics" and "maximizing the protocol document descriptive text" are in fact complementary goals. There is another issue, of whether you repeat the same normative statement in different ways in different parts of the document. In this case, I do believe that a particular normative statement should appear in exactly one place, but that descriptive text about that normative statement can and should appear in several places in the document (i.e. wherever it is useful to do so). Cheers, Geoff -----Original Message----- From: Greg Stein [mailto:gstein@lyra.org] Sent: Wednesday, June 06, 2001 2:07 AM To: Clemm, Geoff Cc: acl@webdav.org; ietf-dav-versioning@w3.org; w3c-dist-auth@w3.org Subject: "nothing left to cut" (was: Re: [ACL] Owner issues) On Tue, Jun 05, 2001 at 01:26:43AM -0400, Clemm, Geoff wrote: > I believe I was the one that originally suggested we allow > updating the owner with a PROPPATCH. I have seen the error > of my ways (:-). So unless there really is someone that > feels this functionality is important, I believe that the > principle of "you aren't > done until there is nothing left to cut" says to take it out. I am beginning to seriously disagree with the whole notion of "cut everything until there is nothing left to cut." You are taking it to the extreme, leaving a specification that is obtuse, hard to understand, and requires a half-dozen readings just to figure out the subtleties and interactions between the elements, such that you can *infer* what should have been outright specified. Cutting features is great. Creating obtuse specifications is absurd. If you want a *STANDARD*, then it must be obvious to *all* implementors what the standard should be. If one out of twenty people can figure out ALL of the implications and inferences to implement the "standard", then you simply DON'T have a standard. You've only created a guide. The other 19 people implemented something wrong because they couldn't grok the darned document. I'm not making a statement on the thing. Instead, I'm arguing that your policy is erroneous. It needs to be tempered. [ I believe this applies more to the DeltaV spec than the ACL spec (I haven't read the ACL spec lately); the DeltaV spec is currently a very opaque document because of the "say it once; anything more is redundant" attitude taken towards it. ] Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Jun 6 16:25: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 QAA08793 for ; Wed, 6 Jun 2001 16:25:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA26703; Wed, 6 Jun 2001 16:14:36 -0400 (EDT) Resent-Date: Wed, 6 Jun 2001 16:14:36 -0400 (EDT) Resent-Message-Id: <200106062014.QAA26703@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 QAA26679 for ; Wed, 6 Jun 2001 16:14:29 -0400 (EDT) Received: from shell.rawbw.com (root@shell.rawbw.com [198.144.192.42]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA27287 for ; Wed, 6 Jun 2001 16:14:28 -0400 Received: from beaver ([198.144.203.248]) by shell.rawbw.com (8.11.1/8.11.1) with SMTP id f56KEH807873; Wed, 6 Jun 2001 13:14:17 -0700 (PDT) From: "Lisa Dusseault" To: , "Eric Sedlar" Date: Wed, 6 Jun 2001 13:12:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: RE: Logic for extending text XML elements Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4984 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit It makes sense to me that you can't extend simpleType to be complexType. That answers my concern precisely -- as long as we recommend this restriction for current and future WebDAV extensions. (Since WebDAV doesn't explicitly reference Schema inheritance, it seems the spec is silent on the issue, and I would rather it weren't silent.) I didn't suggest changing existing datatypes at all. lisa > -----Original Message----- > From: Eric Sedlar [mailto:Eric.Sedlar@oracle.com] > Sent: Tuesday, June 05, 2001 10:49 AM > To: Lisa Dusseault; w3c-dist-auth@w3.org > Subject: RE: Logic for extending text XML elements > > > I'm not exactly sure what you mean by container, but you can't extend > simpleType XML elements to become complexType ones (which can contain > subelements) in XML schema via the Schema inheritance mechanism, so > rather than updating the DTD/Schema, the correct answer to me is to use > inheritance of XML datatypes to get the restriction you want and NOT > change existing datatypes. > > > -----Original Message----- > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > Sent: Tuesday, June 05, 2001 10:50 AM > > To: Eric Sedlar; w3c-dist-auth@w3.org > > Subject: RE: Logic for extending text XML elements > > > > > > I see what you mean, however as we extend WebDAV we frequently > update the > > XML Schema/DTD. E.g. we are considering taking propfind and adding an > > element to a container that coudln't previously hold > > that element. > > What's the difference between that and updating the schema for > an element > > that contains strings? > > > > Adding new elements to containers that already hold XML elements > > seems like > > A Good Way to extend DAV. > > Adding new elements to containers that previously only held text > > seems like > > A Bad Way to extend DAV. If there's consensus on this, perhaps we could > > state as much. > > > > lisa > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar > > > Sent: Tuesday, June 05, 2001 10:00 AM > > > To: w3c-dist-auth@w3.org > > > Subject: RE: Logic for extending text XML elements > > > > > > > > > The XML schema for should be defined as a simple type (like > > > "anyURI", which subclasses "string"), which disallows element > children. > > > I assume the DTD says the same thing (I'm not as familiar with DTD). > > > > > > > -----Original Message----- > > > > From: w3c-dist-auth-request@w3.org > > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > > > Sent: Tuesday, June 05, 2001 9:29 AM > > > > To: w3c-dist-auth@w3.org > > > > Subject: Logic for extending text XML elements > > > > > > > > > > > > I've run into a minor issue relating to XML syntax and WebDAV > > > > extensibility. > > > > > > > > I'm parsing: > > > > http://myserver.com/ > > > > > > > > Since an XML element can legally contain both text and > elements (e.g. > > > >

Hello sailor!

), it's conceivable that in the > > future the > > > > element could be extended to have: > > > > > > > > http://myserver.com/ > > > > 123486 > > > > more-stuff > > > > > > > > > > > > RFC 2518 says: > > > > "All DAV compliant resources MUST ignore any unknown XML > > element and > > > > all its children encountered while processing a DAV method > > that uses > > > > XML as its command language." > > > > > > > > That would indicate that I should ignore the element. > > > I can do > > > > that. But what does "ignore" mean? > > > > - Do I treat it as a separator so that "http://myserver.com/" > > > is one text > > > > child of DAV:href and "more-stuff" is another text child? > > How do I know > > > > which one to treat as the URL, particularly if they both look > > like urls? > > > > - Do I conceptually remove the ignored element? That would leave > > > > with a single text child containing white space, > > > approximately: > > > > "http://myserver.com/ more-stuff". > > > > > > > > Since all this is rather ugly, I'd most like to have a sentence > > > > added to RFC > > > > 2518 (section 14?) that states at a minimum that "text elements > > > should NOT > > > > have their syntax extended by adding XML elements because this > > > is unlikely > > > > to be backward-compatible." I think we already instinctively > > > follow this > > > > guideline, but it's hard to write solid code based on guesses and > > > > predictions that aren't written down. > > > > > > > > Any other proposals or insights? > > > > > > > > lisa > > > > > > > > > > > > From w3c-dist-auth-request@w3.org Fri Jun 8 10:41: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 KAA13352 for ; Fri, 8 Jun 2001 10:41:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA12486; Fri, 8 Jun 2001 10:36:43 -0400 (EDT) Resent-Date: Fri, 8 Jun 2001 10:36:43 -0400 (EDT) Resent-Message-Id: <200106081436.KAA12486@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 KAA12466 for ; Fri, 8 Jun 2001 10:36:36 -0400 (EDT) Received: from conductor.synapse.net (conductor.synapse.net [199.84.54.18]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA15806 for ; Fri, 8 Jun 2001 10:36:39 -0400 Received: (qmail 8937 invoked from network); 8 Jun 2001 14:36:21 -0000 Received: from ppp-44-99.ott.aei.net (HELO sri01) (216.221.44.99) by conductor.synapse.net with SMTP; 8 Jun 2001 14:36:21 -0000 From: "Sridhar Erukulla" To: "'Julian Reschke'" , Date: Fri, 8 Jun 2001 10:37:57 -0400 Message-ID: <000001c0f028$9c6c1160$37c9c8c8@ByteQuest.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) x-mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Importance: Normal Subject: RE: WebDAV FAQ started Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4986 X-Loop: w3c-dist-auth@w3.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 Nice work! One suggestion - maybe this should be named as 'Known Issues' rather than FAQ? Erukulla > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: June 8, 2001 10:21 AM > To: w3c-dist-auth@w3.org > Subject: WebDAV FAQ started > > > Hi, > > I've started compiling a list of known issues with existing clients / > servers: > > > > Feedback and contributions are appreciated. > > Julian > > From w3c-dist-auth-request@w3.org Fri Jun 8 11:45:17 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 LAA14782 for ; Fri, 8 Jun 2001 11:45:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA10851; Fri, 8 Jun 2001 10:21:32 -0400 (EDT) Resent-Date: Fri, 8 Jun 2001 10:21:32 -0400 (EDT) Resent-Message-Id: <200106081421.KAA10851@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 KAA10831 for ; Fri, 8 Jun 2001 10:21:24 -0400 (EDT) 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 KAA14339 for ; Fri, 8 Jun 2001 10:21:26 -0400 Received: (qmail 24025 invoked by uid 0); 8 Jun 2001 14:20:46 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mail05) with SMTP; 8 Jun 2001 14:20:46 -0000 From: "Julian Reschke" To: Date: Fri, 8 Jun 2001 16:20:46 +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 V5.50.4522.1200 In-Reply-To: Importance: Normal Subject: WebDAV FAQ started Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4985 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I've started compiling a list of known issues with existing clients / servers: Feedback and contributions are appreciated. Julian From w3c-dist-auth-request@w3.org Fri Jun 8 12:19: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 MAA15655 for ; Fri, 8 Jun 2001 12:19:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA19266; Fri, 8 Jun 2001 12:10:43 -0400 (EDT) Resent-Date: Fri, 8 Jun 2001 12:10:43 -0400 (EDT) Resent-Message-Id: <200106081610.MAA19266@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 MAA19240 for ; Fri, 8 Jun 2001 12:10:36 -0400 (EDT) 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 MAA27833 for ; Fri, 8 Jun 2001 12:10:35 -0400 Received: (qmail 11582 invoked by uid 0); 8 Jun 2001 16:10:23 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mail07) with SMTP; 8 Jun 2001 16:10:23 -0000 From: "Julian Reschke" To: "WebDAV WG" Date: Fri, 8 Jun 2001 18:10:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_004A_01C0F046.48AEB500" 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.4522.1200 In-Reply-To: Importance: Normal Subject: RE: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4987 X-Loop: w3c-dist-auth@w3.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_004A_01C0F046.48AEB500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Thursday, May 10, 2001 9:02 PM > To: WebDAV WG > Subject: Proposal for marshalling property type information > > > Hi, > > attached is a an attempt to define a way to marshall datatype > information for WebDAV properties in terms of XML Schema (part > 2). (the archive contains an HTML version and an XML version > conforming to the RFC2629 DTD). > > Feedback appreciated. I didn't get any feedback, therefore I am retrying with a plain text version of the proposal :-) Julian -- Network Working Group J. Reschke Internet-Draft greenbytes Expires: December 7, 2001 June 8, 2001 Datatypes for WebDAV properties draft-reschke-webdav-property-datatypes-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 7, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This specification extends the WebDAV Distributed Authoring Protocol to support datatyping on property values. Protocol elements are defined to let clients and servers specify the type of a property, and to instruct the WebDAV method PROPFIND to return datatype information. Distribution of this document is unlimited. Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at w3c-dist-auth@w3.org[1], which may be joined by sending a message with subject "subscribe" to w3c-dist-auth-request@w3.org[2]. Discussions of the WEBDAV working group are archived at URL: Reschke Expires December 7, 2001 [Page 1] Internet-Draft Datatypes for WebDAV properties June 2001 http://lists.w3.org/Archives/Public/w3c-dist-auth/. Table of Contents 1. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of data types . . . . . . . . . . . . . . . . . . . . 5 4. Changes for PROPPATCH method . . . . . . . . . . . . . . . . . 6 4.1 Example for successful PROPPATCH . . . . . . . . . . . . . . . 6 4.2 Example for failed PROPPATCH . . . . . . . . . . . . . . . . . 7 5. Changes for PROPFIND method . . . . . . . . . . . . . . . . . 9 5.1 Example for PROPFIND/prop . . . . . . . . . . . . . . . . . . 9 6. Compatibility Considerations . . . . . . . . . . . . . . . . . 11 7. Internationalization Considerations . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Intellectual Property . . . . . . . . . . . . . . . . . . . . 15 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 Reschke Expires December 7, 2001 [Page 2] Internet-Draft Datatypes for WebDAV properties June 2001 1. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The term "property element" refers to the XML element that identifies a particular property, for instance The term "prop element" is used for the WebDAV "prop" element as defined in section 12.11 of [RFC2518]. The XML representation of schema components uses a vocabulary identified by the namespace name "http://www.w3.org/2001/XMLSchema". For brevity, the text and examples in this specification use the prefix "xs:" to stand for this namespace; in practice, any prefix can be used. "XML Schema: Structures" ([XS1]) also defines several attributes for direct use in any XML documents. These attributes are in a different namespace, which has the namespace name "http://www.w3.org/2001/XMLSchema-instance". For brevity, the text and examples in this specification use the prefix "xsi:" to stand for this latter namespace; in practice, any prefix can be used. Reschke Expires December 7, 2001 [Page 3] Internet-Draft Datatypes for WebDAV properties June 2001 2. Introduction This specification builds on the infrastructure provided by the WebDAV Distributed Authoring Protocol, adding support data-typed properties. Although servers must support XML content in property values, it may be desirable to persist values as scalar values when possible, and to expose the data's type when the property value is returned to the client. The client is free to ignore this information, but it may be able to take advantage of it when modifying a property. On the other hand, when setting new properties, it can be desirable to pass data type information along with the value. A server can take advantage of this information to optimize storage and to perform additional parsing (for instance of dates). Reschke Expires December 7, 2001 [Page 4] Internet-Draft Datatypes for WebDAV properties June 2001 3. Overview of data types Although WebDAV property types can be anything that can be marshalled as content of an XML element, in many cases they actually are simple types like integers, booleans or dates. "XML Schema Part 2: Datatypes" [XS2] defines a set of simple types which can be used as a basis for supplying type information to attributes. Data type information is represented using the attribute "type" from the XML Schema namespace "http://www.w3.org/2001/XMLSchema-instance". In XML Schema, data types are qualified names, and the XML Schema recommendation defines a set of built-in datatypes (section 3 of [XS2]), defined in the namespace "http://www.w3.org/2001/XMLSchema". To avoid unnecessary verbosity, data type information should only be supplied if it adds usable information to the protocol. In particular, type information is not required for live properties defined in WebDAV [RFC2518] and related standards and properties of type "xs:string". A server may implement any combination of datatypes, both from the XML Schema recommendation and possibly from other namespaces. Reschke Expires December 7, 2001 [Page 5] Internet-Draft Datatypes for WebDAV properties June 2001 4. Changes for PROPPATCH method If the property element has an XML attribute named "xsi:type", the server may use this information to select an optimized representation for storing the property value. For instance, by specifying a type as "xs:boolean", the client declares the property value to be of type boolean (as defined in [XS2]). The server may choose any suitable internal format for persisting this property, and in particular is allowed to fail the request if the format given does not fit the format defined for this type. The server should indicate successfull detection and parsing of the typed value by setting the xsi:type attribute on the property element in the response body. 4.1 Example for successful PROPPATCH >>Request PROPPATCH /bar.html HTTP/1.1 Host: www.foo.com Content-Type: text/xml Content-Length: xxxx false Reschke Expires December 7, 2001 [Page 6] Internet-Draft Datatypes for WebDAV properties June 2001 >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxx http://www.foo.com/bar.html HTTP/1.1 200 OK In this cases, the xsi:type attribute on the element "Z:released" indicates that the server indeed has understood the submitted data type information. 4.2 Example for failed PROPPATCH >>Request PROPPATCH /bar.html HTTP/1.1 Host: www.foo.com Content-Type: text/xml Content-Length: xxxx t Reschke Expires December 7, 2001 [Page 7] Internet-Draft Datatypes for WebDAV properties June 2001 >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxx http://www.foo.com/bar.html HTTP/1.1 422 Unprocessable Entity Does not parse as xsd:boolean In this case the request failed because the supplied value "t" is not a valid representation for a boolean value. Reschke Expires December 7, 2001 [Page 8] Internet-Draft Datatypes for WebDAV properties June 2001 5. Changes for PROPFIND method PROPFIND is extended to return the data type information for properties that satisfy the following conditions: o The data type is different from "xs:string". o The property's data type is not defined in [RFC2518] or a related specification. 5.1 Example for PROPFIND/prop >>Request PROPFIND /bar.html HTTP/1.1 Host: www.foo.com Content-Type: text/xml Content-Length: xxxx Reschke Expires December 7, 2001 [Page 9] Internet-Draft Datatypes for WebDAV properties June 2001 >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxx http://www.foo.com/bar.html text/html 1 HTTP/1.1 200 OK This example shows that the property value "true" is returned with the correct data type information, and that the server chose one of the two possible representations defined in XML Schema. It also shows that data type information is not returned for "D:getcontenttype", as this property's data type is already defined in [RFC2518]. Reschke Expires December 7, 2001 [Page 10] Internet-Draft Datatypes for WebDAV properties June 2001 6. Compatibility Considerations This specification does not introduce any new protocol elements, nor does it change the informal WebDAV DTD. It merely specifies additional server semantics for the case where clients submit additional data type information in an attribute on the property element (previously undefined), and adds an additional attribute on property elements upon PROPFIND. Clients not aware of this specification should not supply the "xsi:type" attribute on property elements (after all, this attribute belongs to the XML Schema-Instance namespace which has been defined for exactly this purpose). Old clients should also ignore additional attributes on property elements returned by PROPFIND (and similar methods), although the WebDAV specification only defines this behaviour for unknown elements (and is silent about unknown attributes). Servers not aware of this specification either drop the "xsi:type" attribute, or persist it along with the property value. However, they will never indicate successfull parsing of the data type by returning back the type in the response to PROPPATCH. Reschke Expires December 7, 2001 [Page 11] Internet-Draft Datatypes for WebDAV properties June 2001 7. Internationalization Considerations This proposal builds on [RFC2518], and inherits its internationalizability. Reschke Expires December 7, 2001 [Page 12] Internet-Draft Datatypes for WebDAV properties June 2001 8. IANA Considerations This proposal does not introduce any new IANA considerations, since it does not specify any new namespaces (in the general sense), but merely uses existing ones. Reschke Expires December 7, 2001 [Page 13] Internet-Draft Datatypes for WebDAV properties June 2001 9. Copyright To be supplied by the RFC Editor. Reschke Expires December 7, 2001 [Page 14] Internet-Draft Datatypes for WebDAV properties June 2001 10. Intellectual Property To be supplied by the RFC Editor. Reschke Expires December 7, 2001 [Page 15] Internet-Draft Datatypes for WebDAV properties June 2001 References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, . [XS1] Thompson, H., Beech, D., Maloney, M., Mendelsohn, N. and World Wide Web Consortium, "XML Schema Part 1: Structures", W3C XS1, May 2001, . [XS2] Biron, P., Malhotra, A. and World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C XS2, May 2001, . [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999. [1] [2] Author's Address Julian F. Reschke greenbytes GmbH Salzmannstrasse 152 Muenster, NW 48159 Germany EMail: julian.reschke@greenbytes.de Reschke Expires December 7, 2001 [Page 16] Internet-Draft Datatypes for WebDAV properties June 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Reschke Expires December 7, 2001 [Page 17] ------=_NextPart_000_004A_01C0F046.48AEB500 Content-Type: application/x-gzip; name="draft-reschke-webdav-property-datatypes-00.tar.gz" Content-Disposition: attachment; filename="draft-reschke-webdav-property-datatypes-00.tar.gz" Content-Transfer-Encoding: base64 H4sIAM34IDsAA+w8aXPjuLH71foVKKZeYldJlCUfM/ba2vHYnoyzvmJrdnPUq1cQCUlck4SWIG1r U/kv/vb+5utugOChw9dmsnllVY1HIoFGo+9uNOknfJi2EqG88Y1o3YmBz29bk0RORJJOWz5PeTqd CNVaX3fHaRR+85LPemd9fXtz85t1+Lzbpv/hSod+w53t9c1336y/2+isd95tdjfhene9u731DVt/ 0WrP/GQq5Qlj3/yUiKXjvhdB/DXw+cqfve/uo5DdikQFMt53Ou66w0TsST+IR/tOoGTr/futnVbH +a63hwLAYHis9p1xmk522+27uzv3bsOVyajd2dnZad/jGAeGCu739tIgDUXvKBciNpQJ+1EMjg5+ YEbEAqH22nrYnkqnoWA4ct9JxX3a9pRyeo2Dxj8aK/i75QtPJjwFRHdZLGPR+GfjYHcsAfm5Q7LY F0kYmHHcS4Nb8ejAjxdHf8VBngxlsst+p2X02waDz1DGaWvIoyCc7rKxCG9FGni8yXgS8LDJFI9V S4kkGJaGq+AXscs6G5P7bwH6504Z9gZ9Zgdv42C8iDi1xiIYjdPy5WfgsTLhI9EaJILftEDRBSzL b2XgEzLdpRs1yGz+2qtuPGXVjV951UtcNOLJKIhboRgCObsi0iuYq4mmMl2G8VfHMzM28hlV/sHo /sHHUxpf2wLeOnJRF7SI5hOH9Jnd9frcXZutljZfl7RbHgYjEORUTmBJ15OTKW2njtI6oeSOZdoH HSgwmkXozghdLJOIh/rGXB2cg6/3CJtKGO1ohEDOb7pPQWcgQ/95yDxLTQ06V58OS8hs0+crIDOH MGQZy5KzszNXX7rduSajuLwMcSM8JDF0eeXJSAOOjQ+R8AMOBj2IU/YPAksfN5bmmh+oScinu0iV f8KUvTaZ+t5eW7uJgfSn4Cz4AMy/F3IF7sXMdQDXBJRn3wG35IkwnHBfeybzW024R7+7DrsL/HS8 72zALU0AcGdbDqPt7Tu0PfBMaQL/fDYYEUn3HWOC7DhPxGA6HKNTxe850OE7IA+Oa8LjHHGQHaf3 AH8fYJdwHTYJIwZJuzrMqKADl9upj3+SOahpbs+gNn+jvT3OxokYwrxk6Lmp9Bx2eHpwfb3vkH4h rvny5sJD/wLxBATbvIxIm3iRs8Qst739X4vZ0amxo1NQOsd2A6fbrWmtciw9yEY6vXOR3snkhv0I fwAQ+2Mis8mDRu25sP7ksk8uu9Kh7cMsnZ8F7OS8f3x1ftxnR1cHn/ovxGiUCBEPpqlQr0WnUDPU 19+H6bf+kwP534+0mtvPS+mbxYJ1IZD/NTezcshTMZLJdLeC4kk8RE+E1pWHL8T3tWge308CoO8u OxKeiAYiKW/+Ncjk6kZWwg9u6yarbDjIIziPx9TG9gA0CMY7vWsYnikmhywdB4qdiUiC9e309ia9 xgp8+njVl14WgY1h8B1WPEFrE4u0dYSiBVd8vEHD6c/KShCzYRaGEBBp9sQeWot0DBsIEZvbALMK WvZaeMg8iEHwF9hHzPFcZC3xmYAS1OqqgEgCMI01yBE0GxEWRXYcQ5wmwCXFI70frm7YJ5kAQqsn x/1Pa00WaGBcNfVW4GcOd4RWRrk081ymkISMecokrJCYexAlTmFXSjJwZmkSDLJ0HlpczduDu3Bj pLSl+eh0fGIphxXvgyiLcKsquGcR+OSxBo/oIz4DwbIJaLbwmywR4GI9/AaT5UDJUMB1NpiabZRw RFZOWRpEwiBGDA9iPkEBAhePBJAsU4LN4KxgoaFIBHIa1FFgQIArwngvSAXBg/UisyrQMcZJDhl1 EBdYAYwg5HW09F57UpJAAcGLSnG/XpYkKIf15T2ABpvmngcgYHc8panW8ZWS0kCkQ0pL8Uu7E/gt PgDGQRao3BQcb+/pY9E5LkW3pijXY+7LO3YExsJLZQLq+CLEFYFxdUL9yIAFKAJba7jdBaCZggwZ A22sWLICABiGwzyHYKAQgSdK1qK4tXq4xvplNbyWHqA3ZasIb81lB7DaFQ5V6IdFcit8l/Q9X+bA ENqCJ6TVRHjBEEJOMhkQJ4nYV6TwxtIdWSX02UGWjiUqPrtMJEQ9MkRpbKhsMpEJKJe2lHhfxrmJ nKKmZUK5xRwRCqMfQJqGL4ZgT3yEBIoExjfQ90DzaBtJjuSU0EJTjJLA7QLayKSyEcSAaualZfQj ASj77PLq4vLTyfkRrpKINEviHFsBumIdnms9IVINGIB0shRACuVmvWzAszgMIlBJH/YYgtUTgDhg 5MlIbxPWRIwa80mJyP+gi0L4c1Ujvla1mGhKrAhHPAhTuXu34bXQRLY4wPqgS0NOb95VlNkmuxsH 3ji3Zj9JIjoYLcSV8ABaKQV5vfYrKhv8BErFGg58Ux7gLRzcyVIsICj6GXidmnW/M0D2CxC9ZeNz 3cpVCwjmZco6NmLr8Udka404IEc88cbBLSk8+3J1ussadZVHG6LyEtqBHq7al9kgDLx2Ba22tQLP mEPIs+onFyfaEWA0TmayLswqKahHGyMw3G+/JWi/wQSNs5hHwJ8cHtnUPvEJRPMQQgbUdW1cEUKG sVoELAGMzBcbmer5gxqWSsdtLiR0HQTxYI0RhUomIselbmEpVIqCnotgwca6dVjgQhLpZzTgcQgb Tm+jDuECrPJtIO5w52hGySg/AZtNp7dZh3UIccvIBNdopS8P+oefjdl+AkSkFvypQz2+59EEWINQ VUaxAITPxQJPgdxFyDPUK0MeggkU/nOggmhuPUYB8lNPJcAWEmBrOQFyoG30mI+D3HZ62zM4ogSn wSAIA/DoIIIqAFPEnyiF75zeuzlSCIGMEergFx1/PBfwe6f3fgbwwfnBswHtOL2d2T2b4Ovx6R2w fp31eVsMQxiSgdpemmhlMTAb7iun9791WFf25mIAnGIKO1uHGH9Q7MD3MRFoIJzFs20pO5//CfPN IgLFvJbithqcdhb2Go3fvm/7dzsQdAxlJ1I3927B7kXWHkA0IC6aD8adAKg2BK2YJtyIKcZIEMo7 Z1+u+05T/8/OL+j71fGfv5xcHR/h9+vPB6en9osZ0ViBnxdfTs0I/FbMPbw4Ozs+P9LTzw7+6ugI 3Lm47J9cnB+cOph+UpTcWLFxMsZoED4OMN4Gwk8SSpohYfWFDg19nFWQHesWnc4OxJxYhtl3vrc7 QpOGGTMMh0EUXp9ACOthMn0F8SQkXLTiqbgVIWjD3w2o/9bhJUX2y6jYtVQEPCPm2ETG5C2OTsxt XP+Xs9P8lq5mgOEBjg0hGwWOQp7CE0jrspAnpZQFN4H5ChZyNEqAUyJgYawwjkTq6YgiFPEIonFz FAyh767D2lRWhEk4fulWNudspdgGpi6YIiMupZSJRjl2S8QiStFgN0BzlZeXum6ngxFAlWdbnfeW Z5/7/Ut2jDmljuFxoflJUKtlInvDLoDyVHZt2T0iIxIBVIGURisQVXS8sYg4BWMypnwMNq05cys9 PkDGTAueUU6E1MDV0Ozob2zOMTxm3m1Y9JpWcDB5/AQ7HCTiNkAeU7oKkS1ph9AOWVndqGbeKNA4 HrAfBvfMuVe7DsADEUMZyXkE0yxa3+oiDx62e6JJhSYz2ZRAkLeQTTlIFo3iLhhxTJAzIJHDVgvG /eW6Y5lWDGeXILmsU5nV+zuMJdasmSIdyQZsB7Qt4SHSNTUM1gz3qTiTayyiiSvYIpmLZQ24V5qF pgKHAiw/GJLfS4t954nsmKsX8amVq92vzbBgAcdC2JpIns04bRTe/OpL/Wqe+pT8ajXzWeZNu7k3 ZWxOmWyQBSE4IhmTBATxMOEqVxFdjPe1HUF5eGopDSSBeMPK5bQWZlZoeIsDB5ctt4ld68IOQlgj G41tHS3KVGrBoxYaJ2PKxeVyHRbx81oR6qFQQUICBvI9wWoVQNIj0UEoj6N7MxfuxgLgSaUCmJBX 57AUKpUwFMG9QWRK9TcarlWpjAK6J12q08VBHKGLg2QyzHf0SWBnEkGYgQRKjDPGVGW3Zb0mcCwt bSjfSMpv4Id/y8FdjCiPDxAgIRRJsD1TXRjLEXvEGyHlN4jyF3pDujIP6Z3f1ECVSFMEGUPuXHCU aG10v0xoZDtoQpFil/cE+iYBEtXqcC2imcsODLMJXnV/AC6vXpbhAB3kJA0isClguWSClDAsA/xw HAmmiUchmFFUpoQbFA9oW2oqAUKtvRmu1xquvOJSMlyLCi7LTNhGYcKsIaieXk41GHtkEk9BOIC3 FMSaixHwe8whi0UjBJqeWwyswMfl0LeJRiRCZ+ZxiK9QJqeMU+4bTsmlqwD9KRoAWjUMbnQuMAJz AhoqZSg4FnoTLUkumwlFurvMnsairy0HMN2FAUxlFsYvXYpfbOTCUS312R+VTDR6OsjQVIClKFDm OHjAVaBMYWkyCclEzCgnKE8R0LjsEZO9YU320VxVJ0to4lpAI1OaS6WgiTk4yQFDKCO8AxiXyFCE SM+KjlZO4hKUZknyiJ8/A2t1xEzwjaE3cbhZGfCA6I8OQny9lxmqozNNYVl7IKPYap5jbMCA1/J5 rZnnLzqSQ9o8gyDOI0Z/wxr9vtRNkCyLY4EVR8wrQHEHUlF0Od+MK9DM0IdYIpxqSSOpQqoG6I7Q 9mLGQjayJmHGZ1L04EJwU8o0m0bN6mIUy5QlOkfWEWoY3IqSKyqRCiAYc/GvTPBIaBIR4tG6Dpw5 5vh4tYQV+i3YDaCEiRHCj0dPYYzOf61PRPdPOq4TW7RVMhoEsc0VrQiiPQLHmqsTijQsbqStJtGE q452pnqG9vtWyNSbT3ytT8xPDko+cfnBwTLPuGlLZSfDauCZ1zwwtzTurTCxCMjXiR4Z26aJZUvC pZPC2QBLCSwDI8g81PJrlYoG0y4l1eoyGw67lKrm1rlJJ7f6WBzHUzmDFB5bQEBHjDt1mqW4GZQb uJFo52zBN5iJt3V1zqha7o/ZKi8bhVeaYpfyqQrJvLGUioIPsHxBauwcnQ2ETBORKGOSDk2cQBUp kTn/D8rmj9qqwlDe6dQBz2loz+a4GU0r/tTgAdQIrCA4ICm0hRwGaem+3b7N6HFfj1ifzUoh0ezX 2Pogr1YWJ1MhLJIap0f2xITZ5tSbskDNJsCWDu3TNJeTXCBLoirj+XKtHSCQQU3AXBMs6edpDVin 7qLNFKdsJQ18/JANACKFcAbWLPHflWaBIR5WMOFmob/tAU+oz4ahb2l33A7e/yxVusvQRw+ldMH6 4kVz5trqw953qW7Tvo/C8p1TKp7usnv4NAiJMP32aDcni+7o0rXV3SNTXTW70xeBtPOev1kUMtXm Pj61OuNv9Qmw0bb1ie1fNnbcrXWn6CnVuwFRKLeZFlusNp/i9b/tgqfFBhXfCs1+2VjgjCEPlcDB 7WJ0BRLdq69gLpZwKQ0raF0uXM/IhZbJqmDkQsC66+/YWRamQUv3V75KACIEpHSf5n8493NVnhUB NNN4tQTUKI/VMcOjfOSsCCGNZsWoYP5ThEofV8yVmpIQEzPwTonj6+zi+1yw7P15clhF09yoU8Zc LvG+Jo2LTJ8N8E9MIZgS3OYjtjc3uU5BH8dafkWhA0/L8QPcE0BDDD3oKTkIBaTOp1Q2iIIUA+S5 KYSNLpcZ8KKZYYEBn+1leDPe/3HGO30z3P8/TOkLbeZmt8u+xDCByg8YSh/HEKJPF1vR2t71YfwE jQYOO8ojYoxHKbe4V34ucTU7W5tapsDXMNO2+I7HPIWdroT9xsYNhMfz4ztbbdE5kKOPxXHL+oSY nhKoHSrrhwbyBElnZ9YGv+X4L83x8964JTl+pTVuWYq/VRS/7Tzgq+5v10mhaQPPT6Nmy2WUddoa VO6xFdxUphd9KDHHxDzMk7E+IlH4MBU1f5pWT+xsRTRW9sKg168upkrn21Q4Kle39towgSiRz8xN 8h9UFQhK69wU/dcv1xE+JP62Zlc+GbVI666wR9LKcu/igqik1rr4nJCEeP61IhIgvl/zSK/yRXWb r68WbUHI+nZ9QM19VMxsGWDpEuL9m/ftz6Lk1w0Bf1sxRHF9vsRQiIgcKa02O4LVwTwl8uwsizzn h55LI5lHsr+vE1VslZI/agMxPUFYyLtTRQZXa1xw0iQTTqV/IT+mb+ArLRJqiJrrdPJDtGpq6I2x RCpjYeuBd9QcYFosavFJpV5bVGZddpLqlq0CewAy3/fZoyKDP9pipy4s2Pep6tXYunPiYSK4P/1a DuotEHt9IJY/AFAOxJb2/y+LxLZLfckzjVS24h6Yzix9EGDaY6pPCzbxDSk0A7DChhmKDfMOLHp5 im206h+RtEcQWoX5OQmeI5YaWbRq4Xkr6AYkSZ6yfbCUN9yNYbJ9GlGXYMrz5+pNg+kexyeU4lcn 2HUoMwUIYr2HtGNN6z+mHj6dgpZXrMCsw1MsA4NnA59HTie27enEodkgMoHf4bF+3iNU5ZQ5usBh uu2BdlUchjXYY/it0ouC8FimqRcoxg8E9jLlDdWNcu9C6yTvMCrO7Iv+z4EQceV4Bgy0lxJy2ihl CTadrbnsApC3zNR7IVtoOsbmkRkb/EqGrdiJtYqDaRFprtIDq0EU4PGTTlEUstO03jQqnYBV2tLZ f94XQaQZiDFH4Uh0s3t8E8u72CIAsFbNKwIUJLR4lD2QWWrHFTtYe4IcaPd2bVoEH5MDEehn3LGR fLEE0KPxeZsg6k21V61+svlZ3mH3MJVU8TySHp2OhamKzp6V1U7HClUEhmjm4MsJGBtw76Z4aLh2 +IXSZkuX5Rrqm9d4kdfIH/Kq9ts+/ozXMufxrkjjdR8uSo5UoKVFC+6/MprIj5ZB5PElFvgPUQlq +9Ju8a3L47UilD/OVxaheU/zLROZ9wtFZkmwQat4lVWawDJ0O8TvtJicv4sgn1p0+bBVY2FGIsZH IfDJevA9uvkYwZhwBB8/AUdlmhkgqn/rD3q15OTPb1ZCVvv45jJ52cnlpU/tL7YebJ4CAmvAjiE2 kMkbk179pKN9SrbmI+Y8JLv0Ucf1Z/MMV3rj2zNecVB+GBkZWn7+OH/FgaZTQRcII0E7zLbyd0ak cpK/60BDzx/srD6XqdEyr/eqzq29cKRV+Hee3PLEZ1/igN6qm06d3seE+zGGktcuOfAHfNOOEbUV p/5KEEzd3MC8UscNVOAKP4OrLbD0QrWBEO0hRNj0DVHV7zN66aOoiBB1DdJLuD4eXj50NpulYtsK vioDl6lcPMM3mzx0dnbe2bfTrBTMewLBIZnCHryz02cSOh0kfPoB64XY6A3xjScjS/u+vUwh0rlI lcchC0AGTJusb6hfh/mT4PGEf4gCL5FKDtMKzLP8qtO75DIMmuxPC8B4kYq8nz9kgYcMswAKQaB3 RYUg95ISTXYIKSMfScIVUWfH5sXLwC9I/Di+sNjpXYPxGYhk1Drz/pxBatlkhy47W4ADsNSNeCiS D4Kr1FVZXNnMdRYzvaGpSkUEanSGg5vs2LV9z/NeSnW34ekX+fwoE0hSf4SIBLNGioFkkgZZ9AS5 LhWs+1f4uuj37avjw9Z9FLbwx3oXTbGJjFGHQcZusgk75fEow+d/VkFa1ljHXa+K7I8bhw9wpyKe n8QgyXgyRQl9/1IJve6UHix9uoSO0w+eHCkP1dblnpvdLBAF8AbxIEtGY6fXH8toorDS+tm1RqIO +Aiyb9/9KIQ3/iAT7oWiwtsLugSyjgOa7GgBlChLUIOi7JdIVubjw1NrWFODiBBCzItYkHRAKAiq s0jeziUf/88ZHl+GSo7jD6FMM1UBe4pX2BHaGjkhu3Mok4l5Uy6sYOc22flXF0KQPf0kdqvTdnpL HzKeI3TXnZpNnD7o96i9UN66pa7kp8vbJc9C9wf3Y5DI+MPNhEhk30/AAyUSdinw5YzoufUz/p8F VoC0A2DX8BcYQfOb7NJlPyzgNVdjeRM9aidpif9r7+y+08axAP7cnMP/oOFheZgEGvKxzazrLk2c hG4gOUBPNmfOPBDiJp4SyBjSlvlr+qfuvVcflvyBDVbb3VnchwbZlq4s6epKuvoJ6tCY67u3HapG D9N5ONxmrR9YxM2UItZ9wtNKuGmzhOVUgDmczy7ps+mYdmne1Le/Xj8Ecx/hoairt7+eDoM/A/yc 21+PIR/ctqDP+g7HdxNs/zbNDBCWmxlrTF+Y35XMCYguU18fpX7dyI7f2MuF7WXF3iHUYoy8EzeZ hYRHR0swz/HP9FJ9AVdxcN13z+NgONHYywmCmvZwhERmZ4+358se7Q/Hf4IaQ54ifBCf7R40Bewn +53OM1RUah7da7b/avfgaNnTZ6QnF0niW6zQb12vAzrxl696200o5t/pO9QFkvmfUU7rd9C1Lrsb K9q4nI340HbTJAo3CQ0ohY0iCycVNY4nmZj2JionCyBUgZRMSWArTmSmBfhwOJmNxWo6YQEkOgDe xJkGAnzgOsPsgbzJlIalrX9iLyyUdfCJhhbEqxQOAwILilPXyA/G5z+D6YB8hPEQBpKQFm2t5xeI S2soE5p8VpsX+VS6kOkp9J+GIQKJuXTb7AkBlSQayKHiinjKd7Rb+/PDFOmFodw7tU0rNLiSBE0F nhzJbZE41/kxgP5RRaUgF8pVYXg7/USfR5TThFi2wp0Bp2GH4fA+HD49CLzLaPx850eyEdBgjKs8 DzwXs9RPaKwVGRjW+cwff1DR4ZfB2VrcwY4gh4B7HmBGPuP4lNLBBURcMHqEvIi9VHH5I/nCCMes yE+JOigLNLoDptFwIpY+ZtH387+M/CdiK018/05jMIkVS9qMyg15PkgV0UU7ZGmDLr/kVnVFpJmO wL4Ihd+kytIstg9axaoi6qvYhQsxJ4bcSk9HwbwmNLXYQ4xfQjQWH6su6LmoMYzFeHKmM6q9yT3W zdw2idBnouriQuJjIDCwUIVoDzyvbliV4O6TT7OHWGH40iGVvBIj9D9NP0bTg2mlFtAaP60wQi/O MzkDFTpbXXU8mJ406C8zpK+ODgUBudao1kO7/ZSc1VaftftVQRigqYpzj6njEPqXx21vcMNa3RPz htc9a3c9r9funqm4Bq3+v9jpZe/YYyftPmj1dqfPkO923er1Wt1B2+uDefvvq57X77PLHmt3ri7a 3sk2xHp88f4EomJv3w9UdN3LAbtod9oDD9K+BBFuZEQ3IEtrQAK973vs8lTIBml3WsiDY+dez2t3 2XX74sKID55BkT2Krdc+Ox+QJPhLSKMJixF3vN7xOfxsvW1ftCHhy56K77Q96GJOTjECdtXqDdrH 7y9aPXb1vnd12fdkMaJxNsJV8rF/d691P6nFy+3lZ45Hlg0UJ5d9mlyGDmAykt5SgqM+Xhj8H+7N wK94tSPbm0vV4MeykFue+6OPKdtc3+gqfmxI/cuax//lnP+3v3+491Ke/7d3uL+H5//tNl9uzv/7 Hhed/7dD5zGBaQaKgBxpa9xFejaucVu8hnMAh82jOgTNa+yNW9lyfjq5PB7cXHkM7rH+TX/gdVhV Pnc3v6viQ2/wJtjwr6sLf1Z9o4Jmi0eId6YFY2jwBMMFdKbBw0Gq2IV1yXAvXkkx0RfOhxD6N/iL TyKsdAphhQ5B4ANn6DJxGn4MYtJZQjCaAuuaT+VwWap0/gkPSgx7qyIy3doCEwHBfq+r0XivmhwD 629IifigXWRKXi8csMvmw3E8+IUDpjKUZuqYuSHume/w6EbBfKEGzU6Dfjqhf4+CdK+dhvjTGU3v fFeMp+nvZGSMwVPPk3m4iMbVMsB4mtD6Mht0LIaPI+icETJ/5gX/Oo3o89AvKj6RikNbMun4FCyk CRTawh9CRcOhWZU1qC7v7MB7aMwTu98VQH/jFCqnEd1nOztaHhx5XAiMeyHY1hEWlXJnWFTsHWJR sXGKhfa9GnNeUPifrYMsKqVPsgBLGJIfhvf+fK3jLPD9tU+0qCSOtMgVp/S5FiRwnTcZUXdLHW4B DckQ+nsdccHzEVM+FX0W2UXZGqqZYh/RkJ0E/ngM7u5I+eM/R4K+xMpGOviaujeKygbaumKJbV1Z HW79RS8yBbhuYMXgDTXKZWn0dGWrEHtapfwhuH8OsVwceAVroOv89OvxSWvQ+hWLLYdIDe/99hvO 4ol3MdooxpRcrU+hrmxlYKgTX5d8QVO/7iqkaP4hLaOiMVKrrGiMsDQsurKUFm18XyJGNzIg0JUt ixRojOzbYqAtF0aQVRrrgaBV7W2IKu+maU4dbaz0ZTl4cWXLDr24smXii83maAtSTNXEFqVYZt0a ppiUllVOMcaYDSo2v7EdHDGVo0UeMcZnF0jMu4YEkbhYC0pn7GptyQpFl1SjBYwu1VArHF2MKa7b m6jbVwDkYhwlCblmjbXFwa1sWQDhVmyQcFGSsijczKJKMG7xyZUgtzEbyQLKFkWww7KVdb0EzBaj kDTbLDtxJRQtRqjTOmKdmhXiLKaxNnK2mNJbBlGNhl3lMKmyM7XCScXIyoBSuTW/HikV310FlZra UuvcLLPBQNUMq9IQVIxrHQpqcmxlkXWKQlmDnVJkSDuVIidbQx7QtKoNlJGGMny8HYv5WNeNQDTR jbSxNFtOzKMHEoAaCk1Hqxi3dLYK5hCnAHOYeXL2Zi1iSvzlAsgU85ViUBc5A+wQqS6aDxZ50ye5 nTxaiUuEU0djlejzyw0zRqehpegksHjxaQ990iO7niimTm5FySTtlKsP2aid/7HKINu2USNwGc1d gtlxBGMnUY3wixhVSdSF3CrF0E0wpSpKco0bw9o4immTUvV0KZxGPI+OSbFZVgF5122PWcr7cVvQ 0nT7ZLlOjjNKN/r4xzfB8vp4vtHFBXTxf79uLKwEsyilqWpRz4qGGHWXokmddC6plqtvoWxtkUfF ikNR9GjGSG+lcZ8G1tRmvCyhM1XHkcvOpAkOXJBk5CbzujpbPN5OxzNer3EVezWCpixb8WJRgGbW DAGPbCn+kqfo0KqqW2ykYTAubXZpGQTMb9WjlWVgarrLVCJOgnyp3dP1j9aQoxgcDXX5l+sjVvrA 39uy+O6dkRaUUmtchb50EtxLl5nv5hotuxlGS8JqyegDswcC32YcYAdfiUlb4lfS5FVpgCXGYoVg qc+lFUFY5jsbrNIbL6ErVs0itMFPpGUySwBFmuW3SFAk2SwgFMmGKslQNOc2bZESSTJLqERzeasE K5Gqf1lYot6GytES5ZKBFVwiRlaYl2iWeXkqolHaZbCIGJEVLiLNgxcHI2o2bJ4DSh7rTxtZZNP8 shRrCoqPIspg8RX0mknS5bKFXI8fx4UsD5CjeLIJcgWX+6LdTSKXuQStwu5HSYpX2US45aMcRl84 WG158tFeTLxhBsGXBYMjfF0THpY1/op0QuWbFOTuAHyIIdDpGl1KayXYTnJTQ2JHQ61fr6ntDDUB qKpF2xlq/dF0PmfyBkZh7EpIYq4S2xa0PQvRNgW5MWF37+Al6wxnszprffLr2qYE+cQxDGvC4O7e T7nXabGXzd29V+qWtoPAeXqAyufusJ932eHu39n+0QHbe3W4D4/QDfRSpr0DO3ITQbR9QNs6oG8b qBHuqsb3DdSQelWDR8X8Hoy6/KF7xlsHGrvwC0I/+gssMlf87zRkAL4ROSLLVt0WDjbREj8+8TFy RpRujKIioNon5xZcoIYuEBovxSPnd0RFmEk9ak4JMOHZGMU1hc6d+kowk56COWot9Lhn5l7SqIPT 3hb+QKJP5j4WhssxiND2Bqe6Y6Vw1kOHnamYdRGR3j+DuhpjKhSPWrEdCWqQWKN/egjRnJtAiVD+ bv37YDKJ+pkgVMn9Qi1Nzn1EYzTTb/tvfzxP5/9Ap23+17YWgp7YZqh06DZDyaM7JUimmIiGO3qn haUlqdzA5Q0pYutGhkDlkYnxIOkizn8pd9HVnMRllKiWiDjHVaOYUNJsE8zjlIpoqJbpR3KApWoM pK/2vwu1q1VZimVMaCJpMqjdIBNhOnIHtNBwRtX8+3XnfugUQhgktMGaZ0LZHV/VuDUDbXm/xncA JZ6CvKqnSGHz5xpKo7vpCp7IdvEtEIXQZ4nuoCAMLVvHD2I6fqEr+EHwyCgsodszMHrZCl4o1DQ2 33Idm5D4nS4x8fZ0kd/h/DIPTQit+FO5Yqbh/lYUkwh8mqRxRp8uND3LEk8kMlCOE5iba5NOuGJ+ PT2zhAzUc+h9wvo5TjMT4sDBXDHTAYZFxI2nrbZaXu8dLwWKrWK2dNoDaIO32BFNwwWZYzhP8owj 4/4oQEWQYq4c7B9AwY0eJtPx9H7B+n88g+7Sn6N9lprBQ7+Z3HjZaamNl4zvvETjJ9p5qfZZvu/r WyyTNtHPjJtEzYM91jzc3dNMog/DEY189YdesYOjI0gmuqdsp3nweDuONpJRGNx8DgM3iXNzGhiO AmmfNt3SqkoSmNykiepRbNJUSj2hrKmIhbLm+reorsYNI0t1tUkITKroHGZgtm4m0KPWqiQCUm9Y 5/4EKlkfffbFzRytoZCSue0sSalcUSWcGH0LMid1yYlVyXhwQmZOqswVMZ13uaKYnZjmQpylLmiH cJhM3knImqRi5sodJ2yuKHHXkFjhMXWhkbrJtFsJqZdCN3MzkAn13Kjh/xc13BkuUrbJF9XA/d0V NHCzsAZuFtLAJtIzWwET6VTXYQhA1VsZglXhEcZvJNpYYbZqbntLIbiuqDNaMS1HtFU9Ly1ktzJ1 J9t6TtBbc6VPxcJuNMVGUxTSFM2imqImpt1TJ07Xw9Jm64YbvT1xDK/emm7qTAQmGlKsdhYfVSnA rzGyqrMovFRahoYgerChHuqMh5VKw7BnOZbYmFGuMxFYKhXD8OS0Y8PyrAsE8kqp6JO9cgiizfce qfne5VNLxqQRVtaUyq39mrnRioJYRnAQtwz//2gu1ObaXJtrc22uzbW5Ntfm2lyb6693/Qc6L4v+ AMgAAA== ------=_NextPart_000_004A_01C0F046.48AEB500-- From w3c-dist-auth-request@w3.org Fri Jun 8 14:55:08 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 ; Fri, 8 Jun 2001 14:55:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA01005; Fri, 8 Jun 2001 14:50:51 -0400 (EDT) Resent-Date: Fri, 8 Jun 2001 14:50:51 -0400 (EDT) Resent-Message-Id: <200106081850.OAA01005@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 OAA00979 for ; Fri, 8 Jun 2001 14:50:43 -0400 (EDT) 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 OAA17471 for ; Fri, 8 Jun 2001 14:50:43 -0400 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id LAA02747; Fri, 8 Jun 2001 11:56:30 -0700 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Fri, 8 Jun 2001 11:56:30 -0700 From: Greg Stein To: "'Julian Reschke'" , w3c-dist-auth@w3.org Message-ID: <20010608115630.Y23560@lyra.org> Mail-Followup-To: 'Julian Reschke' , w3c-dist-auth@w3.org References: <000001c0f028$9c6c1160$37c9c8c8@ByteQuest.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <000001c0f028$9c6c1160$37c9c8c8@ByteQuest.ca>; from serukulla@bytequest.com on Fri, Jun 08, 2001 at 10:37:57AM -0400 X-URL: http://www.lyra.org/greg/ Subject: Re: WebDAV FAQ started Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4988 X-Loop: w3c-dist-auth@w3.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, Jun 08, 2001 at 10:37:57AM -0400, Sridhar Erukulla wrote: > Nice work! One suggestion - maybe this should be named as 'Known > Issues' rather than FAQ? Agreed. We already have a WebDAV FAQ :-) And would you be willing to place this on webdav.org and edit it there? It will be much easier to find. Cheers, -g > > Erukulla > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > > Sent: June 8, 2001 10:21 AM > > To: w3c-dist-auth@w3.org > > Subject: WebDAV FAQ started > > > > > > Hi, > > > > I've started compiling a list of known issues with existing > clients / > > servers: > > > > > > > > Feedback and contributions are appreciated. > > > > Julian > > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Jun 8 15:08: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 PAA19323 for ; Fri, 8 Jun 2001 15:08:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA02084; Fri, 8 Jun 2001 15:05:33 -0400 (EDT) Resent-Date: Fri, 8 Jun 2001 15:05:33 -0400 (EDT) Resent-Message-Id: <200106081905.PAA02084@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 PAA02046 for ; Fri, 8 Jun 2001 15:05:18 -0400 (EDT) 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 PAA18861 for ; Fri, 8 Jun 2001 15:05:18 -0400 Received: (qmail 19161 invoked by uid 0); 8 Jun 2001 19:04:36 -0000 Received: from p3ee24608.dip.t-dialin.net (HELO lisa) (62.226.70.8) by mail.gmx.net (mp002-rz3) with SMTP; 8 Jun 2001 19:04:36 -0000 From: "Julian Reschke" To: "Greg Stein" , "'Julian Reschke'" , Date: Fri, 8 Jun 2001 21:04:34 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20010608115630.Y23560@lyra.org> Importance: Normal Subject: RE: WebDAV FAQ started Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4989 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > Sent: Friday, June 08, 2001 8:57 PM > To: 'Julian Reschke'; w3c-dist-auth@w3.org > Subject: Re: WebDAV FAQ started > > > On Fri, Jun 08, 2001 at 10:37:57AM -0400, Sridhar Erukulla wrote: > > Nice work! One suggestion - maybe this should be named as 'Known > > Issues' rather than FAQ? > > Agreed. We already have a WebDAV FAQ :-) Will be fixed. > And would you be willing to place this on webdav.org and edit it there? It > will be much easier to find. Why does it matter where it is as long there's a link to it? From w3c-dist-auth-request@w3.org Fri Jun 8 16:15: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 QAA20094 for ; Fri, 8 Jun 2001 16:15:49 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA04952; Fri, 8 Jun 2001 16:11:33 -0400 (EDT) Resent-Date: Fri, 8 Jun 2001 16:11:33 -0400 (EDT) Resent-Message-Id: <200106082011.QAA04952@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 QAA04932 for ; Fri, 8 Jun 2001 16:11:28 -0400 (EDT) Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA26021 for ; Fri, 8 Jun 2001 16:11:27 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA76114 for ; Fri, 8 Jun 2001 15:05:49 -0500 Received: from f3n44e (d03nm044h.boulder.ibm.com [9.99.140.44]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f58KA2E256120 for ; Fri, 8 Jun 2001 14:10:02 -0600 Importance: Normal To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Tao Wan" Date: Fri, 8 Jun 2001 13:10:00 -0700 X-MIMETrack: Serialize by Router on D03NM044/03/M/IBM(Release 5.0.6 |December 14, 2000) at 06/08/2001 02:10:02 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: about source code of DAV4J Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4990 X-Loop: w3c-dist-auth@w3.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, It seems trouble to access source code of IBM DAV4J. If you happen to have them or know how to get them not through CVS, please send one copy to me or tell me how. Thanks a lot. tao From w3c-dist-auth-request@w3.org Fri Jun 8 17:05:23 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20621 for ; Fri, 8 Jun 2001 17:05:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA08413; Fri, 8 Jun 2001 17:02:49 -0400 (EDT) Resent-Date: Fri, 8 Jun 2001 17:02:49 -0400 (EDT) Resent-Message-Id: <200106082102.RAA08413@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 RAA08393 for ; Fri, 8 Jun 2001 17:02:43 -0400 (EDT) Received: from d06lmsgate-2.uk.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA31200 for ; Fri, 8 Jun 2001 17:02:42 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-2.uk.ibm.com (1.0.0) with ESMTP id VAA180922 for ; Fri, 8 Jun 2001 21:45:59 +0100 Received: from d06mta06.portsmouth.uk.ibm.com (d06mta06_cs0 [9.180.35.4]) by d06relay02.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f58L1c4103214; Fri, 8 Jun 2001 22:01:38 +0100 Received: by d06mta06.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A65.00737BC1 ; Fri, 8 Jun 2001 22:01:23 +0100 X-Lotus-FromDomain: IBMGB To: "Tao Wan" , jamsden@us.ibm.com cc: w3c-dist-auth@w3.org Message-ID: <80256A65.00737AFC.00@d06mta06.portsmouth.uk.ibm.com> Date: Fri, 8 Jun 2001 22:01:06 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: about source code of DAV4J Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4991 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: "Tao Wan" wrote: > It seems trouble to access source code of IBM DAV4J. If you > happen to have them or know how to get them not through CVS, > please send one copy to me or tell me how. Thanks a lot. Tao, I suggest that you contact Jim Amsden (jamsden@us.ibm.com) for questions relating to DAV4J. Regards, Tim From w3c-dist-auth-request@w3.org Tue Jun 12 06:20:32 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11412 for ; Tue, 12 Jun 2001 06:20:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA19031; Tue, 12 Jun 2001 06:13:09 -0400 (EDT) Resent-Date: Tue, 12 Jun 2001 06:13:09 -0400 (EDT) Resent-Message-Id: <200106121013.GAA19031@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 GAA19007 for ; Tue, 12 Jun 2001 06:13:01 -0400 (EDT) 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 GAA23241 for ; Tue, 12 Jun 2001 06:13:02 -0400 Received: (qmail 25485 invoked by uid 0); 12 Jun 2001 10:12:24 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mail10) with SMTP; 12 Jun 2001 10:12:24 -0000 From: "Julian Reschke" To: Date: Tue, 12 Jun 2001 12:12:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: Re: Moving DASL to Experimental Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4992 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I'm looking for other parties that would be interested on working on DASL again. With the current status of the spec I have mainly two problems, both of which apply to the basicsearch grammar: 1) The spec is completely silent about how the grammar engine is supposed to know about data types. For instance, I would suspect that property values for getcontentlength are supposed to be compared as numbers, while getlastmodified need a date comparison. 2) The grammar for accessing properties is not really XML-friendly, which has led to inventions like "DAV:iscollection". Indeed, this so-called "synthetic property" only solves one special case and leaves the rest (lockdiscovery, attributes, deltaV computed properties) untreated. I think DASL needs a grammar which can do "arbitrary" queries into the attributes, so something with the power of XPath would need to be used. In addition, I'm not happy with the language in chapter 3 (discovery of grammars). It mixes namespace prefixes with URI schemes, which is only correct in the very special case of "DAV:" (being a URI scheme and also the prefix used there). Julian From w3c-dist-auth-request@w3.org Tue Jun 12 09:57:08 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15192 for ; Tue, 12 Jun 2001 09:57:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA00100; Tue, 12 Jun 2001 09:50:15 -0400 (EDT) Resent-Date: Tue, 12 Jun 2001 09:50:15 -0400 (EDT) Resent-Message-Id: <200106121350.JAA00100@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 JAA00080 for ; Tue, 12 Jun 2001 09:50:09 -0400 (EDT) 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 JAA11070 for ; Tue, 12 Jun 2001 09:50:09 -0400 Received: (qmail 13412 invoked by uid 0); 12 Jun 2001 13:49:30 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mail07) with SMTP; 12 Jun 2001 13:49:30 -0000 From: "Julian Reschke" To: Date: Tue, 12 Jun 2001 15:49:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: Oracle IFS vs. Microsoft Webfolders Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4993 X-Loop: w3c-dist-auth@w3.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, we just tried to WebDAV-mount an Oracle IFS (1.1) using Microsoft's webfolder client, and failed. Inspection of OPTIONS and PROPFIND responses showed: 1) Oracle IFS only supports DAV class 1, and doesn't return an ALLOW header on OPTIONS, 2) is "getetag_blah" for all resources, 3) It tries to return in RFC format, but uses it's locale for formatting, which obviously will not produce an RNC formatted date when your language isn't english, 4) It tries to return in RFC format (and fails in the same way), while this should be in ISO8601 format, 5) (when not "unknown") is set to language strings like "ENGLISH" (which I think is incorrect according to section 14.13 of [RFC2068]) Did anybody have more luck trying this? Julian From w3c-dist-auth-request@w3.org Tue Jun 12 13:11:06 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19802 for ; Tue, 12 Jun 2001 13:11:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA15580; Tue, 12 Jun 2001 13:04:38 -0400 (EDT) Resent-Date: Tue, 12 Jun 2001 13:04:38 -0400 (EDT) Resent-Message-Id: <200106121704.NAA15580@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 NAA15542 for ; Tue, 12 Jun 2001 13:04:30 -0400 (EDT) Received: from d06lmsgate-3.uk.ibm.com (d06lmsgate-3.uk.ibm.com [195.212.29.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA07305 for ; Tue, 12 Jun 2001 13:04:30 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate-3.uk.ibm.com (1.0.0) with ESMTP id QAA68690 for ; Tue, 12 Jun 2001 16:26:58 +0100 Received: from d06mta06.portsmouth.uk.ibm.com (d06mta06_cs0 [9.180.35.4]) by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5CFYpf81772 for ; Tue, 12 Jun 2001 16:34:51 +0100 Received: by d06mta06.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A69.004E2A30 ; Tue, 12 Jun 2001 15:13:46 +0100 X-Lotus-FromDomain: IBMGB To: "WebDAV WG" Message-ID: <80256A69.004E2767.00@d06mta06.portsmouth.uk.ibm.com> Date: Tue, 12 Jun 2001 14:51:06 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4994 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > 5. Changes for PROPFIND method > > PROPFIND is extended to return the data type information for > properties that satisfy the following conditions: > > o The data type is different from "xs:string". > > o The property's data type is not defined in [RFC2518] or a related > specification. This seems too strict, how about servers MAY excluse the data type attributes where ... > 6. Compatibility Considerations > ... > Servers not aware of this specification either drop the "xsi:type" > attribute, or persist it along with the property value. However, > they will never indicate successfull parsing of the data type by > returning back the type in the response to PROPPATCH. Huh? If it is persisted as an attribute why would the server not return it in PROPFIND? Are you suggesting that aervers should ignore unknown attributes? Apart from that, the proposal seems straight forward enough. Tim From w3c-dist-auth-request@w3.org Tue Jun 12 13:30:55 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20360 for ; Tue, 12 Jun 2001 13:30:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA16884; Tue, 12 Jun 2001 13:24:46 -0400 (EDT) Resent-Date: Tue, 12 Jun 2001 13:24:46 -0400 (EDT) Resent-Message-Id: <200106121724.NAA16884@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 NAA16860 for ; Tue, 12 Jun 2001 13:24:39 -0400 (EDT) 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 NAA10288 for ; Tue, 12 Jun 2001 13:24:39 -0400 Received: (qmail 22049 invoked by uid 0); 12 Jun 2001 17:24:00 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp020-rz3) with SMTP; 12 Jun 2001 17:24:00 -0000 From: "Julian Reschke" To: , "WebDAV WG" Date: Tue, 12 Jun 2001 19:24:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <80256A69.004E2767.00@d06mta06.portsmouth.uk.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: RE: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4995 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Tim_Ellison@uk.ibm.com > Sent: Tuesday, June 12, 2001 3:51 PM > To: WebDAV WG > Subject: RE: Proposal for marshalling property type information Hi Tim, thanks for the feedback. > > 5. Changes for PROPFIND method > > > > PROPFIND is extended to return the data type information for > > properties that satisfy the following conditions: > > > > o The data type is different from "xs:string". > > > > o The property's data type is not defined in [RFC2518] or a related > > specification. > > This seems too strict, how about servers MAY excluse the data type > attributes where ... The idea was to be specific here to avoid "polluting" PROPFIND replies with unnecessary information (as seen, for instance, in IIS). > > 6. Compatibility Considerations > > ... > > Servers not aware of this specification either drop the "xsi:type" > > attribute, or persist it along with the property value. However, > > they will never indicate successfull parsing of the data type by > > returning back the type in the response to PROPPATCH. > > Huh? If it is persisted as an attribute why would the server not > return it > in PROPFIND? > Are you suggesting that aervers should ignore unknown attributes? I think you misread. PROPPATCH, when a datatype was supplied and recognized, is going to report that by adding it to it's response body: "The server should indicate successfull detection and parsing of the typed value by setting the xsi:type attribute on the property element in the response body.". An old server will never do this upon PROPPATCH. So this remark applies to PROPPATCH, not a subsequent PROPFIND. > Apart from that, the proposal seems straight forward enough. Thanks. Do you think it would be worthwhile to extend this for passing arrays (I've got a proposal for using the SOAP encoding ready...)? Julian From w3c-dist-auth-request@w3.org Tue Jun 12 16:17:45 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23854 for ; Tue, 12 Jun 2001 16:17:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA27982; Tue, 12 Jun 2001 16:14:44 -0400 (EDT) Resent-Date: Tue, 12 Jun 2001 16:14:44 -0400 (EDT) Resent-Message-Id: <200106122014.QAA27982@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 QAA27962 for ; Tue, 12 Jun 2001 16:14:38 -0400 (EDT) Received: from hq-exgw2.filenet.com (Filenet-gw.filenet.com [198.3.8.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA28786 for ; Tue, 12 Jun 2001 16:14:37 -0400 Received: by hq-exgw2.filenet.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 13:13:21 -0700 Message-ID: From: "Babich, Alan" To: "'Julian Reschke'" , w3c-dist-auth@w3.org Date: Tue, 12 Jun 2001 13:13:58 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: RE: Moving DASL to Experimental Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4996 X-Loop: w3c-dist-auth@w3.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) DASL is NOT completely silent about how the grammar engine is supposed to know about data types. (2) DASL deliberately punted on querying hierarchical data types, i.e., so called "structured" data types, so that we could get the first draft out in a timely manner. The plan was to address the structured properties on the next draft. If you think about it, that might still be the best approach. Re point (1): By DBMS standards, WebDAV has an inadequate property model. You can not even say that a property has a given data type. In the WebDAV proposal, examples are given wherein a property changes data type (for example, if the name of the property leads you to believe it is a certain data type, say, integer, and a collection doesn't implement it, the collection can return a string that says "not implemented"). WebDAV got away without a rigorous property model until it came time to query, i.e., DASL. At that point one can no longer duck the issue. (For example, even users that are computer illiterate know that "2" comes after "10" if both are strings, but before if both are integers.) Another problem was that at the time DASL was developed, XML lacked the notion of data types, but there was an XML effort underway to introduce data types. So, everyone wanted the XML effort to be the way of introducing data types, rather than getting them in through the back door via DASL, probably in a way that didn't quite track the XML effort due to lack of resources and time. What DASL said about data types is the following. First, you can have a query schema that describes the properties, including their data types. The data types included Boolean, string, int, float, and dateTime. Second, if you don't have a query schema, or if the data type of a property is not given, the property defaults to type string. A literal compared to a property in a query must be coercible to the type of the property. Third, people believed that in 90+% of the applications, knowledge of the properties would be hard wired into the application. Certainly, that would be true for properties defined by DAV, e.g., getcontentlength. That is why the query schema was made optional. Alan Babich -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Tuesday, June 12, 2001 3:12 AM To: w3c-dist-auth@w3.org Subject: Re: Moving DASL to Experimental Hi, I'm looking for other parties that would be interested on working on DASL again. With the current status of the spec I have mainly two problems, both of which apply to the basicsearch grammar: 1) The spec is completely silent about how the grammar engine is supposed to know about data types. For instance, I would suspect that property values for getcontentlength are supposed to be compared as numbers, while getlastmodified need a date comparison. 2) The grammar for accessing properties is not really XML-friendly, which has led to inventions like "DAV:iscollection". Indeed, this so-called "synthetic property" only solves one special case and leaves the rest (lockdiscovery, attributes, deltaV computed properties) untreated. I think DASL needs a grammar which can do "arbitrary" queries into the attributes, so something with the power of XPath would need to be used. In addition, I'm not happy with the language in chapter 3 (discovery of grammars). It mixes namespace prefixes with URI schemes, which is only correct in the very special case of "DAV:" (being a URI scheme and also the prefix used there). Julian From w3c-dist-auth-request@w3.org Wed Jun 13 06:26:44 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18074 for ; Wed, 13 Jun 2001 06:26:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA29806; Wed, 13 Jun 2001 06:24:42 -0400 (EDT) Resent-Date: Wed, 13 Jun 2001 06:24:42 -0400 (EDT) Resent-Message-Id: <200106131024.GAA29806@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 GAA29786 for ; Wed, 13 Jun 2001 06:24:36 -0400 (EDT) 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 GAA29745 for ; Wed, 13 Jun 2001 06:24:36 -0400 Received: (qmail 1413 invoked by uid 0); 13 Jun 2001 10:24:24 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mail01) with SMTP; 13 Jun 2001 10:24:24 -0000 From: "Julian Reschke" To: "Babich, Alan" , Date: Wed, 13 Jun 2001 12:24:24 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Subject: RE: Moving DASL to Experimental Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4997 X-Loop: w3c-dist-auth@w3.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 Alan, first of all: thanks for the feedback. > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Babich, Alan > Sent: Tuesday, June 12, 2001 10:14 PM > To: 'Julian Reschke'; w3c-dist-auth@w3.org > Subject: RE: Moving DASL to Experimental > > > (1) DASL is NOT completely silent about how the grammar engine is > supposed to know about data types. > (2) DASL deliberately punted on querying hierarchical data types, i.e., > so called "structured" data types, so that we could get the first > draft out > in a timely manner. The plan was to address the structured properties > on the next draft. If you think about it, that might still be the best > approach. > > Re point (1): By DBMS standards, WebDAV has an inadequate > property model. You can not even say that a property has a > given data type. In the WebDAV proposal, examples are given wherein Agreed. Some do, some don't. A property "x" may have different types for different resources. And so on... > a property changes data type (for example, if the name of > the property leads you to believe it is a certain data type, say, > integer, and a collection doesn't implement it, the collection can > return a string that says "not implemented"). WebDAV got away without Are you referring to some live property? I don't think this is the case for any property defined in RFC2518. > a rigorous property model until it came time to query, i.e., DASL. At that > point > one can no longer duck the issue. (For example, even users that are > computer illiterate know that "2" comes after "10" if both are > strings, but > before if both are integers.) Another problem was that at the > time DASL was > developed, XML lacked the notion of data types, but there was an XML > effort underway to introduce data types. So, everyone wanted the > XML effort > to be the way of introducing data types, rather than getting them > in through > the back door via DASL, probably in a way that didn't quite track > the XML effort due to lack of resources and time. What you're saying is that there were good reasons for the spec to be silent about these issues. I don't argue with the approach, I just state that it's a problem if you actually want to implement DASL. > What DASL said about data types is the following. First, you can > have a query schema that describes the properties, including their Query schemas were taken out of the spec, right? AFAIK, the "current" one is at , and Query Schemas were taken out because they seemed to be too complex at this point of time. > data types. The data types included Boolean, string, int, float, and > dateTime. Second, if you don't have a query schema, or if the > data type of a property is not given, the property defaults to > type string. > A literal compared to a property in a query must be coercible to the type > of the property. Third, people believed that in 90+% of the applications, > knowledge of the properties would be hard wired into the application. > Certainly, that would be true for properties defined by DAV, e.g., > getcontentlength. That is why the query schema was made optional. (actually it was removed, and I wasn't really aware anymore of Query Schema when I wrote that mail). So some more points (in random order): - with QS being removed, I think it would be good if the spec for DAV:basicsearch would actually define how comparisons are meant to be made (like: the engine may take advantage of type information available for the server's live properties) - maybe, for a comparison on other properties the datatype could be submitted with the query, for instance: 1234 - I think that querying into "structured" properties needs to be handled, especially considering the live properties introduced by ACL and deltaV. XPath still seems to be a good candidate for this. - Is there a server implementing Query schemata? Julian From w3c-dist-auth-request@w3.org Wed Jun 13 15:40:55 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00105 for ; Wed, 13 Jun 2001 15:40:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA28816; Wed, 13 Jun 2001 15:39:25 -0400 (EDT) Resent-Date: Wed, 13 Jun 2001 15:39:25 -0400 (EDT) Resent-Message-Id: <200106131939.PAA28816@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 PAA28792 for ; Wed, 13 Jun 2001 15:39:19 -0400 (EDT) Received: from hq-exgw2.filenet.com (Filenet-gw.filenet.com [198.3.8.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA24041 for ; Wed, 13 Jun 2001 15:39:18 -0400 Received: by hq-exgw2.filenet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 12:38:01 -0700 Message-ID: From: "Babich, Alan" To: "'Julian Reschke'" , w3c-dist-auth@w3.org Date: Wed, 13 Jun 2001 12:38:39 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: RE: Moving DASL to Experimental Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4998 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: It's been a while, and my memory is a little vague, but I assume you're right that query schema discovery was removed in the interests of expediency. Apparently I forgot. --- There are two types of query applications: (1) specific applications where knowledge of the properties are hard wired into the application, and (2) meta applications that are designed to query any repository. The first type of application was expected to predominate, and doesn't need query schema discovery, which was probably why QSD, although optional, was dropped from the first draft and expected to reappear in the second. The argument "Why burden this type of application with something it doesn't need?" applies. The first type of application doesn't seem to have much of a problem with data types on the client or the server. The second type of application, meta application, definitely has a problem on the client, and would definitely benefit from query schema discovery. Without query schema discovery, the second type of application can not check whether the user enters illegal characters into numeric, Boolean, or dateTime properties. In fact, the client can't even display a list of property names for the user to choose from -- the user has to type in the full property names if there is no query schema discovery. With no query schema discovery, the client can not even check for typo's or spelling errors in property names. I would guess that you are most interested in the problems of the second type of application. --- I don't think putting data type information into the query on PROPERTIES is all that useful. After all, the server knows or should know about the data types of the properties it has stored. I think that putting data type information on the LITERALS in the query would be much more useful. (For example, is "123" the integer 123 or the string "123", i.e., what did the client intend?) If data types are put on the literals, then even if the client doesn't know the data type of the property on the server, at least the server will know how to coerce the literal to the correct data type in cases where that is possible. (Some RDBMS's do, in fact, perform such coercions, e.g. Oracle.) The client can force the user choose what data type to enter for literals if it wants to, so the client can know what the user intends for the data type, even without query schema discovery. My suggestion of putting data types on the literals via attributes in the literal XML element was rejected, at least partly because people expected an XML committee to invent data types in XML itself. We, DASL, didn't want to do anything at variance with what that committee would come up with. Furthermore, we didn't think it was feasible to track what they were doing or to tie our schedule to theirs. A significant amount of time has elapsed since then, and I haven't tracked the XML data types effort. So, I don't know what the status of data types in XML is. If XML now has data types for literals, I would use them. If it doesn't, then, you have the same problem we did. --- As far as querying structured properties, I once had a proposal for that based on the fact that no document management repositories that existed at that time stored property values in XML. Any such document repositories would have to have been created after that point in time. Perhaps there are such repositories now. I don't know. Databases and document repositories have been around for a very long time. XML is not a good way to store property values in large document databases. I doubt that an approach to query structured properties that would work on the huge existing base of document repositories as well as any XML based repositories would be based on a query grammar designed only to query XML documents. Keep in mind that a query protocol is a completely different concept than a query language. A query protocol can accommodate any number of query languages plus query-by-filling-in-forms. Note that SQL queries can easily be handled by DASL's basic search protocol. Remember that there is a conceptually large distinction between DASL and the basic search protocol. DASL allows for any number of optional query protocols to be added, and provides for discovering which query protocol is being used. However, all query protocols other than basic search are optional. Everyone has to implement basic search. So basic search should be small, simple, and easy to implement. Thus, basic search can only deal with about "80%" of the problem, and that's OK. Hope this helps. Alan -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Wednesday, June 13, 2001 3:24 AM To: Babich, Alan; w3c-dist-auth@w3.org Subject: RE: Moving DASL to Experimental Alan, first of all: thanks for the feedback. > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Babich, Alan > Sent: Tuesday, June 12, 2001 10:14 PM > To: 'Julian Reschke'; w3c-dist-auth@w3.org > Subject: RE: Moving DASL to Experimental > > > (1) DASL is NOT completely silent about how the grammar engine is > supposed to know about data types. > (2) DASL deliberately punted on querying hierarchical data types, i.e., > so called "structured" data types, so that we could get the first > draft out > in a timely manner. The plan was to address the structured properties > on the next draft. If you think about it, that might still be the best > approach. > > Re point (1): By DBMS standards, WebDAV has an inadequate > property model. You can not even say that a property has a > given data type. In the WebDAV proposal, examples are given wherein Agreed. Some do, some don't. A property "x" may have different types for different resources. And so on... > a property changes data type (for example, if the name of > the property leads you to believe it is a certain data type, say, > integer, and a collection doesn't implement it, the collection can > return a string that says "not implemented"). WebDAV got away without Are you referring to some live property? I don't think this is the case for any property defined in RFC2518. > a rigorous property model until it came time to query, i.e., DASL. At that > point > one can no longer duck the issue. (For example, even users that are > computer illiterate know that "2" comes after "10" if both are > strings, but > before if both are integers.) Another problem was that at the > time DASL was > developed, XML lacked the notion of data types, but there was an XML > effort underway to introduce data types. So, everyone wanted the > XML effort > to be the way of introducing data types, rather than getting them > in through > the back door via DASL, probably in a way that didn't quite track > the XML effort due to lack of resources and time. What you're saying is that there were good reasons for the spec to be silent about these issues. I don't argue with the approach, I just state that it's a problem if you actually want to implement DASL. > What DASL said about data types is the following. First, you can > have a query schema that describes the properties, including their Query schemas were taken out of the spec, right? AFAIK, the "current" one is at , and Query Schemas were taken out because they seemed to be too complex at this point of time. > data types. The data types included Boolean, string, int, float, and > dateTime. Second, if you don't have a query schema, or if the > data type of a property is not given, the property defaults to > type string. > A literal compared to a property in a query must be coercible to the type > of the property. Third, people believed that in 90+% of the applications, > knowledge of the properties would be hard wired into the application. > Certainly, that would be true for properties defined by DAV, e.g., > getcontentlength. That is why the query schema was made optional. (actually it was removed, and I wasn't really aware anymore of Query Schema when I wrote that mail). So some more points (in random order): - with QS being removed, I think it would be good if the spec for DAV:basicsearch would actually define how comparisons are meant to be made (like: the engine may take advantage of type information available for the server's live properties) - maybe, for a comparison on other properties the datatype could be submitted with the query, for instance: 1234 - I think that querying into "structured" properties needs to be handled, especially considering the live properties introduced by ACL and deltaV. XPath still seems to be a good candidate for this. - Is there a server implementing Query schemata? Julian From w3c-dist-auth-request@w3.org Wed Jun 13 16:01:03 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00574 for ; Wed, 13 Jun 2001 16:01:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA00374; Wed, 13 Jun 2001 16:00:05 -0400 (EDT) Resent-Date: Wed, 13 Jun 2001 16:00:05 -0400 (EDT) Resent-Message-Id: <200106132000.QAA00374@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 PAA00339 for ; Wed, 13 Jun 2001 15:59:58 -0400 (EDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA26304 for ; Wed, 13 Jun 2001 15:59:59 -0400 Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Wed, 13 Jun 2001 20:59:40 +0100 Received: from pldab (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 15AGnX-0002Ai-00; Wed, 13 Jun 2001 20:59:27 +0100 Date: Wed, 13 Jun 2001 20:59:27 +0100 (BST) From: Dan Brickley To: "Babich, Alan" cc: "'Julian Reschke'" , w3c-dist-auth@w3.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: Moving DASL to Experimental Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4999 X-Loop: w3c-dist-auth@w3.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 [snip...] As an aside, you asked about the status of datatypes in XML. The XML Schema spec, which includes a datatypes spec, is now a W3C recommendation. See... http://www.w3.org/XML/ -> http://www.w3.org/XML/Schema -> http://www.w3.org/TR/xmlschema-2/ BTW In the RDFCore WG, we'll be looking at ways of incorporating the XML Schema datatypes into the RDF information model. See WG homepage at http://www.w3.org/2001/sw/RDFCore/ to track this work if you're interested. RDF took a similar view to the one outlined recently here: wait for the XML groups to define some basic datatypes, then figure out how best to use them. Dan From w3c-dist-auth-request@w3.org Thu Jun 14 06:39:04 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24372 for ; Thu, 14 Jun 2001 06:39:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA03878; Thu, 14 Jun 2001 06:34:03 -0400 (EDT) Resent-Date: Thu, 14 Jun 2001 06:34:03 -0400 (EDT) Resent-Message-Id: <200106141034.GAA03878@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 GAA03858 for ; Thu, 14 Jun 2001 06:33:57 -0400 (EDT) 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 GAA02733 for ; Thu, 14 Jun 2001 06:33:56 -0400 Received: (qmail 18436 invoked by uid 0); 14 Jun 2001 10:33:33 -0000 Received: from p3ee2478a.dip.t-dialin.net (HELO lisa) (62.226.71.138) by mail.gmx.net (mail06) with SMTP; 14 Jun 2001 10:33:33 -0000 From: "Julian Reschke" To: "Babich, Alan" , Date: Thu, 14 Jun 2001 12:33:30 +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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: RE: Moving DASL to Experimental Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5000 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Babich, Alan > Sent: Wednesday, June 13, 2001 9:39 PM > To: 'Julian Reschke'; w3c-dist-auth@w3.org > Subject: RE: Moving DASL to Experimental > > (stuff deleted) > > --- > > I don't think putting data type information into the query on > PROPERTIES is > all that useful. After all, the server knows or should know about the data > types of the properties it has stored. I think that putting data type > information on the LITERALS in the query would be much more useful. (For > example, is "123" the integer 123 or the string "123", > i.e., what did the client intend?) If data types are put on the literals, > then even if the client doesn't know the data type of the property on the > server, at least the server will know how to coerce the literal to the > correct data type in cases where that is possible. (Some RDBMS's do, in > fact, perform such coercions, e.g. Oracle.) The client can force the user > choose what data type to enter for literals if it wants to, so the client > can know what the user intends for the data type, even without > query schema > discovery. > > My suggestion of putting data types on the literals via attributes in the > literal XML element was rejected, at least partly because people > expected an > XML committee to invent data types in XML itself. We, DASL, didn't want to > do anything at variance with what that committee would come up with. > Furthermore, we didn't think it was feasible to track what they were doing > or to tie our schedule to theirs. A significant amount of time has elapsed > since then, and I haven't tracked the XML data types effort. So, I don't > know what the status of data types in XML is. If XML now has data > types for > literals, I would use them. If it doesn't, then, you have the same problem > we did. I think that putting datatype information into literals makes sense, and with XML Schema (Part 2 I think) . I recently proposed a method for specifiying data types upon PROPPATCH [1], a similar method could be introduced for basicsearch as well, for instance: 2001-06-14T13:31:00Z As for querying structured properties, I think DASL should rely on the technologies that have been defined for this (XPath). One could even conceive writing the full query as XSLT :-). [1] From w3c-dist-auth-request@w3.org Thu Jun 14 09:57:57 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29567 for ; Thu, 14 Jun 2001 09:57:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA14521; Thu, 14 Jun 2001 09:56:25 -0400 (EDT) Resent-Date: Thu, 14 Jun 2001 09:56:25 -0400 (EDT) Resent-Message-Id: <200106141356.JAA14521@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 JAA14501 for ; Thu, 14 Jun 2001 09:56:18 -0400 (EDT) Received: from d06lmsgate-2.uk.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA23223 for ; Thu, 14 Jun 2001 09:56:15 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-2.uk.ibm.com (1.0.0) with ESMTP id OAA40458 for ; Thu, 14 Jun 2001 14:39:19 +0100 Received: from d06mta06.portsmouth.uk.ibm.com (d06mta06_cs0 [9.180.35.4]) by d06relay02.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5EDsxQ103344 for ; Thu, 14 Jun 2001 14:54:59 +0100 Received: by d06mta06.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A6B.004C6AD4 ; Thu, 14 Jun 2001 14:54:40 +0100 X-Lotus-FromDomain: IBMGB To: "WebDAV WG" Message-ID: <80256A6B.004C5E0B.00@d06mta06.portsmouth.uk.ibm.com> Date: Thu, 14 Jun 2001 14:48:28 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5001 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: "Julian Reschke" wrote: > > > 5. Changes for PROPFIND method ... > > This seems too strict, how about servers MAY exclude > > the data type attributes where ... > > The idea was to be specific here to avoid "polluting" > PROPFIND replies with unnecessary information (as seen, > for instance, in IIS). I understand, however what is pollution to one client is useful information to another. I don't feel strongly about this, but it seems that the type information should be returned in a PROPFIND unless "otherwise negotiated". > > > 6. Compatibility Considerations ... > > Huh? If it is persisted as an attribute why would the > > server not return it in PROPFIND? > > Are you suggesting that aervers should ignore unknown > > attributes? > > I think you misread. Oops, I did misread it, thanks. > PROPPATCH, when a datatype was supplied and recognized, is > going to report that by adding it to it's response body: > > "The server should indicate successfull detection and parsing > of the typed value by setting the xsi:type attribute on the > property element in the response body.". So I presume you are advocating always returning a multistat for a successful PROPPATCH? Then clients can tell that the PROPPATCH succeeded and that the type information was considered. Alternatively, if a server just returned 200 OK that would mean the property values were not validated by type. > An old server will never do this upon PROPPATCH. So this remark > applies to PROPPATCH, not a subsequent PROPFIND. Agreed. My mistake. > Do you think it would be worthwhile to extend this for passing > arrays (I've got a proposal for using the SOAP encoding ready...)? Sure. Tim From w3c-dist-auth-request@w3.org Thu Jun 14 10:19:06 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00326 for ; Thu, 14 Jun 2001 10:19:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA16922; Thu, 14 Jun 2001 10:17:11 -0400 (EDT) Resent-Date: Thu, 14 Jun 2001 10:17:11 -0400 (EDT) Resent-Message-Id: <200106141417.KAA16922@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 KAA16893 for ; Thu, 14 Jun 2001 10:17:02 -0400 (EDT) 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 KAA26200 for ; Thu, 14 Jun 2001 10:17:03 -0400 Received: (qmail 19115 invoked by uid 0); 14 Jun 2001 14:16:25 -0000 Received: from p3ee2478a.dip.t-dialin.net (HELO lisa) (62.226.71.138) by mail.gmx.net (mail10) with SMTP; 14 Jun 2001 14:16:25 -0000 From: "Julian Reschke" To: , "WebDAV WG" Date: Thu, 14 Jun 2001 16:16:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <80256A6B.004C5E0B.00@d06mta06.portsmouth.uk.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: RE: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5002 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Tim_Ellison@uk.ibm.com > Sent: Thursday, June 14, 2001 3:48 PM > To: WebDAV WG > Subject: RE: Proposal for marshalling property type information > > (stuff deleted) > > > > This seems too strict, how about servers MAY exclude > > > the data type attributes where ... > > > > The idea was to be specific here to avoid "polluting" > > PROPFIND replies with unnecessary information (as seen, > > for instance, in IIS). > > I understand, however what is pollution to one client is useful > information > to another. Example? I think it's safe to always suppress xs:string (as a default type). Do you think it would be useful to return types for the second case of server-defined properties? (I think I could live with that). > I don't feel strongly about this, but it seems that the type information > should be returned in a PROPFIND unless "otherwise negotiated". My goal was to keep the protocol change minimal, so I didn't want to introduce a negotiation scheme. > > > > 6. Compatibility Considerations > ... > > > Huh? If it is persisted as an attribute why would the > > > server not return it in PROPFIND? > > > Are you suggesting that aervers should ignore unknown > > > attributes? > > > > I think you misread. > > Oops, I did misread it, thanks. > > > PROPPATCH, when a datatype was supplied and recognized, is > > going to report that by adding it to it's response body: > > > > "The server should indicate successfull detection and parsing > > of the typed value by setting the xsi:type attribute on the > > property element in the response body.". > > So I presume you are advocating always returning a multistat for a > successful PROPPATCH? > Then clients can tell that the PROPPATCH succeeded and that the type > information was considered. > Alternatively, if a server just returned 200 OK that would mean the > property values were not validated by type. Good point. I always thought that a server MUST return on success, but RFC2518 seems to be silent about that. Certainly all examples show a 207. > > An old server will never do this upon PROPPATCH. So this remark > > applies to PROPPATCH, not a subsequent PROPFIND. > > Agreed. My mistake. > > > Do you think it would be worthwhile to extend this for passing > > arrays (I've got a proposal for using the SOAP encoding ready...)? > > Sure. From w3c-dist-auth-request@w3.org Thu Jun 14 11:22:30 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01976 for ; Thu, 14 Jun 2001 11:22:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA25160; Thu, 14 Jun 2001 11:20:47 -0400 (EDT) Resent-Date: Thu, 14 Jun 2001 11:20:47 -0400 (EDT) Resent-Message-Id: <200106141520.LAA25160@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 LAA25140 for ; Thu, 14 Jun 2001 11:20:40 -0400 (EDT) Received: from d06lmsgate-2.uk.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA02446 for ; Thu, 14 Jun 2001 11:20:40 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate-2.uk.ibm.com (1.0.0) with ESMTP id QAA30704 for ; Thu, 14 Jun 2001 16:03:56 +0100 Received: from d06mta06.portsmouth.uk.ibm.com (d06mta06_cs0 [9.180.35.4]) by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5EFJOQ196864 for ; Thu, 14 Jun 2001 16:19:24 +0100 Received: by d06mta06.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A6B.0054285E ; Thu, 14 Jun 2001 16:19:13 +0100 X-Lotus-FromDomain: IBMGB To: "WebDAV WG" Message-ID: <80256A6B.00541D2F.00@d06mta06.portsmouth.uk.ibm.com> Date: Thu, 14 Jun 2001 16:17:57 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5003 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: "Julian Reschke" wrote: > > > > > > The idea was to be specific here to avoid "polluting" > > > PROPFIND replies with unnecessary information (as seen, > > > for instance, in IIS). > > > > I understand, however what is pollution to one client is useful > > information to another. > > Example? Any client retrieving a property whose type is unknown to them would benefit. For example, if a RFC2518 (but not DeltaV) aware client retrieved a DeltaV property it seems unfair that the client was not told of its data type simply because "the property's data type is defined in [RFC2518] or a related specification." It does not make clients forward compatible with those future specifications. > I think it's safe to always suppress xs:string (as a default type). Agreed, there is a default. > Do you think it would be useful to return types for the second > case of server-defined properties? (I think I could live with that). Yes. For clients that are expecting a known type the information will be redundant. > > I don't feel strongly about this, but it seems that the type information > > should be returned in a PROPFIND unless "otherwise negotiated". > > My goal was to keep the protocol change minimal, so I didn't want to > introduce a negotiation scheme. You don't have to specify the negotiation, and there are examples of this approach in DeltaV error reporting. > > So I presume you are advocating always returning a multistat for a > > successful PROPPATCH? > > Then clients can tell that the PROPPATCH succeeded and that the type > > information was considered. > > Alternatively, if a server just returned 200 OK that would mean the > > property values were not validated by type. > > Good point. I always thought that a server MUST return > on success, but RFC2518 seems to be silent about that. Certainly all > examples show a 207. It was generally agreed on this list a while back that total success may be condensed to a simple 200 OK response. Your suggestion would require a further modification to these servers. Tim From w3c-dist-auth-request@w3.org Thu Jun 14 11:40:11 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02428 for ; Thu, 14 Jun 2001 11:40:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA28457; Thu, 14 Jun 2001 11:36:45 -0400 (EDT) Resent-Date: Thu, 14 Jun 2001 11:36:45 -0400 (EDT) Resent-Message-Id: <200106141536.LAA28457@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 LAA28355 for ; Thu, 14 Jun 2001 11:36:30 -0400 (EDT) Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA04454 for ; Thu, 14 Jun 2001 11:36:22 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.99.140.22]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA53980 for ; Thu, 14 Jun 2001 11:28:34 -0400 Received: from f3n44e (d03nm044h.boulder.ibm.com [9.99.140.44]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f5EFaKn47552 for ; Thu, 14 Jun 2001 09:36:20 -0600 Importance: Normal To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Tao Wan" Date: Thu, 14 Jun 2001 08:36:12 -0700 X-MIMETrack: Serialize by Router on D03NM044/03/M/IBM(Release 5.0.6 |December 14, 2000) at 06/14/2001 09:36:20 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: what is lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5005 X-Loop: w3c-dist-auth@w3.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 read the RFC2518 and not sure what is lock-null resource for. could you please give me a example to explain its purpose or function. Thanks tao From w3c-dist-auth-request@w3.org Thu Jun 14 11:40:15 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02441 for ; Thu, 14 Jun 2001 11:40:14 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA28198; Thu, 14 Jun 2001 11:35:48 -0400 (EDT) Resent-Date: Thu, 14 Jun 2001 11:35:48 -0400 (EDT) Resent-Message-Id: <200106141535.LAA28198@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 LAA28160 for ; Thu, 14 Jun 2001 11:35:39 -0400 (EDT) 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 LAA04311 for ; Thu, 14 Jun 2001 11:35:31 -0400 Received: (qmail 31321 invoked by uid 0); 14 Jun 2001 15:34:59 -0000 Received: from p3ee2478a.dip.t-dialin.net (HELO lisa) (62.226.71.138) by mail.gmx.net (mp003-rz3) with SMTP; 14 Jun 2001 15:34:59 -0000 From: "Julian Reschke" To: , "WebDAV WG" Date: Thu, 14 Jun 2001 17:34:57 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <80256A6B.00541D2F.00@d06mta06.portsmouth.uk.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: RE: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5004 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Tim_Ellison@uk.ibm.com > Sent: Thursday, June 14, 2001 5:18 PM > To: WebDAV WG > Subject: RE: Proposal for marshalling property type information > > > > > "Julian Reschke" wrote: > > > > > > > > The idea was to be specific here to avoid "polluting" > > > > PROPFIND replies with unnecessary information (as seen, > > > > for instance, in IIS). > > > > > > I understand, however what is pollution to one client is useful > > > information to another. > > > > Example? > > Any client retrieving a property whose type is unknown to them would > benefit. For example, if a RFC2518 (but not DeltaV) aware client retrieved > a DeltaV property it seems unfair that the client was not told of its data > type simply because "the property's data type is defined in [RFC2518] or a > related specification." It does not make clients forward compatible with > those future specifications. Understood. So would it possibly make sense to to change the wording to "he property's data type is defined in [RFC2518]" (leaving other specifications out)? I still think we don't need to return the types for RFC2518 defined properties... > (stuff deleted) > > > Good point. I always thought that a server MUST return > > on success, but RFC2518 seems to be silent about that. Certainly all > > examples show a 207. > > It was generally agreed on this list a while back that total > success may be > condensed to a simple 200 OK response. Your suggestion would require a > further modification to these servers. I see. Maybe this should be put onto the issues list then (for resolution in RFC2518). Do you think it would be a problem to require the 207 response in this case? From w3c-dist-auth-request@w3.org Thu Jun 14 11:59:23 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02950 for ; Thu, 14 Jun 2001 11:59:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA01322; Thu, 14 Jun 2001 11:58:31 -0400 (EDT) Resent-Date: Thu, 14 Jun 2001 11:58:31 -0400 (EDT) Resent-Message-Id: <200106141558.LAA01322@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 LAA01236 for ; Thu, 14 Jun 2001 11:58:16 -0400 (EDT) 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 LAA06748 for ; Thu, 14 Jun 2001 11:58:16 -0400 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 IAA11449 for ; Thu, 14 Jun 2001 08:58:10 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Thu, 14 Jun 2001 08:55:55 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: what is lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5006 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Accidentally caught by the spam filter. I've added mike.evans@glowebs.com to the accept2 list, so future email from this address will go through to the list. - Jim -----Original Message----- From: Dr. Michael Evans [mailto:mike.evans@glowebs.com] Sent: Thursday, June 14, 2001 8:54 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] RE: what is lock-null resource >> I read the RFC2518 and not sure what is lock-null resource for. >> could you please give me a example to explain its purpose or >>function. Tao, A null resource is defined as “…a resource which responds with a 404 (Not Found) to any HTTP/1.1 or DAV method except for PUT, MKCOL, OPTIONS and LOCK”. In other words, a null resource is one that does not physically exist on the server, but whose URL does. Locking a null resource has the effect of reserving the URL. In this way, a write-locked null resource (or lock-null resource) ensures that no other user can use the specified URL until it is unlocked. Cheers, Mike -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Tao Wan Sent: 14 June 2001 16:36 To: w3c-dist-auth@w3.org Subject: what is lock-null resource Hi, I read the RFC2518 and not sure what is lock-null resource for. could you please give me a example to explain its purpose or function. Thanks tao From w3c-dist-auth-request@w3.org Thu Jun 14 12:57:25 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04090 for ; Thu, 14 Jun 2001 12:57:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA06789; Thu, 14 Jun 2001 12:56:37 -0400 (EDT) Resent-Date: Thu, 14 Jun 2001 12:56:37 -0400 (EDT) Resent-Message-Id: <200106141656.MAA06789@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 MAA06730 for ; Thu, 14 Jun 2001 12:56:23 -0400 (EDT) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA13657 for ; Thu, 14 Jun 2001 12:56:18 -0400 Received: from [216.36.75.57] (HELO beaver) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.7) with SMTP id 489865 for w3c-dist-auth@w3c.org; Thu, 14 Jun 2001 09:53:44 -0700 From: "Lisa Dusseault" To: "Webdav WG" Date: Thu, 14 Jun 2001 09:54:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5007 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit RFC 2518 seems to want 200 OK for the response to a LOCK request. However, that means clients can't tell the difference between a lock of an existing resource and the creation of a LOCK-null resource. Shouldn't 201 Created be returned if a lock-null resource is created? lisa From w3c-dist-auth-request@w3.org Thu Jun 14 15:24:40 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08240 for ; Thu, 14 Jun 2001 15:24:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA21360; Thu, 14 Jun 2001 15:23:07 -0400 (EDT) Resent-Date: Thu, 14 Jun 2001 15:23:07 -0400 (EDT) Resent-Message-Id: <200106141923.PAA21360@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 PAA21336 for ; Thu, 14 Jun 2001 15:23:00 -0400 (EDT) Received: from gits.giti.waseda.ac.jp (IDENT:root@purple.gits.waseda.ac.jp [133.9.168.144]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA30999 for ; Thu, 14 Jun 2001 15:23:00 -0400 Received: from dsch ([133.9.168.151]) by gits.giti.waseda.ac.jp (8.9.3+3.2W/3.7W1.0) with SMTP id EAA10913 for ; Fri, 15 Jun 2001 04:22:58 +0900 Date: Fri, 15 Jun 2001 04:24:31 +0900 From: TAKEYAMA Jumpei To: w3c-dist-auth@w3.org Message-Id: <3B290F6F284.8D48TAKEYAMA@mail.gits.giti.waseda.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver 1.26.05 Subject: questions about WebDAV methods Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5008 X-Loop: w3c-dist-auth@w3.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: I am new to this list and I would like to ask some questions. 1. Is there any way to apply any kinds of WebDAV methods, such as PROPFIND, LOCK, etc., to a specific part of the content, for example, a specific node in an xml document? 2. If there are no such ways available, have there ever been a discussion about nearly related topic? I'm very sorry for my bad English. Hope to hear from you soon. Thanks a lot! Yours Jumpei Takeyama t00a1452@mn.waseda.ac.jp From w3c-dist-auth-request@w3.org Fri Jun 15 05:24:15 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02063 for ; Fri, 15 Jun 2001 05:24:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA20132; Fri, 15 Jun 2001 05:16:49 -0400 (EDT) Resent-Date: Fri, 15 Jun 2001 05:16:49 -0400 (EDT) Resent-Message-Id: <200106150916.FAA20132@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 FAA20093 for ; Fri, 15 Jun 2001 05:16:31 -0400 (EDT) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA02335 for ; Fri, 15 Jun 2001 05:16:28 -0400 Received: from eurodns4.eur.xerox.com (eurodns4.eur.xerox.com [13.202.66.50]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id KAA14580 for ; Fri, 15 Jun 2001 10:16:16 +0100 (BST) Received: from eur.xerox.com (eurdubmg02.eur.xerox.com [13.202.65.254]) by eurodns4.eur.xerox.com (8.9.3/8.9.3) with ESMTP id KAA07854 for ; Fri, 15 Jun 2001 10:16:12 +0100 (BST) Received: from eurgbrbh01.emeacinops.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 15 Jun 2001 10:15:37 +0100 Received: by eurgbrbh01.eur.xerox.com with Internet Mail Service (5.5.2651.58) id ; Fri, 15 Jun 2001 10:16:09 +0100 Received: from eur.xerox.com (eurdubmg02.eur.xerox.com [13.202.65.254]) by eurgbrbh01.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id L7G4LJGS; Fri, 15 Jun 2001 10:16:03 +0100 Received: from gbrwgcbh01.wgc.gbr.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 15 Jun 2001 10:15:28 +0100 Received: by gbrwgcbh01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Jun 2001 10:16:03 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB77672875BE@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: "'Lisa Dusseault'" Cc: "'W3C WebDAV Mailing List'" Date: Fri, 15 Jun 2001 10:15:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5009 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Granted a client cannot tell the difference as you state *if* they took no preceding action. However, I don't think the spec should be changed: 1) Obviously it would go against the definition in RFC 2616 for 201 Created. 2) You haven't actually created a resource. An LNR doesn't physically exist, you've only reserved the "name". You have created a lock, but that is not the same thing. 3) Doesn't make sense to me to get a "201 Created" response for a successful LNR, then if you tried to DELETE or GET it for example, get a 404 or 405 (as per RFC 2518 sec 7.4). 4) Might break existing applications etc. Alternatively, a client could perform one of a number of actions to discover that the resource didn't exist before they attempt to LOCK it (create the LNR) and get a 404. Side notes - results when creating an LNR with: 5) mod_dav pre v1.0 (think v0.9.16) returns a 200 OK response. 6) IIS 5.0 (on Win2K) returns a 201 Created response. Regards Shaun Hall Xerox Europe > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: 14 June 2001 17:54 > To: Webdav WG > Subject: Status code for creating lock-null resource > > > > RFC 2518 seems to want 200 OK for the response to a LOCK > request. However, > that means clients can't tell the difference between a lock > of an existing > resource and the creation of a LOCK-null resource. Shouldn't > 201 Created be > returned if a lock-null resource is created? > > lisa > From w3c-dist-auth-request@w3.org Fri Jun 15 06:13:46 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02476 for ; Fri, 15 Jun 2001 06:13:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA24348; Fri, 15 Jun 2001 06:06:02 -0400 (EDT) Resent-Date: Fri, 15 Jun 2001 06:06:02 -0400 (EDT) Resent-Message-Id: <200106151006.GAA24348@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 GAA24254 for ; Fri, 15 Jun 2001 06:05:43 -0400 (EDT) Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA06450 for ; Fri, 15 Jun 2001 06:05:43 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id KAA176548 for ; Fri, 15 Jun 2001 10:47:14 +0100 Received: from d06mta06.portsmouth.uk.ibm.com (d06mta06_cs0 [9.180.35.4]) by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5FA4VJ70828 for ; Fri, 15 Jun 2001 11:04:32 +0100 Received: by d06mta06.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A6C.0037556A ; Fri, 15 Jun 2001 11:04:23 +0100 X-Lotus-FromDomain: IBMGB To: "WebDAV WG" Message-ID: <80256A6C.0037470F.00@d06mta06.portsmouth.uk.ibm.com> Date: Fri, 15 Jun 2001 11:04:33 +0100 Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=SXO7A12PiXxfgrtTccVMfSXPecXMZ8Sk7RCoKF9dMeueHGtwEsIUu8qX" Content-Disposition: inline Subject: RE: what is lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5011 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=SXO7A12PiXxfgrtTccVMfSXPecXMZ8Sk7RCoKF9dMeueHGtwEsIUu8qX Content-type: text/plain; charset=us-ascii Content-Disposition: inline "Dr. Michael Evans" wrote: > A null resource is defined as a resource which responds > with a 404 (Not Found) to any HTTP/1.1 or DAV method except > for PUT, MKCOL, OPTIONS and LOCK --0__=SXO7A12PiXxfgrtTccVMfSXPecXMZ8Sk7RCoKF9dMeueHGtwEsIUu8qX Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =F6 and UNLOCK. > In other words, a null resource is one that does not physically > exist on the server, but whose URL does. I can't let that sentence go . The protocol does not state which resources physically exist and which = do not, that is the perogative of the server implementation. Given that t= he lock null resource has all the mandatory DAV properties I would imagine= that many server implementations _would_ have to 'physically' persist a= lock null resource. As for the URL physically existing, "As far as HTTP is concerned, Unifo= rm Resource Identifiers are simply formatted strings which identify--via n= ame, location, or any other characteristic--a resource." [RFC2616] > Locking a null resource has the effect of reserving the URL. > In this way, a write-locked null resource (or lock-null > resource) ensures that no other user can use the specified > URL until it is unlocked. Tim = --0__=SXO7A12PiXxfgrtTccVMfSXPecXMZ8Sk7RCoKF9dMeueHGtwEsIUu8qX-- From w3c-dist-auth-request@w3.org Fri Jun 15 06:16:36 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02489 for ; Fri, 15 Jun 2001 06:16:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA24274; Fri, 15 Jun 2001 06:05:49 -0400 (EDT) Resent-Date: Fri, 15 Jun 2001 06:05:49 -0400 (EDT) Resent-Message-Id: <200106151005.GAA24274@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 GAA24242 for ; Fri, 15 Jun 2001 06:05:41 -0400 (EDT) Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA06448 for ; Fri, 15 Jun 2001 06:05:40 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id KAA138372 for ; Fri, 15 Jun 2001 10:47:08 +0100 Received: from d06mta06.portsmouth.uk.ibm.com (d06mta06_cs0 [9.180.35.4]) by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5FA4QJ179812 for ; Fri, 15 Jun 2001 11:04:26 +0100 Received: by d06mta06.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A6C.00375461 ; Fri, 15 Jun 2001 11:04:20 +0100 X-Lotus-FromDomain: IBMGB To: w3c-dist-auth@w3.org Message-ID: <80256A6C.003745FE.00@d06mta06.portsmouth.uk.ibm.com> Date: Fri, 15 Jun 2001 09:50:40 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: questions about WebDAV methods Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5010 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: TAKEYAMA Jumpei wrote: > I am new to this list and I would like to ask some questions. > 1. Is there any way to apply any kinds of WebDAV methods, such as > PROPFIND, LOCK, etc., to a specific part of the content, for example, > a specific node in an xml document? No, all the methods apply to an entire resource. > 2. If there are no such ways available, have there ever been a > discussion about nearly related topic? Not to my knowledge. > I'm very sorry for my bad English. It's better than my Japanese! Tim From w3c-dist-auth-request@w3.org Fri Jun 15 06:42:27 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02586 for ; Fri, 15 Jun 2001 06:42:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA26733; Fri, 15 Jun 2001 06:38:57 -0400 (EDT) Resent-Date: Fri, 15 Jun 2001 06:38:57 -0400 (EDT) Resent-Message-Id: <200106151038.GAA26733@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 GAA26680 for ; Fri, 15 Jun 2001 06:38:46 -0400 (EDT) Received: from mailgate.excosoft.se (mailgate.excosoft.se [193.15.188.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA08799 for ; Fri, 15 Jun 2001 06:38:46 -0400 Received: from julio ([192.9.200.127]) by mailgate.excosoft.se (8.9.3/8.9.3) with SMTP id MAA00905; Fri, 15 Jun 2001 12:38:42 +0200 (MET DST) From: "Peter Pierrou" To: , Date: Fri, 15 Jun 2001 12:38:44 +0200 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.00.2314.1300 In-Reply-To: <80256A6C.003745FE.00@d06mta06.portsmouth.uk.ibm.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id GAA26680 Subject: RE: questions about WebDAV methods Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5012 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > TAKEYAMA Jumpei wrote: > > > I am new to this list and I would like to ask some questions. > > 1. Is there any way to apply any kinds of WebDAV methods, such as > > PROPFIND, LOCK, etc., to a specific part of the content, for example, > > a specific node in an xml document? > > No, all the methods apply to an entire resource. Would it not be possible, if the server supports it, to map a part of an XML document with the URL, by using xpointer as an example? http://server/files/file.xml/descendant(1, 'paragraph') If the server can handle a lock on a part of a document that would make sense. Peter Pierrou From w3c-dist-auth-request@w3.org Fri Jun 15 07:21:19 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03211 for ; Fri, 15 Jun 2001 07:21:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA00510; Fri, 15 Jun 2001 07:19:44 -0400 (EDT) Resent-Date: Fri, 15 Jun 2001 07:19:44 -0400 (EDT) Resent-Message-Id: <200106151119.HAA00510@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 HAA00490 for ; Fri, 15 Jun 2001 07:19:37 -0400 (EDT) Received: from d06lmsgate-3.uk.ibm.com (d06lmsgate-3.uk.ibm.com [195.212.29.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA12038 for ; Fri, 15 Jun 2001 07:19:37 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-3.uk.ibm.com (1.0.0) with ESMTP id MAA92884 for ; Fri, 15 Jun 2001 12:10:02 +0100 Received: from d06mta06.portsmouth.uk.ibm.com (d06mta06_cs0 [9.180.35.4]) by d06relay02.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5FBIbB94286 for ; Fri, 15 Jun 2001 12:18:37 +0100 Received: by d06mta06.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A6C.003E1A87 ; Fri, 15 Jun 2001 12:18:20 +0100 X-Lotus-FromDomain: IBMGB To: "'W3C WebDAV Mailing List'" Message-ID: <80256A6C.003D4A67.00@d06mta06.portsmouth.uk.ibm.com> Date: Fri, 15 Jun 2001 12:03:56 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5013 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: "Hall, Shaun" wrote: > 1) Obviously it would go against the definition in > RFC 2616 for 201 Created. > 2) You haven't actually created a resource. An LNR doesn't > physically exist, you've only reserved the "name". You have > created a lock, but that is not the same thing. Arrgh, where did this idea that a resource must "physically exist" come from?? In what sense does http://foo.com/cgi-bin/quote?myportfolio,yesterday (or whatever) 'physically exist'? A 201 Created response looks like the ideal response for the creation of a lock-null resource. I did not read anything in RFC2616 to contradict that. > 3) Doesn't make sense to me to get a "201 Created" response > for a successful LNR, then if you tried to DELETE or GET it > for example, get a 404 or 405 (as per RFC 2518 sec 7.4). > 4) Might break existing applications etc. > > Alternatively, a client could perform one of a number of > actions to discover that the resource didn't exist before > they attempt to LOCK it (create the LNR) and get a 404. Lock-null resources are generally bad and should have been strangled at birth. > Side notes - results when creating an LNR with: > > 5) mod_dav pre v1.0 (think v0.9.16) returns a 200 OK response. > 6) IIS 5.0 (on Win2K) returns a 201 Created response. Tim From w3c-dist-auth-request@w3.org Fri Jun 15 08:09:59 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04534 for ; Fri, 15 Jun 2001 08:09:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA05751; Fri, 15 Jun 2001 08:07:10 -0400 (EDT) Resent-Date: Fri, 15 Jun 2001 08:07:10 -0400 (EDT) Resent-Message-Id: <200106151207.IAA05751@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 IAA05675 for ; Fri, 15 Jun 2001 08:06:56 -0400 (EDT) Received: from d06lmsgate-3.uk.ibm.com (d06lmsgate-3.uk.ibm.com [195.212.29.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA17096 for ; Fri, 15 Jun 2001 08:06:56 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-3.uk.ibm.com (1.0.0) with ESMTP id MAA79432 for ; Fri, 15 Jun 2001 12:56:31 +0100 Received: from d06mta06.portsmouth.uk.ibm.com (d06mta06_cs0 [9.180.35.4]) by d06relay02.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5FC4mB228438 for ; Fri, 15 Jun 2001 13:04:49 +0100 Received: by d06mta06.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A6C.004252CC ; Fri, 15 Jun 2001 13:04:25 +0100 X-Lotus-FromDomain: IBMGB To: "WebDAV WG" Message-ID: <80256A6C.00425118.00@d06mta06.portsmouth.uk.ibm.com> Date: Fri, 15 Jun 2001 13:05:12 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5014 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: "Julian Reschke" wrote: > Understood. So would it possibly make sense to to change > the wording to "he property's data type is defined in [RFC2518]" > (leaving other specifications out)? I still think we don't > need to return the types for RFC2518 defined properties... The RFC2518 defined properties are: creationdate displayname getcontentlanguage getcontentlength getcontenttype getetag getlastmodified lockdiscovery resourcetype source supportedlock So the only ones that I believe would return type info (using the xs:string - exclusion rule) are creationdate -> dateTime getContentLength -> nonNegativeInteger getLastModified -> dateTime So although I don't think it would be a great overhead for servers to return these each time, I don't really care either way. > > It was generally agreed on this list a while back that total > > success may be condensed to a simple 200 OK response. Your > > suggestion would require a further modification to these servers. > > I see. Maybe this should be put onto the issues list then (for > resolution in RFC2518). What is the issue? I don't think that there is any great harm to interop if some servers respond with 200OK and others return 207MultiStatus with 200OK for each response. > Do you think it would be a problem to require the 207 > response in this case? You may get pushback from some server writers. Tim From w3c-dist-auth-request@w3.org Fri Jun 15 09:54:47 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08364 for ; Fri, 15 Jun 2001 09:54:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA17897; Fri, 15 Jun 2001 09:53:05 -0400 (EDT) Resent-Date: Fri, 15 Jun 2001 09:53:05 -0400 (EDT) Resent-Message-Id: <200106151353.JAA17897@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 JAA17872 for ; Fri, 15 Jun 2001 09:52:50 -0400 (EDT) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA30227 for ; Fri, 15 Jun 2001 09:52:40 -0400 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id OAA08750 for ; Fri, 15 Jun 2001 14:52:36 +0100 (BST) Received: from eur.xerox.com (eurdubmg04.eur.xerox.com [13.202.66.61]) by eurodns2.eur.xerox.com (8.9.3/8.9.3) with ESMTP id OAA13068 for ; Fri, 15 Jun 2001 14:52:36 +0100 (BST) Received: from eurgbrbh01.emeacinops.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 15 Jun 2001 14:47:11 +0100 Received: by eurgbrbh01.eur.xerox.com with Internet Mail Service (5.5.2651.58) id ; Fri, 15 Jun 2001 14:38:50 +0100 Received: from [13.202.66.60] (eurdubmg03.eur.xerox.com [13.202.66.60]) by eurgbrbh01.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id L7G4M1L3; Fri, 15 Jun 2001 14:38:46 +0100 Received: from gbrwgcbh01.wgc.gbr.xerox.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 15 Jun 2001 14:33:28 +0100 Received: by gbrwgcbh01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Jun 2001 14:25:35 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB77672875BF@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: "'Tim_Ellison@uk.ibm.com'" , "'W3C WebDAV Mailing List'" Date: Fri, 15 Jun 2001 14:25:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5015 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > -----Original Message----- > From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com] > Sent: 15 June 2001 12:04 > To: 'W3C WebDAV Mailing List' > Subject: RE: Status code for creating lock-null resource > > "Hall, Shaun" wrote: > > 1) Obviously it would go against the definition in > > RFC 2616 for 201 Created. > > 2) You haven't actually created a resource. An LNR doesn't > > physically exist, you've only reserved the "name". You have > > created a lock, but that is not the same thing. > > Arrgh, where did this idea that a resource must "physically > exist" come > from?? I meant they have no entity body unlike "normal" resources. I realise servers may use a file to internally represent an LNR. > > In what sense does > http://foo.com/cgi-bin/quote?> myportfolio,yesterday (or > > whatever) 'physically exist'? > > A > 201 Created response looks like the ideal response for the > creation of a > lock-null resource. I did not read anything in RFC2616 to > contradict that. > [snipped] Disagree with 201, you haven't created a resource in the normal sense. You cannot do a GET on an LNR for example. RFC 2616 sec 10.2.2 states "... a new resource being created". You haven't created a new resource per se, but reserved a name. You have created a lock, which is state. Okay, somehow the server has to "create and store" properties for the LNR, but there is no actual "entity body" and never will be unless a PUT is performed. > > Lock-null resources are generally bad and should have been > strangled at > birth. See point 4) below. [snipped] Let us remind ourselves about a few things here (in conjunction with null resource emails): 1) Locking's purpose it to avoid conflict, the lost update problem etc (RFC 2518 sec 6). 2) A null resource MUST NOT appear as a member of its parent collection (RFC 2518 sec 3). 3) A null resource MUST respond with a 404 for ALL methods other than PUT, MKCOL, OPTIONS and LOCK (RFC 2518 sec 3). 4) Lock null resources (LNRs) are there to reserve name (RFC2518 sec 7.4). They are there so a client can reserve the name *before they create the resource* (store the "entity"). Admittedly, a server may use a file to represent the LNR, but thats an implementation detail. Since the name is reserved, it avoids potential conflict when the entity is actually stored e.g. with a PUT. 5) Methods performed on LNRs other than PUT, MKCOL, OPTIONS, PROPFIND, LOCK and UNLOCK MUST respond with a 404 or 405 (RFC 2518 sec 7.4). 6) If you UNLOCK an LNR, the resource is returned to the null resource state (RFC 2518 sec 7.4). This may mean a server actually deletes the "file" it used to represent the LNR, but thats another implementation detail. The client should assume nothing about how the server implements the protocol, in these cases, null resources and LNRs. A few people interpret 2) and 3) to mean that a null resource doesn't physically exist, which IMHO is convenient. As far as the client is concerned, a null resource doesn't exist as per 3), and an LNR doesn't exist as per 5). Regards Shaun Hall Xerox Europe From w3c-dist-auth-request@w3.org Fri Jun 15 10:19:44 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09771 for ; Fri, 15 Jun 2001 10:19:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA20541; Fri, 15 Jun 2001 10:18:27 -0400 (EDT) Resent-Date: Fri, 15 Jun 2001 10:18:27 -0400 (EDT) Resent-Message-Id: <200106151418.KAA20541@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 KAA20516 for ; Fri, 15 Jun 2001 10:18:20 -0400 (EDT) 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 KAA01623 for ; Fri, 15 Jun 2001 10:18:20 -0400 Received: (qmail 21887 invoked by uid 0); 15 Jun 2001 14:17:45 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mail09) with SMTP; 15 Jun 2001 14:17:45 -0000 From: "Julian Reschke" To: , "WebDAV WG" Date: Fri, 15 Jun 2001 16:17:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-reply-to: <80256A6C.00425118.00@d06mta06.portsmouth.uk.ibm.com> Subject: RE: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5016 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Tim_Ellison@uk.ibm.com > Sent: Friday, June 15, 2001 2:05 PM > To: WebDAV WG > Subject: RE: Proposal for marshalling property type information > > > > > "Julian Reschke" wrote: > > > Understood. So would it possibly make sense to to change > > the wording to "he property's data type is defined in [RFC2518]" > > (leaving other specifications out)? I still think we don't > > need to return the types for RFC2518 defined properties... > > The RFC2518 defined properties are: > creationdate > displayname > getcontentlanguage > getcontentlength > getcontenttype > getetag > getlastmodified > lockdiscovery > resourcetype > source > supportedlock > > So the only ones that I believe would return type info (using the > xs:string > - exclusion rule) are > creationdate -> dateTime > getContentLength -> nonNegativeInteger > getLastModified -> dateTime Tim, thanks for the summary. Now I'm tempted to agree that these should be returned. A minor issue is with DAV:getlastmodified, because it's format isn't xs:dateTime, meaning that we have to define a datatype for it in the spec. That's why I'd still prefer to leave them out. > So although I don't think it would be a great overhead for servers to > return these each time, I don't really care either way. > > > > It was generally agreed on this list a while back that total > > > success may be condensed to a simple 200 OK response. Your > > > suggestion would require a further modification to these servers. > > > > I see. Maybe this should be put onto the issues list then (for > > resolution in RFC2518). > > What is the issue? I don't think that there is any great harm to > interop if > some servers respond with 200OK and others return 207MultiStatus > with 200OK > for each response. The issue is that after reading the spec (and tracing IIS), authors of client software might think that they'll always get a 207 which apparently isn't the case (so I think this should be clarified). > > Do you think it would be a problem to require the 207 > > response in this case? > > You may get pushback from some server writers. Well, unless somebody suggests a better approach, I'll have to live with that. From w3c-dist-auth-request@w3.org Fri Jun 15 10:31:39 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10469 for ; Fri, 15 Jun 2001 10:31:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA22234; Fri, 15 Jun 2001 10:30:43 -0400 (EDT) Resent-Date: Fri, 15 Jun 2001 10:30:43 -0400 (EDT) Resent-Message-Id: <200106151430.KAA22234@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 KAA22208 for ; Fri, 15 Jun 2001 10:30:35 -0400 (EDT) Received: from mail.glowebs.com ([62.189.24.210]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA03421 for ; Fri, 15 Jun 2001 10:30:34 -0400 Received: from [192.168.100.55] by mail.glowebs.com (NTMail 4.30.0012/NY3127.00.c05462f3) with ESMTP id cuoiaaaa for ; Fri, 15 Jun 2001 15:12:11 +0100 From: "Dr Michael Evans" To: "'W3C WebDAV Mailing List'" Date: Fri, 15 Jun 2001 15:36:02 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <59697CCC6CE3D411B4CD00805FBB77672875BF@gbrwgcms03.wgc.gbr.xerox.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5017 X-Loop: w3c-dist-auth@w3.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 >> Arrgh, where did this idea that a resource must "physically >> exist" come >> from?? [snip] > A few people interpret 2) and 3) to mean that a null resource doesn't > physically exist, which IMHO is convenient. Convenience was certainly my intention. Shaun's perfectly described the sense in which I originally meant 'physically exist'. Given that the original question to which I replied asked what a locked-null resource was for, and if an example could be given, it seemed the most appropriate phrase to use. Mike Evans From w3c-dist-auth-request@w3.org Fri Jun 15 10:54:47 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11023 for ; Fri, 15 Jun 2001 10:54:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA24623; Fri, 15 Jun 2001 10:50:29 -0400 (EDT) Resent-Date: Fri, 15 Jun 2001 10:50:29 -0400 (EDT) Resent-Message-Id: <200106151450.KAA24623@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 KAA24595 for ; Fri, 15 Jun 2001 10:50:21 -0400 (EDT) Received: from d06lmsgate-2.uk.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA06196 for ; Fri, 15 Jun 2001 10:49:53 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-2.uk.ibm.com (1.0.0) with ESMTP id PAA24278; Fri, 15 Jun 2001 15:31:08 +0100 Received: from d06mta06.portsmouth.uk.ibm.com (d06mta06_cs0 [9.180.35.4]) by d06relay02.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5FEkXB202444; Fri, 15 Jun 2001 15:46:33 +0100 Received: by d06mta06.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A6C.0051216F ; Fri, 15 Jun 2001 15:46:09 +0100 X-Lotus-FromDomain: IBMGB To: "'W3C WebDAV Mailing List'" cc: "Jim Whitehead" Message-ID: <80256A6C.00511124.00@d06mta06.portsmouth.uk.ibm.com> Date: Fri, 15 Jun 2001 15:46:02 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5018 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Lock nulls don't deserve the effort of the debate , but I know that Shaun is a reasonable person so as a courtesty to him... JimW: there's a couple of typos that need fixing too. "Hall, Shaun" wrote: > Let us remind ourselves about a few things here (in conjunction > with null resource emails): > > 1) Locking's purpose it to avoid conflict, the lost update problem > etc (RFC2518 sec 6). Agreed. > 2) A null resource MUST NOT appear as a member of its parent > collection (RFC2518 sec 3). That's interesting, because Section 7.4 (which I was reading) states that it MUST appear as a member of its parent collection. By copy to JimW. Please add this to the RFC2518 issues list. I'd have thought that the correct answer was that it MUST appear as a member of its parent, otherwise the namespace is not reserved. > 3) A null resource MUST respond with a 404 for ALL methods > other than PUT, MKCOL, OPTIONS and LOCK (RFC 2518 sec 3). And UNLOCK. Geeze, there's another for the list Jim. Good job you read section 3 Shaun. > 4) Lock null resources (LNRs) are there to reserve name (RFC2518 > sec 7.4). They are there so a client can reserve the name *before > they create the resource* (store the "entity"). Admittedly, a > server may use a file to represent the LNR, but thats an > implementation detail. Since the name is reserved, it avoids > potential conflict when the entity is actually stored e.g. with > a PUT. I couldn't find the bit about "before they create the resource". The use of a file is a red herring, I have never suggested that any DAV server has to use files at all, in fact the opposite, I've always objected to such statements. If a lock null resource is not a resource, then what is it? > 5) Methods performed on LNRs other than PUT, MKCOL, OPTIONS, > PROPFIND, LOCK and UNLOCK MUST respond with a 404 or 405 (RFC > 2518 sec 7.4). Agreed. The lock-null resource is dictated to respond to methods in a certain way -- but so are other resource types that are defined in DeltaV versioning for example. > 6) If you UNLOCK an LNR, the resource is returned to the null > resource state (RFC 2518 sec 7.4). This may mean a server > actually deletes the "file" it used to represent the LNR, but > thats another implementation detail. Agreed. The implementation is irrelevant here. > The client should assume nothing about how the server implements > the protocol, in these cases, null resources and LNRs. Agreed again, it could all be in memory, in a RDBMS, whatever, I don't care. However, when a lock-null resource is created, there is a resource and it has a URI. The "null resource state" is also a term introduced by RFC2518 and not properly defined. > A few people interpret 2) and 3) to mean that a null resource > doesn't physically exist, which IMHO is convenient. As far as > the client is concerned, a null resource doesn't exist as per > 3), and an LNR doesn't exist as per 5). We can have a very interesting discussion about lock-null resources and null resources ... I happen to believe that the ideas are bogus but the problem to solve (your point (1) above) is real. Tim From w3c-dist-auth-request@w3.org Fri Jun 15 14:39:46 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22257 for ; Fri, 15 Jun 2001 14:39:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA20944; Fri, 15 Jun 2001 14:35:48 -0400 (EDT) Resent-Date: Fri, 15 Jun 2001 14:35:48 -0400 (EDT) Resent-Message-Id: <200106151835.OAA20944@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 OAA20923 for ; Fri, 15 Jun 2001 14:35:40 -0400 (EDT) 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 OAA03029 for ; Fri, 15 Jun 2001 14:35:39 -0400 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 LAA21033; Fri, 15 Jun 2001 11:35:39 -0700 (PDT) From: "Jim Whitehead" To: "Peter Pierrou" , , Date: Fri, 15 Jun 2001 11:33:22 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: questions about WebDAV methods Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5019 X-Loop: w3c-dist-auth@w3.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 > Would it not be possible, if the server supports it, to map a > part of an XML document with > the URL, by using xpointer as an example? > > http://server/files/file.xml/descendant(1, 'paragraph') > > If the server can handle a lock on a part of a document that > would make sense. Yes, it is certainly possible for a server to perform a mapping of the structure of a document into its namespace. Use of XPointer is one such possibility. When we developed the WebDAV Distributed Authoring Protocol, one of our design rules was to avoid requiring the server to have any knowledge about the internal structure of a document. However, an individual server is certainly free to do so. - Jim From w3c-dist-auth-request@w3.org Fri Jun 15 14:56:45 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23259 for ; Fri, 15 Jun 2001 14:56:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA22291; Fri, 15 Jun 2001 14:53:36 -0400 (EDT) Resent-Date: Fri, 15 Jun 2001 14:53:36 -0400 (EDT) Resent-Message-Id: <200106151853.OAA22291@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 OAA22265 for ; Fri, 15 Jun 2001 14:53:28 -0400 (EDT) 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 OAA04577 for ; Fri, 15 Jun 2001 14:53:27 -0400 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 LAA00397 for ; Fri, 15 Jun 2001 11:53:29 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Fri, 15 Jun 2001 11:51:13 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <80256A6C.00511124.00@d06mta06.portsmouth.uk.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5020 X-Loop: w3c-dist-auth@w3.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 > > 2) A null resource MUST NOT appear as a member of its parent > > collection (RFC2518 sec 3). > > That's interesting, because Section 7.4 (which I was reading) states that > it MUST appear as a member of its parent collection. > By copy to JimW. Please add this to the RFC2518 issues list. Actually, the specification is correct, though it takes a careful read to see that. There is a difference between a "null" resource, and a "lock null" resource. The definition of a "null" resource, as given in Section 3, is correct. Lock null resources are defined in Section 7.4. A null resource does not belong to its parent collection, and does not respond to UNLOCK. Perhaps a better way to express this concept is that what we termed a "null resource" is really an "unmapped URL". That is, the URL is not mapped to a resource. This avoids the philosophical question of "is a null resource a resource"? By calling it an unmapped URL, a "null resource" is clearly not a resource. A lock-null resource is a null resource that has been locked. A lock null resource has diferent properties that a null resource. Specifically, it has at least the lock discovery properties, and it is a member of its parent's collection. > > 4) Lock null resources (LNRs) are there to reserve name (RFC2518 > > sec 7.4). They are there so a client can reserve the name *before > > they create the resource* (store the "entity"). Admittedly, a > > server may use a file to represent the LNR, but thats an > > implementation detail. Since the name is reserved, it avoids > > potential conflict when the entity is actually stored e.g. with > > a PUT. > > I couldn't find the bit about "before they create the resource". > The use of a file is a red herring, I have never suggested that any DAV > server has to use files at all, in fact the opposite, I've always objected > to such statements. > If a lock null resource is not a resource, then what is it? Since a lock null resource has state, I would claim it is a resource. By the act of a client taking out a lock, they have likely made a mapping of a URL to a conceptual resource, and are int he process of fleshing out the computer representation of the conceptual resource. - Jim From w3c-dist-auth-request@w3.org Fri Jun 15 16:05:00 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27128 for ; Fri, 15 Jun 2001 16:05:00 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA28845; Fri, 15 Jun 2001 16:04:01 -0400 (EDT) Resent-Date: Fri, 15 Jun 2001 16:04:01 -0400 (EDT) Resent-Message-Id: <200106152004.QAA28845@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 QAA28817 for ; Fri, 15 Jun 2001 16:03:54 -0400 (EDT) Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA11953 for ; Fri, 15 Jun 2001 16:03:54 -0400 Received: from aptiva (212.140.127.25) by mail.san.yahoo.com (5.5.032) id 3B2918FF00021EE6 for w3c-dist-auth@w3.org; Fri, 15 Jun 2001 13:03:29 -0700 From: "Tim Ellison" To: Date: Fri, 15 Jun 2001 21:03:52 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5021 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is cool. > A lock-null resource is a null resource that has been locked. A lock null > resource has diferent properties that a null resource. Specifically, it has > at least the lock discovery properties, and it is a member of its parent's > collection. Now I'm confused again. A lock-null resource (i.e. a URI that has no resource binding) is-a locked resource? How did you make that leap? Is it fair to think of LOCK on a (unmapped) URI as creating a resource just as I think of PUT creating a resource? If not, why? > > If a lock null resource is not a resource, then what is it? > > Since a lock null resource has state, I would claim it is a resource. By the > act of a client taking out a lock, they have likely made a mapping of a URL > to a conceptual resource, and are int he process of fleshing out the > computer representation of the conceptual resource. Agreed. Tim From w3c-dist-auth-request@w3.org Mon Jun 18 04:55:08 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02259 for ; Mon, 18 Jun 2001 04:55:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA29291; Mon, 18 Jun 2001 04:48:10 -0400 (EDT) Resent-Date: Mon, 18 Jun 2001 04:48:10 -0400 (EDT) Resent-Message-Id: <200106180848.EAA29291@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 EAA29262 for ; Mon, 18 Jun 2001 04:48:02 -0400 (EDT) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA32059 for ; Mon, 18 Jun 2001 04:47:56 -0400 Received: from eurodns4.eur.xerox.com (eurodns4.eur.xerox.com [13.202.66.50]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id JAA28484 for ; Mon, 18 Jun 2001 09:47:18 +0100 (BST) Received: from eur.xerox.com (eurdubmg01.eur.xerox.com [13.202.65.253]) by eurodns4.eur.xerox.com (8.9.3/8.9.3) with ESMTP id JAA04534 for ; Mon, 18 Jun 2001 09:47:14 +0100 (BST) Received: from eurgbrbh03.emeacinops.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 18 Jun 2001 09:41:00 +0100 Received: by eurgbrbh03.eur.xerox.com with Internet Mail Service (5.5.2651.58) id <2XAFBV50>; Mon, 18 Jun 2001 09:42:05 +0100 Received: from [13.202.66.60] (eurdubmg03.eur.xerox.com [13.202.66.60]) by eurgbrbh03.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id 2XAFBV5W; Mon, 18 Jun 2001 09:42:02 +0100 Received: from gbrwgcbh01.wgc.gbr.xerox.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 18 Jun 2001 09:36:38 +0100 Received: by gbrwgcbh01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Jun 2001 09:41:04 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB77672875C2@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: WebDAV WG Date: Mon, 18 Jun 2001 09:41:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5022 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > -----Original Message----- > From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] > Sent: 15 June 2001 19:51 > To: WebDAV WG > Subject: RE: Status code for creating lock-null resource > There is a difference between a "null" resource, and a "lock > null" resource. > The definition of a "null" resource, as given in Section 3, > is correct. Lock > null resources are defined in Section 7.4. A null resource > does not belong > to its parent collection, and does not respond to UNLOCK. > Perhaps a better > way to express this concept is that what we termed a "null > resource" is > really an "unmapped URL". That is, the URL is not mapped to a > resource. This > avoids the philosophical question of "is a null resource a > resource"? By > calling it an unmapped URL, a "null resource" is clearly not > a resource. Agreed on all of Jims points. I like the point about "URL is not mapped to a resource". Maybe it could be included in the revised RFC as it could make things clearer for some people ? > > A lock-null resource is a null resource that has been locked. > A lock null > resource has diferent properties that a null resource. > Specifically, it has > at least the lock discovery properties, and it is a member of > its parent's > collection. [snipped] IMHO, null resources have no properties. After all, they don't map to any resource within the server, can't do a PROPFIND on them etc. Is my interpretation wrong ? Just a reminder, LNRs have *all* the mandatory DAV properties (RFC 2518 sec 7.4), though as spec states, most will have no value (except lock properties). One can legitimately perform a PROPFIND on a LNR and retrieve a DAV:* property. Regards Shaun Hall Xerox Europe From w3c-dist-auth-request@w3.org Mon Jun 18 05:15:56 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02370 for ; Mon, 18 Jun 2001 05:15:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA00327; Mon, 18 Jun 2001 05:03:58 -0400 (EDT) Resent-Date: Mon, 18 Jun 2001 05:03:58 -0400 (EDT) Resent-Message-Id: <200106180903.FAA00327@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 FAA00302 for ; Mon, 18 Jun 2001 05:03:51 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA00838 for ; Mon, 18 Jun 2001 05:03:50 -0400 Received: from maggie [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Mon, 18 Jun 2001 11:03:46 +0200 From: "Stefan Eissing" To: "Hall, Shaun" , "WebDAV WG" Date: Mon, 18 Jun 2001 11:03:45 +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.2910.0) In-Reply-To: <59697CCC6CE3D411B4CD00805FBB77672875C2@gbrwgcms03.wgc.gbr.xerox.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: AW: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5023 X-Loop: w3c-dist-auth@w3.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 > [mailto:w3c-dist-auth-request@w3.org]Im Auftrag von Hall, Shaun > > -----Original Message----- > > From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] > > Sent: 15 June 2001 19:51 > > To: WebDAV WG > > Subject: RE: Status code for creating lock-null resource > > > There is a difference between a "null" resource, and a "lock > > null" resource. > > The definition of a "null" resource, as given in Section 3, > > is correct. Lock > > null resources are defined in Section 7.4. A null resource > > does not belong > > to its parent collection, and does not respond to UNLOCK. > > Perhaps a better > > way to express this concept is that what we termed a "null > > resource" is > > really an "unmapped URL". That is, the URL is not mapped to a > > resource. This > > avoids the philosophical question of "is a null resource a > > resource"? By > > calling it an unmapped URL, a "null resource" is clearly not > > a resource. > > Agreed on all of Jims points. I like the point about "URL is not > mapped to a > resource". Maybe it could be included in the revised RFC as it could make > things clearer for some people ? I support that. It's currently to ease to misread. ;) From w3c-dist-auth-request@w3.org Mon Jun 18 05:53:58 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02576 for ; Mon, 18 Jun 2001 05:53:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA02468; Mon, 18 Jun 2001 05:39:12 -0400 (EDT) Resent-Date: Mon, 18 Jun 2001 05:39:12 -0400 (EDT) Resent-Message-Id: <200106180939.FAA02468@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 FAA02409 for ; Mon, 18 Jun 2001 05:38:58 -0400 (EDT) Received: from d06lmsgate-3.uk.ibm.com (d06lmsgate-3.uk.ibm.com [195.212.29.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA03648 for ; Mon, 18 Jun 2001 05:38:58 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate-3.uk.ibm.com (1.0.0) with ESMTP id KAA90124 for ; Mon, 18 Jun 2001 10:29:16 +0100 Received: from d06mta06.portsmouth.uk.ibm.com (d06mta06_cs0 [9.180.35.4]) by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5I9cDK34294 for ; Mon, 18 Jun 2001 10:38:14 +0100 Received: by d06mta06.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A6F.0034DDE0 ; Mon, 18 Jun 2001 10:37:26 +0100 X-Lotus-FromDomain: IBMGB To: "WebDAV WG" Message-ID: <80256A6F.0034CBA5.00@d06mta06.portsmouth.uk.ibm.com> Date: Mon, 18 Jun 2001 10:07:18 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5024 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: "Julian Reschke" wrote: > Now I'm tempted to agree that these should be returned. A minor > issue is with DAV:getlastmodified, because it's format isn't > xs:dateTime, meaning that we have to define a datatype for it in > the spec. That's why I'd still prefer to leave them out. Whatever, the set of relevant properties is so small I don't think there is a problem either way. > > > I see. Maybe this should be put onto the issues list then (for > > > resolution in RFC2518). > > > > What is the issue? I don't think that there is any great harm to > > interop if > > some servers respond with 200OK and others return 207MultiStatus > > with 200OK > > for each response. > > The issue is that after reading the spec (and tracing IIS), authors > of client software might think that they'll always get a 207 which > apparently isn't the case (so I think this should be clarified). "...and tracing IIS..." thanks for the smile I agree that clarification is good. As an aside, I wonder what a client would do if it received an unexpected 200 OK back from a PROPPATCH -- would a reasonable implementation really signal a failure? > > > Do you think it would be a problem to require the 207 > > > response in this case? > > > > You may get pushback from some server writers. > > Well, unless somebody suggests a better approach, I'll have to live with > that. Maybe you can get a few minutes in the London meeting to gauge feedback. The problem, of course, is that if people don't like it, they won't implement it. Regards, Tim From w3c-dist-auth-request@w3.org Mon Jun 18 05:56:53 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02629 for ; Mon, 18 Jun 2001 05:56:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA02518; Mon, 18 Jun 2001 05:39:26 -0400 (EDT) Resent-Date: Mon, 18 Jun 2001 05:39:26 -0400 (EDT) Resent-Message-Id: <200106180939.FAA02518@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 FAA02428 for ; Mon, 18 Jun 2001 05:39:03 -0400 (EDT) Received: from d06lmsgate-3.uk.ibm.com (d06lmsgate-3.uk.ibm.com [195.212.29.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA03650 for ; Mon, 18 Jun 2001 05:39:02 -0400 From: Tim_Ellison@uk.ibm.com Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-3.uk.ibm.com (1.0.0) with ESMTP id KAA121166 for ; Mon, 18 Jun 2001 10:29:24 +0100 Received: from d06mta06.portsmouth.uk.ibm.com (d06mta06_cs0 [9.180.35.4]) by d06relay02.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5I9cJZ20290 for ; Mon, 18 Jun 2001 10:38:24 +0100 Received: by d06mta06.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A6F.0034E05B ; Mon, 18 Jun 2001 10:37:33 +0100 X-Lotus-FromDomain: IBMGB To: "WebDAV WG" Message-ID: <80256A6F.0034CBBA.00@d06mta06.portsmouth.uk.ibm.com> Date: Mon, 18 Jun 2001 10:36:52 +0100 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5025 X-Loop: w3c-dist-auth@w3.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 more I think of this, the more confused I become. Maybe that's not unusual, but ... "Jim Whitehead" wrote: > There is a difference between a "null" resource, and a "lock > null" resource. The definition of a "null" resource, as given > in Section 3, is correct. Lock null resources are defined in > Section 7.4. A null resource does not belong to its parent > collection, and does not respond to UNLOCK. Perhaps a better > way to express this concept is that what we termed a "null > resource" is really an "unmapped URL". That is, the URL is not > mapped to a resource. This avoids the philosophical question > of "is a null resource a resource"? By calling it an unmapped > URL, a "null resource" is clearly not a resource. I agree with all of this. (Despite Section 3 of RFC2518 that states clearly that a null resource is a resource.) I think that calling it "null resource" is very misleading since we agree it is not a resource. I'll use your "unmapped-URL" term for now to help distinguish. http://ces.ucsc.edu/bogus/bogus/bogus.html is an unmapped-URL, got it. > A lock-null resource is a null resource that has been locked. Or in the new phraseology, "a lock-null resource is an unmapped-URL that has been locked". Hmm, that doesn't sound right does it? A resource is-a URL? And not _all_ unmapped-URLs (in DAV compliant namespace) can be locked. It seems that we need to augment "unmapped-URL" with "where the immediate parent exists". > Since a lock null resource has state, I would claim it is a > resource. By the act of a client taking out a lock, they have > likely made a mapping of a URL to a conceptual resource, and > are int he process of fleshing out the computer representation > of the conceptual resource. Agreed. Moving the server state of an 'unmapped-URL where the immediate parent exists' from no resource to a resource should, IMHO, respond with 201 Created. QED Tim From w3c-dist-auth-request@w3.org Mon Jun 18 09:57:29 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08012 for ; Mon, 18 Jun 2001 09:57:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA21721; Mon, 18 Jun 2001 09:44:24 -0400 (EDT) Resent-Date: Mon, 18 Jun 2001 09:44:24 -0400 (EDT) Resent-Message-Id: <200106181344.JAA21721@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 JAA21695 for ; Mon, 18 Jun 2001 09:44:17 -0400 (EDT) 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 JAA25983 for ; Mon, 18 Jun 2001 09:44:15 -0400 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 JAA44082 for ; Mon, 18 Jun 2001 09:37:15 -0500 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5IDi9v32368 for ; Mon, 18 Jun 2001 09:44:09 -0400 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: Mon, 18 Jun 2001 09:48:51 -0400 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 06/18/2001 09:44:09 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/5026 X-Loop: w3c-dist-auth@w3.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 about the delay on the response... "Jim Amsden" wrote: > 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 don't understand how making these explict will cause anything other than forcing a bunch of overhead. Take for example, in a client app the user decides to do a "Create file with path: 0/1/2/3/4/5/6/7/8/9/foo.c" The client app has the options of: a) Performing the PUT and seeing what the status code is. If it is 409, then client can then attempt a MKCOL on each parent collection until one is successful. Once successful, then traverse back down the path and perform each MKCOL, then perform the PUT. b) Performing many PROPFIND's (either starting from the root or from the file resource), then perform a MKCOL for each collection and then finally the PUT. Does the client app have to prompt the user whether each collection should be created? How does forcing the client app to perform all these operations prevent erroneously typed URLs from spurious namespaces? My app does a large amount of *implicit* namespace creation and I'd like to do a simple: PUT /0/1/2/3/4/5/6/7/8/9/foo.c HTTP/1.1 and have the parent collections implicitly created if they don't exist but the spec forces the overhead mentioned above. Could this server behavior be advertised using the DAV header with something like "auto-collections"? Then if one so desired, removing the requirement that "PUT operation creates a new non-collection resource all ancestors MUST already exist" (RFC2518 8.2.2) if auto-collections is supported and making the method MKCOL an optional feature. I'm not sure this requirement is consistent with DELETE, MOVE, and COPY: which can perform a large amount of namespace manipulation in one METHOD (namely on a parent collection). There is no way to guarantee that the new target destination URL has not been erroneously typed other then by user inspection after the fact (or by client app prompting, do we ever pay attention to those ;-) Thoughts? Thanks, Steve From w3c-dist-auth-request@w3.org Mon Jun 18 17:42:11 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21855 for ; Mon, 18 Jun 2001 17:42:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA06549; Mon, 18 Jun 2001 17:37:31 -0400 (EDT) Resent-Date: Mon, 18 Jun 2001 17:37:31 -0400 (EDT) Resent-Message-Id: <200106182137.RAA06549@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 RAA06529 for ; Mon, 18 Jun 2001 17:37:24 -0400 (EDT) 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 PAA04287 for ; Mon, 18 Jun 2001 15:54:56 -0400 Received: (qmail 13548 invoked by uid 0); 18 Jun 2001 19:54:33 -0000 Received: from p3ee24655.dip.t-dialin.net (HELO lisa) (62.226.70.85) by mail.gmx.net (mail06) with SMTP; 18 Jun 2001 19:54:33 -0000 From: "Julian Reschke" To: , "WebDAV WG" Date: Mon, 18 Jun 2001 21:54:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <80256A6F.0034CBA5.00@d06mta06.portsmouth.uk.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: RE: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5027 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Tim_Ellison@uk.ibm.com > Sent: Monday, June 18, 2001 11:07 AM > To: WebDAV WG > Subject: RE: Proposal for marshalling property type information > > > > > "Julian Reschke" wrote: > > Now I'm tempted to agree that these should be returned. A minor > > issue is with DAV:getlastmodified, because it's format isn't > > xs:dateTime, meaning that we have to define a datatype for it in > > the spec. That's why I'd still prefer to leave them out. > > Whatever, the set of relevant properties is so small I don't > think there is > a problem either way. OK, this allows me to avoid specifying a datatype for RFC dates in the spec. > I agree that clarification is good. As an aside, I wonder what a client > would do if it received an unexpected 200 OK back from a > PROPPATCH -- would > a reasonable implementation really signal a failure? Depends on what you call reasonable. I haven't written a client yet, but up until your comment I would have been tempted to think I'll always get a multistatus. > > > > Do you think it would be a problem to require the 207 > > > > response in this case? > > > > > > You may get pushback from some server writers. > > > > Well, unless somebody suggests a better approach, I'll have to live with > > that. > > Maybe you can get a few minutes in the London meeting to gauge feedback. > The problem, of course, is that if people don't like it, they won't > implement it. Which meeting? From w3c-dist-auth-request@w3.org Mon Jun 18 17:59:59 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22136 for ; Mon, 18 Jun 2001 17:59:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA07662; Mon, 18 Jun 2001 17:57:25 -0400 (EDT) Resent-Date: Mon, 18 Jun 2001 17:57:25 -0400 (EDT) Resent-Message-Id: <200106182157.RAA07662@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 RAA07638 for ; Mon, 18 Jun 2001 17:57:17 -0400 (EDT) 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 RAA15315 for ; Mon, 18 Jun 2001 17:57:17 -0400 Received: (qmail 12335 invoked by uid 0); 18 Jun 2001 21:57:13 -0000 Received: from p3ee24655.dip.t-dialin.net (HELO lisa) (62.226.70.85) by mail.gmx.net (mp005-rz3) with SMTP; 18 Jun 2001 21:57:13 -0000 From: "Julian Reschke" To: "WebDAV WG" Date: Mon, 18 Jun 2001 23:57:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_01C0F852.63CB2BC0" 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.4522.1200 Subject: RE: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5028 X-Loop: w3c-dist-auth@w3.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_0004_01C0F852.63CB2BC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Attached is an updated version of my proposal which should address Tim's concerns (Tim, thanks for the feedback!). -- Network Working Group J. Reschke Internet-Draft greenbytes Expires: December 17, 2001 June 18, 2001 Datatypes for WebDAV properties draft-reschke-webdav-property-datatypes-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 17, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This specification extends the WebDAV Distributed Authoring Protocol to support datatyping on property values. Protocol elements are defined to let clients and servers specify the type of a property, and to instruct the WebDAV method PROPFIND to return datatype information. Distribution of this document is unlimited. Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at w3c-dist-auth@w3.org[1], which may be joined by sending a message with subject "subscribe" to w3c-dist-auth-request@w3.org[2]. Discussions of the WEBDAV working group are archived at URL: Reschke Expires December 17, 2001 [Page 1] Internet-Draft Datatypes for WebDAV properties June 2001 http://lists.w3.org/Archives/Public/w3c-dist-auth/. Table of Contents 1. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of data types . . . . . . . . . . . . . . . . . . . . 5 4. Changes for PROPPATCH method . . . . . . . . . . . . . . . . . 6 4.1 Example for successful PROPPATCH . . . . . . . . . . . . . . . 6 4.2 Example for failed PROPPATCH . . . . . . . . . . . . . . . . . 7 5. Changes for PROPFIND method . . . . . . . . . . . . . . . . . 9 5.1 Example for PROPFIND/prop . . . . . . . . . . . . . . . . . . 9 6. Compatibility Considerations . . . . . . . . . . . . . . . . . 11 7. Internationalization Considerations . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Intellectual Property . . . . . . . . . . . . . . . . . . . . 15 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 Reschke Expires December 17, 2001 [Page 2] Internet-Draft Datatypes for WebDAV properties June 2001 1. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The term "property element" refers to the XML element that identifies a particular property, for instance The term "prop element" is used for the WebDAV "prop" element as defined in section 12.11 of [RFC2518]. The XML representation of schema components uses a vocabulary identified by the namespace name "http://www.w3.org/2001/XMLSchema". For brevity, the text and examples in this specification use the prefix "xs:" to stand for this namespace; in practice, any prefix can be used. "XML Schema: Structures" ([XS1]) also defines several attributes for direct use in any XML documents. These attributes are in a different namespace, which has the namespace name "http://www.w3.org/2001/XMLSchema-instance". For brevity, the text and examples in this specification use the prefix "xsi:" to stand for this latter namespace; in practice, any prefix can be used. Reschke Expires December 17, 2001 [Page 3] Internet-Draft Datatypes for WebDAV properties June 2001 2. Introduction This specification builds on the infrastructure provided by the WebDAV Distributed Authoring Protocol, adding support data-typed properties. Although servers must support XML content in property values, it may be desirable to persist values as scalar values when possible, and to expose the data's type when the property value is returned to the client. The client is free to ignore this information, but it may be able to take advantage of it when modifying a property. On the other hand, when setting new properties, it can be desirable to pass data type information along with the value. A server can take advantage of this information to optimize storage and to perform additional parsing (for instance of dates). Reschke Expires December 17, 2001 [Page 4] Internet-Draft Datatypes for WebDAV properties June 2001 3. Overview of data types Although WebDAV property types can be anything that can be marshalled as content of an XML element, in many cases they actually are simple types like integers, booleans or dates. "XML Schema Part 2: Datatypes" [XS2] defines a set of simple types which can be used as a basis for supplying type information to attributes. Data type information is represented using the attribute "type" from the XML Schema namespace "http://www.w3.org/2001/XMLSchema-instance". In XML Schema, data types are qualified names, and the XML Schema recommendation defines a set of built-in datatypes (section 3 of [XS2]), defined in the namespace "http://www.w3.org/2001/XMLSchema". To avoid unnecessary verbosity, data type information should only be supplied if it adds usable information to the protocol. In particular, type information is not required for live properties defined in WebDAV [RFC2518] and related standards and properties of type "xs:string". A server may implement any combination of datatypes, both from the XML Schema recommendation and possibly from other namespaces. Reschke Expires December 17, 2001 [Page 5] Internet-Draft Datatypes for WebDAV properties June 2001 4. Changes for PROPPATCH method If the property element has an XML attribute named "xsi:type", the server may use this information to select an optimized representation for storing the property value. For instance, by specifying a type as "xs:boolean", the client declares the property value to be of type boolean (as defined in [XS2]). The server may choose any suitable internal format for persisting this property, and in particular is allowed to fail the request if the format given does not fit the format defined for this type. The server should indicate successful detection and parsing of the typed value by setting the xsi:type attribute on the property element in the response body (this implies that it should return a MULTISTATUS status code and a response body). 4.1 Example for successful PROPPATCH >>Request PROPPATCH /bar.html HTTP/1.1 Host: www.foo.com Content-Type: text/xml Content-Length: xxxx false Reschke Expires December 17, 2001 [Page 6] Internet-Draft Datatypes for WebDAV properties June 2001 >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxx http://www.foo.com/bar.html HTTP/1.1 200 OK In this cases, the xsi:type attribute on the element "Z:released" indicates that the server indeed has understood the submitted data type information. 4.2 Example for failed PROPPATCH >>Request PROPPATCH /bar.html HTTP/1.1 Host: www.foo.com Content-Type: text/xml Content-Length: xxxx t Reschke Expires December 17, 2001 [Page 7] Internet-Draft Datatypes for WebDAV properties June 2001 >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxx http://www.foo.com/bar.html HTTP/1.1 422 Unprocessable Entity Does not parse as xsd:boolean In this case the request failed because the supplied value "t" is not a valid representation for a boolean value. Reschke Expires December 17, 2001 [Page 8] Internet-Draft Datatypes for WebDAV properties June 2001 5. Changes for PROPFIND method PROPFIND is extended to return the data type information for properties unless one of the following conditions is met: o The data type MUST be different from "xs:string" (because this can be considered the default data type). o The property's data type MUST not defined in [RFC2518] (because these types are already well-defined). 5.1 Example for PROPFIND/prop >>Request PROPFIND /bar.html HTTP/1.1 Host: www.foo.com Content-Type: text/xml Content-Length: xxxx Reschke Expires December 17, 2001 [Page 9] Internet-Draft Datatypes for WebDAV properties June 2001 >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxx http://www.foo.com/bar.html text/html 1 HTTP/1.1 200 OK This example shows that the property value "true" is returned with the correct data type information, and that the server chose one of the two possible representations defined in XML Schema. It also shows that data type information is not returned for "D:getcontenttype", as this property's data type is already defined in [RFC2518]. Reschke Expires December 17, 2001 [Page 10] Internet-Draft Datatypes for WebDAV properties June 2001 6. Compatibility Considerations This specification does not introduce any new protocol elements, nor does it change the informal WebDAV DTD. It merely specifies additional server semantics for the case where clients submit additional data type information in an attribute on the property element (previously undefined), and adds an additional attribute on property elements upon PROPFIND. Clients not aware of this specification should not supply the "xsi:type" attribute on property elements (after all, this attribute belongs to the XML Schema-Instance namespace which has been defined for exactly this purpose). Old clients should also ignore additional attributes on property elements returned by PROPFIND (and similar methods), although the WebDAV specification only defines this behaviour for unknown elements (and is silent about unknown attributes). Servers not aware of this specification either drop the "xsi:type" attribute, or persist it along with the property value. However, they will never indicate successful parsing of the data type by returning back the type in the response to PROPPATCH. Reschke Expires December 17, 2001 [Page 11] Internet-Draft Datatypes for WebDAV properties June 2001 7. Internationalization Considerations This proposal builds on [RFC2518], and inherits its internationalizability. Reschke Expires December 17, 2001 [Page 12] Internet-Draft Datatypes for WebDAV properties June 2001 8. IANA Considerations This proposal does not introduce any new IANA considerations, since it does not specify any new namespaces (in the general sense), but merely uses existing ones. Reschke Expires December 17, 2001 [Page 13] Internet-Draft Datatypes for WebDAV properties June 2001 9. Copyright To be supplied by the RFC Editor. Reschke Expires December 17, 2001 [Page 14] Internet-Draft Datatypes for WebDAV properties June 2001 10. Intellectual Property To be supplied by the RFC Editor. Reschke Expires December 17, 2001 [Page 15] Internet-Draft Datatypes for WebDAV properties June 2001 References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, . [XS1] Thompson, H., Beech, D., Maloney, M., Mendelsohn, N. and World Wide Web Consortium, "XML Schema Part 1: Structures", W3C XS1, May 2001, . [XS2] Biron, P., Malhotra, A. and World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C XS2, May 2001, . [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999. [1] [2] Author's Address Julian F. Reschke greenbytes GmbH Salzmannstrasse 152 Muenster, NW 48159 Germany EMail: julian.reschke@greenbytes.de Reschke Expires December 17, 2001 [Page 16] Internet-Draft Datatypes for WebDAV properties June 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Reschke Expires December 17, 2001 [Page 17] > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Monday, June 18, 2001 9:55 PM > To: Tim_Ellison@uk.ibm.com; WebDAV WG > Subject: RE: Proposal for marshalling property type information > > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Tim_Ellison@uk.ibm.com > > Sent: Monday, June 18, 2001 11:07 AM > > To: WebDAV WG > > Subject: RE: Proposal for marshalling property type information > > > > > > > > > > "Julian Reschke" wrote: > > > Now I'm tempted to agree that these should be returned. A minor > > > issue is with DAV:getlastmodified, because it's format isn't > > > xs:dateTime, meaning that we have to define a datatype for it in > > > the spec. That's why I'd still prefer to leave them out. > > > > Whatever, the set of relevant properties is so small I don't > > think there is > > a problem either way. > > OK, this allows me to avoid specifying a datatype for RFC dates > in the spec. > > > I agree that clarification is good. As an aside, I wonder what a client > > would do if it received an unexpected 200 OK back from a > > PROPPATCH -- would > > a reasonable implementation really signal a failure? > > Depends on what you call reasonable. I haven't written a client > yet, but up > until your comment I would have been tempted to think I'll always get a > multistatus. > > > > > > Do you think it would be a problem to require the 207 > > > > > > response in this case? > > > > > > > > You may get pushback from some server writers. > > > > > > Well, unless somebody suggests a better approach, I'll have > to live with > > > that. > > > > Maybe you can get a few minutes in the London meeting to gauge feedback. > > The problem, of course, is that if people don't like it, they won't > > implement it. > > Which meeting? > ------=_NextPart_000_0004_01C0F852.63CB2BC0 Content-Type: application/x-gzip; name="draft-reschke-webdav-property-datatypes-00.tar.gz" Content-Disposition: attachment; filename="draft-reschke-webdav-property-datatypes-00.tar.gz" Content-Transfer-Encoding: base64 H4sIANB4LjsAA+w8a3PbOJLz1foVKF7drl0lUZbsOLHH1sSxnY13/Fpb2eyjrq4gEpI4JgkNQVrW bO1/ybf7m9fdAMGHHn7N5mavrKo4Egk0Gv3uRpN+wodpKxHKG9+K1lQMfH7XmiRyIpJ01vJ5ytPZ RKjW5qY7TqPwu+d8Njubmzvb299twuftDv0PVzr0G+7sbL2Ba2+3Olvbb7c7b7vfbXY3u2/ffsc2 n7XaEz+ZSnnC2Hc/JWLluB9FEH8LfL7xZ/+H+yhkdyJRgYwPnI676TARe9IP4tGBEyjZevfuzW6r 4/zQ20cBYDA8VgfOOE0ne+32dDp1p1uuTEbtzu7ubvsexzgwVHC/t58GaSh6x7kQsaFM2BcxOD78 MzMiFgi139bD9lU6CwXDkQdOKu7TtqeU02scNv7RWMPfLV94MuEpILrHYhmLxj8bh3tjCcgvHJLF vkjCwIzjXhrciQcHfrg8/isO8mQokz32H1pGv28w+AxlnLaGPArC2R4bi/BOpIHHm4wnAQ+bTPFY tZRIgmFpuAp+EXusszW5/x6gf+qUYW/RZ37wDg7Gi4hTayyC0TgtX34CHmsTPhKtQSL4bQsUXcCy /E4GPiHTXblRg8z2r73q1mNW3fqVV73CRSOejIK4FYohkLMrIr2CuZpoKtNlGH99MjdjK59R5R+M 7h9+OKPxtS3grWMXdUGLaD5xSJ/5XW8u3LXZamnzdUm742EwAkFO5QSWdD05mdF26ihtEkruWKZ9 0IECo3mEpkboYplEPNQ3FurgAny9B9hUwmhXIwRyftt9DDoDGfpPQ+ZJamrQuf54VEJmhz7fAJkF hCHLWJac3d2F+tLtLjQZxeVViBvhIYmhy2uPRhpwbLyPhB9wMOhBnLJ/EFj6uLE01/xATUI+20Oq /BOm7LfJ1Pf229pNDKQ/A2fBB2D+vZArcC9mrgO4JqA8Bw64JU+E4YT72jOZ32rCPfrdddg08NPx gbMFtzQBwJ29cRht78Ch7YFnShP457PBiEh64BgTZMd5IgbT4RidKn4vgA7fAXlwXBMe54iD7Di9 r/D3K+wSrsMmYcQgaVeHGRV04HI79fFPsgA1ze051BZvtLfP2TgRQ5iXDD03lZ7Djs4Ob24OHNIv xDVf3lz42r9EPAHBNi8j0iZe5Cwxy+3s/OdydnRq7OgUlM6x3cLpdmtaqxxLD7KRTu9CpFOZ3LIv 8AcAsT8kMpt81ag9FdYfXfbRZdc6tP06T+cnATu96J9cX5z02fH14cf+MzEaJULEg1kq1EvRKdQM 9fV3Yfq9/+hA/ncjreb281z6ZrFgXQjkf83NrB3xVIxkMturoHgaD9EToXXl4TPxfSmaJ/eTAOi7 x46FJ6KBSMqbfwkyubqRlfCDu7rJKhsO8gjOwzG1sT0ADYLxTu8GhmeKySFLx4Fi5yKSYH07vf1J r7EGnz5e9aWXRWBjGHyHFU/R2sQibR2jaMEVH2/QcPqzthbEbJiFIQREmj2xh9YiHcMGQsTmLsCs gpa9ER4yD2IQ/AX2EXK8HRdZS3wmoAS1uiogkgBMYw1yBM1GhEWRncQQpwlwSfFI74erW/ZRJoDQ +ulJ/+NGkwUaGFdNvRX4mcMdoZVRLs28kCkkIWOeMgkrJOYeRIkz2JWSDJxZmgSDLF2EFleL9uAu 3RgpbWk+Oh2fWMphxfsgyiLcqgruWQQ+eazBI/qIz0CwbAKaLfwmSwS4WA+/wWQ5UDIUcJ0NZmYb JRyRlTOWBpEwiBHDg5hPUIDAxSMBJMuUYHM4K1hoKBKBnAZ1FBgQ4Iow3gtSQfBgvcisCnSMcZJD Rh3EBVYAIwh5HS29356UJFBA8KJS3K+XJQnKYX15D6DBprnnAQjYHU9pqnV8paQ0EOmQ0lL80u4E fosPgHGQBSo3Bcfbe/xYdI4r0a0pys2Y+3LKjsFYeKlMQB2fhbgiMK5OqB8YsARFYGsNt2kAminI kDHQxoolKwCAYTjKcwgGChF4omQtilvrRxusX1bDG+kBejO2jvA2XHYIq13jUIV+WCR3wndJ3/Nl Dg2hLXhCWk2EFwwh5CSTAXGSiH1FCm8s3bFVQp8dZulYouKzq0RC1CNDlMaGyiYTmYByaUuJ92Wc m8gZalomlFvMEaEw+gGkafhiCPbER0igSGB8A30PNI+2keRIzggtNMUoCdwuoI1MKhtBDKhmXlpG PxKAss+uri+vPp5eHOMqiUizJM6xFaAr1uG51hMi1YABSCdLAaRQbtbLBjyLwyAClfRhjyFYPQGI A0aejPQ2YU3EqLGYlIj8n3VRCH+ua8Q3qhYTTYkV4YgHYSr3plteC01kiwOs97o05PQWXUWZbbLp OPDGuTX7SRLRwWghroQH0EopyOu1X1HZ4CdQKtZw4JvyAG/h4E5WYgFB0c/A69Ss+4MBclCA6K0a n+tWrlpAMC9T1rERW08+IFtrxAE54ok3Du5I4dnn67M91qirPNoQlZfQDvVw1b7KBmHgtStota0V eMIcQp5VP7k40Y4Ao3Eyl3VhVklBPdoYgeF++zVB+w0maJzFPAL+5PDIpvaJTyCaRxAyoK5r44oQ MozVImAJYGS+2MhUzx/UsFQ6bnMhoesgiK/WGFGoZCJyXOoOlkKlKOi5DBZsrFuHBS4kkX5GAx6G sOX0tuoQLsEq3wViijtHM0pG+RHYbDu97TqsI4hbRia4Rit9ddg/+mTM9iMgIrXgTx3qyT2PJsAa hKoyigUgfC4WeAzkLkKeo14Z8hBMoPCfAhVE881DFCA/9VgCvEECvFlNgBxoGz3mwyB3nN7OHI4o wWkwCMIAPDqIoArAFPFHSuFbp/d2gRRCIGOEOvhFxx9PBfzO6b2bA3x4cfhkQLtOb3d+zyb4enh6 B6xfZ3PRFsMQhmSgtlcmWlkOzIb7yun9Tx3Wtb25HACnmMLO1iHG7xU79H1MBBoIZ/lsW8rO53/E fLOIQDGvpbitBqedhb1G47fv2/6vHQg6hrITqZt7t2D3MmsPIBoQFy0G404AVBuCVkwTbsUMYyQI 5Z3zzzd9p6n/ZxeX9P365E+fT69PjvH7zafDszP7xYxorMHPy89nZgR+K+YeXZ6fn1wc6+nnh391 dATuXF71Ty8vDs8cTD8pSm6s2TgZYzQIHwcYbwPhJwklzZCw+kKHhj7OKsiOdYtOZxdiTizDHDg/ 2h2hScOMGYbDIAqvTyGE9TCZvoZ4EhIuWvFM3IkQtOHvBtR/6fCSIvtVVOxaKgKeEXNsImPyFkcn 5jau/8v5WX5LVzPA8ADHhpCNAkchT+EJpHVZyJNSyoKbwHwFCzkaJcApEbAwVhhHIvV0RBGKeATR uDkKhtB3z2FtKivCJBy/civbC7ZSbANTF0yREZdSykSjHLslYhGlaLAboLnKy0tdt9PBCKDKszed d5Znn/r9K3aCOaWO4XGhxUlQq2Uie8MugPJYdr2xe0RGJAKoAimNViCq6HhjEXEKxmRM+RhsWnPm Tnp8gIyZFTyjnAipgauh2dHf2IJjeMy827DoDa3gYPL4EXY4SMRdgDymdBUiW9IOoR2ysrpRzbxR oHE8YD8M7plzr/YcgAcihjKS8wimWbS+10UePGz3RJMKTWayKYEgbyGbcpAsGsU9MOKYIGdAIoet F4z7y03HMq0Yzq5AclmnMqv3dxhLrNkwRTqSDdgOaFvCQ6RrahisGe5TcSbXWEQTV7BFMhfLGnCv NAtNBQ4FWH4wJL+XFvvOE9kxV8/iUytXu1+bYcESjoWwNZE8mXHaKLz61ef61Tz1KfnVauazypt2 c2/K2IIy2SALQnBEMiYJCOJhwlWuIroY72s7gvLw2FIaSALxhpXLaS3MrNDwFgcOLlttE7vWhR2G sEY2Gts6WpSp1IJHLTROxpSLy+U6LOLntSLUQ6GChAQM5HuC1SqApEeig1AeR/dmLkzHAuBJpQKY kFfnsBQqlTAUwb1BZEr1NxquVamMAronXarTxUEcoYuDZDLMd/RJYGcSQZiBBEqMM8ZUZbdlvSZw LC1tKN9Iym/hh3/HwV2MKI8PECAhFEmwPTNdGMsRe8AbIeW3iPKXekO6Mg/pnd/UQJVIUwQZQ+5c cJRobXS/TGhkO2hCkWKX9wT6JgES1epwLaKZyw4NswledX8ALq9eluEAHeQkDSKwKWC5ZIKUMCwD /HAcCaaJRyGYUVSmhBsUD2hbaioBQm28Gq6XGq684lIyXMsKLqtM2FZhwqwhqJ5ezjQYe2QSz0A4 gLcUxJqLEfB7zCGLRSMEmp5bDKzAx+XQt4lGJEJn5nGIr1AmZ4xT7hvOyKWrAP0pGgBaNQxudS4w AnMCGiplKDgWehMtSS6bC0W6e8yexqKvLQcw3aUBTGUWxi9dil9s5MJRLfXZH5VMNHo6yNBUgKUo UOY4eMBVoExhaTIJyUTMKScoTxHQuOwBk71lTfbxQlUnS2jiWkAjU5pLpaCJOTjJAUMoI7wDGJfI UIRIT4qO1k7jEpRmSfKInz8Da3XETPCNoTdxuFkZ8IDojw5CfL2XOaqjM01hWXsgo9h6nmNswYCX 8nmjmecvOpJD2jyBIM4DRn/LGv2+1E2QLItjgRVHzCtAcQdSUXS52Iwr0MzQh1ginGlJI6lCqgbo jtD2YsZCNrImYcZnUvTgQnBTyjSbRs3qYhTLlCU6R9YRahjciZIrKpEKIBhz8a9M8EhoEhHi0boO nDnm+Hi1hBX6LdgNoISJEcKPR49hjM5/rU9E9086rhNbtFUyGgSxzRWtCKI9AseaqxOKNCxupK0m 0YSrjnZmeob2+1bI1KtPfKlPzE8OSj5x9cHBKs+4bUtlp8Nq4JnXPDC3NO6tMLEIyNeJHhnbpoll S8Klk8L5AEsJLAMjyDzU8muVigbTLiXV6jIfDruUqubWuUknt/pYHMdTOYMUHltAQEeMO3WapbgZ lBu4kWjnbME3mIm3dXXOqFruj9k6LxuFF5pil/KpCsm8sZSKgg+wfEFq7BydDYRME5EoY5IOTZxA FSmROf8PyuaP2qrCUE516oDnNLRnc9yMphV/avAAagRWEByQFNpCDoO0dN9u32b0uK8HrM92pZBo 9mtsfZBXK0snU75Ijc8jc2KibHPoTUmg5hIgS2f2aZqLSS6PJUmV8WKx1v4PqKAmYK0JlvRnbF2L bIRuR5kSZpoja7olODv/fNY/vekf9j/foKHGHjdP+pQrkPRh3TLKwjTQN7FGaVeidWxqsD/uLiNa cZpX0vSHD/MAIHICZ+C6+O9as9owCSulcLOwE+0BT6ifh6EPa3fcDt7/JFW6xzAWGErpgpXHi+Zs t9UHIu9Rfah9H4XlO2dUpN1j9/BpEBJAi+O9nP66c0zXcPeOTRXX7E5fBB4ues5nWWhWm/vw1OqM v9UnwEbb1ve2f9nadd9sOkXvqt4NyFy5nbXYYrXJFa//bQ88OjbC+FY6D8pGCWcMeagEDm4XoyuQ 6F59BXOxhEtpWEHrcoF8Ti60SFYFIxcC1t18y85Rilu6j/NFAlBSh3937ueaPC8C6A7wagmoUR6r Y4ZH+ch5EUIazYtRwfzHCJU+FlkoNSUhtrapxPFNdvljLlj2/iI5rKJpbtQpYy7XTGFJGpeZPptI nJqCMyXSzQeMfG7bnYI+jvUwikIUnpbjFLgngIYY4tDTeBBySJ23qWwQBSkG4gtTFRvFrjLgRdPE EgM+3zPxarz/7Yx3+mq4/3+Y0mfazO1ul32OYQKVOTBkP4khFZgtt6K1vetD/wkaDRx2nEfeGPhS DnOv/Fziana2NrVMgW9hpm2RH4+TCjtdSS+MjRsIj+fHhLaqo3MtRx+/45b1STQ9jVA7vNYPJ+SJ mM4CrQ1+rSU8t5aQ9+CtqCVUWvBWlRLeFEV2Ow/4qvvodfJpEqj81Gu+LEfZra11Ya05DkGtwMGL PAEcSkxmMePzZKzPYhSuAyjiw1vUbGpaS7GTFtFZ2w+DXr+yKHUA4RmTPVSnalWppMbWC5klwY6J RDDHMw11QocKkBJz0JwC+Ia734YFaXi+cm7af6/qSKDcLywq/PoFRsKotC3sNShq2DxMBIcUeAoi 3zIYFVvRvW0PJK3lDswlMU+tAfMpAQ9J1LeKd2D7fs3fvcjT1T2Kvlo0NyEf2vUBNedUMeJlgKVL iPdvPnJ4EiW/bYD524pQiuuLJYYCUORIabX5EawO5jFxbWdVXLs4sF0ZJz2QW36bmOVNKbWkZhbT 2YQVvqkq8sNa+4WTJplwKl0YebNBA1/MkVBb10KXlh8FVhNPb4yF3pJXS6fU4mAaRWrRT6XqXNSX XXaa6sazAnsAstiz2gMvgz/aYqcuLNi9quo15YrLomKy9hPfyGm9hnkvD/PyxxjKYd7KpxhWxXk7 pe7quXYwe24QmP4yfZxhmnyqzzw28T0vNAOwwrYfijzzPjJ6BYxtF+sfk7RHEHWF+WkPVuhL7Tha tfDUGHQDUjBP2W5eykqmY5hsn6nUBZ7y/IV602C6U/MRJwrrE+ydlJkCBLGapAMorf+Y2Ph0llte sQKzDk+xDAyeDXweOGPZsWcsR2aDyAQ+xcAu73SqcsqcaeAw3bxBuyqO9BrsIfzW6XVHeLjU1AsU 4wcCO7LytvBGuQOjdZr3SRWdB0UX60CIuHLIBAbaSwk5bZSyBFvnNlx2CchbZuq9kC00fW+LyIx5 RMmwFTuxVnEwKyLNdXrsNogCPETTCZBCdpoGokaln7FKW+pgyLs7iDQDMeYoHIlu2Y9vYzmNLQIA a9286EBBuowH8gOZpXZcsYONR8iBdm83ptHxITkQgX5SH9vhl0sAPeCfNzui3lQ77urns5/kFHug qWCLp6r0AHgsTM117sSvdsZXaCLwQ/MG37AAyRf3bosnn2tHeChsti5aLtC+Oo1nOY38SbVq0/DD D6qt8h1vixqBbiZGwZEKlLToI/5XBhP5+ThIPL6JA/8hKkFtX9orvraqvFSE8mcSyyK06JHEVSLz bqnIrIg1aBWvskoTWIZeh/idFpPzFyrkU4tWJbZuLMxIxPg8B74eAFyP7qBGMCYawWdowE+ZjgwI 6l+bnF4sOflDqJWI1T6DukpednN56VMPjy02m0eZwBqwEwgNZPLKpBc/rmkf9a35iAVP+q58XnPz yTzDlV759oT3NJSfqEaGlh+izt/ToOlU0AWiSNAOs638xRepnOQvbNDQ86dTqw+XarTMO8qqc2tv TWkV/p0ndzzx2ec4oFcDpzOn9yHhfoyR5I1LDvwrvi7IiNqaU3+vCWZubmDeC+QGKnCFn8HVFlh6 odpAiPYQAmz6hqjqlzI993laRIhaH+lNYh+Orr52tpulWtsavu8Dl6lcPMfXs3zt7O6+ta/YWSuY 9wiCQy6FjYTnZ08kdDpI+Ow9lguxWx3iG09GlvZ9e5lCpAuRKo9DEoAMmDVZ31C/DvMnweMJfx8F XiKVHKYVmOf5Vad3xWUYNNkfl4DxIhV5P7/PAg8ZZgEUgkAvvApB7iXlmewIMkY+koQros5OzNuj gV+Q93F867LTuwHjMxDJqHXu/SmDzLLJjlx2vgQHYKkb8VAk7wVXqauyuLKZmyxmekMzlYoI1Ogc BzfZiWubtxe9WWu65em3EX2RCeSoXyAiwaSRYiCZpEEWPUKuS/Xq/jW+8/pd+/rkqHUfhS38sdlF U2wiY9RhkLHbbMLOeDzK8CGmdZCWDdZxN6si+2Xr6CvcqYjnRzFIMp7MUELfPVdCbzqlp2MfL6Hj 9L0nR8pDtXW552a3S0QBvEE8yJLR2On1xzKaKCy0fnKtkagDPobk23c/COGN38uEe6Go8PaSLoGs 44AmO14CJcoS1KAo+yWSlfn4BNgGltQgIoQQ8zIWJB0QCoLqLJO3C8nH/32OZ6OhkuP4fSjTTFXA nuEVdoy2Rk7I7hzJZGJe9wsr2LlNdvHNhRBkTz9O3uq0nd7KJ6UXCN1Np2YTZ1/1y+D+t71za27b xgLwczyj/4DqYfVQW4plO427DFPFlm1lLdkjyfV6On2gZcZmLUuqJCdRf01+6p5zcCHAi0iJSNLd FTvTWCAJHBDAwcHlfFizvtW1rdX569ul9zys/lp9F0zHo18eJ/SJFGTBC2b+lF36SJjEnpuDCs58 nADiHQDrwf+hIOj9bXZZZb+mlLU3exg/PmXqSUoC6tCQ67t3bapGD+P51Ntmje9YxPWEItY3tieV cN1mCcupAHM4n17Sp+MhuZreVLe/XD8Ecx8JqKirt7+ceMFfAX7O7S9HkA9uW9BnfY/juxG2f5tm BgjLzYw1pi/M70rmBESXqq8PE79uaMdv7OXc9rICCBEvMoIPiprMQsLDwyWs6uhneqm+gKtgvu77 52HgjTSAdAwDpz0ccp3Z6dPt2bJHe97wL1BjCIWED+Kz3YO6IBalv9N+hopKzaNzzfZf7x4cLnv6 lPTkIo6tixT6rdtsg078+YvedmOK+Q/6DlXBlf4lzGn1DrrWZXcjRRuVsxYd2m6aRO4moVGxsFGk MbHCxjGRiWlvonKyQHMVXMyEBLaiWGlaf596o9lQLKYT20DyD+BNnGkgSgmuM8weaKua0rDkvygc eqGsg480tCDoptgvINimOHWNEGR8/hOYDgh5GHowkIS0iA/ALxCXllBGNPmsPDD5VLqQaTL1J94U qcpcum02QcomicZdjPgVQqHvyOX808MYEYxT6QC2TQs0uJAETQWeHEjfTpzrfAygf1RRKVKH2qng 3Y4/0ucR5TQiIK/YzYDTsN7Uu596kwfBqBkMn+/8UDaiMgxxkeeB52KW+AmNpSKDJTuf+cMPKjr8 Mjhbi274SKMI+MYDzMgnHJ9SOrh+iAtGT5AX4REWlT+UbxoypRW+KlYHZYGGd8A08kZi6WMWfj// 88CfECBq5Pt3GkhKLFiSRy035PkgVUQXuvkGIxWZ9LdXWJ3xAOyLqdiUqbI0izhzq1hVRD0Vu9if zLEnt3IXpQB3E19bOELjlxCNxceqC3oubAxDMZ6c6aDt5uge62Zmm0RyNaGBcR3xKRAsW6hC5MjP qxtWJbg78Wn2ECsMXzmkkldiTP2P48dwejCp1AJa4qcFRujFeSZnoEJnq6uOB3MjDW6X8eir436C gHbWqNZDPotKznKjx1q9ssAk0FTFWZOpMx16F0etZv+GNTrH5o1m57TVaTa7rc6piqvf6P2LnVx0 j5rsuNUDrd5q9xhC6q4b3W6j0281e2De/vuy2+z12EWXtdqX563m8TbEenR+dQxRsXdXfRVd56LP zlvtVr8JaV+ACDcyohuQpdEnga56TXZxImSDtNsNhNqxs2a32eqw69b5uREfPIMiNym2buv0rE+S 4C8hjSYsRtxudo/O4GfjXeu8BQlfdFV8J61+B3NyghGwy0a33zq6Om902eVV9/Ki15TFiMbZABfJ h/7dvdb9JBYvt5efOeNZNlCcXPZpchk6gNFAbpYSMPjhwoAY8c0M/IpWO7K9uVQ1frYM7cpzv/dZ a3/HK/+xIdXPax7/l3H+3/7B7t5P4fl/By/x/L/d+t7m/L9vcdH5fzt0HhNYNdCGaAtqhW8ung0r 3Iyt4PD5Vf2wCkHzCnvrlracH44vjvo3l00G91jvptdvtllZPnc3vyvjQ2/xJpi/b8oLf1Z+q4Jm iyeId6YFY2gwAUsbTxTBw0HKqP07ZPPmr6SY6AvnwxS6BviLj79XOoWwRIcg8DEn9DY4gz0EMeks IRiIgGHKZ0G4LGU6/4QHxUaMZRGZbqhA74pgvzflcKhUjg8f9TekRHy8KzIlrxcOmDRzbxgNfuGA lQmlmTjcrIl75js8ukEwX6jxplOjn87Uv0dBOtdOTfzpoJO9K4ai9Hc8MsbgqefRfLoIh6QywHia 0PoyG3Qsho+Dz4zBJX/mBf86tfDz0C8qPpGKQ66SdHwKFtIICm3he1DRcFRTZjWqyzs78B7awcTu dwXQ3ziFyqmF99nOjpYHRx4XAkNGCLZ1hEWp2BkWJXuHWJRsnGKhfa/anBcU/mPrIItS4ZMswIiE 5L3pvT9f6zgLfH/tEy1KsSMtMsUpfK4FCVzlTUbU3UKHW0BDMoT+Vkdc8HxElE9Jn4B1UbaaaqbY R9RkJ4E/noK7O1L++J8jQV9iUSAZfE3dG0VlA21dssS2Lq0Ot/6sF5kCXNewYvCGGuayMHq6tJWL Pa1S/hDcw2gb/4JXsAa6zg+/HR03+o3fsNgyiNTw3u+/4wSYeBejDWNMyNX6FOrSVgqGOvZ1aRtl 4tddhRTNP6RlVDRGapUVjREWhkWXltKije9LxOhaCgS6tGWRAo2RfV0MtOXCCNJKYz0QtKq9NVHl 3STNqaONlb4sBi8ubdmhF5e2THyx2RxtQYqpmtiiFMusW8MUk9KyyinGGNNBxeY3toMjpnK0yCPG +OwCiXnXECMS52tByYxdrS1ZoeiSarSA0aUaaoWjizFFdXsddfsKgFyMoyAh16yxtji4pS0LINyS DRIuSlIUhZtaVDHGLT65EuQ2YiNZQNmiCHZYtrKuF4DZYhSSZptmJ66EosUIdRZtpFOzQpzFNNZG zuZTessgquGwqxgmVXamVjipGFkRUCq35tcjpeK7q6BSE1tqlZtlNhiommFVGIKKca1DQY2Preyx TlEma7BTiswK7ZRXoRy4U/lt4s0ui2ha1kbkCCzxnm6HYuLXdUNWTHgjadDOliPz6IEYQ4ZCk+kn xi0df4I5xLnGDGienCZaC2oSfTkH1cR8JR93RU41O4SqCyeeRd702XQnCyjiEuLU0XAi+kR2zYzR qWkpOjEuXnR+RZ9dSa8nCnuTWVFSYTjF6kM6Dee/rDLIlm3UCFyvc5eQcByBwYlVI/wiRlUSdSGz SjHcypdQFSVcxo2QZxyFnUmoeroUTi2aR8cEzSyrgNxGsAct5QaDLWppsiG0XCdHIaUbffz9m2Bx fTzf6OIcuvjvrxtzK8E0TGmiWtSzojFG3aVsUicZTKrl6msoW1voUbG0kZc9mjKkXGmAqZE1tak1 S+xMmoZaCZ5JMyq4AspoX86b8mzxdDseznj9xmXz4ghNXuo5GZqykoiU8yM002Y1eHQrAzC5HA6t Drv5BjIG5dJmj5nCwPxaHWZRCqamGk0d5cTYl9o9Xb1peiKMwdFgl/9zXdBKH/hbGy7fvK/TghJq javgl06MfOky891Mm2g3xSaKGUUpXWz6OOPrDDPsACwxaUsES5qEK4ywxFisMCz1OcE8EMvsTROr dPZL+IplswhtEBQxr7YQirRaYZGhSLJZgCiSiVaQomjO0dpiJZJklmCJGJcVWiJV/6K4RL0NFeMl yqUPK8BEjCw3MdEs8+JcRKO0i4ARMSIbZESaz8+PRtRM2Kx9NFm0P23cks7zS9OrCTA+iiiFxpdz 80+cL5cu5HoEOS5kcYQcxZPOkMu5ahn6N4lcZjK0cu+iinO8iibCDR+17/WFg9WWJx96Y+INMwi+ LNgb0zcVsVG0wl+Re2m5r4V0csCHGCKdrnFnbKUA3Un6ZsQcMyq9akV5ZVQEoqoSemVUeoPxfM7k DYzCcK6Ig65i3hea60XobSH9K3b3Dl6ytjebVVnjo1/VfCvkE0cwqpkGd/d+wr12g72s7+69Vrc0 Rwhn8gCVz91hP+6yV7s/sf3DA7b3+tU+PEI3cLM1uUDsSF+I0AtC84DQvR8qBLyqcPeHCnKvKvCo mD2EQZfvuae8daCtC78g9NFfYJG54l+nJgPwjXA/tWzVLbFPKNypgE88hnsq5W5MURFQ69MeHVxn hx4QGi/FI2ePREWYST1q9AxVJjZohnGNoW/ncxsDbxLMUWuh4wAzvUnD/k17W2xrEl0y3ypi7JwG EVrN/om+P1TsOcR9R2MxpSMivX8GdTXEVCgetfA8ENwgMRMzeZiiNTeCEqH83fr3wWgU9jPBVCX3 M7U0OfURDtHM7ef/+PN5PP8nTsbwv7a1ENxQbobKfelmKG1MTwiSKcai4fvVk8KSklS72eUNKWLj RoaIBW28eJDc6c5/qV2vq+11l1GiWiLmHFeNYj5JM00wj2MqIk/tNhjI8ZWqMThbJz3ghdrVqizF MiQ4kTQZlFPLSFiOfB/d1NhTq7kp6D4K0ClMYYzQAmOeCWV3dFnhxgy05f0Kd2SKPQV5VU+RwubP 1ZRGd5MVPLHtop4cueBnse4gJw4tXcf3Izp+oSv4fvDEKCym21NAeukKXijUJDrfch0bk/i9LjER 93SR3+PsNQ+NCa0IVJliJgH/VhSTGHyapFFKny40PctiT8QyUIwUmJlrk0+4Yn6bemYJGqjnsPkR 6+cwyUyIIgczxUxGGOYRN5q28hi93jtaihRbxWxpt/rQBm+xIxpPF2SO4TTJMw6Me4MAFUGCuXKw fwAFN3gYjYfj+wXr/fkMukt/jtxFNYOHfjPpP9puKP9Rxh1I0fgJHUiVu+hVT/cUjdtEPzJuEtUP 9lj91e6eZhJ98AY08NUfes0ODg8hmfCesp3mwdPtMPSHozC4+TwN3DjQzalhOAqkfdpkS6ssWWDS 1xTVo/A1VUo9pqypiIWy5vo3r65Gv5elutpkBMZVdAY1MF03E+pRa1USAqk3rDN/BJWsh64H4maG 1lBQycx2FudUrqgSjo2+BamTuuREq2Q8OCYzZ1VmiphMvFxRzHZEcyHQUhe0TUBMJu/EZI1zMTPl jjI2V5S4Y0isAJm60MjdZNqtmNRLsZuZGUjFem7U8P+LGm57iwRv/7wauLe7ggau59bA9Vwa2IR6 pitgYp3qOgwRqHorQ7QqPML4jVgby01XzWxvCQzXFXVGI6LliLeq56WB9Fam7qRbzzF+a6b0iWDY jabYaIpcmqKeV1NUxLR74sTpemDadN1wo7cnDuLVW9NNlYnAWEOK1M78oyqF+DVGVlUWhhdKy9AQ xA821EOV8bBCaRj2LAcTGzPKVSYCC6ViGJ6cd2xYnlUBQV4pFX2yVw5BtPneQzXfu3xqyZg0wsqa ULm1XzM3XFEQywgOApfh3++Nt9pcm2tzba7Ntbk21+baXJtrc2nXfwBjZwD8AMgAAA== ------=_NextPart_000_0004_01C0F852.63CB2BC0-- From w3c-dist-auth-request@w3.org Tue Jun 19 00: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 ESMTP id AAA00246 for ; Tue, 19 Jun 2001 00:44:22 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA28329; Tue, 19 Jun 2001 00:43:04 -0400 (EDT) Resent-Date: Tue, 19 Jun 2001 00:43:04 -0400 (EDT) Resent-Message-Id: <200106190443.AAA28329@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 AAA28238 for ; Tue, 19 Jun 2001 00:42:49 -0400 (EDT) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA09245 for ; Tue, 19 Jun 2001 00:42:49 -0400 Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA24735 for ; Tue, 19 Jun 2001 00:13:44 -0400 (EDT) Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id D0D9B49B67; Tue, 19 Jun 2001 14:13:43 +1000 (EST) To: w3c-dist-auth@w3.org Message-Id: <20010619041343.D0D9B49B67@io.mds.rmit.edu.au> Date: Tue, 19 Jun 2001 14:13:43 +1000 (EST) From: ajk@mds.rmit.edu.au (Alan Kent) Subject: Newbie questions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5029 X-Loop: w3c-dist-auth@w3.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 am new to this list so I appologise if these are ignorant questions. I have been reading all the WebDAV (and DeltaV) documents I can get my hands on, but have a few issues that I do not understand. Q1: When are null resources created? You can "lock a null resource in order to lock the name". Is it that if you do a lock on a name that does not exist as a resource, a null resource is created? Are there other ways that null resources can be created? The text says you lock a null resource to create a lock-null resource. A lock-null resource has properties and appears under its parent container. A null resource does not appear under its parent. The definition of null resource is that it is a resource that responds to requests, which implies that it exists. My guess is that any URI that is not bound to a resource is implicitly bound to a null resource which has no properties or any other state. When you lock a null resource, a lock-null resource is created allowing it to be placed under its parent container and have properties. Is this correct? Q2: Are locks on resources or URIs identifying resources? The DeltaV documentation I have read I think said that locks are applied to the resources identified by a URL. Q3: The MOVE documentation says that a successful MOVE on a write locked resource must not move the write lock. (It then talks about collections and locks.) If the resource being moved is locked (that is, the resource itself, not the collection it is in), why is the lock removed when the resource is moved? If the lock is applied to a URI, does this mean a lock-null is left for the old URI? If the lock is applied to a resource, why does not the lock stay with the resource that is locked? Or is the text in sectino 7.7 only relating to parent collections that have been locked and has nothing to do with locks directly on resources? Q4: PROPFIND in section 8.1 talks about responses and errors and multistatus XML elements. I have read the text several times but is confusing. It says servers must support returning a multistatus element. (It does not say that it must *always* return one, just that it must support it.) It then says errors must be returned as 404 *if* a multistatus element is returned. etc. It was not clear when a multistatus element must be returned - is it optional or mandatory? Related, how to know when to return multistatus elements in general? Examples of packet communications are given, but no formal request/response packet grammar is given. Q5: MKCOL behaviour with message bodies is not defined in the standard (section 8.3.1) but may be "defined elsewhere". Is there any such defintion around? Or is the body of MKCOL not important for interoperability. Q6: Is there any clear definitative list of which properties are "live" properties? My understanding that any property that is not a live property is a dead property, therefore if I used a property name such as DAV:xyz which is currently not defined, its dead, but later if DAV defines xyz, then it would suddenly become live. I assume the protection here is that I should never use DAV: because its a DAV namespace. Q7: DELETE is defined to delete a non-collection resource, removing all URIs to that resource, not just the URI passed to the DELETE command (section 8.6.1). Other sections such as MOVE and COPY talk about deleting the destination. To me this therefore means that if /foo/a and /bar/a are bound to resource R1, then a COPY with overwrite to /foo/a will delete the URIs /foo/a and /bar/a and resource R1 then create a new resource R2 and only bind /foo/a to the new resource R2. Or should /foo/a and /bar/a both bind to R2? I noticed that DeltaV changes the DELETE semantics relating to versioning. Q8: In DeltaV, versions are given stable URLs such as /his/73/vr/1. Should these URLs be made visible via containers? Ie: should /his be a container, and /his/73, and /his/73/vr? Or are these URLs hidden from containers? My understanding that there is no standard for "/his", its whatever the system chooses. It just seemed a potentially very expensive operation to get a listing of the contents of "/his" as a container since it would contain a child container for *every* versioned resource history resource. A short background - we have a document management system are trying to work out how hard it is to support first DAV and then DeltaV. The document management system uses the DMA versioning model, hence any experiences of relating DeltaV to DMA would also be appreciated - although this is probably the wrong list for DeltaV questions. Thanks for any help people can provide. I relise mail with lots of questions can be a pain, but it was either that or send in lots of separate ones (which I find worse)! Hopefully there are simple answers to the above. Alan Kent From w3c-dist-auth-request@w3.org Tue Jun 19 03:22:08 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15877 for ; Tue, 19 Jun 2001 03:22:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA04232; Tue, 19 Jun 2001 03:20:52 -0400 (EDT) Resent-Date: Tue, 19 Jun 2001 03:20:52 -0400 (EDT) Resent-Message-Id: <200106190720.DAA04232@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 DAA04212 for ; Tue, 19 Jun 2001 03:20:29 -0400 (EDT) Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA20848 for ; Tue, 19 Jun 2001 03:20:26 -0400 Received: from aptiva (62.6.116.221) by mail.san.yahoo.com (5.5.032) id 3B291AC100077B9A for w3c-dist-auth@w3.org; Tue, 19 Jun 2001 00:16:35 -0700 From: "Tim Ellison" To: "WebDAV WG" Date: Tue, 19 Jun 2001 08:17:01 +0100 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.00.3018.1300 In-Reply-To: Importance: Normal Subject: RE: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5030 X-Loop: w3c-dist-auth@w3.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 > > Maybe you can get a few minutes in the London meeting to gauge feedback. > > The problem, of course, is that if people don't like it, they won't > > implement it. > > Which meeting? IETF51 which is being held in London (http://www.ietf.org/meetings/IETF-51.html) Tim From w3c-dist-auth-request@w3.org Tue Jun 19 10:15: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 KAA22022 for ; Tue, 19 Jun 2001 10:15:42 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA10544; Tue, 19 Jun 2001 10:08:30 -0400 (EDT) Resent-Date: Tue, 19 Jun 2001 10:08:30 -0400 (EDT) Resent-Message-Id: <200106191408.KAA10544@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 KAA10496 for ; Tue, 19 Jun 2001 10:08:21 -0400 (EDT) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA28324 for ; Tue, 19 Jun 2001 10:08:21 -0400 Received: from gmgw02.us.oracle.com (gmgw02.us.oracle.com [130.35.249.110]) by inet-mail4.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5JE2Vf24640 for ; Tue, 19 Jun 2001 07:02:31 -0700 (PDT) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by gmgw02.us.oracle.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f5JE7nj07653 for ; Tue, 19 Jun 2001 07:07:49 -0700 (PDT) From: "Eric Sedlar" To: "WebDAV WG" Date: Tue, 19 Jun 2001 06:59:58 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Subject: RE: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5031 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit This spec is cool. I think it should be folded into the new RFC2518. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Monday, June 18, 2001 2:57 PM > To: WebDAV WG > Subject: RE: Proposal for marshalling property type information > > > Attached is an updated version of my proposal which should address Tim's > concerns (Tim, thanks for the feedback!). > -- > > Network Working Group J. Reschke > Internet-Draft greenbytes > Expires: December 17, 2001 June 18, 2001 > > > Datatypes for WebDAV properties > draft-reschke-webdav-property-datatypes-00 > > Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on December 17, 2001. > > Copyright Notice > > Copyright (C) The Internet Society (2001). All Rights Reserved. > > Abstract > > This specification extends the WebDAV Distributed Authoring Protocol > to support datatyping on property values. Protocol elements are > defined to let clients and servers specify the type of a property, > and to instruct the WebDAV method PROPFIND to return datatype > information. > > Distribution of this document is unlimited. Please send comments to > the Distributed Authoring and Versioning (WebDAV) working group at > w3c-dist-auth@w3.org[1], which may be joined by sending a message > with subject "subscribe" to w3c-dist-auth-request@w3.org[2]. > > Discussions of the WEBDAV working group are archived at URL: > > > > Reschke Expires December 17, 2001 [Page 1] > > > Internet-Draft Datatypes for WebDAV properties June 2001 > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/. > > Table of Contents > > 1. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 > 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Overview of data types . . . . . . . . . . . . . . . . . . . . 5 > 4. Changes for PROPPATCH method . . . . . . . . . . . . . . . . . 6 > 4.1 Example for successful PROPPATCH . . . . . . . . . . . . . . . 6 > 4.2 Example for failed PROPPATCH . . . . . . . . . . . . . . . . . 7 > 5. Changes for PROPFIND method . . . . . . . . . . . . . . . . . 9 > 5.1 Example for PROPFIND/prop . . . . . . . . . . . . . . . . . . 9 > 6. Compatibility Considerations . . . . . . . . . . . . . . . . . 11 > 7. Internationalization Considerations . . . . . . . . . . . . . 12 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 > 9. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . 14 > 10. Intellectual Property . . . . . . . . . . . . . . . . . . . . 15 > References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 > Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reschke Expires December 17, 2001 [Page 2] > > > Internet-Draft Datatypes for WebDAV properties June 2001 > > > 1. Notational Conventions > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > The term "property element" refers to the XML element that identifies > a particular property, for instance > > > > The term "prop element" is used for the WebDAV "prop" element as > defined in section 12.11 of [RFC2518]. > > The XML representation of schema components uses a vocabulary > identified by the namespace name "http://www.w3.org/2001/XMLSchema". > For brevity, the text and examples in this specification use the > prefix "xs:" to stand for this namespace; in practice, any prefix can > be used. "XML Schema: Structures" ([XS1]) also defines several > attributes for direct use in any XML documents. These attributes are > in a different namespace, which has the namespace name > "http://www.w3.org/2001/XMLSchema-instance". For brevity, the text > and examples in this specification use the prefix "xsi:" to stand for > this latter namespace; in practice, any prefix can be used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reschke Expires December 17, 2001 [Page 3] > > > Internet-Draft Datatypes for WebDAV properties June 2001 > > > 2. Introduction > > This specification builds on the infrastructure provided by the > WebDAV Distributed Authoring Protocol, adding support data-typed > properties. > > Although servers must support XML content in property values, it may > be desirable to persist values as scalar values when possible, and to > expose the data's type when the property value is returned to the > client. The client is free to ignore this information, but it may be > able to take advantage of it when modifying a property. > > On the other hand, when setting new properties, it can be desirable > to pass data type information along with the value. A server can > take advantage of this information to optimize storage and to perform > additional parsing (for instance of dates). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reschke Expires December 17, 2001 [Page 4] > > > Internet-Draft Datatypes for WebDAV properties June 2001 > > > 3. Overview of data types > > Although WebDAV property types can be anything that can be marshalled > as content of an XML element, in many cases they actually are simple > types like integers, booleans or dates. "XML Schema Part 2: > Datatypes" [XS2] defines a set of simple types which can be used as a > basis for supplying type information to attributes. > > Data type information is represented using the attribute "type" from > the XML Schema namespace "http://www.w3.org/2001/XMLSchema-instance". > In XML Schema, data types are qualified names, and the XML Schema > recommendation defines a set of built-in datatypes (section 3 of > [XS2]), defined in the namespace "http://www.w3.org/2001/XMLSchema". > > To avoid unnecessary verbosity, data type information should only be > supplied if it adds usable information to the protocol. In > particular, type information is not required for live properties > defined in WebDAV [RFC2518] and related standards and properties of > type "xs:string". > > A server may implement any combination of datatypes, both from the > XML Schema recommendation and possibly from other namespaces. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reschke Expires December 17, 2001 [Page 5] > > > Internet-Draft Datatypes for WebDAV properties June 2001 > > > 4. Changes for PROPPATCH method > > If the property element has an XML attribute named "xsi:type", the > server may use this information to select an optimized representation > for storing the property value. For instance, by specifying a type > as "xs:boolean", the client declares the property value to be of type > boolean (as defined in [XS2]). The server may choose any suitable > internal format for persisting this property, and in particular is > allowed to fail the request if the format given does not fit the > format defined for this type. > > The server should indicate successful detection and parsing of the > typed value by setting the xsi:type attribute on the property element > in the response body (this implies that it should return a > MULTISTATUS status code and a response body). > > 4.1 Example for successful PROPPATCH > > >>Request > > PROPPATCH /bar.html HTTP/1.1 > Host: www.foo.com > Content-Type: text/xml > Content-Length: xxxx > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xmlns:Z="http://www.w3.com/standards/z39.50"> > > > false > > > > > > > > > > > > > > > > > > > > Reschke Expires December 17, 2001 [Page 6] > > > Internet-Draft Datatypes for WebDAV properties June 2001 > > > >>Response > > HTTP/1.1 207 Multi-Status > Content-Type: text/xml > Content-Length: xxxx > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xmlns:Z="http://www.w3.com/standards/z39.50"> > > http://www.foo.com/bar.html > > > HTTP/1.1 200 OK > > > > > In this cases, the xsi:type attribute on the element "Z:released" > indicates that the server indeed has understood the submitted data > type information. > > 4.2 Example for failed PROPPATCH > > >>Request > > PROPPATCH /bar.html HTTP/1.1 > Host: www.foo.com > Content-Type: text/xml > Content-Length: xxxx > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xmlns:Z="http://www.w3.com/standards/z39.50"> > > > t > > > > > > > > > > > > > Reschke Expires December 17, 2001 [Page 7] > > > Internet-Draft Datatypes for WebDAV properties June 2001 > > > >>Response > > HTTP/1.1 207 Multi-Status > Content-Type: text/xml > Content-Length: xxxx > > xmlns:Z="http://www.w3.com/standards/z39.50"> > > http://www.foo.com/bar.html > > > HTTP/1.1 422 Unprocessable Entity > Does not parse as > xsd:boolean > > > > > In this case the request failed because the supplied value "t" is not > a valid representation for a boolean value. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reschke Expires December 17, 2001 [Page 8] > > > Internet-Draft Datatypes for WebDAV properties June 2001 > > > 5. Changes for PROPFIND method > > PROPFIND is extended to return the data type information for > properties unless one of the following conditions is met: > > o The data type MUST be different from "xs:string" (because this can > be considered the default data type). > > o The property's data type MUST not defined in [RFC2518] (because > these types are already well-defined). > > > 5.1 Example for PROPFIND/prop > > >>Request > > PROPFIND /bar.html HTTP/1.1 > Host: www.foo.com > Content-Type: text/xml > Content-Length: xxxx > > xmlns:Z="http://www.w3.com/standards/z39.50"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reschke Expires December 17, 2001 [Page 9] > > > Internet-Draft Datatypes for WebDAV properties June 2001 > > > >>Response > > HTTP/1.1 207 Multi-Status > Content-Type: text/xml > Content-Length: xxxx > > xmlns:Z="http://www.w3.com/standards/z39.50" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:xs="http://www.w3.org/2001/XMLSchema"> > > http://www.foo.com/bar.html > > > text/html > 1 > > HTTP/1.1 200 OK > > > > > This example shows that the property value "true" is returned with > the correct data type information, and that the server chose one of > the two possible representations defined in XML Schema. It also > shows that data type information is not returned for > "D:getcontenttype", as this property's data type is already defined > in [RFC2518]. > > > > > > > > > > > > > > > > > > > > > > > > > Reschke Expires December 17, 2001 [Page 10] > > > Internet-Draft Datatypes for WebDAV properties June 2001 > > > 6. Compatibility Considerations > > This specification does not introduce any new protocol elements, nor > does it change the informal WebDAV DTD. It merely specifies > additional server semantics for the case where clients submit > additional data type information in an attribute on the property > element (previously undefined), and adds an additional attribute on > property elements upon PROPFIND. > > Clients not aware of this specification should not supply the > "xsi:type" attribute on property elements (after all, this attribute > belongs to the XML Schema-Instance namespace which has been defined > for exactly this purpose). Old clients should also ignore additional > attributes on property elements returned by PROPFIND (and similar > methods), although the WebDAV specification only defines this > behaviour for unknown elements (and is silent about unknown > attributes). > > Servers not aware of this specification either drop the "xsi:type" > attribute, or persist it along with the property value. However, > they will never indicate successful parsing of the data type by > returning back the type in the response to PROPPATCH. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reschke Expires December 17, 2001 [Page 11] > > > Internet-Draft Datatypes for WebDAV properties June 2001 > > > 7. Internationalization Considerations > > This proposal builds on [RFC2518], and inherits its > internationalizability. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reschke Expires December 17, 2001 [Page 12] > > > Internet-Draft Datatypes for WebDAV properties June 2001 > > > 8. IANA Considerations > > This proposal does not introduce any new IANA considerations, since > it does not specify any new namespaces (in the general sense), but > merely uses existing ones. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reschke Expires December 17, 2001 [Page 13] > > > Internet-Draft Datatypes for WebDAV properties June 2001 > > > 9. Copyright > > To be supplied by the RFC Editor. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reschke Expires December 17, 2001 [Page 14] > > > Internet-Draft Datatypes for WebDAV properties June 2001 > > > 10. Intellectual Property > > To be supplied by the RFC Editor. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reschke Expires December 17, 2001 [Page 15] > > > Internet-Draft Datatypes for WebDAV properties June 2001 > > > References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and > World Wide Web Consortium, "Extensible Markup Language > (XML) 1.0", W3C XML, February 1998, > . > > [XS1] Thompson, H., Beech, D., Maloney, M., Mendelsohn, N. and > World Wide Web Consortium, "XML Schema Part 1: > Structures", W3C XS1, May 2001, > . > > [XS2] Biron, P., Malhotra, A. and World Wide Web Consortium, > "XML Schema Part 2: Datatypes", W3C XS2, May 2001, > . > > [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. > Jensen, "HTTP Extensions for Distributed Authoring -- > WEBDAV", RFC 2518, February 1999. > > [1] > > [2] > > > Author's Address > > Julian F. Reschke > greenbytes GmbH > Salzmannstrasse 152 > Muenster, NW 48159 > Germany > > EMail: julian.reschke@greenbytes.de > > > > > > > > > > > > > > > Reschke Expires December 17, 2001 [Page 16] > > > Internet-Draft Datatypes for WebDAV properties June 2001 > > > Full Copyright Statement > > Copyright (C) The Internet Society (2001). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph are > included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assigns. > > This document and the information contained herein is provided on an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > Acknowledgement > > Funding for the RFC Editor function is currently provided by the > Internet Society. > > > > > > > > > > > > > > > > > > > > Reschke Expires December 17, 2001 [Page 17] > > > > > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > > Sent: Monday, June 18, 2001 9:55 PM > > To: Tim_Ellison@uk.ibm.com; WebDAV WG > > Subject: RE: Proposal for marshalling property type information > > > > > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of > Tim_Ellison@uk.ibm.com > > > Sent: Monday, June 18, 2001 11:07 AM > > > To: WebDAV WG > > > Subject: RE: Proposal for marshalling property type information > > > > > > > > > > > > > > > "Julian Reschke" wrote: > > > > Now I'm tempted to agree that these should be returned. A minor > > > > issue is with DAV:getlastmodified, because it's format isn't > > > > xs:dateTime, meaning that we have to define a datatype for it in > > > > the spec. That's why I'd still prefer to leave them out. > > > > > > Whatever, the set of relevant properties is so small I don't > > > think there is > > > a problem either way. > > > > OK, this allows me to avoid specifying a datatype for RFC dates > > in the spec. > > > > > I agree that clarification is good. As an aside, I wonder > what a client > > > would do if it received an unexpected 200 OK back from a > > > PROPPATCH -- would > > > a reasonable implementation really signal a failure? > > > > Depends on what you call reasonable. I haven't written a client > > yet, but up > > until your comment I would have been tempted to think I'll always get a > > multistatus. > > > > > > > > Do you think it would be a problem to require the 207 > > > > > > > > response in this case? > > > > > > > > > > You may get pushback from some server writers. > > > > > > > > Well, unless somebody suggests a better approach, I'll have > > to live with > > > > that. > > > > > > Maybe you can get a few minutes in the London meeting to > gauge feedback. > > > The problem, of course, is that if people don't like it, they won't > > > implement it. > > > > Which meeting? > > > From w3c-dist-auth-request@w3.org Tue Jun 19 11:08: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 LAA23521 for ; Tue, 19 Jun 2001 11:07:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA15533; Tue, 19 Jun 2001 11:01:31 -0400 (EDT) Resent-Date: Tue, 19 Jun 2001 11:01:31 -0400 (EDT) Resent-Message-Id: <200106191501.LAA15533@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 LAA15478 for ; Tue, 19 Jun 2001 11:01:17 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA03497 for ; Tue, 19 Jun 2001 11:01:04 -0400 Received: from lisa [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Tue, 19 Jun 2001 17:00:01 +0200 From: "Julian F. Reschke" To: Date: Tue, 19 Jun 2001 17:00:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0034_01C0F8E1.46A98A20" 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 X-MDRemoteIP: 192.168.1.2 X-Return-Path: julian.reschke@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: RE: Issue: XML_LANG_CLARIFY Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5032 X-Loop: w3c-dist-auth@w3.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_0034_01C0F8E1.46A98A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I've spend some more time thinking about this issue, and actually implementing my proposal in our server. Text was added to section 4.4 which tries to define what a property value is, using the W3C recommandations "Namespaces in XML" and "Canonical XML" as base. BTW: I think the first sentence "...when expressed in XML MUST be well formed." is misleading. In WebDAV, there's no way to express the value of a property other than in XML, so it will by definition be well-formed. Feedback appreciated, Julian -- 4.4 Property Values The value of a property when expressed in XML MUST be well formed. XML has been chosen because it is a flexible, self-describing, structured data format that supports rich schema definitions, and because of its support for multiple character sets. XML's self- describing nature allows any property's value to be extended by adding new elements. Older clients will not break when they encounter extensions because they will still have the data specified in the original schema and will ignore elements they do not understand. XML's support for multiple character sets allows any human-readable property to be encoded and read in a character set familiar to the user. XML's support for multiple human languages, using the "xml:lang" attribute, handles cases where the same character set is employed by multiple human languages. (added text starts here) The value of a property is defined in terms of the W3C recommendations "XML Information Set" [XML-INFOSET] and "Canonical XML" [RFC3076]. It consists of a subset of the property element's information items, of which some are optional (that is, a server MAY choose not to persist them). [prefix] (optional) The namespace prefix part of the element-type name. [children] (required) An ordered list of child information items, in document order. Note that the full Information Set of each child is part of the value. [attributes] (required) An unordered set of attribute information items. [namespace attributes] (optional) An unordered set of attribute information items, one for each of the namespace declarations. [in-scope namespaces] (optional) An unordered set of namespace information items, one for each of the namespaces in effect for this element. [base URI] (optional) The base URI of the element, as computed by the method of XML Base. In addition, attributes from the XML namespace (http://www.w3.org/XML/1998/namespace) are inherited by means of section 2.4 of [RFC3076]: xml:lang (required) other attributes from the XML namespace (optional) 4.4.1 Examples for property values Set request: xyz Inheritance of attributes from XML namespaces as defined in section 2.4 of [RFC3076]: xyz The value of the property named ("http://foo.bar.com", "bar") thus is: [prefix] "foo" [children] 3 character information items [attributes] attribute information items, describing "attr", "xml:lang" and "x:space" [namespace attributes] (empty) [in-scope namespaces] the namespace information items (no value, "DAV:"), ("foo", "http://foo.bar.com"), ("x", "http://www.w3.org/XML/1998/namespace"), ("xml", "http://www.w3.org/XML/1998/namespace") [base URI] no value Removal of optional information: xyz The value of the property named ("http://foo.bar.com", "bar") then becomes: [children] 3 character information items [attributes] attribute information item, describing "attr" and "xml:lang" ------=_NextPart_000_0034_01C0F8E1.46A98A20 Content-Type: application/x-gzip; name="rfc2518-propattr.tar.gz" Content-Disposition: attachment; filename="rfc2518-propattr.tar.gz" Content-Transfer-Encoding: base64 H4sIAMhoLzsAA+xcW28bOZbuV/tXEFosNgEsWRdbttKJZxVZ6Xjbl6ytJNtYLBpUibJqUqrS1sW2 ejD/JW/7N/dcyFJJLEusdKMzDyMgsS2SH885PDde46nXPm6d1hdxtJBpGjdm6Tz44Y/9NFvNZvfo 6IcmfE669BO+adHfrWa72Tpu/9A86bQ63e5R+6gL9Tuto+MfRPMPpqP0kyWpjIX44a+x2lrvZ+WH fwY9f/Ln9V+e5oF4UHHiR+GbWqvRrAkVetHED+/f1Pwkqp+eHvfqrdpfzl6jagioHiZvarM0Xbw6 PHx8fGw8dhpRfH/Y6vV6h09YpwZVlZycvU79NFBn70ejD2L4lKoQ+0jENIrFuZ+ksT/OUjUR/Syd RTH0J+p18Xn49rz/6fUhN32dpMtAiXS5UG9qqXpKD70kqZ3t9/f/tr+Hf9cnyotimQLwKxFGodr/ +37/1SwChkqrZOFExYGv60kv9R/Uzopvb85/wUpeFETxK/EvTfr8uC/gM43CtD6Vcz9YvhIzFTyo 1PfkgZCxL4MDkcgwqScq9qeF6on/m3olWp3F04+A/r5VxO7Qx67cxcr4JdJUnyn/fpYWv65Ax95C 3qv6OFbyS11OUwXdyofInxAx7a2MamKO/uheOy69dv7gXj9gp3MZ3/thPVBTEGdbzbkH/W3MUqav of7t0GrRMS3Wxw9qj/pvL6n+BgtYdN5A+2AVNQ2n9LG5bpZyrVktML+paQ8y8O9BkdNoAV02vGix JHY2SWoSSY1ZlI7ABlYU2QQ9aqULo3guAy4otcESer0dw1SgqMcEgZ5/abuQM46CSTViKpmpJuf2 3aBATJc+fwIxJYIhz1jUnF6v1F7a7VKXsfp6G+FaeUhj6Os9Z6KBxv1/n6uJL8UCvHoq/kaw9GmE kf5u4ieLQC5foVT+Dk1eH5KrP3t9yKFjHE2WEEDkGNy/F8gEQo5uWwNaYzCeNzUIVZ4KgoWccLTS fycL6dHf7Zp49Cfp7E2tA0UsAAhxxzVB7L2pEXsQrdIY/k3E+J5E+qamXVBez1MhuI6atqnV3yXo 8DsQD4FrIUNDOOhO7ewr/P8VuITvgUmoMY4P16tpE6ydYUKW10wn+F9cQiSPu0VkOctnr6WYxWoK 7eKp10gjryYGl/27uzc1sjSk2hCiv/g6ukGKgdRDWSTkkEbFDI7urtv91+cHprUxMK2VzA21HWye s8b2VcslQ96ydnat0sco/iI+w3+YL/wUR9niK5NWFeuXhvgpCmQ4+WrLuBLQrfrfTCUppTWDaD6H YUjAzGAMv5GyK9+LoySapr+XspXdgf0OZKruo3j5qvituEtBAjKeJGIUS+/LN1I8bIjPMz9V+Pfv JfobSfg4EBfxAzi679R/vyHeSf83/zt1D5aReHLxvbi/a9w2xEDG4IC+EwXnDfEfMMFQ4fcaAJhy BMF36vydGseZjJcC52BfS1w1xZqJ/7AZ+Irhh/KK2rfN1nSsgh5g6tc6A6+SZomIpiKd+Ym4UvMI 4nrr7PVizSeJvREWTyIvQ68pkoXy/KmvEgFUXWA0CxV8m7uoFF0UJBURRK8oIMrSmcpr7u/BxwMP nIV+uoTMJJyImJ0zdOInXpYgS/R9kt3fw/c5h/4cYB8UOe8GAX0IlEwUAEwVdBNRT14Wx0goJDfY lBlUopbTejOd+h7kQ+KDJpKgcidbEy/uRuei9TKn3TDn/0ZZIv6dKqZwTYZ7BGRYb6xGJCcDBDkH OQv4mYWBPwd3PGkUpL33+nBBgzMwMwFxHUEKp/KR2dtbFb0YvBSjgmzFXeT5Kl2KF6hiLxuiHwTi Fqsm4lZB3vdgejPd9McJjldK8FiwD308O94igT6Aj7kC7ZokOLNB1U54FD3IPaFBHdcBEuxFhp4f BKjxMDKosYetRisX6lyGMOujLgAyVkmUxZ5CxVmoOIX+DhDDg0lhavThmSYg60B5pCYHIpRzhSmM 2qcZYugvsoAQjKrpRkHkUXbyAlv7rHI45wSi1csGymd/7/UsttJaTNspV0pmwDtmUYf/zID/oTNg SToBUtR4pPgjGjHQogFrbcIGhghZABo1h8EBivQvuS/n9uMNKhPWvgZkzC2E+Jpb9N4e2GYcTTKq sJLncwjATnsTARwAKTA4LCD2AYhFTd+N1amddTaxRiqe+yEMzP1yN8BR7exoE+BcplJcRRPFnv3W mNOH3GwdcFFQ8J9FHHiFTcAld+YC2kZQS3rDJ3DCaOhXKpUTpB6Ro0QGTpR2ENQS44pbcioUjd+z L3QBRcE2LNHmHH+SQeYmRy3JElkOn+R8ESiOmwuD/OCMfIy4x8+SeI1e1gWnizjdTZwrWni4CCdq oeA/8OeXYMsOgECWRdRg5f7RoD+rca5FLogowmNbgDSmH28vmVUMKK6aeIyaeGxr4orOavR1EM1S wUExMN4qyDMUjC57tG/r5wj7sbTyjs0xR6L+brJ0kaVV4EEPLC245BDs0BjHqFum5F6QJf6DEp+S hribyRhSX0R1IQhHqWuPEi4U+Ihzly0WUZy6IHUQyRohJESMoi/KxVl3UfxdW/zRQkJujMlKikhi BQrKeSHuvBnkQ07wLMMSV3ENai3e+SqYiJ9UqHglVHz2IceDMabcfTgcitNmW/QnE0ignNg5xt4s WyXyB3Ihx34A6T9myB5uAzlEoy7pkO1L+rQ9xIKpBHeCcCebcB8TSDEx0Cb+RMvCgV/AspA+x5Dd E10O7XF0TuyxueJMGy0NLNzDqd14KVbILqShop/Yil4AIZuupK4nqPMnts5vglZJC07QBE5sE9jE vM5wVuPuek5QF09sXdzELcQRF9AuglrauAlK5jMVZvmRkwQneNaIUq9HoV3URTUNQx219d2Sws2H Xw6vbj4NXSBPEfLUdqFT8BIzTLoqaSqgWVgUho0VPLvKUY59NRy9vzn/9cPtzYd3F9fngG4L0xQ6 UNdo4ZDQj+eHREdi5B0Th2oWgNht7qIkjzVdfEwQXcKEEqBxaq37VDTdr9pfh/uzLHmzP+wM51Fr HcpVh1tzwsJIfOiPBu+xT4vDvNSF8DaPRdseC72sNYCoxhqTJbj/kc5Eu3kiXlxlQerXudJLt57a 3NOWIdlBumb/6ufBzSViWcKmEq3mLjR1mPuOzb12NG4gbQaxGCuK0A2pw0hbtIhYdAE7QigrCPw0 HB2I98P+ud7BqeCqT9H/n5ZMZm7uRm5oevzOh5fD0RCxLLfPRS60dHnoSvw6YxBF11FY/7Y0/pQT W/qxpYOKAuwae+uWWdxqkLeJwfiAjyMEsuIQfO9CyQnTUZIqAcDvlt0Jy64kWzLorrqCYRShrICG BRUs/ZT5LYlcBIQk5SurcRVWT5nVEj+cA1cLJafsBEq8Ww5YUeu0LyjxBoRo0qsbSPgfKc9wza5O jU8o8QpVfd8pJoL043mzIHIpBOW0ukGfMLRlLGXQ11FV9FNGt1R0Az2aClkYuu0hDhJHRO1ZEQ4K Kqh9j9W+VzIjQqDq2tljde/Z6p4DVtTOHut7rySaI+Lv0c4eK36vZDWmonb2WM97tp4XIjOSS4O8 7jrd8LuMv0X7V/iOSnR5M/iZstKmtXwAJRW0qNXUGXvT1qObhZ7dOwK1NZClP7hqPZxOoS4yyRMp iDsbS8QVlQs66ugOS9eVMCO/VYvA9yROhCoFOcA80tj28r5agCsxywFOi3MEdKwBLTWjrUnJoZjc VARGEZsZnSN6V6OXriDicZ4FjKReUaKNHUfcE41r+deqZgYYpxprize98+kXIrpCng6gPQ1uudXi xDOfdMtKCwNsHk1jJ5bNFQyZpk75Ds1uPrQ9f7zOLdoyQy6rYtNmFr51Gs6wu/FAsJZMi7s5VZcc cIYyvP31vP8JgEtS/P6nrWHANEcrRAA7hSf7dILAXS9ycAhkOZFCuQvcxRRRLHdxMXWOaj1ege6V r0DXU3lfD0DO6Dedd0sJLEfdpg/FHioS3WZ42+/L+3s1+Tai24borbMp7kFcaqJnFYjuMLw17GFU ndgjxrIG/0qmHvmbd1lYAe6Y4exIYYaFF3khFUFrQece+DIksp+eTfa0mqJLqtMaNnZSuvvAxS46 n2duiGWFHre8TkNxPKl/vL1ArGfCDRZjJF9AjuCEOvLnKspShLSiji6rvPCMgcCOAYV4WDx1VjjW U458N+qPPt792mq2EdXWdSjAcYXEJXnWpWqMdvOEMCw7xFW94qLeVpSjNlNiGQYUiI/hgmmhsyHD MIV8Ygdah9As04ACCo/qmZCWtz+i9paiQgEeVA3A+s/1Frm3nZRjLR5LT6FAXIRJRmfecKf9Lo1i ee+QIrXwOIs9/yqIOtdWBzCUuzV2/3V1KYYBn+g6V1M/9LdkyMPL4dXwevQr3wfDLVGEtJVqVS4K +NsxJxxxEc4GpEJ3rHyzVuNZXK92c50xU2PqhGhpry52x1sdmSNIi8RVuTsm/kloFnlYUkF+fsgj a5kVllQY04TlVZJwQJE7ThJ7GscSExRV0wuoFC8JzbL5vLgaoh9OIwK0LN+UVsNLPJi3EqAVpvJi d0RlTmgwoj0SeYUK40HnPDSgPSR8CqSatS41y1YYNaXueDpjQDCbW04YnLHm6Gv5iDEhWlOVQgV3 1Fg7bYa0iTTl7oi4N4hUGEQb09SoMMoFtsuc6LdyDTN6L/YXuesrmWSVVHXvJ3oM8bA/+mkrjaKy amJlpFJ5EpByBcIt2rGayQcfZu+MajG+US927+GLUgsZGDsvi8p5DXfQaO6nBs+iFQurSyBbTKQ2 z5YVptYruYPHah4Zzku2ZLnYHS5RqcGytV5VZBpyKnaVLSuammJ3hdRnDjReSealzyRU0nA8VGAQ SzWSTh3shFxLNjEtt5c8YDq5a9MAN/KHt6NffjX3DrS6lAxrsUZ+CGIHqr5Pq1kuGd9CBVfMe5Xq mxeBDO8zSO0J2mLfrvcNPajwnvLkjp2cbdaqjq7DcMfOjdbrVEBWqbwnSCs70oUVsAKZpPNogndh JoRpJUgblVyxMcmYmJOLhFyah+RVduCuWwLvIPNPp2NLuGlVpbucDbP9nA+jla4Ua7iicgs2QSug btwVcJIHbwrpX56XSF84ga/o5OPCaqInpp2SqL1WpyLVLUO16/Ezurj2rR3iuoS92hsmaZzpk/Z6 C1Yv3ZB/9kNB9wx3oh8DumXjxdU+EPsAL9y47L606AR/q+QIP0GIZ5amNiDaBGGfhSCItgNEFwAs J8MX8/TtHXN7sOrZ4hau7NhrhsrLYtzwqg5H8iqZi+HeBt4u8phOvEoQ+Hw3ygG0TaAlOxahz/cS 7lT8QDcZHcA6BGbFsJzpdBZH2f1M3IwT/sYJ9YhQSy7e+A/SW4qLJMkUrnKGoaKj1mnkenS1RYeM WyWnjLeBVznC0KITx62SI8e3Si/ns5C1hCYZHdXU1zfweo1TH6RrdmS7mPNes68v2VA69kTKHfBK qSsTp9SBfWbYT74UpUN7xZWOpLcQ2cK96F/3q5tID6Cs6IXGTKtimQwq+NJ2s3bWtiJX3/sSRo+B mvB91i1ExXi3WYFLhMnw/9ljbwp3E9KvnfU3239WY/S75+ay7wgj82oldjfo29rZW0tQdzfitNts iXNzTRp3I1BkU99lb35QOxvYW4SpMucqijFHzwkc2B+g2xuUbT5q5OF8kS4rg7YRtOzOJoNegMbc g74g7K6djg1gpnfrDiGi3i3DVD6JYRxHDvs7Az7PPNh+nvljiNrpsOqxDt1BYMtpI0h+iY4TB1Y7 J0iWQsn8q9rF2gEfdx6UHXe+UjJEfQK/9p9g25y777jhKOkcQG6SfCzg3xJzQ2ofcZ9vDbNu9WTa 4jXIJ2qwpUX+Mphp9Q5vwayeAsANGRqnjZ4Ps+Bs/x/+Hvv3viKOV7+L18Q3L3Q3VuqyrnbQEF9M KG/cWADAIT2msf6kAi8sjvkJDWX2U837Ffl53vwNjXQmcVzxukX0mABvlJVhfYhBYE9zgWtM4Gsf 1dg8wyBk/gRIZI66JY2cllWv+KSGP6HnHbxopujpjGffedAvdSCMov1RgU+AoU3PZZrkTyzw+nFJ DWLFdIkoK9qwyqt9ephii0DbWqCr1OkVPYFhLhSCTGhhRh0IXndjmoBqmMjibgiSAWAkzjHumeF9 YXx/EKhPMm8mJBKp/FgLEL7O36DApR74W6UePq2RRPRCRbreO+1RER6deQyXgl9ZozkvlMcqoCN7 VKWxk9+O5rdwfvAZhnHQqE+jZvoCGnbJ13WIZzHzQeKxN4N0LsDHSMYwsDN/IQJ9T/5F4H8BeDHx Y+gwArGZEpjfSYEhHIGSZQIO5+VuDo40B/pAoUU9LgyLeRQr1A3IYUOFWp2AuKdxNBeP+hUxvOmM MLkRSb6bmtCdJMgvGqzYi1g9sHXgmy9BlKRCr+eC1oGxzw9qCAO8PIIIZoIXa0xqK2Nc/IA2oAVT P4ZfkB7WBETE69Z0ghExaDcHzBHIxuF+1Ddm5wqfnuQJOJ92lCY66Kq7hXashba6fJ6fV7XH39fz cpYHvvJCb+FgyEAVQBxagUZNz+8I7Kahq2nQN6JXKhXrCa0yb7mArRfsGGVoPNyElAZR6CWNkKxI j+CBqK1BI5h85hUjzcYnfgEXv/mw+cDQ5ygOJuIz+BVktCZWUeL23aDd7kGoo8eT3lTqtUqXZ/+t e/ofihk7BXySBwccNr2uMlbg442HRDNUKR8E8QuBh62aRxIRVo/miBcaSRy9PCi+jFN8MadQ6/jl gRGueRGnMJR5te7LBtGZFCg1BKHhsm/RjwlRaf70Dl9ZJnFR1lfXDwp5/GyGjjFk2kWlMT2fgpq4 XQKt7Zb4qZb4RZhH2QNNATjkGNpA3lEME+JRYqzUe9TBkl9dJgoRhwjTwbEBWTO5zhWynl1xm8Tq iP3Qqi/lk7dAiwnNMSvMx65k/CVbiEuzbP8CMuqXRf0eDurwVa7fO5vi+9GgrNyMlBVJ0bG9GLYP RGToKbDKqkD3KvVSAKgjM0m+ZoPNhIQI+Yn/UNSGggODhBITklgiGOUWegJGwOYBF3ZyWYwhmO0D v9WJDIP9SCY7XiIGQIHHLfTCFK5JHFjDyWqr2T3qonNG7YURwEh6oO1Kd+OXreTp5VVIBjB7ijN+ USidZfMxN1+JAJ3iSnd4Dy+XM9rtIwYXkMtSzCT46iyE5AQmBmyZtKFCg7GqNpfQFsxxhhM1FKKA fmGgYFj4COUM1wVoVMHZccbGL4brEX2GcxjdG9TDRz+B5GmdhRxFr9D44YYJ4PoTiaZXSHJxtEP1 SFURQddGSvVCjzYU7Qt223FvZcc4GTEuMWfQUsEDXqDWfQLZusc0WrFEdJrkNeHsI8+AV5qAtdaU zvjPUhWRkwcJ83OdDiIR6L80fRE9o3KAycYjTKTgJ+PAl7tl0GpqIRT2g1f80VNzxtNqUiguT/1w 3cG22g59tQqhCvvLX1krTCRe9Bd4VNF/gtCDopaQIa/RQ2njGklQQHNL0l+c3JB0UFfWmIJS0HQY aTYHk2hNlYxRqvSCG41N4YaJbsyUOnBoJhafZ36gzKt/eMKEfbcOyOS98gkaSrRwspKVyeg9eDx0 prgsg3My1tKEdC1DTdFPeaxp/gF2zGZG2BHktoSgJ06TSOAJ7ineuw8h6Q9wTqOnjbmf9PgNWV/x dO8apLnGykTh6cgF9J/nMWtEbCgKjZrRlSaauI9+hWjbaIguibMHcISYhYI/WnJo0YkHMbh2XHc1 XZxJzH5UuEoszOwli5kKblB04GRMiIbrVqvclhW1tBuysKQ812i1HBTFzMhMcJ8vgmjJTi5/Z2uu MNP3kzkykKQ4uSlSzRNPnTWZ5yr5UUn9WKVhBTh5BywqXpk7YPcvKVVDLlKJp0gBjKbSWGIaHuS1 Cv3m9K37Zk2BEXFOBLZv5B691dFKscYrhq7cj5Odq4Jw1qzdQbZmrvjOB+HNeE2OabFdWZ6HYpaG xuHj1EuG2l2YOQdfHiDHUOIT8wS3hYkwLwtsC/WFBl3OnLH7xGy6mFKEaZ3oyfE+fP65AveNK3Dm QcTCCtxz7yFuW4trF9bi2H+lz63ImcUvtXbPobgwpzNDmguyQ5PZPcKAGby9fsf2gH7cp6wkDwj5 ep4JbNoXgXV76Mrz5Qz5jH9qQ8wBytZnts3uaZ75v1+iTQLl+FB4mOCjuPmktV7PGdAzVWjJM1Ut E17Nwsi9yQ6b/FgmMGv7f/b+fbmN5MoXRve/7YjvHWpj4kyTNgjeSVHdLTebpLpp67ZFytreDp+J IlAkywJQnKqCKHY4vmfxo551zVyZVQCKFNu29mnFjBsEqvK6cuW6/taN10JR4jVXY3hXbA22fonB 9sXgwH2nNzfjO94fu50iUC3mOFvGnIjXxQcQqm8LhDDuvXx3dt7r83+TV6/p89uT//Xu9O3JMX4+ ++nwxQv3gZ/AZuDv1+9e4CP8wb979Prly5NXx/Q6tHv45x5zj97rN+enr18dgvZmpCQ/kTIT6Ye4 0g1chrDQMX3A+iRbm5sH0WLDN26x/+gmp5A4/B4R9ylIJyg1WFNP8gLFhEpWH5oyRo1fGdrDGZqi shqGFoCyLuJi24aLvXt7uo7wlBip9G6akxfApeaeIqYm+rFYE2z8/qKA7S7KvshmNxmnzNwNxMYD SzWpkhXFMBiRZMnH+iKrbzPWQSerqhMatSIkwe2DPUeCC0YJfcF8Vp8yACEwGXZqCvFBIx0satvm OBv8F1wfB/pMQjQ6SNJ8alg99I2SKUwa5sAmcVniqi9m4pzHeic/G1MaAVNnmVicS2tbDBniroMA v4dYtG18AC+5a0wTpF2H/8rgcC4yMJHdzMx0wplaRlJjF1ze+47TtSXcIxqG+ZOWFwaTT8jnUaPB jPwdGPbN2hGODR+VYZo8oxWiNBd6gE+0tsMc8go+Tu3duDvYWuKM2DZ2dQdahjPAR9cJGje5SfMy ohKXBfAxEOK9A8kL3cv7V5v6C2wtGISTzW+vC7Kygu5U50Omr4p9/GxEgiEM3V56k3+sKpAEj930 GvG7vrNrMTkAsdICyGscwCt7JHYq1sNYa02TH0/O1WBIXCSd1QUuzBBU0ztQQcfD0PYrY1y6QGoT P87S0cMWCBRktum4dQoX6dw7SYopEdaQ7kV8iImAsEpGMABjWr/7humVXK9I46JPkpWVtFAgFiQY NREN8ceqxsRNUs7kWMo4cchuAq4/19nydVJLdgCGGTI75g08zhG7p6CfnY2dZAVEaCCW2XS0KscS /ZTOrIEGdqfVo/U7u+HCOW/enfcZyK2fsNxyxlghr4/+SLaGw+TVO5CH3BBUfkI5DY01aciokOxu UtJ+Y470q4jxcBFDcduNiNEFth0lD1j0rTmNGtB2K7sswmyHtubKMjtBfIRFy4EzfJNnQ7aYEmI7 275UjVLbnBxUz3yb7dDbzKXx4+JjtTMnwIBaUjvmyHiefIRFNv2Yl8XUWStNgAMud+ZMhD6ofn49 iyrm5OQ//bqaXfwNRvq1sTJR5I+3m+LCUGSRBDOhldDLKe6+gBtO2mIVJJ0mX4uHenHbbvDC0Mjq IlES7LVAjziwPGE9LhChy7pvG00MuY8fCVGtsFOiiei+VnMfJc3gtC3bVsEtD81Wd19XrbyYV0RD YpgzouEZY7rwJuGJkVVSKs4gD2trqcucd/ycgcRI17stjP0WZ3NjAl16lGHHeiPeF70Bslz8Mpgy GlLnDWvuvfgibAV7B5F/PBsBZ00rdlDhIFfji9KvNF6K6WiNbZHju767E+PeeJUvoqYCCypLec0G +ALuJxezINxB4qDcnIfXmTizWQSfXUyQMkdSAYEr42DcBOYayA3MIiWJTG4YdIGRGfFOPQ9JJKcC xy6GeeqCljXCiRvAraddiuWJ++0ST/sbNa/KrCewI/MkmGA14eELEM4m5m6dy+Z9GQ3D5hdW0VjM 5rfa2Tzxi3GByMLj9C4jNgSHDA8r6BhlMc7YIJIxEWRTygopLskfmpZXmTeSlBmMJK/pyPSVsd45 w/qNjlRlevJdYDsgKoqm4cmYvKxSh4ri6SY6Y4pRuiKE/DGqyqwrs8WYD8qb06OzyC+PXzkNmH5/ kV4APwtKQ/FXZ54Qjrg+lhip1SoGk5NolETsYtKBGMbw49qrH8nXScEHNmqsLxT2EYevhMjLgpa8 7AZYHC4+bAirWvDOdX5TeT/vyxcDqulIUdjcFTPIUdyXd+XAwatmE0/HTlQ49rnVZPBHRy1VjVx5 e/x81S86gXmg+iEkHYbcUGR/AQQ1m9D1D+8GNwVQJBejXLtI8QKXfcQLRW4+9DO6yTvFjjqDY0yP LuPk1o54hl4xS3DwJzmSMZ7uKq+BtMf5RYk1sTDITQwvbbSEkz2eXYAoCJMEwgvtKjub246q7FPu eAZS3rFPLvyLvE0k45cZzQVq7Xmflrf58EO4Lb77989dz+f+af/o04QSLohtl8khRhrWGcVtSOgO ljHPkjOJVtQRw9DePxdCTp3JAlSGuIFRfnnJUao6euKIWAgjVVFgnCPqIL0i61kxT8i0LA5Ht9Lr fb/sxOEO3x6Z6b47wy+8EYv+RPkMtF0azw+gAubFVZnegGxAgjZMhR9z07kInpmYTYJWRAoj6Swb Xk8pMBN5WllHL/Lz4nL0h+oY7oaqlohMbCaglc0nG/tu+IfzR/6WbxEmEXxJfAOHEmCBTK+v18ow y3CxJEoCv+RoSaoU8tLsC2ykZKgYxzhxZy0B6OPBLDUulZ+2jMz4JgUWMMxv0mldKaPYPDjY88fh 9JRYV3Vd3FD0BxNtP3n3x38qZculg45tZC89jHQIZg3cFgQT8dBLKLLysEyiTC7L1IVCwVpSRJQK he5s6PJSaBG2yUwp60uIAmisIoVlDVOGb4VK+dmzMuh5TlVcoBgikYLDFE3D0G1ZFhdYTZvJE29Y MoggMw233UaDuNhlz/fHKEvecVRDX3kTnmeQmGDwZD5ln7VElmk4AItntICqWeEys3gYdFG5+AS7 WsAJoGvM0hljkNWHTHQmfudjmo/J3EC6IHN0bLqvEXQ5R47Gh5wiXCq8mLihcaGubKycCN+MCwwa 7iKg+ZJkRkBbWJFssYC2PUcPD3eAgr+lYiVs1xSDwzT8a4KYaVeZie0CPvxTcZuRrN9Na06dhZdF bZbxpjO1Fd2E+vgUGBDHh8yxC9iwE5V9aiTGdTZkip1uQlqyppPaYDZRQeCsq/ZOl8uMTVga3wHk KENh1VBSNLiqOrKksVjYnAPBeR0CTUs1S2Kv+mZesdsvq2jhOMwMI0qwgdLF9Sd/m1WoDaFZ1Dfa hZR8IbomKfk6dIvJZydIc2lXDSlsJfuEYlblAyBJubrIOPYNjwlWJ13M9XeMrIVNOEFziLNHFjRM yblZs1Pkcgzke4FGlCobX64JrcDe9znaRdioSIZ6VJFbScAH6LS4LyxeGLWvcmHT2qXYMzVQJIhM CkNLBxqcSmMyMWNIk1MWW5SOgGUakwWvLTuEKT5h5J06ZN4kVqfhBRjJOcboOk0YoosAA8gu4Gh/ 8LGkGgNJcWk28EHnRgGn9DZogfC/pLwRo6WLSyrEyv3EiQ8lMEf0FsnK4QGkBoB3o6DqY/uwaY5r w9cx5rWkert+lZavqFkuYkIYCLuG7ItYtSNDWTgJYOVcpZRTFMIGyXCXTvJxnrqywhhXu3hMHH+r 6CocQTyr1CHQ+zQZP8Uf4a6uhRv2YSWnI5RHrY1F40DoZrLDomARI/zN61mP/uJzRNLTV3PPLAXJ Obcue4RVCds+IqPDBLZwxAIANNTDA3lqws1AELJpGPDz2umr56/PTs6dnNX2yrO/mCdZTyHh5iid FiwcY7A7dBiIudsb+97VHDxqlOYNlm7xWfEof5Wc1pHKiDorc+jAhiIUC5vv+r2u65un6+u3t7eD 2+1BUV6tn79dh21eQz8htLH+H/gBbszJQN7uPQvCz+GXigXDr9igSrwGlUa844obCXNaEcdqny4P Mv28PPwz8jxk+XigORUQJwEtkWteaGAxCewwCXx7gaF+/z0DyfTZt6MxfvXVV/D1qH72F+DZl/kn WC3449vR6NmKjmrVGV05EJgfRH+OWzuZNFWEptLYiECMBjFobRT0AqL0eAQip+lHPOmj1eRQooSB EgltGUN+8fmksZZ97SX3aUb87gDDxiQAgNQV9JtFlEdRXynsgLROzikuWP7VVzIlOinN8bsTXc2b wWyqcxDicq80p9Fs3y9za09+T1p60jVZ0GGf0tzIVYHzl7n6TkfZEOQxySFtDC6frjEspHuh89hM uW63c/cbGwlPGddfYPEfmSQTXnOoaAbC+IO59KwPRCRMMfpoB54Zn7ZG8XNc/w/wpusQ/jvG8tn+ XHUQbHb5NJqkhr7Zbq9qhwH4KwvYETy5Dorwk3X3eO9Zl6eQJ63CUFIyoMCllMu0OcAWZuyj/HYa UX4PYsVPk8WMSG/PluMV77IkXS5buRYSWLJ9IEpvz99AW4o5MJ0vqsQMDSKPJtthVmtIxVPh3WWG v/znuP4mxCaEISawINPqu97x4Z+e9viPp5dF4agAPg8u0nIARKs/f+pIInAUdbW/62VTeP0p/fBd j+ykcP/0/vOq/gYHgUODk6x/8hfQ9dOLlHfgux5sQE3Pf7r7GX9dl59tE+vahvwZzpZ+gRXB1ZC1 OmWiFJ9AY6+Dfa44XrKR+PJ4pPuL7Na/brOSLg0+1m7OP04qogYCaiCSTanC5krbIvaTHnzsoYsR U0aqp/cUc3rQWK+DmLJtJPQW0a6DmLDwWvaKod6PPXwep2fUCZSOZZeaY14iOmSIetNgoYvv9FA4 sEFxeonj6JOVaaFRZUz4q33YLFxY+KJlz1b7Imut9D6ZRxbTP7Tp35qMu7/XQTbQ8S+9Fm4kUX5S SA12J7qbxfm/jqmHfOKfxhR2H4MpsK0INK2lnOGfe+bnH3k55nrql9Gk/Ftg/NtFeWV3nvFP8I8W 2/52je3vMNwCtr/NpuQUoaBQ+AzCjQ/IKV28sA+hcEEWqRqOLGBMmPvnsuhMCAUHR5jASksay4yL u8a4+INYvlJrftN5NWfVdzY2dISMqGYHmX9uYKAuFLROHLI2w07ckONqBrqVX7x0WBZV5Ww71o5N upBJE0K3IT/tXTZsH0Awm4LDK1LOHQ2DoiqNJZL2fJgYCEgkgrL2wW4XsuuhEDtRJ7lLEQyiZaDZ yxR2D5RrDY3yFtMuq2+DwEItx1nc+z7mnX36MBiKcv8FEw/64gugIECYGNGBMd8bq7ODn/FDp/Rk tqcKhTpyRir4mJZ3aCMcZVdlJrFIowkmQNYlR7yjM7wslsYh7IYRZeFxlKsauhynFEckBiW44hQQ 6C50SrjkNER+zGuJM7qa5j9nI/GEwLoEJsNDJknzxfoPZFv+RGabMD/VufOmhbbsonGmd0EQCpvZ Xd4JRckZR0eCNjweqkBrUmAiHAUEAKgz62kUVA+0RNNGzegQc3IepxwzedETGviXE3Ynn0QcFVp0 ixBIKfa7LN4mTUN4notbnf0VaMm7geNMnlhybaHS4g+8N2Tf5qj4CLQO+Soz6+2q2AxyW8zG6F1k RuboUG30+sLXVcAcHLl08SDt4SWyF10iLwnxCnHtuHZRTfijS2+TPXubjDHHn1xyL18Y9qSGdwyR plBbVvajBPP32QW52rMMs9JN3FZguOc2lLB8Hxa3izxuCN214mG82ANJ8AYMkwjr/fL05Qn/SAFk CsJG36xSbJKkRLuzT2BjNIQBHBz5ldDD6OYkgkXvIXbOYW+h8aDP7iok33ZUh52+HAT2jWBDIwnJ mGqglnhEKowoz6trNPIsXA5qZdDgMCyJWTO6cFrkByNTalBYMUvLc7hxtfpNU6KL43hxoXRvfJr1 rzkDD80ZgM5iUfAoBI/CcDtTZ3ZRnuLuIEI+VKo0WIO2uIpE6t0qsQdIZQ5kz6eIsGAiQZoZh9Hm vtBs5eN0yaH/7i2BCnm+xsQ7KzEghjs3eWgueSWn40EhgHxs9JE1gnkqKIQeSDYbXA36hIsnIVgO Og+IdVXjJ1Mft/t1FfPYRQu55TjimALjPaiBP6LkSVfWZudtJSidiHPXSo668xbO4/IEsL7bMGy6 PjxIXYe8j90IF7N1rMQBg/vV/+Z8pOTpdbILuSs1PsXtf2+955W1ZWtt0z8Op3PGVaX5SNimkevz S4afkDRQTvxAvkuALA795Sn7MSgBBFuWi5jDTtxUasWAIbmpCskzTE6kv7CllLBEc83R5Bwrx6jL oqjpXqqLm7UxBkfZJhvuHnLCy1XhgbNZxEJ7kTeoo7ibFwivMhsvpWWb5vFKwM5c0tnUwQJrDq13 1iHnL+cc5nAjbNzREC6P1EM9GXQbuUyvQctGaqHZsPzH4c8V6F6ytiw8eS8VRTj43L6l8t5ukOjh pJp8wlJ1M2P68xESiDn+otoQy+cqbbrQ2ZBLWpkMvdUX5g5nX1KA+QkdDzA4leleM588Nx6SLNts REMglDh83NMihraFDC1OcjBZ4/aiW8jMtgILiJl9XtnRS84qRacF0QYgyWYp4o2qa5spLDjGrN+y atWIHeNUGMEyTRk9TuOBxAbJ3Sq4bQg7Z7N6fzw5HxDn0/4putKnd2u81pz0boxzDr2nIUGQ0ihq J6eqNWZJLOa/ZxQ0p7ChLqvWtwQXKD58M55Vkp/lppoRcgnDiMFNPZ8k0f7SfI+aBL07HxPiIIhW 13iHMD8v5zTFN5I2kbc6m7YH27K5/zKAhN0gU+EQzrAm0Tf3gbaa0qMRj5T13VAGowjgKZ3/QTZQ DTYXuHtUjzFGzB3PINfKKbTQlcSMpSGhmDhUXUwypHmJlCxpmcPOSQU3xZpl4A2kgbZN67JSelVh LiYGico90iZ/seHjh37EnOjcvnPgtaSxyVF9twAnAZ/8wZ22NFp0upYw7vFd+6XPnPSsIOOMVfNZ KpL701jHYULrF2m5fjFOyazWmCfOra0tbAdlj5a2WtupJd6weysTDGyN1oATvPAHTedaMqU5otFy AtBb+6iFgOhKI5bNiBYvODMVyC2eNkfxsQ8hEPhC0dKLf2kVD7ZCHk9MnfENVELi+OcClO1BmDH8 wJ3Hplt3X+Y453Wrm0eyarZ0dwgzsKT/UGRq1kbSbdeJm1Rb0122V41wp6gAzj3cdNSmRfMBs6eq oS7cVkf9c7sSi2u8wRH9d5naXpBYzPYkjKkVbUQw05iVCKRgKLpQejP3T8bXO9KxyRCj6JtpdE/y pR7dnWw3D8FBUoIJJSPyMUczo7EyEPaQGtIh4U6kekm09IvaHUY+FvmUEyyCS+RUUFAxtBaGTyE2 jMrFQo+kmWGAosvG4Nh/YyBlaErqgc2+utd4S2ZTjzoq2macu08GckUNmX4sPuAZYbmKg8emSeio 5FOBrvNwKVf7wZGOjpS+uJ6sRK/RWgoICLEWZg0O5JuWlqiERkcjyiXjpromoXvpcikbbx1Qju0N CKtXjbDqK5PtkAhzI2hNFNZVKLIDiCsT/r4TxT0GCeseAYWjyCzcJj6NRkrVrQ7IkpPBxUlJqSOK RUei+ayej3ZbgmhUEsVcF7eNI0cnnVEUmNLZgo0Vg9Iyhy7FvkPpReOx02fF2bGMq1iO4nCrcVNY L+BT0pitbL0wXwxLCGo4+gQPPQJsCcYHo+VWKBj2oghB4YiFhoyg79tBqy3d+A5uRo/kct/ELiZK 7TYSpY60mAcSuJRL5JiNh6h/27Gl00Udq5WNzdUEmqNn3pfsQJtnKN0ZtQLO5zU7yacmjcDB/DrL yZt353iDvnl9du4ZS9/lwnk7FKa1oRFqyTmyQGoBUD62hp3JNIyi41Bua4FAQxx5qvvCjmey2CvT 8PZHlxROL6yR4CoAzIGBWLmC5K0GJwf97ZjFkbMbD5VryuoReGPkLUSciF2kQ8mjanaVMHI5CtY0 LXqPRN2L7QjtY1VeokW9ld83bNuR/Y50JwGkYIxn3VQvXxJPxtWme01xM+hCY2yWi8yZCjwsZEqp jK7uC5X94MQwkSQHQqfsGuQcImxHetJ6QscnL07OT5LLGaP+pYhzbjzvZgHQ+zjU+1VLofCSmTAM Qo5iZIYPZLCniAUMfai5VAl5uInHtPQs3HZKMkFV6eMcIpL5OIBO+PG7Aaaeh/vG82NI2+N6jwnU errG2VbCbntygtNQKO1xM7oJzmhlyFI2MVxF9nC7KIJbfS9YJfVnx8twWZSRaOwqFpFpk12kBOOK WwED7LJCNpSAtOwInA/XzIWzwN+ICIdzJnYU6uoCairMAnHhSodRrwyzC0PfQYYepytKhUvHsmkQ rwlZvzsft0mMzwsGLo+dynNx8BxQGpkiiAenNZCmIA5xXs5ciG/m1Mbk+ePpc19lCbnqiEMnRnn1 QdgNo0hSSA5d3H0nkqZqC0xjAYCJJiPiZoVtyIaaxqt0enlVV+TmjyexGs/C9qA8RmsAkOEorRwc Frn05TWcqMowotzecJnEGDQI82LJg0FcHO3hk7yqOihENmfUOQdMu3iDIBfGIlKV9h7HHVxkl3K/ 3akiLmOoHesVscbUT2kgeUmfnPwOu7CmcB/sMsxF+tOSK1guAvkTc3xX58llgfFilNnNOB1KQmbQ jlar0ogBU+DMweNg+OVA7nqnL/UFUr1hIE5WaFRkJx0RIXDoGQfe6wW7jOaDVnTEHCZxfncjeqIN ELpNuVAMMz7Wtc3+RNIj39GejlwXXUhFb4YzRxJzDj+uRs6/ciEPAXJM63RNPEziUVKa0nhHD94M zaDzAzlOUbpT58gOm1kR8AS2j2DQEptWDYaAqKt4iJ3lYZVQpzg0iLgvDqs5JGx3dAdvyaKzila3 ZdPfFDWjM8FjcXa+LICFsDucKt073FuxBiRHP54mLCElAbQfHqIeXBJXGBJxBX3jtgeLN0lvJCsv SZp+S07f5KNBdTG4LZVIfYU/o6xi1LTGCGPoNL/yX9L7Omb9fg8C1JKCLLs+nVJPElY4qjJJUGkH QBimN1yfiPw4ZEGnBSLLRypBYLTZcARg6jcC7BeRyUq1avh4FOoAY7lMEepPIhNJfZRjVFhWb1sT WFgj5GmFgwugj8u8DgEeLhOpP5mhQ4XHKMewpXE+AKiL9uf1L4YHEIDIRcFUs5Dc9c6RxryywS2x ss8+C1vfQkvW2atPj4DW5xEuSIoiQgkw7yah15s0xP0xceF7qn75enwuRjeXmEQlS3o2PvosugWP 6EngYQXa4sDY+orLmix6KMOs1cXaJA6ndDFeXj4I4awbp7kD7as19fW0aYqQmGS3a+oCam48F7Uy ko/Ajkw/aKRyNDaxPFDZ6sM/PdXrpcoEJ0+i4bYHmxuiO0bKmRkIl+4UkwbfRmc1n1TzFDl18qlE D7aPqkroRnaxIBezcpRNhREQFFfUqDRjWMNYEEdc2rLerSZX345bDMdXM1ARQCdkpdxZRtl3V+I1 6E/lwAnPPBdafEKGoKpv8rykKmq9sYxrFzHcL0p3U5dXjf2jZUq3m2NoCUKU+h9LlSSylIX8gabA udWByOT5OZ9PPZuVfbHic83WjjHVmiVzNV4zLF/SSKgeE4Zuje90qGyGG5vqTTK0lnH9GmT42UGG e71ncaiwVIVdHE+4F0WM2XK7WOPIeA5MhKEH6SH+CmcOy/lInIq9AlN/cIH63lUM4IQt98noEB1K VBhEvpManWxYo8125090GpG/PaaPw2ChwrOCx28xu8eKXnOREUjSCGOUBl48B6mk76nWjYUudzaj m6K3Pa16u5iF7wWlUJqV4ziCGFeElgxTFrjAF+HV0kjWAhQYW3mPZDSD4yQrUZHHYfwRk7Vchc3k I1xlcIQwrZuWRpyPGhjqtw1lA1rp0aBRXZurVEk9U9U6KZqBqvlKG9Bkn2v4DiK9kNOJfJVsvfUJ GxiLdUixB80giJYLxqm1VKljogDulZg4xoQvDbrcw7iuvZZscl2pP8FKndFK0SFaYuLYa4RdEjvk kj7qcdGyYlSVXPvhKmBeo6cvyGvkwGpkRUvRUl0CEUkjuOyyU2LLdDqJowVFcM5cUTrsqbzI61Jd JxyTp1iaJD8qdv3HIh+hmCx5GVh/OdM3ltH95hzjgOIxkwKoQEnJVcGuAl+BTcBXaLmkojm+LSPN PmXlMGeGMg2XCX0iauEvPC9hC75lXObAUK1nKdWjwZFUATBjg690J4WcqIa56ZLKczLB8EkmpHUt 3uSWHdV/VN/oNvSPKxNwET3huEBSyHLVSpFefiLVRwCZLPtDq8QNSlllbm2ZKcrStcrlH7rsm7Ph YpuVnVkdAGrXJUaLVJnGdKaMFhJBxyMBMoilex43mO28bO3joRIHIMtTRZFKbhlurwtvG5pVZOsN bHsan2eawLUjHiRSmhXGcRcmFHxFFnxoXjT/eByLGlFTVx0xX9eaqyGIRzPY74qmQ6E2vCQMwIKL 2xcTM92UK7XabEBzw4wUpGldQ3Xdi9LWHDsPHAvPdthy1bDP6pQ9oURPHFDtVC9PbSIUcumajFEM ke+xCgesW7JgSKyu0Lzwt6L0aMNVQOXu5nZQ91koSSiEuNm/16JgTKhiJ1+CuPKjorWVPruDTKdk n4HLZUR7a6ULPN4oHPA5vixZ42GDP6wHLyvCr45zTFMA+mUnoufs/AidGC36Sx2y6s99IoPhveQe 0ayfEsBnUZol8T3yY4hXKsarzBuOlAzDRljOmUulZKtxa2UoZ5XuY85tM4Tr3FRThvykAal/xPcq fhxPK6Lf4MgZOD6wWHYhzl1zu2p10KCIIMUHSQ3XqapoyvnH4yDMyQCAo8Wrvq5cMMBdy70wLAoM LUh1B5imCDubUyTf4x3GFGBZZT8mNlrP6R0xBA5YvWBPlkUkx/tpmo3bOk4YxVuSYkAJRhMEUSZj Rbgsnb6rFoEaJA4EDuZaXvOfLtEZ+Ew2Zc9tNs5urlGCoxCmskq5mZNJmo/7SVYPB6u8+Dkn37GO bFgam9dQa8jqiBwwkY9OZjaushZa6FrkiSlB468a162Y+0fO2Yc5q2VOdyUdXUScN8ZC2kanf3B6 EcOrqyAgHslQXuPO2BBUF+wkyK/ykZpl7bOuKjYV0KayA2Fmuhj1ROVBEnxKlwbfGXFzfcZUDD1c 4lbGJohl9RPHLMxTZYax8JmXAUTqVKui9M4MwZXzQO2G18DPnNV70JQqsedwgC22zncyjURMDBIA Bw+CmDqBiy2triVC3JbbLW4R9Rna+JhVNkRnNlVhP7Wcnx3LFwVap0CIhIclhD/M7U5d5IcgKOtW iPMesyNAXOH4BF7fqaTOeDHRW808PjENnaFpOZ1SRqG0TVHdYqM0Y+KlsdGY2uJyB+0eplXsNdIq 3mrk0RmHHS1TVMKUijnGxLZASZcbLPtBXrQ7DR4ZUKSnMcmOCptPrO/wAgm0om+U1T8K/7rQZFYq Equ0z/Fy5riTtXF6Z9XNpdpIXJKUDQteNmc4WzZ+5JWnejodBVz0d4hpm2OIhZcESTi6zgwuownx cgWIcPwfGeLKshqFG6WLABN9S0r3QutsSlqWL72hVQyCL10ylwnxKNiehyC7BQ9K50DyBCHEjyzl RV5ULd8R9EN6pu6mbIQRcMSyIsoZPmxNODYrvFU+ktfvUEDhJigtjDirO/5kUkQWW7GkLNmgcTCJ gVcnZZVDZ6RbJitNXXNmhIxh3iV2JDQ3MEsKRiIROFhEJf2Uc2h6dlWg50Ejp11iXJdzvY3nOo6k Q6tDcl6A9rDU9rAdHGlipzW+yAYFNe6wu5F+6PuiHOpdf/f2VEQ7CmiwIefmspJ7I+7E+m0zLWFV zehoIloJVrDzMbHqYcI2fMUuD3PiAiJdgDA6+/uC5T7lqIcL9AHNyH7F4OI0It+cojd0lStsWN4L PzlyR2iuiEDsCChMWP/rUtJY8B4YOEMfvzGVcCK8AtBjYAx+3I2a3HwhJe6j6Tvyxn8O177Eun8k 808vZ8vDNfaC6KwWW6Qx8I6DVdBoMFREmV8VNynMDZ/ih9iD7Eq1mqnbqq3esxlNTrQsvpw5gHV6 Z3s2iDtxMvC8vjqshaq8P7GBK5i2W4xp4QAjIpPP4fSORGa2E1/m7N7DoePXKO1+bTcaD4hIaypx eJodKO15ivOFqigIj/COkLVnFC4JkisHGtHWOYFFIpJmjRifPksdGs/HP4AGMHT1f3iQUsWrA+fa Qc4Vh4zFhOE5GW3nGW3nMp4W497HjRrCEI/31dQldDQOakhrwVkN0iQsJWGiJMVlOm+AKO98Skl2 pEEFzJBCi0ASkrjrQLcRWzWGHKu7sZhm6iIRFpovtdTYiKvDgAkR2TgcIe4gWjdZM+AlfYkeRuF0 Mpv0gxdTbyuUmZE8xzKh1ObjWaDorckvLMnfT7W3QUGnAkUdGmPMnixlvW5do2kLWxDWVLkghXeK NYaf4A0ahYdQW3n37vR41cJjxcXhvXvv9Oz12ubm7r5PMIdv1k9PjhL69imWzBkEoNhUj4gKkydr yesbGOaZyIVkUvNIMvDzWw4BeYNK2ghLGBzhlFfevjla7T37i+u7Q6LqXhBM8zpaKHEBF+haulaL vUREgdiec8DNNTud78R+K6teCQMRWfWObmtRp1zkE0OR4LoatAZ1euhN4loWHYqb0qBghWSiRtSJ RYnKLOqJUchDU1RWO0G8CBuJnI0V1ipzkodqqzJqnx3g7E101CJ3ZH3tKwv4UbAVjzi2U0AJYMpl dZgahzilLtu3G2wfclhisBjkn3yX9CLyf9rjtfrLiY7qr0nyDfFV/F5mPJr5bBkKTys5Zt6Wb2Or D77UD3F/sY1/y7NgkOlvr8kWzrjeL96fraqaSwKZR2ei/dMKGhpd5xeoy/6oicotOOwKmhlx2em/ 8/LYt7BC9GXy9vlRgpAT4bI+DoKF843OQdveY7TtvRa07VcFqHPP82w84lR53rv3IoySMwBLlD3Z 2MLCZoju5jC453dlbnokrCqirH9Lsuq79Og06U1hVXog/OGyaCyRw5AxEXFubQT5Tu4uYzSZgGIL 0yYtF1vhamYWeGx/8MR6UKXipI8gLPPqQyvkZ/YJ1XkunsW9gGQaj2gwD1CKgwTHlDdcZ5EPNeKS wXo4fuGVSydJsPWDBKbGONQypQoP5hlyJqNEcY6xiG99zSNw7jKKhkAi5d7JTGeGR/TFtxPbvD+5 hEI3aVTopbwORjuRS3zqnFxrx2V6WaNc/SadkVz5gqwRlO+GjpGzdPxzn2zdYioVJCjxRrC11CPU OncCWsOXc5bNyIQFu4O7X4xnJtGxuBDK3NlPLkBSHZZ3N7WrRChybQIcY8Qx5ew56zuHDwq3ggMH 9zw34pAlaHWR/bvry7v8XOE46lZeYK9vAXdsHbXB4WBFsqmm6As21uROgxymVb1OPnH8hL+r/ym8 Vcmb7MmICMSdMV4ORSKScn8gUJSj6hvYmqmHy0Qhw7XpCiyih88FdRIFmSBWBMnh41RpTsDIaefS F9ufy2WpU3uDsFY3Zc4r5pmeGRHFbkrE4hJACydbBRuNTYR7LRvNQUNT9dY6Y6TnKrOKgTtT9izl ZUtMusEv5NZZQHcWcva30F4BCzQmeLd2g+RsRgV5vAVAZqs2CUbfIUcL0QW7dxZnWOoqooD77Wys sXV41HvP+CL7dpwTyDqcxaF4sibA+0uyPcEB+HYdHggfxQBEeg4Pln/44q7G7KfG4+kEq33hC2TT 6PiWdkJjS69ydiFUt+kN56nMeZW6oB/Ivdt8saWrusDSitohhuEnH/OSoq0UllXh5+cOl9vwO06t hG8vm+lFUdSUeZWMSiTmBb3RLOlRyUaYytvLXtRMHFQPF24VPiCh5xynRrSInWSjlhfRRQi340zW kRaf42HzqbfkNyAL20Yo+YR9OGRVTR4+SefEIEa173CwlOlEpbJ79QX3xDj/WdIX0yF5Z6HNqA2v XK9cZ+mNuH+j5nRhYQErWuYK/eboM4DG5zwLbDCrlz3kmUw5m06Nb5JN9Lg+8dS00BuMAPmzHCIQ XUABugF+DAzq1oU7pprChd+2rJGLAa/qdPiBw7wdTApbQMuW1zSBgLshPy3ccWicbXtDV1zeKqJa zK52q5gLqRaL1BCsdOdXNGeNVNLsEwiBFBY1hBsJ09p4xc5f/CCfZQe/XZ8hqP1yHqpa5orXoTh4 FlRCjITjNDKEiofl/ADLWc29GdhEIHmI6oWtMEpjkXSipOCtEmRymro7S29aNc+Cxj+6TUuXIEIx NX6RBqud7o49b4/ytaK46kaQ48cVqxRx1NEX/eGjTcTx4dx+fXF34XWOSjYhbMEEUvIu8cT7LOBc Z2OC5w6SW9S85kM2OYLNyTmY9kZGF1mlbmLHfi/OSPYythUyUie+OdiESkpV5pUpk20ucYnGYHf9 dRYX+9V106x0I8SKZWliIi7IYBQJCibEGG772cRVRTbGeaADjOgg/UWhRST5wgFuGknGI/Yz9t4M d8DFKUt8U0i714jJo5NwlPLyeJcccTpdlr7U473nb24cAD5MzWgKOHdrhG0rDNPZxG+v86vrpsyN La+SbKyeX/Se+ejQcaAE8KZ2o5Unan4iMgvm7dMAk7OfDtc2+4HPblZxRHnmnMTGYeOc7p7A2SuW Y+aD4wn/pQ5EqpOc2OwdThRygcw49RnD/pFn2GcJ5lN6LuUQ6wmwMnHytj7et3suxkdSrAiQQYdD bSq1XWQGML8QoNPrdHypWyQ5TaRa4QPUVAd0zT0Ek95rVBYhJ8uRZjzeJcfqVVrmaLFo0mck/Igt goz56rpHpViK7hiHSM21FVyiiHWzsOvDJIGLIRje8a4FXNZrrIOkdpCLrKrpkKEoIWgZFLSpQfTe w0sI/lg4FUH8bzVWI8j6VLKQUWjRYRNv7xDmw3fvWrxyrb8G+dnW/XypvZEzVwOrFFNCoOydsFm6 oLgIfIIB8U08FKWNEdyUc7hw7AsBpLqsldal4cbkVorWBC8NScN08aI6AXq5W5mXvRBUGxjcHNy3 sAo0dkdBAmKXt4jbbhMXDGfxgcHEqEYVhUMWAmlnOx8WmyqF6nkj/0iC5KJ5pkGIfkXYFRzMLnHJ LFUBi8BoCW8TJFeFLXVOFCKZy+psJuPRdWH4vi1xbiEtFJO9EXwhDgBXZkbTFvSguN/GjJiNwbSR 24/xvHyqOctenAVEJhE2LvhL0NkW+UnvaVxGYHu/FIG1x6N0IbB9JLD9iMDeVRjCdWQxvpdG8uy3 1ejQseFSO8NrFQHN+2Ar5JYoN4qGaBLTTeYa24DIrRbktfKyyTMkNpBsoDYxbGGQuEkxzTkErGoI 0hVoNcsMNPvWiOlS3BzOq4TyYiJsJeZvjVENwuu+ZpvQKPs0uK4n469xYMwADyXNiiLChSlavC+P 50a/OamuKryhjUKWyc/pcZtkF5ZR6L4x4rkRYcPTr5UToxAsGXVs5KJ+Uwfzc5FdgW5Hjiieepc+ d8I+f+BGkexdjHCzj/t0sBt3gIhFxM6kkaAfQqViz+w0efcKx9Glk7145eImNRuC874wILRS1D64 dn8AbUyAsrr0ZrSeyKUieG7AuVhg8RVm2MEGgls2vpQTZE6aeBM0/wUZMHJlYvJy3CQMfOyxGoHI ZpxZpifd4FUpTi9yOWiT4o9RHzDkLYIzZz+wnDCB8Vxn05GjWqyBizeKHYnGjzoMgSAkNx6Lq9IN YgKn8bgg0buohJkm23CSA9uBy4xyRBOuiKjgEOSNL69Y9/VntJj645aYWk6cz0LBjGO9O2UyPr6+ QmAHAQdxcYccxInFRegmWKeDsE6IWuv3oE/VfSIHlb1v3MIxfB5WvmIujunx+XVRGD+hbB9n8w+H FHlJxnef9OMTwzxts7yGm6elATwlEYtpgCtxRrRwUYzXZuu7BhQikAfxG0rfA9FofOcomghtc7BB myV/bLoeSfR1rVsdoNMJPAjX01b6Q28BLtYQDvvPGCbp0qwkTm9dZdYsWSc6o/Va56SBOVSQrLiy ABdU3CkFPXOVXIUallhr4ieGj2jFxGC/I/HiHhfD5oZGHMbr2DbjPuffkkXfsD0iBrPrXytZ9E0m GmMq1ekVWaRPL9deIm6aRKY5b5VTwgkIheMkCNSFd/R+e7nphGPjg+cweE5+Q88n1TghbyhTlyN0 3F+605WTeFSANZQ32FaKrvnK075hUkjm+L6ndFfyJJjDrygTn4EyAbJuLOm+p1OHmtRioIn9wZzC VYHaYKAtnRFcMFZ8ykBYKc1876u74XtaF8FklXuVRNHFxBDlfg0D/JopAUvBBfYxfGa/ETzzUiCF 32Zs9WVLrV+8JdrBfhApc2gnTdqMHqdQ2fSROfSkwsj54Hxg8+w4YLZKEhaCWML/vn395s3h+dFP fZEh+Y7sJy9f/+mEZGZGE6VcLobgLXxkfzYKMq1ROKPL3XmNeDWoHcJ6m5pEg743o+a+zuHYxSkv z2HfD0Il0H9h4hlZKa8oEtEULnLZ6Lm3mLqsULoXJA4c2KKLgIyvCb8tyzXHfUzp2m+kdBmSIELt nAqyH2V3mRQMhQ3mvCmThoOO4jifhwhKLnI0woqB88qHfNF5kjBrEyRsIhnVYm2uF/bkWVCKGSGm X3KZW5coKzEOdljugNoKvUbXR+Fdt+zS5V5yNGqfvACaloiylB9Ehy3axi2Ks3PiLfIVVZbtkE3W UXjcorLA/2YfNFOQIq9s6dc4vUUsSLDGsAYNlDRxc2AqmKkonDszFAsPfYY/ZOcUH+F+MtLg+CxI rZCDmJdSSLoiXvx6SuUy05HtglS0qFuDbI3WTMSLcOml2JDB2RIIEDG18+D8CiFU1vIt3MEtjNMU 4i18BbywK6TtfpCfwPVxbWlZOAcw03AvyR4+nZnQdTxXGu/ubyBxIC5jb0EWQLAiYSf9xFSb4Fwv fGwtfAhbkewBrmUg3GxnY4e8v8lzTLZaRW6xs7GbrPBdhnwVWTsGz66qSXN658HT4XFbHA64Dhad QLKke4Yujb6iz/ON8/z01TENh+8a3BnRzTTvLBw6DxurXqQlT89VNSFZsiZESzKL2xJIh6461dj7 I9pa1opfplBSzkBsiEGdkuordgFfMfllUakvrtKAcldRTN1j6oS8yurfBg+w61eAKTkYIZW6Fi2j dBYrW6HSAycP2HuxhuQd6GZ+em5u6g4tysgYqrXf20zwS4v07Qc5Hu9AtBvTLhEF6WIIzD6LEZTT 2RBQXNbSnIUIjINs4K1TzSc0L5DtgPiVcxoXhKbTfRDmDAVcOBjCEBPiNbVv3iiWL9yO9zcEzVO2 krJpTYdmo1Xf3Cb2oPEVWOWTHJM5ZQcE2umCICtbJ0xpZ7mvMBVMWbgGF7LgiyKe32LmvIvMOXZn xszZVMtdxpl350nJRViIhyrLsUhqQIiS3jGwqOunCShYvFz6RT4lfPa7ntpXSKZxyK+sTGi4CJIR YQwQohUppabYoEYSmRoed1TdykMhVJzpTFVh1I7RZ1Oa4Cl4Hw+WT/fUSxD5Ku75YhiUdxPsHNUh 5dRfMdBxRW9xM7XWiUpDcQzDd0zxhYIiHSn4mKwbHjvY1/S8I3VBB+21CIvKECD2oclCU5R9jQSS YbmsA7sBmlX2/HCbY5VUb10mlXcvU+BNUsPHr3AcfBvSVLiTy060dY9aiN+gVR0W+ahhoUZx+SWD yB3TlqRu34X1Llzolahf4ztdEy2ePEHMGQUC9cBGLvDED6/vpEFdOlo3Ik6RGra2k5UX1P4qMYIZ erRHS9ndbhz9bKBByAIdgNxaLyuT7Ggk6ezThTTRQrkKQYcaYcDaJJYjqrFFHQm3s1gqxqRgciTI 1rt85sroJT18zvSIEoySyWpUBIWWX6pT00xyPV2/oNKBwZnQ4CvX2foQn8GDqPXJ6MUhL5J/jL90 kUV2Se6nA+/hBRC75+MLAJsFkpBiNslPZMRcdhXE7noJUb6SWKMY4YSON/r9xtnoisIa6QYlIryV mC2jylICsFOIp56wQnC4pn+UjhvBFBZDOI9ckJPyDQ/7GPJKxS1xpPBnTRVdGophA97At/FDn6Ot ooak0J6fng9QZL3DAdVhbosfD4JyhB44S/icYGRGoTiqOldf14hkC7xf1JsUaHyx5cDccJy27iCE NBiLY2dlynxMnceMymV4BDvPyg+/JszBESOm9bmIBif/Ma2rq1dGbYHYr1mv5R41cujCmtf6Uqjn 1qGiE0mpgbuOCnSS7IC6GcPpwPWYumFwziXVJUnHBYhnxSe1S6oj3OWmyH4gcbt0dj7/wUZYzF6k fkIvsoZ4D50i0ySPGcfSWc9UfjUtnOm9CilHA2L4/cAKRDYbgdv6Oe1yWdpQD5sbbvB4K2ZxOWfl BvANCqLgUDWISO4M6PDPmQ2vERHdJ+9rYnl0rE0ss8rQkzQ2BIrlxYab4CXJ4ThkiApqWlmpnrk9 M2Dy02vYrDwiytiI2JBACJeOn/NVdlsE8CLqQXZL0dekHBds5NrmG4y2UX80XXnj95zs0X3G1qX/ NNB1GRJsLfQYcH4oPvWfV/U3+P/C5amnb2GzOR7g9Zs/J+v/LyX2AfGt+8gPZ29goaqqnyZYdyIf VoPZMB9koxmJmX4ST215CvMY1aOo1i/XWzrhO+Rp8p/j+pv7v42z0nVYwSbiDO3LJ5ujncs0W9sf ZcO1zc3Rxlq6v7e7trGRbgwPNrO9i8s9bIQC2HFFGkvGWDnhmjlDzNbGTvKqwMAdxO4zbczfwxCX gXiJo1kyFEp4Ugt5xrTp1YW+B4o2J7WFPJX0jJQdEb2RuZTzm1HYA+XwwLkqHl03RE58lVAKIGhD DFzrQVOskNVYAdxraoiEiQiKBe9a5FGY4IGzHZLUPUo+5mnAhTGILh850IpqWNy4IAtSoDTYpK/M iXS2MXvxMeWbow3SOy25vDB0eJ+cd41AtYauDSuzjj6eZeJVEK3G51NxFaYftUSIVqZMRjMuC8gA mBb9S/JxCoeK4qQJE9VvF5Syal0dZuoYli73wa3GwhprTlolSNglMeuGiq+1DBsFtVuE3S6+qP3A WGvcMrjMTpUiGTIQzkMrC64iXgu6TEYedGqaF8UC0HV7HOCU/S0bakkGjqfxuoXXqyVEu46vANoN H33IYYbqykVVprVaNs2U6xMGA0q51LOrg3TvrWruE2uija1KrQlYYJkGgSE4uoyNlaO9b6soMW66 43oydlWKNWPBnnCSh2iNBc/VPOgtJ7VAD5Ml1jMnfE+KFvMIQiJNr9AIQ4V5LbHqjIihKeMmnFTa rKqxtWZf9/oMbYRtiIDU4Nu2UlggiyE7jy4KdhaM2oSLRSzsCbKwJw0QzEuY/zWFfHT3pz8J+JfE ibqTJjBPbqda7DOE4yJVZIxQqAWpK0VJTSklLZdaR7JaLsxeycCol43oPy1k565EBzcViqx8GJ2g jOctsNZwkZ4wSJrGiemKahNaxs2etNmwLEqWg8gKYq61zKgf7cXMAZizhitV/ehe14wPaoJ2hUQH A+LaK3nbe943gr6XLJ1SKCrC0Sm2lZQLuaMs2rJqc1S7PVC9oczWluKm82Jse9auOB6uuHOanAs0 rCnnrYdDJmC5hcGvxDBIHFjUgIMKc4UT+ArgqmIGu0I2neL4A3+XRpyZrZI+/OEmK7UUiSjvxA2l a6UB+zp+jR/jqk4cUthnHxceAMbmJ7Uxnk1lmAezNmJ2XJ+pw9Ib7wheXWVJxuVECiYQC3MwksSk dchEVu4g2261cDplEsZgaLepQ0HDZoz/+deQsoeGlAFLjxk6Sb8aMIVM69gk7x0qZPficLMngxBC 0Bvi0MpLPahjGlnt/375QguNMlHg5aS0I6ryJK0lmCnMOtEDJa9YB6s2fZOWlaRue2O8a4AOlgF6 Ojlag5cczNGJq5STvEzLD7Ob5EU6vZphgskKPLeKwbmI8sSvCfAVjRO7Jn6Zuww8PazMLdwUHepk yDlvgfZo6lwmydSAlDNG7YDMscYPUY/51KxjXquTkMXOa673WfpbiVkitrOzsZGs/JCO1NC7qn1q Fof0OadDv1kkFObmOpfTDHdATXKCt9zBf4eFy9h2bk92rNDNhdsqTKFGbxrf21K0HNnoWMPVXBDw AhnmCdpHnjSsI+7ZlyfnP70+/i8Nhug90098rBbJNE9cjKD7mU4vLPZlcBa0SZ2hhlFXbVE6RVO8 dgDBbWXmnczfjFFgDxoHHUf+GcaEj/pa3JGKkLZ2KgZ8iMPHncTmgPIq0ArdqWTs/4bfqGo99eFJ NwESbD2OllhNa7jAlLuHdCswc1hS0Q1kc2uwubMKXLpQ+3UqB9mB0unOIGecVe5exkoF/Mjiq/NJ EBx52Cq5ka4TySwOGAMupX4C15qGFPS8SiSPutlHXnerpyAMnqx15MVEM3ZrjUubt0erqSNRq6gZ iZZPh9Z+cIH+/da98RIoTduoOBxdNKRwUVIOm0qgrhGRDheg6LL82wuXv5VKRNxHKdmDzdNpMMzK eAm4yrQJxXd176xoeKqip41gU9ZswL9d8CGHCfWJLOMv5VJJKVU0qCEcw+N/XYUxU4cRzK4UCZD4 P7cwTkNiVQELbkxuoH+3pfYBK87XEuUR3PFqZuQREkq/i5UU3OCuYU5PghJKh6ZSZ0C0LL27ghYs mTKCN5VVwQh0YkfZp3r902RMq3nDpjPohr4SW4YgDKYMCiF+dkMvjquF8fUKHSL7IRkZUmdMsmlq SfMqZtX912A3iFjisrlOODdJ5iaetXZVQuBv9ySO026hq++Su1uC1o+ox4S8RNNgpsVmX9cjBzp4 LEI0egUDRWLQjgODoxgYeecoKGHuDvSVHbrno+1x4Ra6lXHApbRpiqQuXnuXPalhQzWatchM1D5E MQm0cGgX0GHDS2hF1BrRPi8ORcA4a34R2zF1iYMgnMLDmY/owkEuapjTSUp5g16us/3QWBwO55SE 5+ABIv4rkhd93IhaTy1QhS9PbcQfITL8JmhVHBpyBw/Q+iRYPLSS3W6+OQEqnIfgNHziVZdjTFhD 8rxlnB+y7vBEYDxUn0O8HAaCsQux7Fv/Tka1CYXx0aRJtIIP+LqYRucFRemxoKiGutCCTxxfl7be InTiKm+91R9IjnIVyqt8zOFKUgNyZMB69PR3mOkTI/sG/A8tuHxvioCPugLm2iKE1miptxNbZ2l+ gbfzrWd5r1LUWIJsgY7uT0dWyTqBAbb7PC+LYnCRlsIB8EJZwwvlqbtOviFU7CoDJX9WX6496dlH X2TTK5RtPsG/39CIxvU3v8cbR2rXfNdDRROobliwcYLbSH6v/k184fipE17g1Wn19Pi7HlYP73kn qH9MHnn7Xc84VWUW6xfFJ04vWO9ZB6o08PbpRX4Fj6y3/sYu/vbfjmHshy/QQ9v681vCGVoPh7vO 47UTXfczpa8f6JndT14ia147I95s9+P8n7919pZYvHt6/FqW8PgpsmL8oWVTkXpl9fSpxuu4rDiI 6MfHoZ12Kpr7kHnyh+ITbgk+Ch85WfCQ5hL8Nrev9aWdWdrtMiLkJ/jcHwZ/GCR/KK6nVTGVnvSn RaOZ31ELycc/Hz9lOsHfDTlvJK//KG/733/T2nLLFt9n/+mEtRzoxil+6GR2NrbRl3mRj0bZdNGc TDN6LFjmJswsfJhuHgo/jGwhWt9UxRI3FYNA0743c3rqstRRC/OOdsscyoxsJJQt4Isug5o9Zg2T ZOdBay8t45QnDNOJGOn8S3dReIq7K/MqStvAIPs5ou4cViXFs1v1cfWUVk6HJPX3EktTlVaUZMFN VEuU8BpauM4BZTBqBH1dGMZlW8mMbGjQw6JkAHEsWnfiKDfhiL5cWljNSBA5qUUYSzlSmwrOhqIo QyXwN0vkoi2Wi+LsVi8XvVPcFmLm0Ptb1dtQe/5MIUn0gqxcXy4qiUln819893YUm2TB1qND9Kso cm9RxNPIrwLJIwskP6WjMk8fRxZxTx0/VahsxCdbPJzNg4P9tc2ttY3N8839pztbT7c21zaePN3Y mD+Gjs3zSEZ5dTNO76aLZkb/lN+F3oZ5I+jSrCN6urtq2WRZINeLlXziZxc0G+R4Lt/x46cUMzKt y7vFD0dvUCSUH7bDI7CjDp7r3HK4HhS1Eze6cBlcc+ud5/aIC8GgB1/aKqhsvIx2/gVaRUdR9+FX x2UJHznI+/+eS+SHR79EHsq7nzzd2v+X8+6fzkHqt8rCvEF0Z99XWS0unzHJS4sHsrO7tbuo386t xZ0vZwIk82kGxPL+O1wx8HBWp1eLu/3557ufPy3pcmErri8sqqHh/4v7fInUc9dPgPT+kE7XDp4k GwdPt3af7u4lP748XzKYTt00r+7YBBk/++t9rM39eh//X3wfP9wStNXJEsTRGR+LD+3xTAtveHXi BiExxWWy2U8mHGwc21vIYc/YH2GyA8LOIdQjpjyUWIgdvwmjPbAdNTCZcHpy1YupJPAwmyHYaBBx oSkyh9infIiDOPrmxHuh+5Yn1KWKr27DTuhl4zkvXlo0Jlb5p5ZhsBUMlmsxnLT2rUEHC4UmllP6 S59jXbSPQUiBXMGod/Cluef5KcvSeVfx2+AAdlvDPbOGVA4qtiWi+ZBxLdd8iZWWWqKb2xyNTVZC QtgLYIL0HHBKgslXj+CIsA3JT4mFjFUtcRhGCpoWudQHDpVI0tU0MrNhpCzy1PccXfTovCouC7R6 nA1dLAEcOxQQKUx1lzX7Ny/7HAJKNbx+xvTCJwkcAIQ5zTgOSS7wFbudq32BFtGKPb2mst5LVsxm wxtxlpJPpkDBecUSwipTgoOJ9ah7DkWFfo/x96pkJaCc1W6ks3/v4+d1F8YHyKcRWlUIe9XtJD7p fhKTFS2hYJE6Ka6PH+iZ4dwlsqaNU9k4knpMY4rtR9/yaZXvUJq0b1qB7pEP+YHZKXuQ554Mv1Hx 0WD7NZ+O4GjsseL06Ecj0IXi00Ek7WLZeNHxbdRfpNLRSoONYPLQy9OXJ3yCOLCl59SOnn3DnSoD b0yjI3WBH8V9hGckH4Z4qMv+xYRUEfJBwp9hZsvmFi3aE1q0WN5fiehAl0WjDoPDb+9iVypN8NiD SKCFTILS5CJO4QDYOnKKZa6ZbXbNxKiWsWtGg38C30zqfTN3FM/yy/tn/mVOiNAj0+p90DUK3TH/ lzljGq6Y1qVYYEvr7oSZYz1bZjt7dMvZYr18XnxR+JRlqIufNEx08YPdTQcBX2h91FHqvB8Xa37z 9b45Wl+7DfZzqSayv34Z9PMLUEZ8rXZ9ejklyZ269CF7Uf7/DxXTlw+wW2x3jWCJzBbdw1f8Gel7 UK2WMJYQTFBjcenin2tpULEwMiGw1QGbufChKgPVQqdFaEPhSrIVNU5F5zFFr0ILCbYgGTsm68iA PrSNJYrf9ngiZsnI3jIeMy5wWVxl0zsTbexGvFSK37b1lhTcsvbJ5IpW4re0u7lpvk2E1bDl9ot/ czvHtrHXdFdWPZpS36I8q+3NWg9sjoEqtp+/nPdYpk6Kp9E1Sfe8h+Kprz5g4b2ByTMcRgwcZROq lUy132qOV8QFRibgAUnQ9s34CjwMRofho+qeckeedHm6V3uYacQp3D4GUvaMLSFYMXWcD4ET9OBI loh/MKImQa9DpLz80yqolHWtoDZ+TGJvJb7jUv0o3x+OOoi24wJToDV9EoGFCE+Xf9akSs0IwlY4 JYhHg9WZa627bIBZCp82grAUlK6JBjFJZyX7pRgzSFgO1hDpqgNk0xOOootj6NpyhalUBycL08cu 2cJb87OFt6JsYWpTcyVcPfYkqEAeIMdE9mhKWqQIQ8qsX1eA5Hnn8l4Zx8sof8umuy7J420k8QYz F6KXiitc8D1YA5fc7xfD1cm2xiyusdjH9egLbgCtRpDnK/RDdaeEZBJU06leC5fhoOMHO0YYWpWr WKNAXJhVjcmFM1AQ+xH0U1RrlgulI4BzM//WL5GkycTFWTMGtAkwQ6JKEF02aTu4FdiZMsECLFc+ 7TVt7kqQCda60HZdCabUbZluIw6fYWYQri3xDXG+VbDJnKQlECMr+SAb9CUviQNZL4q6LiarA5bt zIvUgeAwpIxQ5QOUSwxP9l8MtEAKc8c7yUuk4cFRmZViotHBEzPTxvJGrxc0mdl0hH14t1OUbmmE tvY1YskMFnrsKpZdYqqiHnk6wrmlTjnxQuB0lu3grMtia4Bei6U5V1ucc7XVyLliUwkIZCMpY+CS 49GcsmLtKavOajW/k7kAIrj/ipnFZRAlDXJIPeMKMwYs1wBnSE9afoHiSFsG5Fu51Iq9roQDFTAi OSWoYTSbYg1Ee1PBRl3ncAAJO/Qu2VrfXt9Z3/30CZOR5YYMBqt1pzsNbPkJtrgCqGStvP7jarJG qwfMZMKGTsIBZlSiSjKEhZJArMs/Af2R2AF0U6mLhGmn4hEiI+jTSDeTlSO2hGOd+2yCD5gC993G qzwHsz1WXLqHGzaXiKU90ZKgBv6Ds9QrSVP3Xq67vlal5No9SBINFaXb+Hbc+A5gugL6Gw5PECe5 arMDauCsA19OTRJXaVB+kVwOvMs3UWBNzvKtTJl3PMqIFLbGztnx3b0no2J/ABHPU/EXpoXpiGDK Zb7MQomXVAIPbbDiLXYo+RQE5TsCCHan0kNQRd1o3oSgD+RLs2q3giTsXTxKwEZ9wsVZXZRwl7kp MxHNS88gYZGuWMxpH8JFFG5UB1v/lgiQC9IwjMR4Hzs+X8DroCktAuFFZWrINef+xZkVRhYIswnw Mf7m/wSWv9ttHPk6lTlPy1G1/vP2wWB3Y72RfgCDnxvvOc8o9X/EgNyaSWaeOnRR8X/IJ1gwrM7Q eEJGJ/trpybeFnfJcwEnXtqCPNA+zNbAIY0Hyup4hZh9L1wkHutRcXNH2Uhrr2/JJXA1J3vPhRHZ hs2Tfrf/L3HBLMqHuScFP0r+DDasZ/9xAp89FTBRVp+Xu7m1kzwHKRWY+rEUkBzePShi7TMm0pmc u0wIrn+9/T93HvMSPN14k9dSdGVKF9MFyvXjjLUUkslQqAERLorma01FfeSIv63FEX/m9jZVjd1V K0JMDAyDf3dg/UKY7gaWWhQFi9Wkv9sLukuTnkSwEVr2wHgWkZBve+iKTJDhmlCAsVSG1X0l8GEo la+13AiKHng+VhoHRAFnsBFSD1Q4jGeOdVkJzbvi9U9Zg2OtR2vmOVEfwUOwqGom8WLaqithQToa TcKYSuZNvZPdjEIc4gCH2G5GddF6z7jgG8NNdjGbbc83m1kDBjfrLDEOt9ZW5AqqEoppihe/g3XK dtBBbd5mtXm7oTY7GW+xRrwdaMTcOc+lakzGxLw69FTOEPdiPkPxx6a8lkp3i0x/gl2Gid1Ud87h ycimmsobx2wy4R+8RaPvIC2dZc/hJtuOrM+htaxkX/Txllnh9vfWezy5aSFlD+GMVzVhpSMUjsA0 eYsWtiNDfx/OytcdWrr+HJKFkODSm9CRQj5T3/159Up8HdADbMeon7asV9JAfPcIa47emarDalTD 9RFVpJqkI/EmTcU4xsWqpkWpD+oi6eI66yDCY9MqLVHNtgPjBC2oK/SoLlaPA2hR5MTbkN0idDKb G6LJiFFUa3aKB6DbiDwOIA8nNnuigcaBXAXGUOHkinPoMM7CdhxKNNlPvcuVlOt8QqYi3SSx7/mZ IXQzT4Ytr5bYob2czV/6iBjHAx9s5ICtkNJ0fdxRjxBlOcY2nIbG+6E6D1dJo+opGvuwOAZdsIr8 6s1dvqLt5m6y8m7qo6BfZqM8TVCej4n6nNBg4WZjf7ZbZRkZXmKCkWc2DRvDQVZcoNMHZjPhwpej Yjhjh3pKw2IzcIS6D8wlJUcZP9sJcmGbdf3thq5vzaLLmbytIa4aUiVloKJNcei6DjELIcv4GS44 Nl0T582EQVq9OWr56dgKjInW1qcWRXcAsYo5mZRnZVALwYTK8g4g42b0YZUjlo1gkXmQWIfKQYjS lqVUx4NtfbcFHlzGXa+eJpur3lvCZh+lYSpBxgdFvMvstPGHRi5RxLKjabjbNJ/SlJxrkTj51iqL ofEFZbzl9m4SJLYLYHxqsxxSoebOfGwrMFPOqQ+9piIDFs4TKP8AnYVdC6RmrCPl0LgyIwJ1G8ju PHvpYVBBk2eKlbbSkZNS7LLMsFIxGzoz4lqIXk+YfXTK65CtEe8nWBwhuG6DVVPhIrYU2grbyj0b P6vEUDuO320Y+10tlnMgnf0LbAIXB7kxWrILPcKATdJLNI7X10oJjkhZqgtF28W8jwX+BTHNRH3L 2d924PUxMRJe1ArIaIwa1PptdoHlstc/IWZQtW5KVsm+oQ7IHwdFqSDhXWytfGgaHbSbW30PDzV5 bSbCZbWBxWrWDq76TrTmP56c95OfTg6P6Y7sXLv5CdW7th4377vANIWTc3K8zaZYP+tKC2Bw7Eej RC4JipVNftKrOAWhpucgYh3+qMVJXhFnJn5DHODSpxysksC4SCXpWST/50dbG3tPHJL/T3coGmWf 6uQc63ddQsdvpMhXsrbmNgLB/PlNBfPHSWgR0jlTtmVHRLuuNYwAht/zAVQ9EYwk7QtGO4OFXkON gGpTfMxBmXB4rb6VUJZzBcULPKeoWmXjCmOJ6uKKkD8HHGcjmRAeXloraojLWUs/4RRj0FQRj1L0 jcP3ZZkJ0JikVsoVdZ3fmMutazlmJjgVMc64Ljri5XpordCdTTRN2PG0HUZb8Ai1VkLvy3VvqJia YDJ2WSkRHUfKhTMALC+P9ASrqT9pVFOnkuD3PIq2jDpboziySleD8lFB3krHiRY/0OKpfCioU6lp k+GlSYdPTosWT5hi4S+sizoiE5RTGDxgbEipdajvcCcxG7DXsrvmeWsoaJTL2/uKgEHdWOjyKoOf neguFZY9OzebSd0v3syAnDtZrvZwC+N6yLHlioum957xf73RatEducf2n2ZhTqnAjhTyCuQuTyUo /zPtLbs39xZVnjBFeiicibvzhjFb5HwOQh87s7ERh5LcXqHeCmuBHkuGIY6a+Y2fs42fUaqUaiVc i356R7jRarHsHJLGCpMlxQDrm+OdpfQ6Db6LlLPHGt5eQ8MzOxie8SWbtiAA0AbohjsW8+jlNRKw HVMmgQyhFHs7WFB5raUGBds3ZDTNq4Lqi2mtKlRndADLroG9QNeU9jVKqfIXlumtEesYmArZEIJm N2++DckFtba5AOAuMkHUoW7j3/bHDJdhjv00Nb0ZLUj9O3RMpPSB3Pj8/NdVbEIUxV/ehFuzQAqg snO5C+v1Qa9DDZMfdtwPV0sBJqPVwlwJANpt2SmF6VeumwdBfSjd3dlrRCos32ttd63dsMnE0NhB JntaQ9O5L35Eok4+1fxxlzLgY6Y7DWTPbnIYEuhrDQiwPVlSXRm5FnogLtYk39pU1ORQMbfCLeFh FOU4z51EA6wicHXp0jT1G2elWmXD252GhFXpJV7H4+yy5hrjptavMA6SERFxnu0rclY9sRZBhe3A b6ZU74yk3CRTixojdZn1DtCWv3YpJHGBvS2u4mCiAOashEP6by6JXV3WvDH4zMcGaqRfznVdaN7S r+80d3KLBsVL8Vm2cS73Ge1psOVeS7il161VDOkaQCSn5x5pwF9+BMeoJYJj1JpIO1oUkTHqBkun 9L5NfvbRvOCMUXvsxHbCsXnychxoIF+3uvRH93fp70WRmJFTnw8dl6lB3s2HlmSKTitA7qGmoM8F yemeRsdTYUMDUUrxUYGmujLR8qBZXoWaiYe4JM+Lkm54bINAxxC+hizNCB/3bJ4kS3SOMc6478sC R4uFuBnmIZHFkorHJZoJ+QDbITOnXp/ABkw1+Ehou5ZymfgGXzZ8ffepXPINg0OolEaaNeUAjgI2 7xWFYhrDr3iNaqFOtY8sLC583siieXfeewb/002b2me+uN/gitDCZ6lS+4tUqT3nLcRuvMJNqY2+ dLe77crsZpwOJZ8LjRbWVCE+tcgoCzv6ZmlKjsSNy0UJkg9Z8SUpgYbmZSCUxBUpiGSS2xzNRJeX MGUioOdsRwodyN4nWFxN859lCrZMVlQDjS0u7OTRsPZUypmls7pA296Qrmfg+SXqK9bkJzW1OBFU vJiXOVYuxedvKIEsre4R77wfFdnDRaFObgWYSwXC2O9jZBVnYVKznwZtY04aYtCNWpw8y533XVTN fVY19xuqppL3PfTM/UV6proeDj2tyaK4+0jhcXiJHtu4ylalHs6LOQ0TtYsdS7VmqaYR8qlB2RSE QOKVI3FioE9mLHK1jWnpqQ2N7pSq0p12MDZwTNkrT4aIyADIBJNPXJIHyRmGaLiMOrBjbtfqOmT4 yKtoCXM6RCqtOlcOrz/3X+MK6lj5mNC2a5xAqHtzihssoeRWAfd3kRpxGJTuso+EMlYS7xhZSEtb sTqGuzcvKmaeSUm03EWBMVJ+NgifGRW+Ypy7+xcEznSOmgl0VI2P4eD6vBKlVb3ZuOUaGRMWsdN1 DzIw4zCZZfcllmQexEWZ4/vy6PWbP/ee4f/eI3buyXxOYIt0UauyqH43RzMuhOhYv7vlTLDTstq0 mqeGN2XajJVqvk7xW6L1m7dYxJE4EfODMXap2iyH28aUBGbsOpwx62uBQdzed9Gkl11ET6LkVwYP 7BZhaAY1YL1M0s/0IdWJ7X45eryapcBFaqkpkl7k45zru5GR/ubOXHWD8DC4ABhUsMt0UrkwqLIY B/xNF6hCEAhxf9JlksoV21dxQCRcU+WU+WwwDjZCu/AKzua9uclAN5QT2NLfcjVaaj43qz7TuuEi usuu7ConPgnCMR0njKjDJ0gZFhg633T/DB/LqxaxBHlpHNZpj5Ez0bOvH1mUI3K4PoZSoridilG4 ogsWLqQ0KEeL20lhAqkaLy5nY144jNvjnerHSCTGAR91pIfSMRMn3M7lCT5vmt1GlA+nJsk0hFOp +iZR1Btf1G9GdyjQnKnwxPVvfch3Nv2Yl8WUi03Wvg0/OJFuYSQg40ily6luiQZozIiYL4HXFIJG MKsr4G78EEqPWncWs78LG4nXlwDVSg5ulTE0Y3jyJKtuJHMqMQndX8JLzx1bS1H+cFw9du+FsSIN imOA09mFqOKclSCx7uIfbttSNhjisHgzVVCJ+eqytqPnsZmo5blD6CKBC/ZDE/3B8YyWEknz25qb zKzZ1yyXVZhiHB0kwx4lhxShOcZe4Ut5TG7vl19JVoh7kYcoEGIiDY9oqg4UVuGYSqDrcf4xxixt YU1mT08vbRngwD+MyCbQFTYp/kL00rA7qck1+kkB+mu9BjuxRp/6iUMysUPFBRj1AzSEu0UcJ2I4 xBFIV3YhGNqKOyoW3KDT0ts0hUWtkWlIMpqZe4dIxGbVCjTXY6DuJSxILQnqyJTH0faSKIrak2Pm 4zvbThCJ7uRWCVHHNo3vTauMt1BBWzdL+iC4YtNM+5LkgaJqsQu2uh3rbT7WcaSaO9b30KyfROFq oSDW5iE1Ze7ba9yLjzV2vcox8BhcYcH7Zv32di8uDYmZRav71qB9bZANHtbD99nAJWktsU7q/EZP vbBmyMFQdHOXWnJ4kb0lh4d/KQZMb71c6C/uHjjgdT0mVuEBKpM+QEfpB7Bn6nX2oQfmTnfeZ9O7 kYc5/OojPSPIWXDrz0qEqsWChdclW4Hx2IOiMG6JGkuuc7glyuH1Ui/wkwAjz6+7hhfAFlMc8eKF F8z9iDugTRIZ/33d8+wviBap20SWu7PlZDzMnS375XwV2SeM4fZR3226a6dxB4EgjTZ4C8JKmPZW M8EzsVWMdRYTKmVSTaJNDDZH5bXIZe1Zhx2lO00uQIviki+xZW0ICJikaBtVj997SgVRsCC7tO03 8eln66lUiUDHpa4Mj0ecNJezKSWAOoiJcJDGm6VPXqyzDEK+6ei3FE1DnMzDSFyU8oIXGTaEjpM0 6AAWpdE6Gpc6EcBerGLaO2Zp5AO5n5zZal7wQ5vQtoLVSPV+3QXV2NBRGJfZGmSCkQTOXpE3wiVI XL/OCeyf1TEbUGajXE3Aoot7YbPBNDiIMQ8JyBlruxoEcMaM8i07b131Ib8Rk+3soi4zwgeXJFs2 BGv6KI7WLyU2YOD3WGPGwMthLXOjyff9BnpzqQjcdXknyhmubUX63wT1QDmPRZlf5bw4MHn/empi e/3ESAbgVROATdhZNKR6Nya3Q1EqMtlKj0fussT6LqrDV5uohhRg4kKbaWpr6DHEufp1XpWDe9ni YJrqzZ3JRR7NCg+Xca9FNnk4gf0wos/ubyX5i2KlHa7LDUytBDE7Snv0PAHb6/oEi6ZpKrJownKG 6wMbtczJFOgcmCEZ2233NO5yslot4pTVWsuqtqxPTLIB5dybbAIrTydWtN8S/ZRPNXlE8GADEXhB aJQQ1tzoqE6hUdjI4uioLvOypu/Fmfmclr8wiggbWggvxql81rZLPVd+VhQ4je34CKxCgiEWBWB5 AUyxdTW2vz38SmWWMPqqPfRKL2t2eDYjrkx+4HojDsqsXWXoNl6/tNIi3bCSC5aQ0yF/o0obL2Il kWtwRoqiH8WvtazeHcuR88OzOiV9SgpOMwmHRqbCxms4r1w14ieSTZbrlTYV5zRwSku6YMuF3ezN AT2TInbe4/NzU6JODQxDGKweXGIQ8W0rzzAZSdwYHedGlPEio4rLNcZWWsbHqCBF0nve82fc8yqi 8MB9tnBLdnlL4jyM++ThhhkYbemvsV2bY5Yaxg6mSufq8HNiB4Bnc/ON/ct52G6QqhsdvnsNlxRO VtayNRfPMt+GumxUi9H9TF22SGmp9HSSp6dbX3OR+g4N/3MR104mbhwkkuEx+/QXSj3l0bo82c2t ZOUNxtlIrrLgJkUgdRS4P9WAGg3x1iOFBrgpMq4mDjva6DyVLTKtib1nDguhs6ksJkgnjZYudH0x Lki3JXHZuE10wnZHQqpxhN3a92m2sOQ/pKPkR5jFbXrnssnRX8L4s+5OHIXKLLFZJ76YPKr4WRc/ dTmruBShZHVbaafbsJ+4YS/JDm5dpCBTmC2DIcLh/TKFWZCPkoXvkSksCVbNFCsfzUxXJ90xjgyX s+u9eXnDIMjf+pJ4RtHHuE0EQpgNQWkazdb/30vB5jNQ93CuWaUxpkA6b2qqmNMW7HlZrV+utzQp UQjAprGheWJSAPCUtUQWtnsm8UQUsmjQ5j3ynGnR29egPTLcTJdEAz+Kpw9YlYcGmO8kfgGDlOkF BLjPBBjHo7YRIDR+Dxrcn+vkC4nRBTBEIgETm1N7SfVGS6kzKjbYshObMMbt0OsYWPNtc4sIrPVq oSKRInVbjWKeQ0yK0SnKE/GIL4i4rND5NHn+MGLDi7plMbtSHcd0NaK6Iqoj4c97oLqndPAS36es 27xF1Vh2uuXCgPZI5Kd+/3X5HA1ZZnFSx4csu0lRUMIffivJEsGX2vR6s+3/S2BMuyXBfGYWTEQ4 b7fWH5IE037a5mTEPHZKDIftbQeul7By0mw6zVB5wkoLqfpd2IhgQ2icrzWy+eUiEi7I2vVJHCOX wOGSYgbNNJ1JUdWx3FZhYBZWRtErJBxGnzEhRbyx6uBAbfexK+gt3SqcytLnPsf5B44jkvA9ODug pky4T9VU1MhgNJXIJ7hCs8mrAKJwqdLCGXo/+DusZL2gYXp9u9XnAg+wRG+3vq6cfwCXQPRz1td1 5tNCswZplUSRYi8IQrtrAzJxFY6p1wnMeJL/LDfpDAsVEHqUjVlg62OngOADvDwOlsFpvv7TSe8Z /u89AoIP5gcE2zK51KqXVCh6YF5gt0QvjosrDMGhNfnvWf4xHaPKITh2IPes4NlY1XA93m3jP2LK yaYY+S2U4hAj7SuppmMFgY3oHcBNSwmTssw4Q0zhvOAH71xI62LCsUIims8ZBEg92Q01g53HsLZq J2PUazTgUpq9UDCCGbioPrIv4GNaNoTsHVG6sLV6s6NDLON3cwIr+zSKIp+6sCW0IbVbbvheCVPo 2pzLUQA1bTuMF4mBPGZseCX9l0PvaV/oGWJ8EqLI1XSCWGXxc6hVmcjLGcPvVSMoHMxgQZC06WRO kDTtLsdJc7Appu5FwckeGyWMhVysyR8YC12HUGuGdhm7mGsTa4p1ORqxoK1R2Od4AmDy2ZJY0Hia yLcJ7dJU22oEYtOtopGY8Jw3h3RZiu37mbb7C5UTxXBk6zS5EdIEQ23XOHBPOUPIw+JyTHJt1mUu XELeinWuDuHmBxxuftAIN6cR3C909KBRB8eKF3GgKHbQl7AWvXHD6EVz6bbep3136B1BpWFpMd5p f4V1Crs74Gjag0Y0rVuSe4TdHQThtIfcxhynxMLoJHx9cTTYBfNuFwaG38XYI5Ey1Yj66hLkxBys BYbEd682pyoOA7MxYEzJjxkGdhAEC59HfPRfA0ajAjWf6OVANCaEsdNst5fGirGU9aBIMd7QxwwU OwjwWmIeMeduz6vghLN0SgdRclEwkS/ODFw2hgZOi6WVR4xVuihk9eZ4kGzsEpnOffhSx9ilMHTJ C/Ya0UChSwKYf4/IJX/fGoighZFLmeIGhGyrEcIUxC9lUUzOnGAmWuLWeCYbzKSK5jDFIoZpFNpk 1Z6+E3bnhTe1B6mw50niVHh5WoOalkQ0ucVtD2qau97/moAnGmkU5hTHOJF4c+8wp0agndBp9ygn 3Cz/0nCdU326xTrpoYj0w4ATLox0YmXJbPd9A+QiAjS01I2L/TuCPHUZ9/6/IIwp1Nw4jEmsJhyC Q+LiLxfDJLdplxAmJ/4+JITJxx7xqmFDnxe/5EWY9vivf0b40gFnwxw0smFoWx8avnQQpMX8s8KX XP2fLzt86YAjyg4aEWX3CV86CALIHhS+JBWNuFTtNLsNjqBF9m9LDF3GrXYeIWDJKUaPE6/Eg/rn xCtxX19KvBKP9td4pcaSLIhXUvGgnMtT7hG9xL39m0YvLeNmu8zN4mBMUxiAlHi8JELIruU8bveX jPmxZh8i2c8J+TlXz1sI5t5OF66IG59SE88j+aFzX1VXoafjJNLeCHxO2hBPGRIECezz87b7oaTK AUpV42q5T1kF3PQvL9zIl2eA718IRXzOAJYcnj0+PPNj5fzheUjQCO/CLxw0EkTekDz4NFlBx3xx k8KYkAUS6uPTy2zzyc7lVra2l2XDtZ3N0cbacH9vd21jMx0Nd/eyvYuLHZzKqq5DayvZzu7O5fbl 9lo6HEEru1vp2u7ecH9tYyPdHR5sZjsX+/uulX/H6JWvMRrj61+jV7pGr7Sv1yMFrxw9LHjln4zg ekDhr4vwW02helNuPZnOFLjfo69WDuudmb5groJUahFaCWkl4xvyIjONoqLdMH332WLbLj+jknHH 7nqR+hw8Tm3h3QTUwoHHRpebkRdjLFm44kjgCQYZX3adiGHgZA2sZmGcSh45Lni+xVjRNWAlbMgF r+DbwU9RKEvHOBYyoy0IZVkexxL7Abehy3cVCpRXhNgzQ024VszDa0LvzD5ivb6xyKkIXvQxJ/UN YfGxrlBeTdqBkvAPPF+4wwQpSVBysGgE/zi+k7oShJtIXv9xemeqOiyMrtncwGt2c2NJfM2L10d/ 7D3D/71HfM3mxvwAG+h3ASJQlXA9Z3HFUr96ECQixBW1palj1VTGFyHyL7gOQcomIUSwc3Ym14PY PLBtf858vwQuwBTiC68427iCWirFRK2Q5YDO9Ejsj84Tb8akX9GQSfJmvkFcZ7lqRMu7Zdx1Xoym JZIYkCpeQrIO9VHmJQqfTVy4iDI+VDQVvhGn4g2fhMbpUWjwBOfTDmEBMNZNJrRGYMBrtRUtU3rw 3cD3befk8dgcaKNb2kZQHX6LCLzYjMXXKRq26gGJuh+0F4fNasuuptqMRQOOXRdYeZBKSdv+HKI+ DsjsvZbzTTQsEI2Il7AL1/5OOtdNdTiboAJrnkuanOeTDA9ENy+qLK0S0xHdmIpKSrjYTPo4TonS KS9yYDhljtGPecXxMUhTeO5q6FwQWq7ScjQ21g52TLt4QPwqGiqzBPnSeMwFcMWmhsSuXlHd88uk R0DLRQkCVVqy432Yl8PZBIu0ohdMoFS1LnkQl4ROohGejQraqAlCEA8X3mC8uERVZq5q66ju4NxO GDCyTKtrinikwDe45gTFKq9Zo65kDpJ+ZFjB11Ui9SfR+nre8JMITelhddgj+j4W60PF+c6WTBfk sfvgdQlRGNEKBsoRf7oN/oyxwAG0Ugzz1CHXp83axfg0YrDjsVo7p7fc9KLQOxd2kDcT352oZZEZ g/OAT3AyKXYJe/yqqH0FOFFidQgalRFWtg8rZFguyIfedK3nMxiC+iz8MFQkC+2Pi1Vh2Ict4Z1x BBESx4kL9HpBpxOYmAFRR/Z9j/Ai7COuhKhiiNC9BE9wKdv2lDkThkUuQCzxijyRrkVPIgEIZYCb qtf4NHJ/CUxypRUTTJ9f3wchXaZpoxKDil16xLGnVGLI6PL2AZLpiMDcPFvwpaVx1UCwnpVuYSQY T5F1ZzdFiK3LQoGayTDoEe+z8cfOBLItBBL7sl7QTXcFV5qDM3zbFeUVmwvu2wiBX8rXfkzzMdu6 JfaKTPDkFkapnS5REcf1/FcUNnTH2ZcuWh+PBboTBj56E/mEPVDtBMHBUrCEeFYvbU2J62JKOOkY K03R0DSeilknj5bv6dCBXeHulpjh4PzmS3dgR3Ygdl1x8BZSvuxFh2WPi5EGAWCy+CT9ukgqIwoB Af6JPbHeQY8NbSSEWCKQcbaMVthUEzQvFG4lSNkHlBBLtWHJsaxpf/yNW5LOkol1mB1Gw7uU629D ddIi+RvGAjXYgxcCsZlmtGPHcZjg3cZaeV+oW2Ub6RANI/E3eFC/zaesxKh5LkrH0TIKFSMQK7Uh F9jYN0GUzmBwGN5XhMEsFcKocCtfaUCh4+BO5wPiygRUrveIApzVXk85WykojuTdK6KJPHJj2hrc JOpSj30Hj++vihAmEKRj076TQbzD8Iri2lU7DAJR+wuh8Z3s4S5/3gphOnz/axkGvNJEGOOoH2ui s3K+KJVyHeqC8oBWqlUyDmRTqYHHc6EoCfbGyGTQqoEiIQnWFIkPJKFRDwq1DTyXAiqxNk4ux9/d 1Y48xIHBi4hsYVpEK9zNOSeHwhTZhIYaZ8JZnhwzcfy8jooFkGF+ThitSQ5TV49PCevGo3eFR8cO uVM8YakJoWXOyZaOLvfkbsSwc9MgSU40awEzLdEO5BJICNNVbQQqGOjuqOnCR2SGBgX3TD+EKNc6 lQKpGl6XIpOOCXkbGQxfycwtWJ7puqB7sqCxk4Z05qNicgMauYhM53iXdljKvWgpa5ItMOni1hln Iu2Psd01OBXVkFihTshFPMpCSGnns9M8Yg/G+IEF2/Uk+Tv8cHadohRBs+JvTj6BfFsJ9C99rz3p v78n8b+/y6P4yndt/3637Bt88xUKVW1Nn5ezrPkNvrLW9u93y775TWPiCzt7DsLyZ/bmFtV26Npu 9vbbud0t/bfcryCkqBf+i+wKjt1Tnvh3TCIiiXn+zOOUX42EhQ24p3773SnRYw76xhXWsCY99aYE lSm/gb9JKHbskYPUlZzr23x5NI+M3MbEDxuUHZV7yqvQJoNFLynBFdSi2WTqatWNDanLTRHErFzm JbxUFrcDwwjVUu6iGTFPbjqStqljtYW4quxBT82CNSKsMHmqWnqdjUfhCfdRwY605OHA0so+fuY0 sEwl1YPrXeJu9vpq7HBZvLT1KGSKa8WQQDeuuS9cM0bhuE+UG74ehLltJCuv/6ghOHbxVDWS0j2x yUivmjarUdUwwaDM04H+9o3IvixoynXR7rjKsFLaMKO9UTHRhyCX1u7n/U0VbFfl00XdLTANzL/3 NIbt2xi5ZtiTPUtS4RHrEmOHJglEBeQyw/y7ziTzREhmPoTGWU4fiHO6gIeuwRAknqzfFuUHyntY v80uRunHdaSEokrHg1ExbIuPoKcG1cUgLcYI7Uvshg23T0Go4sj2fnJGe7+2s7kh/x7Dkw7fH85g WUvx0D1NjvMr3GSMPOFVzP522+vLUpVZOp7QV983ht0jB+MQ3hgMBu6NWZl/11u8JqZ1Vg2khYQD M/ivh/v8j586SmWH/3Grw58fIzMdbTJ95Rjeun63Hj0XN4BipH+folbid/UR+yp5NVqCA47bIg2C +DPYC3bmDmuKC5KOwmAD+TLoxYwIF+dzIjw2ktd/fAxq/Iw9JrO87m8bfAvP1PHn1rVGXeMjRQJF P3/uJrc18kBSi5uijBf8WTjFnbzqvm9/rY3g5pFe6yP0rytRzu2kQamNn+cOlMdYM6PEB4RB7m3s PNnYkLfNzwu2E2/LB65FI3hsf3O0c5lma7ujbLi2tTXaW7vM0l0MHtvA4LG9i2znM1Zj3nDl5zYC Nm82qF9+w8PTLU4IL88A16YRM0uShNehA1BSK0FysLWK5EEMqhBVfMEsvkVMnfWonWXE6dzL6jmI S8tqrA+7no2PUMRzEZwI4owLCOE2wFFcu0gpukJcszfFOB+SG5Fq+jYEMQdIjqaFSs2RItBFJXC9 kUFS6TZBkMg+JCtM/higAYdBys8HPju+pfvutmXpnuk4oUBTifC3dZ+hU0SsMDpKIDY42TBEOFgi jh2IOBbD0nhx7C37A9ku+J4oBkWzf2uRbG50ahfW4OJKvxCp7FeB4VeBwT+zUGD4VVb4/z9Z4SCW FfSe0BrqHO6h1xxdSlktBU80KmhWVxx3kmviicKwcEhyWn2QgFybCa7vEnyHNW9cF1LlFF2MV9NC su6ckSwKfu7PvTN/47a09drsemdiM/e6NjXYtBlvarI6KOJegxQ+z57Bd8NjX5O/ABJo8sVcm49p zJh/dz3QFvHZdpAv25jxb5SuctySrjJvwxekqzTXvalaMSUDnymzev71wq215atsbCcu2Vneb01Z aRvoI05g2dDxqOK45l/yer+1iICW+N012NpIa0bPTtJA05izUna5miOes47y9b1Tf+giWazTp2E4 aLsa3wZSa8tWDq/z8ajMpibpxgVqhwlG2IiP8JF4X3Rb5yUDcrhLfkzHTGQH9GdpGB1xYYo/uM0p dFR1cMQ1h924yMdjTlMmNTl8WcOF3fXcEqoi9dUXWAuMLzL9IEErhcgiMmCbe5TidZrcpFcYXPei S1TxRuSelGpaFYXmhOADHtY9DKQi2aMTTxjYjCPrPBoqDJQEDanTRpFywxgnzh/SsCOyS1B4qA0o nuNH03W1cV7qC/Lur9T5JLGyeQvI8aL4bnhqclNL1gG2E6ZolZkgOpFMWgNxUwFrjRe2M+26f7vt GXfzhc5fyFCzMLmJc07ijJM4uYmj03rPJErtHglOmwsSnGwQi7TsskjQ/GUSVJo4jMYX6uMEg5B5 uxgcLRaRmAdhdKgHBgQs8uuKTRCj9YLYTjbrtYT2ce6Z2Ew1wMuM2gTharSei/bCVmRFdB4Moetg YpYsuU16agfL7ZICRczahK0Gm9Qlp2lTcpo2GzlNXp3hRrtrLjKIpqiOjPo+Rj9PLE+TNpteuru5 O7xMd0CFh//Z2so21y53L1iF39lFFf5yXy/oL0Q3ecQ6KgsJcHN+wnG/26HGN3sP2ZGehK4EYbRq TndcoNslOY/CNKrW5KU5duFj+ynMGm/KEChDY3GCMUk871L2g6xyUQFFmTzFqyO4LTA/vKhd8MtF kFlMMbGtUbsdmMymjWv9V19xyIZKEDPTqvquNy1QPqt7SZX/DCPf7GEY1Ag+YUbttxzEFD96QZlb +EgyzMbjm3TEqpv8jWRAf2/1ktt8VF9/19vewCIM+dU1KImbuz3YwvwKVL8Sv+lBNyX8PxD2FYjM BTT8HwcHaB5xzw0xnLmc1xquOyo6cl/WcMCToxeHZ2ff9cb59MMWPHChc5Av/nH++ugf365fPON7 uR7h/5T4PzjhZ99eb7Zv5kHvWeykoVTqnwTaFmWzY0z0yy8oEl02hNI0Np8tkC4I6LoJc+2e/enk 8Pjk7X/B9dR7hneUwsd5qUI4Ef74XYKqcS/pPYX/hx39S68PH7Z6f+VPm/8BmjsoXn9dxp4OgjRO 0oc0ENskTsZp+8EticOphtfZJFVLoWadB2DYg+VI9ZJWoEkf8KhJKoGXX785P3396swdoSVZWwcB 3z13YWykNmAUIjlqx2M3oKGcg7Y5m7u/ClID0wtGhIdGYAXIMTqGK210x9I6HBwPiL3lERHyyiT7 WQQzp1wgGHWyZVZLUnzzWrgap7XRY5v+sUHyZpylhI94ybmXGk25uUvESxx5lIFmN64Gwq2usmlW puN+ct1WDwCZdrxGvihAhkri2MpGrDlLuWxj6Z17MLbwYMSpio2DgVZUOBqULTD/cNDP30kOAB+Q FWRbf6dz8ncDb726/HDEaN6NwjYuEUqj822GSiQVs8EAnQE3Bd5UOXm3iefHGTtByuztdaaJGayo cf66BuAroDbjDxThSV1R6MaN3mrfAHR5cFm4hChnaOLg78R40fcvb+LLopPaA2FtHopAutIAi1wC yBqiiLetMs1MiIsz9lJZha8rg1BN5otPmLaY12PSdT+CSMUcm5KqpYkuw7HGBg82wZgeCl7YKGGk dC87hOzBso1GAhiwRH2W4Ojg4JWC5VG55oFPkMeA54l4ja66hes4n9IW+KXoMkXVxyVpJVSAmslq lKNODiU69chX5FER1sQAwo9/7dBdkUbwXUaA6AsCPTIoLGFD/02rvOorZcYp+krulzGuvWQwSZbZ IAj4VgU4RN/3VFS1QJrSSYh7IVk26IjRfO5djEpOaZeNUaTEAFQB8wJKhLeljJ+Q2yBV0JcWCT2n sWsGV844u0idpiYLp+cTh+e0L1erlBPJuNoPSdAKL5HZ92Vl2w4dHThXL2bpTW0Rmd/hDN1Q+u6w K0JAQAW0Gw641mFc075hwkFVgXiJN3BafQiA0iW0feqSGb3gzzLLncu+Y6Ms4Q4JRGc65Puw4kRd fUTA5+GBUdFlxlqsVmDQQ0AJh9Qu5dFNNh7DS1DqAwJGFBPFOuIDw2QQVGPFUdJzQMldRnZgDCZa 1IFOruFtUuhSoV3yOCfOsRDv9m1UgcC1DKt+NEGtpE9m7wSsqeWq6NKk4h6eFVaWHGVsTeYAC3x6 ufYyrYchJfFtXAv3csNMr9AOXguAhL0CZbzuOuKBE1Fgex67WxeuICpBzuG5JTaE31YM/wqD6rJH DhEpAI3uGzjVADdMKhUtWN228+VyEyJokpTGKnmoyrtNMGRU9li76fsMTmP7u5ScvEAyUVLx1kJH VVF6Bsy/TRFesnpz8+X5ohC9pR03xjAkHjOi1ojUprUtjA8oyJwKakwHNW30Fb9GwbgcyglFcnS6 SjZVeBWdALrNjJCv/ibUiMawqwZYje53KSdDZ4FoVGTAYFiKM0fpxL7UXHAqrGRCSz5zab4c8Ogl TWYzyPL6eNymelIa60dcpU147vPR8wwSnUQbDAMsJtRV9nt50pfaDnQ0WQHzJzfoefp1PadXEl5m /lUhFc3aE91zao59B5cEYc43EeebupE76KgheZy+BXqSf4i0Jd8A6UzpRVWMQZF59/Z0uZq03VCT GhV0wvPUKNRHyDMs5rZA9ZLaKiKP1AWUSxGL6VEZL0HlSD9wvNNtIUDjVDsDhlwz0koYHmwmiZLL aKb1Rp3AzXzPW5/ePj/a2j7Y6yU13C+wDu+mOUkeLvzoVOcDF+YKtLv6NPkRlet8mJzdgab8qffs L9LIX2lTu9DADtJAjBMS08DpZe8ZcJq5Ow6/wUbDU6wTJ5u/fVWs1enVGplC/g5/n6dXV9mI/qbA XPv7d8mLnD3E5in41k1887f6gPvqO8pMHK29e/uCHAz8Rm+lBw+v/KUHe9H76wrGnmRrfA+Adv6X nthdseuk99fe6mrSW6WAE/tk1LT7A9tH50VAwAlFkPSW0/FORMewZP4apNqWYswhDlBxiZfkcjal BlJF+uE7iTKUAwnDUJSzyewMtnaRVYQktrH3xJHYT3foss0+1ck54jWiUeeNGtjW1pxfQugK3mS6 SoKitKeXRgizk8GjhdzKFQLzR9MgeFAGMIs7zvvfZwtTKVIc1RGkRGHF5LhgfEVbx+Y2U6CO5ATo iGCcEI4AI/2d25qyeU1TYrBz4oKLSPRfeaWcL2//cmVXnYzyisTYofpCWOZgqf2SwINUIukmiexE tgb3IqJTzcobVLfZ0uNwJlMM76QihpcyUTyKFckZqgO0gmxhKx68yNOCCrn2YiUhlI14gpTnglRM n15QabhljTw5N5+XRSMTPKFzHHmC435oOHJ3zJlbPBLUkSSRucsmqDWk4wXxT74d5jqVcfDkVthp OBYs937jxr44TZzaifA0bDtmDTy0RpMg9UzyMdWTDntNEVt4xtsbFbCeSl3/RBpTLtSI+MleP1pA CSqkeoXrIlPBlM5HQbFM+XS2JHRFF2PLqlmqxhjwX+aSQ2FcLBujk6ilyqUY7r3y6xbEYiMJJc9Z eFEDooay1EAEBYazyjzWjZ4cRS0IU7CDM1IHE5eTOCQ9yLis1yiKbg2/WXMR+8lfeqdJOkHtA4ml 99fVZMV95YJR5Kcu1/hm5NbKHJxyCNwowVPiyQmqDMbqsjFxqs0WHdoZgya5aDCvpHqOafEup7bG GRNw0+8frgb9L2Ox+beolcaLHOPHLwTrxy2hxxyUdonMm6CJiVaWXEI34zTHy5O8PVSiLZ9+8DVn ZPm8SJSqiclXqiFmtwIjXUHB/KE7L2v0l5YJ/HV11QrMC4h4i0m4gX9phNf7MMUY47I27ZizSZTi 3Iv+BwpVIDW5L3iuVh+Sy4avOu9tCF2uVmpxTNGhIoYE50LzIkDO2H9jRn6RXeWCZu8GE1x56h8a 34VDDGw25gWkAMKudE1OUYZtebQvlVrg/C1nyNYj5wqnBnK6NS1aY3UYdiKEoCJGcAk5y1OG5lYx 6KIGOYErn+tTOrnIA8R71uFvKCprNvUbgthtej8pxI4DSWTxrS2YNBidb11baAhBLQZXNRrFIldr FygJeimQ9i6dNF/hiD6qgzrS8m3evCfaoG13Dm03Lze7iTGNqcU1nU6NXcEUwRJOpVTTiaSs+5EA lFDic44XAau2OKU8kLRtEsLgycTctQ46j0Pu3a0F9y7TLevSrvno3iXTyLqObPPzC9VoU1t6qyNr X/DcJrH2Tlc/cfr3671D0A3TD/b6r+oSkS311k+SuFfokXuFE1ZMsDF4S6+L6O0OMsNWKOxFsdSL ZsvBHMbbwiiSixZyYLiXF9QYDMvT/pJWNvuJHwNJIxdZQ0gIsOx7HcWxxoZgS4096bkiI3irqSik A7HykMfXYzEIOElv0SjYG8tg+TwOCcaDe5c4fzg+Eo5q7llekpH615Jg8F24Qhg9xEZub2Jw1UNV qaVqYY0rdi69wnWoSAqGCAzfgwmtCO+jHpmuHb8JYdQcK1hVEXMR9am5fk4bHUWsbeZWsW0aG76P aGUho08YoN3YfgqW/Mivx/Qltx7HT16T4hXAPBLRNxHrKIBF5h004fwxtoLInEbYbXBRFOOMkFP1 1oOH6K5kZ4YZP+2eTEHENL2121D1anSM4F/jj1JJMKkRP7AQFyGiBZIjQUHDizqyS0iNkwQdc2Ul mo15hSZm5cFmE459rLkt8CZZutxaZcG8juExSf97Be2HTIcOO18RLT9sMS5EB4a9bc4nMdPIU+hS ufrMyr2UKGqflmeR+JVIVqscZl/MzeKpcIzLrFJwvwXPbi1PfMapscG/YfJ/qTT2XEzOy0+XRQan RTKFgP2CAAEgN4Mv+xraJP46JlAlbn8sItIgDpuTv4UpYmnEx05gbXcz8809xfGKVdd0oqZA9FQG d0JcSoL2tluSko5mOx6NmasZDoeKU24gxgGxlHyR1bdZFl2+mpATaSmMMRkxurasqmV0sst00oAn VoMM9YSVQtFufeTs1sCeP+XLICOpYUM92ow3f99wM1LfDD3aTQN439+Ld2wTlmdJeaDMsvgF/IpC rt0xxQqd8nzB/lqNSWHrnlduiMQxFHc2VQhOIgaXvSFjduFmvaMUyGntiKsoPIWu1ob4TS/OmFLN hBhsVXAABCs4LgaCWr/jFIZ8wsl2qJ+XVKOMQnHLj7mTEiTPtOT8G0ocxa51GqMsHccT2HCLTnai N2V6NUnNqFlTmj9wVT5JxymztCqmJmtggQuSKC2ms9gF6VOIes9M7tlcl6R55rukZ94mF6X38C29 DHYja9/8xLcgaJdc0UGmHW+pGNaCJByLdZ14zNTghPtu5+2Da1kdWsikgjzbILgoMPAFqP8V2aIx 8mAZa9uN1NtgbcI6Oo3FaVmaOYV8XMVtX5VFHHlhtR27MGiJp9ds2Z0u/vA9JMYYQjwmRldKtffM V7yeS4r+EaBE/6rEj59T5PjzLiHjexEpNqpte8ufCexWyBaJQ9Eyxlp92AqLWq64PVRiNCtZCCUj AJx2DI+goJtDj+KL1b6pRWN9lAE4mUdjKvE3aYuuRqqh6wRfCc6ZVzI8wLj19cITV4ahiFdHJHSb 7xXOxSar141qGXTIaiSqgMdyqG4uIYvTcH3j0iCw2wPgwLlkUDc2kK1B7JSdSZUc3acwFkAWRCMN nya/NZ3pldR3v3uXThVE8zdydCUAu45Cbbi0MayVaB289Yu5Q1AL9TJeaw19ZlpAH7F3ewVlxF43 F7Rv9VrnF17qFJb0PWwHM/i6jH+nq4PeBrfH29olT2Uf+U4Mwh3zHQZTwc3qPfOfE80qbWFBc7uL nA6mtZhzt9b42dygNVbRflWld02O5MIzesgdxJTzJ/CjhXd7DjQMR0YBrNLMlnjlb1fkG7y9/RW+ mnyTmB/oJgmc6Hvos/slAmGW0M9+xK4paiy0i+ixx+JlzGUWprtz+S/vk7MACs7Wf+7Xl/NUbZlC NXePWwJoVU8wooHx9kggOTYQYN9HiRCUruaQSzDDxoyRlBOkHbL5GfLxRCdneAE9UkIvF8RxyRiO p9MakyLgpAnr/tbSQJg+4UoocjS8Vv7JJj7uXvg/Chy3adXlGD/BYxwDo8fHWMC9es+02qRw4fki BD74ekYhbvoyHYnN/8A/EVFJn8LP8NhKT+DCesi25PU/pWOUNRRSDAWP1ygl0OkNH/su2fztKL9i hyI9hH2fUOZnj3OK15hLJ3j8MlfLNtkZbCFZuYOyXKx50lLtE5mObGpUk1Pj+PMyKN9Tmco0TrKR Epx80yiaCQXZkTbJZRunzs2EL1WZb9EOyBR3k9BlHVYki7toNx8B7GufafUdi+uweGFchNi8/mwZ TqwDitHYnAzvyEHypPje4wddcIh7CGtNUPVDCmmQ+DAs65NXpOvqGwGhyUsSR+aOnGvdJ5SZlC0X 842waaaOMRYevKk1D8bfG8LT5BJx0WHtA9HCoDDyGwoipMqlHRbahcq5ZRa2IyOndeacWj5a/EPf IPRpKU43KnP3oXSo64PB4JMcxIgSJTkkmBACWfZKit2m2gR6ceQ9T2WuL2+hJLm2UbO2yxrsmttK GEjP9BDEWfuS9YL+xBuJvJfuiHF6gwl4YrqioiSUTGZqpAXqQd9VBHEQzXxZAZ9Oxy140YpFxWwI rQ9upG7sCq0ixQWvSCWUo7j1/93eWtvssix7NjpDeh0WM4zS1+LLpMHDPUdZpA500xVaNqMnSYmi F1ITR8YMQ1dUnzW1S5PZ1KWpkv+cY9aJ6DR+nSUGLkrndeMoXNfXA7oQaYDQQzX5Nagd692HEcbH MMs/Lg9+fGIy70Qp0+XLPt2Ildym7IioOS6ozM6ZxqVAnxrIYdj6bV5dsyfjOoUvKo8JJqXLoKs1 6KtvXiIhk3fMpFlOI0sNpuO5ZGsX/kSd+pJoPlShCqrxOC+kTneEg5Dt9NqO5vegac5l56YM+FDf DTiPZVxcVaq3owh+M7I2aBrGKAc2VeVWmuOu4MpzQT22kYq8U1k9HPQZNyVVjPQ7iVy7yBSgLgRG 6rLdLu2QlouDLtPRx1xcRzeY6Yv1pknqmnJYh9H5bIU+zk1m3oeVEisZIwp3F06sxQw9XWxXwJZx 43WJlH1SXDrnlvE2tNXaBh05A+Y/m04l/ow4+kVZ3FaiC2G0KDbCLMw4AdsydKbAE7joHAkCUoF3 +jEvi+mEU34pFtAHT8sIUMrlQfTt13I1oCeRS0IWl5fUBtLYbVriC3EB47DVcf4hI/2fr5gPUvOr BIZNSMZ3STWhqpoBe1VwOTHKSHMjNHfrsaT1wOg+GBxIWsMPhEBAJ5MLRmpqWJqMiuGMZj9Jp+kV 1Twitsgly+0g/QjRJVLDbYDfU11SHaAuOZwkbGRWeZ31ZpzyPgKZXRV8/VyujUEx7ELLLlFVKcgH 7Zgy9H+bVWFOl/IduvKZz42CNXJwe8TnrIn8V1ydB+HqIJRzA8XZFDBLSG+piBECSak2z6g682iA gAWticS7o412rRzOIbEUVWZtDzY+6tHzcFzk1xx1FOERcWXmAwOdnR+evzv7L9DI8bmtxKvky41I 2G60RLFVKMLLYtBRoJl84sVriSpgB0BsMYpNyGRjJTVB6tOSPS6rndLmUiWvpbb9XVa7hxCOZCAg OXZkIhGQXVRuSPInqmxiOxfPFpfn+wQSSq3BiZFdWAVhzBtMECmAbmOcE0qGlCnAoxogt76a5aOU QLwMBAmpVQ71FJmek11daZJkxQ6JL6G0vMjrMi3vmHmvcjp1oWXdzZRk5g6noLGBuk0Dq584wMKM 7DlA7OnYbygXUrFL4Rie24jF7FcoyznwRbzFu8XC29DKpnwZwPnJCwJg0+WVCRNBZKS60EsqKzcK hYfoKRikR+mgCCNSRZIE3i6OyzMVTqdi/rgl4/5tmpO2o3erLmJyHvl1NSbGKX4L9iK0r4Yes2LR qSFyJzAL15rOKASYXMhKiEXMh1ISVrK1sd97FsN/d2ImcRw8NrJiWwlXwMOB8JeUyGtsFEF1YnUq wXGpjK1qc9PDVpn0w9VO67FN6zE3fVrWY2cL1g3+J3k3ldUn1nFC8SWd1mU7WhdsbKWttXB9FHTX qj4+MMIDLxPB3Nkgfj60EgGzwmFwJAXvbO5Cxx4t6SWGaiWocTc4PbCEGwxSKDFqZtXp9izlYTba nO4Qx7koQcGkCMVZ1ZZgH/saGt0RE0QlbjZVa5Kslpt1ihc0k0lVlxJEHusDHKVLmAXel0RwSljf WVTH//3yhXU8h+jWmJS6JhrfSj7IQOei6Q+1AJVMdpUYN/PUCVpK+Ffse5oVUsE9GOpyXzYWRCcS nZvd7Uh0G0l0O+Eaop2IcqdBlKYG6RwybMMOCWISivDqE4DrTjPdpZnODSJxM93BmbZAyHeadFxZ HVtaaTTVPn/hyDK7GO7b2wWiWK0ILUJqBCepywYQJseuFwlQT32aDBtX+W+GEJpXv5hABqdiPXzz 9vWbN4fnRz/pgAVC5ppSpOEGzKf5ZDbp61hrU8BXGhI3DCEJeu/snCXrtsl7tMlzgzNkk3fxBoL/ gSu8ml2C0EV34lldlKBqdtrnuOw7NrbS1to8Ure7bCozd9tlf2l79lVBfy4QwCXP8wmacj1lQlUx RjonGRvKEeFXHAHC0IjlsgMk05xW9IgVKEEOnOXOybWKN6hWQGaTdiFu02YJbVLLU0nKqsNSyKY6 OU6Oo31mwAXHgiDjCf/ijnKCEXijJt2B7rXUpOP8qkp/liqNCmOsLlohzAUbLNGeY9VQEQ1bpDqn OdDdSYgMWh1GIoMocoVNmfQthXBqiG4Q5pZiTOgVbKkpp41Qx2OxmvuyHq5MpHk1I2I1r1byrhsj 64XmPQR87ifb+D87+D/IQnepciT5owJTAUOhigFfoqkMu8inHwuBjkhA+m9vQzQ2Pi1yDJFaRy5n jNeyUU7812PxOccClZ9Y9cElPhESO3ZR7dWSg2HVnFO1L2ii7Li45TuVdWq0VCJFUga+PnWVf/Qa qZI4SfCjDGYr0XPeK8FqzRxUiZOjNZiGM0SJoQw3/2VafpjdJC/S6dUMy6mswHOrCZZbevYXeU3Q YM4l3PlPaGyQ4IC+AOnJTdU3zsPLWVlLulFd5pK+6f0qBKfA5MfaiaJOBkeap/fDq+cqViP4HTcs zhlq23oW6Bp6c3R8eH6ozawuN6FR5uRmM23SPX3y4uTlyavz//KFAHvP/GdLJB1kj63BoioeaBD5 9gKb/e9ZUQO5jsZIRt+O6mev4Nmn367Dp29HI9M/fDWyzxDIvn8Qa2DZR96w3988YKA4XHkiHxbE 78L/jmFmdmRBsg6m4vxPWafErM2Kq33WT7SMWj+hCpp9dpz+vq9m/t/32QYmKS+/X01sXab5qQy0 pLKFyzdxxEDQ9J+WrVuQ0sDtL9i87a6bR51/7r6dx1GUgXnLvkqn1r/Yjmf9gH3mNVz5Dz5x0XYt 2a8t2a+5xibdL0cPvWfu4wP2bWvBvu103Tc3gMfYO4vrESUfpRLMnlByNZzOG06uxteQrXuJhnLx xbwl1SBMuxgq58UZhkoVWPda0zj4mAqHxchWagX1fIryx/g8tmf6JD8PQLY32Fl9CIfwO7mC8/nd /WhnW2hnrmFOaafWKDx1JN6fbrYX0M1uV7qR7h+DanQm7SSz4NS7yJlvjptAchTQeO9d1LHM4wAL 71xmAEuPv4807T0zUaf3vXMXHf+9rtvo+//cnTz1uJXka/ebafHubJytk8H0ARIHXUU2knzM+oQp DRQQSzo85/I+YK9N2ycv35z/uXFg5+80H9elhxUZQe8Zsbf77u6iQ7rfdXex50feVzW+a1CISLa0 tcBXF13SGBYdRt1uI6jALxHj/gBqoF1yx747KewQKcy1Vrs7H1Q5uO4RQeq+pLCzgBSedL7noedH JgV3UlMGeIKpoR0hSN4LS2OMwtwcMoLgewHVWPEglC508ZToTHa/+NVMnw5tz3Qq6hR1KXgBBsbH zUdm4ALk4PHfiOasXTs/ng3h0ocHCO06/cBGITLecNT5yOi+iEruI47xrSrIWamLK8mFa4lQJqWC XvHgajgRHMjAVPZx6PGOBTkLUU62U+dYL4e8QVUdPmZmFczfGD+Zg/+NUzw40uouuSnyac2wC2Fm yKjgGjmf8qp+kJiFI1mB8f6uj6ONxaxFUtaOaFRNZMimRlWBhKWLcR/pamehNnXQWZuqPluyOrUJ NPHJ4zOwmFc/RHuq5ktOi3dmS3ZmqfAEO997huR6/51ZIDBtbXTdGej6cXdGHYyOMT36ruBqPUie 3aVNmeuetOosZjLcsTpLH+99ye0u2JzN+yiz1P3nG5BQn/DcnRghF/tlyz0HjAbZhVaSfagCyWvX ZmFqHqf5+7ZH+zbX42j3DeNHeNvw0713bW/BrnW2+2nvj2WBcDOJ5QTRKps5/FLfJrjMBY3AhSfZ wH1QPSS9/6EbTWNstySyCfE++71P+z03DdfuN/XGG86gR/fd8f0FO97ZWOi6/9wtP2tAB6SufmpQ qp6zCzTVqbpOS4GhfegG8uqt+B7+Lq3eQyDZF4Fkf7lA4vrpPfNd3vcK3F8knGx1Nhm6ATze7jX2 6gG74hto1+YX7cOW7MNy8YP2GCQQpqD778AiIaSz8Y17f8TltyfiIRIGv9227gsZ1xNa9rmJx4G9 /E75FjHo+7KtJwuWvbOxTHt/vIUnSxnjJro8IM0WPKy9H7KW+Jcm6LF4SNlszncW3SLYMqM5fA6X o0GtUDv34GtPhK89Wc7XBI+GR3rf0/RkIT/rbCWjzh/zMH3euvPb9z5LB7TkcaXmxoKbWJLeM/PH vU/UwYKl72yVMgP43A04UrOTrSDAUSUTjDi+yqpuZiZ9beQf0JzfuriR+sLe9CSeJLI+pVo3WLtU CE01JWHOJFWfhL9BG5+VmQlBNAH3Wj3e12f+mObjlMs02sAishlxHhk2YUq6C+/QntGGBGOc2ZwH M8MqjC82WP++tvQDaNkS2Iq29Lt+2xrfxzd+IAxmQfFwpXftqfcsCDK6D5s5WMhmOtt0SheC9nmE /lMxHpmQsWg3HallhLpCNwrFkDmoE1vpeJ1wgis1feZdzsihxZAnw+ISWPDUZ6JgPT+H8NoI+RL8 9DSJ+ZILCUskD0pQMVS7m2aUVFDeeSQF0NM+ZNmNTR4ZFlxOQJQANwLMigXCh4Gj9w9O30lVabqO hNNL6kuFup9DLsSDzIfO93lVFrMbb7yllFR7iDAUFNeMrbSYhFdy/U1XgnBa2NnhVLGUImWBYif4 4SKtOBqXVp8tvQ85nW4FyGPdT1bov7/tS+ze6t9XkC7wj9+trvbtmi04t8sOrj+6yw+vdt97pp8e dHgXHN/tzoY/HcHnHt8fkUIqQyJ0+LgeLVO8i45jiG1ynjRc4/EZ1CPS6YoLVjMw6Wt8KEqTNC5J FHF+vumIfms5nIJ3EoW/tTVCPZHwSpUmavHDVHxtKScKq3O54pXOZREulsDEPeQYuNUgclfq73RJ LSX2LUfsy1VLEcrmymPLCX2Bcrnd2Yj6OOJYdEtR7DO3TJnsC4zc5ilYpm/sn3NrjP1LPMYq18w3 rS+iDaWMpXTRQoZemLFC6v0pZhG9dDbftgzl0WT51AnS1uyO6CHj9M5VQ3EZFVjo2jhuAwnbi9cd WGRetXt7TbplUs1yB/t0IdWDSOTWUjs4qs+5lu3ePsh/QwgD+J9lJEYm594zRv25d+zvxgIq6mwS pr4/l27etO0Tl93kuyifDvMbUIE4Pz2hqDNypntdfcnV6ddoCXFo1hU2T6XsuVjDKMfMybEEGQyl 2rMf2YqW88V0knF2cw23LTahwFVlcjLBvDSslUgGbWwbDsQQVUsl/JbmRALHirAkf18Xk+yGksFu rwuclcZKP4RieVEOX/35PsQp4c2dhEAWAO2ydyPNRZJfZ3s3dv1oHM3INwReo8wi8hx2EOBiF5cY H/KhU+VLhb40neoVahRBKjoLikoUG6KSaZvwxq3MmYzNEaQK04mrWOi6sKEu0h2RJfUYyrL3luWa hLiQDiVse+k9rOFBFxkqgTA7JkrzVXl/Al10A3d2B8TDuAexLjFmimZqNxqRY0C1H40J/LgNW7sz Bc9bOpN2A51HBLy8f28+C08IsdEIStvmiFIiXx3Bp1DFqxsObsKDOqxZH3MHSZDWNFPQBZHRGElb 1xl6S59R5xwALp7A99lFV7hmsyqta/jQwxO0t1IgaOjfyZKSjvOP93EC+BykDmlIroPeM/ex5TAt iWxfmIe03dnN40bweD6BwKLj6h0WN1gGY31SfBSMSew0JPflh+n0UqtrQgMEJEzIEkLiktPskmrc 3ESNnjrte2QPmZbI6NGeeHCcOzp+XNQNW1ih8g+ryvVbge4dCDsVQsUTuurys7ENwZj/bQ8HjmmC U7dCrbQgJjnoK7+aYhgVT4XrFtES2plIznqEU+0mSI/7ND4zgTCH3G1eUD0uHKOMjwydoKgISAKB 9mr9ZpM3uxwAHhvyhcHvheUeLJy9vYPq9vgkbQxadQwgdrUw1Qo26ptE1BHZvGE6dThU8PsDWI8f sGo6wHZa82iWMR29zpcr1sjcQOlBFvcAVrPo5u7sesTOHyPsKZ6EQ10JgJrYoFgLrCYuzIzAbhHI 5vKSaKcgrmQPEEFzEaGiLq0PpO6ywGacA8DjQXiQWHy1m0ygd6jeP6o6NWswyDCQdVIp8+DEl3ys /Ci4vsY0GcITaNwc5uVwNkFEoSEWPlIViZDTUl0sYnKVkcyxEVSyHGDJjVqVtIHn52+o7iPhbQpE SlFxYjI7Cv2gTcA5ddOo1WVlaIJVTaeMr8zA7+ES0Lige8FCTce36V0lOTICZCJgHZE05cA+cLDE zKmtPkOMk5iT2pvBMyKeTgde1KBNYLe4n+u4md419SDTLbV9b1f5pmTbLc3fURpnCFsv7/Pf95f2 FyT1bHf2mYeDeERTm6lClI4VDS+8StVx1llVbQjhlNNl1FNxTjvLCXfgMe8nxUgjM5u3elDWO+yK HHNVkH3xOSKx7PgKF7zCYL+sXv3dPaThbZWGt7v4rLETNPJSZ/e+nLYXysH3cFhj959LYC8U+Z6k l9C94yuIcYm4+5hB3vLi2IsurWM6CYph4/e46B5V2pcvY1H9zlfidvjt/qbjHrQUuMti0UoNGMOI qGvCIiPsh4qRTtosKtb+0dxyJ6oi178jRGkuhcQS6xzHmVlZlNj1RD3MHE1DIufYvZKat1UW2+7g /MpAFEMkmwcQ+wJJbKd7Xkf22YJYK6XfaSYWbwpO0cFr3sPgFy1N7Kwd37XTljhlPS6QBvmo9tI0 JDIxCnW1dmuj5XHBfXmMmA7hvJDIUvIEYvywudX8BlJ6y8qY6bgEUeSOz5xA8GPoiguRKrObMWwY nGaH/lKnV1eCQ2uN82L30da/1kZW5Ifep8n46Rga6aG0VeYgAmcK5S8+nlV3LKGJCqsjTdGoT4hn KH8VWqbSdtTXlER9t5pdVDhrerfMsBjIR3IpMVAM4tk9P311/JBTi+vdemQXS0aczbq5NJ0VW77M pyOWifDT/f1GC/Jadzp7q7X7x7PVRFeIMlNBrpd7SrfGy6941G6LRDB7/ZEj4nfXUKB/69j7TN9j FwiCH3BJ+BzQ1xpwKOfTrXpuwilYJGee4NgPXRBUWOEzIoVcdys6zL+7QcrH+5gGNRNzs0MqpnTY e6Y93xvwYmFO5k53eCLu/7ON68iQzVysJGBr1Yg9K9xHz2obMrAy2pBeH4R1JIO7bxrFpqZxbnbI 41TqYQZCdPSAjV109Xd2PesAHmVn7WwWbK1c2Wq3jXa5ZWvzmBM99BjT4FpV5l+h9j4Dag9NCrE9 AcXAN+4mWYKwZwGzEeo21Jb6XtqK0QpQpx5XBv7Ie/vt81aMC9EnnRQ1iKD9sIl7ovsF0H5sUf9X oftF0H44mIeg+3loP71eH4DuF0D7OafHQ9H92JawwJCA0snJ2/M//xdlqcI7bL6yfylhdsGQXmhP 2OkcR2G7/1xx7S3hh0qCdi46yCh1wMGiYSCmb5ip2+rTwBfXqBnGpzm8QYzn/FOy1Uk5C9bVnUtv ZjAxF+lC46nKe0KfeQARi+Or6nRyYxzJk4LLMTXKPpuJWyQ0eZ7qPo+o/jTHFsGoqGL1g5DPgunP h3+YT81bRM1zRQZHzRL3x2KD+eN+tLxIZugccmF6f7SgNR6PM4q6vZQ4cB9w6KJ6DJ52HHG4zNVi Vu8RKTa4mAztmlBGcqNcLp/h4undi0DtZB9Cn3S3z0f7cvR5ldVyP4zlhuo9a353P2pd4DLY6RzR 0BzEo7kNyIfMba+5e1mKvDqlmfDPfzyh8jta9o0LIml53E5E27KWjtjUpGIplx1m7U5zpjke4eJZ qNsDxr/oDtEhrdXpFTz9TfB3WNrbFXIBzXRbzsO/QTx7y/I+5LTs0GmZa0FqOy3Z9AoBbONv7ndS FpmTOjvk4yH8MueEZ3f/U9KNtzeW8Zc4JMEUcnHb+YS6dNlxkRGuyRC/SYIKR3Awdv79TgUP9SFn YpfOxFwkpZYzwXgH4d/3Ow8LEJV2OjubwwH8IqeBEFx/mbOAAWXhCi45CvMlnflHwY4/nwY1F7oc hAmWo1qjwWFR+pZrYnuw/293FhgY4gEnYY9OwlxsKnsSMrg56Qjgh/vR/gJcqp3O/m/p+VGJ/uQc pjKP2JXSyZT7MMZPS/WIRH5Su/EuIuKMqpqw6DOHhjf/XYBedZUeQr37RL1zkbYs9Y7TqqbglRzx gqIv7kfNCzC3djs7uKMRPCpVv4CG117q3Bbxcq1V/kCW/qqoMx/ogfNZc0tK5oeg0IPWnYaFQqDn ZHgNci2DouIxwBRqVUXJ+hHrpX2tgqX4Avn4TqqPS1sm3cWJPvg3HmbnFnxeSHKiFuzWl11ECB1W jBr08ZMtc5MQQnqXLZwxVT3iwW/d0gdcb3hu12j48xjD9r8NBHS8nA/hEE+IQ8yFtHIcAgekaXsC nOn+vB93WABttXsv5EzX/+fyBl9+heznVDpF0DOD89npUgtXxlG40ir70CR/AlMZr1NGTBDIv1ti FhbTEeGQU3GoKNw/PSDVPulLZhsTSSYWT4A87eqC2qhdX6JCYm58/VKQQi/LjHgD8r3rAiN04TQW jA9SSLJSEKESVK+TEBaf1YkxaOTRpwhfU+FPsMTIfVYxSklUhJF8MmmdPhQRzG/Fiq+Js/rbrs7/ bQEH224BBzthBpmsJW85FMYBcM85HOIfpnFC9/j/EkQUTkKDNZJ1F3q6HtQ4/6mo6qfJ7e3t4LIo BhcpbVuo6j5NPsE/+z3K/U9dzbdvkDGXVVZ/15vVl2tPer/R5fs91n77iFFCxfS7Hjqrkmw6LNgz ys8mv6flkxeOn7pwC3h1Wj09/u5rPHNf60P2MZo4/RWs0rp+v+4f0/bXfQd21xorqXBFdil11ZK4 WPJ9Vmbe4n7GilnEoMWLpheY/978iDcQ/nBd1zdP19cNRRjSkTXUZxuNKJ5I9GPLxsW/mkeC3Zz7 rHnBn8bFT0d9IOfzNETYc5Z27COd2yRsVN+oA+aMG3bPdWqZSjPh0xvShPui0+uUo45P/yGdZsnZ BDixtON+6dSOXAL4/CkXmsqkHfNL9+XHG6PDG+a1Frqjf1wryTX69PLJ5ijbSkdr+5fbo7V082Jr bedye7i2sZFuDA8204PR/l7XXtvJfcHTHecmT3egXdPuwmPRwvPin4+fMqPA3w0/20he/1He9r// prXl8HTLDzFjka8NZ4q47YIbEkS6bVeGlGJbRU6/Tg2ojke89YiTKKvkIKJwUiHZZaUempNfupQt 3iY8ye35eJJOkLXFewiXxpfyuZcYuwBPcvc+WDSu+8eNCG1gydwjeLu9vlGbjrbM12qz5FzgMyUG PBBoxo/r8FX3AkjbDC2zvQBaxtEHd9F7JgR8v7CTBdAyu53j+5rKxkPTLBv1a1xiMZUlyYP6OOIS Mfp1UBlnNr1haELYep8pTeIutPV1ldwrPaDRANVIWaWwwbubHOsBc8A+FmHy8SPADW5mxgwA8/KQ a2OpYSME6tSeMguapXYwnLGYhiu0MqrqVTsmLV6cV24oHJElo5m/JNaig2eG9RzK3HmPsS8OcZIH I2O3g+G0AckdD2GUQYsDikSFKrkpxvkQZ0LtCN7ig8LvebgrOI77aEdA8RLbtbFAPzpMGqeJdSEz lAeqHU567uGJ6Mmfz7/rhSLxsChvBsCj1mEEWPpnvRfL2TzCVgEZF2Xe5fwcR/G3y3yc0XV5xq3g VRr9MudmL4dGflfZHV68KtOJ3u78THsDQLMtDcAr62gMGAxV9qxiOU8FlObc7j3pF/kFVrH/95n1 OL/4Z8z7Zfohwz/+TSZuBtN54tpnQPyxTLpcBMTTD1fflq24TUg0zAECltg+eZUUXQB5mMVoriI0 TVExMUS+xaBe4p3hA2S/lowW4KG3BVvbgJn3be2wPmUgWLs6xhVUw+tsQiE0xv7LGB7FcMaQHoor 6i6ICF7HtzGHD90IH0pWzsR2L6eI21bSIiQNkq+kqgv1R9dXjkvLOTsmkNmVUKOZwL0BkjVIaeIY IMBiBBIYSVgzDcgk/0xH/Hx+NeUrKpvgHTSr0DIn9i12DgjGkMdmDq4v3aBDuMmm1whcMNIp4JX4 Yco4SR7rrnUoeHMKYqFE17EoAvcfKQzUxIjRR9LxHBQ9Hcq5pchRNikwE9fjsSD2wW1GqEcYJD2h 0O0+R1PjxDVqOkiP1LlhE+ojuigzQesbow+CZ111U2I25TJdHiktiAXZCK93kFbtn/cUWhcES+92 DpYOBvDZsqsvkBjYy9W4mgzTm/QiH+ecNK1d43LJ+btntmqweo7zKPC3YvGIBR+7iQYFJ/rC1mzk ajtIwqZahpYUZJkQWwnSvaUSkKIaNCEDQmdiOqxn6ZhVL4nxT+XEVtn4Y8bJsyXWjGWXJg9EvkRx 3WOHeKwxC2WgW2CPFU2Wz7Gmkc+A7Mv8Z1dcABjFgyTQYA9WXHWxe0mjmyqNNsG651rr5x2de1vr v1xzPcvOi831wTL9aq6ft2hfiLk+2M0u5np3Hv8NLOuP5gcwD3eY2yMuBBeg+tJWQZWFZbTzpdi0 f00h/awUUgycj8PmTwXehgQhzIp54+uZoFgNcg6wzSWppTsmtXQpjKBoKhigMJuiXjENkhwFwQIt 1Zg3ShVdymxKHH+GK4kIZvBlZiuvpNSlQsKhxAUqB91B2HTKKagwoglKeJp8wBL+wkltRT4Szd3k hFgpCaExWX48fZTfRI/oo3gpNvcYsoWNky2rUCVnP71+9+IYVRZerxE8NobWne7jsUVYdZVEWMz5 RBPqbV51mWDsBHITdBEgOMk7jvSoSYImwLYIaskDXIqA6syu+gVtfUlJla0T7jDWHaUwp0C68jmL Ry4qqGqKNDaljWssKTRV9ZBVAxJFgqLrHH5KAL59BluXWDvSI9FATNgZAoZKOL+cefvuvMPEdmVi ZzlWM8JRSR2CGsPRmHVT2yJBUWCPL9GFX/X5CJgdoAWX8EdzOERbkcLu2NdNWsKw4GAxbYVdCqj8 4p6nTA9M8NiI7Ru78NWJOIV5eatW+/6V3T+M3WNOSJwRgvt0JJwZaO0Ie1qKHLBr2fu8TB4k2eF1 UcA5IwgbtOENuXk8C0PX6YCbEaUUX1N/u2rmOjrzulHrL+7YnpUNZ8SPXr85P3396izWv5ku8Zz6 eh2oAfQk1pRPrhgDHebF4sO6a64EPqyBlVErpGVotiJMgWLqbgcnNCmqJ/EOHNyEfGfp/Huz7+8S Ae/5ZDCUQ2cuHevHDnXtsCx6kRw1tw+tHMiPbZCzoFLl6XgAtBDn6bL9FN5OtszUJhQYjRfvhTSe bPqfvyEg2fzS2BftykTjUesv1hQo+5a8NFVYOugnW4yeBAu/YweDR1pxTfnZbf8zQfTBQKdqAaIw CfXelnJHk0NRCm+EFQvSqjHwqIXlIA67ZFrZbdhVjnhiS8yMuw6SQY9rtN4R1PUkyxhPqId/9kJM 65wiD/hyGjqbW3B2lpKYdVcczR1MpYIGnuc+ltWkEzabcDiuQIHDzeHrfOGhM5m447G5ruTsKotR tF+5mxat/RatfQw5wAPfWrr2Wy1rv7V87XWTgsUXgdoi5poC9f0Wk5qHkxOhrj1Eml89zyfZ2mv2 8XOKgiym+ixewMuEAnGO4VrOXCo5P35+eAW3zFAEYTz38TRM17ZN13OjlM5SIttqEFnbqnchsgqp TBkHTs14eR5Gbb+KQg8XhTApME4JPMXBsQsAxvszm8uPCoK/YzyhZXLRnjmlpyp9pOMJMre8pfXW 4BAmL1ZWHaDj6cn58+ToGiTzIeIkn8H5fsORI+HVvrW/7652eueNxpeEb7N3ToEHKrne4W1BM1L/ bzA0Lhs6A515DZExGTcDoY4q1U8uQSMfqTQvBO5wOn3mETVUlJwWxRi2ruyaS+LKp7Zoq1G4BrS4 FwV7D4dppWBV0dBUb0OnIVqHUWVWM4YGBknuBpZxy4e5lNaqnO1j6NYM0S0F3JPlSLE3O4RNYbGC tkZ6FKv/RYniZDoK1XkZUcAsyL/rEKvenT9fe2K2l/52m0t/oZxC+pl37wjOFSz36dnrZHNjbwdI /S/0NG2tG7hqsu4xRq7GAjJYsvlmnE5ZMqdhs3ZbOT96SLLGF6t6NUnubNYnQ4fqlPpbSy5z3xa5 aRRc3N7fc5PHIb3ELOYEX1fqhSdoitgOHR7gYaqB4xs9nXoAsirRZ1ocVV1mZuwqZA0VyzVY7eTl 6csTIolwz5dcLXvmYiGTFEqHNx6YZxwhynqH6R31WgXw0XQn6xvOo+mBw4LqrWEJVfxLbWNycE8P X6EIfoUgs2U2CsZSJSuY4RPszeb+nt+bc3xGEYVOw6WDkUQsB1+lTVtFfoC0uLd9EMyG+vTdwSNr 8IhncvzK082DJ08GQFUjC2cUAPpA54J1eOlarwYwDGmSj8cCQF5ayMBIRRJjoQRyJ2mUfhtyAUAW M6Zvqgt1qAIlJZqMPaSl5EEro+r7r1nUrkO2FY5XCe1yNh3KLcUedDk/xt09dPVqNIIFmRw82jZW gqOty2J6xZGbZLctoUdyURNnbBzoB5992vzcm7AlsJIPOZ1UQj9gWx50j9zqUupYOUuXBgcZXkY3 DbOETrysw/6q9ZLCK1jLw+u+ncNekvl7SgIhhk/B19lVUYKY8JQc/6nHZGfd3V00WipEal7Q1CT7 ue/fC7FDxa5gW/XVOF6hAeWqtTNs4rLAeBsFNQYNf0QVOC7JlNCX++0EiCGvrqUHvZ1h6u/ODs+O Tk+5obJt0ANvaYHD3TJhsS5gE3iVS/QRRhzJtPCBHJd0WIO0PEGbMKFnU/aIValJqiCaHRVisGCi 1ZPn7lJojm5PDE8IjmI1YNPQJAfOy9bpYnZ1LQH+fvH98AVzmYigceRo7PMXj2UCXhhB721dDA3B 6svC4nLOmaJOSw+AZzI6+S68bNd5FTykqElEtwkJBqwd70HGZj8cy7pVBWfKBhxmJRtcDfqmHKV3 q+TZbVauckScgLIFGO9UvsxVSOWlyUullrwOq/Fp5I5EokcD4V6QZ6QgFn/C0LqsDo9P38fnufAo svpBM8R7yVBqIe1otTBunVLf24RvcjcQkfL8fElW24SHswOuTdPiEEQJCEoRIVzdIOyliYau0ULs qUnxNBL/QwxLxo6e2sUgroS0pKuezpsTD+p9Rs6gCRyCkTOQBbusCxatQQRkTJNA0/FllhK9d6DO PQOCy8oIiA5A/HRP3mbC0lSo+oj8geUJZ8KtXIgLHkakHCqHlysmP0PXcvQJPoGBW9d00+hhbscr pGeFvHe2tpMVtJ1ko9VVSkPIJTCXSz6xbOiKFcgKwo9FicV/SyypN+LIS7h80TJM2Iu6P3TpuNrX ujGkk0SqK5oj7caE4aa+FSZ2aZ8tH/hiieYH1BS0M6FB7O7ryssj+HLAcTrs5H5gi6dxI3U4AVDM 5tQ2u8Uq7x4UDQ6NWykzPCPqt6rq7lUtUIE+7EmGgBl5NVHUTJIrJnlVuSSeMPfemA9/Nec8zJyD KDkxRs5ZNpyVeCTuZcLZNyYc8oErbEjuOBDdj6OsxhpnsKszDtQcwhHB815Jt0Q/E3NMNH69VUjW axfjpW/h0l5C6/tGezxURIfM9Y3jMVMOWNUK2m1nFUsZ+P5j+4ZWnTIcdPVgkX7Vx1bQDc3LhyYq 4ini3OmHC1Dm1Qc8ZHgbUI0ZKioETEeCXWGj5LiTjEXqCTJG+BXZu5zvGo7yFGj/6g45Ojw0mg2x E+Ab6Rj2DMsU5x/TodbBQBqQOx6dN8CE4JoSeJ3r9OcU8aPpikemrH55Lis6EPGoypSm2CtVUzlO BkVf7uLZJxfPfsPFcxjOC+jhiDnhEsfDfuD0OZ5lXkTKJjfXcMMywIoual+JW5mr0rXUAZy7vhKt XCNoEjJUxjySyGu8jKZZfVuUH9jSpg7dC0kQQEZ/VRp11cmQWGQReB9iIjEuOubt9VXI0T3VRUG3 RlMFdpY9lYmFr4eTWXpirb/qEJTIqrrF2JdK6JPjsrO01JKPqMYiOZNGMZ1mYxKIJb8a7oL/nvEl moqtUpZPxT9ePBULkCSDVQrq6qmVzA1KXI90gWLQBlcso0v1B9j0Ycte4hC8Szsr8XoD2bmq2KuL IgjNDvlJ262Yut773EfcgSv5qT5RDlY3T6FYpQWtOZigNiHyHC6lUtzUsXXxQsJCDwIi8Y3ZABoc QIUy6rx1gCM/4ilLAbb379+vHdpBirfHj0e4hx+SG4/GvHNKglCDe9JVXebdPFf7RfIivSMzvzDD lfMXZ6u2Bzi74+KO4+SY9yXD/OZazEQzzNwnsXUywwyFeIZOjjJiVJ9CdqKJMCHr0fXBFTfXd5Uk CPOcwhAqJfKqGBPQkb5Pq3kxy8dertYwr0zTNDqdwntZ1o7zK/QkRmtAIXZZ2/XpTZOH0+REoz6Q EvF0JE+1wUNmbiFndlfpgfhh+My1jwFW19R3QX8IW3nJccjCPypUs6m+gKobaR4YuoxLX2Zo6zIH TzOgsBouWUT4cIhKJq8E3Ko/Z3DpxyIfOep29zIwKZDkJuHV3HrcXUgniFxEqWQVhquXayQ2HmbS AsZwORszqdyitlgS7h0l9GTTtMyLqoO3fp+89fsNb/1xNs25RuMZUH2OKf5Lrk/rt/dvV/w22oNT xChLGedBK3mJJOGFHb1OB4Zqb8agSxJJwbwukEWM5raPR5499ZIoSYtZ3VV1NvnaY30sPz1bQQhs xtmIY+IkWIgO1TbxBHLXnLj05t05XUvA+TEGAe1taXlFhEHZtp261UN7WPEVTVo6UBWhkTglj+ZK rcMqjsfKJ3FQPCJyRvk4YTRfdOperbUvOTPQWftu8ptsTMYrF0hZWGOgYdbhIJSrmSc6DWQ3ZF6x oKUKhCvaY2wDdMs6KtHQUE8oiVa0x1PW7Zxs0zmJCxW4m6e+Lsls9/qi4m+WHhhblEgpXbxifdcc TswlbWnYShpq3prgp7LeJMOoKhOyQavhiUTzS6+wtgiQ6ChHt2x17aE1ssvLjGCDpsi49UKmhS1V EWCRNv/vmbLlMiOcCvofbWiUI3wekAhticbRqODmzMJKIRaO5V1FwWKXLRSAmx76VsgUGSQNBsMr +Cxg3e0aTvJtOvX3KLtmXLghHC4XnjbKqFSNAylkQRKuajqIutFCf7lfcZ5YJ6raIaqKMxPeyBKf sn50xAeHp4p2seXKjE1LIBSPanYxyTmKPUreTK2lDMVhUkL5eRTOKZRInbdsh73K6dKkPLBh3fAT 02mEjcJVk/TimavOxCmT/BhGzFJUgwTNp/JauA1pAldpgTV7KmmP7IaaMo0YiQOm6LYBoYzJlUNd 3qqL5xIWKRm0bUG0wuNJCgf+zrGLeJTSC7gEyBnI1HWRXUH70+yqAIHYyISOxqIE2Z+K24ykSXSo SKEAXop63kxkLBKIBhRSyyCltgxHZHIwzSijgw06yQRzfVmrkeMjYWXjHDeYvJLBKOdHvaHyZMya kappyIg0DenGhRnIuSwkR0JWsn3DSORms+5Ywuzzy0VP98P2QcAmN8etxp823+h0PHfpeMaR5IuO Z1CTbvEZtbHlLP3GSTKUJO0ghkQVTAjk1M5IHJ/K/9lGIXegQ4GoHbhQdFcS826x7sAHpCqQJCt0 a2eTifPbIH1VNxHpeH/W11VwsAgSFWMg4QEyK9FRyKsPHCyWjj6i7Y2CDMdkRCJvDNF3vHcf8zTw Mc2/EUZ4s2PJVxqfzIsIxN2dlYr66Oaus5ajYCLvMa/FxT/Nfe7rKvQgE1dK2U0sfFaQpvWWus7M MXVmc7xNgvVz+gqS91iQtyXxB1n6vNFoaEwnat8jao+DBd9mxm7k5J0RW8gYECR5kU8/LKV3GzPo 7CcgwWHkxBXiodRGCYoWmV1G7CW6yAjKm2iDbywtzFuhCkq3s3U6JMmfQZVjGaJPJITRKh69hTBZ LtMhHYc+sdmbonbGHI/ugI48ikjiwXgBi+Nz0YXuQLToDGYCUe6m2/dGGj5daDUtUKu5syKKmbfi OWhXI2eZxKdHBdLNlMG8cMko2pgLoLKVIHETJzMCznyOPdOdHw7iYzfWSOAP54/IJWZwPFcd4raR 5iNL2wggcpehpOAhc6hC6/YFiKCXOV8oWBgTLy08KAHNx0Ny0iPFQIxIuq35tpZ2IoHSF2ej+w7I CwhnVnF6m0NVYbu6GsLYtE7qNlIDrANdqJ52W9bOT9raJJl7emgKh0Xd7dSSR6hRN+E0cshQAeBP 5N0cJycYYtrlirI+ImxBzEXIzNyuipu8SnqZtp9J+72+iXIU6whxEqwuvBUh039+aVKHgSdRURrD 5kIVhflKNXh2vIoBl83QVIBVTY2yaugkJXWhDoILJaZiQLBBOnGKb+H4XSs51uTUQeMSRvogBP6d 05A0gYritGxF15Xj8+NVC4MusKPUicsdQdgiUtnmDEGThnQcOjnKBtUgLFt+1cT+mU6QiWFJSxBM 8hGfP4ot1pgrEzlnw3qiqGoTLJC2rxqHXvAmCbrLxd1jF7B1svejtss+ci52oWEisiSeAOF6oEBo 5MMoYAMpmoVh0ahlXZbaS6yb9KTxPhpKCc5+WnhzJByRCtVupAHkTxIwxobxCwT8Irods5CiBjae GYlbIxBahvTM9I7tc1iaQ9RKMuAF6gGHGLHkKWUo5xABNBkeEjgJNoArJfMEDYvrJtMBbtJtX+23 MMuqVg0rQSck0eQUVQTuiULbUCrIQBmDE16RmT/7BMNVa0VjL5Whh57YR/EEMxwtvKk+PAegRuly 6DJ05i/akeYyEtqU3mvshuKStXBaZ1O/+d1oyyfLixbhy2KDcqLh2iTU03g44gZuvmJyg+SRik5K LC9Dn0wYW+PgpkYurr51SpQRwcIWcpe8nilnCalLA9jKTIZyEew7mSUl+ZAkJzFoIlEiVF4LVfat UEhiBEriRSrc7M6n/+NEJFkkaNiK5spwU5+hO/fYL7n/n9D9H1dFeUvE6FVTujzQdsS5aMuv/ieN 8JCYlbvbfG+w07dZIW4L301zlK84fvAdWeNcoDwu/cq7d6fH1SobMV2RDwoqY4RYPGPAdUs02GnA HgYtUlPMtYYl7HlCqG0c6Y12bugNW47zLCgAHpvZ3Nzdf/LXvlMc0qQ3BdWi5+IMcQ97FFtS+YLk pycnJxiGAbOsJIVl5sB/rwu0pfGPcmGy26FSD6MYyqmVJxtbyZQC6FjOhhPyMc3HFO00pbA5bsmK EYOe2glify3GpbEjsZplZE7SkjCEmAYzGOeXGa4MB4+YaB22CNCN5JpRmeFmdgGPje88H8Sm3Ph1 ssv4x5PQlYJ2vtLHljDXjMUc6lFAwbVDCYLBPkXG16MTD+npbwSqa+GYCOR6NtbILHTX92iQ347z Z6cRPynQjY8UigZ2WNaJiErXaTkiNkyGEbg4p5iVIPma+Mfg23Vo7jemXVERbduBWgT7N8OQbZi+ C7zXbkgymk2nbMcNqKBTRyOM5p+glEsGeGKBxGwxbFNhP5BpzySVQjuTWCTu49v12fhZlyVWX9KZ 5xRckao1tQojgCqKnRxzGGbmjTWkSMKZosDn1MV+BMeWLF548J21hGPwocUWGlJtAU5w9hFJr3KG qeX0iO0YgoN3L+58b378Hmrb86xfAT4+PwwSL734yqNkrnuFQDbuOANngZdGRVAeU0UFleRL97cJ GyeJgH7w+UbBc3x+1pTkWzIhWBsLLKdsBh6IqslmTnoWTwKFQUiXZJVShkomJWCQhxVKPMqoUmml GQWcOlcQWXFxkynoj7NfxDBR37n8TxHCKVLcOy5taLqGRboJsrsWuht+UBnQQRDjbSXNkIE0RMQZ 6NRN1iDPhQ+UuyhppdGKBceUuYOkMIzQ+EO5aBwTbtK32FfCkMOsIKFrR7Ji00nRll/QnJ2z/Q1J wl5yH4a3YQsXZMJLadyYooqe2TjBwgxFTTN+rVVDEwDlouBlhmm2hAGxphFQ3Zw9bE/Xwo6waYTz /8iwti614wK1LSQ5RJ+kMYxGEoqFZdU+sQYFTcIzTWwpfIlWFLqhIocqQ/fstz037g7rvj1/3Ym+ /OLjqDnyyXVr04lRuqJtF3kVf49qBNkmFBxnFEnNHYasN+h5waSNJFpiEk8c84+LPWInZlNYR9aI rZDmiKmiIDDQoHGQnr+h9YKSQfjSkzIFnMjDOei9uBJSj9YH5f2Lu3aTT41qkKSamxxyjnhTCca+ U/2aJvDZ9yNWGIrrCyHqA8WAYKSjwQ5edEMeBDekJgghhQDLzDl1bVjcICw0Hfu3z4+SrY2tvThY cMukTaPATnk2wNLOEN+dosUFfBHD7d8KuSTbGiW4pfnuror9Buic6qIYBTUxUVUxnjQGlDBpC7lZ hoDvwdLnk4ptEOqQug9Qz0EUMkYd1+mHTMqfyLDK7AomrAIsGVQlsoaRuMmOxUkVdsN8nEIpYQha ifI6VUwmxmMCNU9DhvEN1G/FVOWsSOJq5IMrgEw+Qt2yK2drcaKRssNPtcQdixiNSidQBEJY0M3D tmEeJPEeGiLaQC1+lFN7v0mmkpRPAgqFJnggfVJQSfhIdYegv+zykoJXjQJFlhjfMdmLvP/Yx/Hg 5rC3dpiNZmi30DDbG7F8yvIix1YiXWMdUGGF3NfKzXSNgngNRgrB4M+jN2ubmwMECrsh5EiKbRKq QysUd8izc9YACngnRVwuqilXOAU2MSvR9acNyeKrsBU200+8AQoLXLGxNK1rLHDFzzLFFBdiEGFF a+z2FIeBqiOHseulKIYeXHE9S2UOilx5p9O5MNUfKHe+9FJYGyYMh0RfZDISZSzuJJ9RZG6KESgd zuN2fB7z6ce8JvHmjm9QqtxKfh0yPF+w8FjQvYXrM5VVl9iImzueVx9eEdCJUj4GclXfn1OzKHT1 8bp4fH0BADQZInSiWXkPQe6xmN8w8/ZPoUCgqTccOqHSMOd8GCz8wq/gCeMHfmTTOmUEF6XeufDV r9fuQ6/drY3es624bNvhED2k42x0xYL04ht3a2Ng8c/Cw+G9bWS1Q4mbvPjATsohReSBoobRQiRx ZbfKqW6JsUpGVnqDsXXwGEar4e0ite9Y0cOwUKDmyxkBM/qha3ARBa6gNqWO5TqQCm6yghIbbim2 D65QIXa0+nGUBOq0RDbotSB3O1AxB64XsxJdNR8Wn2taIXfPZiW0cAi3JIiaP6XAsEbw10cMjYG5 95M/5JPkcFKN8OcfsuEHeJa0IpRMD8fMa35IL6jYzlmKBwbzXUoM9r+Dn+lzhiFoP6BBB348ukaG Ab+fQ8v4JTRGJuUXGUz7OCUcLTjHiICAnR+x/ew6nfSTt7BV8ESeQXt/KAf8wHEKwk4/+WMmEvZx ekujQ7cj/AHN/AC8Dl7MMv62RlzqGWp2fXp5BH/xZF+wjfy5jvnoega31XNs431WjUFDfZ6NafBv C/iMNjOK/KCunqOeWfpVeV5mOf79Y1ZgjPlzOHnIC6cZD/vHrK7vYNxvrlF//glUwHSy9gMIO7h0 GcyZ7vyf0kk+rnE6ZzU63H/KaDWgSwyR+AkklTGsZk6bkX1KfipuJukU/5oCGwNSQX2YzJA/FdkH 3IRp8iIF/R4G8SadjWHGKe7c6zKF7+FmGqewkiliZr9Mh4dlfT0rpWuaE68eLFSKVPMyregGgNHA /qfZGEc1HtP4aDuSlwV5Ls+viwmculcphqmR1AnzKPMPyStYwgq35Y/Z9G958rqG7n8oLmBsJS3E j0CW0+QNIQzjIvwBCOBtOiouL6mVs/QjbCoGWCG2MrZ5h0TIgCVHcLxBecdcJbjz8lugbGhgNsJx nY1pzV7mH2jDz0BOyuufsceTHKgUZ3x5mZUzeONHEDfxb3z+bTq+gZdvcyzezkM+Tz+kIFJd5zSg t7gOQOSvBvDDHew4UsoFyJCwBOkMx389Tc4RtKyk4/IB+vpTXo6u0ysY7C36afpMgRd5Ab/UwKB5 CAVM7X1RjK4LuPz7Ask2w43CbzsceHeR3xYqEOQVRb6juEr6rCaVTPjOFrYWMixG0A33ny0/F7gV IB0Ie+qzfQ3O2nU2vlFp3UiSl8oRkWPh71dlMbuR9EOUCDBvDHMBCyBRl6ooPDYdFx7O6jYVoLeq YN8NfFEl11yQFu0+1/nVtZc2EaeBRlwXlDDLchsCYQ5aJgxs1RINjg1DTEJALQua2W9OgS8TAkBH bIUE8RVK/tx36HQg5JUgyIxajUQER3yDpD0iLj/JpyO6uVRipimk0/SqA1gl0cOOy5xQXzMacMZw IljWAeK05EoCq8SEGoc+Rhb8am3oKvbYzYCWMYxkiKELKA+9dX+TfEMt8Dr5dcGEbpnUR5kDMDgc iG9bQdZCzDQeFA4oftde9j8Nzgf9f/zmq6++EtHrq55bBCljgzLxIBfrwyCv8gFof/DtGsIVV+sw s3VK1MJP2PugRqdgV6Q3HGqPOGACg4AJ/APb6DtREL6GK2h4/Y/Ng4PdgX79lV/qbgtE2JchjuX8 BXIrMEnxKn7KQhKslF+572dwKcN9PpgWHnXx1emrk/Pz5gKTHebxFhlnwIt8DxDPcJ1Br/7H5pNg lXHpseXgyz+k0xnoYLj4Tz5j8TfRuPYX+XTPxV/ziBNp+RGvWgmRyOu73rMfynTEV+ujrzIMlVf5 jyAFYgZs5ey2wOphMmQ2OJ2OOHH7rb8QQMbCHLmWJd9pLjl0007t+5+x4NsHexoedbCMHcQLXueT i/H3t9sDEGLd2r8vSrgw3qMn6X12QS5DxECaTWALRKInaV6JPW70UiTn7/NhNZgNaeFd48eYTlCr 180an5CEj8S1npwNc+SWvWdeDH8rp4sejPuciLDyPbQ+HHzKyuIT1ub08WT4TfLm8O1R75kXbF88 OiHBFjAhAeFS2N1bTZEIA3venq4+BSWBUcrO7qZ1+qnJHbG1gF4OZ1ezqv6sEyqBnGFsZgeCMXXO breHRC/P5hJKO13UF2V69z3GkcwIT4M2CE/13Xxa+luWTm/S7yc5xjEVlzW/8yYtUHL+w3x6GE6q yfC/v5/lQ6K+Z2c3WQmS+tXay+H/mpGqeDR42WX3ecI43/Xzt+u48uu4cp8m4zX8Y2MLy9F3CYcN t/f99tE/MELY7u7z7KL8bA7Mu7r26vDlyZnfZf7733yvR5Pr76mo7vUNP/4TJhJOCRD4eP5Wp6gM 345jGnmR3oHEDLryg3b5wO0yuf9wrw82NrFO1ivvDswpnrZ1Y3nB592vB+27243fI7JEiA4xf0uf g2DyocKT0v9HaIR4g98UVZ0Beyz5AbEW4C8vZkVdTDNavv4/zkD+Bd15QMsPyjJosjUyz8dknDAX ZpwPAMto4ZzQ3LzF/5y7FkGxQpCrBWtvbq7+P9QghAv9sriajfnj8/Kuqu8+oOxIqxtdsI+7wk94 hTuiebWu6pPHXlWFcQ7Rl+/HpPKqGAyvQUS28ITJ6/IqnSp6P0pz6kyV74QtJGY+X331ABhp24L+ C5Gl+41Hfv/73/+Denj4oj3Z29iUVcOP/wbLhsNAm2udhqW/GTzqmvBXWNyr1ozg9xvz+9ra28Yi j9Ja4m0wQrdqWc0/zKbZ5y4nhTzLenL48798QddPT444FBuoEeTKQFo2/rC15PUNG3Djf2cSYU0D MnhMGENAIHhv1L+bHEkZnvjfyts3R6tzKRhG9Rk32eaOQgbCp3tqLn9L767T2w/fjyphgCDpARP0 mEvn/5lObr4BDf1lkaLZ7u3jK407myLrv301X4aHpyKd77P4JRd/sIUc5q/Zn0HgzdAw/fxRL5Kt fbmq71F6omVhoJlfwv6AsTRhWMz8BTIWhUe9abfUMHaPWJ6mBeGgaUCAloMvXw9rdEAsOImdLIpP NsRghp+WrNmLlB1hbweisV+jmHj8qJZFGIUIg5gogrSEfPMHULDy4qpMb65BaX5LFUPbbIrwdkhY fD082KT4/jkszvvn92RQ4/Sq+Dn7fliBOgJzHo9DM0h+he6f5EUOilJ5h2aCDI1ByY/oJgHtlN8J 7F8vqEXUXDtqNKNxfkE6DX5Y/9tsfHewt87jWt/Y5w+D63oyZkp9n5bo+0qeY1UDdNs8TShgnIuZ J4cwvByBJfG6wP04pqFlbICEw/4yq1MEYwi35A/Q7Vz6DO+ULuzv7CXZcP7CH5bsySsBTjpmz4ZW EU7wVX8e+8lrhGGClX2Prr7pVY2O6KOnjoaOYFJw06Jj5FijpfHMCvZb3+0iwqkW0ytK+2le6Tzk +RSNktP8m3bnUdYPtdo3p0dqGsCP9714J/kYVMZ7GA1f0gtqrmmxFeSTD99XN3dX6G1h5f2PZTqr PhQ3l/OtBSgmwqX/4ftSjs4grUX1f8u/oCo712pQlxm89z1KTmiyyeTVc/oaKOGeVoOb2cX6+/fv 0Xqg67o2Ti+ycbV2sLe5sb0p5wx/SF7gDyEp8VcsRKgl1AA2qn4GtPonZAcY4hlraGh50L5/gUti a+tApTX4dE+iqdC5+v3tAtMsMLybohTsS3HgzyOYS/SfI2eFBbqAW6WeY11uWpPV5/58TsvZ324f xWr9Hjklwrui2WSBmXJ0NcJ5XMwW9NZsXQNajgc/Pr6/6UCE2re2UiRlo3uKzUZkgWGMD5yXECX+ 6UwJqjaHnKFNEDzYfHw7KJDpzqYGSMOnexLsbZbDgfy+GI6HAZt7ffTiKHnNQBhuY5T9H2XsVjid Dgd6qeAO6uUOdEHNorz5Yp7BO/3w/fDDBCiwugyIwksCRBQweFjgaZ5SpAne2dMhIpL1ZRS0/H/U 8LTkpQseAOY6m6IY8YfB4ZwxLBZdmqJJ33x2i0G1v5cQcijRtDt28uo6HdwW40tg9Ph2FTCPt/wd 9DqBEzdCO/UYLo1Opv17nQsgIT4XxxhsjGFsIAWpxEOL7Tw9x4oM10Lr0ExA62eIqT0R7vw5xI7g CSFIQndiX8D16sHjMrwJsK46/f7yU14NLmd/y/U6GPztxnX7HL5P+FawHYsxo48OvA/AY36JXYa1 412O8CfafHP7e5GWMf5cjrW9oZuIn+4rl10UdyCWvQHp/AROfHBKjvXb5KwYS+QTMinQgPElf9M+ 2kriBHglj9JpMaWgW1xTL71sNNcUX2rxj29tbGw+cFHRE3P66vnrs5NzWFjz1y/oCjsqblMSXugA nBcXFFu4TD8OPVDoeMLlrrJ6nYkxOAlZ3e50ksndbw1d1Pav4V2dw7skUJFju1gU+rpKDjXbPY7x kjEeHPx/ui/UhluDZ/9QIn3250EC//djgW5RM8TGcy/VF2rl6kUvvAZ5xr/0Pr379qJcf7bojbfZ aFKgFPr+MDl4srG7hc6bg8Yb8bZePDt5CQzr6T/s4Wsws7sUaxHELt22b6PNioe5Pm/4JwM8oeba +gMiRMyfLt+Fr5ffhf3f4CGfL62dlh9BeFzU1dKl5yZAbIKV39o72F/b3tnafaSVj2WBZ9EXD13v w0HyPM1/zhfN61VWV8P0ZuHi7D3ZTU7SqgZqHY3GGSNbvC3S0dJVe1nMGM3mT3l2y4u3s7Gz/Ujr llbp6PupTIDJtfHVQ9fubIDW1iOMry8Xrh9InePxoic2d3d3KXzde4/0rL9cP0tev32ZPN/c3Fy6 lq9BMQSp/zx5srMB9Lf1eCe/Koc0z++nNBleyZYvH7qWx3DuMWFvITf8v2EhR8O/0TyDhWz5suNC /iolfF7u22Hv2WGU+SbJ/ceaOUxVg48RYyHn63pRItzhvPJ0pnR4DJ6pLfdNRhoFNszGHMYQQvI9 BuKoGoHmVLY1ZXsrBOCbSMCAJo8I0HdUefi01nINnMkpDZsZVojBn0mJLF2aKtncovZBlVcErDKj FfzPcf3N/zx+fXT+5zcnyW12MUo/rsF0kr/8xv26tvad+ceAsTohyrhRECfo5LvGv7W1/7yqv/Gt nbw4eXny6jxJqY4Eg/4TJhnmuPcJQAM3DQFib+rrPlcZ+H2fQiCKWf17EvEdzMTvV5P25vEJxKu5 a21d3mp7CZWPOSPioSzqkchthdB953TByL8nL9+c/3lBO5zwv5J9Go5nVN3l71KyaE6r/kHTcvyQ FD1a1DetebLyH2+Ojg/PD+fNlNYhOXw1rxXZqqXteEiUFTx5v5v3HP64vDEE616B+/J3QDpV/bs5 KwU/xU011qkcLu2NQPukmu0KYgPAIct+10/0o6llO5dg9FmefT9Zof/+ti9Vclf/voJHH//43epq n9Ox5rbemISMbfFUtYOEutKeF05j3izMo0tXDztbQD+KaHGRYREu4KMrBVak+HvyIctu4Hr7OO9w 0WOL6Ns14IYIrS6kPR3L7IaghlYQ65vPY1av/m7ektAztKbztierg99b+wWePkpWUpAWcL3+Tt9R 4Wj+OKdpfX4BJ3ANLVorXxeo9bHgVnCoMfNuhu34ZpBrodGpxXVaQrxSVpkmsuTRq6wWFGtXW7n7 G9n0qskU5z/Pd8DSp7M6verwGIhgNSERI5LOksfD4iwr/oZd/e3cs0uGexqyO48NWmXj/gpy2Hkt Cf57NvIXOt2+5vm/0geQPlDy+FWafqA0/UPv2Q8xfJNEoGIYBUPdnmNFejiSaJReLEz/EME4BefP IQtJ0m6I4Uspj9r1SGqySACcXw8XsKvC9GfEyyb3jJeNYoQHkb7gQd1ueKniWeGEFGBOA1dw8gQI 1Mxm1va1Nfj437OiNth3iDcqXoS1Y8qYvrjjfP7kVXZLSRu0DJWmqmeIbF4qBA/vB8Jv1OKNTrA/ j4zhxXoc9hqugtDIdwkCd6zRbHrnPf4LfyeG7n/Tp+l9wvrAgrW9tR5/MwEWd23+HHFVe9eae5/K IaTyJf7PWnF5CZfeb9zgXOP4+M7x6Y+n5+437kaa2qLfkuSbZGNzbXPLPwSdJ60PbT3p038O6D/b G/yfTYeEh01QF+s4ANK4cITXmIDe0uDG2ta2e2iST2eyTtFDuwfuIaAwOELtD/XxP3sbHpZvnKU3 ibzh9FFt5rJMh9xMb9BLNn/r1okemM4mvKz4wErvd71kHTdn1cyn97RnB+5e1fe47f+Db4ZN0k4F 20iPzm3Z/81zaQupTv5i5/VXdxksYE4K7/AK9HnMGOTBMeLpMB1jxQ3BrsdyHGMaAaIIgOz77vwo WTkqCsRUS+UYOuBx4pGrWPyMAZAw5gN0brIZYBOgPOP7AtXl0JFHAhRRzS5qAl0SQ4Isp0Ok8oMR yG9X2XfzydPdjadAA9jMxg580tpbVSpnBWeztfV09wn8+H8WQx78YBAPTpl72eFDy1SFxdcJl4HW hV0vrBo75QfZ/pA7fHGX+mHqjEgbwC17axs4l56yPizrmHExHWV45mGgMqnDgjDjWh5SximFi+D1 MhMkSAEOSG4KYPzOoKKX0chULv1VnnioPHHUe3YUyROv0KmdcOydFom1Rh+WKOaXHjgCieLZEQfp tTV7MrkBmSJqcUHNgSOqWN1abQhRmE3ZNiSRnFPVHdKvlP5wlrKCGawD9kVcFZHcBRjmMi8rAnkn WHQERcniVlhQUIGHROFDFG/xwzp9kraEr3dojFpSufpw3bSBkwysiIySz/VIqMwAgxzC58XMghdS EbIYyD5NQMMe2wpzvMIBTIsUUsUfW6bKa5A73BsDkX58fqyzDg2WDEXIeuVKNrga9AN9Aps65J+x B+TTp5eCcsaVdKiV3JV/HxHULhtWM6Iv6ckLpX2zsq5SCpVPcKxTR8fFhnTkUlQYW6IRSVcCSjmP ABDmz3bIqH0OpJsGiU3qri4v6XGEJbmPGhW53bk6BX39SqJN/NFddra2orNFNHE5zj6RvVtjvCZp reiDHxiEM0srwkWUerD0YC1VNbGmVVrClUzjwasH7qNLqtBJKyuEfXOdj4uquLkmV3Hvh8z3y4Zw rNKZ3BUzqpR2wxHsXNsQG3S/YnV24PI1Ao4R1CIin1OvDB+Ee62oovQzahqmXukYYZZk7r5AdzSW UZaOHQByzgU+YdS36Ed3GON6ovE2oQTYfFplDJw8zW7tdsPD9VCvTe6KS+U0UNgzzQmmuzkTMCsY ID4kvgSg0lSP7yRLp4JGHdLWYhrYigv5TIvkAzBTKqaCwJ+0BYSTK3Q2LCYXUpxSK8kFBA1HGNe8 ciVEEirPiOzPlVoW1FHCLq25HJPsGsof/DzMbQz0NUmv9LaHM7I9fy50+2w17p8TlsCSNdpqCTg/ KcuihCOyvfiIbM5FO1aEfKoDysHCUVlu4lK8ZG3Ol99/moyTjxwcBpf/ACQBBRT/rjerL9ee9JLf W5vL8VNnG4RXp9XT4+8Yj1sf0sfEELgef6/Wv3Xb6rpvNrDTLFkUC6PqnVCu8roO1B0MKkDJZU9V nlN7ZVHqBeLMk/Jan09vUV/TgZnxVZJeoJE1p7ogGW4jUREedmyHRFe0TI+Yf7PsmuyAuL3yQzoi IBvYt9XlR2PTithAhBSAcq2V4ljGcPV2mKr5duvh8ekJEPUwH3nw5VzqxejUdXmkXl5dzvxdhK/L TBh9Fs8VHZBxTrVxpQ4LV5UGtXI6IqGSq05CnxSxfXtdkPVElyMjqFeuWenX21XEyqdCyxf5FXD4 8oZq/eaXUteM5qplw1yVwMmEjrEUaqGZdVvdXUU1BambU4cRJDO/NOuKPAmUs1xXxC8oaijjO60Y wIoDbW3fwBpXMrWPhD8MDRQT5PBUmUdmU8invoO0r4pJ5iqB8oI5uD7ZuBGB5IJKyYabgtFU3bMN gnbPD8LSph6yXwum+TLn7MpFw5xUWjKSwgIuyLJCQ1rwXPAda3xWEF/OCLciRoiFaakiqui3cAIc t9N6vMj+pZ4W7hhIs2GBDGT8GV10iJKcI7AgULEDeGZhgsGXr7g6uPegE3sxt44toK7SzFSvULzM 1f7fR1BFrOiG90zOx5r0guzWC9oXGWEbSkmSwPynfUOHP2RY8IRVWEN/fCVQ6SF3I1DyCmMRtixe X8VSbuVvpkBbC+eiuhmOfHEVVXTA16XGh5acgbVFsOg1cvi5xfpFryN8gL85CWJ9L4ticJGW6w63 cp0GtR7dXydPgzF/7mW1ZS+rwi7P7fVd6/LS8awRJBJ4aIYlo5JxUXxIuHpMY6PTyjLH2fQSEW7z tHRlosz6VxnJ0L/8+tt/D9qLz1htx9WDhXHibRcC5UIOw2EhZRHYVNdWMenGmyrIhmqsRGGB4c0d KglJBy2/mmIuS15bsULGSVuErEP1NF0CrQ52wTXZOgg9sfy3bOH2ZOEEuR1zDPh8X6e6VooSRNi0 KV2bH4nP8jUnPGCa4ZoA7wSOSrYOvgw5BKlNFgpNlXTxMGeMwLwXCL1P//1peq4crIwH1v1jtlbM avzhtxdFVf2WzkH0y2eejyeLrlG5L5kkgcixyCn9LjTlBoIxYXSP3oCURtDqFVcE4ILxLAIhF5Py Id6px0jsJJaAdj+8zrRelaj0XP2gRneVt5A073sCcHcvYKEwPm6tbNANWyojTQlEmFRAJ3tqfS5s xj3vJu5FVDq8XE69TYQVCXdki+rNNaxso7C0HYlKyFcM5hnSObMeNqksEr+2WQndbiihp9O6LEDm kzDHhdLWdqB2HoL+jEGTWIMRFhSWQquIvnx35hzwzoDna8w5bkH7m4assRn1KAB66q5tgL61Qut1 EUm3WSTdboikL73B4n8hZh4NjfpdvkJWHv3LK+KUhRB9CvfL08jjq5cPy5SPN3/ilWRxqhzXJZ0k /VjkQJ8T0KNmKNd7IgoL0FeDvy4uTaqT3XLw1hchNYTNMVGQWgFHFjXU/3ZLS+cE1TRyiL09RWZT gc5J0iYKlVSRXlWdF+gmepNyNZ2weiE1hKXuI54vOoaLFRpl46dXYyy+KAwbvgjhOrLxgMOzKQ0s 4tT+dezQ/0b/EMobuNq7G0Id9y+tz3srbBGECzKeR/Klf6AbR+e9cVYCqbXmxHpcNr/+yspo+Xq+ q16SSyyy7Br7Nbka24tkwYLJ+23yJNyEn7P2/vX7rP28t8IW56y9f+A+a69C08lH8gIUs6vrYBPw ZFZo8xuq04R9lbgRzmurtxsplLp5XEB8jr8FOsQCuVgSDEsuGcdQdEx6MK0e6xQ3Y/hW9LpFO0Hs msXjqRxKvmG9g5maJncCjsI5V9IrX72Rr1c6zemVlHDMQwIlhxJ8HtZSsroSDiEmOhZ/w4u/jdZA 8nqqZAafF5EZbXBEa/T6fcis5QXXzhziot/uQ1dPbKaBpaVWetDdQSOHW7FiKqVa20ilQScwwiad 4NtLV1Od69UCilHKbCUaazELCQYJxE6SJUWu5NMqF/5aqvFB2bWgQmSfOLf2FD9G6bQuSenbC8yp uWhJX4o1JPr31T/+0fo9/uSjROc+kyzo5iv7HPQT9WR//so4sZt9uSebv8C/f4TrnsPHwSYs7qb4 eR5jIdim+6Wtwo6sws68hQBaOXokWvEh4V/aKm3u0SptPRKtHL1+8+dffAnYffgYs3/Se/Zk8OSR 5m5DhH/xNVBrxaOclB2gge0Fx+T4kY7J8cmLk/OTfxJ9JCuviunakU/WUDSeavVRFg1JZ28pk33I uP2YH2eouzzUxzrjlAv3xfG5bb4NHu1WNEk2X9Zh36XD/mjEULVsj/77NyWFAyKFRXLBySMxPJd+ +qWt0dYOrdH+gjX68ZHWqJmC9mWdpz06T9uPdJ7i9Lovay32aS12Hn0tMA/vy1qJJ7QSu4+3EpgW +WUtwQEtwd7jLYFN+fyilmJ3g5Zify4v/emReCl2/KVdNZv7dNXMYaCwOH98pMVxOe5f2gpts44+ 36QDi/TikRYJbXNf2vpsPmGB7pE4zYvXR3/8gmwYWG3uCfzvI80+yJX/srjsJnHZxzLnuFT9L+04 bG3ScXgs2UOxf764ZWD772PJHw596ItbB7Z8zBE+HrQOhE30pa3D5o5YgB7L9KG4Vl/aQmyxODGH T4Is8fKRZImXfzx6/eILukm38SJ9LEX+5es//bMs3Y8x9wOc+8Ejzd2AgH1xh4NlyTkrAYfj9SMd DoTk+tIWZ3tfFZHH4qGEmPfFLYP4EuaI3EAkbx6JSL5Ev/u23LOP5WiJQO9mXx657MqpeeQFYeS9 L241mMFuPtY9q/kVX9Bdu0kK+yNSA2ZYfGl0sLMp4TmPuA7/FGfsY6/DtoYpPRZ/wBPx5vD86Kcv 6Ehs4ZF4TAaJ0ueXRgrbGyx7PmKUwpt35/8kKviFw232kEDmuqM/a9yPHW6zz0OdQ80gHb59JOmQ 4XS/OCo/EAHg0YjcorV+WRbrLbJYP5barYjTXxpFbB0o33vkhTDQ21/ammxvyZrMZyNnj8RGquyL uyl3NpSHPJbMwDUAvrR12NqVMK1HWwZipF8WE93m6OXHcoBW5fCLI4MNiWh8NDL4Im2325tOfn60 hbDw7V/WsZCg/vkhI+ePdH9IVZMvjVo2xSy3IPLo3SOt0LtXX1pMCZuo5tPO+0daGar686VRzha7 QZo2vF8rot0/s3NY3NzpQK83nz2fjcfJkX6XnCmkrU/4vNHOzJu0fV995d9bOVol/BitKpCcFcMc FMRkZfPg4GB1QKghb/HRimqxlx8REOUrRiFq6QAaZxxvrZ9G+edlOq3GHucT4ZMYzRbezAWC5XJW TvPq2mEc0j/Gw+sLYl+Zf0wJpwgLFgj4N6IGMjAk4uXS87cINYhYcFixMq8FF5L+wXDzikBPc5gQ oojTojFIsYzppsTS6wgIzKPrJzdYt5yGlhpY+lFeSRGFUZ/RZAusAEGgIAh7zziACD0DahZhzgrG E4LoILKjrzUshedGDrpGsCndwiLmSD7MJJsfS0SkZXpVpjfXnFktGMZ+3QhAkfGOaRZV6xIOPNZd HewarE42vnTN4coI/q0rJYMIUDCR2/SuL7jKFWJ/kK1FoT/i8fvxlR6dvdL88gYN6ob6X4ryKp3m PzMp+fXLPjG6L2KnZCNB2qOscsE0wtoeGSYp3+DQXHMO4UkwvugfJ8EP00ox9ophNpqVAuDjplQ5 WD/JYNdWXUNnrnWBVXGg0QyEhXSD0FeVIvVypr0cFkLjAj7nD4OmfVSyKojtmJxMr5A2l57JzMF5 3mAhgqriUn8l440yuSEpwa83WT1Lx0QwBLrLO++GUWYfiw8M9DJv1/BwAU0olAxNsgIWWt2fdVwj dfsCLh4GElGG8RxX/vRQWWE3zt7hWXJ61sM6GTmT//lPJ8npq/OTt69OzpOz10enJ+d/Tg5fHYc/ nLz68fTVycnb01c/urbOD8/+mDx//fboJDk+PQOufvryLDl88SJ5f/j27eGr89OTs35y8r/fvD05 wwqmyenLNy9OT4770OrRi3fH0FTyw7tz19yr1+fJi9OXp+cn0PdrKpwkDf0ZxnJ4TgN6d3aSvH4u Y4O+Xx6en75+lfx08vbk9FXy/vTFi6A9eAaHfEKtvT398adzGgn+JaMxg8WGX568PfoJ/jz84fTF KXT8+q1r7/np+SucyXNsIHlz+Pb89Ojdi8O3yZt3b9+8PjvRbcQK3kMEAR1noytz/bRuL0kKz2cM DKQH9O3zoyQb5TX8eTmbMovE2hGzEoFVxnd+c5nc3BBjsiN8DB7VOqLKwX+u68n42f/49d+/4T8Q aLZ2N58QWCPWIhp8mowfu4+NzY2NvZ2d/4Ei3P4e/Re+2aS/N/b2dva2tv/Hxv725vbe3vbW5i48 v72xufM/ko3HHkjbP7gIsHLR//hbmS187o/A4/4Z4/kn//sWER3XqvpunIFclXGZ3e++rrNP9fqn avw1C9JfI5nsbR0M4Kv66+T3z/6f33zrSs3Cb8nZn8/OT14mPX1uVI96+NDv8UcQwL/r3WVVj1+k 76q7CTRcme/hF/xhOptcoC6BVAnqA1y/V0V5912vkhYvS7h44MNX3xKsG1yYF3APftd7f/LD8eGf es9+Oj9/k5w4oDzib8deQEwOZyAKEgbx2lrCL4GUj01Royn9nBAQaDqG8f150EPYbBb/fyzg6h9x zS3+5s+DBP5PvocWiLd+a6UjN8KX+bAsquISWLD7CIoDyEVlyiCC9jVpC/99C/oUSD2V+eqrb0Ga qtOx+Yq/xgrEWf3s9TRLfCdY1Xtdfvl/Gkrjt8O8vnv2NhtNiuno23X669syu8JBvD/8dl0+fjss Rtmzgycbu1tre1Tim74I2wO23zaubzMs6P3sLoXNu/p+ogPj0t38m5nuejhf+Js2pX1/Tuz+vMcS DtdZGmzRySD5wyBxP/WTP5SDJVv17ig5LUF4znrPjkGeHSSvLxNbvQ5lmKNicgMUVSZncO2B9NyH 4SWuLBUiBIKse4RIcQXoU2lfWmzs8ldf3X9/k/XGD7Rt2kWwh0eNPdzaO9hf297Z2n3AHmZ/u/0+ H1aD2TAfgDTutw/mca+NO7Qb9zzNf87tph0OEv5u8Ua9yupqmN7APumnuaeobZkXLHVwnPae7CYn KagML/PRaAzaRjYeJW+LdLTgWNEK0Ea8LGYkKyd/yrPbpZuzs7Gz3bovLFXNG6tsT1qlo++nshbt 5yu550adDd7arToCjRptL36vzgbJ20Ei3y/ZL9BuxmPYLfrvQ8/CV1+5ndnc3d1NXg2S82x4PS3G xdVdk9t9ZZ5/uY7C+Mvk+SbaChtP0d68BtU52qZ359E2PdnZgDO0Zfkgvr/w6FTlkNbo+ynNvm13 7rk1x3Zj/kAocnZjjoHz8Ze/7srcXRkNGX7vgbtCf1LBTapDCawsuyhnaXnXS7Ak5Xc9NN/1iGHD Ml5UVGuQzH8gzNTPQkXbV2dNEym1xybyqp9cEwyumOAEZWANpbWKBpFOh/l4LFi1KAStbw42nXY3 SafplatRpuEniiCNVZaoEQWE4vor7e945DAYi4M8pNfhjfxmxvbFvpY74bc4J+8qWcHXc0I8J0Bd xE9cHYAERuuz7hYIFmddRb1vJ8R18ZPC/2oFWoPBTNKhUE24qhxUcZHZAhJcCg2Xxq0VLAZIqsWY bH+8plzehsuzMBh3VlKVMDSu1QiZfaFbkaROsKTqH7RAAz8a368o0rjHw+KacUvnbrbgs1M7CNoI YoVCtWNN3b4pKoO21uYTbMmUPqkZPzx85imudP1MV+6No4inZI7WKiYwdyKOrC810blnGBxQnLEL 8bpdoLH1PSzODVrJvFkS1jsvZaXga0duVO5X6mgdjquCqbEO+0dTPTeotttJNspT0li4egwXEKVH BuG0TMTcnHklVIsUzZNCNlJ+GNsF5SH7yIuXJtc5LF85vCb8zEmG2kp1nd/A8CqC2lyhoiCpFIgB 3cX9QlD9WE+YWmLM79VooC/4nDQGiVAAwGHKjI2NWO4E9qmCtSPIWzQiE+lBF9SOt93VYUXSgVY2 JlR5xiTujYE/Jhydj6RyMc4m/R61Q+Z0NMOyuXkohIMGSnoJoWWpyCKOSO4nxiydkm2UGiGfGZwj KvdcOWv8JCuvXNVVMqRyA1+7R6PFcQjeyWtHw42VygUBOyhwVJC5GHeUGRUaWZE+lT/FPb1lO7Cn A+4tHWfKUtGW7Q8SroeyGbbIMz8FHQF4IuGV8370k17QNpdcaFdQdbR/4noL+NUb5VHK2N8XJYii 7+Fs43x6ybefQK1O6rS8yurvem+fH21tHWzi9RNNUCpa8ugvqOyN8Agk3QzE1TFNxPNXPgq8XNSE vzySFeXLO6t9e0HYi8M8tbvad5PTi8Espntub5XBjyszVh0S+QSE2/CdQT+7K8jbxeMiI2QhEE7L Z8VunPb9BHaKnnzJT843JPSipT2dujulr4Xj0Es0wcrDgQ0dKyw5wK3xHZfSoGFQQ9S93AQDUCyJ sfimBTeeX6oaPcnx9b1JlUtyF6mFBL25L9Pyw+wmeSFOjWTlf798sRoTEuPk91Tx1LIh5sLpi8ct ndqBS31IKTSPbm0sWUZD5pMYjbqiRYHLFd1jfg/N+QZJjEo7ptga34ta5ImqoQmzZSaA3qK+UDZ+ q+WjqLVv6GRf3FEj0BjwHdMPDzJYQZgdFpTf3Njb2UMWhVRHBWZqkZ98R4T8PhWmofK2xOYMsJBO StVtGDp6NrmQ9/0yEJC3oweuGusWG8/crRRJlYIwsylcuggSzaeKoLhoS/xz4latrrFWGK5kAj1j Cccq44p711SjWXxgInJwcRfZ2Dmzh01+rf7efjQJ34wAYOfTiLCTMzlyB0ZSIzzt7JYepSbkcS67 SoDrQv9ykpuHMJUadG4zcR4NenPFxahhGJw0Wxdm5IqmTVJWxVeuk9X8ppuKPkJHyuVaySEdfUyn tQo0OAzkMTJCuCBvsLgKnIbbDKuhVtIQfBvNNagorNMgN3JY+5cvKecqdXWUtlruhjmFR5KVQy4p 8QlYPZVkA2kt6JNlm6DffMplVInmUKSmeeLuBiPnUouwa0LDKiZcYn0PWCDSHEaucCtLDLYCQ0wD 76/hEmMxgKIDE2aU1pHlhH8qxDy7hDHnXNQ4uBmAISGzo9KUWAU658sGiWOGO8uNhQRJEOxC/9Q6 1iCkJiqt8UYO3UuMD5iCCIro81NRShwbEwN4noku8QpWLZiNeNONqz0cRrTrvD268xt4+nI89DS6 6E3kF3wtZ1yTEpjFnbB/udMZZ/4lZs+vnfGwnDJyjXEIWNXKXdkqTs9KGQe/YVksnQBsDsH5vXTG RNnaDx+Lqv0W39yMaUIuzcnNuLjTUvVSRsmVH6cSkjUVFLNGX9JqVOoQxyiXsNYKADrgqPwW8+CU ZB0C9U8/wN/QGutj+JO+2XePmZ7dCEP+KENwS+mGgQ0MHFvd3Jb9D6aLV4jjpRw4YRcoOMHRGj7P MT6I6/xIHdEGn3HyWiHVnTHUKEuncsyddMwVb+hAt3AsJwluosgo2uWiq9W8sbcqlTyJGmYlsmP9 ldrZ3FflC/9XfiFHVNPQ8KqopUNQJaeoOeHkrMmBj1E9z/CgGr4v4RTbH1SAIPmez1U6u8J2YJN+ ePWcd0uCLagEvfAmZ7dQTqonoq0OSOsp2QIGCGNr6g4be09Id5DpiVaObD8eGdMWRngMcUCqM3AF P8dxI/6zNdha2G9fFC1uBQt+u+qwRsHlC7LlDvsAMg8oxsDJelhDqdfn/2KQBn5+e/K/3p2+PTnG z2c/Hb544T7wE9QOfPH63Qt8hj/4l49ev3x58uqY3oeGD//cY3rrvX6D4SGHICzbK9GPt8zkqouq AwVbg+EYW5ubBy2LA98ahS6m3ZhyzzHIiG2wllzfvT1dx1JEa8khuqzIqKX5j8kp1Qe5zEUsbPyO haSAPfb1LrjhSrhYfJ21NZjXBPQ4jRsa0WXGw7rI6tuMJdLJqhMQjVjSnPD2wV6LBmsSN3ESztIo wYhSdM8dPJgw3lYwMOiGzTa6EJUWguS6KJd38rtRXckemmViLymtBh/R9C4z4ZiVRYN/yR1gyS7a AfivK/mSaveFFml2EzBRV6K2pEbdbojAxCfHcWfmT1orLGo5IVNanVERvzEHJooMxEWrTnU0vrtk pVk1s7UhOQFX+UcSBvxSDbZi89cbvelwoFTR8WM6ngGPS/My2lmXKvcxuKaNAdLfqrGRDd8JuopK KWpJIN74igvMs0YGHQ398nsbU3zl0z2M/fRigOSe7+1apXqgI5qovEfP6YqL2ucq2FKx4B9Pzl11 bJ7yrC5wBbiMEfzvMLSCyCjDhTgGpephCwGSq+hHbkHCxTj31jepDTkkVowP8Z5SPeURjMBak0Ap Jyrjiui5E/PIUkHCIWw+EoCPbJ1iJDGI4rwjemhkqDhqNwfXo+stNjBiLLdjcwFb4eMp5dsrX8p5 B9PIa9h7UL5X9cygcdqpFmg3clK1RsjiVN68O+8nBDnWT/jSOKMBY+oFS/uHyat3cB25Qej1pVUP 05BbIBlhxPS0bnKFZffEcVqnyUtQKdi26BbBOwR67fcLxg5GD99xQ/a+8c1wcGuOpRXJ3I79sj6k Ao1qbEIi5hA3G6LX+bjjx3Z2og+rnmoCxo3bJpt+zMti6pRR6zOhGltOO3Roowv8ZFXMENgi/HU1 u8Bq4F8btYPisr1izJG2I1ABuZIm6of+JvKMBziiNMaCRzpNvhYD+uLG3fD1wJCALl4ZtiahxR7O lFC9c4m0CFlI2r43oh85krS9EQ9XTY4Kl+HcgrOvF3Aeqip3X1et55mnre40OXiJeGqRIfHoSee8 ZPMDxUO3NNWcWMlR2Fj+zevgOOQb4yHrIYfvsdiHfKU3wDOLX4bzQlV4XtdzWeiLqJmcyv1RfgEF xZMJEIe5GjNVv54VVU9dEz1zfNd3/DPujxfzImor0I/lHm+2wNy6T2VTjddFnKVu2sPrTGz9IjK5 WsPUX8U5LlpVT9g1Sw10k7qBEBsk7fHOWYqSSBhJq6oY5nQDys/sBuUWkP5orxr3z/32imf+jdOe ZeYT2Jd5d16wpPDwBVzak45M+kTNQi+zOiXWhxyuqNJxNYfZ0mkeF/AK1n6hxJkETgceM5AMS0yU kawJ2tZsKgUN2YqMQrjXXMoMusIIcYwXUNZ35ywhNzoUldHIqEQNYdKJpNy4uZNxGlnRrKrIkT7R OZGb8yqbZiXKMuoCEt2f6f/N6dFZi4sCv2bFET+tvfqRrLvkKrEu4L7s6kfswe0+jx2V1gyUMloi KpAu+VLX+U3lDdgvXwzQ9/YBn5e+hAGN4t68IQwIvppNPPW4e/PYwz6whQWt0+jTTVbeHj9f9UtD Jf4ktrDp/kPbRFXAxs8mfFnCywE3TpMpqF/Q7hpo6jAOWW5k2nKDoEXWzd8L1NQdHCB6NmKWZ2g6 tJuPNSnRQo4+8Ku8Bjob5xclhqagy1qUxdZtxSkdY47XFANjsxZdcGdzGzfYrwhqR6pnvk/L23z4 IVrCsJH3z5lAUqdLgRiF7vw6I3cR3ZK+oKz2w6cbONgk1TtsDK+UKb0j46/4QGjhTInooPf7Zp50 gA/fHkUje3eGX+roLkDizQvKLMuHfrqs58iFz5IAxlhRMAKez7KO3uQXxODpSe8Y+FalhcepncZa bz7Z2Gfrz6F4UvA49n0uVoYzqXzNXQ4EOD05OXH8Sex8U8kwMwZ14hzFZDIDfn3nnbN2X+NbGUtX gwR2k06ZmrHPzYODPc8NT0/pUFbXxQ25cpge+sm7P7ZTgTInTfjroVMiGAInXomRXWs4yyHK1Ldz WabO3QgzI6+jSgWOknSy5LvDRvnIZH31NORXEjR1kTW0Ht8MRXxZyhr0zEEqLvAGEj/6MJ1yamdZ FhcYZM7bj8yYlCc8z+E2BM4bFxHjuc8YpYk79k709diVXEUXhk/WDjFIiwtXbfp8O9MqqqSMa83y QdBH5d0Mdsng6EDnFYx8jJ7MD5mIwPzSxzQfU2oySffMdLBtNVGhvYZCKuKTRD4pzkWlb7G0rouA g4/puMAYlY73s9U34H3yc/7Ejst5ylC4pBQipPmBFcYl0ncSslBVoGhYbyhwIpc32k2vSZ1ZRmQn vuM56yIUb1nP5zROa28O1bPAH6QXa40Uts4WC1HUJ6TH1Ncl1fO2HmCVK4EVq4ZFHHbGyq36ZHKX U8pivQTnoUABtAFcYazatzPjOeNfIEGrWkBsTF/NKzbHZlXN2cXMWwtuoXRBYMnfMHOUCyb7Vu9H HnfJn0jeDSMW2yV48hxln/BCrnwkAAnAFxl7hpGQs1GLT9jJHUMcLvKCYYqBGFwGHU7AGKjuAnVT zDFekw2G/eqLS0lYmsgJemCQb4i7BdQLXEq+F430Xfn4Hu1UzBPqpwn8fGEoxUCDMWhU1g+LpDTl G1d3f3pntUReQbauk6dlZCylBEpAXEcdJRi3MEbHtEZ4+ixbOJUffOiECwUgb6914uj0KMCCXgcB Hf6X5G5ienSTSFyvXhgc8lYCo0L7rCyfS/MFTorCj3eMY9vsLab3McyjpIxpv1TLl9UsGbMQjP1Y Q+5DjNNRnKyeRGxweGnKMW1hi2wYSSf5OE9L9WZhLMniUXHMiUuhZlqbVWrP632ajJ/ir3CB1sLN +rCc0xFKVFbvVbcWXxV2ZOT8MgLPvL79sf2fa2twstEZOYCTNrz+kH1/VcLRubir4TGQTNfW9LB+ Nfes5mEmeiZXG0mm20ekDSJEwoivZ2yph8fUJhadZXUcwwePrGHa8dnJOUm+JFYcpdOChT6MysKm GuLb9sa+uk2+Sk7rSA9AVYR5Y6CPCs3B3n0LS3yJr2qTpmb97TbVqj9/u47Jg2h8h7bW/wM/wMU1 GUgrvWdB8BT8Un27js0+o1wpMjwR+0CNAS+b4kZ8rCvimOgTCyeV+uXhn5GPId/FA8qx2DghGuO1 j6R12/Qtxt0mlNoIo4c9x1g9+uWrr+DXGonq6hzO8ne9vwB/vcw//bX3bEXHsOrsVBwCw08QnoQz zPM0KQifEg2wZbIsSDx7S0egaIxHIMhhVwo2sJocSoQMUA4NGqNd8MGksYB911Hug0r55UHyCmPS HXIF5oHExEUu6BRRFbh5shfX3OZXX8m8iLYXzMGdy6oxi9lU5yHU5Z5tTmVBD37Zw7785rT05VZm QZ99ilMmay6ugkzYdzfKhiAQSfD+/PHl0zWqrOPfXD48myvhtvB+wyPpBYQkkCpEqEZGx1S4YLSo 66MLr0ne+ktE0RR1NuT8RqcxalwaR6r9AG+6Lr9dR6p9ZiSQr2wAXt/sotcWwwizFeI3C5gNPL4O yt6TdfdO71mXp4TjrOKYGKEFLo9c5sURKTAlH5Gw0xqRoMz0aXJPzuJuM3NQ5u6UBMEvWyy7ja1b 0GY4FJMEko23Pnox9DK/ArHq2bfA5tLJxVhyD5FjiJfx6bfr5rdvgWugCvzs2//5l6Pjw/PDv+Dz 34ZA/5QQCwswxUy1wz897fEfTy+Lwu0wfB5cpCVmXenPnzpuPx4jXd7vepj59ukp/fJdj+xXcG3w piT/v/bevblt5NoXvf/mVO3vgM1ddSwlJPWw/JwZZzSWZkaJX8eWMycnlbsLIkEJMQloA6BlTqXu Z7+9nr26AVCUpZkkZ9tVydgE0M/Vq9fzt9xq0CqBmcP1+PQspWX+ZuBW2d1Tn1Y/f73DD/iTnZpT 0GDedlbux7/+FYCdZAV2eO16V/GESI4tq639Dfa2pkiQVpDmtYT5q23Pr747ybXN3NX2wReBcBfI RjC3abLVtTTDZOD+OgDnCcQz1k8/W/4YuGYHG4kP943M2yFnbXR5r70pvdKlF9YAPoDZGiEdxFHe kzUD77vRnZjerPo5Ys9NG17aQfSHXK0wh2SrKCWugkh8e+g2EJbY/dCxj9tDEYW2Bp/MO+tJ3TVq PlvMN/9woztb5tDH6ruZzlvI0nOitKNiFavNQv3fzM5DhvFPxR3ICuP0nZuziF/t6K85+Xza5fD3 UWQUTLu5fr2Z9QzTAK3x7DDcBrJuLQmIA8Oh3N+dEOPDCyqNfPNuYu9JTsUiY1NnwzB1jQU3bmJ2 AJtgI0sgkX3uO7YbpdZ8JYNvD32oJiow6k8zyMEgw8klYbFRDBTAw2HNqYoTCy/RZbJ0Oo1fohTQ V2o1isQB/WVhAobBy0Svew8EKeSQ1VuSZzmlhIYolKOW6Ahu0IewOLEGRcpcssTFex7BQEo0e+D7 d+3OUrdLTruVgA5vd7w2kUXNyUMfb0muUNcfRlj2hp8OxU6NUUSua9wtY1k25lXNrvU9a957rbSi lAV79TGtVmADm2ZwMMhKM11ApH1TURgl+CursivQOaB+vhNdq/MUIxPYkuKuEUldXoU2cR8vfjnP J3nDkQvnRf5zNmVTvJt9YOs6JNowP+x8R1bST2jACHMa1EtUlNK0BgQUq8DHzkZjDRLGCBxjaU/A lkWDdexBHHdgJoKcriYLXFicZglGVdyQJR4pipmnhBSiAnxDAofyul7yotDAwDJZhnnfLdO/yY0g LykZ2cFUdemODzry0IkCkr0/YN7qegWoopq+jX6uzPpVatL2r8rlHBxTxDs8mEIeHrJ7dXgalTA2 9FS8xMz6k4I4DZz6F3nxIWS6c0jPQl/OyxfmdIvRF9L1MY6OtNooZein7Iycr1kGmUYm4iOwGlMj Qg6+EwsAQJ4aAAHY8oAA5L3C7DSARYR4oOTlyctjeoixJwLcgL9sU8AEZ7/oyUTgAhzE2JE8P0Ug ArxjkM7A8QS9c9BMqF0PyW0CZNedencwZAom6zy0NBWveSERJGyTrwGNmPBv1y8JNjNu8wcSXawl mANQCJMWYovoyHDIP0uSrbQAJ1kDs9z+qi0DxTF8sFi6Q33Ut5YWn4f55BDnopWaWqAf8q0B2TA1 VSQG5kp2LAAB8KgTPnqWEY8pTCmjyDB0FErCucaeoUvz/VtKSfbnjTbAo9/agH0f2JvjHmN0DW++ vDPCrO8S4zzdsmfj8/EQQSQ4dkNxJtyCb0t8UmqC0e7VrdPvj/Ac4zd9IpYnJ3QxylG087O3qY5X HVycoKQb3d5ObcejObSihU+7+8MzF/Bh/0x9QuTc0psOnTLiUdfNGuwMvAwdr0rR03ed5lM+ikbi yglGW5JDOFwYTjPmb2q26FOy62LYMDTNHJs84TrcRnNG8SKtQ3oJMyDwX9BUisg2ueR7UEC4P/5V WTbI8ZrycjSHIAzbZssGju5FYUG1O0QV6wZw6YK+7s2SIOfkJSRjLucxcb1ivAGNgy/cCJiDsinU +yqAZVR9ZyhccBvzMHFsJ/U52yblVVjxhVNjYOdxyHTrU1Rf7cRfQS7H2zSEMsoLn1jQvuX17gOJ FUSm7sQlTmNDFrJGriQRSG56jRGLGIG9QcEZdmZYLRmzA3QYx5/HEIDOtCRB6BbHCSSJdiviK5W9 6AtuWMeouxn0oZ1NXtvBcLYJRpUEjkonR2QAvJeKY4x3JyB1ktxJIG1FfFBYMoPYpISWoAEBbBih jgWlKMRZsHk3PxyfjpFByAAo1MknVElgRk9CFcT1hS6XaJNR2maBnfIAWhPFc/hfSwx3UZgZTYnx TTm+D29fzpc1h8XrbDNM3qQsfHfDrCE0UCLbH2KbTi3J54i0MU/rC+CominR3RZxaGkj7zRz3x/f lz3eNA/w0J0eSS1rLxZuCCYgAcgNSfLhDc+x8Xj0xtlYJHenEWTntMgYy6HnIohPV0He9SWxHWm4 nybYSyaMKrsXalBnzzRdN5WEUatcuk9gq7pWNtZAYM/cxc48setuJ+Xtu2F09PEUvfewQyi78sl5 vyZNEN78Tkk/jdcWeSzEIr3vvqiIVb0rUcW0Sgxd13IdGMOam9POWVrtnM1T1OBbU4XpdTWGDcGN 2dFYZ0MNRwDdoBkpLRBc3BgsDw8kNP66WfVd6T0ZsEZuc1cDskrK23xBWTiOdOK5cdgMGRUDaSQU fLxsktbxgGrgrcRMKScwKKDgKLgux2EW1OduMbTduc08zb7vrToSiVLZ9buACBiVrbrRQb6djFwn 1tV2nKgLWkHvccWjU5TtF8zeqeKydv+UmHv7EktQvJMROXdmS5FCDFFpLPcySgKdf0bACAUATMui Lsjss0L9CtVIQX9Jo4uG7sXo8mHLXJgDmyJSDVqwjigqECwogQwEG5tOqGSJsvCOnkFdgIijMi8o Yjhg8SeMtoOVSnI6D4wWQMIDJxtArJDGF1Pwq7HbEGgKdkEWJ91UuMeywiPfsAITJxiigU4SZwso DVKzfCChG0USeieIyMFJFq7n9jA4pPERkS93kq3oO1xQzpFFdkGnXbHdaH2RWgqqXYI+Bw4bvkCJ 9NolUw7cOSSsKDRGACgxKInpnPeEwzWtxLIQfCGmzS40IZMLzOJ3QM4gZDKPiI+XEep0TwMSpFQ2 dj5glLRgXqA0u2zWgCtVTkqpkDYuyqvWCcOzSxmdRNVsdIOCMGmVu05Zxcfg+PlcVSi2ql7LKSyX UHgzWHwSpn31nmDCvMfCNsGbaEsim/BnoXeyXMGL0ZpLSjTba5l2YNBMLkY49g1BXTO8ljXxWk7g hgbS5xYp9y0Fh5O39TotqA/xFwaHyeByXD00KRisIqHKyNXuaGkRIh9HqwhSqn+/eX8Kl9mb1+9O DVcYanqGN1pAogVYLNbgGsIH0CCP1Ujzip3UMFIG4AQiIi27iNAqKGfaG440Jw6/GKFQyBBegQ1P z2zasJPLUAR4xyBcOZ+vxGqAUewMjwVHH0kKUu91MKTE+6poNTNbJmFrP2TtgWNSxc4AFpM6ryCO upMptyyQkUmHVBDOhSWcMNk9L9gh24Qlx/tHknbx4qEk7zOxXASoMilm0SiULSKfUvoCi3BjJkny LFDUPDbEfQnk8dHxi+PTYy0OlAK+nfGimTUA78VEb0JBfaV1M95RhD+gLNIPaFlFHyN4KxsCbEV3 FzGIjr6ZXRZ4gde1vE++28x79brxAT02HJwHQ8YeBG6O6GfFiLIImCEO+EiK4i37OKB2ZK3VuGIo kDcrXCt2d6nn8Eo+DNZCnFvxXGdlFY3DYyqjxYt8L4jPBCvuhtjhPkTFMwJygZVRX7L7N+CNwMSQ iYTqqwAc8fkH1JFKEQiF0W3IVt/RHaGME/t8jVCI3dz0+5Jg6WL/Ui9oisJwoLJNjDBtHM0w5AAF lfciuxG7NPa0H06+N5jOwPio/Bn4DD4wNyA4IPRu44U4VLEuFctU2rpZaaszJEpSYiZkjmh9iyeL Fm5LrtR4HtvxRGwXwgIEzxENJGntoS/QxcffwWRFPmClj6vqxZACkF6FVmfitFBOj+vdRURoah/q t8DJgRUCZrWv2xf5Gs+yGd80K9VCuZ9G+R8LBQaqtgXNwZ1y/qNb7ZFkJJN3JWcBSuBtAaoT+Acx XkWc1mQFnnKVXc7TCecBBQ0JPLY4CQ1AuubTQzzSWG5eVTCGDKfXMkwmWzgutM1NcccpZIOiTPWy u47Ag2ZkzOwdPV1dsm5lHfpXKeHyEmsiLdTsUiSA8YXpSUY76Ugrp83vOc8w55yeElgq4/ukTToS 8z+b+4V8JOrHQ625dsBaDlykrPQYKYVhO1ucKktGAAgkIJOgyRZlNQ6OpWre2wgwQZ584pAwsvag oOHpyn3Ga0tqS9OZaHlZNgTd4N6LMzd5ESwAzWEhRK6oZKIqJ89/OElILEkC+B04MgPHys+hyMu5 6x32N1jARXopeSNJ0vYfUX4RHQQENKXGRBb05QCsEgexgRIzBwGC9M1/cv87kFb2rZNaYujbE1r3 9KzOOLq6Owd2kl4StDM6BNDCS8uAyn/K0Rm4q46i3QQvGXwnIoitetuw4NjV60YzSwGOh+N/UKni Y1FaNm2bEwwwIz4JXOWZo4RZ3oRpvrOEi09AtUYepZyrjuaJ2vOK5I/OEbDi7YQOtKMzfaylbbkx fHUPFuepKVKE2bJuYUkFLt9eXULvgnnMvA01KshOZaaMIqVX6tlKv9DoGlFjPOS/hqzlEhckJIgv x2edJKbgFSF7GlioeI2N4aucNWjeAklk1JSjRRzVpPEa5o4P0QVbpzck9NdFWxfnQDzdHfFHtHeY kL+tiMKJ5sUHCc+L+mfNG5RxULrlbqgzwbkRbNnx3i6rYZGWY4ZClTtYp+e75F1DJ9O8hv6HvOCg n+5x1Qleqd7VfrasplnBJx9hraJWuR3DC+acYq7pcno5mqxOO3S2iJ4vU6zSS0quGgPJnVTBLWYO IWCm+iaIy1NWMcLk8wecgiPQ7BmBSTP4G4hihab0wQiwlDTvOsWsIbAXjmDOwNVoM4oYAs6C0voC 0cczajqOchRr+2HN55iMBHOsLIN2WrhBSBrEsSBGNkSrzFcyWLJIzS2kNo+uY2RdGsJ1LmculxLH jtiqMQCmbEy+JjDIYwsgO3CUA3jC4nm3jDv1BOgW8H1NUBLQ9BA10Ii2QHgVCYRLapBJBdm7khEL 0SwJeiwCzULHmiuC82mRCOeSxH+WIcLDFGIcxl5QxFrgaXs0eCuR8dOUfBlIzZeWbtiGkKcoNZg5 Lg1ErRI2OAKlYX+jMNvdQu2joGCgJnjGNZqD5x8hgF7rYSQfHYutL6AA/DYtAXt7JHTLbxDcXFQ/ e9wq/UTA11xlRBUa9AhjyRpuxLU5pDo140gdofhuX8FJryQEnwN0XUaFlQjTaMncSKXGyUzrqFO3 xHcg/HBNvNSxLsif3IK8wwXBMkEt/Ag8gATBLDZtQRzHwlfSDsGDe5UPfyDTvCbW87pUrOBowDbe drB4UrCcrFFeyNVNFaS/TKHpoa/qLG8qsVxTDI5gRaGUogiaUBwMBDKOvoVaQZl8skZ9FNg+VBwE vyE5L8k26yHYOYccF0XqYsHnPJzsU1ZNcjrnRbgYYHQWk2vpTzibVC1HMfSNdYmmQBI+6Anh/jMy zHF/grCNVbJMp1glg3aejh5iaAqqtq4u6Icg9ROj9e/LsdUYhnBk7iLKctFngDJ+RGFagCIsYwLN 9RJu8iq35qgU5LJGhLwPsa0NPqvt8JsAX9Epz3VDGBXEESnDOUb+BGoiiCn9ACuUo0GOLDw0HDyU aGeoMf5C53p1URozwbJGo1xgz5EAIdMGrBAyBr7rA9kNVnuBYSVoUnUdsGoYj2RtK2L4aCKuqM1p wQA4a8G+1jQjjC2gZaHMcVhhKbCGl9VWI8q7E/ghIBnoV9ZR/Z4s67eHT2OHWi+Rlt6k5DxC2qDo RhXJPeWw9CC14hGtCNgVy/aObXKgMwphNeiYfysrD3RXBzSrF6RilWbRlS24kWafXrNIusB6G3QJ wQJPy+5mhmSJN92iou5Y+xQ30V7jcF7hEqaDOatYSiYTrFsTWj3AQZvnEMbraJU8NZ4p0yt4PKSc DvbIuiH1CkyDNo36BDNsitBeZWWWxXdJr0Eqm1gyMm9DEIoLWyGRopcgSWnXBTM0so03IiUmGCJV H0FBYF84JLVa+37ZwO5phmViU9rO2qk67NhS2yMosYAREVxqpRDRXZj2fB5GbyDcmCipl47J1+or XXWw9ElZgus1lYVm6kGIRspV+QluINpqywCHMVnhqjmdsVxqjOMZ+RHMkNCVUmTzrq4TQovk8HCn IYEaSkRIKbIasj5UcF/QLWAo7hyO8ob+qelfE0jPYx9ZNs8uL0BawqiOquYCn8dQJJWqNm7TDuSU UUEKlOFTbG0BcTxron2H9Aw8iNm8zjo2vRfFvXUhss12qv4UyBGqsDg3V0nMzqx9SGJGWHaneHqC 65TLmv0+oexEvZHO35Rs6s3P86lY3OzLWloKq1AhemyYl8dmHNEXgNqeIsMnfh+3NyQ4ptAnwT46 bAP50DDR829eqzIIps38PS21SdmSxN3zEVcMZlANaB387EnBc3pGzYo9hQRC83Sn0lhYzeToH/em ExsX7lpK6wsOL7WlccorQON0jXz0VSLZXiwidGpZOjnxzkqwVDiBz73NUcBh4lzq3eYMiSgbwv5Q CJl2Mgd5fWmRC45e9xKdsaF4uEEcPcHSUS4Mj0PoGENO2TBlRsXLY+PKpMkNHWVvJe7iHQVdhHHW PaairtAuTdfiBUYXx0qd7GMMTzN2tWlpc7zkI5ow4zP5VllPwgiXM8ktwio4QtIU+GMOMtqSipVV zLpgx0mf9qIvYdmR1p/XnlqRrEt3664Azy4HR7MRwFBcucgMppMJU1FUdxjjR1+DU/iEIIwRt4bk qgpzIcDClqKy4uGStY6l/VHTIKyruyRrDGDslTQsmQZe7widOrX0EvmyFHM56AlVNtk1Xm8jcbBN gTUgeDkwX9iMvE6Jhb9fgcBAbWBGBbFGPbpoEgIeWZOQyglMsdPdYJ2i3sdxBNwxEZAkfqhmnaVc 67GjihQxlHAsHI8A+Nfpp5yCZLPzEkzFEr2peSUbHknQyZPT0knqUdYD8rYGHpC6LQYM8u3gg6EH XRa35fu3Jyw6kUfYxrGa64P5eNyLdZRlivVfL/FUQe40FJnwgXli5IdGfHUDn3TtY7U0UpFqfhJM akF+4zOwwi/RTEMwnzgm356mt/bVZfFTQFuwhJRz+j5noof1EGYc7o61jb3Zij4pOFgCmC5Ya435 ivoR85GHoqdOOgz03u4alyUsZssOp3aH9czYHufBVCVoBfQzZijlZeomAK/RW+R50xJEZn62GpH3 FMUzYL3EV+BDLmv6Ntn8rXy2vt4iOwxZa4LJ6ZSLUrNlI8vGYbFC2ZKtlLOcvCEwPvgdxMJ7ds+A pFngkfva09hYCcmTjwftx5gghEwADpt95JLTFFyBW6T3vYRhLFthDUO6syW+iB44cXmiqOw0TC5q sBnziLfbMxPco3e4R7HBL/7I7Ca7/c4LDeBuHaKIQoKDFIRM2+2HxCMM/FLrsuiodIRQlsJhBQyJ qsfOJCYzEOvZJArxi+qIKYtMzO7Mx/LY8nAYsAHca0UtoDai1eGVcWd5KKGIIJAtloth8GXqDVk8 fJR5SHDiOiI8VJA4JeKdJNi1SuqJKYTqzQdmda/lcH6BosnxsWTmUKvP9b1AicDf3Bc0Do+DsvX+ /cnRtsXFiCvRhXlYJ+9ej/b2Hjx63JGJ9ToaE3uTSrD8X4iNliMnnKiYk8P+ghxYKzbkyQxrPkYs Oq3wlmGhXCMkKJcbpmCSa9WaLYxT22ZJnNqSQD7BWsBWxMmA+XIsdkjpW80Xrq1QDAm+Nnwwmwss ReYvTVF8eOBRrWAwNiD9Rp6h5sIA3PpxkJkHmZeqMogeocHSpvYJzKpzm4DBIH+BSNvkmyTmQE8H tCJ/OZaO/5okXyHbgd9lWlLokQNxQMbGqFVbQYLsAfDVMES3w0bW0ZdBNL26QAMkgUW++Ondtigz eKd7RARaLIFOlqgXP9JoMXR2bgnA4ANzxP/25SdyrUysz7j78HHHFEzmb79X5xVUlf4+z+bT5Acm CvfwJ5Yt0FYKdRQe7+5D9QXAJQmqN7q1rKPFXLeQQ807S5NB4boeuGsW+lbvtyaVm3gNHQEjozAv MsrgwonxrnuU6SkYBmspWISLR+PH1jHDRVd8jEuV1x+6YZiyT6DAEGg/9ePEgHhM4z7YBw5jmVOt 2CxyzUQHMVgTpVYjfesNQEof3matkWjtXJYUIU2Ekk0k2mgOZaSaCxqDGufRKwr0QP2jTcEMEDeb uCCb4z5pQohOHFQYxhMHDz261Aq1t4+OqnTWgBjzJl3Sxf8CVTDMXgDr7Lt0/vMQzXBs3WEoBzaX koHHY4Z5cydY6jr0c7cJsMvlfGlSUcozpsGDR8mZkxUm1eqy0UolLFokjgVOOWCRzPRDNSznjWhu EFpArWgeLi4h8Bjlg8bDoMUpsGP+grxJpePXTdQIhSmUyZ6YyM5YC81V/J6kdbODHjX4G7wglu6Q QaObypMLEYIeKFoSASjgwiLufqqm9VduAwqPngR3ljbqC6uAQ0Gji5BUTEAV5PPT0ZGKhcVUFRju jO1iVStEHtMSBWRE6J+v78sKEDU4/Vev42A/sY1wT3k/KRCgEB+QGlQ8l1jWhNSUsgU7rzriHQ3w DTVPIpTa5sjkizvimJo1/+kCjZN3SwQg90oST1gUN0IPQFsv7T/ZmH1qTADhV68WZyXV4krgj3ve UMzthO3ii2xRVqhQO3qmy8G+WYMICq/BOfHvIkxe++10AQUJ4H1U7Tb7SLrAgaXnORko66v0kmKa u7/EDvB3dAm1v2t31JRQhUW6gwjO5GNeYYSEQG0JfmffWKkJv6XYSPjxNbM8K0us1+hUxIoqxfZ9 gTPENzmMteCPr/lOwrVBPF+3RfCcwxgprgTpDLrIpu3vwAHhbrIlryCuOsVa5YW3NLYQgDqGx/kg Q3d+6gadB5x1A8FFovZSvITpgxtJbtSX4/VakB0CYcG949qMmvCazZZTBy/ZgRS2JovqVq/GJa7B +Qb2TNd296uOhWXNNe945lEti8K4PMhyCIsTTUsKT7jugbXyuXEShpOSLx0rdXznSiOTUgnwh1/b y6PRhU5ndLoiBhD6Ms9o+6naX0kMKnWCzh93P4HhqeMDWWr+qIxqm2lpJ7afICQ1VzWpdcu3JKEB NZPskxPVMFJi4q4SyHmg5Tp98R3/fVsMHIgCaq+QLS+/U7yaUwsgzIWL0qdn4H35kENB3T6Gzvog Z5uI46YGT+468UG22uugpLAXetvINShWKafdTa/SSgOJ0b3uF2K83dLlPb49oQ0HSRyEni/oW0oi UvhUNEO2wKpbYcimdLhrQZlCRBA3xBTN1jS3IUkYF9mc0BKDOGexP/jQKgpNUUEDMh5Qi+aF6E0I 89KqveNTFZE017TmKjd5bevJmRuU3bHkqLvI4ppdsjaS3mdkRbEGLIzLFZX86Jo2QXtOlVgutMCZ tSy67QSfLqoDkmbN8beKaGUkCQ9XSsA9S1hlH/rH8QohEV4AGoHMQwni5dEDtPzLjEn+UefYQ3+x whDgbWxH0vCoYyPWWqHTx3Vc5OcXbekWmt5GIVT8R2Ct9zFc81Dgpr2NLQZIL8HcfBZH8u7Hw9He MPACLGsKxcy8L8nYjdVB50mVbPA5ZGLoCf5PcUpgHbQkCNSmqHCNHYTpLQmyEB1IPgUkL/C9lMIa F471iCuo8/2h3Vo2DKGmgkmsMiBsVMnqLDNgpCWjiV2k85lsBIewo64CL2BbG4Q7dzqYnksmyyo5 EqO3NQ28QwmD9XO0SYr3DlRERgI35tuGYGc1UjqwCpOh1mTksQHOfeRtpLBiFwDRLsaBMy1KX2oR YAqmkrBU7xJCTFQolQSwqFfitQ3ydXTTeRxSe8yEsCrEZ/jxqssv0Pk4yJWzHquZdIeuIY2OkARc RhNVsa7SCJYoU5cwSW1MA2YAIFKGWo/J2Y1AaRq53bk81FoTFh3WmmxnK8mf0UgumQN+3QNJDUBa PRA0Yc03aBHdh2z2tFCRfrPWdXkdpR+SIIXb1UnloJu24uY5OiUadhoEsNaY6MthoBznR6KJO7Xg F/UWLrTs2uKCuK2cKiZeKrKBXJSG49qigjYBWEBAW35WsaUqwLVE9gqF67M5QUJC2Frkeai1jCgn 8ZEEQ3HtqPWTcu2vIDWV0Zve3fGLkkW3g3lDsngP9S+xyLGiUnZDEktPsDpq+KsjlFIf3gCsCaQp 0XtM+p5JkyCzBToPgmwgWgZ+B29ZukrFVgNNjBMdNlGKYm3UEyeQOKE9Ats41XQKhWvjGDctUgm1 oDhwK4hcuceGimn2aXzRLOb3oHPiJ4ecC4BBkcxjLHyIB3yhiu4q7NSlNwFhwB56bTw4BC92DFAm vcK3xT1hXhe+pjiZV7DpVDEGzrLzvCA+yxPsbvc7+hBobuiLzcftXNcGoB4gV+D3gqYQo4L8QUXy /hV01TfH+CsJwqUcAghvqgVkx90q3znFgJExOtG0rK2c4VjcEaZb14NUN+WkhFRIqJTJdGkJmE3E El4NzAg4FHI8pmIOSJx7lCS3q0tORJAjZPApBN0OuIFrFGPgQC41FMXCnSlYCS9X2UVWTJVQoLYU MFg7FgmH0rzGMI4sHo1Wq3M3HQWKa8jTKiolIMHcHFpLRsEqwxyghIqLSGYqevOqc9K2/MkoC0Pj icF5p3BpDOWZy23C8/HhnjUklXKCssbccEQSwDsj29xBwt1BiI2dbmKLHAyW/+ryEAQOoNsTG4SE vPyiLK2zx5Y7dbcgxhahwdVHjvs0Ak+pJFlwLeWgJREfW9AMlMImNYBh29HgKrE0kC1MBx1zPrAs sVIv0tTeeNfXUgYYI+kSJTVtPgxm6F42W0IDrMCwJhN3QH+GOCANyefwlZ1ES/7uENHgsuxQKGrP jiZbClh7hoDvqdNtttGjozE5jWT+gDNZCo4EGxvdq928tbUeXbMaUh4V2moNO8Jttft3T3Z4aFIT CHGhSc/R5ngyG70EnBSt2sz+BK/dYdY0+WoxCZz2pndTbGVKCrakhAfwMiHKNHqeiBKULGup5qvn 22ddjuB6JcvXFGIBPaka1gFEiQ14wlRM6nCcN9HMfkLaAHG1F5A+kMwMEJKa5DiT2EdVRiD+5oGv PQAfCiCtSXDzYp8AZIgaro/DII921OSajMSXjBH3NiMLFRmV/BpE4Y9m4CgSyqaGgrl3fOObilni QxbnK7ZF0inFSxYQjdz/v3395s3h6fMfhywMEPMcJi9f/+mYhBhCkMKIcwJZK33AYzYN8rnggkbG r0Zomi81hKgjhYnAHHp7T+7rZcw1GKwjIQ6soiYkhtSUGmNZDIS5Zrbl3naj2SjESjimzp0yjaKJ OYtf/Q2FbLOPSEG9Ya0mmFRg3ih428QIg4cojjZGKhB+DbYftqqc+zgIpGQOWDNxWCauRYxhlvuQ Pd+mny4RgnJGBYQ04YZ9mHZg/mxIRB/YaY2iAzKZbMJMczsoQkmrttJNBhenH8bnLboHjbZrLqBl ZW3xUc3KSkIBhj3Y6jytyFtWeqlYeQtDg62iEHxuii/lXnWm62JIYDhksaaTNEymEjiYBbGifByc pknFtWribK8LrIySTm0nKC5HHRt4QTCbQIKoZqNgSwadgZN72WhHw/OrhPgKn7Mpr6CgcicKGZUk soV+HKm6gYe7g8a0YmmC+4D0JSLQsGf2E7QASO0cwoaGicHSpfhxeG0UvoTNcKQkYbQykzjYPUBf TfI9hG9vw7E92H2QbBGnB34FbBHCrLbVeFKsPLSke9/WX3DnHyB1gZqQSyPHHQrUJvHr709eHdGA iFXDArPMK9Hs4ehp4ADqC9X+CL+BvXkkETQISoRmM4u/fqj49XNvtOxqWgsDGJj2nDA3ANMvRb2C FS9fjeplWYvFvdZgPy09IDZycTecZ81vgxfIk8O4Q+QgTAW2t2OgqoTbyiwe1m5MJs4RUGooEfsp 6vTE9VFWkVVGa9l1mfDaxTDeO0FmjtuBxCJTZrhRum0xx6N1kWsAdd90A7sG2ZOaVNIRzAeofhFD UT9QiTnsmw/DnJiQUwaDmECGm2QN9I4jCqMJWsB4amGWku1EKv7QcHV7cPhmqfNFDikfvNAMjnCG sEKds8JI99yj2IfzYkZASLzEsFuTuCmLNLWaeoXAMgQCx8IQJG+ZTP5kcORYyMXTZHcg05df8gKB KlcDUTnx8lfQLRJ4xTcLe19pKVSS/E3NEPG9G0zhFaLl+3zEmjKWEI9atL4hmxE4q9Hbe6FynCc6 hAQV2cjD+WLUcrgXWHOHkn7YOkGF0djo3Ak6n0aiC3jEDa5sifFAGHCHuqItRSiVbVYoEMuwjaBs kyMD5BlQACU9yYO/osxHiLVsfGxX4vAjbo+W07ZkqVRAnKWOs+RSSFOWOQ5GC2kr3M8+qJA8HI12 nXP9v2kM825gDFtUxLlZqxCwV4MWWI+Yr2TiWqFrAfncAr7k4QHU0+sHOFSBShYIF4fokC/x/fvJ 1gvsYRsP8RLcT9MOfhSk26IxLQARsx4Uor/plLPSivXb20GGAsECyk3AesR3GoH2Y1fMjmyOslFk TSwvmbTs9DjFq2cOuKlGJZLilgEISD5Td4WZyU66c4ZFQgIaltgF7W1nAu/AydGyBvjlhJbCv0c/ qlPezvvWOhs04vaZsbSTH9FkE/vPOJrunD3ycWIwHi6w9c+z6XnGFW+Zcq4kfMFoXpj4owpc4akh RDlpez7oJCC2TjlxZ4Vq5mC+xOEQArWwNg2M1f2zQazoluLTziz0jXw3pLiEqCUuq+FnaKJySAxX 0BWIm/YjgizX0Nhv6ZUj2M04BJRL5uvB0/HWBjYvJu1Qo4nVXXPVUA6aZtRL2AJFfvGs+YCp6R4B fz1Wi+enh/cQRWdKqCBDggGmpAqmYHHz8MAtHuUFqW7Upzjiz6wtZyhI4FeKDYm0JUa9Jiqxgzc5 KDOUju4uqtQPhNJKEF45nZdO+ik/mXLVfGY5Kpp3BchcE9r4ZAfbYZHg4CBgOr81P/qMZJ4pme4p +MSaz/PzolSDYx1SkHirqYHQgEHFlgmJ4ue0496ymWMGxq0O6wpbW4kkP2pmK5HDyuDV/ZxZ/zYL sz5JT/LOomNsI/JEFF2kseGJDQnWFQz3FfnDyU4SQORb8ZgYNrFQ9ONJ3Bi/IvqJLVgK9ywPlK6c qzJI8xW/lS7HUIPC1eOvrdNNg/slD01fa7HaCO9ilEQWYa4i/7Xbu3RxNs9oV589Yw4NZej1wdda fP7f//L86PD08C/kaHz95s/Jzv+HOSKOxHa8g1f1cBZx6uZpAni6+aQeLyf5OJsuSbTzc3hqcXfN ewi0W+/Mdjq64YvjafL1zb+VENUk2fo6TjSbPd6bHszSbPRomk1Ge3vT3VH66OGD0e5uujt5spc9 PJs9fLb9b//jr3999vWOrs0OL+naxaVU9U1WV00Z+7sHyasSvPUAZbOmV4tAjOiATM5oEuM4hA7K janWiO9DD0toDnIH5QpRGpE3PhBGbJIrwIzDnjYFmqQiHHTzILXRrYJJKE5BIVQ2nwxtpajWIgAp UEsoXkRJ1nD1SulQmPAEJeRp8jFPA2YMQS751Ce91pPyUv2+qNSID3wo7AsVqTk5HAEInlyj6UqL p32eW4e1W7coO+BTCHVbPJmSAlp8FCxkqUyTTJdUX4QgnixsBgeMa6G8zIPHmnhWu1aYmaVl1LBn tyi5iQYztsVYhRH4c2aUyKhbWrXWRWkVvuuQVDucG4FjABZLtRYUCgPpObRFwFoB19fFMAKeqkRe sApgOi1Fu5MC1ZLlticPvZf/va7K8YtNzOFx0X2wEEcFCXE8Gj/oLmqHk6ViJsGQUirV5lHcb7wl 7e1gxa+1Jam1fjJswjiwgUYXrjUfdPdu9RnC6VT+xaNXLVQCdu05RdkGF5rRycyL3ibRCGYe2iA9 l4EPuRwZjSGkx/Qc7BtYi8vSpU4KWZNwYUQEwy2rWztsdvfhkMAKsBGWhVpM2FY1COQu4M0R22d7 +bRTiLgO5mnmJnyBbuo+/yrHcekRYiAGXfsOKwfmizMCthXnpHpcLdheKWZE5IzJzrPXqFLZWasK toKFpJKGXlgKCRGKm3zKVMyFgxQYPQhlPAw+xJFCTozYVvrsPRauQqEqgnBFKSfkRyS1Lb1RlouH 4M0qsczYhi0zq0kqg4p2b2Ds+eAxyNIC48wA0EUAKBgKeoWZWFXd5er0Sy2yfZWN2oichz45Wwut pckp45KZGnpCtzzK4DAbDCaIfoLeoxYUmENBdolPczUDk4zM+4fhrIEzRiJXzJZwJ+boURlogg2u VuwikSWRuFWZgoShMMQ8RRkNyQED9EwAr6ilxROqzdkm3mMCZDpMaO4WqSo0niaMn4tsROGRkFfK uJBG9PAFTUtVQkxbieFHrlLFHYF2ejyX61kIykkSsgFn6MikRxwK+mEMLePNNGC4wzbEuweH+3+/ fCHFdWhSwN5k7qJVLdKG4ymiwqW87/yNdVBJ25dpVUtKmrejagu4/xHqwvHzkfuSYCOwU2gHj2Ku eQtCH0yiOmLFCgoP5VU2x4DwBYGrm7omvOXUkLuIRvQW9pkXZl3yRvwsJJJcaK17eYOOIjZ0sLub bH2XTsVwty29Sqgu99rTo1l9lBdycykweTkO0+Bt4k007r+TUpPS1HnERm5kjbBRTKYNuDCI+3MN PDi/cwmB8XFqXaQofl/HEIuJo7tvBi+PT398ffSf+oCo8OscdhaS6uw37nzSTzQqwtdgcpW3ZMQS u1d3hRCUHaJUWAkbHptChO2yxZELgqPg4urI6F2Jelvfk4oKttAPeLbZ0q7HpT2kPCxw7I/ORbtu M7otOs9meB6tG5iMf9E6i7EEVhlTIoAcGX0FqoX4oeztj/cOth0fLsUAmfIZVbAW2Z+gUiPhr9Ir rZuu605H8TW65zTzdrDrhOnB3kB9qgMv5vK7OsXIT2klT8CH4RWNnUHjJOmu0mLTIXDNZCxqzzJj kdJ7rrnvNJB02LkFXjrBmVuplSImJg2X4k07ZHtZJ6QRgs/daJU7N5xlOiz2qXiaSNuWmxhzLZUy M4GgWtLCCg0nKpbYCBvhnwYLUcOdKLRhiCQW/yi8P6Uy6bZ8VQwCeq8OYz0OY8wzBjzleCNdHFv1 lDGBF5duBLp19oVAomvYBR7crWLuoTEiGqnGZwmOW290xqEpGROQIAlwiqlLUgvhGSKIMwSJEhPJ PjU7nxZzXLRLLZWKP7HCydhBKaWmsu/RUIZnRmEYrOQp87pz5C8XJeDo64Zj/MtlvX6mFGjBlchF PDOJcCYcrlE8YvdvfRPGEuyGAkpHVbrHVA1a/frRWInXsCHNlzJGJ68HEgIbRDBU2FjpOTDziFmH tgi9tb0rPRQ2pu/H26DOZtmzOPiLG7VFeTTZRUIgGrAjoFLePYx2Zd7IcOHGaD3oOG/RFLsHTz5a CK6kD7EhU/YqiCYoPcDjFO8DYHCGpxynmABiJCbbE45GEbOK5ALEEfsCkvI5imLeb65mK5s968uc GUGEyQl+CZoVczBfhI7M3koiPy7nZldTn4uegopVb0MWM5tDwgJQ4hWhBKD2zXNxQ0LwYDYSGxCl 7ip8WOubeBJODeUY9xfgW2x16gviUCpHN3BTCio8BQalnUweT1DtTWPygIQWrWlX53MKvuBaL1OT 7B/W/A7xpQ1nAgMY3V0sBYNEDUlQAIgx3cgf9NbzoVcpyO1RhO8dOIiUOpIdBPLp8QpxlUU5z8Dr R8Drnyqj/wqhDmvQqpbNbPR4ELz7IivOQYb45P7AnN2jr38PdwFDZH8z2BvvDhzxTEpwAkkbye9p Sl8fPVXZwX1V1E+PvhlAiTkPmkRv8NO33wzaJSJ3zspPFEa8o5/Rt2+fnuXn7ulO/DP5PFs/H7kh Hr4AZ1X85C2iEOjPX+/QsHgWO34az34919Sj5CXw29E7ZLjBtpz+qlto2X7vLsrxClf26Cmw02cd m0owUvw8+gYWG/oLfr81uXQQTs9zeem78hOs9DP3X0qjOfx6x//a0/bONY0reV7TOXCOZ38Y/2Gc /KG8KGpAOeIf+zvuazik5+DJ0VPa2WeG8naT13+ET/hJsDs7PduzybY9C8+gOXc3GuDB7n1wyZzl U6dd94xTvhWyNPUqnyHPx3ioSLOXikJ6uetgbfJ6x9p29XLdqtnvOs5RPOAqQ90eA4B9lTKnNlLd URIrxx1tt8YED82RXsfR+tzeevvkdRRWDeG0fYJgDxfg2nGdSqZ4bWrViUijmwH2fGXFLBJpWFcC 2aelWtrC2tQKmPAhdsQ2kxmxyWB9RIG/ualvLbrBNDfxTr7IQYiAznhW2KQbTTVVgwBMCCO1Io3n OpOvFzveS845skjX0VtRVUAv/EVlEJafs2pnE0mEDRN7/8A77XqxhNdx54sM8IvJAJ5qvkgCazrH S//HdFrl6W2EAHrh6KmARAKEybqe9548eTTa2x/t7p3uPXp6sP90f2+0+/jp7m5f1xs17QYwzevL eboq+qeBf4SxRWbuzo6vb5LIEy8j2MBnsBDaMAkgwfPeVoJEqbU7d/QU3dROsV6te8++jMEUMDbN qqWh+WcbNiRzxHgA38aaqdHXOxsO+laTo2Tcf76ZoSy5fnt/WUn6Gpnw5nx1Vrm/YlDmvxyH/e4u OOzncbvHT/cf/aO43Y+nTvwNxObOvjdieOdZwwb+OQoA6/o/eLD/oL+7DVsK+rzuRKLoorHG13S7 nie797ImPV/X288/r37+tLanNS1QF4CpLMGz67p6CSSxGiaOmv6QFqMnj5PdJ0/3Hzx98DD54eXp 2jFs0EV0ke30v/blprr15L7cVKal9TfVXZoVyEP9sfzQE8Cx9s4Tp1gQG1DOkr1hsqBovJbqjp5O rRZpgnkBVAfgliCkt4LKfVhxNLBVYENirzCBoujjZF088NmZQQQec/ZiSJI22zu8C5i9LT1BLuAs 4zn11kzWea1fP7Az1fmnjo7YbOLWJEIwXCsa0BU9vP5F0lyGEFMRXK6M6uN+NdcevWZZIe0O/Boc jY6FQHT82IIERiOChxp5OOuOskB79zniEG1DCBEUwDQIzVIUrcmGjPAgsBEOk47v122tuxvEMZkm CXEZBkvEo2DvZkIES4L+y4Hu7wBPl6Tfu2aPson3sbpDApIQhsY9IKXvzcshBZ1hUYOfIWPlceJo FWDBMgqqkGtty+7a9pCzxwUGfdDW6AbJltlS90UrZt6HAINQuGX3e5s2XLHTomql2JIpOWtzMbYC Ctn+7LPi5WtKMc2LGBYkBBi5+bFJtgT71kJ/YUgRvTCwHa4SXpjWEWodHz1TMe0No1/paPFvICQF n1qJ5TZH0h67XiL2yx1TMdsViZIDKn5IwvzdU3EgqceETMSn8TW0svA5yNkMAb/VOvUQuv7y5OWx VI3FVgYqKA/sJ3oCDHgfjg8lXXoVdsu9I3HayPY0/QuyllhSdWLqEgKu9/Zx4R7jwrWE1q1ou2Vp JOIpOKr2ntOKEIIRGsQzrD3TmF0RlyFWzJpND/ZNbegSyBAY0VNvRF+hX/8fb0j/R9iCQ8t5bASW lVOz+X9fo3nLZB6vVbdZZxNjeduQs8aMc5dGnF5tszvmwrxgeWrvS4aF9r6zkfIbcIGOt4guO37v U4w61aK2UtQy3n3uHlvD3T/fbt/ZZsY34AYvrt13vvPWPbc32P8NRPb1zh068yOl+waefE+6Qw9g 0uHRj5CVJJYPb9teNVlkr0j9JY0Z2znzXvuxqGZFGdoAqCRVja1jcUnIkoEC6JwGR4H3Jn/A5OR2 jSYK9DSJ3Wbd0GAwnxNiYVWeZ8XKxCvqmNuhtwja1fiEQMkL9xt3A5NIv0pPeskGyvk/nxa/mYrm cSmGFkZSbUBWM7ZhxaLP3cGa3WQpNtLGrAKGGtkNtDH9dv3yeg5BgErTbIEF0rDuRXOhdcfhzPrM brCPUrord0TJ9nSw9DU9oajG4mU1MPVmNSqLd4YVeSi8NM8n7uQO3AGqIFd1im06XQdAhPJP207P ahpBCfCjYvMeMQrNsMGsTXcynQA3LyF1UHKTAJCBirHiY8lYkph+bIai+mk8ULStkWpsJsu99AHh kCqMyVBg1uGEMTKmsS6PkmGwkEBAn5EBqvDYnXl39ORZZ+Idf3Vd5h2+JiHSWlExCcoIBsn2sZ0T M4YwDAozSXcEtLHvpN0sfa8jI2Zd0lsr4S2YnlAxQ5lTbcZgppqv6qespfICwwyVjBnCrIecDItz DpLimBqwOoAQQAK+QURCJ6xsPFFYmJOyQ4sgZj2HPETI61k6vWYYo2NEdaqo5CEAR7Yz2fwycRh8 q+ZTRuAAQcZ2BO7cybTJ5L4AaPNznz+Wtlc/yMzoXk+7fIi+plsj2wVDpIR9AJ5JTEuU/hDsJuVM cIL3Vj7OxkNOIKCAurOyacrF9pgFKfMldsGJxykBdfjAyArCIv0PYwErZ8a24pwgHKEj/WVlipVK GRltLW91e0bzWRZT6MV7KKJsJyMgda8TS0FuuedaYWIGaUJyivFQ5pYQ+QwzMdPptOOzZvP9MVrO +9InSFt3os+UcYo1KxQ0+i2r0m/3J7DDDgruB1WJ4eSiCbYLC0TIdFTFj+DHaPk4ezzt6M83M5MC X4rBjPj+JAoEGP/LAkrE2EvCrfRFDsx1ipu+v3N/52DnwadPkLIn11MwXikvt9HQorMGOsXW6z9u JyNcIXewF2RYQxRCwmeQKty81046yj9h6ViohJexWOy3t6YxwIkd4lj2kq3nZIGFopNQFTUvTLXJ aEQQtr2lcds6MCo+hQsrtY9MxjklXdacdWlcHauhVN4h/HvY2ZZM3hrBEzdiRgwMB8AwVVSKTZOI KajY1++QnC3s1k9UkzY1SlwAuSjJrTaFF+HEAIbJiH1p89Wa8VqQVxqtv2ZsLniET8pTInZEh7Jm DEmDBWtxxdDezICgEbagPyEeMyPqSCKfOSc2j1PGHgDVOp7jY6LfNWXluL/Oija7L4IaRSK6eCD/ cuI4d7jcN7XyhqLQHVlw6e7acRrAWqA+0BImXO/kHxf7bK7QMJwXX6Kf/k9gP7q6D8PewUKEaTWt d36+/2T8YHfHBgC7MXfFl3WYQP4P2ws7sjbkBYIrefaHfAG1MJoMtPivd/T36757W66S7xmccN1n 8KxrLHH8BAZH+PlhGA5wxc4Ju2E8Ly9XGPM/eg3HrZ3jQiEUvgl57rfmv5/NfF2g+U0p83Mj06Et OcSfHTX5TAmxvml20/5B8r0TwRybPeICQ5PVL5ONtQGRrh+qu0/lOv2MEXamOumIkteMWF7gnXAG 4qdT71GeJsEE7n0nyFyTgPWLRCqZy89UQ9OLjO/5FkIA/LABS2XC0fuNEZ9LlhBRb7T33yZt+p3G VnBxAztMRAq+8YkiOaPBEpH5AJI6UMfYrTzh0niC7Q2XOxD0VouiBXoAW0FhV4SoePZQaQsRNWva hJQudRLjtY6LCraQew5FtDIOoJFmFSkadQqch9XT+6b/GSYYKj/yks0nkRUGH3ZYYOj3tdYXalcV fYWes5UmgnI4bPzgJd7AAGJ7WKOqsWBktTD6kkZSt4ZiIuoU8IzSFr08y2i0sTmno6bKOvOPgMdA HiIWOFHEAN4VA059RIo2PfBq8FCRv7ztR/EJbVfWmtxZkGjISmDXxGADBzsDml9RciUddxjrBtFG Ae6AUTe8NQQb4tH/FE7Mw/FfuwkcnAKImtwfk4KgK2Lvwz5Yb19H6gk2ZDQqW4giacGmepAbJVom zbDuwmRnirUXFumUvQEFW1aoLENRVvKiLJSusJqXAI0SVypURXDVtD6QuLs8rJIF62EzcnYF8IWk 58bjZduY1HRiy24LVIk6jE1foN0r8EhgEGPOKcBQHmAmbEjRGNGI5t1bqBLmC7Q0yFJrEVdftGco 4yX7m6Vb12BOBhR5RUyhgcMrcnbVQDKyBnpwIxQ9DvELZyIhTKCG5k278hWYgwDsGa81wbozBhNf 3GzvQbL1vvChmC+zaZ4mIMPG5HmKAHjuNmEHoq41jw0uDsYiMlsHrcEwa6rt5ONDmQTdr77eNdZi Z9zeCIDWMYu08bWxN832tVYyy39F7OdSuTGlKDSgApkAJAy9Q7UxipHY1hcER+fNHi3LkrX7iHlJ jwRUgUQD4LIKEHxNuB4vFvBMwkfUa3adrQjPq0gCWnpX7D5QQt3RAVon66fJ3rYxVJNxQWgKy10Q 5bJLjizmnor5kgLMHxqpXld5gaNWPw0yyf1tksZi9m+9jJbzM5YNFEMXE9YEa+h1s4/e4nwjuXWx ZDXB0QbZ+GzQRal5B7YYe86MDHCdgewwKIpEg4VyDelUr3I7syVUh2PDFtYDXZRSxh5PThNyC2Sb iGjAlBEPZ81hDg1HXZXyrM+J4ymVWd7UQNWDBek/YMsk+/2MjYo8gxHWXJLOmoxu1yz07bD4Eolg m9q1rHDZ9uN6wSDY1DkI5jtX2RkUBdz5BJAM9Y6tNMCLDNoF/XVcVh758y7MZ0THrTH0WND8IH49 +8he8lwkgN4uN1YQfjg+HSY/Hh8e4R3TU0aPyFsszxCefHyK7o1lQbVOGY2ZnNutEmYkEtU2R0Hu qtTd/AOFsVPsNAvNuMUeH/iFzvPMRxpvo+i0TgofxHi93z/f3334mPF6YThaVKpn+BbQmrW3Rlyk biADH9UxEDGAMy3S5GLpVm0EomwK8JEfcycGK26cbyaUXXzhxRIOHxZFn9cQ/NCU54hMNqaoAA5l 9uiUAuLMXjYF/odpxthtLAyk4BF0v1dVxvAtnHnEN8BFfmkvj94Kd++oSCTg83mkktBLh2SGcLG4 7EbQNXh4VvYc8qVpKA/bINLT6PGI9mLBWJXMDXkYVk9ccxrITkHBGzI7zLByckY691W5uXgVUSU2 KiDnGVxCSP9Mr4JpXECxBqhLRfW8Va71MHQRhTWhaE7dxGfR3nN6cfJiYygZle/0xViC2l1zODju sQqYUuHa82SzPziA9fsTkGHPnrR3hepDtmwY/HPnRnJJSdjKV07i8NvZKqZsrR/SUWT+AKjK7ja2 1TLCWgb3660jtrJjDyoR+fewFYVM7C6/acWZQINC8wJ57LEdHoZ13guhMTQ41dksVggkKcapzeNb SL631BVgfFJgo1ScxPFveALNxrXP4EZ7ZT7bDgxX4d7EPPF64GJsyIAXo+ELY/DGa2pidKBDsxbN 42kzZywKIXUHQD6XIUR8lxuQUIfaXwKmuVYQVGA7YnU6NRWQ40sVNI1eaE/vlmUBv6tswarPapaa 9oxcLxZ2pGpBG+arkj64V8dGI9Yq+VN3EWFJclORluxxXQVpYzuJG6/UZ1A0XtwUXm8BzBW2lgdR PiDErAJWzcXluhdI7WchdYI2jLZSXAjTvAf3x2tey7rqfGyAY38JCQ7y8cC9jB6L9i2tv9GxbcQa 2pTUmGpBFDqiy9QRLkKhS30meRxiHQGfcp+mLbqRuUE84iuJIanTGdxb82zWUC1EU4+MzynKQAD5 yho6nxxPVmFV2sD9IASqli9qk3ddDEyy1sJdpel7GoIdVyfZJ1hk68vsWQ2F1G0vS7DEpDVCPIuP GZIAoJzAz3Hq3LPvNfeXvASqco0tW+B3vR7oL+i70M74gNwoOe2/md962uG3nsb5XtMeN/R0AyAf OQ73v96Zdnikpx1u5PsJhQ7BF6FnFn6JXaLT27lE6ZwRpDuwXTqodHFvNC801rflYKqVSFclOAJs oU+UBXxQkqkah6Q9biOYUzvxKK/JncDwdxrdOBTCmaEBLzMiwA3bJ0kN3BUEQup7s+iTbFtsO8M5 zFCSWKj4HKblQkNoXJP7L0mOTbnKSDy64OpD8AVfNXQDD7EM3CVlL4s8hBol5s9MAxbvxe+yaOXy X+tKvU4defP+tB3V7n7r1ijfn95UC8H2P0MFOcQCz171xLQfX3hQr7Iqu5ynE86fAHU8UMLZBxKZ Cqm29TVh8RwoKtegE1/QBsyRxDg4L8iAXCvoEih2XOVg5+CKn71Fe70bpzwv8p95FraARFQGhKwJ bOmXUNaUC3qEheAdj8ZqwtYExdUmKFFKXE+zvHEtwAeXmLKR1v3Rk7Qr2MwVI6uI5BYb/424oRYS NU9JlCekeQD8z7TD0r+Bc3RTQ8j7PjvI9ZTaqYAdeqrhmesdIXgLtA69JjuyeODIqCemM417SaXW lSTSECWDOOikLmRSUzZ3g4F+LtKs9fMPxMaDDL2uZWcU3sAdHvJuolId25toh/OFBlvjVW12mUoy OkZIDQd6AurxeR2tR46ULRKiGv5pMXkEWHZWhku0i7snLtdQwaTMEKqpfkK1zr3nOo7ukE3zAR5G 6ffEFGszsEt9sQB9ZhDR9NaFA3B1siBoYFr66ib+fl0TL7BxrECoxklUAMXVatFwcSfC1ko8QFhy pVXetjs44Ga3ENbh7YnugWcdxxV/XhvbY8sK+03zxYQl3yIs6Ty83l6kxZJtKdfrvsf4FNaOzWck KrDr3Dyw9hlRPvmwWj97YDRtwkmzvhMYYO2dEk28I8uLoJs2i3MyHY9Zg+HUDXlLVEe7L0pb58vU nfuGYbzTs3yecyUSNPxersyFElUPVsc/KKJVuqg1CqQq5yFTkmXAyqvs80J2nvJNNpR7lUVCUzCL 2WMwEjKFqiubMtcuLzOnFfGB6uiwX9vElYFl0uukikSrkDH1VCOPalZbN4qsv+Uqed1xeQNviyPM LLl7My95Y4FhKC06lj3hynPdtAZCBl5s7hZIw9JksB/oyU1tHWxcGV8bfBinrVvXatSVnB49+Crq 9R9fn+NH3gTMNBE7Whqm39dDkytlzAziUsG7y5GNKXlA1dB8nGhWfMyrsqAaRo1pxI+PZb2orqyU kmRH+hIJcub4Qim5sFQBnt6SqtKSq1jaYKIhh8vVfADrjHCxogPECS1TnlYFSZP+crz++JAVEC5/ 5cOx7yf06rdIj5Hilmesh1LQMgfJss+va2fJSAYDoy31wSwRH7yu8eh9bCdqu3cQG0qsygiiCgOd +XnyLUk3NeTMRUfDMCxJt4JM77nXZ1I6YbqR0WXwIg9Tidl+F56qVIztpIDQlkKR+PxjC8Gtg6OY 9T+Z2cJvoasPsuFdZ9Aou4rApk/uhfZRHyal08AaKPY6wr8NE5/8bkcLdubpMEi2Xa3jEzGbwGOM +p46wqUZpW2bWNvO4l33OlopOEmP+GoIsmhXpgSjMcT/zdykG6mM7chzHm2ir8kubHa+ChoKYlVV wOMgVqx37v0xUguya7O7OrqmE4RitO10L0seKGI2LXb/pidtTciIFVi6HFymemh35VDxkbUqqxLZ 2hqqto5oR8HMbj8cDooOcKf/LajfSvdCZXq9UcnVrmqrwWB86dXYdkAjnLHpy9u91rr8buDG9VoM 0RYfSxHPPkcwHwZgM101a/3VqC5E078RDiku5SO+I0gn7vZcVoDCB1VzLioyIsJRdZLzvCOiJrnI HYOuJhctP58urnh63U5hAOP61WU03vjEgj2L6qbfzI3KVuVoITb2STIRf6ZPklddbdbZJ4gA9UGj XXpXmw23X6J1DMsm2SvBBB20TDAkq5uYERMeHm1FsMIqnERuSX+S7TiV8DVUBQMmZ9C0tuQoDQVH G3gLv3uScoJPqXWxpePEZIDspIwEDd4pWR0aEdvjZ8sCc6U0nTkcpnVeyKtnO3SNo/8xepaCiYKi 8AkUBQPV4ZbAlsBEngZduIVpNQ9Wjh4/teXs13qp0ZegBpJeR3WXbLMF9ank5nng9DpLL2FwWadX H1zCqk/nLdc3iaAXOeIAk6ZhY26Cyq4+SktDDUipLcJDFR/5gHCh5JdBGyVUD9+097/UH/JLNgQu z5oqQzBSTjoj+6JkWsF4/XKGAQ5jVgkh4GzS8PRwAYZ+G72FjqXTplqJ3gELXKNyswAlhw9fWeXn OS2QWwD/fWpCEf3c6P6lpWO0MbfBYLzzzilqCOMOeL61nIRc0zjEgpY2BpG6nmDEgEZj4uxG4AWC 6frF3uZTOutyKBRyqWZ8x0YTg4NkPCqxwdcdt2Fc3thGRVGqEJsGJzt8N1IzQSSGECF+gHi6skbB wknUOy+csJjJzthGYVJcN9iel0DQdvc9tftsi05jLCaSNby0HWvUIt6AhG5MPqFBoz9wJS8kVp1h 8AJJc01Ui1BQb2TLRlEt2Mo1kS3x9bg+85SyTtdGd2BLa+FgKNnG2hOx69oPHMM/sSEfHlOyy3pd dIwXgQQ2UCOLu2NjRKQIQ2O6w2L0oiVXVjscxqT47LRCVMz61ZYC40VMaynI6JZzzTJS0hIFZPiV rDm0CCp8l8MowKhjBVcky62Jndk0GBkHIULBa3fMCGH6R5QhrMJ1ErgOOa+n40ptt6WQlKSenA6I 4i8r0BrdKWbWJ2cNT218HfI7TBQcpYNHsBVBuc46oJl62EzHECmXvUwG3w/8ufQsBCm215uyeQpb V15ZbB+liI+WZk6U4o3efnBkTfY8pt9w3Mpyi4j+RgNCdYoVlWykkQBrrGzrUZJMPZJImq+F6tFs f30+l+cdGvWpYmKLcElwhaSuu0ro2k+23kAIAWfqMdJFhAOEMb6FhApIHKmSKJhtCjjTbQxWsOz4 zV5njhHLQs+xRGKXYxvkcMXLEzo0KOv8ehynbqNvKhFPrfw0t27fpdPkBzeQq3SlCZFgviZgO2X7 01DXQu7j72GT9BC/rAEes2VNtXA4LdFe2zdNnOucZ5BEx6aiEOzpZkl0LFxGiXSfm0SH3B/ZqNJF b0qdExGvfE0WqzFCsBfkzi4nTiifLnf+vxljERlAWq5RHFiAiMJF7e1pDIpX1zuznY422eHq2BfF n/Tc2wGoRtYRq9Tj2gESLXlZXKN3mgWIC9+9UD3hpmZN6A70I336GWv364WtHiR+XzbLKNyUZl27 PWRr3TAh/arTN7o8iTxVCyNdEMxtarZqcU4VFSCg59ALylD5ZG+fSLLzAsDSRiw3WrG415/BVVkE 5wNZxP9t5GjlsafJ978WfcI13bFJd0aoKHt5H8ZdxanTht20FHn3FkmcLt6cUbBuJFxT3/+QoPOW gNMbef4hyy5TEJye/RZivf0/qamddlvrYsD/+wbxf04Uf0RDb/d3Ng7i7z6I7Yj+OwnpJ49CWDBh WRQZKDcA7pyKO4E0axsGof682KyVsyC5JrvPR6BPffS5hvWP26kGi7JuYmGwhigbAFiXqykayJAA wVjUshrbWIzVsY/jLV1XFIs/pF7n+QeKB+FoKndoHJEvqFdRVERpN3pK7LPawgnldYB/da3OwqlF 3/nrsSKloWVjfLs/JMxpt0xv9+/VahGHVTB+c2+qh9QKTnjClWJNimz/gIIrLfDcVezGfhdu1ov8 Z76mlwC+jOgp1tP9ePx4fL9TGr/u+nj5+k/HvXhq7lkXnBr8vB5NDRr1sg46o/sCZDnqbF6eQwQG zfu/lvnHdA4aC6MnOdFpC87BtsRY0aYazwhRSFZABK1QhIKO2W9SyRwJItLA3g1bkyKsWZVxOovB LvcG87QpFxQtwgpBzzCc3JRdUjvQfYxiKCYmwiMFUybm3jKtQiqzhmKRrQDeE8hytE5EiY3WxkvW e7YDr/pi4oY4jjIvNHQFrDY9lhS6DcKkny4vaRSlirvvRgw0wf5ytECinkyBzLg7+BLyOg4tI9j+ IFiUjfdqYUU6U9vwjeoRRMMZr4lTNb30xKnSJlOsKsUKQrZRFB3qMQ+iKDar9G8Q0EqwDHONbDWx gAAs3g7V64x1PQVydzPMrgvVi+cC7BhB1Uw1jla4K14XEibn3jP2kQ43yAZm3uF6hUWAwMhQi9bx NIGAxxHFYslhDxlTq4YD33pNlQvm2qxTFVsTuos9rI/Ys5d7HJ8Hnw85GkLuujCczF53nTfZUE+g 7noalg3h3fBXx6ZBUjq5niCpQ1rgHjv52ggU/H59WM8ZcUWN54HfYiCAWPFohe9sEsnCfKEDFMAP QMxIdRzPY2N5mKhuEc9zGvGfOK7rVwJ4UPGTDtD14A4mqGzToB+SRD4v5Ie25ZYRP3HsccfdltfB oSI5DA+ExNJDYlArl6gVb2K39C7jTbCkq5dqWk4NG39CRmYfg7Jh/EkYftL2+VP4CSMA3yD6xFw2 BltjbfRJJsm8ERtpxaEEMShZFFPRE5BC69wZlGIDUkSBmqRQEyiNwlMCSX6ogl1fjEp3gAG7UzjI gJaoMzLlmqgUv8LdkSm9i/6PilrBsUaxKnGcCl3/N45VaYdNMcVuHqoCW+Y/muxI5fqNAlbkfERq Ucjb1oarkIJgdv3G0U4RJRqa+qfGWPmHRaKE2gZForBaTwEUJFf9gmEofM1tEoXiRcXPiULx0SO0 ctjS7UJQjADRHcfza0Wg4Db+U0WgaNGBLxEoYcAH10OgsmtFdhUeDQt73JkedhcxJyrwfwk5+RJy 0htyIrdg1XsO/4UCUDYP5yBtENhkCOTyy8Z0WCMAUdBtQjpO1Z8Rwtd2b6IWRqFzYcI1JL2r91vx wXiySiLtATGJpBF2P8D2oqTYnyg5DMUnCkGp21z3bmGlYev/ewSUGHxq9+AFE9sdj/nGJ+7uffy0 pb+8jz8Mu0BB62my9XV5mbqhAotEBLKns2zv8cFsPxs9zLLJ6GBvujuaPHr4YLS7l04nDx5mD8/O Dp5tq5e33UB28OBgdn92f5ROpq6BB/vp6MHDyaPR7m76YPJkLzs4e/SIG/gnCzG4B37xe19CDO4g xKC1lLeMMHh+gwiDfwBMoKm4akqKJsVS0JY9xF/tYXvp/mBkPydVWhxABDTI6MI9y0yroGS2DbJD skF2S7ggyq/I0coynWJRNAHCEWerK0phdFUacTDGLHT3ZRjkYMybxpy7yT4L2CiGu6aFcVt49KTg gw5lfeOogrAljTDAz4NnUcDBhsEGZA9aE3BwfbBBy2t033X6vgaB8xwRMpagPjYC8UVFf7OPUONn zoIs4IV8zEmTAphkKLaQ14tudBL4B5wl2OimdHoJwi25hUPEs/lKYMERJwwdtvN01QPJfV0UxIvX z//YFwUBzzqiIPDntVEQLWSOOqEaiuyaw06F3tlhr5XnaGpQGo1QBai4MAFPc6l5wHBSU4p2wbYA aNwcKN8zJjE3UfFlNecKTJtQRdwMquJ4fKdsalPfqhmV/ISDRqGdeQSymM5EcC9i40KwD76OFwpt I0OQhpFSlwt11ysjA61Q0MiowLavL75IG48UAYcxL9b4cl+LFST0cdrheCgihRbTibfij+BXgGHE dix8Rdkyi45R0Pwg3SggoC2Klmo7FhUyNoZDASOsumg7VNhkGJLdGymrl0gQFVjAZm4JL/wFcSpb ophvTlHVdIM0Oc0XGRBtp6PtOV5QgoKHMKdEfTASDnCo3Jmq0iqHaLC8psAC2HKg/cY1LpgJ52k1 nRvLAbkfNTgKforGQgeTf7SeUYZIsHH7sTuQVeh8lgwQU7OsnBiSVuxhneTVZLmAGmrgP2H0PinV GUR1gGthCtRbu0YaRMkC8ofrghcQqcfMV+wK9codngWhmlVpfYERYBgh5O4UxoPJG1aJa54Gp3qY E3mvTrhYFZgHT1umdyYdPVAKNSANQCEh0Hy1vPqKqtfDv9aA25xAAbMpBT/JUvvTQle4o4hykqeK OZx21AiE1wE5Fw7I6BQ/0wlEMUjqYc47Ml5VgLEAYwFhwxuUyQZ9uo18VTa+Ko2ogzIIcbKHNV1D SHPLjPgAm87lqAWDECO4H4gIOpFZ7jotEnb6WMNhXuB5c08NBC6wy3Ulk+RqZhJlbzjVmetOJDKx LOQAguJswKXwIvGbHQCiBTh8cvUVsWeEcTRrga02vd5bA137PQpdpsyInDdoKeVQG7zPfDxXOkWA InNIfSVGWBgnVTrRXObOIUeCuLi8LEPMRboo1egEIVxwjcw/bryTL/AiOXcXhoJuve0CCDT2YcaN o+pyH9N8TvZYjk1BOzB670DsxPuHxUk9cTXGZKwoe0wDg4EKwWw99gFlcDIt/fbsHAWbYGFh4KkG fvuiLBDZFoI1qcosdsH8iAZMl1zoaqxhnyoIqPYuzOtWkqJcgBh5TWOaD8JgeBFRRNNgEyMOOHL4 E3nEvD8UW9pNMMufgY5sbY+wrTaaUySAcZij99QjM7KBjbGwZB+yycb30UIPCgcwY96/KwpQmfwN IilaB87LOthOO3ir7VFuTde7onShrG846icxF1RQ/MVHqsdoTRrBoGQFt+bUSUfakoZhDU3Ml6qg hyGvRixNrluCxdSYnzsqmgeXGhGrgizX2n+0jWpX1kNHmi+639+/wp3NI/+ULUqJMht2OfS4w57H hghVTs4zHeg17P1I5xjfqrpIEDw3XIs5rNev3n60H8IF6AYUJGu4DVjkoJAIa8axQiurMHKVyKrS kLbqbVQ3s4KL7NB00PNMbgOeD2jKIPkMxTve5I40xJEsyKmOEWIAGQD753yW9aZTKhEzO60knPGi jJa50+VDZalb1K8mCz35ykSbCGeZDLY9wX8m/UN8Dj7nYzO+eAJnRqrBw+YRQyMVuSUY5OZtFA9w 7IxsR1V+JeobkfpEc5SrURdRdFofZBbqmfrOMISFlapTgrAXXjUsP83nUk2c7jM63XSp3+TmdSLS 4tLpfCwfnMJ1E69Ig9crBEJfqeodqRUEiytBcyD7trQxqdQdYne2/Tg9OXse6OsDSWc7SfJ39+Dd RQr3K86Ffjn+5IS0WiAb8YEMQf78PYn//J1fxW++6frzu+t+wU9fgczR1fhptczav+A3o64/v7vu F/w0nP3a7r53QuGt+9O1tV1q6+3+ftvf4bV/rjcav8jO3XF6SpP9hmiDxRrPIGlk/NRIK9iCvvbb b06QQnMnTJ9DoUjUli4rJ/Hnl+7fKCkq+6KgWaXw5ipvBUvAwZm0iDYqIpHXoYYP5bAwf8wJ9ctF 4evZzA0VMy8OwglmeeW+qsqrsWFictx9IBZkphRTbh27Fr1aS5IGXbUB90UuILoTzekim0/Dc+1j E5Vi+OXQekb+XuIwbqkqrBgzmMGeDYaiWWuiHG4wCG1iGTc7fduQnt1k6/UfJQbCLoJI9lxBILYi KL/vsiTULa29o6r0daEn2kSPeyCDaiiTDNdQJCcfzFhZg4836tduWWuTTaVcugjMe2tMIB2hI5aw uSQT1PmDBk2AuEqFVfY3qiVz01iNdzn+BXkQC8x35TjG234HHmBQNNaaTj/uwJaWdTofT8tJpy8Z XxvXZ+O0nANGIzEBMs49TU443nWYvMNtHh3s7fKfO/IxugeHS7fEFTs8niZH+TlsKLjwIcb7m0H2 t6vBUPx8biHmC/zt29bYB+iymbhPxuOx/2RZ5d8M1i+NbZ9EY24jIYc2/etzPKJHT5UkyR16FLtD 6Q206zxz/1DGs+OuDvssfB8EMHgdnfj+VfzZv4lW59BHetTysgYhP25hydU1aTBcAhq2jlb4t2lV +oUJ/oru7t3k9R//YU7uI3T063ZGWAS0HspU48UHCf0jBkgET264ta1vNiaf4EuMYn/Gh3wF79Mv Xe+2SalNVN1P8c+m9NbTwU5fDxE9RqNqiJE9Y+71cPfg8e4ufCIPevcAbqubzrYV/PJob3owS7PR g2k2Ge3vTx+OZln6AIJfdiH45eFZdvA58+0eIDxpU5e8HxEk/AxUvEGIQ0fwIN7MXvMLQOes6EQR oCpvBpF4TA8xD1/Pp23t0aih6whLvXFq9I0rskmQArnqjK+FhVOWRRCYh+sWwHK7kzM6S9FjzI6u y3KeT9Afg/XwWsKNAruCTiw2VbVWRbXjvHrMySx77tLOPiRbRMzgdHakLWVZA+cI3YZDvdNIuCUq TTA0juOLg8KIrlvIkDZSenBBq8QVpeFuKgO9Jf8KmZl+QgIBeehfWw7qjp7b5Pxz8Nu/kAz05Y7/ cse3/ny53v+lr3fh6VJIlFzgcinhDZI1DPYu8RDLpiZvfK4B84IoQAGQaf2BQ/9s5qR8jCnqVsW/ KKWKGbifzouSk3DUphPFWg57rzgSNvqvuU2vOGznM685CscVj/AvqfITJ/8FLrVfBgcu+Ze67O5E 4e+8PTZT4G9qGvi/VeH/J4lvP+qIb+/Y3+749mgj2poPkaljKVXWdF4RrolWgPvu/URzG+GjOMa9 PZrbDrBvaHC+oPfOWxdvo1hwIjrmi6r9TTuY/yBpJZm356wTjwfUXgz45aYggi1tOA1j1boV4E70 QFvPCivbV1lhwuw1HjTMKsBWfBAGhxyCizOvKANdL9s50jtf4uAFkagjYn+mPLoqr4Bk69b6LJ/P KWkR1cvwa4lY9LdkRyCBL6Dep2gbN1X6QUIKShYLeMw24yCFGy25TM8hGOlFh+OKK3nUGBkRJv16 pN4wmoXu+I2O5NgmEVhfxUSxSjhsQ3wIAlEYxplQSoAEfqDGjoFvQUxjj2dGls6G24hvwjtcUu+t gvqgHRiT68JI3VuLy4aDmLGhMPWiyhh1BGXAxhExVpaUWEY72Xb06WYS3K9hpFgvyXGoT08+Aj3t yEjgB2tzErhpDSsH444JWW8DcBn/mYm4CkJv7Wwp4CaiEo++5XOVDdZM5O1jqxdXRDeki3arrhgp yghhy6DE0JiBm9hCiXrSgBpshldFpqLl1TvyFLoBBjfJWiDWaSL1gr1Yk4bgBXuz9Xcgw3P/bWEV +OXNjFWeHp4mLVNU+mDvwWSWHjhd1f3f/n62N5o9OCNd9eAB6KqzR8/+1YTzfzI0+3VM7tqTjZ8O PmfbBhKcEMQkis1YecGGF14fHUqIos1XUa7hQ5cxNBVuvTAxXgIuglFJeOS1bAiY5roiTbIAGMcL CIdQONhduxoccRbk/mF8YWcM5L/QdbX28sKUvR8Z4Q9EhiNIdMnPMEiVe6Yw645obMdcGYdHb70f jw+Pjt/+p3sU8L3ugwMNfJNAO4Nk8NT9b2+Q/GUwdH/ZH/yV/rb3H05bc/L7XzeUtyU+0+QGxVmg AduHIdSTi2yRqjlIEhgDHM7x9Xi1HFasgdvuXRMa7r5+/eb05PWrd0oQca7DqcbdoFwqtZnhU+kU RMh5WtddE7M3Vh1kv6RnhArrWnHzRK/U3HG16YqEwXQ69TCd+yaPNq9NOovFrlHpFQAyk32zJpyP ljdy0ijlA9/b8++NkzfzLEVMqRmlGGkV6AdIhsgnppnTDub1WI7YeVZkVTofQq30Nvgv8JJ4nTwC cAaaxjy41UkH48qPN8pA6KN6eLgJ3WMj33AAMNH+FhRp/jsegb8bPM7tzwSr1zwFieS1keeRlMa6 JthzL0tgmTm6E5E3xdH4QTbY1UUmwdYs/FOWpQTrCiwoJbGW4THc8iWPt4cWH8YD6lGV4yRfKNwR a75D//UefM2qTnASrMYsgG1bLTCuLoi6eDGpkDARDaW/pDzVe7WB4STt9hPk+DhaQTXpo7vHia1i 4h+30dGlTz6mLG6BlWpVGBCa5aWG4x2c+1aihmNcWqYdEIrcsak4ebvW9mupXUyzAbAsRanWrvMC 19JPOJoHR5uHwnU7cQTzIdGCj+cSjj6/Krc8q8H0/j2FrYMNhY8pIXjIuLbARABbHv+b1nntq77G KaFCnrMYL5fTCDjhYxxEhKoSFeL6eoqoOxDekHLjbkgQCroivIab14Tgg7UuWRdCgCtA58Oo/ZAL wAbjjxadNacBSrZETkCBQGsGCp0yQpHZUoqFlhqjrA0C2ycRSzKTM9sAL2DXMcEjokDt8eX4Hqah 3Q31CEriabChuKwKyaeAmrQDEF5c1/k5ZLo0af0hgGfl+NdCk4S89EeywMontJAxDfEhGC0tndAF VFOSmrzCuLfuhWkZTYvhVcN8Y1+ZmOpvmhQWyj7GWGZIJy4XCjtBFE47GlRTg5Hgi47w1sA743Ey bIXLSkn6fR6nmOjBNr6vFiA0rEkI490GEuFOmX0izJlUd8C7B9G6PReqLfHw6DqOrFvHk9noZdpM QqqgW61hrqIDTc/BDtlwhnFwkfCQlePT2HF/oUEPGCqLV+KGS0V2c/jh55pQ9dyw1kHrDw1GXYDI wnj+69aw60BotHKUhJ7icDgTSxmnCdiKaglKR0Of4mQsNzPOkwmvcaEJb+xR+olCst0SdKo3vZcz 8WGW0btxAAyX4GEBDgHLMYJ1bQzqQfZCUJ4xBJyXb/xCBCPTlHb0TsecmoVf13JmhFkxz4P0P3e7 Y3Bn8JZkqHckXKInlnuCngWKBxPjfCGVgISDOxwXdqkJbRRu5cUrYgzAiIZwOgqh69YiER/oEhqH dFI83wKj+y7BKLIFbJscBYaMGcgZjxKpG/6kBX0X95qebkkKWPpvmSYkBYaVrcKc0x41oEsR8PhE veqAvrKRUuAbRNXAf4wKQnpWl3Mnwb9/e7KpTtACxA+PSqvyDIIKsBzYAYmIehkLElzqJtEC0VQK gxO90w8cnnFVMkwqYmOn7mtKww+DD83UQByYLqVilpdJiXN9/Qns501anYPX9u33z/fvP3kIFvON t82d757dOpltsEnuc7c37lXS2ZK9374qR016PkJl/e/u36fp+Xk2xX9TvJ594ZvkRc5uMPOe+1mj P/Z+q2/ob99gMs909P7tCzLf0jeDrYF7fesvA7eYg79ugb87GxEjdhrkXwZsroLek8FfB9vbyWCb fNz21bhx/Rf08HVAdsng2TpTqiE9t0z+4sEKS2xhwHNaE+h6MlsWE4K4ZuAGugMoDy+4uQ0JqJ3g YLz/AA50myZ2Hz5GmkiCemYnMyuo2HEBXQN30MIY/mCYLHDMbmOBQB2UQzJgVCzqYB0bzIKTvO4z woOyIPFXmSZ7J8eODBBDA9JkIYxX3W6YqWbaYpuQXrY+fMn/5vVGuhj917VdQrRUCnRUF/rytaYu xHyQK7v3qtZnAPCxrC5B5SPbgMJbpRDTheV0ZjxcOBA1XsQq1XbXPHbNeFgJv6si0AW3EspbZOth dCD1iZte/VXeci1Zwao3mY3EB+PIlWlODfFQTzggZsM904vHApI/5+lFa70hM70ZI22zTsvI3mjD cSq1fct077Oq21sutMv0LGfCrSUGXMBp6G6VoRFqcRDi0hdcyAdQEL2wvWalRYry4vtZJpIT0WCJ sQl5sewqtaASsUHnI6Yx4VNM4hnY1jsqHYmZ1CtMOmmLN8HE0LO6LG3GLWWpgVwITCC1eW0jX6bt 2N+hm1yYEO5u3FQjDHQZwS90Az1L/jI4SdIFCLuw9YO/bidb+pN3QfOzzS4ggTIMUZ44yoGN4kHd mlivsoYoMZ+BwyojeAmN3PC6jGcpFiCrCCppEAG2nXvhAuD/EwSN/4qaaX1JQTf0RbBm1BS4xJx+ x4EyC7As0Gqiff1y7pReQHssyKoPS/DBA7vzEvrLPBXLgsGDRxPLlhvsFkiB/3PefHXjzZZF+kvH BP66vb2JjyvGzjLCVT+rasxb5jDh/qsDxj9A9yLqVkPBbbPyNLNf4u/enhu6nuyl61mVQjWFdGSK QpzG+n5goTCDP8vOc8aK1eEE14DY0uercJChzm6+gG1FZCxts8g+NV2vDgVU3R2tvlJagWRorUTW SBh6hHkz9fYMLgA1LmRgH2MjG2gZC3fVUZ0ivfQNtqo/+P52wCoahV92wKiRu0FwDhTWicWTrrCt YHy+eWmidcN32c/EbBBLFJ19gKhjxBzconTR/obibrAw1lQKhngzjqgdtuUeMm7fPHYrW8QkBrS0 KIwOagpFMKPhQ9whSSIYBQg0atpmmEmLhEY9pV3DFB6MRsHrq0L6a49ojzQu/XKDa48KsMtI9u4C m10a29d79es1b+09u+7aJZb7087g0Gkk6Qd799ZNBbBceuO6F21frh/qy52WcvHMfSAsO/7wppjY 6yZE3mhj12akq3VLNTacx4s+BCXiKfa6ZvaGiR8FSgFnWftuDvBjB1sb3ISttcd2Wus/UHhtLP7K EoiMw4ohBpKIxA/HAQbrBkGeKoKnpZFwiIu7Golvh0NEoaShvvkrHqv/LgmG3zrMZJz0OqqWhBJl CstqtO+4Xvpz15Hk2pptNvzIDXhLeBL2SbSqbCLEmdFTvq3C2zoKE0trTyOfIbtAa90yyzGhnxqb QElSEjpFiCz4lqFYowvUQQJAKyLVNlAP+tB5LkEbagK3YNh9rZAR96ws5xlismlJ8RndTWRbNjOg TeFZsAAkF2UXnFADhmr41/wj18VJGoBGKsXBAkhIaNYVrM+yibRgRuxOwOdR1awMmE9oblbWareh J3+k++CNbXTZdMpZeeMJYgO9ySn2iWHieHodY49/2n+2AatFPhi5YDQdYUhs2AtnrCkJ1Lg45iMJ qVaoopgTxYMm5/2yVkyjNS9vXN5YKOp7tiMO4umawm1+arbSPBlpbB3VVAnV0Hi0ycjlcjRq09bG vmodmX//KYyIjXOmFbEDgaMn5LwxtDJuRE+wvPZnhms6pEBGzDaBUAOSEs+y5irL4ktMQscjWZ2Q riLe0xm/f92mqe0A24Q6VGBofK6GRsf5PkVFuOUlb428pJe42gW459r2yKG/SFZsveOXUQzGZIT4 C/gJAyKV/KH4E79fsl9K/OVkJ/KCOlIcRNgtC0H0wo3T6GAetY9PGTxP3eaPnhOq8FPX2WgCvwzi KH0RspF11SV5bVlYV88ttr+ieNl8QTkaoFVWWLACI+yqj7lerZyGVHFIOOYVQecyk2mWzuM57OrK o9HiTZWeL1Izbhb7+8cu6hTK81WW1mWxwQ3ZpiKT0NDjzfFvbCCtm+a+SUzj5OUx/pFNTE/9yRZB XB464IL0Dt5StvEEUd8W+TLx8G3BafX99m6DNi2OBOApQQ5WGPgQWJsC2N4a7Z7gZe3Q1oIVCJHe W0vQtQA9YPNaKdHjjbOXJMSDD6YPtluuCu2R4Td1FrbKjcZUpi9sQGS+MUdj/kMO/jzFsM/vN433 bBVN9JYoE5QZVZiW8ndatM6KWFLmrtv1O11SQWRSbN0pxsKw5CzyWIFQthGbNPYwW9IbBSmOyoJn 3BjdYVgqTSVGDjLoK/4Y4PCZwo+JwiOX8QqxcGsTB8LpBFmKTQvLGk9QA7QUcFAK3Ms5XKqIFjmG 5nb7PHb8Nee8utY2klmDfGRLRovX3Qr9pbwoEuT0NPmt6U0unaE+N76BOgjIbWV+cVRmE4UQUBk7 t14iszMJtPwhwZpKvKPWBDdekqBSxeuOdRtajU59cdf64Tjhg8J0HPO+qXfThq7GO3QjEE7klZJJ 1MdD/Kuxfdo0EvPRTmj7vV1cEBFvt1WCleQXAmuX06fYG2p5pldL79Qaa7gAj8OxLjNe5F2/3eJf 4J70l+V28lViHhBnD3yQD8cgFa3z4LevFgwmCXVtOTlVqzxwdxIiFY3wHhSbmWrLhYdpQ7bWjFo3 5x2RcSIXm8vT2PE53BNbCDBno/BiTNbQ5G+IQTejpALLbrfJXmR23NMJn5E1JIQ5VgT47oOclTvi QqPIrNexdUcK/D1EJftSOBS3Kuj22cIHwTInhSv7Kt209LdUA2IO1XeA+LUNrmB48/USY2fkIyTh vf+AfwI6hL4G/3DvbQ0Y8GQALIO//1M6h8taQFHg5n4NVy4duPC9b5K9307zc/YX4WvQ/TEmNQ0o DWxEjDCBE5NpbbDkYLwPpPUXPhAbZEBJADhwB97JqKSSBODmVQBYXxsQdy8ccAUl4uCSIY5RPKhu UT2eQh0K8FGd+SaDIZkiIhzGKAOLBFUNwjGhgL48h4DVB1m4vh5GT5u2ThJUaoLoS8o91K3m5AK+ M+hNdcTrW4DfjEVv0MfMIS0AdM8lxuWLkIz4K4590fOkzftcC5Pp4KM8AefF1HyjStASce4ZOXMt 5uoa0NIzFCnu5AZ/iSFMWF4qYri6msw5eHi4nJQURqeDHgwNTJCWS9KezY0DkpKsAgR4LnJ3DVcg 08DmhxCKsidceyyVNsCMzx96ktHOvJ0Lpbx2BbEOrYVP+sC0EkRL+qKcDHRBWwI8ktj5PL2EHBS2 qyBoNyZamHIdgUw8VLBthXHkm8Vx1HTeASspwBvEL0CZ1rHq6DV3nSvWnKP2w6dn//+9vz/a65i8 tDwplxBEK4XrUO109w7mPSmel9aoMyMkWQP9xKmJpKGDLAsnL5syU8my0Mwq8mFSgCmSkASb0jVO ZVC8shfF93n0+zO5oRGbTDK2gmpd3hkUpUJPsvxjVwGQxixS9umSbaM2BJ5FsnmJoPLvxNPvmh3a YuNM11d5fUEW7IvU/VB7JBMus+H6GrnOhuYjEsZoZ0zOUBHZESAhRbP9NEwEezX1O7xXuA7A59Vx JDOewjB427wYr/H0YDjSpLKUEoab1ZhCyufleS3aJ4irl1Nr0KSBTHPHXercSlLUmbt1NFbCtlKj byJrJuMhJZGnCoy64kCfs0wAdkKsiDj5BleFosjS6cecPQOXkKEGJflQoilIJDEqi639wnlzxJWg 0E7N4wDR6UwFR0hhkTXVumKECKsLIZwNw1IpL4OWu6skoVPkMseZl0XB8TjEbs+q8qpm/UDKABPn MZ6eroj4wp1yqpBCNy7XRis+5lVZLChVDSOkfMwljwHkSBrG0P4sjBscRlRVqJzNsBEgp6u0gi/i 6nFhs/P8Q4Z6Kt8AH7hmReVYLaIbrpJ6gcWZAr4o+DhsQuD2pmB61VOIawIhT254Tq6ZfMB8VzyI tjovpJlNy8kSF2CRFuk5lgkgZkflHe04/RjB1t44Rg6/Y4krGaKsuzs22Mqy9trc5Tyl7XT0dl7S 3TEbzZ2+1BJ0mFZ8OIQpzfm3ZR1mSwgvwYuXmNc0XAnFBULu9TkWWVN1IkHhtsZT69ZETBGxdmvq 7XpFS86iJqSXdWZ1xiCOoj/yuz+0A3RkrzB5XeLd6eHp+3f/6R7H44y16ghOgkC03J2ZL7ygZKsC tzXu2DaGliOU6rgWFlomskZlaZ/IcsGlJFdZo29BkvSYM/bt2PimQFsPs01yhMi1ZbtnazxVKfnk Lq9G4oMie5fKO1jtGNIokUnDtEA2wFhZGtcYzvb5Mp+mCINh0qZREvY4XnBAVEJRmOpkyw6KuJbU ml3RUd+m5LVSCzSaWfHsNY2ztY2yWWMrbnrknwyVbEd46dzvK8Fq2+XQk6O70ZMVDczGZtfj8qXE HByfz0sq+spryJOijc9QEMWvRCJq1REMU74hsAYzdCAtuo5vGGA3yhOI3oqCj8kV2iav0hxlV+G3 slLJaex2Eme4SutrVjw0RUW2/nLdCUHKxpxebU4nFQEyrTcpxPCQLQbgXogZAHyzZT8KZ+Lzl+lH zJKyemBQFE0M3I68a6Pr7+151AuTXtId+9qe1sH+fvK+4MXBM3yM3uTW9NyL8fTg262uj8NpCrBb IIx6V6qH8MP9W9lIVTop7N/eoqAUElcO9h64rj20wkuImUhAoWmxWXcQL8GpWYFPfFt1J76KncL+ qadDgAQsqwpqvG5h+EhH8mHLUtrqENkPSNbLQlRvXjGdeAqXFO943VQcQxkLbxTvhkmd3nCNyAxQ W44F+v/98kXgxQrBEiGBaMRy+FY+zpwcjCswkUIAPN9tZJrMzqh2PD6G3ous5HqNwWA39YxBZSQq jNRBYvfbJGbqKPUQVVe6c+iOLMMLhGERNx9xByJox+AP2oM/SLZaX3bPg7kWD7IF9ujVpyh4Ikpu 5cphSeqDV5mFkG2Yoy1TH6BN1iH6N6EN9BY2QxCggi0jb96+fvPm8PT5jzJmTlG/wAQzd1XkRb5Y LoYy2saWBOOW2E6MQD/eP9OzbBvv1wPHdU8ca5g56QLvhHdNWTn5u7VlD9ocG77d6vq4j/rshtnK a5ttmL+kPHOoXYfec6dphETWBdVaw6RuY31Qsc9QAQt2YpdkfoE8jayumWQsge29BNnIl4hVmU1R fsTAQWzILsZV2i6Uh8pJyrH9TVRGzZZFdvMj3/zSMZk557B7OobS0G6VIAO4QeGYbo/UhnvfTN2w 17F62GIyEPCcjgtcJTrkrJhaKbDQ4pBGXylZH/BnDAySIK0gcCKVIsK2/C2wWjFpedhgredivs1w tc23NX+so2Sx3XwIgHXD5D783wH8HxzoB1jiBc27gUZFqFliX2NPvqF6qGbOaaCJE9q6G2Fx2hSW BMdrpY50XdB2Nb3rdxO+OeZ1O9JwvCAI7ERUFklzcbojcSUS0UFLhmXElDd5S8s/soGWekDhZJpN 5inHGngLGAleaxIlj5+P3GApu/hUwriwiDj7coaMXcLnfWiMyLNl1XDgcVPlnGFhLHKYcoj8g8Uo QeYJ6IoG+92r7+XqB7gRalnseti6NVfhYX6DjjBpZ3uNjuxrRyRmZzzjPX5x/PL41el/+vc64G3N Qw9xayYCa/g1pvPUzQp6ddrfOUMNOtUeNKvi/NSdyW8Gr9JF9nTwzLdIA+94C/Eo3auAst750hvy 2cArJiFVUbe9q1YIF0b4bKOI3a//ndclMeu3pcj7w0Qw+4cJllUZkhH990OxDf1+yNowR8P+fjt5 1u/za28btrp+x6YKUBduFv3evU833SZs6y526DQOEQl03M6P8SS6T7ux9G6zp7S4W/9Bp2jtzqxX 1XR71++UvtaxW/7Z3eyYtndXu2YTYKMw5lQi8BLMeHJH8JIynuA7KBXgr0ZMe2OdmFFTTcMQoGDu RUKZYizJRkJM6Qwyn4RoHmwGNBEMTxwhlkoSJFAaiImH44PtWzECv9dbMLXf3YJsxH68lmgaEwkR kow8uRuC4dbuilxkbt20svagq//zq6M2RMiT8ePb7J4M68aHfv1OmrietZvp3+vYT/PwbrbUN3gX u3ri8YTQBeM31gKh2BgnL07JGyimaakBFGHM0oVhmRiLhCoNJfLcZttNJ8cv35z++fPPLLKztXsM b3TsLv58N/sKTf0COyqGPvETsnCKm+qY6vrbGaLRwlCn++P9a0IBb7OjuA96ij//5gZwhPWXtnuj 676Gn+/oqnZN/QLbqccsJdwDN1HQKIPUgAhadxqGBqNGDB92b7296llGkNUU2jGpeWxSN916dBjT Lys22Ctn+5m0d50Tz0KjHNzr2JLtXI341kMvb48Bcqv4QGYCVOYpYm9q1UosA68hXfBZHUTpNuU5 x+V3hICR4I/feDwRmAsMZWyQwRVAU3mL2gxytAd5N1g1oX2qm/A9M7FgCYw9h/kwla5nP/oquSzz oqHMyTC+dloSwvYnR8m3k5dgTFtu5L8bwrjXy0sdClB9jXw0rbtkI/j1jlSf+k5kohMbbBwfNKL3 6/jrrVSd+jNknvZuAAGu3Q33QsduwK93sxuupbvfDfFTKOP5JXcClvCOpU/0mhRNtbpe/cTXetRP enZ36ie2dzdmHVADPB9HfkcFp8hoSzE/QeJEIHbeWuGj1e0y/NzSaoCFIq/dNXirZ9Pw0d3tGTR3 lxYDnV8sEbAy2JEqyJDcwa3NmY0aS2AjLZ2WwFmEt95mHG23eY/serfcbUIguHa78bWe/aZnd7fh 2N5d7Pi7VrJiqnV/gqKIFAiqweT1RVoxvtqt94/Wd8v39Xdu/oZCh29g7V7pax175Z/dzV5pe3e7 V62duc0W+JZuqWQzTayXNPCdLmGDHtyRvIGN3fGaW5q/lShBzdxosTcwZK824VHwVp8Ze3WnHAqa u9sNQPMVQRRp4LakZBw23s3XiJO+DfHH7kQyaNPthNcENO2rvt7e0AzD28IGb8jCaBBrt9EnuYd7 yDnsd7KB2NZdH587WmBq5g5Pjy0OvXblzYsd62+f3s0umBbvYi+eiwnJotpSpMACwg3Ps3pTi5F8 OPVPJKGqKS+5xpi3IoljBy1JqdQOk14FzkqsQpDCgmVv3L+dsr2sMhvpZCJgpbShL9QmpY4lL0PO Plh/KNRfgwK52iBzDekbzEFulEsbaWwmWUfRhQaq1leSuw1xW1rckiZ/N+xa8Jv6pIOwkF4ar8IA Hkvg+uhuqFuauwvS/rGcT03wT7R1SlkZ5pvjxUHRQJrjbQud7SCyXi1Wy3yzY3FoUVPRJHgNQGZq gsGhgInCq7WCdxgtNE1iTuWDexJOOuDUYNHZigwDiauVzzJ1yteHLLu04duTknByRbbXMUDGkqN1 N3ZwwLkTd1zXEjXP4bMcfo7lMxXcCE4vHzTf63lVLi+97RWThey5gdA0WDeysVK5agrD0KosWABU JwizhQIymJ0DvcBfztKaQgRxC8hQe6sTqYuBfuNhsoX//e2QY7K2/74lBet/t709DNbvBoe1fVyl 1fXHVd7qOK766G6OqzR3F8f1ByCF2tACnjWqjkXUrQFiBFJJro6WTzo+cXIeNrzFgiUObO8S2gdi Ig5NosDVuwblYwsFprCHkXO/o7ixzlawL5RLcSsadpvUdDEJ9wnLK2jlHu9eCJeMgWVuRfS6Mkjc QuufcQ1dozBuIHT1ylt3KmrdnZQVXUUYqkqtY/rgWhu1ec9tx1f2n2sLRtyBY1Zkjrs1cXfJiRuJ H+aDNZKIfetuhRLT8p2K3qkKvdYEDnnX83TlK/9qXDbU1zMO00Ac9qLwRvwur7vdrCbHya1hrnAW ZwJojwKyQMPDyO7kPrUkccdUR4gIa+kMX+mgLPr9bmgJ27oL6nnTtVVUzoiulryY5JdOZaFEzgQD uDSAddPb0K/aNSQimRzYAxbMJLzjaQ6ZTnP28k+4ep0f3ZYUKoMA/3l2eeEuUGxD4Dyq5HgBSSvv 355QIWFo3J2NCWiEcgQ62hMxGiploRB9US6yS8wxubooYWISWXwryqUFOnz1543vu26pzq5xt0TX I83doSR3p0zNiCqIByC8IvLjbSSPxV4nthbkE9W8K0XtMv3K9WhUOazl5ZSMKCpDhM1OWYya6ZmQ TTrCunmJr4ijndg4E+4QSRL7DOXTzxfNbkSEXSQIwThanfNacjRvL7uYZvuduyNUO9IbEe21FklR Le1uA+KB+2g6R3TELpzNG5By3yKbPBTXfUzJ1w/BG77Cs0K8NMLVtLlnmGDVRJADVMSXwouwbHLD ypaeKcatkRQuDebCUaLOHdZ5jZU1RfKD0/hTdrYp4KNdmc6FvPU5ChreKgEM7e9oHUnn+cebmu71 u/UHSl/rOEj+2d0cIG3vbk35gQ1Gy/KUl4BuvbMoPzLUFnQcUfcmx+dkJvWeXBuIfYgZ4EzSnBqp ySg6RVGHC1Wjp/ZYCfb1gJZX0SNWeOCojAk2sYXQztvC8DuBbhV/FattwaHc1kxPbIQRZn87gLFD 6luh69RJJmxMc53l5wUEOPFsCPAfV9JOhjNgI4xNnSO+brLZzBzChFTdxKBgSjhKHiHZKZ26wvnT iDsoxf5MBuP10LDYki/TeCMI2GDxgus7KBwKrwbVcAWs45pUJbdfXyWsi/AeTtJCYVvc89twHD94 0Xcct7lpMkqHtgNsay3LgTe6dB34+Y5UHdfUXcUfxfNRVIQA3kQKdBMWGa70EiH/AG1iNkOCKZEp 2YODwDVInqBGywupXgbYjtrt+8rJbyoEyI0pV4wqTG1gZh4KcE8seBmc9ooOlB8Io2sXycS9AnbK SV5NlgtA/5hAVQNRjBBeKJUlQyZXG7kcWwHdSmEMXK9NOSnn2sL3p2+w0hGCmDFyQlnXOdkIiCno uE2oN3bUKpth5WcEpUsLhpQkuNpwGXBkbgAMJMd12Cm/hOENOPU/lqEUPADGi/wcG+Oi6SjapPZ2 8GyIZ7QBK2qRqTuRsKs7sKXGu3Q7Qyz2coe+biF0gv/bTPSnd9fI/fzCHeUWh63esfXN1CJI5wIg Fd6s6gO7ge7aksUxQ8roq+xcVjMK9+FxfBflVKIn2xd9UH0y7IvcbHWQC3EncjFTyBbVuoCQvKzZ /t1NXc747Voqo3c6jbz44I6oilq7C2p6IXC+KLaEbhpfG4SKv9zMBvKWlsved2kTk0RQsxF+p1An heT0tUlIYF/5kpGKZesvPOpCq1Zq7ohATUOgIQAkMYeMEBBqApzotKdY40ebDlRWBba/QqxOKoTA ImuPG8ysL4jtcoBuaZDGwaGn6za+rOwaKcy90OXFyvpksBuTuGvqF6PvleQ80SbAZBWQ7kY2vmiZ YnfrfNVDT+xW9bAsEocjGkvbeEgEKBTV2bENWseENYX7jmnPHROSVCqaQwxC1FugZ8ylOAIRM51X TgJZ0Vlj9GIIOdFIpiq7nLsdc8f4hVvMJTqM0vNzgWm0Bnkt3Urt35NWtvjB4NNi/nSeIsJm01S5 k4EzhUFm7862nkfXRg01HQow5CNyEkhepVSfsj0NNRFQK/8uz2qYOX5cZYBv/hHdSYSUAghX35+8 OrrVcYXFv9lZvV4imuXFNWHL8laPFISP7lD+gfbuPni2g5cyHjBfVrJBRnyFc3dVJgx76c8fngO9 igLtWyYwZFKfa3AH/AWOGZ0J/FmCBPm06m7kJjqChXLiEcqQ8IpAaOq7CPPRjrdkwH/X4fJfb2gP lHbW4/bQS12gPfzkrhB7qLk7MaEDIzazC679qAy7UWV5xzyLbYm3ymBD6rwdABCP85apDUoK13IJ eKuHS+CjO+QS0N6dbaid4bod5TtaDLTR5nbtaB6zm1sfVBznZ2vFsUGtvdsg+LxRZmmxzwDHMRT7 h154iLPdQQ2c1wYDx/iq7QdWLAnh7FQmGEeoa9jGDZHXAtQ1NgzfBfJahLqGLX8O8ppHXVOGn90c eS1AXfPG+Bsjr2Fyovs3asFMDAakFK7K47enf/5P+94gaR/88Lke/ktt8cbwMKbBu5AR3iJ4IKfp 5iwDT1PFvmQBF0Apw4TNHiv6FGsxQ0MELHJ4CYij+adkf0MVIVh5PUxewzW+/nS91U7kDKbCPACK hCHWTbq4tG7LRUkFFlolB830LYoVv481B6dY/ZAjWtzAsGDi7VCrgqW4AyAADjRD5rOGps1rXSAN 5uldELRp706jpVJismJ9M4XLqfC9Brv5eBIDDBtHu11v7Tdre5dUG1wphn5NAB0Z8mfXT3P9FD8T o8LM+w5I1F0xzPnnovmuodT22x0E2/HSXdBtu9k7NVajE5PaH6kRQGvCs+KGcL4/HFOhBKnoQgUs pMzchuTbse5KdaLfWxpmz0236zbhEukwyvUzUYO7m8T6e0WGNYJi7UnyVfDvsJylQvkfjPfuy+H4 RcKmO1btbs9AVpw7lXqzE4Dvrqd/euWOqR8b/eVon5bgMyh/U87dWu5fhPCDaeTiAfKZVun1R4BH OeJhfpUEdSscsR/8GoROnd8pmWPC9EZE3pPAHr1wtwR+V6nsneSNkJm/GHFD+FG4ytfQ9hrBpJ+2 7RxyX2megpg2ouwFVBsZ4QCh9moHL78/fvQrEDdl7t8JaWdwL62naXilm5jxyR1RMbR15+R7fOpm 10e2QrJk0PtcnowLeJfketzomNdTY4alBUjQ6CHGvV8OI1OmfjdkOE/rBoMLwE6/nhztq91kGbxx R+Rp27xzMn3hGh+9lOmvZbNSsvOzue2rssm8yx6mNdKFRwU+gLXXqoxugQHkNplAu4QqCYQNua2i 06ElIVbwhlodRbK88/mKq3ByYyZrQcUM+DccUXXvfB/XQNev1bmPBxBCwHxEXMf0JB4MPybLYEx/ d3maO7f2824fSNIc4Rz6jvv9XxATN16kO0K2l8Sp1bpTH7zYAwzkn9/FiQ9avIvz7qtHoA0ZCz4w zGBw4Da8eMKlU4IVyku1wLgjB8guu+CStykjpF0hA7AAeAARm7KfQIDMGyl0Lj8yK1hwsidbxPl1 U57ax1R6AP6gTLe4XGZVhucd+NlFOaea0SXhLpScPxKEEQR1iiTQwGfbQYwQOlsxANPUc2JIpio/ v2hqwn+IimeRryFt0lsDK/mN2fKVPbZ/ezPH7DExumSUvKUQBVt0uePU2EFeVlm6OJtn5A169owD Pb7eMQ96ZiLO9WRHIwN3wiKqP5Z18zS5uroaz8pyfJbSXoYK5NPkk/sTPADp+6nWTPoKGHBVA39a NrPR4wEsASzk76FyEtRYdkvxzWBvvDtIsmJSAnyGvJr8nt2ER0/VH+6+KuqnR9/cg6N4j57rG8/c f4NVA07Ij6ilHd/UOm7Wv74CEnP9AstaJnFlyZutVu+Sf84yWsSW3pWUG0t+kt8hN+DZRdNcPt3Z MVRh6AeWF9+KvhT8huD3YONaD+RpsJ09r8m7/gyue9G2DHwPiAZBvIhY9OcNm0C0SGhDcQt9O/Rs g4awhsyzXfiO/rrBN5j/++wPaZEl7xY5WLzktw0+Zk7+7IQq4GTwsfy26doBr7/2ZfmiRRb4h4q3 aGtPZ4/3ptl+Oh09mt2fjtK9s/3Rwez+ZLS7m+5OnuylT6aPHm7WYxcl9r240WzgxWsJTFpbQ7Eh QwqeHD2lo/nMsI7d5PUf4RN+EhysnfbJgt/C8wu/mGO/jutxK4zcxIIu1YBm+BCPzenR80A4yJ1M QAlWZEjkwkoqMWxQya8Dq8MX+1gjMtr3urE5/OO7EBhtg3cfE9dC1LhRNGt3gZQu5eZal59NGNIw UIyOvi3chh/h4avboLsSea6hDHqjK8iZHtwFNayR5T8j16xVOUOTKrH+QR6U5hCLvdFHg6ocSync 7LbcJ4qiYOkau1cnN4yUbjWB9Ri2MZ5qdckFhOEZFHExMQzu+F8ujeZMpcQZPmrO1TOYNlWzqLKg XWoIQr3KIlymrWndbNtRSR1NLj8Og6HoHxlP/7pYWwgcGFIlMHnhJ4jAUMQ8Hg4P3w6HIqg5fzYE fHW6kqMxUFqSy3KeT2Au1BCDxd0uDplGvgUj+nwN5DCJj9UGY7i5JK+yJ4S2PR3wP7935y2QLidl dTl27GnHjQYqjuwMjJRKA40lTZh+x836PXT7t1k+z+pn7/jI2t867+JqItKuSLrug/MqXeB97J52 feXIMf7KvboDivR4gvJdHUpYKDLEo95sJi/yM6jq+4+Yyjw/u+PJvEw/ZPC3X3020u31s8HmDdkZ Ue46mQrDJRHbgo5awG66JyOSl49cDbOkDLMH2wrWCAJMTAi2RL4UvkBGVY6XdwzqqiSTkeOVQ1sS aIghz9bcC67lenKRLSgywhgkCSWgnCwJNEBQCJUBR5AdppGeg37JBz3ZesdGZaZxalxoBBP1SXjh Sg7YI14QOawvJQWYIFOtjoSTcXyZKpOLyRoRTSFfecohpzgkk15QTOmD/LygSyDDyudOja6zjA02 bLZm8BIP4BpcELJNh+6uKC4gQXoqk4Bb50PBECweT6tzMHA7MTAax1DRnQ9luUEQpzamBHGQznug umQwp5Y0p9mihJQ/g/sAWdZXWSXFqBdp9WF5OaQAWZi8xMEGSVkyvcBpfFZlDAo2B/s4zbz+DPWA c5+zKaog66RA+2KXMBg8vxOZ0LZ4J6Khr3sW2HvFSJhM0sv0LJ/nlJEp3ePC89G7cV5csLzKeAQT WJA+2AiNPUUDc8f5zFZjo6oaQLsGNF/qhJHAhc0ECaVc/EPSpNv5x6GTy+nny3TOWg2Ha6d8XOts /jGjRL2qxBrq4G6jofCPIBJ7fAKDYGQzo2Un7InC+dIhlkTVpaP3Kv/Z4407PnE7AS/YkS2tJ3Rn 5uaeE3XX5uZ/UXszSaod9uZg2b7Ym6+3N7dW8p/K3hxs5zX2Zj2Dv6qt+BZ2a3nv2kHfanJUUOaf b2Yovq/f3n9i4+yG2WMxuz9h9Aa8hiHk/o0H2gdZzl2y7jzanLJrEbBYBgYH7rIAgbUIkqEkCxts jJAwhtUEqqxAPrF0nAUuUnftzzML+p9inwJsBBe6k2WJdUHjKSWfuTEtQISQ6GYWHGPLtaRyUb4b I5BLtInvdAgiAIugQ5BRxCQaowyQAaljsnXy7sfX718cgbxLyzJ1rznF1UjOPhGe9B9Oc4MUMDB0 XeX1tdNQZzdMZUVO7QaFLUQOioA/DNQaizJqAJMfcB8rzLTqnFY0oENVJLTQwvrhsS4iCgP2r3t5 AQUoClETSFakmtG2vC4FvSFI5JBgfTkgiPQJsMdhpjYj8CGYJOXUvT+Nhv8uhwIX0DUDXDvlpqiJ D+D3fBtiPIIv0wI/DYkw7WLi2nE4lqFZllG5TC905nRoJ+c7emdiCDtllOL1fRe0uUSj2IrtHTrx 9SooCfH6ZjuVrb600+fMBNz6PZ+DBTNIPz3sCzuHdXZ6mFNfKJcfrA0T+h42aaKtjrkdlp7hO/Gd iRYh/ZvvjQ5ytmK1O5ss8US8fnN68vrVu1hXoMUEGvLw5TDDAYdqMVWx4UJTg7sIKbB6SE2XDBRo R8Q1Mlo+AnpVXDKQGREvDGGB5vK0n9cOPWdirIJPBjgy8twgzfVGg0WzeN5eU1CS4ADb0D2GzsjT +dhtUJzHxdYX93mybwaywHg/4Lpn3Hqy5x9/hYh3+cxYJoKJRCMS8xFAHldDu+uSTMY9DJN9Rndw K3VghwNRQIK8Ri/f948RRajGEtWZh1RRL0vFHBpN/owKHiIqp3Vr6HETa1J6n9PgwwPVWrMIT3OR ZQRjMIB/DkLczBw9e8ysJqp6BwQbE0Nvf7XcEnAUhlBPC+l2uaDQMcYU3RvY2h9AyyaTaj43/InP hJxPhQ7sYkbdS7XftVT71y+VrGmwViKmWBA9U0d22KETe6QZuV+7o/Po29N8kY1ek+eLwl15ZcTK +MJ9TPm5pxB8oFYODgn3UxzsD7omyaIHnLbWTEzntlHtu4Wu30kWXWu7CVnUQBd6IGH4xvp6e/q4 XuZ1/IJMT+k8/5lsNE6pBUgXghcIbrETuSnS+QKOS97xeadHjxaHpVTFIzo5Pv0+ee50oHQCiH7v HBG+IX9fm0HvP3pEuAXiHwg64HJTSyfyjgCgidJmAdWgFklm5iTqqVz6vMgKGOWjpYfsaKRobsJQ 09IfGn+eF7bilxHAxrhIZyXblSdpLUAT0eBEkANzMlgFQBwWVUMcsxKhCrVE8knOdR1qVVAmunSA rcQwU3R7s6HBIz3xiWYsEBS6SLovK7jE02korPOYAqol+7+iTbw//X70ONop/A32SUcgQurJu9fJ 3u7Dg4cEeAjw41Cr79LpJyzaYP8kudbqMgnJyBjcRWhG0YcsM6SQiCgpDztSnYYWJL2zLs/9Rw9h FvAikWzmDiDLzzDOgUwvgOZiZ70UxxL7px2e3HcTgQDzplHY0ZcnL49xA8MNilgOqnlwHV/6jHnN YhUyUEv3CluuA0xBYsnyidqhPW5HUKIrLJIF/1KNk8/TyeErEHzOAYAMK+2a0dTJFgQWtxZ579FD XORtOG1AHg/vPwnHhR+H37n3Ru49JLE1MGk4hUBRo4u3lA1YcS6EX4GcselYMfdtxavPQPhGV+gA me08mkP/M0seTXhSw0HJTs6WxYRZLDkWmAqtE2CiIOHi1INz7d7tGi1CgDVVWZxzvAjaGyrXJ9rt kRsgyNFLSO5L4OTUg/5TgvSVe+uJRGvQcUCSxixBUlpdB3B0Z1wRQHU9cYqag00slE7PRgc72il0 HpH8qfU+WzxlhtaXAu9U8A67n7PzsnKX1VPyahhAS4JYViYpWMuMF4wT4LSjof8ugmViLaUDJ3OM I2ae2eoN25iV4EgUUDingkwRwHiG+tOQmfOx29e8vuAu5HZxs3//7vDd85MTbqnqGvfYq25ZnXXM mfUfbAPuInatgjuVZwZv5LCukyapwce8ShCGEONGrcCP9yIR4LRkpYooUE6SXiKuPa19Gxyteszq 5iJ3nIpsLuXy/IJDBP0W+Bkwal3SU20aht+/gnC/DXlxGBWte0HExzzk1YU17ZmlzEzJ3TMOWYCY B50a5CqT6WXjFg3CJdwPBGh5OOflqUvOXAkYw1Y2Ph8PTekeb97Ls6us2ibXPgOHhMiYWPBBK0nR CuSVEEbehPVKxA/JcWvxUKgf4ASpE+M+QZBA1oSnZehDDdTlSzYD1w6yTTSnWAwWXDEIc8Pksi5p Ea1lRJE0R1+8yrbh8Vccw8WZUUAF+zdTAFRUQx4ZE6PRi/eTDIrpBRc1RvQlwt8L6iATJwK6kbVP +6ZFw/opQ6PlwpH81CvswWbLqkXrEOHC4TzAxjTLUiTuiBIBV42E5CoDasar7CpjTiVyBVSa5VBN tfTU3uUG5wuIBGuF5AJZSmBo5BKDN8DhfIE3hZzPHiQdfJlp+WD/frIF+mM23d7G8MScg4oIDp8k JIVzlYVyT8sKKqJVUHBkSuEi7oIECxICA8k+4I2ipQFlA0hWjtQjMIPYDQjDZHwzRNncAeuG8KXb mAoyyLQ7pjfo8F7t5Qb4OmAjnbY5HBxstQbRshWNqrmiBbf2BmvWH0CPT5lVGeG1U+nTbwWsF/wg iwzSTPN6oeBNKAEs8rrWWN4wwW1Dw8e7bLKsYC/71Vf0FshnuZ4AZMbTrIG6BG4YS4p9mLitA1Ks uV2a8sLsnwSFdcpYwuQh/OjK3RGxn0CS+TLtADo1Aw/OyhaYTpY13VzkD+szYW6r/hB81C++bXvf D/Jtmg0o2kR7bIAchoOt8voDbBOwB8RsRjhuR5wcz+FWjkmG7lgUN+EMucfADJhGGkcORTkvz1dw /N1L0+UEevmIdeaLDIp85R/TiULJwrYw7wf7oiNlx7k4tfki/TkFQDzk/HCAxRFB5Xmk2jbc3bzP ZDttsKYNoTKusUIehkN3+/OcToylsaNl5i+/bHHpdPic8lllXYZCL3LGhFSkHkbvEnFQTQNJ53Cu KGWcY4SA9RQZekNZ4Rdz/hnHsMGJP6+MDuFrp9eo4UJOOWExQvz2UG8v2RiZNtjy2oqJWhhErpED Hs4nPghOsK/rK3Cv1UxIFCMExcu5xAkoF0B3KPsVRTZHkUbyZ5zc+l9LYospG0Z4keTypiUSXg+k EyxFWDdC1HwdFpuxkV+CM4kg+pGHfuc2d9K1ZzAI79LIKmBmTvzxRdh5guB86mSCqfY/pF7iHrTW jVjYOXjKvAYXplRtI6dRY4K2yPkqF3ShXFFs4m65xwE5+Nasew+GUIOQ0bsW7oBOadpcdeCnn34a Hdphsp3Tj0gOux+Vjig5FhMRRMoxVeibWm+MN/VUtMvkRbpCEyOzr63TF++2bRfuqM7LFfnXiVkl k/xSqkQCFB+DZC+WEDkXT1KvT3N7YiXUNJ4L0bQcVe9Iu7xY1ZwaQtMKfblK73VJdS2lAVzSs2U+ 94KTeJwziSD8HAvGUX4O1vBonuiYz3pvoCdko6XT0d0CVIT1oMRgKSVTE9q1WfgCwXVZyBcgI6Ps B8EysDhVBtYCc0IkZhaqNaGmyUTMsi9/E/CWYc/w0o9lPvVEqPedYylO+F2EV17nydSADSdbID2R UctdaVTCo/U27b87xLPlnLbzCuTyCqE8MB40K9IqL7uDfzu80VmRU7mQd44Oc03sovtJH9b0EAxd KWAupJRNJ4DxfNd6iUDuq7Glocu5E86xVLob49kcC7r2dQCnjLw/HDJPK1Ov6iZb3POJlF3KLoad z/F8Qm0DEHPZrk+tU5Dqm/enyPQdVwXnFVgegDzJ4AFZEvHlU9M9htqL22jM11SZGEeMDbjFmM+F w0C/1KlEwEhkDmhvUQ8vKYZbjReX+WU2Rx1doyBKa9swnCzqR867eaX7WMdihUiginJt9B68aXTH NHbD71oihQyBfDclQOWyzUWF1obXZzX9YilRKIht2EN9GwapQbDiY0xDzUFiqFVGWWRYitr73nBq ft8kdv8cgHkdYUxzcGvUFyZDMJvNMkxbLuAakusFl6kSMZSksfy/lsLAqgxT7fD/tKVpDiAbblNx heNC2GqWki212aTva/Smz7p2FDYxNNWihSSIzA4GWDKFQvW0xp2hq7TwlwKZejWGwtG8evCnGSI/ K5wJC0ju4sEDIrvJFJX7Zae5bUgmb3hJT0gWf06ETRMDjT2QqzGtsF6eLfKG65MH8e6p1dBBYkOd ht4HCRK9uOo8IVvPeY63BRc9b/li8Ky4ZYcB+/Ls1p+dbNF7ELyDnj4OH0v5u3BR08RdISWgWdfc INksJMMEAFHGRKRdQwIZiKq6aLS/+tOFEXHqQVc8D3NLFBUdp6RwDTge6Zljp+gtYHI5y85dD0V2 XjqZzYgsSjRRYsGP5VWG0g4YaQVkk5aj6ZsMj4ZjARwZNDxMhl2mOBT2Fk8zPK9OeF5AmgTJ33wk 2LM/z2Gf0XERjHNN6AHWs/dGlUj3MeREEjF3pD49Pm0lBw3ycnZvG4qFbFiac7BaPlv3+jDswAmB aFW90sib9id3cOi6KyeQMBcHemKyiCYzswaSIF6RHRy7SJRNkxbM946mwzWaxhzdT8hiuywAXCnS iUU1+LKyxUJNvkAw9WVEC94cfq8OTwvCG0FgiXsDjQ9I3nn9gQIc0qnbAHQKOv6Hlga04yLJtrbi Y54GFup+xj2F+xSK6+AIZWq443rP1SK8guuryTrI2wT3QVCn9/X3vnivDh1OyG5ScioxD9XqoHyf XGTm8Pl8+7wK11CFcKDYuSDkcegrMOy+8YjbeUMCfpsZS4RKGlMyu1AuZPIiLz5YElZV3MlB4P88 h2TPxsjo0YqRVZnsyLZSKddTlYpGNQQx4pVozZVJ8mena9DVPUSSANeySU7FlNNZOkESHyIvvCwb tQz4BDaw6aPvnobjZRsOYwL3mWbg48HKGBdQZzy0VWThxIC1rARRfRXIBmbuYW3qWpaWXY7TEuig ICgAWDaKy6LiMqRsJjp51EZh9j2GMD0TFILCtu4pQ6b0j0kDPSn6oQnRH0jc5/Vt+fzDgpx05qVA MRPTmZMAZzkzfqjKAtcLEH9AxvGgVHhDJ+gUxcuGrlZpKJLnfI0BvJkcnTkCWkr1X0kZJbuqWlbI topqIVCFWwu8/DwVd6yfn3dg6iLO6PPvFDNu07N4EpnDscbSJ3R6zJNjiIqK7hJ4gY0MNdZz5k1i N1idDDL5PJPPhyZUR3RyHMTBeH+83wHu6KvcKMIFBydITIhG1giz45J35Dthex0ZHrEyjxiVeIrg A0E5ugniZMQNOsaUZZkH+p4pQMzKYA1a3MFCAY54rSHL3nCOmMaACVvrZ+vo9Gi7VZ+ZZ6Vxq5Az TRpNzyAk7FhGIvPDDASJlAiK+ZiAGtMNcBooneJkgnxK5wPD1yQwwgaqWLd7FLxnHH9p98qRt5S3 ijNMz1phgra8kUqlve+Qf4oQWsXlKoP1BOLYKwbBARcDIdJRihkySQsdI45U8+PWG2DvQkDGovQm JUekNaiEsANwdDmcgk2QZ5DwTwWQ6VoWwwqNHmWMqbumJ/hOsSK7DEDGspZElptAzCW/vFYGx9Kg 3VsQlDomU9LpkY1uSFF9xoFRUSs8RG26GYodzk20blRbSMBFgzSBRSipL4z9gNszc5qFO2Y12lSz T27Aok23t0wYXuiq2swZRnhO7qE6QBQlAUPaweOiBhVc9/ZaYWq5sHa27lP9IXckloXf5JhKTkUM 9sXHnHgtUXwok2KXXFZ9AlG1sM8pK0nEPDIwZIe+Zs0dn2rcZOewMXqVRQs4pXmzlBMa0onEb1QZ D+Ys2D8yWHEaAMoJbOsC+gLciw4CG1ohiC5MECTLlPnCyqdowVw4uDdo2QqWyrxSn8XSf06vFTqR hLyyhGwXbBQUkN7hZY4ZnN5aD8cHQxuNqzvyvshBKuBgmPdow0lOTIrF1vv3J0f1Npm/FEMW4yYI GQko/3zp7gpHrBp7AjE42BZxlEnl9jBBSAWKOMyxqic2HcfF/gWiLbGdvb0Hjx7/daiSb5oMCicc DzRqBrZkgA7s2hd+Ozk+Pgb/sZtoLdHDSwW/uijBbkNP+S4hU3AtjhY2imIzj3f3kwLDRFhKdGT/ Mc3nGLNSYHQINWVv2fFA1NfYdwWxF+xPcXow2i0EehgRDdwk5vksg9Uhx7fx/JOiineCb0eu1Mvl mXtvvvJMCtrSKch8uw4+VSgmzzfxrPiixzYZ9U6aFCc9NMtCqNB73OtTJfYmBOqoV4uzcl5zqrl7 ehId9xIclEBxYGl1K7RgkeAirabIClHzdldUAdGukmQB/xqLN10bZoXFNh4I6G4vlhA86OapsZ7S D0kAy6IgE2Cwpxv1NIUI0gXIdGiJRRalhRclqRL46lKCdKU3DovoAqYQQ4k/4QQ63hnBDsEGNUb0 zCk6KPMaP2ku7iBg/F2qDuzgsKHtBM6ratwU9uma7KIJkYHducs+Ai3VauG4nsCwIUNB7uOzle/P T8HDw3lm8xlYNRhHfk0Aj8knBE5VY8pkITgxpqwnMTlT6pSuJao+LNHWwYu0xyPZso64UZKOQwsS FzEW8Z/MPfg2bCV6OLlTVOblhKMi7g7sYQ03p5yoVJpph16lau1Gg9YEMvghSIZihlmPs9W9WS7D QDzvbYlL+gaTJH+R62/yQeUJRaYCJsntoKUozJgdy+xNZgJPh2hCOTSuN2j/jtSIxDkadAoaMwbd U8SdiWBnWzAhUZHkDNZrzoZJF2VXoGZ7gt5uQjUhu/LJ4xNLVJbi6CBtBbxGcUCq6U8VXb+oIp8z eFZZ0nK6yXS44kkEDUmsZ7e6I9qhJ2gbsBI/MriRBsOegagN5AXYIjiK6ZSjHgAZ/hNJz65N905H Njl8FdS2FLkrKpcqI79+fZFc/CLD0CjIQJu2qURwR9MesuwDL0TYyLYNyTmeRiJYPK6SqBGIqoIQ 5jg8EpZtSp6VtnQHXAubQfUAQMbcfYQjg5F41gTKJkbIErNlSEcKY+aEsUGM8zzQEu1nq27duQEp mNPCbL4XhYnIFWk/2ti849YA/acQ8BLAHBnPPAX6wqTcwcwp3HxSXuZSnN4pV8n+7v7DrniRfc6y 0kpou044VivgNKgPAdKUMT9T8qCJ08zNYMPDM5mn+aIm7UdMv+sSfU+l9Sb9kDEKKfddZedOEpFr Gc0e7B8m0C7UdjlU1C6e981V7HqTqgsXqeReU961Ezg1lgs+AWmbFVrVRNkMT2TBidc+SNCSvNfl 9NaUQ/Wp4YgwFg9AAHbbB/mMyKbIiEPDJOLGUYJJxKaKqxD+VVJwMhheXOiO84B7KC3TpZTKVrge s9kM442MCIianu8aVVLvYTH+aNgicmdMsukSlCkJfrpkOwmvMZx8ACyE2NARybGa0qy/y3mRdQr8 lJQ7CgE/z9+M9vbGgAxwiQAi5KdnCgNNl7qkCap+gjGJqBgwzyuoqocTv5YVGNO1Jd4CuYjDdoaJ V3IBbZpsK2nTANo0vcuUU56xmkaC5Fy3FgYCAjAFGgqHZQ0Ull2PTpU7UbVayYzODF4kppZV/obu SvhNpdI5j0XYgR7ddxiTlYLzte/85cXHvMF7b0X8GIuSoMUV7VFnJD2UyANhGQpeXfEVXq5o9EP3 Dac2VvzX4Mod+nNppk58lKbvwfcYccME5eIRJlUjhL8DEPxJ5s+gUJujnzfkSxSJiKJsDUxe6Rfq mAA7PrLRDTNsyqqThbvnHWHLE7Cuz7PpOUkNITRAuG3ecIs6boUV6N3vjtirCQZLOAkTfL545WRX epCu8Ohz6HV6CWEP7j2IIgAWyCjpJKJCDI7bgtkSYT384NRHjJ5HkALFrdAE18xlVmJA5BXGXThu zjsEKjQ7xkAix4MH9jn0rbilp2A6p6eA4fFDTHNZ5d46dAzbXak/pu7ITN2/PoL/0k1xmPwhXySH i3oKj7/LJh/cuyjLwQ18OGdi/y49Q4zYdylsJYTEVhBnuHLP8e8ZOP+/A43JPXx+AdTsnp+6puFH 1xoZW15kbnZHKSbiOxqDpDbo/jkpohfpYpi8dXvi3nD6oHtWjemFo9RJAcPkj5kIE0fpFQ7wZVp9 cP9w7Xznjpv7Msvo1wYwrZYgkg7x66n7F833BRuQvpdhP79YOr75PTTyU1bPnQD9fTbH8b8t3d9B M0WXHvb1PYjIlVmZ76sshx9+yEoIp/t+XoK923EFGvkPWdOs3NDfXICA/6MTXtPF6Dt3+8LyZW7a dAP96DSdeQMzeteAs+bHDFfEdQqOrx/d1Tl3S5rjlmSfkh/Ly0VawL8Kd8ocUYAwT0r9j2X2Abai SF6kTgdxw3iTLudu1ins3+sqhSJlteO6bjlTQOR6mU4Oq+ZiWXHfNC1aQrdaKVDPy7RGLuXG48gg zeYwrvkcR4ibkrws0eh+elEu3CF7lUJgAck7bipV/iF55daxhs35Y1b8LU9eN24A35VnbnQVLsYP jj6L5A1CJcE6/MHRwdt0Ws5m1Mw7pxe50b7NpoAFBY2ugBopI/W5O89O+YCgZsd98ytH466F5RRG 9m6O6/Yy/0D7/s5d3XnzM/R5nDt6hVnPZlm1dJ/84KQg+Dd88DadX7qvr3KooEWDPk0/pO6Sv8hp SG9hLRy9vxq7Jyu38UAxZ06yccuQLmEKF0VyCrAKFZ6cD66zP+XV9CI9d8O9AmvmkEnxLC/do8ZJ XTSI0s3uJ6dMXZTuKiKVHrbTLQD8Gp/wq1JuoLzG8EGQlFBSl5DXBV0gzK1CNsToSeFOkx56Bkvu 7ipmOkNS+d3RusjmlyIrGhFmppwOGBG8cF6Vy0tOTID7CQLJIUegdOSoSQzMPNN5aXL4r1KGnHBK FBox3Q81Fy5DFfUiP7/wYg5k5uGYmxJTXlhcAPyXccekHb+09AGjA19khCNgwWKG7VnQTYEQbJBM l0BCXUV/H3qkDCdcVO5mnXYqtIhHdQl0PEUGvsiLKd5LIq3RLNIiPe+CaPlJvBSoa84djdMF64jN kh+KQxyYY7xL4OfqU5h2Fvl0Os8YXeXf/sdvvj5LES3xa6frgE9vgsjs9t+Cu3yPIRDu0XNHmgUZ E+HWfnYK0Acinp2EoBFuV6QYO9SIx/cB65RCq6CaDORafHPvx/Hp+J670ivQQL+556+zewlcvvQr 33WnH91xNzcejOprx6vdHUOwLs++3on+Sf3Be2gIWLjxX3xzz7HEycW9ZJWlbop7T548uOdehRcA opHniDIKZNiDZJ/QONxq3CNLmvsMlsUphrDAum5rlhHAYTqXMUnPzhz5fXPvOYMIELzMvWcoWL2R 2hIhBk3NjORXX+H3r05eHZ+eRgsN/ZKUCH91mqjjf/A314o7tc/ejF+Pvys/JQ8fP76fHM/dgOFy cGRKj/2Lr0aPdnf3k9O3r18d/Xh88tK+gmiT1erZq9dvfzr889c78u+vd3x/lxdlkT373cGj5NH9 5MGT5NFu8uTAvYA/u+dQAXH+jCbrlsVP9Nulu6TdBT8uyq936C1HPDylPjL6Q1osnQhuCOmxEhKs SJWlzw6NBA9IoO4n9+hDtoKkkGcEbeT2/BhAyDMKvz5N6w/gaYKqFvKi+cZnzYrNyb+2nnydYujJ 9zET71oiR6K9CZHv7T1ZT+RgafljBlei4/T3nsFfYeS1WpAcW3bvoG55Ukwp9+qtZ95O/IEg/3UE /86S+3dVOnVs09L6u0nZNIk8aFG4o46PIAuwqzNvVjcj9r37D3bh8gWr+UcACW9R+fN04bRCp010 PHt5mOzu791/rI/a5D1KfreXPNx7lBw8eZDcf/ywTeCjzWk4ZoWPWhT8A2nnbeLl/wZEmp7BeZpY j9MJRVyb+53MG3It1uptIEJQxwSEr6G7fqWySAyPh+EHEbjMKebO+rZKd5UXHMFxiYLZzxiB2OOn sV/XZIUP4yRQqHKSZ0P2WuTSOhcIa2IZCMq3eoAB1+j5EgIgoBcy61CreQHlIMqKInwwx64CrbvA 1EswhkOoe+FRqvJKu3uKJw29fH692TjxQU/W//yvZdl8Bblz9Leh+QVSI8Nf3x7/r/cnb4+Pwl/f /Xj44kXHT9JjqxkKRe/6ravL569fvjx+deR7lSEe/ll+ESU+kWeELHfIo2rVL6Hg71KzYnnHMHgg sj2CAgAGYMe8RCjrcp2GxQlmpS81pRQD+AhSaFlLNSjJkvFMcuzQlySDzU0VrZUeAR2NHqsbMPiD jRg8MOybMPj7T7qFQWXw4E34gZFZ3q2KJv1075ljpRhn9VYiwcOIkbcn20+jb9bx90CcEaPEiyyz PN7aK+BRi8u7+8cdvp/A/fdTdobuXAAGWS5uxuxfnpw6KYyzUwjE7Dk75pN3UMEYfIivjg/uj+4/ eNjB7h8cPEhOvZnu3X85gSK4Fibu/rEXBv4bd+cchvfyEPbtnEcKseDP4Pp4AuLRNAsuj1k6qQGB yMlHe1vu+tjef/B49Pjh431HU/pIr5AmX5zNv726P3arsf42ae3P21DgFLOL3R4wx5yO1SLT3p4j yCdoxN9sjesg98ZLfLM98xc7wiO4C8G1XuTpMDmpPjr23Fp++Tla++fttX+y//DJo9H9g/0H123A k4Mn24/3D0Z7j/YedG7AjNfm23xSj5eTfJxNlzfciBd2G8QcYLchNBS0d+F/Z5WT2t8cvn1+sxW+ 7/64TVoBw/wRrGVvy3TaWtY36bwEsKdyo5U92L1/cN2iHuw92H68tz86cP13LuqCp/qto67J+BNM DwpVbS4uHS7Pl3VzC4l/yazQ143vEPEdR1wrVbFZfA1bJa5KqFoYgQk4Z41E5asKUXNbCI7Hzi0J m+E+0RvBaf82oy4Qn7gZI0QpOleN/BxjB8FZ76Oo0QDleinngIWI17t3CkO+CuJRkK3Gi05ibyDU rq/IhfcxrznyoMou5+DF5rbsQHBwuQAw4I2/9+j+Y/wM//F497E3oTRqLukN6UnBR7BYoJhG+NUQ nwBZlRR1AeEN6H3FmXNT6LyQSO7IWYpJNmADYA/DYsGotE64V8hL15YulFzQEmMFbgqt/4OxBT5M KBCdIZiMcjLJlSbBZx74DuPM2lKyhPvQGqjvjjw/2JasCeyTG+tXLDGBTouRMWeZ5C54GSl3it7H fIpOcVqlIBJAY998zERbMnI/EPA3OpTunRy/+wEltnvBocHpXKaXhLfDnvs0Gci+DdD94pPrqTQf J/Fj4QkhUydaElzdSZPYmFIia10G9KJaDDB8h2BI6OgF+DS8apTrZ8rYXSmFeYqirtDAGay8RI2Z uDnbP5tWMRq6cUeRUlVLxOkzxyYcl5GZfW0Itz8csQik7jdHIjxoK7Flv6KokkEilhIdZhJNOIzA g3DWlFXApE6pL4I/zGErQ451mHMuvKf7UHwGwriBaQ+F3A2FYp+sIUEjpsQRiU87p2934KbYgVc/ LeYj+IeT0napGFdoUz2mqgOwLi+xLp8a+ZIt1812sjfebQnH8cUtwvjgp/vPB7+iqHtnAm7SId8m bfHWWAXfv/MWQdi3lk0wIZvJ/oP7yf7DvfvGZmJECH3pcfLgyZMnkQyxrPJnwe5OSDqG36FPs3pr xLLB6XigYtnguyrFaKXfhBu480z3QgTyM/fmt4DFtMQj2S23XNP1H2zXb9Jynm/U99+ytLhMv13k EJhfzprP6vv5+KXt/Z1jCWdZdT56OflfyywrNhrIZFEvJv/17TKfdIvD4RCM4Db4PjurwFg7INFt AGdwwGdcj2DMFfD8MFcYcEbWTZjC6NXhy+N317OGJ8oaMA4PGMST3b29gy4G8cpH6uWYs/SFG3zh Bp/HDY5s1z8CzAYIHBv1P11cfItlfi8uP6vrQ9v1i3S1SDdjAClESVzNb8aKLB9gn41hA09uzAbk WHcxg17D2e7Dbs/Is8MiOZZSQyBLYULkU0H+OqT86BDWcZ117A+B7aVKiw+1Vfn/ME74x5a2v8Z5 2urlje3FxsLYvt6MgzCZ2/UYzAtqi2ZuBapoav73u5sdxttE06LfbtXHYdDHsmxAybPdHLpu5Odb 9XRse3qXFx9sL8cIhPfhdj0EhqZ3TXaVVk1gZxon8utN+lnva330GU57PIU3MXfvPnzcfWp/XEHg s+O/BN/ovoXgc8KhH40U2mLdSX17rZV0nYX0s88OxbFFB4d/vLteXpbny3nUCf12qz5+DLnbqm5W ATn/COyNfr1VPxv5GMbrXQy/NmU/3lhnlQIlbfFSZUWudTJ4xn95uvfk8eOxk/GmmUlj5th5DflB 8VV8asEfSIuRaJXxtSLrs6DmU/LaCgXQ+zv2JfNv/aJrLKXldTmeXJCQtlZcEPHgsdMSWHT4/e9/ P4gkhc2W+vHD3b3r1prekb9BpGuTmoIWDAdcQQ7muQTq1SPjGPm3/2FeGI3etvZmmjZsJIWE4XYE xT/fHojItiyygd2Qz9oEzA6/bhf4JffXnZPj5/RPR/lPHo4DH5QJrB8lry+zopPk33GiOK6jAdeF Uu2IQv5GskLACTXvbGPr7Zvn2/8CW6XS9MMbHJfeW3fvYK/71n3/9tUGDuK34UXkDkpwq67SIqFf W+t4ePo/08XlVzcMb9t78HB/Lzmqsk/ZPHmeV5N5l+77epFepF0xb8fJw8d79x+M9u8/eNwV8Pb+ 3eHaaLe95GB3P3n85GD05ACczFEw0N/S1UV69eHbaT2mWg/5ZFxkzU1ChLovp3/byOHltqzTx7XW EdYRRtRydlHhpC3Xfr3N9XyarOBKCRQzndYIcgkFv4qGArQRFsmNdJQXBCCKYC++DI0p9Rn5PqCQ jzjLriBADJ00aVEW6BpjPxcZ8F9hIJDAuYjVv8TkdYMJO8/OAeYQSy1lVzYJk3xZxmPD7SYBV5eY mACYHZaC3yKktVwLPQtySzQw1y42A/05cYKP4zS5gNAlC0eQNzeNSAljTdyx3lT4xiJGPUyA6hul NO0AD9X9DeMFpI7fOi7xveUSf86q8yxdWj7x/TiRX+9OtHv8OaLd/qMbKi37fQHbEKctIafvNB6P a8iD3vKWk3ST+7eKsBz3h1duuHSvJw0kYJile7jh0tkgqCcbxUDBet1gffce73ZHcj87hLBdoEE4 rd/lZ/O8PK/Sy4t84hYWqrOvjVsNrq0XKWQnRdog/3grzebI9vK8vAiNDkcg4l/c0OIQkLwT1m4b WQ/ru6kq89P3neb16Tw/QwM7/GXnb8v56snDnXl6Xv6c7ew+or+ML5rFnKyOMjQQuX5jDstPaQVZ Q2AyW2SQCPM0QegPTBatkkMnbudQxANkONjzI4wsyihC3zGil1mTAu6o33aW637T5R8JTKIwQhzc b34ThUbl5xDFmrzIzyrIfXUXYgZBvMkPkKAzdMNzxxv8sf3xyzgC+L/YvEoL8+2kHk+olT43ixuU JwARVntFwT+49UdZEGe+Y1f76393XOdo5CYTy78v0/P0Z8q+c5/vUORNQsL4aBRRR/hpD628f/fy 8O3z/h2n5/1n+GjdTj4Ld+kVw6YfUarOQqpuYA/KeofJawBhd3P8CZLRivMGciafP/Vr8dz16RQN cHofCfAI8GeumjBUMoBQtrI4R+Cm/rPq9i3cpIOWvB7u0Y0XGTxZb06er/V6XS7Pdn766Sfwfsnr o3l6ls3r0ZOHe7v39zqO5m9kl+BtcD05WTtYEfqJtAOJEjQFOsQ659b8T3AsAMnB2ud+03EkA3fp y3w+z6qBZ5YDMGnRjx3n9HO9btCOPWfunyrx/wb/+VkeuODT69xw9PLtfHHcRqdDDh/tBNO61jGH L23qnIvVaFGFFrhdUVgrt73en4cj7uF/XaQTuPX+WKXL+kN5ObPUczpO/O9mzNf7/vLFh2/ry9U5 FHXv83/pzNcP840dprtJ3HH5YAf5ZpzIrzcZIugf8NG3FV9O47TpddVtONSf7FBPHaXWmR3pT05f ox9vtJb4ybdgw4Fwm+yGg7RmKpZYB8EFuIM8TLnpb9b7Fj3vvEle4RM0lhhOGUXkA8M5OvzTvWdv Y4Uy9RzUqc2HCtwM3JOZJPxTHRti+A252cbeSMzPDXwCJm+3L/r4OWfHrLVbdVllHu/uUq5+fllj AHKyt/94tP/kuDO1ina8hpF8e9UVG/xv5PFHOITYILZW4A70TMoMD9RMkzF+XRz8Xca9fwe8v0i7 DE4np4cvehIsOTYdxgxSortez8pxfo0xqcMjGdDFTyBEQ321yDH5B7Tw6FNEkfjnSBXoMOO1cwck 2+8wsWkBHbTnb65HewcjyAo42AVDXkcAe/a3q1skBByNf7DrTjgagfqH+Bo/jBli45elx+/cD26X rJ7SWjx6p4tIX/YYRTk+5XwK9Hm2vH6VrPYqUWK3CPB3nLbT3nmFPBOLpl0Bz1xv7Xy+rBBsO5Ib t5zUDAH57u/bJqFSgAyxknkm4PUa2R8W9BWgzfJKqqFmU4Lmhwja1SWEC2O5kROBkCSIoCFDcpH9 EpIpCfSZIKboXnCjw/BihEkoTN1LCZnWoumg9uRoeyX46HkWj2YGhe4hGttRB9QKEKPppCxmbjpN y0DLRk+wbyJyhvt2lqUNom5xriijfbcQIfg2xJtykxtRSs4TvMUFAurkMwPDDfX+KL2TICNo7XjS kxUDuC5KqUhL9lfZB42WHppCG1LQ1JcYQ/wmKo0hi5SFSzTU/rGehwef0I04c3oqQIMAQv6Pp4CA 7vaedgtisO0AmLqcJEfrM0KpBYqfoY3DVAvhb5QA0VLO0Its2k4FLHGi1hRshHv19U+FeD761XcP SqG3WxmkQXS6iah1sHe/2/B3BLhpgIVUZWrzwZmrt+JIajutt6sGkTQ/ZblTaQPDarOEsoQvoHY6 Pmsx6NfPXzxPXlNFCGXPYiN4nhH0z0kxGYvpAfZATEg3498PHzx8gMFkzc/J2+m4FcZJi9JK7nr9 Yyu56+D+7t6jrijO6xxfD/cOkkcPD5KHu4/3umM4/Tv79w8OOu/UK1zKb8vJfPIZ2Y5/GAeRXH9c Fj8HUSKI3XLodD180Nqv/mTEd2mBqzsByhny3iFR/VHQyJKXeqBvtnUP7u8CXFMB2H41wBQAgtOn ZPfxwW5rG4NxbJaqt3dwf0Rt3XxLH+ztJg/2HySPHzx60LelB3sPkoNHD5ODhw+68/z+ln74dvJh 4cSkevYZctLz0BIPNlG7pc/Tap7wz60NbZtfh+bvehSBwd2lMNVOWm0u0kna2q9Xf27t197BY1jG zzh9u2B/eeD+e/Cw9/TxOwcH+487t2pDk/Pa/XoZcM1yPrO79TKvL9zVDr+2NutttsSSGS+gOlE2 vaGC6bjfPENPGvy7tQMvymJatvlfa/2Pnx+8SQ4O/9CxBX9cD3NzkOw9cifmYD95+Gh/v3sLzEuP 7+91c8AFLNH4yi3RtxWtyM2yYt9BxfFF6K67qdw89Rdkh/RsLtjO5wt1tGwGhROIAXCt3wgD4dHD yOIitmlA4nqJGWynIMdY63LbonVbNfg3bdeQ24fxZ2nBv2mbnWO7829uoBSHH7RU4/Bxt4LcMuK2 TMa/Wa8TGyvgb7oseS1rXscOvQwz6D84qT9gLU5LdoIeP+jcku+Xf8sTsmTZTeHYsOGtNuKP794k Tw4f9S7s/miv99m79EM6LZP7I0fWi/69AZzEpl6OPix7X/ljepXW6Yd8VF/ka15ygop7cfQhK/rH C/b++Jnwvz84fbOwToTYxp/00ccCd+nbmdNcxzO3HWLaG//tsk0r68jlNxG5hH7veZ/VAHe0lwHC U+FZmM3luZt9BLpZ37MLjUVvJBZdFNS+T3yabd8b/fYKnI83WcA/O0tfAEpxWUvti+yKc3vr5Rkr eTDknU+LucYxGUMF/D60oGDZJwxtRQx39q1qISu2aVRe+y0rrDdxXTbtOCyIpS2Q9QUL5FBA7RRr ZILOiYH/p92B/1zUGI02BOrIhpsh1TsoRKeda3l5fF/LXngzOxtD3NLTyvh6lFxvDcAmtSguGl2W DdXg4hLHbiMWgCM/ZueVYam/CfLmiRH2uyii3OhHNwqWub/be1k+19g52ATvlN295toMLs3vylWU BQT6Fv3afUe+WVbZMShP7wB5Am1ioA9vxolZvTiD9r+VlkI3wY1vnV44tv3d3b2Yj6iVQ8Cx3UbD 8m31k/q2gZmqlfBSKQ4itek8HpuWAoHAA6qdrKGBjdReBIgQf1zl4MGRHiZny4bP5EfQdQBp1SOI BBGMWrICwyfBzkgt4aGrCQa+aQgpAqbpqAMPQCsLlqEq2ugRAc6DExMvymlcvSjV4bFh0A5xGMV5 AmsZdlQM5FWb4AVVB6YvAbOHveGZjaHc4sSJa1QoDdQPts/66g1pMsuusKFlgTXJqGA5WhqBpfoN I0gHAD9wy9IaK2QOKqxD+OF1m4z4KbkgSdtifbzX4wAWLWgb0OZxYNMcQJnVfBuMrnakDsg0jAxi RkCVAaBv6UuJJR6MBzmxEazVcs5wMUSKRSmFBrCOrJB9VBJAqxYuEaH3DjkncsJNw9ogy/Tk1fev 3x2fXpM+DlnjgMrvTvNOV7440GggeYKm+iVj/F84YzyISnpeXl2bOr1pw2+DCIvyLP+choOYCLzO JCICrrOb51rrKeg8Of7ftWj6QV0JFq2OhEmDWp4cKRJUuyQmf65lu9NWoWP5dmjKPWA2HPAbRghd V+1ZboV23TZmuCoHApGnC/aFKAenSm6mrBfWREUUIizlQ/Bb3HKAeuU5ua8zVSd7+9jD3n0PfjXL z51o4za6QkH72df//pfnR4enh3/Bj7/+96PXz0///OYYpNNp+nEEl/JfpKjhv49G35g/VG5bponY 9lKC0HX8TesPRnZyS8cvjl8evzpNQC74iOWmki2sfwlljIboEIM9gdrbl82Fu5SvHHv//RDz28pl 83vN+KAyVb/fTtptw1OoUbfqbBq/aL0P7LZnJDSEvo6QgrbQT9dumeqhH798c/rnns+pfNOW00nm yxoQ0v6e1BeOHU7bjfl3tMHgOX3X2xsuaLL1H29w27umgxNNDl91fc3rv/Z7Xwht68Idld91vQMP 1jcCTs2tupr8ztFA3fyuvQ7u17CFcBWqydr2sborFN9e1skW1Gxy5yX7HaYL4V8NrFbnnst7NMdh soX//e0woTa3/74FRxj+8bvt7SELnz1NhwPnMfXOTNpNsAfpcM3IO8dtYcPWrRP00UMLUlTsLHOy YO5Y31bpZF1HuR+y7NKJYh87TgK+0Uea+p2OyDXWS0LS/fISr6UtUKvp4GTN9u86Jo6PcdE6Vj1r zKOOnhyrnSZbTpbGBfk7/ga3Gv+13aK82n1I9fO+tWCOD9sTvxJwYa2L18eJ78ecGNlw2JctqNhP eNO8vpynKxx2/1vuVkShvmjmao/Z5OWsOI/5Us+rxGrXvZg16fn6N+Zp3Sicc/+bwMrUe+G2X2+r 7d92nSyMB8Dh8YkJaYzCBbaAtXV8z2Eb2dTfhnh76at/df/5619BNJO7e4dv83+7rpAi555DmgPl /506Pg6kM3Pya1xRMSAHrRzIylRYMxyrg0jjU4nn4Gy9UFDSbHmpcm9EMg+7eUlDitsmKwbX+5QM DhgDltxrl2yRDqQ591eAErfFSKFcMefLjY6wMMzZikoUJa+yq0VacKRKLWV5HKFglqUUR8SFgRJi EjSTQI+mtte10hZMaAQ3Kmug36Cta4TzHJxSBDQ+VzxJeSrvYwtYyQwg5QejAf2CIrr55zRd+QaC DsFk5DQE+hH+b1TOZo4ZCupr0D58cHB08sPJqX9IXXFr+/gwSb5KdvdGe/vmLTeCpPOt/cdD/M8T /M/9XfrPXmgQwE52YAwkKsM4L6AQT0eTu6P9+/6tRV4seb2itx488W85OnTk3v3WEP7zcNebs+ZZ epnwF14xkHZmVTqhdgZO5dr7rV8ufKNYLmiB4Y2twe/caYB92jZzGjwd2LH7b+VDav3/wKdhmwL5 avcUX+5t3P+bJtThenF//mIn99c1TEjQ9J1SBbC8NCoyRU3S+WRJJS7TGlO159gx1FJy4s770+fJ 1vOyBPNYKueUvZHuTWBX24hlShqQtyVhG07ngQYYzFWTmqdSNQv8EhjqyPocr6QWhPTDgaRqU3M4 2Xv89MHuU0cB2M7ugftrktfeIIfduwnt7z998Ng9/D9R6acT4mN2lO5zAPMtyJZqhtOUdl3ca8uC XmT9EArb0gzVjCl109NCGnGMczDahSEPFOIXjXR1wPrM246QyIoGMYDE3x2D5ZGS0gqKeJVJYV8x aF2WedGoziv3A2GQ9BSsal9NYGLEUlqcqQxbZPXKQeeFpl8dLy6bVesDWX34na9VclVpgCVZD3Oq QqM1wNnuqwp2yYdbS36D74WlEK7SNsurGo3vmE0P1cmyuBm6y/RmTP7nvPnq8Bn8/87hM26G+ckG 7WAb2Bi2syMtwPQCuwO0UGfuImvYBkwACO7vMY0K/HBezhVSRswYoQ3VDW7JGNbBLGhiua8sZwCK j06PZEah/YKAikm63crG5+MhNioCEflA6PkzOPwnM64PiipPJl4Pgh2HsFywhlMPSBXcjxFJhrJm VCn7jLGE9ZjKyHJBwsZRT2mk2A6OhnvicsPtPYUwbu2ICrOiEQirmcPQKCSYN2rDYthK8idzwJYg z5o/NDHZ447O5tkndE1I0OoibaRe7Acqkpyl9Yqit89ANaNAXfeGGOLdnVsn1CGwK8fDZoAcTyvE pHd5kc/Lury8wKiRwXeZ75iNW4hxvSqXYH4HzwhIVhCLPeHyKPzUsbTpgF0GBMldE5fk2s24a1L4 mSC7IRD9kormOpqYQzVCnn72qYEQcEf48WimWTrXKuh5XbPN7QrCcBJ0PQ39oaumGTlnc6c1U/X0 gn03soPu7WYi3JY6I3etYqpzQDpVvQZfKPH0jCs/ujHCW2wkhOgBOYKLLJX6QBG9GImdoD+KMvng GFoBcA/gYcGVxphqJphJuTjLC/ZFGe+gNuyOGywt8LOGEN0nKRx3x4eWxVWK1w2XfkZPdQPSbq27 A5cTfeAmMHektHDKn1J3m6KP6ZJNRrhjnN17XFVl1V/jHRYSBnhWTlcc2f/m7es335+8OhIPILAE mvHGVs/fQ6QCR6F/M9gb7w60ANs3g2UzGz0eJL9nfe3oqZoD3FdF/fTom8HR4Z+eam6ie4N1/x3z kyj8/NvXO76ddWqdWQRv7hXi0IEosQL4OuZ/+OKNYocoK2XOanzg74Z0psrmAol4SWw6PQN7CfAR x+pgV3DT4QhiQyiGgC2JYXlIDkkOnIC09V06xcJubqe248vGEQVm/l+UV1CnYMg3L8H6VAmTGd0N AyDoAfbreHE+NaXpAbrBTk+WgAp7JU219Oyc0hJwrFStGyidSHYOiSpOjOcqXDCC1In6xfQqn7r5 zCl4NMGYe6j6ZYGIMiyMTfdC6hf1iiuKIa9ECj3Lz8H54lgUxLswlj1NF9wAON8LCXBZLPBs4bLz 5KIlPJxOc4IDA+iffGYWD1iBE4tzmbVfNSyfsaK6o+xL57M0NCXdax49+vYhTaxcAP8EoVEGzABM buOupM4z1gGgX2teFa0ay9szxbLh+Ucuk1tStW59t02a+gGnArlreEkhAU64xywa5rFVircwVFNl /wfYL1COVEyj6+5Wz4nek8htJcqYGUFeTl4ua1ESHMkqx3HbThwwbzT7ZYqimTBZninwzowifeb5 JId4JEd1WqWeLl6qLn+e4QS9BwnPvOXcYygozadJ7v5C7hq498QSN4QyvWWBcQRO3MeTSAJuduUF x7MMi+WiTWYaWlqkd9fjdxmkmZGKYMmJWDNGoShnxpLeVPe2YwGHIo1xM3+j2Kc+hgJ2GqV4XEm5 ZvF7U1mDktouHSVNR2g11wX7VS8GfEw/HQee/llZjs/Sakez/XZwlDv+Kjl+Goz/My+PqNzIqnNV 8Yw1UIjYsTunGi5BSy8/JFQTr73DzGh5H5bFDIqj52lF+xYue52hsPkPWHb75zO24IYrfRisiUp/ m5AkCYQQnUIRQpIGh05uHwUDx/vSa8oUCONVbxZwhb3tHQyBE+Hxys8LSGHLG3vH80hxf4BlqHIi kx6ybYCr+Wwgg7TEL1mcN/MMi19qTNFFKushEOlYyTzF6+0j8lC6jeRoFxnM2/HFOYcf0aVF7vUu 0SM05tD1QFyPNekNxMqn/3JE2yVvIi9xG/AxG5XL5tlvz8q6/u3XO/a3z5VLW/chX3xEYY5oIQIX nzOFaJcQ2kAX4qWTjso6Y/uHZL6SXAI8iYLyVt4b4WQxoCWQFJxOO7kQKyzQNGqyQBWXaQMGfq/f t69uuIP9B1DuiA9QJ1fTkZPMhOI2K0Qq9UkVUWxHP9DJe+kQz+OUq0i1pUeWLqedIsx6cQaYhImi nFFWuaOvbmPaSdFUpZOu4qiZQ6cAQoQNlClzawCZxQx7i+VlJc1YLEUKcekPNG1KGnKo7gAaX3hh Q5ntpdeM/xcUysDWcdZ2Dn+hEMaSaSl1jPhp5HsSLk0y1wYDJEaCZolaeRKK1unHMne76dTs86WU /OIwJcO4nc48/qtOkgfKr/m1Dj+gJddqt45i/ksnjXQDCgMZzd+eYNEypwFNOLoWZlZMRSR/ATbm NxAqzMviNw5bghplG/I8lpvFMz3N5k/P507hqJhtuR9C6L5sPv6bI42swBBHz6/8lzCEZ5YLQtC3 O/nvL6fgpJMPdrq/MA25qxQNnl5o8s824GwnXHNYZVRYKb/mcpxxxQa+5UGSS6BYUJiYqpq9SNas BjewsZDkboDPXG3/5aar3f2Faai92v7ZBqt9/BEtt+Xy/CJYdjhhGj6OdjJyZsDSq/dGuDqpRLJf OR7PHgO46xGKDrpLyl2hWuuZhIzwNAzcPAYkHGP5SdZL1q0zMT0S9go+fHS5eF8Tto32YBiHWsTT czKpsrgNNwse2/ScxqWlsGV9KFvELc985Z1SqVp/WJYLb72NKczJGU+FuNzf1xEX7rSnMPxyU+Jq vUyft0kKf95IKokoqJMIZENAO9clcsoxGFiTbgJpEYcbUZs48PNr10qcbvUaMlGC7CQVa7gJqQQh s808WTYqKd2qSxLq9kL0ixy0U3DKJx/wYTWbuP/+P1/+fPnz5c+XP1/+fPnz5c+XP1/+fPnz5c+X P1/+fPnz5c+XP1/+fPnz5c+XP1/+fPnz5c+XP7f58/8DwUBCxgCoBwA= ------=_NextPart_000_0034_01C0F8E1.46A98A20-- From w3c-dist-auth-request@w3.org Tue Jun 19 11:59:37 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24875 for ; Tue, 19 Jun 2001 11:59:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA21381; Tue, 19 Jun 2001 11:55:10 -0400 (EDT) Resent-Date: Tue, 19 Jun 2001 11:55:10 -0400 (EDT) Resent-Message-Id: <200106191555.LAA21381@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 LAA21326 for ; Tue, 19 Jun 2001 11:54:58 -0400 (EDT) Received: from d06lmsgate-3.uk.ibm.com (d06lmsgate-3.uk.ibm.com [195.212.29.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA11036; Tue, 19 Jun 2001 11:54:53 -0400 Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate-3.uk.ibm.com (1.0.0) with ESMTP id QAA175074; Tue, 19 Jun 2001 16:45:17 +0100 Received: from d06ml034.portsmouth.uk.ibm.com (d06ml034_cs0 [9.180.35.31]) by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5JFsLW112204; Tue, 19 Jun 2001 16:54:21 +0100 To: w3c-dist-auth@w3.org, ietf-dav-versioning@w3.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Tim Ellison" Date: Tue, 19 Jun 2001 16:54:54 +0100 X-MIMETrack: Serialize by Router on D06ML034/06/M/IBM(Release 5.0.6 |December 14, 2000) at 19/06/2001 16:53:36 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Newbie questions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5033 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: ajk@mds.rmit.edu.au (Alan Kent) wrote: > Q1: When are null resources created? You can "lock a null resource in order > to lock the name". Is it that if you do a lock on a name that does not > exist as a resource, a null resource is created? When you do a LOCK on a null resource then a lock-null resource is created. > Are there other ways > that null resources can be created? The text says you lock a null resource > to create a lock-null resource. A lock-null resource has properties and > appears under its parent container. A null resource does not appear under > its parent. The definition of null resource is that it is a resource > that responds to requests, which implies that it exists. I also find this confusing, and I posted a message in response to Jim Whitehead's explanation which explains my confusion. If I get a reply it may answer both our questions :-) (see http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0285.html) > My guess is that any URI that is not bound to a resource is implicitly > bound to a null resource which has no properties or any other state. Not _any_ URI, but any URI where the immediate parent collection already exists. > When you lock a null resource, a lock-null resource is created allowing > it to be placed under its parent container and have properties. > Is this correct? You are as close to understanding it as I am :-) > Q2: Are locks on resources or URIs identifying resources? The DeltaV > documentation I have read I think said that locks are applied to the > resources identified by a URL. Essentially both. The lock applies to the resource (you cannot change its content or dead properties) and to the internal members along the URI path (you cannot remove or rebind those members i.e. by DELETE or MOVE or COPY) so that the resource cannot disappear out from under you. Caveat: I've built my own mental model of how this works because, IMHO, RFC2518 does a poor job of describing it. I stand to be corrected ... better still I'd sit to have it explained clearly to me. > Q3: The MOVE documentation says that a successful MOVE on a write locked > resource must not move the write lock. (It then talks about collections > and locks.) If the resource being moved is locked (that is, the resource > itself, not the collection it is in), why is the lock removed when the > resource is moved? > If the lock is applied to a URI, does this mean a > lock-null is left for the old URI? If the lock is applied to a resource, > why does not the lock stay with the resource that is locked? > Or is the text in sectino 7.7 only relating to parent collections that > have been locked and has nothing to do with locks directly on resources? See http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html > Q4: PROPFIND in section 8.1 talks about responses and errors and multistatus > XML elements. I have read the text several times but is confusing. > It says servers must support returning a multistatus element. (It does not > say that it must *always* return one, just that it must support it.) It > then says errors must be returned as 404 *if* a multistatus element is > returned. etc. It was not clear when a multistatus element must be > returned - is it optional or mandatory? Related, how to know when to > return multistatus elements in general? Examples of packet communications > are given, but no formal request/response packet grammar is given. I agree that this text is confusing. FWIW my rule of thumb is that if the status code applies _only_ to the resource at the request-URI then 207 Multi Status is not used (i.e. 404 Not Found, 301 Moved Permanently, and so on). 207 Multi Status is returned when the result applies to the resource identified by the request-URI and other resources (i.e. depth > 0) *or* the response applies to any number of properties. For a discussion of this topic see http://lists.w3.org/Archives/Public/w3c-dist-auth/2000AprJun/0042.html > Q5: MKCOL behaviour with message bodies is not defined in the standard > (section 8.3.1) but may be "defined elsewhere". Is there any such > defintion around? Or is the body of MKCOL not important for > interoperability. There is no such definition around to my knowledge. I also haven't heard of anyone using a body for MKCOL for their own devious means -- did you have a plan? > Q6: Is there any clear definitative list of which properties are "live" > properties? Do you mean in the spec. or in the world in general? In the spec. it is those properties whose syntax and semantics are enforced by the server, i.e. all those in Section 13. In the world there is no such registry. > My understanding that any property that is not a live property > is a dead property, therefore if I used a property name such as DAV:xyz > which is currently not defined, its dead, but later if DAV defines xyz, > then it would suddenly become live. I assume the protection here > is that I should never use DAV: because its a DAV namespace. You are expected not to use the DAV namespace (despite what you might see in some implementations). > Q7: DELETE is defined to delete a non-collection resource, removing all URIs > to that resource, not just the URI passed to the DELETE command > (section 8.6.1). Strange isn't it?! BTW this is explicitly overruled by the bindings protocol. > Other sections such as MOVE and COPY talk about deleting > the destination. To me this therefore means that if /foo/a and /bar/a > are bound to resource R1, then a COPY with overwrite to /foo/a will delete > the URIs /foo/a and /bar/a and resource R1 then create a new resource R2 > and only bind /foo/a to the new resource R2. Or should /foo/a and /bar/a > both bind to R2? I noticed that DeltaV changes the DELETE semantics > relating to versioning. I believe this is the issue OVERWRITE_DELETE_ALL_TOO_STRONG on the WebDAV issues list http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html > Q8: In DeltaV, versions are given stable URLs such as /his/73/vr/1. Should > these URLs be made visible via containers? Ie: should /his be a container, > and /his/73, and /his/73/vr? Or are these URLs hidden from containers? That is your choice as a server implementer. These URLs to a version are server generated and servers are not obliged to expose "/his/" as a resource. > My understanding that there is no standard for "/his", its whatever the > system chooses. It just seemed a potentially very expensive operation to > get a listing of the contents of "/his" as a container since it would > contain a child container for *every* versioned resource history resource. Agreed. > A short background - we have a document management system are > trying to work out how hard it is to support first DAV and then > DeltaV. The document management system uses the DMA versioning > model, hence any experiences of relating DeltaV to DMA would > also be appreciated - although this is probably the wrong list > for DeltaV questions. Check out http://www.webdav.org/deltav/ for instructions on subscribing to the DeltaV list. > Thanks for any help people can provide. I relise mail with lots > of questions can be a pain, but it was either that or send in > lots of separate ones (which I find worse)! Hopefully there are > simple answers to the above. The questions were clearly written and beautifully formatted :-) Shame about the answers. Tim From w3c-dist-auth-request@w3.org Wed Jun 20 05:35: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 FAA01312 for ; Wed, 20 Jun 2001 05:35:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA26356; Wed, 20 Jun 2001 05:34:01 -0400 (EDT) Resent-Date: Wed, 20 Jun 2001 05:34:01 -0400 (EDT) Resent-Message-Id: <200106200934.FAA26356@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 FAA26305 for ; Wed, 20 Jun 2001 05:33:19 -0400 (EDT) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA10838 for ; Wed, 20 Jun 2001 05:33:18 -0400 Received: from eurodns4.eur.xerox.com (eurodns4.eur.xerox.com [13.202.66.50]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id KAA28171 for ; Wed, 20 Jun 2001 10:33:09 +0100 (BST) Received: from eur.xerox.com (eurdubmg02.eur.xerox.com [13.202.65.254]) by eurodns4.eur.xerox.com (8.9.3/8.9.3) with ESMTP id KAA04110 for ; Wed, 20 Jun 2001 10:33:08 +0100 (BST) Received: from eurgbrbh03.emeacinops.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 20 Jun 2001 10:32:28 +0100 Received: by eurgbrbh03.eur.xerox.com with Internet Mail Service (5.5.2651.58) id <2XAFGV8M>; Wed, 20 Jun 2001 10:33:01 +0100 Received: from eur.xerox.com (eurdubmg04.eur.xerox.com [13.202.66.61]) by eurgbrbh03.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id 2XAFGV8F; Wed, 20 Jun 2001 10:32:58 +0100 Received: from gbrwgcbh01.wgc.gbr.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 20 Jun 2001 10:04:14 +0100 Received: by gbrwgcbh01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Jun 2001 10:05:24 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB77672875C5@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: "'ajk@mds.rmit.edu.au'" Cc: w3c-dist-auth@w3.org Date: Wed, 20 Jun 2001 10:05:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Newbie questions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5034 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Apologies for long post. Corrections please if my interpretation is wrong as its all IMHO... > -----Original Message----- > From: ajk@mds.rmit.edu.au [mailto:ajk@mds.rmit.edu.au] > Sent: 19 June 2001 05:14 > To: w3c-dist-auth@w3.org > Subject: Newbie questions > > > Hi. I am new to this list so I appologise if these are > ignorant questions. > I have been reading all the WebDAV (and DeltaV) documents I > can get my hands > on, but have a few issues that I do not understand. > > Q1: When are null resources created? You can "lock a null > resource in order > to lock the name". Is it that if you do a lock on a name > that does not > exist as a resource, a null resource is created? Are > there other ways > that null resources can be created? The text says you > lock a null resource > to create a lock-null resource. A lock-null resource has > properties and > appears under its parent container. A null resource does > not appear under > its parent. The definition of null resource is that it is > a resource > that responds to requests, which implies that it exists. Null resources are not created, they don't exist in the first place as far as the server is concerned. At least thats a convenient way of thinking about them. In other words, any URL that is not bound to an existing resource on the server is a null resource. The server detects that the requested URL doesn't exist, and depending upon the request, will return 404 (e.g. for a GET) or whatever is appropriate. One imperfect way of visualling this is if you tried to GET a file (on a file system implementation), the server would respond with a 404 because it cannot find the requested file (URL). Thus the requested URL is a null resource. However, you could PUT the file there (assuming all checks/permissions/etc passed). When you lock a null resource (assuming parent existed), you get a lock null resource (LNR), which has all the DAV properties and thus has state. LNRs are purely to reserve the name (URL) and nothing else, in an attempt to reduce conflict issues (as per the rest of locking). The general exected behaviour is for a client to "create" an LNR (with a LOCK request) and then do a PUT or MKCOL. Example, after a PUT the LNR is no longer locked (unless its parent is infinitely depth locked) and is a "normal" resource, with "entity data", in which you can GET it. Imagine multiple clients attempting to perform PUTs on the same URL at the same time without LNRs. Side note, LNRs can be returned to a null resource if server only implements timed out locks, the timeout period expires and the server UNLOCKs the LNR - see secs 9.8 and 7.4. Maybe the spec could be better phrased as the use of the word "resource" in so many different ways seems to fuel the confusion. > My guess is that any URI that is not bound to a resource > is implicitly > bound to a null resource which has no properties or any > other state. > When you lock a null resource, a lock-null resource is > created allowing > it to be placed under its parent container and have properties. > Is this correct? Yep, though most DAV properties will be empty for the LNR. > > Q4: PROPFIND in section 8.1 talks about responses and errors > and multistatus > XML elements. I have read the text several times but is confusing. > It says servers must support returning a multistatus > element. (It does not > say that it must *always* return one, just that it must > support it.) It > then says errors must be returned as 404 *if* a > multistatus element is > returned. etc. It was not clear when a multistatus element must be > returned - is it optional or mandatory? Related, how to > know when to > return multistatus elements in general? Examples of > packet communications > are given, but no formal request/response packet grammar is given. Generally, 207 if a problem exists on a resource that was not the URL in the request e.g. "recursive" operations such as DELETE, COPY etc. For PROPFIND though, you might get a 207 because of multiple returned problems/values/etc. For example, you did a PROPFIND on a null resource, you shouldn't get a 207, but a plain vanilla 404 as its the requested URL and its more meaningful. If the PROPFIND request contained certain properties to be returned and as an example, some of the properties didn't exist, server would return a 207 but contain 404 inside the XML for those properties that didn't exist. For the properties that were found, their values would also be returned in the 207. This should indicate to the client that the requested resource existed, but some of the properties don't. > Q5: MKCOL behaviour with message bodies is not defined in the standard > (section 8.3.1) but may be "defined elsewhere". Is there any such > defintion around? Or is the body of MKCOL not important for > interoperability. No definition that I know of. In theory you could create an entire server with *one* MKCOL request e.g. your request could create a collection which is a direct child off root, all the descendants for the collection and all their properties. Hope your not doing this down a 56k line :-) > > Alan Kent > Regards Shaun Hall Xerox Europe From w3c-dist-auth-request@w3.org Wed Jun 20 19:54: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 TAA26715 for ; Wed, 20 Jun 2001 19:54:00 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA15483; Wed, 20 Jun 2001 19:52:10 -0400 (EDT) Resent-Date: Wed, 20 Jun 2001 19:52:10 -0400 (EDT) Resent-Message-Id: <200106202352.TAA15483@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 TAA15446 for ; Wed, 20 Jun 2001 19:52:02 -0400 (EDT) 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 TAA01417 for ; Wed, 20 Jun 2001 19:52:02 -0400 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 QAA18111 for ; Wed, 20 Jun 2001 16:52:07 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 20 Jun 2001 16:49:45 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <59697CCC6CE3D411B4CD00805FBB77672875C2@gbrwgcms03.wgc.gbr.xerox.com> Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5035 X-Loop: w3c-dist-auth@w3.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 > Agreed on all of Jims points. I like the point about "URL is not > mapped to a resource". Maybe it could be included in the revised RFC as it > could make things clearer for some people ? This sounds quite reasonable to me. I've added an issue about this to the issues list. > IMHO, null resources have no properties. After all, they don't map to any > resource within the server, can't do a PROPFIND on them etc. Is my > interpretation wrong ? No, your interpretation is correct. An unmapped URL does not respond to PROPFIND requests. > Just a reminder, LNRs have *all* the mandatory DAV properties > (RFC 2518 sec 7.4), though as spec states, most will have no value (except lock > properties). One can legitimately perform a PROPFIND on a LNR and > retrieve a DAV:* property. Yes. - Jim From w3c-dist-auth-request@w3.org Wed Jun 20 19:54:03 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 TAA26726 for ; Wed, 20 Jun 2001 19:54:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA15504; Wed, 20 Jun 2001 19:52:17 -0400 (EDT) Resent-Date: Wed, 20 Jun 2001 19:52:17 -0400 (EDT) Resent-Message-Id: <200106202352.TAA15504@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 TAA15448 for ; Wed, 20 Jun 2001 19:52:02 -0400 (EDT) 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 TAA01416 for ; Wed, 20 Jun 2001 19:52:02 -0400 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 QAA18114 for ; Wed, 20 Jun 2001 16:52:07 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 20 Jun 2001 16:49:45 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <80256A6F.0034CBBA.00@d06mta06.portsmouth.uk.ibm.com> Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5036 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I agree with all of this. (Despite Section 3 of RFC2518 that > states clearly that a null resource is a resource.) When that was written, I had a different model in my head. In that model, a null resource was in fact a resource, but all this resource ever did was respond with "404" to everything. Pretty dull resource. But, I now think the "unmapped URL" is much closer to the idea I wanted to capture by this term. > > A lock-null resource is a null resource that has been locked. > > Or in the new phraseology, "a lock-null resource is an unmapped-URL that > has been locked". > > Hmm, that doesn't sound right does it? A resource is-a URL? Now a lock-null resource would be a *resource* with: * null (or undefined, take your pick) state * properties as defined in 7.4 That is, by reserving the name, you have explicitly created a mapping between a URL and some abstraction, whose state will be fleshed out later. > And not _all_ unmapped-URLs (in DAV compliant namespace) can be locked. > It seems that we need to augment "unmapped-URL" with "where the immediate > parent exists". Good point. > > Since a lock null resource has state, I would claim it is a > > resource. By the act of a client taking out a lock, they have > > likely made a mapping of a URL to a conceptual resource, and > > are int he process of fleshing out the computer representation > > of the conceptual resource. > > Agreed. Moving the server state of an 'unmapped-URL where the immediate > parent exists' from no resource to a resource should, IMHO, respond with > 201 Created. This makes sense to me. My concern is that it would still be nice for the first PUT after a lock-null is created to also return a 201. - Jim From w3c-dist-auth-request@w3.org Thu Jun 21 01:45: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 BAA07220 for ; Thu, 21 Jun 2001 01:45:48 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA05486; Thu, 21 Jun 2001 01:44:18 -0400 (EDT) Resent-Date: Thu, 21 Jun 2001 01:44:18 -0400 (EDT) Resent-Message-Id: <200106210544.BAA05486@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 BAA05461 for ; Thu, 21 Jun 2001 01:44:04 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA26382 for ; Thu, 21 Jun 2001 01:44:02 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id 00D2249B68; Thu, 21 Jun 2001 15:43:17 +1000 (EST) Date: Thu, 21 Jun 2001 15:43:17 +1000 From: Alan Kent To: w3c-dist-auth@w3.org Message-ID: <20010621154317.K28868@io.mds.rmit.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Subject: Is this LOCK model correct? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5037 X-Loop: w3c-dist-auth@w3.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 found a discussion of LOCK and BIND in the archives which helped a lot. But I still am trying to understand fully issues relating LOCK relating to depth "infinity". WebDAV talks about moving a resource under one locked collection to under another locked collection, and the old lock being lost and the new lock being gained. I am trying to get the semantic model in my head right. Comments on my model below would be appreciated. I am trying to work out if you do a LOCK with depth infinity, what is actually locked. Are the resources locked, or the URI's to the resources? My reading of various documents (including BIND stuff) indicates resources are locked, not URIs. However, the concept of LOCK with depth infinity is URI based. Moving a resource from under one infinity lock to under another does change the locks. But what if there is still a binding under the old tree to the resource, does it maintain its old lock? My guess is yes. Since some of the lock description is URI based, and other says resources are locked, I have come to the following model of locking. Please correct me if its wrong: - Locks are based on URIs. - A depth 0 lock puts a lock on that URI only. - A depth infinity lock identifies the leading path of a URI - any URI with additional path components is covered by the lock as well. - To check if a resource is locked, *all* of the URIs to the resource (if multiple bindings exist) must be checked against the locks that currently exist. In my understanding, locks are not really associated directly with resources because moving things to different URIs does not keep the lock. So the lock is not independent of the URI - hence locks are really best thought of as attached to URIs. Resources are locked if any of the URIs to the resource is locked. Alan From w3c-dist-auth-request@w3.org Thu Jun 21 02:21: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 CAA17148 for ; Thu, 21 Jun 2001 02:21:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA07584; Thu, 21 Jun 2001 02:19:56 -0400 (EDT) Resent-Date: Thu, 21 Jun 2001 02:19:56 -0400 (EDT) Resent-Message-Id: <200106210619.CAA07584@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 CAA07558 for ; Thu, 21 Jun 2001 02:19:41 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA28816 for ; Thu, 21 Jun 2001 02:19:42 -0400 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 CAA234912; Thu, 21 Jun 2001 02:17:22 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5L6DIA42498; Thu, 21 Jun 2001 02:13:18 -0400 Importance: Normal To: Alan Kent Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Thu, 21 Jun 2001 02:18:26 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.7 |March 21, 2001) at 06/21/2001 02:19:09 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Is this LOCK model correct? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5038 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << I am trying to work out if you do a LOCK with depth infinity, what is actually locked. Are the resources locked, or the URI's to the resources? My reading of various documents (including BIND stuff) indicates resources are locked, not URIs. However, the concept of LOCK with depth infinity is URI based. Moving a resource from under one infinity lock to under another does change the locks. But what if there is still a binding under the old tree to the resource, does it maintain its old lock? My guess is yes. >> Yes, and if those locks conflict then the MOVE request must be rejected. ... << In my understanding, locks are not really associated directly with resources because moving things to different URIs does not keep the lock. So the lock is not independent of the URI - hence locks are really best thought of as attached to URIs. Resources are locked if any of the URIs to the resource is locked. >> Sounds right. I believe what you've described is the best model for locks. URI/binding protection works with this model also. J. From w3c-dist-auth-request@w3.org Thu Jun 21 04:42: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 EAA21809 for ; Thu, 21 Jun 2001 04:42:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA15909; Thu, 21 Jun 2001 04:41:11 -0400 (EDT) Resent-Date: Thu, 21 Jun 2001 04:41:11 -0400 (EDT) Resent-Message-Id: <200106210841.EAA15909@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 EAA15880 for ; Thu, 21 Jun 2001 04:40:57 -0400 (EDT) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA07848 for ; Thu, 21 Jun 2001 04:40:47 -0400 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id JAA16859 for ; Thu, 21 Jun 2001 09:40:43 +0100 (BST) Received: from eur.xerox.com (eurdubmg02.eur.xerox.com [13.202.65.254]) by eurodns2.eur.xerox.com (8.9.3/8.9.3) with ESMTP id JAA25453 for ; Thu, 21 Jun 2001 09:40:37 +0100 (BST) Received: from eurgbrbh01.emeacinops.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 21 Jun 2001 09:40:00 +0100 Received: by eurgbrbh01.eur.xerox.com with Internet Mail Service (5.5.2651.58) id ; Thu, 21 Jun 2001 09:40:34 +0100 Received: from eur.xerox.com (eurdubmg01.eur.xerox.com [13.202.65.253]) by eurgbrbh01.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id L7G4XVG6; Thu, 21 Jun 2001 09:40:32 +0100 Received: from gbrwgcbh01.wgc.gbr.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 21 Jun 2001 09:33:45 +0100 Received: by gbrwgcbh01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Jun 2001 09:20:25 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB77672875C8@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: WebDAV WG Date: Thu, 21 Jun 2001 09:20:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5039 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > -----Original Message----- > From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] > Sent: 21 June 2001 00:50 > To: WebDAV WG > Subject: RE: Status code for creating lock-null resource [snipped] > > > Since a lock null resource has state, I would claim it is a > > > resource. By the act of a client taking out a lock, they have > > > likely made a mapping of a URL to a conceptual resource, and > > > are int he process of fleshing out the computer representation > > > of the conceptual resource. > > > > Agreed. Moving the server state of an 'unmapped-URL where > the immediate > > parent exists' from no resource to a resource should, IMHO, > respond with > > 201 Created. > > This makes sense to me. My concern is that it would still be > nice for the > first PUT after a lock-null is created to also return a 201. > > - Jim > Just double checked MKCOL. It of course returns 201 upon success, never 200. So your above suggestion would match MKCOL as well. Assuming no errors, expected behaviour would be: 1) Client issues LOCK, "creating" an LNR, returns 201. 2) Client issues PUT or MKCOL on the LNR, either of which return 201. Which of course is consistent, duh. Regards Shaun Hall Xerox Europe From w3c-dist-auth-request@w3.org Thu Jun 21 05:52: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 FAA22559 for ; Thu, 21 Jun 2001 05:52:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA20359; Thu, 21 Jun 2001 05:51:11 -0400 (EDT) Resent-Date: Thu, 21 Jun 2001 05:51:11 -0400 (EDT) Resent-Message-Id: <200106210951.FAA20359@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 FAA20323 for ; Thu, 21 Jun 2001 05:50:48 -0400 (EDT) Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA14579 for ; Thu, 21 Jun 2001 05:50:45 -0400 Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id KAA111976 for ; Thu, 21 Jun 2001 10:31:28 +0100 Received: from d06ml034.portsmouth.uk.ibm.com (d06ml034_cs0 [9.180.35.31]) by d06relay02.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5L9nDQ103644 for ; Thu, 21 Jun 2001 10:49:13 +0100 To: "WebDAV WG" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Tim Ellison" Date: Thu, 21 Jun 2001 10:24:33 +0100 X-MIMETrack: Serialize by Router on D06ML034/06/M/IBM(Release 5.0.6 |December 14, 2000) at 21/06/2001 10:48:27 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5040 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: "Jim Whitehead" wrote: [snip] lots of stuff we agree on > > Moving the server state of an 'unmapped-URL where the immediate > > parent exists' from no resource to a resource should, IMHO, > > respond with 201 Created. > > This makes sense to me. My concern is that it would still be nice for the > first PUT after a lock-null is created to also return a 201. I don't see why? The resource has already been created and the PUT is simply modifying the existing resource. What is the basis of your concern? Tim From w3c-dist-auth-request@w3.org Thu Jun 21 08:34: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 IAA25668 for ; Thu, 21 Jun 2001 08:34:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA29921; Thu, 21 Jun 2001 08:33:07 -0400 (EDT) Resent-Date: Thu, 21 Jun 2001 08:33:07 -0400 (EDT) Resent-Message-Id: <200106211233.IAA29921@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 IAA29881 for ; Thu, 21 Jun 2001 08:32:42 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA27856 for ; Thu, 21 Jun 2001 08:32:42 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 21 Jun 2001 08:38:11 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 08:38:11 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103625245@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Thu, 21 Jun 2001 08:38:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Is this LOCK model correct? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5041 X-Loop: w3c-dist-auth@w3.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 totally agree. The only way to make sense of the 2518 locking semantics is to associate the lock with the URI. Then the *effect* of that URI lock is to restrict updates to the resource currently mapped to that URI, or in the case of a depth-N lock, any resource mapped to a URI that has the locked URI as a prefix, and has no more than N segments following that prefix. We then overload the DELETE and MOVE methods to not only unmap the resource at the specified URI, but also delete the lock associated with that URI (and all locks associated to an extension of that URI). We can use the shorthand "write-locked resource" to mean "a resource whose write access is limited by a lock", but the lock itself is on a URI, not a resource (which is why the lock does not move with the resource). A "lock-null resource" is a mechanism (hack :-) for exposing a lock when there is no resource currently mapped to a locked URI. Cheers, Geoff -----Original Message----- From: Alan Kent [mailto:ajk@mds.rmit.edu.au] Sent: Thursday, June 21, 2001 1:43 AM To: w3c-dist-auth@w3.org Subject: Is this LOCK model correct? I found a discussion of LOCK and BIND in the archives which helped a lot. But I still am trying to understand fully issues relating LOCK relating to depth "infinity". WebDAV talks about moving a resource under one locked collection to under another locked collection, and the old lock being lost and the new lock being gained. I am trying to get the semantic model in my head right. Comments on my model below would be appreciated. I am trying to work out if you do a LOCK with depth infinity, what is actually locked. Are the resources locked, or the URI's to the resources? My reading of various documents (including BIND stuff) indicates resources are locked, not URIs. However, the concept of LOCK with depth infinity is URI based. Moving a resource from under one infinity lock to under another does change the locks. But what if there is still a binding under the old tree to the resource, does it maintain its old lock? My guess is yes. Since some of the lock description is URI based, and other says resources are locked, I have come to the following model of locking. Please correct me if its wrong: - Locks are based on URIs. - A depth 0 lock puts a lock on that URI only. - A depth infinity lock identifies the leading path of a URI - any URI with additional path components is covered by the lock as well. - To check if a resource is locked, *all* of the URIs to the resource (if multiple bindings exist) must be checked against the locks that currently exist. In my understanding, locks are not really associated directly with resources because moving things to different URIs does not keep the lock. So the lock is not independent of the URI - hence locks are really best thought of as attached to URIs. Resources are locked if any of the URIs to the resource is locked. Alan From w3c-dist-auth-request@w3.org Thu Jun 21 12:16: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 MAA04587 for ; Thu, 21 Jun 2001 12:16:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA26720; Thu, 21 Jun 2001 12:14:34 -0400 (EDT) Resent-Date: Thu, 21 Jun 2001 12:14:34 -0400 (EDT) Resent-Message-Id: <200106211614.MAA26720@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 MAA26696 for ; Thu, 21 Jun 2001 12:14:25 -0400 (EDT) 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 MAA23384 for ; Thu, 21 Jun 2001 12:14:25 -0400 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 JAA09168 for ; Thu, 21 Jun 2001 09:14:28 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Thu, 21 Jun 2001 09:12:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5042 X-Loop: w3c-dist-auth@w3.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 Tim Ellison writes: > > > Moving the server state of an 'unmapped-URL where the immediate > > > parent exists' from no resource to a resource should, IMHO, > > > respond with 201 Created. > > > > This makes sense to me. My concern is that it would still be > nice for the > > first PUT after a lock-null is created to also return a 201. > > I don't see why? The resource has already been created and the PUT is > simply modifying the existing resource. What is the basis of > your concern? One of the features you need for document management is the ability to set a large number of properties when the body of a resource is first created. If the 201 doesn't come back, then a client wouldn't know that this is the first time the resource body state is being set. Of course, this isn't the only way to address the issue -- a client could allow properties to be set internal to the document format (like .doc and .pdf files), and then the server could extract the metadata from the document. But, this requires document-specific knowledge, and that implies brittleness over time. - Jim From w3c-dist-auth-request@w3.org Thu Jun 21 12:47: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 MAA06202 for ; Thu, 21 Jun 2001 12:47:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA01959; Thu, 21 Jun 2001 12:46:34 -0400 (EDT) Resent-Date: Thu, 21 Jun 2001 12:46:34 -0400 (EDT) Resent-Message-Id: <200106211646.MAA01959@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 MAA01932 for ; Thu, 21 Jun 2001 12:46:18 -0400 (EDT) Received: from d06lmsgate-2.uk.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA27331 for ; Thu, 21 Jun 2001 12:46:18 -0400 Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-2.uk.ibm.com (1.0.0) with ESMTP id RAA75550 for ; Thu, 21 Jun 2001 17:29:36 +0100 Received: from d06ml034.portsmouth.uk.ibm.com (d06ml034_cs0 [9.180.35.31]) by d06relay02.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5LGjkQ43586 for ; Thu, 21 Jun 2001 17:45:46 +0100 To: "WebDAV WG" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Tim Ellison" Date: Thu, 21 Jun 2001 17:45:27 +0100 X-MIMETrack: Serialize by Router on D06ML034/06/M/IBM(Release 5.0.6 |December 14, 2000) at 21/06/2001 17:44:59 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5043 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: "Jim Whitehead" wrote: > One of the features you need for document management is > the ability to set a large number of properties when the > body of a resource is first created. The implication is that a lock-null resource has properties but does not have a body! > If the 201 doesn't come back, then a client wouldn't know > that this is the first time the resource body state is being > set. > > Of course, this isn't the only way to address the issue -- > a client could allow properties to be set internal to the > document format (like .doc and .pdf files), and then the > server could extract the metadata from the document. But, > this requires document-specific knowledge, and that implies > brittleness over time. Not good I agree. Tim From w3c-dist-auth-request@w3.org Thu Jun 21 12:57: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 MAA06740 for ; Thu, 21 Jun 2001 12:56:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA03431; Thu, 21 Jun 2001 12:55:58 -0400 (EDT) Resent-Date: Thu, 21 Jun 2001 12:55:58 -0400 (EDT) Resent-Message-Id: <200106211655.MAA03431@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 MAA03353 for ; Thu, 21 Jun 2001 12:55:39 -0400 (EDT) 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 MAA28425 for ; Thu, 21 Jun 2001 12:55:38 -0400 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 JAA16912 for ; Thu, 21 Jun 2001 09:55:41 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Thu, 21 Jun 2001 09:53:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <59697CCC6CE3D411B4CD00805FBB77672875C8@gbrwgcms03.wgc.gbr.xerox.com> Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5044 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Just double checked MKCOL. It of course returns 201 upon success, > never 200. > So your above suggestion would match MKCOL as well. Assuming no errors, > expected behaviour would be: > > 1) Client issues LOCK, "creating" an LNR, returns 201. > 2) Client issues PUT or MKCOL on the LNR, either of which return 201. > That certainly would be my preference for the behavior. I've added a note in the issues list about this. - Jim From w3c-dist-auth-request@w3.org Thu Jun 21 13:12: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 NAA07776 for ; Thu, 21 Jun 2001 13:12:31 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA05817; Thu, 21 Jun 2001 13:11:40 -0400 (EDT) Resent-Date: Thu, 21 Jun 2001 13:11:40 -0400 (EDT) Resent-Message-Id: <200106211711.NAA05817@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 NAA05797 for ; Thu, 21 Jun 2001 13:11:33 -0400 (EDT) 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 NAA30540 for ; Thu, 21 Jun 2001 13:11:33 -0400 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 KAA19823 for ; Thu, 21 Jun 2001 10:11:36 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Thu, 21 Jun 2001 10:09:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Subject: On metadata (was: RE: Status code for creating lock-null resource) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5045 X-Loop: w3c-dist-auth@w3.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 > > Of course, this isn't the only way to address the issue -- > > a client could allow properties to be set internal to the > > document format (like .doc and .pdf files), and then the > > server could extract the metadata from the document. But, > > this requires document-specific knowledge, and that implies > > brittleness over time. > > Not good I agree. Actually, I'm starting to like this solution (grabbing internal metadata items from a file) more and more. DAV is nice, since you can add metadata to any resource. But, let's look at the applications that create those resources. There are two classes of applications: those that have some notion of metadata, and those that do not. Those that understand metadata, tend to store it in their native file format. Storing metadata in a document format has the very nice property that moving and copying the resource (such as by emailing it) is guaranteed to preserve the metadata. If an application adopted a DAV-properties-only approach, it would lose this characteristic. As a result, there is no motivation for them to use DAV for properties. Applications that have no metadata support whatsoever seem unlikely candidates for adding DAV property support. As a result, we have the current situation, where authoring clients tend not to make use of DAV properties. To break the logjam, it seems like several things need to happen: * DAV clients with good metadata authoring support need to become available. An ODMA to DAV shim would be very nice, since many word processors have ODMA support, allowing properties to be set when a resource is created or updated. DAV needs this capability so that institution-specific metadata can be set on a resource. This is a fairly fundamental document management need -- hooks need to be in place so that,if desired, metadata entry can be made very visible to the content creator. * Registration of property sets for use with WebDAV needs to happen. A standard profile for using Dublin Core with DAV is long overdue -- and we're really close. With standards for formatting and meaning of properties, metadata authoring clients will have the information they need for their user interface and protocol layers. * Existing metadata in documents needs to be exploited. If I've entered author information into a Word or PDF property field, using the nice interface provided, I don't want to re-enter that information. - Jim From w3c-dist-auth-request@w3.org Thu Jun 21 13:48: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 NAA09968 for ; Thu, 21 Jun 2001 13:48:48 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA10823; Thu, 21 Jun 2001 13:47:03 -0400 (EDT) Resent-Date: Thu, 21 Jun 2001 13:47:03 -0400 (EDT) Resent-Message-Id: <200106211747.NAA10823@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 NAA10795 for ; Thu, 21 Jun 2001 13:46:54 -0400 (EDT) Received: from postmaster.enron.com (outbound5.enron.com [192.152.140.9]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA02783 for ; Thu, 21 Jun 2001 13:46:53 -0400 Received: from mailman.enron.com (mailman.enron.com [192.168.189.66]) by postmaster.enron.com (8.10.1/8.10.1/external_corp-1.08) with ESMTP id f5LHkb705907 for ; Thu, 21 Jun 2001 12:46:37 -0500 (CDT) Received: from corp.enron.com ([192.168.110.110]) by mailman.enron.com (8.10.1/8.10.1/corp-1.06) with ESMTP id f5LHkaa19976 for ; Thu, 21 Jun 2001 12:46:37 -0500 (CDT) Received: from nahou-mscnx04p.corp.enron.com (unverified) by corp.enron.com (Content Technologies SMTPRS 4.2.1) with SMTP id for ; Thu, 21 Jun 2001 12:46:36 -0500 Received: from NAHOU-MSMBX05V.corp.enron.com ([172.24.192.109]) by nahou-mscnx04p.corp.enron.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 21 Jun 2001 12:46:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Jun 2001 12:46:36 -0500 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: Error Messages Thread-Index: AcD6eh2/ksqkwvCfQWe5OAyTVEPlfg== From: "Fuller, Dan" To: X-OriginalArrivalTime: 21 Jun 2001 17:46:36.0320 (UTC) FILETIME=[1E087A00:01C0FA7A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id NAA10795 Subject: Error Messages Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5046 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit I am a Newbie, but I am using WebDAV in my work and I have been following the thread for a couple of weeks now. Would it be possible to make the error for 400: Bad Request a little more specific? It would be nice to have something along the lines of the following examples: 40x: Bad Request: Metatag '' not supported 40x: Bad Request: Metatag start tag '' does not match end tag '' 40x: Bad Request: Request not well-formed From w3c-dist-auth-request@w3.org Thu Jun 21 15:13: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 PAA14664 for ; Thu, 21 Jun 2001 15:13:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA21792; Thu, 21 Jun 2001 15:12:33 -0400 (EDT) Resent-Date: Thu, 21 Jun 2001 15:12:33 -0400 (EDT) Resent-Message-Id: <200106211912.PAA21792@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 PAA21718 for ; Thu, 21 Jun 2001 15:12:16 -0400 (EDT) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA12362 for ; Thu, 21 Jun 2001 15:12:16 -0400 Received: from [216.36.75.57] (HELO beaver) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.7) with SMTP id 900423; Thu, 21 Jun 2001 12:09:26 -0700 From: "Lisa Dusseault" To: "Fuller, Dan" , Date: Thu, 21 Jun 2001 12:10:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: RE: Error Messages Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5048 X-Loop: w3c-dist-auth@w3.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 proposal on the table for adding more detail to status codes like 400 Bad Request, without allocating new numbers. Instead, it adds extensible codes to the body of the error response (where legal). Please see: http://lists.w3.org/Archives/Public/w3c-dist-auth/2000OctDec/0130.html http://lists.w3.org/Archives/Public/w3c-dist-auth/2000OctDec/0137.html I'd be willing to pursue this if there's sufficient interest from other implementors. lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Fuller, Dan > Sent: Thursday, June 21, 2001 10:47 AM > To: w3c-dist-auth@w3.org > Subject: Error Messages > > > I am a Newbie, but I am using WebDAV in my work and I have been > following the thread for a couple of weeks now. Would it be possible to > make the error for 400: Bad Request a little more specific? It would be > nice to have something along the lines of the following examples: > > 40x: Bad Request: Metatag '' not supported > > 40x: Bad Request: Metatag start tag '' does not match end tag > '' > > 40x: Bad Request: Request not well-formed From w3c-dist-auth-request@w3.org Thu Jun 21 15:13: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 PAA14685 for ; Thu, 21 Jun 2001 15:13:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA21749; Thu, 21 Jun 2001 15:12:23 -0400 (EDT) Resent-Date: Thu, 21 Jun 2001 15:12:23 -0400 (EDT) Resent-Message-Id: <200106211912.PAA21749@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 PAA21714 for ; Thu, 21 Jun 2001 15:12:15 -0400 (EDT) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA12360 for ; Thu, 21 Jun 2001 15:12:16 -0400 Received: from [216.36.75.57] (HELO beaver) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.7) with SMTP id 900422; Thu, 21 Jun 2001 12:09:26 -0700 From: "Lisa Dusseault" To: "Julian Reschke" , Date: Thu, 21 Jun 2001 12:10:10 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: RE: Moving DASL to Experimental Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5047 X-Loop: w3c-dist-auth@w3.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 also interested in working on DASL some more. Xythos has implemented it, including the basicsearch grammar :) Although an XPath or XMLQuery syntax would be useful, basicsearch is also useful and should not be dropped: - it can easily be translated into SQL for clients or servers that already support SQL - it is very simple for very simple tasks - it can be implemented even by servers concerned about limiting their performance "liability", because it can do very high-level searches and restrict what properties can be searched. (Servers don't have to support any features which require parsing of the body or property syntaxes. Since parsing can be expensive, XPath/XMLQuery impose a far greater performance liability.) - it's very suited for directory contents listing, filters and sorting -- common browser tasks, easily automated. E.g. only show items created since . Only show items created by . lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Tuesday, June 12, 2001 3:12 AM > To: w3c-dist-auth@w3.org > Subject: Re: Moving DASL to Experimental > > > Hi, > > I'm looking for other parties that would be interested on working on DASL > again. With the current status of the spec I have mainly two > problems, both > of which apply to the basicsearch grammar: > > 1) The spec is completely silent about how the grammar engine is > supposed to > know about data types. For instance, I would suspect that property values > for getcontentlength are supposed to be compared as numbers, while > getlastmodified need a date comparison. > > 2) The grammar for accessing properties is not really XML-friendly, which > has led to inventions like "DAV:iscollection". Indeed, this so-called > "synthetic property" only solves one special case and leaves the rest > (lockdiscovery, attributes, deltaV computed properties) untreated. I think > DASL needs a grammar which can do "arbitrary" queries into the attributes, > so something with the power of XPath would need to be used. > > In addition, I'm not happy with the language in chapter 3 (discovery of > grammars). It mixes namespace prefixes with URI schemes, which is only > correct in the very special case of "DAV:" (being a URI scheme > and also the > prefix used there). > > Julian From w3c-dist-auth-request@w3.org Thu Jun 21 17:08: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 RAA17877 for ; Thu, 21 Jun 2001 17:08:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA03855; Thu, 21 Jun 2001 17:07:42 -0400 (EDT) Resent-Date: Thu, 21 Jun 2001 17:07:42 -0400 (EDT) Resent-Message-Id: <200106212107.RAA03855@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 RAA03818 for ; Thu, 21 Jun 2001 17:07:33 -0400 (EDT) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA25562 for ; Thu, 21 Jun 2001 17:07:23 -0400 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id WAA07825 for ; Thu, 21 Jun 2001 22:07:20 +0100 (BST) Received: from eur.xerox.com (eurdubmg01.eur.xerox.com [13.202.65.253]) by eurodns2.eur.xerox.com (8.9.3/8.9.3) with ESMTP id WAA22527 for ; Thu, 21 Jun 2001 22:07:20 +0100 (BST) Received: from eurgbrbh02.emeacinops.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 21 Jun 2001 18:11:41 +0100 Received: by eurgbrbh02.eur.xerox.com with Internet Mail Service (5.5.2651.58) id <2WZAWQPB>; Thu, 21 Jun 2001 18:17:28 +0100 Received: from eur.xerox.com (eurdubmg01.eur.xerox.com [13.202.65.253]) by eurgbrbh02.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id 2WZAWQ37; Thu, 21 Jun 2001 18:17:26 +0100 Received: from gbrwgcbh01.wgc.gbr.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 21 Jun 2001 17:44:47 +0100 Received: by gbrwgcbh01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Jun 2001 15:23:34 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB77672875CB@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: "'w3c-dist-auth@w3.org'" Date: Thu, 21 Jun 2001 15:23:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: Minor corrections needed in IF header examples ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5049 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Secs 9.4.1.1 and 9.4.3 give examples using the "IF" header. However, both examples use literally "; Thu, 21 Jun 2001 17:40:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA06642; Thu, 21 Jun 2001 17:39:27 -0400 (EDT) Resent-Date: Thu, 21 Jun 2001 17:39:27 -0400 (EDT) Resent-Message-Id: <200106212139.RAA06642@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 RAA06621 for ; Thu, 21 Jun 2001 17:39:18 -0400 (EDT) Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA29166 for ; Thu, 21 Jun 2001 17:39:18 -0400 Received: from [216.36.75.57] (HELO beaver) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.7) with SMTP id 917971 for w3c-dist-auth@w3c.org; Thu, 21 Jun 2001 14:36:28 -0700 From: "Lisa Dusseault" To: "Webdav WG" Date: Thu, 21 Jun 2001 14:37:13 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: Obscure HTTP 1.1 header of the day... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5050 X-Loop: w3c-dist-auth@w3.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 RFC2616 defines the Expect: header for _any_ request method that normally takes a body. Before today, I thought the Expect: header was just the client's way of advertising client support for the 100-Continue response. (I've never seen it sent by a client, BTW.) But RFC2616 says "The Expect request-header field is used to indicate that particular server behaviors are required by the client." This is ambiguous, but clearly the intention is that the server has some responsibility here and can't safely ignore the Expect header. Krishnamurthy and Rexford, in "Web Protocols and Practice", give a cool example of how they think it's used with the "100-Continue" value. The client sends a request that normally has a body, but sends the Expect header instead of the body. The server indicates with 100-Continue that the client should proceed with the request if it's likely to succeed, and the client sends the body in the second message. But if the request is going to fail, the server responds with an error instead. E.g. POST /foo/bar HTTP/1.1 Content-Length: 23248 Expect: 100-Continue The server would respond with an error of some kind if it doesn't have /foo/bar location, if /foo/bar doesn't allow POST, if the Content-Length is too long, or anything else. If anybody's got any other expectation of how the header is supposed to work, I'd love to hear it. Now how it affects WebDAV... RFC2518 makes no mention of the Expect header, but RFC2518 servers are expected to be compliant HTTP 1.1 servers. This would presumably mean they must support the Expect header. So if I sent a server the following request: PROPPATCH /~lisa HTTP/1.1 Content-Length: 1234 Depth: infinity Content-Type: text/xml Expect: 100-Continue The server should NOT wait for a body on this request, and it should respond with 100 Continue if it's going to allow me to do the PROPPATCH based on the information provided. E.g. it tests to see if I have write permission on /~lisa and all its descendants. Unless RFC 2518 were to explicitly state that methods defined there did not use the Expect header... Then WebDAV implementors would only have to worry about implementing it correctly for PUT and POST. Hmm? lisa From w3c-dist-auth-request@w3.org Thu Jun 21 18:26: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 SAA19215 for ; Thu, 21 Jun 2001 18:26:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA12631; Thu, 21 Jun 2001 18:25:28 -0400 (EDT) Resent-Date: Thu, 21 Jun 2001 18:25:28 -0400 (EDT) Resent-Message-Id: <200106212225.SAA12631@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 SAA12601 for ; Thu, 21 Jun 2001 18:25:17 -0400 (EDT) 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 SAA01301 for ; Thu, 21 Jun 2001 18:25:18 -0400 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 PAA17875 for ; Thu, 21 Jun 2001 15:25:23 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Thu, 21 Jun 2001 15:23:00 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: Re: Obscure HTTP 1.1 header of the day... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5051 X-Loop: w3c-dist-auth@w3.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 Joe's btconnect.com address to the accept2 filter. - Jim -----Original Message----- From: Joe Orton [mailto:jorton@btconnect.com] Sent: Thursday, June 21, 2001 3:20 PM To: Webdav WG Subject: [Moderator Action] Re: Obscure HTTP 1.1 header of the day... On Thu, Jun 21, 2001 at 02:37:13PM -0700, Lisa Dusseault wrote: > RFC2616 defines the Expect: header for _any_ request method that normally > takes a body. > > Before today, I thought the Expect: header was just the client's way of > advertising client support for the 100-Continue response. (I've never seen > it sent by a client, BTW.) > > But RFC2616 says "The Expect request-header field is used to indicate that > particular server behaviors are required by the client." This is ambiguous, > but clearly the intention is that the server has some responsibility here > and can't safely ignore the Expect header. Early version of my clients used "Expect: 100-continue" by default for large request bodies. Problem is that if the next-hop server *doesn't* support the feature, you end up with a hung connection as both sides block waiting for the other, forcing the client to implement a "timeout" waiting for the interim 100 response/error. (that's all covered in RFC2616) So if you turn this on by default you face the client "hanging" for X seconds until the timeout kicks in, if there is an HTTP/1.0 proxy in the way and you didn't know about it, or the HTTP/1.1 server doesn't support this correctly. I turned it off in the end to prevent it causing weird interop problems. > Unless RFC 2518 were to explicitly state that methods defined there did not > use the Expect header... Then WebDAV implementors would only have to worry > about implementing it correctly for PUT and POST. Hmm? Not sure what you mean there - RFC2616 defines this behaviour, so, if a DAV server claims HTTP/1.1 compliance the header must be honoured regardless of method. Regards, joe From w3c-dist-auth-request@w3.org Thu Jun 21 20:34: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 UAA21867 for ; Thu, 21 Jun 2001 20:34:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA22308; Thu, 21 Jun 2001 20:30:09 -0400 (EDT) Resent-Date: Thu, 21 Jun 2001 20:30:09 -0400 (EDT) Resent-Message-Id: <200106220030.UAA22308@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 UAA22249 for ; Thu, 21 Jun 2001 20:29:55 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA11295 for ; Thu, 21 Jun 2001 20:29:55 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id 348B749B49; Fri, 22 Jun 2001 10:29:23 +1000 (EST) Date: Fri, 22 Jun 2001 10:29:22 +1000 From: Alan Kent To: WebDAV Message-ID: <20010622102922.B14654@io.mds.rmit.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Subject: Can you BIND lock-null resources? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5052 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Is it expected that you should be able to BIND a lock-null resource? I am in the process of trying to come up with a software design for the programmers here to implement WebDAV (first) and then DeltaV (later). We want to build a fairly generic lump of code to do all the protocol messing around with a fairly clean and simplified to the underlying 'file system of resources'. So far I have put the LOCK mechanisms into the WebDAV library layer (because they are based on URIs). I am also trying to keep the 'lock-null' resource concept in the WebDAV layer since they are tightly related to locks. My current proposal is to keep track of lock-null resources with properties that have been set and then copy those properties over to the real resource when it is created later (if I have understood things correctly). I realise BIND is not in the base WebDAV spec, but I want to keep what is done future proof. There are two variations of questions I guess I have. (1) Does the spec prohibit BIND-ing to a lock-null resource? (OK, I am being lazy and have not reread the spec again to verify this question - but the next question is the real question) (2) Regardless of the spec, do people think its acceptable to fail BIND requests to a lock-null resource with an error? (Is there any reason why someone would want to do it before doing a PUT or MKCOL etc?) Alan ps: Thanks to all for time spent answering these questions. From w3c-dist-auth-request@w3.org Thu Jun 21 20:54:05 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 UAA22445 for ; Thu, 21 Jun 2001 20:54:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA24211; Thu, 21 Jun 2001 20:52:13 -0400 (EDT) Resent-Date: Thu, 21 Jun 2001 20:52:13 -0400 (EDT) Resent-Message-Id: <200106220052.UAA24211@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 UAA24187 for ; Thu, 21 Jun 2001 20:52:03 -0400 (EDT) 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 UAA13580 for ; Thu, 21 Jun 2001 20:52:03 -0400 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 RAA09209 for ; Thu, 21 Jun 2001 17:52:09 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Thu, 21 Jun 2001 17:49:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: Last Call: Access Control Protocol Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5053 X-Loop: w3c-dist-auth@w3.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 *** WORKING GROUP LAST CALL FOR COMMENTS *** A subgroup of the WebDAV Working Group has been working on the acl@webdav.org mailing list to develop a WebDAV Access Control Protocol. As stated in the abstract of the protocol specification document, draft-ietf-webdav-acl-06: This document specifies a set of methods, headers, and message bodies that define Access Control extensions to the WebDAV Distributed Authoring Protocol. This protocol permits a client to remotely read and modify access control lists that instruct a server whether to grant or deny operations upon a resource (such as HTTP method invocations) by a given principal. The access control subgroup now believes that the Access Control Protocol specification resolves known technical tradeoffs, and reflects the consensus of the acl@webdav.org mailing list. The specification has just finished a very productive last call for comments period on the acl@webdav.org mailing list. Since this document is intended to be a work product of the entire WebDAV working group, it needs to be considered by the main WebDAV working group mailing list, w3c-dist-auth@w3.org, so it can reflect the rough consensus of the entire working group. Since the Access Control Protocol specification is in near-complete form, I am moving it directly to a (long) Working Group last call for comments period to solicit review from members of the working group. This is the final call for comments from the WebDAV working group on the WebDAV Access Control Protocol, draft-ietf-webdav-acl-06. This last call for comments period begins immediately, and ends July 29, 2001, at midnight, US Pacific time. This allows over five weeks for review of the specification. The latest revision of the WebDAV Access Control Protocol was submitted as an Internet-Draft today, and should appear in the Internet-Drafts directory in the next few days. In the meanwhile, it can be accessed at: Text (this is the normative version) http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-06.txt HTML: http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-06.htm PDF: http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-06.pdf Word (with change tracking active): http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-06.doc At the end of the last call review period, a new draft will be issued. Depending on the scope of changes introduced between the -06 and -07 versions, there will either be an immediate call for rough consensus (very few changes), or a second last call review period (significant changes). Once the document represents the rough consensus of the working group, I will submit this document to the Internet Engineering Steering Group (IESG) for their approval. IESG review involves a (minimum) two week public last call for comments period. This IESG-initiated last call period is in addition to the working group last call period. This document is intended to be a "Proposed Standard". Quoting from RFC 2026, "The Internet Standards Process -- Revision 3": The entry-level maturity for the standards track is "Proposed Standard". A specific action by the IESG is required to move a specification onto the standards track at the "Proposed Standard" level. A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. Many details on the procedures used to develop an IETF standard can be found in RFC 2026, available at: http://www.ietf.org/rfc/rfc2026.txt If there are any procedural questions or concerns, please do not hesitate to contact me, or raise an issue on the list. Notes: 1) Issues raised during the last call period will be resolved individually, rather than lumped together and dealt with as a whole. 2) If you've been waiting for a "stable" version of the specification before performing a review, wait no longer. This is it. Please review the specification NOW in order to ensure your input gets included. - Jim Whitehead Chair, IETF WebDAV Working Group From w3c-dist-auth-request@w3.org Thu Jun 21 20:56: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 UAA22515 for ; Thu, 21 Jun 2001 20:56:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA24645; Thu, 21 Jun 2001 20:55:33 -0400 (EDT) Resent-Date: Thu, 21 Jun 2001 20:55:33 -0400 (EDT) Resent-Message-Id: <200106220055.UAA24645@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 UAA24600 for ; Thu, 21 Jun 2001 20:55:22 -0400 (EDT) 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 UAA13921 for ; Thu, 21 Jun 2001 20:55:21 -0400 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 RAA09457 for ; Thu, 21 Jun 2001 17:55:28 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Thu, 21 Jun 2001 17:53:04 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <20010622102922.B14654@io.mds.rmit.edu.au> Subject: RE: Can you BIND lock-null resources? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5054 X-Loop: w3c-dist-auth@w3.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 > Is it expected that you should be able to BIND a lock-null resource? Interesting question. Since it is a resource, it makes sense that you can bind to it. So I'd say, yes. But, I'd understand if servers decided to fail such a request. > I am in the process of trying to come up with a software design for > the programmers here to implement WebDAV (first) and then DeltaV (later). > We want to build a fairly generic lump of code to do all the protocol > messing around with a fairly clean and simplified to the underlying > 'file system of resources'. > > So far I have put the LOCK mechanisms into the WebDAV library layer > (because they are based on URIs). I am also trying to keep the > 'lock-null' resource concept in the WebDAV layer since they are > tightly related to locks. My current proposal is to keep track > of lock-null resources with properties that have been set and then > copy those properties over to the real resource when it is created > later (if I have understood things correctly). > > I realise BIND is not in the base WebDAV spec, but I want to keep > what is done future proof. > > There are two variations of questions I guess I have. > > (1) Does the spec prohibit BIND-ing to a lock-null resource? > (OK, I am being lazy and have not reread the spec again to > verify this question - but the next question is the real question) I just gave it a quick look, and it seems like the BIND protocol specification does not mention lock null resources. > (2) Regardless of the spec, do people think its acceptable to fail > BIND requests to a lock-null resource with an error? (Is there > any reason why someone would want to do it before doing a PUT > or MKCOL etc?) I think this is fine. - Jim From w3c-dist-auth-request@w3.org Thu Jun 21 21:00: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 VAA22617 for ; Thu, 21 Jun 2001 21:00:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA24937; Thu, 21 Jun 2001 20:59:16 -0400 (EDT) Resent-Date: Thu, 21 Jun 2001 20:59:16 -0400 (EDT) Resent-Message-Id: <200106220059.UAA24937@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 UAA24917 for ; Thu, 21 Jun 2001 20:59:07 -0400 (EDT) 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 UAA14228 for ; Thu, 21 Jun 2001 20:59:07 -0400 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 RAA09798 for ; Thu, 21 Jun 2001 17:59:13 -0700 (PDT) From: "Jim Whitehead" To: Date: Thu, 21 Jun 2001 17:56:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <59697CCC6CE3D411B4CD00805FBB77672875CB@gbrwgcms03.wgc.gbr.xerox.com> Subject: RE: Minor corrections needed in IF header examples ? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5055 X-Loop: w3c-dist-auth@w3.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 > Secs 9.4.1.1 and 9.4.3 give examples using the "IF" header. However, both > examples use literally " " rest of the RFC) ? Actually, they're correct. Section 6.3 allows for any kind of lock token, so long as it meets the uniqueness requirements stated there. That said, it doesn't seem like there is a big advantage to allowing many different kinds of lock token schemes. Or big disadvantage for that matter :-) - Jim From w3c-dist-auth-request@w3.org Thu Jun 21 21:04: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 VAA22774 for ; Thu, 21 Jun 2001 21:04:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA25401; Thu, 21 Jun 2001 21:03:45 -0400 (EDT) Resent-Date: Thu, 21 Jun 2001 21:03:45 -0400 (EDT) Resent-Message-Id: <200106220103.VAA25401@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 VAA25375 for ; Thu, 21 Jun 2001 21:03:38 -0400 (EDT) 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 VAA14597 for ; Thu, 21 Jun 2001 21:03:38 -0400 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 SAA10248 for ; Thu, 21 Jun 2001 18:03:44 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Thu, 21 Jun 2001 18:01:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Subject: RE: Moving DASL to Experimental Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5056 X-Loop: w3c-dist-auth@w3.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 also interested in working on DASL some more. Xythos has implemented > it, including the basicsearch grammar :) The missing element in moving DASL forward once again is someone who is willing to act as the editor of this specification. A volunteer is needed... - Jim From w3c-dist-auth-request@w3.org Fri Jun 22 04:38: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 EAA14659 for ; Fri, 22 Jun 2001 04:38:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA13429; Fri, 22 Jun 2001 04:36:51 -0400 (EDT) Resent-Date: Fri, 22 Jun 2001 04:36:51 -0400 (EDT) Resent-Message-Id: <200106220836.EAA13429@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 EAA13316 for ; Fri, 22 Jun 2001 04:36:34 -0400 (EDT) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA16876 for ; Fri, 22 Jun 2001 04:36:24 -0400 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id JAA20590 for ; Fri, 22 Jun 2001 09:36:15 +0100 (BST) Received: from eur.xerox.com (eurdubmg04.eur.xerox.com [13.202.66.61]) by eurodns2.eur.xerox.com (8.9.3/8.9.3) with ESMTP id JAA17114 for ; Fri, 22 Jun 2001 09:36:13 +0100 (BST) Received: from eurgbrbh01.emeacinops.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 22 Jun 2001 09:33:48 +0100 Received: by eurgbrbh01.eur.xerox.com with Internet Mail Service (5.5.2651.58) id ; Fri, 22 Jun 2001 09:36:05 +0100 Received: from eur.xerox.com (eurdubmg01.eur.xerox.com [13.202.65.253]) by eurgbrbh01.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id NML2W9GK; Fri, 22 Jun 2001 09:35:59 +0100 Received: from gbrwgcbh01.wgc.gbr.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 22 Jun 2001 09:30:01 +0100 Received: by gbrwgcbh01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Jun 2001 09:35:59 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB77672875CC@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: "'Lisa Dusseault'" Cc: Webdav WG Date: Fri, 22 Jun 2001 09:35:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Obscure HTTP 1.1 header of the day... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5057 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Bits snipped > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: 21 June 2001 22:37 > To: Webdav WG > Subject: Obscure HTTP 1.1 header of the day... > > RFC2616 defines the Expect: header for _any_ request method > that normally > takes a body. > E.g. > POST /foo/bar HTTP/1.1 > Content-Length: 23248 > Expect: 100-Continue > > The server would respond with an error of some kind if it doesn't have > /foo/bar location, if /foo/bar doesn't allow POST, if the > Content-Length is > too long, or anything else. > If anybody's got any other expectation of how the header is > supposed to > work, I'd love to hear it. Thats how we understood it. > > Now how it affects WebDAV... RFC2518 makes no mention of the > Expect header, > but RFC2518 servers are expected to be compliant HTTP 1.1 > servers. This > would presumably mean they must support the Expect header. > So if I sent a > server the following request: > PROPPATCH /~lisa HTTP/1.1 > Content-Length: 1234 > Depth: infinity > Content-Type: text/xml > Expect: 100-Continue > > The server should NOT wait for a body on this request, and it > should respond > with 100 Continue if it's going to allow me to do the > PROPPATCH based on the > information provided. E.g. it tests to see if I have write > permission on > /~lisa and all its descendants. Er not to be too picky, but according to my interpretation, you cannot have a "Depth" header with PROPPATCH. Sec 9.2 states Depth header is only supported if a method explicitly provides support for it. Sec 8.2.x PROPPATCH doesn't mention Depth header at all. Server should return 400 (as per sec 9.2). If you removed Depth header from above example, server would only check /~lisa but no descendants. Am I wrong ? > > Unless RFC 2518 were to explicitly state that methods defined > there did not > use the Expect header... Then WebDAV implementors would only > have to worry > about implementing it correctly for PUT and POST. Hmm? One interpretation is that any WebDAV method that takes a body should handle the Expect header i.e. COPY, MOVE, LOCK, PUT, POST, PROPPATCH, PROPFIND (and MKCOL if server supported body). Granted some of these methods take XML as the body, but the server could perform some checks before it needed the XML and thus return a response. This meets RFC 2616 sec 8.2.3 "a server is willing to accept the request based on the request headers" and sec 10.1.1 "the initial part of the request has been received and has not been rejected by the server". Obviously, if the client submitted the XML after it received a 100, and the XML was invalid etc, the server could then send a 400 or whatever is appropriate. What do people think ? > > lisa > Regards Shaun Hall Xerox Europe From w3c-dist-auth-request@w3.org Fri Jun 22 05:04: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 FAA14883 for ; Fri, 22 Jun 2001 05:04:48 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA16272; Fri, 22 Jun 2001 05:01:46 -0400 (EDT) Resent-Date: Fri, 22 Jun 2001 05:01:46 -0400 (EDT) Resent-Message-Id: <200106220901.FAA16272@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 FAA16237 for ; Fri, 22 Jun 2001 05:01:37 -0400 (EDT) Received: from c2bapps9 ([193.113.154.18]) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA19235 for ; Fri, 22 Jun 2001 05:01:37 -0400 Received: from light.plus.com (actually host host217-32-143-110.hg.mdip.bt.net) by c2bapps9 with SMTP (XT-PP) with ESMTP; Fri, 22 Jun 2001 10:00:45 +0100 Received: (from joe@localhost) by light.plus.com (8.11.0/8.9.0) id f5M8teY20429 for w3c-dist-auth@w3c.org; Fri, 22 Jun 2001 09:55:40 +0100 X-Authentication-Warning: monolith.homenet: joe set sender to jorton@btconnect.com using -f Date: Fri, 22 Jun 2001 09:55:40 +0100 From: Joe Orton To: Webdav WG Message-ID: <20010622095540.A20407@light.plus.com> Mail-Followup-To: Webdav WG References: <59697CCC6CE3D411B4CD00805FBB77672875CC@gbrwgcms03.wgc.gbr.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <59697CCC6CE3D411B4CD00805FBB77672875CC@gbrwgcms03.wgc.gbr.xerox.com>; from Shaun.Hall@gbr.xerox.com on Fri, Jun 22, 2001 at 09:35:55AM +0100 Subject: Re: Obscure HTTP 1.1 header of the day... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5058 X-Loop: w3c-dist-auth@w3.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, Jun 22, 2001 at 09:35:55AM +0100, Hall, Shaun wrote: ... > > > > > Unless RFC 2518 were to explicitly state that methods defined > > there did not > > use the Expect header... Then WebDAV implementors would only > > have to worry > > about implementing it correctly for PUT and POST. Hmm? > > One interpretation is that any WebDAV method that takes a body should handle > the Expect header i.e. COPY, MOVE, LOCK, PUT, POST, PROPPATCH, PROPFIND (and > MKCOL if server supported body). As I said already - if a server claims HTTP/1.1 compliance, it is a MUST requirement that the server supports the Expect: 100-continue functionality, regardless of method used. RFC2616 is quite clear about how origin servers should behave in section 8.2.3, and WebDAV doesn't affect that in any way or allow alternate interpretation. > Granted some of these methods take XML as > the body, but the server could perform some checks before it needed the XML > and thus return a response. This meets RFC 2616 sec 8.2.3 "a server is > willing to accept the request based on the request headers" and sec 10.1.1 > "the initial part of the request has been received and has not been rejected > by the server". Obviously, if the client submitted the XML after it received > a 100, and the XML was invalid etc, the server could then send a 400 or > whatever is appropriate. Sure, I thought the best motiviation to use 100-continue in a DAV client was to prevent having to send a large request body with a PUT twice in the presence of authentication. i.e. PUT (expecting 100-continue) -> if authentication is required, the 401 response comes straight away before having to upload x mb to the server. Regards, joe From w3c-dist-auth-request@w3.org Fri Jun 22 05:12: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 FAA14932 for ; Fri, 22 Jun 2001 05:12:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA16605; Fri, 22 Jun 2001 05:04:08 -0400 (EDT) Resent-Date: Fri, 22 Jun 2001 05:04:08 -0400 (EDT) Resent-Message-Id: <200106220904.FAA16605@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 FAA16585 for ; Fri, 22 Jun 2001 05:04:02 -0400 (EDT) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA19582 for ; Fri, 22 Jun 2001 05:04:02 -0400 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id KAA04691 for ; Fri, 22 Jun 2001 10:03:54 +0100 (BST) Received: from eur.xerox.com (eurdubmg01.eur.xerox.com [13.202.65.253]) by eurodns2.eur.xerox.com (8.9.3/8.9.3) with ESMTP id KAA27959 for ; Fri, 22 Jun 2001 10:03:26 +0100 (BST) Received: from eurgbrbh02.emeacinops.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 22 Jun 2001 09:56:54 +0100 Received: by eurgbrbh02.eur.xerox.com with Internet Mail Service (5.5.2651.58) id <2WZAXW6Z>; Fri, 22 Jun 2001 10:02:47 +0100 Received: from eur.xerox.com (eurdubmg04.eur.xerox.com [13.202.66.61]) by eurgbrbh02.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id 2WZAXW62; Fri, 22 Jun 2001 10:02:34 +0100 Received: from gbrwgcbh01.wgc.gbr.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 22 Jun 2001 09:59:43 +0100 Received: by gbrwgcbh01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Jun 2001 10:02:03 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB77672875CD@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: "'Alan Kent'" Cc: w3c-dist-auth@w3.org Date: Fri, 22 Jun 2001 10:02:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Is this LOCK model correct? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5059 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Bits snipped, all IMHO. As usual, corrections please. > -----Original Message----- > From: Alan Kent [mailto:ajk@mds.rmit.edu.au] > Sent: 21 June 2001 06:43 > To: w3c-dist-auth@w3.org > Subject: Is this LOCK model correct? > > WebDAV talks about moving a resource under one locked > collection to under > another locked collection, and the old lock being lost and > the new lock > being gained. I am trying to get the semantic model in my head right. > Comments on my model below would be appreciated. > > I am trying to work out if you do a LOCK with depth infinity, what is > actually locked. Are the resources locked, or the URI's to > the resources? I think the lock applies to the URIs and any descendant of it. Imperfect example is a file system implementation. Infinite depth lock is applied to a directory and all its descendants (sub directories and files). Oh and of course, as HTTP/WebDAV are "root directory" based, a request with infinite depth lock on root (if permitted) would lock the entire server. Yes this does have uses, e.g. an administrator wants to perform a backup but nobody can make changes in the meantime. RFC2518 sec 8.10.3 states that "locks apply to resources, not URIs" and "LOCK request on a resource MUST NOT succeed if can not be honored by all the URIs through which the resource is addressable." If you think about it, the first statement makes sense when you consider the second statement. However, I think the server applies locks to resources, but our visualisation is that locks apply to URIs. > Since some of the lock description is URI based, and other > says resources > are locked, I have come to the following model of locking. > Please correct > me if its wrong: > > - Locks are based on URIs. See above. > > - A depth 0 lock puts a lock on that URI only. Depends on what you mean. A resource can have one or more URIs mapped to it (RFC 2518 sec 5.1). The resource would be locked and thus all the URIs that map to it. So no matter what URI (that was mapped to the resource) that was used by the client, the resource would appear to be locked as far as the client is concerned. However, none of the descendants would be locked. > > - A depth infinity lock identifies the leading path of a URI > - any URI with > additional path components is covered by the lock as well. Correct, although you might want to word it a little different - "descendants" is probably better. > > - To check if a resource is locked, *all* of the URIs to the resource > (if multiple bindings exist) must be checked against the locks that > currently exist. As stated above, a resource MUST NOT be locked if the lock cannot be honored by all the URIs which address it. You shouldn't have an occurrence where a resource is locked, but using a URI that maps to it indicates the resource isn't lock. So in *theory*, you shouldn't have to check all the URIs because any of the URIs (that map to the locked resource) can be used to discover that the resource is indeed locked. > > In my understanding, locks are not really associated directly with > resources because moving things to different URIs does not keep the > lock. So the lock is not independent of the URI - hence locks are > really best thought of as attached to URIs. Resources are locked > if any of the URIs to the resource is locked. > > Alan > Of course, its all a lot simpler if your server only supports one URI per resource. It makes the understanding of locking a lot easier :-) Regards Shaun Hall Xerox Europe From w3c-dist-auth-request@w3.org Fri Jun 22 09:13: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 JAA20136 for ; Fri, 22 Jun 2001 09:12:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA28045; Fri, 22 Jun 2001 09:11:44 -0400 (EDT) Resent-Date: Fri, 22 Jun 2001 09:11:44 -0400 (EDT) Resent-Message-Id: <200106221311.JAA28045@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 JAA28025 for ; Fri, 22 Jun 2001 09:11:38 -0400 (EDT) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA08470 for ; Fri, 22 Jun 2001 09:11:28 -0400 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id OAA28554 for ; Fri, 22 Jun 2001 14:11:22 +0100 (BST) Received: from [13.202.66.60] (eurdubmg03.eur.xerox.com [13.202.66.60]) by eurodns2.eur.xerox.com (8.9.3/8.9.3) with ESMTP id OAA00370 for ; Fri, 22 Jun 2001 14:11:14 +0100 (BST) Received: from eurgbrbh03.emeacinops.xerox.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 22 Jun 2001 14:04:36 +0100 Received: by eurgbrbh03.eur.xerox.com with Internet Mail Service (5.5.2651.58) id <2XAFL79K>; Fri, 22 Jun 2001 14:10:00 +0100 Received: from eur.xerox.com (eurdubmg01.eur.xerox.com [13.202.65.253]) by eurgbrbh03.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id 2XAFL78S; Fri, 22 Jun 2001 14:09:48 +0100 Received: from gbrwgcbh01.wgc.gbr.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 22 Jun 2001 14:03:51 +0100 Received: by gbrwgcbh01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Jun 2001 14:09:48 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB77672875CF@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: "'W3C WebDAV Server'" Date: Fri, 22 Jun 2001 14:09:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: IF header question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5060 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Investigation with a client lead to a little IF header problem. This is not meant to be taken as criticism of the vendor, but would like people's clarification. Scenario: 1) Client successfully "creates" a Lock Null Resource (LNR) by issuing a LOCK request. The server result contains the lock token "opaquelocktoken:xzy" in a Lock-Token header and in the XML. 2) Clients issues a PUT request after the LOCK above. However, the IF header is sort of empty. Snippet of the request: PUT /Test/foo.txt HTTP/1.1 If: ( ) etc As you can see, the IF header contains empty brackets. Our interpretation is that the IF header if supplied MUST? contain 1 or more lists (as RFC2518 sec 9.4), which is why the client gets a 400 response. What do people think? PS Our email servers have been very busy last few days so apologies if any of my posts appear to be a little out of sync. Regards Shaun Hall Xerox Europe From w3c-dist-auth-request@w3.org Sat Jun 23 23:20: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 XAA22823 for ; Sat, 23 Jun 2001 23:20:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA08322; Sat, 23 Jun 2001 23:19:04 -0400 (EDT) Resent-Date: Sat, 23 Jun 2001 23:19:04 -0400 (EDT) Resent-Message-Id: <200106240319.XAA08322@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 XAA08250 for ; Sat, 23 Jun 2001 23:18:53 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id XAA23173 for ; Sat, 23 Jun 2001 23:18:50 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Sat, 23 Jun 2001 23:24:31 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sat, 23 Jun 2001 23:24:31 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103625713@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Sat, 23 Jun 2001 23:24:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Can you BIND lock-null resources? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5061 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] > Is it expected that you should be able to BIND a lock-null resource? Interesting question. Since it is a resource, it makes sense that you can bind to it. I disagree (strongly :-). There are a large variety of things that you cannot do to a lock null resource. BIND should be one of them. (In fact, just about everything should be one of them :-). A lock null resource is just a mechanism (hack :-) to expose a URL that is locked but that currently is not bound to a resource. If you want to see just how bad the lock null mechanism really is, just compare any two implementations of lock null resources, and notice how different/non-interoperable they are. So I'd say, yes. But, I'd understand if servers decided to fail such a request. I'd say "no", and all servers should be required to fail such a request. > (1) Does the spec prohibit BIND-ing to a lock-null resource? > (OK, I am being lazy and have not reread the spec again to > verify this question - but the next question is the real question) I just gave it a quick look, and it seems like the BIND protocol specification does not mention lock null resources. That is an omission (somewhat conscious, because I try to ignore lock null resources in hopes that they will be replaced with a more sensible form of lock discovery). If it looks like we can't make lock null resources go away, we need to update the BIND protocol to explicitly disallow binding to a lock null resource. > (2) Regardless of the spec, do people think its acceptable to fail > BIND requests to a lock-null resource with an error? (Is there > any reason why someone would want to do it before doing a PUT > or MKCOL etc?) More than acceptable, commendable (:-). Cheers, Geoff From w3c-dist-auth-request@w3.org Sat Jun 23 23:25:11 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 XAA22833 for ; Sat, 23 Jun 2001 23:20:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA08352; Sat, 23 Jun 2001 23:19:12 -0400 (EDT) Resent-Date: Sat, 23 Jun 2001 23:19:12 -0400 (EDT) Resent-Message-Id: <200106240319.XAA08352@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 XAA08264 for ; Sat, 23 Jun 2001 23:18:54 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id XAA23176 for ; Sat, 23 Jun 2001 23:18:51 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Sat, 23 Jun 2001 23:24:33 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sat, 23 Jun 2001 23:24:33 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103625714@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Sat, 23 Jun 2001 23:24:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Is this LOCK model correct? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5062 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Hall, Shaun [mailto:Shaun.Hall@gbr.xerox.com] RFC2518 sec 8.10.3 states that "locks apply to resources, not URIs" and "LOCK request on a resource MUST NOT succeed if can not be honored by all the URIs through which the resource is addressable." If you think about it, the first statement makes sense when you consider the second statement. However, I think the server applies locks to resources, but our visualisation is that locks apply to URIs. Note: I will be arguing vigourously that we delete the "locks apply to resource, not URIs" phrase from the next draft of 2518. I believe this statement has proven to be very confusing and misleading. We should replace this with "a lock is on a URI, and a resource is locked if it is mapped to a locked URI". > - A depth 0 lock puts a lock on that URI only. Depends on what you mean. A resource can have one or more URIs mapped to it (RFC 2518 sec 5.1). The resource would be locked and thus all the URIs that map to it. So no matter what URI (that was mapped to the resource) that was used by the client, the resource would appear to be locked as far as the client is concerned. However, none of the descendants would be locked. Yes, you'd probably want to supplement this statement to make sure it is not misunderstood. Something like: "but the lock controls access to that resource, even when that resource is accessed through another URI". > - To check if a resource is locked, *all* of the URIs to the resource > (if multiple bindings exist) must be checked against the locks that > currently exist. As stated above, a resource MUST NOT be locked if the lock cannot be honored by all the URIs which address it. You shouldn't have an occurrence where a resource is locked, but using a URI that maps to it indicates the resource isn't lock. So in *theory*, you shouldn't have to check all the URIs because any of the URIs (that map to the locked resource) can be used to discover that the resource is indeed locked. Yes, the protocol does require that all the locks that affect a resource (from any URI) appear in the DAV:lockdiscovery property of that resource, so you just need to look at that property. Now an implementation may implement that property by a scan against all locks that exist on a URL that is mapped to that resource, but that's an implementation choice. > In my understanding, locks are not really associated directly with > resources because moving things to different URIs does not keep the > lock. So the lock is not independent of the URI - hence locks are > really best thought of as attached to URIs. Resources are locked > if any of the URIs to the resource is locked. Of course, its all a lot simpler if your server only supports one URI per resource. It makes the understanding of locking a lot easier :-) Yes, 2518 largely ignores the use case where one resource is mapped to multiple URI's (thus there was no BIND method, and DAV:lockdiscovery did not expose the URI that was locked). But we'll fix all that in the upcoming new draft of 2518 (:-). Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Jun 25 07:14: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 HAA10581 for ; Mon, 25 Jun 2001 07:14:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA27257; Mon, 25 Jun 2001 07:11:34 -0400 (EDT) Resent-Date: Mon, 25 Jun 2001 07:11:34 -0400 (EDT) Resent-Message-Id: <200106251111.HAA27257@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 HAA27236 for ; Mon, 25 Jun 2001 07:11:27 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA31543 for ; Mon, 25 Jun 2001 07:11:24 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10419; Mon, 25 Jun 2001 07:10:45 -0400 (EDT) Message-Id: <200106251110.HAA10419@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 25 Jun 2001 07:10:44 -0400 Subject: I-D ACTION:draft-ietf-webdav-acl-06.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5063 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : WebDAV Access Control Protocol Author(s) : G. Clemm, A. Hopkins, E. Sedlar, J. Whitehead Filename : draft-ietf-webdav-acl-06.txt Pages : 46 Date : 22-Jun-01 This document specifies a set of methods, headers, and message bodies that define Access Control extensions to the WebDAV Distributed Authoring Protocol. This protocol permits a client to remotely read and modify access control lists that instruct a server whether to grant or deny operations upon a resource (such as HTTP method invocations) by a given principal A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-acl-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-acl-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-acl-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010622075918.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-acl-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-acl-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010622075918.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Mon Jun 25 08:50: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 IAA13760 for ; Mon, 25 Jun 2001 08:50:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA00083; Mon, 25 Jun 2001 08:48:22 -0400 (EDT) Resent-Date: Mon, 25 Jun 2001 08:48:22 -0400 (EDT) Resent-Message-Id: <200106251248.IAA00083@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 IAA00059 for ; Mon, 25 Jun 2001 08:48:15 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA07582 for ; Mon, 25 Jun 2001 08:48:15 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Mon, 25 Jun 2001 08:53:52 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 08:53:52 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1036257BE@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Mon, 25 Jun 2001 08:53:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: New (minor) issue for RFC-2518: revising wording in section 8.3 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5064 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: RFC-2518 currently states in section 8.3: The MKCOL method is used to create a new collection. All DAV compliant resources MUST support the MKCOL method. But then section 8.3.1 goes on to say: If the resource identified by the Request-URI is non-null then the MKCOL MUST fail. I believe the second sentence of 8.3 should be changed to read: "All DAV compliant null and lock-null resources MUST support the MKCOL method". Since any other WebDAV resource is required to fail the MKCOL request, it seems rather bogus to require them to "support" it. In particular, this requirement damages any attempt by a client to populate its GUI with whether or not a MKCOL operation is appropriate for a given resource. Cheers, Geoff -----Original Message----- From: Joe Orton [mailto:jorton@btconnect.com] Sent: Friday, June 22, 2001 4:56 AM To: Webdav WG Subject: Re: Obscure HTTP 1.1 header of the day... On Fri, Jun 22, 2001 at 09:35:55AM +0100, Hall, Shaun wrote: ... > > > > > Unless RFC 2518 were to explicitly state that methods defined > > there did not > > use the Expect header... Then WebDAV implementors would only > > have to worry > > about implementing it correctly for PUT and POST. Hmm? > > One interpretation is that any WebDAV method that takes a body should handle > the Expect header i.e. COPY, MOVE, LOCK, PUT, POST, PROPPATCH, PROPFIND (and > MKCOL if server supported body). As I said already - if a server claims HTTP/1.1 compliance, it is a MUST requirement that the server supports the Expect: 100-continue functionality, regardless of method used. RFC2616 is quite clear about how origin servers should behave in section 8.2.3, and WebDAV doesn't affect that in any way or allow alternate interpretation. > Granted some of these methods take XML as > the body, but the server could perform some checks before it needed the XML > and thus return a response. This meets RFC 2616 sec 8.2.3 "a server is > willing to accept the request based on the request headers" and sec 10.1.1 > "the initial part of the request has been received and has not been rejected > by the server". Obviously, if the client submitted the XML after it received > a 100, and the XML was invalid etc, the server could then send a 400 or > whatever is appropriate. Sure, I thought the best motiviation to use 100-continue in a DAV client was to prevent having to send a large request body with a PUT twice in the presence of authentication. i.e. PUT (expecting 100-continue) -> if authentication is required, the 401 response comes straight away before having to upload x mb to the server. Regards, joe From w3c-dist-auth-request@w3.org Mon Jun 25 11:36:06 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18465 for ; Mon, 25 Jun 2001 11:36:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA10603; Mon, 25 Jun 2001 11:34:22 -0400 (EDT) Resent-Date: Mon, 25 Jun 2001 11:34:22 -0400 (EDT) Resent-Message-Id: <200106251534.LAA10603@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 LAA10577 for ; Mon, 25 Jun 2001 11:34:10 -0400 (EDT) Received: from aegis.cybertitan.com (aegis.cybertitan.com [209.239.42.49]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA29284 for ; Mon, 25 Jun 2001 11:34:06 -0400 Received: from kwmjr.knowareinc.com ([205.252.220.30]) by aegis.cybertitan.com (8.10.2/8.10.2) with SMTP id f5PFY0q27531 for ; Mon, 25 Jun 2001 11:34:00 -0400 From: "Michael J. Ryan" To: Date: Mon, 25 Jun 2001 11:29:44 -0400 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.00.3018.1300 Subject: MOVE fails on collection when IP address is used in the Destination header. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5065 X-Loop: w3c-dist-auth@w3.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 Folks, I'm running into something that I could use some help with. I'm trying to rename a collection and am receiving a 502 Bad Gateway. It appears that if I use the hostname in the Destination header, ie, webfolders.mydocsonline.com:80, then all goes well. However, if I resolve it to its IP address and use that instead, 38.144.45.187:80, then the command fails. Oh, the collection is empty in case that matters. Should the hostname and IP address be interchangable, or am I required to always use the hostname as part of the Destination header. Below are copies of the working and non-working MOVE request. Thanks in advance! Michael This fails: Using an IP address as the 'Destination:' Renaming "/New Folder" to "/asdf" Connecting to Host: 38.144.45.187 on Port 80 ==================== HTTP 'MOVE' REQUEST =============== MOVE /New%20Folder HTTP/1.1 Host: 38.144.45.187 User-Agent: SRT.WebIFS.Engine/1.0 Authorization: Basic abcdefghijklmnop= Accept-Language: en-us Overwrite: F Destination: http://38.144.45.187:80/asdf Content-Length: 0 =============== HTTP 'MOVE' REQUEST =============== =============== HTTP Response Header =============== HTTP/1.1 502 Bad Gateway Date: Mon, 25 Jun 2001 15:09:11 GMT Server: Apache/1.3.12 (Win32) DAV/0.9-MyDocs Set-Cookie: MyDocC=3B3744a95417-551; path=/; EXPIRES=Sun, 06-Jan-02 12:00:00 GMT Transfer-Encoding: chunked Content-Type: text/html =============== HTTP Response Header =============== This works: using the URL as the 'Destionation:' Renaming "/New Folder" to "/asdf" Connecting to Host: 38.144.45.187 on Port 80 ==================== HTTP 'MOVE' REQUEST =============== MOVE /New%20Folder HTTP/1.1 Host: webfolders.mydocsonline.com User-Agent: SRT.WebIFS.Engine/1.0 Authorization: Basic abcdefghijklmnop= Accept-Language: en-us Overwrite: F Destination: http://webfolders.mydocsonline.com:80/asdf Content-Length: 0 =============== HTTP 'MOVE' REQUEST =============== =============== HTTP Response Header =============== HTTP/1.1 201 Created Date: Mon, 25 Jun 2001 15:17:41 GMT Server: Apache/1.3.12 (Win32) DAV/0.9-MyDocs Set-Cookie: MyDocC=3B3744b85615-461; path=/; EXPIRES=Sun, 06-Jan-02 12:00:00 GMT Transfer-Encoding: chunked Content-Type: text/html =============== HTTP Response Header =============== From w3c-dist-auth-request@w3.org Mon Jun 25 12:04: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 MAA19476 for ; Mon, 25 Jun 2001 12:04:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA13669; Mon, 25 Jun 2001 12:02:53 -0400 (EDT) Resent-Date: Mon, 25 Jun 2001 12:02:53 -0400 (EDT) Resent-Message-Id: <200106251602.MAA13669@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 MAA13646 for ; Mon, 25 Jun 2001 12:02:44 -0400 (EDT) Received: from kebi.com ([210.116.116.14]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA01355 for ; Mon, 25 Jun 2001 12:02:43 -0400 Received: (from kebi@localhost) by kebi.com (8.11.0/8.11.0) id f5PG2Lu28024 for w3c-dist-auth@w3c.org; Tue, 26 Jun 2001 01:02:21 +0900 (KST) Date: Tue, 26 Jun 2001 01:02:21 +0900 (KST) Message-Id: <200106251602.f5PG2Lu28024@kebi.com> From: "Sung Kim" User-Host: 210.116.116.51 Reply-To: hunkim@kebi.com In-Reply-To: hunkim@kebi.com To: w3c-dist-auth@w3c.org X-Mailer: KEBI WWW-MAIL [version 1.0] X-Mail-Id: hunkim.28023993484941709 X-Priority: 3 MIME-Version: 1.0 Content-type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit Subject: RE:MOVE fails on collection when IP address is used in the Destination header. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5066 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit >Hi Folks, > I'm running into something that I could use some help with. I'm >trying to rename a collection and am receiving a 502 Bad Gateway. I think this is misimplement of the server. As you know the RFC dosen't say about the using IP address or hostname in Destination header. But you must use the same host name(ot IP address) in Host and Destination header. IP address destination header works on Microsoft-IIS/5.0. MOVE /hunkim HTTP/1.1 Host: hunkim.kebi.com Destination: http://12.99.96.140/hunkim2 HTTP/1.1 207 Multi-Status Server: Microsoft-IIS/5.0 Date: Mon, 25 Jun 2001 15:48:45 GMT Content-Type: text/xml Transfer-Encoding: chunked b5 http://12.99.96.140/hunkim2HTTP/1.1 502 Bad Gateway 0 MOVE /hunkim HTTP/1.1 Host: 12.99.96.140 Destination: http://12.99.96.140/hunkim2 HTTP/1.1 201 Created Server: Microsoft-IIS/5.0 Date: Mon, 25 Jun 2001 15:52:39 GMT Location: http://12.99.96.140/hunkim2/ Content-Type: text/xml Content-Length: 0 -- "Dreams become reality!" hunkim@kebi.com Free webmail hosting service MNARA.NET -- This e-mail was sent by FREE KEBI Mail at http://kebi.com/-- From w3c-dist-auth-request@w3.org Mon Jun 25 12:15: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 MAA19761 for ; Mon, 25 Jun 2001 12:15:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA14153; Mon, 25 Jun 2001 12:11:02 -0400 (EDT) Resent-Date: Mon, 25 Jun 2001 12:11:02 -0400 (EDT) Resent-Message-Id: <200106251611.MAA14153@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 MAA14122 for ; Mon, 25 Jun 2001 12:10:49 -0400 (EDT) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA02351 for ; Mon, 25 Jun 2001 12:10:49 -0400 Received: from grumman (ip43.indianapolis17.in.pub-ip.psi.net [38.33.134.43]) by granger.mail.mindspring.net (8.9.3/8.8.5) with SMTP id MAA29203 for ; Mon, 25 Jun 2001 12:10:47 -0400 (EDT) From: "Keith Wannamaker" To: Date: Mon, 25 Jun 2001 11:08:27 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <200106251602.f5PG2Lu28024@kebi.com> Importance: Normal Subject: RE: MOVE fails on collection when IP address is used in the Destination header. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5067 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is only true for servers which lack support for cross-server copies. Xythos, for example, supports this so the host and destination header can be different. Keith | -----Original Message----- | I think this is misimplement of the server. | As you know the RFC dosen't say about the using IP address or | hostname in Destination header. | | But you must use the same host name(ot IP address) | in Host and Destination header. From w3c-dist-auth-request@w3.org Mon Jun 25 17:13:05 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 RAA27259 for ; Mon, 25 Jun 2001 17:13:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA06095; Mon, 25 Jun 2001 17:11:42 -0400 (EDT) Resent-Date: Mon, 25 Jun 2001 17:11:42 -0400 (EDT) Resent-Message-Id: <200106252111.RAA06095@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 RAA06071 for ; Mon, 25 Jun 2001 17:11:21 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA01696 for ; Mon, 25 Jun 2001 17:11:21 -0400 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 RAA402544; Mon, 25 Jun 2001 17:08:50 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5PL4gN49994; Mon, 25 Jun 2001 17:04:42 -0400 Importance: Normal To: "Clemm, Geoff" Cc: WebDAV X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Mon, 25 Jun 2001 17:09:10 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.7 |March 21, 2001) at 06/25/2001 05:10:35 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Are you using lock discovery? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5068 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << That is an omission (somewhat conscious, because I try to ignore lock null resources in hopes that they will be replaced with a more sensible form of lock discovery). If it looks like we can't make lock null resources go away, we need to update the BIND protocol to explicitly disallow binding to a lock null resource. >> The paragraph above from Geoff prompts me to ask.... Do we have any clients out there that do lock discovery or are dependent on this property? ...and... Do we have any that require LNR's? From w3c-dist-auth-request@w3.org Mon Jun 25 18:53: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 SAA28973 for ; Mon, 25 Jun 2001 18:53:25 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA09775; Mon, 25 Jun 2001 18:49:25 -0400 (EDT) Resent-Date: Mon, 25 Jun 2001 18:49:25 -0400 (EDT) Resent-Message-Id: <200106252249.SAA09775@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 SAA09755 for ; Mon, 25 Jun 2001 18:49:18 -0400 (EDT) Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA10589 for ; Mon, 25 Jun 2001 18:49:18 -0400 Received: from [216.36.75.57] (HELO beaver) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.7) with SMTP id 1013502; Mon, 25 Jun 2001 15:46:31 -0700 From: "Lisa Dusseault" To: "Michael J. Ryan" , Date: Mon, 25 Jun 2001 15:47:05 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: RE: MOVE fails on collection when IP address is used in the Destination header. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5069 X-Loop: w3c-dist-auth@w3.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 > Should the hostname and IP address be interchangable, or am I > required to always use the hostname as part of the Destination > header. Below are copies of the working and non-working MOVE request. The host name and the IP address are not guaranteed to be interchangeable. As Keith implied, in the Xythos implementation we only treat the host name and IP address as identical if the administrator sets them up this way. lisa From w3c-dist-auth-request@w3.org Mon Jun 25 18:58: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 SAA29025 for ; Mon, 25 Jun 2001 18:58:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA09931; Mon, 25 Jun 2001 18:54:46 -0400 (EDT) Resent-Date: Mon, 25 Jun 2001 18:54:46 -0400 (EDT) Resent-Message-Id: <200106252254.SAA09931@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 SAA09884 for ; Mon, 25 Jun 2001 18:54:26 -0400 (EDT) Received: from c2bapps2.btconnect.com (c2bapps2.btconnect.com [193.113.209.22]) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA10982 for ; Mon, 25 Jun 2001 18:54:26 -0400 Received: from light.plus.com (actually host host217-32-146-157.hg.mdip.bt.net) by c2bapps2 with SMTP (XT-PP) with ESMTP; Mon, 25 Jun 2001 23:53:43 +0100 Received: (from joe@localhost) by light.plus.com (8.11.0/8.9.0) id f5PMl9h01644; Mon, 25 Jun 2001 23:47:09 +0100 X-Authentication-Warning: monolith.homenet: joe set sender to jorton@btconnect.com using -f Date: Mon, 25 Jun 2001 23:47:09 +0100 From: Joe Orton To: "Michael J. Ryan" Cc: w3c-dist-auth@w3c.org Message-ID: <20010625234709.A1617@light.plus.com> Mail-Followup-To: "Michael J. Ryan" , w3c-dist-auth@w3c.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjr@SouthRiverTech.com on Mon, Jun 25, 2001 at 11:29:44AM -0400 Subject: Re: MOVE fails on collection when IP address is used in the Destination header. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5070 X-Loop: w3c-dist-auth@w3.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, On Mon, Jun 25, 2001 at 11:29:44AM -0400, Michael J. Ryan wrote: > Hi Folks, > I'm running into something that I could use some help with. I'm > trying to rename a collection and am receiving a 502 Bad Gateway. > It appears that if I use the hostname in the Destination header, ie, > webfolders.mydocsonline.com:80, then all goes well. However, if I resolve > it to its IP address and use that instead, 38.144.45.187:80, > then the command fails. Oh, the collection is empty in case that matters. > > Should the hostname and IP address be interchangable, or am I > required to always use the hostname as part of the Destination > header. Below are copies of the working and non-working MOVE request. You should be using the hostname if you know it. If your client is given a hostname, then resolves it to the IP address, and uses that IP address the Host header, that defeats the whole point of having the Host header in the first place: name-based virtual hosting. Consider that a serious client bug. :) If your client is only told the IP address by the user, then I think you're stuck, unless you do a reverse DNS lookup, which might not be a good idea anyway. Apache/mod_dav won't like an IP address in the Destination header in the default configuration[*], and MOVE/COPY will return 502. Regards, joe [*] though it can be configured to know the IP address with the ServerAlias directive From w3c-dist-auth-request@w3.org Mon Jun 25 19:57: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 TAA00146 for ; Mon, 25 Jun 2001 19:57:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA12994; Mon, 25 Jun 2001 19:56:42 -0400 (EDT) Resent-Date: Mon, 25 Jun 2001 19:56:42 -0400 (EDT) Resent-Message-Id: <200106252356.TAA12994@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 TAA12970 for ; Mon, 25 Jun 2001 19:56:32 -0400 (EDT) Received: from smtp-relay-1.Adobe.COM (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA16265 for ; Mon, 25 Jun 2001 19:56:32 -0400 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 QAA12458 for ; Mon, 25 Jun 2001 16:59:23 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id QAA04248; Mon, 25 Jun 2001 16:55:46 -0700 (PDT) Received: from [153.32.159.20] ([153.32.159.20]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id GFIFTB00.VLX for ; Mon, 25 Jun 2001 16:55:59 -0700 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com (Unverified) Message-Id: In-Reply-To: References: Date: Mon, 25 Jun 2001 12:23:47 -0700 To: WebDAV Working Group From: "Dan Brotsky" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5071 X-Loop: w3c-dist-auth@w3.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 also like Julian's proposal and would be glad to see it incorporated into 2518. But there are a few questions related to live properties that I'm hoping Julian and others would comment on: 1. I work on a number of servers that have specialized live ("computed" in the deltaV sense) properties for workflow tracking. It seems that we could use the extended PROPFIND to indicate to clients the datatype of those properties, but Julian only shows an example where the client has indicated the datatype. Were live properties expected to obey the same extension rule? If so we might want to clarify this and add an example. 2. Some of my servers implement "type-restricted" live properties which are essentially dead properties whose values are restricted to a certain datatype. These servers will reject PROPPATCH requests that use the wrong datatype whether or not the client has declared a datatype in the PROPPATCH. Julian's proposal shows an example of a 422 response when the PROPPATCH-declared datatype doesn't match the datatype of the value; I would also like to use such a response when the value's datatype doesn't match the PROPFIND-shown (and enforced) datatype. How does this strike people? dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Mon Jun 25 21:50: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 VAA03105 for ; Mon, 25 Jun 2001 21:50:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA18824; Mon, 25 Jun 2001 21:49:29 -0400 (EDT) Resent-Date: Mon, 25 Jun 2001 21:49:29 -0400 (EDT) Resent-Message-Id: <200106260149.VAA18824@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 VAA18770 for ; Mon, 25 Jun 2001 21:49:20 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA25965 for ; Mon, 25 Jun 2001 21:49:18 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id EDB6449B49; Tue, 26 Jun 2001 11:48:33 +1000 (EST) Date: Tue, 26 Jun 2001 11:48:33 +1000 From: Alan Kent To: Webdav WG Message-ID: <20010626114833.D21551@io.mds.rmit.edu.au> References: <3906C56A7BD1F54593344C05BD1374B1036257BE@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1036257BE@SUS-MA1IT01>; from Clemm, Geoff on Mon, Jun 25, 2001 at 08:53:54AM -0400 Subject: Re: New (minor) issue for RFC-2518: revising wording in section 8.3 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5072 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Mon, Jun 25, 2001 at 08:53:54AM -0400, Clemm, Geoff wrote: > RFC-2518 currently states in section 8.3: > > The MKCOL method is used to create a new collection. All DAV > compliant resources MUST support the MKCOL method. What does this really mean? Does a resource support MKCOL? Is MKCOL "applied" to the parent collection? The URI is the new collection resource to be created isn't it? If I have a non-collection resource (eg a web page /foo.html), is it mandatory that I be able to do a MKCOL /foo.html/newcoll? > But then section 8.3.1 goes on to say: > > If the resource identified by the Request-URI is > non-null then the MKCOL MUST fail. > > I believe the second sentence of 8.3 should be changed to read: > "All DAV compliant null and lock-null resources MUST support > the MKCOL method". I think I sort of agree with what you are saying, but isn't it more that the MKCOL method is really being applied to either the parent collection resource or a lock-null resource (if it exists for the new collection URI)? I am not sure of the wording - my point is that not all "null" resources need to support MKCOL. And related, weren't we trying to reword "null resources" as "unbound URIs" or something? > Since any other WebDAV resource is > required to fail the MKCOL request, it seems rather bogus > to require them to "support" it. In particular, this > requirement damages any attempt by a client to populate its GUI with > whether or not a MKCOL operation is appropriate > for a given resource. Bottom line: I agree with the concept, but I am not sure if the new wording is quite right yet. How about from: > The MKCOL method is used to create a new collection. All DAV > compliant resources MUST support the MKCOL method. to The MKCOL method is used to create a new collection. If the URI is a DAV compliant lock-null resource, the resource MUST support the MKCOL method. All DAV compliant collection resources must also support MKCOL for creating new members for the collection. Hmmm. Getting the wording right is hard isn't it? Note: I am only reading what you have specified. I have not read the surrounding text in the spec. Alan From w3c-dist-auth-request@w3.org Mon Jun 25 23:15: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 XAA05514 for ; Mon, 25 Jun 2001 23:15:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA21104; Mon, 25 Jun 2001 23:14:11 -0400 (EDT) Resent-Date: Mon, 25 Jun 2001 23:14:11 -0400 (EDT) Resent-Message-Id: <200106260314.XAA21104@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 XAA21080 for ; Mon, 25 Jun 2001 23:14:01 -0400 (EDT) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA32051 for ; Mon, 25 Jun 2001 23:14:01 -0400 Received: from gmgw01.us.oracle.com (gmgw01.us.oracle.com [130.35.249.115]) by inet-mail4.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5Q381527506 for ; Mon, 25 Jun 2001 20:08:01 -0700 (PDT) Received: from esedlarlaptop (dhcp-4op7-4op8-east-130-35-171-33.us.oracle.com [130.35.171.33]) by gmgw01.us.oracle.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f5Q3DTv16338 for ; Mon, 25 Jun 2001 20:13:29 -0700 (PDT) From: "Eric Sedlar" To: "WebDAV Working Group" Date: Mon, 25 Jun 2001 20:18:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Subject: RE: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5073 X-Loop: w3c-dist-auth@w3.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 like it! > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dan Brotsky > Sent: Monday, June 25, 2001 12:24 PM > To: WebDAV Working Group > Subject: RE: Proposal for marshalling property type information > > > I also like Julian's proposal and would be glad to see it > incorporated into 2518. But there are a few questions related to > live properties that I'm hoping Julian and others would comment on: > > 1. I work on a number of servers that have specialized live > ("computed" in the deltaV sense) properties for workflow tracking. > It seems that we could use the extended PROPFIND to indicate to > clients the datatype of those properties, but Julian only shows an > example where the client has indicated the datatype. Were live > properties expected to obey the same extension rule? If so we might > want to clarify this and add an example. > > 2. Some of my servers implement "type-restricted" live properties > which are essentially dead properties whose values are restricted to > a certain datatype. These servers will reject PROPPATCH requests > that use the wrong datatype whether or not the client has declared a > datatype in the PROPPATCH. Julian's proposal shows an example of a > 422 response when the PROPPATCH-declared datatype doesn't match the > datatype of the value; I would also like to use such a response when > the value's datatype doesn't match the PROPFIND-shown (and enforced) > datatype. How does this strike people? > > dan > -- > Daniel Brotsky, Adobe Systems > tel 408-536-4150, pager 877-704-4062 > 2-way pager email: > > From w3c-dist-auth-request@w3.org Mon Jun 25 23:38: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 XAA06246 for ; Mon, 25 Jun 2001 23:38:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA21269; Mon, 25 Jun 2001 23:30:32 -0400 (EDT) Resent-Date: Mon, 25 Jun 2001 23:30:32 -0400 (EDT) Resent-Message-Id: <200106260330.XAA21269@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 XAA21245 for ; Mon, 25 Jun 2001 23:30:18 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id XAA00632 for ; Mon, 25 Jun 2001 23:30:18 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Mon, 25 Jun 2001 23:36:44 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 23:36:44 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103625AD5@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Mon, 25 Jun 2001 23:36:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: New (minor) issue for RFC-2518: revising wording in section 8 .3 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5074 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Alan Kent [mailto:ajk@mds.rmit.edu.au] On Mon, Jun 25, 2001 at 08:53:54AM -0400, Clemm, Geoff wrote: > RFC-2518 currently states in section 8.3: > > The MKCOL method is used to create a new collection. All DAV > compliant resources MUST support the MKCOL method. What does this really mean? Does a resource support MKCOL? RFC-2518 tries to present a model where every URI is mapped to some resource, but that most URIs are mapped to a (or perhaps, "the") null resource. In that model, yes, a resource supports MKCOL (in particular, some null resources and all lock-null resources). Is MKCOL "applied" to the parent collection? A method is usually described as being applied to the request-URL, but I agree that some operations (e.g. MKCOL and DELETE) result in modifications to the parent collection of the request-URL. The URI is the new collection resource to be created isn't it? Yes. If I have a non-collection resource (eg a web page /foo.html), is it mandatory that I be able to do a MKCOL /foo.html/newcoll? Actually, it is required that it fail, since for /foo.html/newcoll to be a consistent DAV namespace, /foo.html MUST be a collection. > But then section 8.3.1 goes on to say: > > If the resource identified by the Request-URI is > non-null then the MKCOL MUST fail. > > I believe the second sentence of 8.3 should be changed to read: > "All DAV compliant null and lock-null resources MUST support > the MKCOL method". I think I sort of agree with what you are saying, but isn't it more that the MKCOL method is really being applied to either the parent collection resource or a lock-null resource (if it exists for the new collection URI)? If we fix the model in 2518, yes. My modified text was intended to be compatible with the model currently exposed by 2518. I am not sure of the wording - my point is that not all "null" resources need to support MKCOL. In general, the fact that a resource supports a method does not mean that the method will succeed when being applied to that resource (for example, a version-controlled resource supports both the CHECKOUT and CHECKIN operations, but only one will succeed at any given time. So in the MKCOL case, a null resource can be said to support the MKCOL operation, even if it will fail when the parent of the null resource is also a null resource (i.e. it is not yet a collection). And related, weren't we trying to reword "null resources" as "unbound URIs" or something? Yes, I think that would be better, but then we would have to say that there are some operations that can be applied to unbound URI's (e.g. MKCOL) > Since any other WebDAV resource is > required to fail the MKCOL request, it seems rather bogus > to require them to "support" it. In particular, this > requirement damages any attempt by a client to populate its GUI with > whether or not a MKCOL operation is appropriate > for a given resource. Bottom line: I agree with the concept, but I am not sure if the new wording is quite right yet. How about from: > The MKCOL method is used to create a new collection. All DAV > compliant resources MUST support the MKCOL method. to The MKCOL method is used to create a new collection. If the URI is a DAV compliant lock-null resource, the resource MUST support the MKCOL method. All DAV compliant collection resources must also support MKCOL for creating new members for the collection. Probably not quite right, unless we are comfortable saying that MKCOL applies to the parent of the request-URL, instead of to the request-URL itself. Hmmm. Getting the wording right is hard isn't it? Yes, it always is! Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Jun 26 06:14: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 GAA26279 for ; Tue, 26 Jun 2001 06:14:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA08295; Tue, 26 Jun 2001 06:09:22 -0400 (EDT) Resent-Date: Tue, 26 Jun 2001 06:09:22 -0400 (EDT) Resent-Message-Id: <200106261009.GAA08295@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 GAA08271 for ; Tue, 26 Jun 2001 06:09:10 -0400 (EDT) Received: from d06lmsgate-2.uk.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA01628 for ; Tue, 26 Jun 2001 06:09:10 -0400 Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate-2.uk.ibm.com (1.0.0) with ESMTP id KAA27804 for ; Tue, 26 Jun 2001 10:51:51 +0100 Received: from d06ml034.portsmouth.uk.ibm.com (d06ml034_cs0 [9.180.35.31]) by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5QA7l3189932 for ; Tue, 26 Jun 2001 11:07:47 +0100 To: WebDAV Working Group X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Tim Ellison" Date: Tue, 26 Jun 2001 10:50:24 +0100 X-MIMETrack: Serialize by Router on D06ML034/06/M/IBM(Release 5.0.6 |December 14, 2000) at 26/06/2001 11:06:53 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5075 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: "Dan Brotsky" wrote: > I also like Julian's proposal and would be glad to see it > incorporated into 2518. But there are a few questions related to > live properties that I'm hoping Julian and others would comment on: > > 1. I work on a number of servers that have specialized live > ("computed" in the deltaV sense) properties for workflow tracking. > It seems that we could use the extended PROPFIND to indicate to > clients the datatype of those properties, but Julian only shows an > example where the client has indicated the datatype. Were live > properties expected to obey the same extension rule? If so we might > want to clarify this and add an example. I suggest we say that servers MAY return type information for live proeprties. > 2. Some of my servers implement "type-restricted" live properties > which are essentially dead properties whose values are restricted to > a certain datatype. These servers will reject PROPPATCH requests > that use the wrong datatype whether or not the client has declared a > datatype in the PROPPATCH. Julian's proposal shows an example of a > 422 response when the PROPPATCH-declared datatype doesn't match the > datatype of the value; I would also like to use such a response when > the value's datatype doesn't match the PROPFIND-shown (and enforced) > datatype. How does this strike people? Great. Tim From w3c-dist-auth-request@w3.org Tue Jun 26 12:55:54 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 MAA26486 for ; Tue, 26 Jun 2001 12:55:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA01951; Tue, 26 Jun 2001 12:50:26 -0400 (EDT) Resent-Date: Tue, 26 Jun 2001 12:50:26 -0400 (EDT) Resent-Message-Id: <200106261650.MAA01951@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 MAA01931 for ; Tue, 26 Jun 2001 12:50:15 -0400 (EDT) Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA27935 for ; Tue, 26 Jun 2001 12:50:15 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA41854 for ; Tue, 26 Jun 2001 12:31:54 -0400 Received: from f3n44e (d03nm044h.boulder.ibm.com [9.99.140.44]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f5QGmwE103454 for ; Tue, 26 Jun 2001 10:48:58 -0600 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Tao Wan" Date: Tue, 26 Jun 2001 09:48:54 -0700 X-MIMETrack: Serialize by Router on D03NM044/03/M/IBM(Release 5.0.6 |December 14, 2000) at 06/26/2001 10:48:58 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: question of PROPPATCH method Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5076 X-Loop: w3c-dist-auth@w3.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, In RFC2518, 8.2, it is said: " DAV compliant resources should support the setting of arbitrary dead porperties " what does this mean? could you please give me an example to explain it. Thanks a lot. Tao Wan DBTI Content Management IBM Silicon Valley Labs, San Jose, CA Phone: 408 463 2256 Internet email: want@us.ibm.com From w3c-dist-auth-request@w3.org Tue Jun 26 17:35: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 RAA22148 for ; Tue, 26 Jun 2001 17:35:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA15443; Tue, 26 Jun 2001 17:30:51 -0400 (EDT) Resent-Date: Tue, 26 Jun 2001 17:30:51 -0400 (EDT) Resent-Message-Id: <200106262130.RAA15443@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 RAA15423 for ; Tue, 26 Jun 2001 17:30:39 -0400 (EDT) Received: from smtp-relay-2.Adobe.COM (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA29247 for ; Tue, 26 Jun 2001 17:30:38 -0400 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 OAA13853 for ; Tue, 26 Jun 2001 14:35:30 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id OAA17923; Tue, 26 Jun 2001 14:29:52 -0700 (PDT) Received: from [192.168.1.6] ([130.248.188.66]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id GFK3Q500.QN9; Tue, 26 Jun 2001 14:30:05 -0700 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: References: Date: Tue, 26 Jun 2001 14:29:52 -0700 To: "Jason Crawford" From: "Dan Brotsky" Cc: "Clemm Geoff" , WebDAV Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: Are you using lock discovery? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5077 X-Loop: w3c-dist-auth@w3.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 have any clients out there that do lock discovery or are dependent on >this property? Sure. Every Adobe client uses lock discovery frequently. Uploading a multi-megabyte file via PUT only to have the server then tell you your lock is gone generally gives rise to a very bad user experience :^). So we always try to discover workflow state changes before doing lengthy operations that expect a certain state. > >...and... > >Do we have any that require LNR's? Hard to know which LNR behavior you're referring to. If you mean requiring a way to discover that the "URL" you "locked" is still locked then yes, definitely, see above. If you mean requiring that such a resource vanish if you unlock without a PUT then no. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Tue Jun 26 18:49: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 SAA03526 for ; Tue, 26 Jun 2001 18:49:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA20622; Tue, 26 Jun 2001 18:41:39 -0400 (EDT) Resent-Date: Tue, 26 Jun 2001 18:41:39 -0400 (EDT) Resent-Message-Id: <200106262241.SAA20622@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 SAA20591 for ; Tue, 26 Jun 2001 18:41:28 -0400 (EDT) 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 SAA04159 for ; Tue, 26 Jun 2001 18:41:27 -0400 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 PAA10119; Tue, 26 Jun 2001 15:41:32 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Cc: "Joachim Feise" Date: Tue, 26 Jun 2001 15:39:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Are you using lock discovery? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5078 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jason Crawford asks: > Do we have any clients out there that do lock discovery or are > dependent on > this property? As I recall, the DAV Explorer client uses lock discovery. I believe it's smart enough to do lock discovery if a resource is locked, and DAV Explorer doesn't have the lock token. It then tries the lock token on the off chance the requesting principal actually owns the lock. Or maybe we just talked about doing this, and never implemented it. I can't remember -- Joe? > Do we have any that require LNR's? I don't believe DAV Explorer depends on LNRs in any way. - Jim From w3c-dist-auth-request@w3.org Tue Jun 26 18:51: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 SAA03943 for ; Tue, 26 Jun 2001 18:51:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA21230; Tue, 26 Jun 2001 18:43:59 -0400 (EDT) Resent-Date: Tue, 26 Jun 2001 18:43:59 -0400 (EDT) Resent-Message-Id: <200106262243.SAA21230@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 SAA21210 for ; Tue, 26 Jun 2001 18:43:54 -0400 (EDT) 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 SAA04420 for ; Tue, 26 Jun 2001 18:43:53 -0400 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 PAA10558 for ; Tue, 26 Jun 2001 15:43:59 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Tue, 26 Jun 2001 15:41:34 -0700 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: FW: [Moderator Action] WebDAV and strong authentication Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5079 X-Loop: w3c-dist-auth@w3.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 SAA21230 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA03943 Accidentally caught by the spam filter. I've added to the accept2 list. By comparison, over the past two days the spam filter caught 5 spam emails. - Jim -----Original Message----- From: Juan Carlos Pérez Aguayo [mailto:juancarlos.perez@acepta.com] Sent: Monday, June 25, 2001 3:04 PM To: gstein@lyra.org Cc: w3c-dist-auth@w3.org Subject: [Moderator Action] WebDAV and strong authentication Can I authenticate the users with digital certificates and WebDAV? How? thanks Juan From w3c-dist-auth-request@w3.org Tue Jun 26 19:23: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 TAA10193 for ; Tue, 26 Jun 2001 19:23:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA22980; Tue, 26 Jun 2001 19:21:57 -0400 (EDT) Resent-Date: Tue, 26 Jun 2001 19:21:57 -0400 (EDT) Resent-Message-Id: <200106262321.TAA22980@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 TAA22960 for ; Tue, 26 Jun 2001 19:21:36 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA08099 for ; Tue, 26 Jun 2001 19:21:36 -0400 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 TAA493938; Tue, 26 Jun 2001 19:18:48 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5QNEeM82378; Tue, 26 Jun 2001 19:14:40 -0400 Importance: Normal To: "Jim Whitehead" Cc: "WebDAV WG" , "Joachim Feise" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Tue, 26 Jun 2001 19:09:02 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.7 |March 21, 2001) at 06/26/2001 07:20:36 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Are you using lock discovery? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5080 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << As I recall, the DAV Explorer client uses lock discovery. I believe it's smart enough to do lock discovery if a resource is locked, and DAV Explorer doesn't have the lock token. It then tries the lock token on the off chance the requesting principal actually owns the lock. >> The spec deprecates that kind of client behavior for the reason that two programs that don't know about each other might be logged on as the same person, right? From w3c-dist-auth-request@w3.org Tue Jun 26 19:29: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 TAA11677 for ; Tue, 26 Jun 2001 19:29:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA23184; Tue, 26 Jun 2001 19:25:26 -0400 (EDT) Resent-Date: Tue, 26 Jun 2001 19:25:26 -0400 (EDT) Resent-Message-Id: <200106262325.TAA23184@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 TAA23147 for ; Tue, 26 Jun 2001 19:25:17 -0400 (EDT) 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 TAA08381 for ; Tue, 26 Jun 2001 19:25:17 -0400 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 QAA18592; Tue, 26 Jun 2001 16:25:22 -0700 (PDT) From: "Jim Whitehead" To: "Jason Crawford" Cc: "WebDAV WG" , "Joachim Feise" Date: Tue, 26 Jun 2001 16:22:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Are you using lock discovery? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5081 X-Loop: w3c-dist-auth@w3.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 I recall, the DAV Explorer client > uses > lock discovery. I believe it's smart enough to do lock discovery if a > resource is locked, and DAV Explorer doesn't have the lock token. It then > tries the lock token on the off chance the requesting principal actually > owns the lock. > >> > The spec deprecates that kind of client behavior for the reason that two > programs that don't know about each other might be logged on as the same > person, right? Not really -- an authoring program will at least know that it had to do lock discovery to grab the lock token, and presumably would then query the user for whether they want to grab the lock. In the case of DAV Explorer, we felt that a user might want to undo a lock taken out by themselves using another program as a way of either testing the protocol (and applications), or undoing a lock after an app. had crashed. - Jim From w3c-dist-auth-request@w3.org Tue Jun 26 20:44: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 UAA27516 for ; Tue, 26 Jun 2001 20:44:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA25390; Tue, 26 Jun 2001 20:43:27 -0400 (EDT) Resent-Date: Tue, 26 Jun 2001 20:43:27 -0400 (EDT) Resent-Message-Id: <200106270043.UAA25390@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 UAA25366 for ; Tue, 26 Jun 2001 20:43:15 -0400 (EDT) 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 UAA14502 for ; Tue, 26 Jun 2001 20:43:14 -0400 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 RAA01015 for ; Tue, 26 Jun 2001 17:43:20 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Tue, 26 Jun 2001 17:40:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: FW: [Moderator Action] Re: Are you using lock discovery? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5082 X-Loop: w3c-dist-auth@w3.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 Oops, accidentally caught by the spam filter. I've added Joe's email to the accept2 list. - Jim -----Original Message----- From: Joachim Feise [mailto:jfeise@ics.uci.edu] Sent: Tuesday, June 26, 2001 4:30 PM To: Jim Whitehead Cc: WebDAV WG Subject: [Moderator Action] Re: Are you using lock discovery? Jim Whitehead wrote: > > Jason Crawford asks: > > Do we have any clients out there that do lock discovery or are > > dependent on > > this property? > > As I recall, the DAV Explorer client uses > lock discovery. I believe it's smart enough to do lock discovery if a > resource is locked, and DAV Explorer doesn't have the lock token. It then > tries the lock token on the off chance the requesting principal actually > owns the lock. > > Or maybe we just talked about doing this, and never implemented it. I can't > remember -- Joe? You described the implementation accurately. > > > Do we have any that require LNR's? > > I don't believe DAV Explorer depends on LNRs in any way. It doesn't. -Joe From w3c-dist-auth-request@w3.org Tue Jun 26 21:37: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 VAA12857 for ; Tue, 26 Jun 2001 21:37:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA27140; Tue, 26 Jun 2001 21:31:27 -0400 (EDT) Resent-Date: Tue, 26 Jun 2001 21:31:27 -0400 (EDT) Resent-Message-Id: <200106270131.VAA27140@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 VAA27117 for ; Tue, 26 Jun 2001 21:31:13 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id VAA18377 for ; Tue, 26 Jun 2001 21:31:13 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Tue, 26 Jun 2001 21:37:36 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Jun 2001 21:37:36 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B10377064A@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV WG Date: Tue, 26 Jun 2001 21:37:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Are you using lock discovery? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5083 X-Loop: w3c-dist-auth@w3.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 hope by "grabbing the lock token", you meant unlocking the resource and asking for a new lock (and then, only after warning the user about the risk of overwriting the value from another editor session that they forgot about). This at least gives you some protection from forgetting about another session you had open (an attempt to update from that earlier session will then fail because the lock token is no longer valid). Cheers, Geoff -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] Sent: Tuesday, June 26, 2001 7:23 PM To: Jason Crawford Cc: WebDAV WG; Joachim Feise Subject: RE: Are you using lock discovery? > << > As I recall, the DAV Explorer client > uses > lock discovery. I believe it's smart enough to do lock discovery if a > resource is locked, and DAV Explorer doesn't have the lock token. It then > tries the lock token on the off chance the requesting principal actually > owns the lock. > >> > The spec deprecates that kind of client behavior for the reason that two > programs that don't know about each other might be logged on as the same > person, right? Not really -- an authoring program will at least know that it had to do lock discovery to grab the lock token, and presumably would then query the user for whether they want to grab the lock. In the case of DAV Explorer, we felt that a user might want to undo a lock taken out by themselves using another program as a way of either testing the protocol (and applications), or undoing a lock after an app. had crashed. - Jim From w3c-dist-auth-request@w3.org Tue Jun 26 22:30:06 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01202 for ; Tue, 26 Jun 2001 22:30:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA29585; Tue, 26 Jun 2001 22:28:42 -0400 (EDT) Resent-Date: Tue, 26 Jun 2001 22:28:42 -0400 (EDT) Resent-Message-Id: <200106270228.WAA29585@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 WAA29561 for ; Tue, 26 Jun 2001 22:28:34 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA23059 for ; Tue, 26 Jun 2001 22:28:34 -0400 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 WAA198260 for ; Tue, 26 Jun 2001 22:26:12 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5R2M4M183902 for ; Tue, 26 Jun 2001 22:22:04 -0400 Importance: Normal To: "WebDAV WG" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Tue, 26 Jun 2001 22:12:36 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 06/26/2001 10:27:59 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Are you using lock discovery? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5084 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << As I recall, the DAV Explorer client uses lock discovery. I believe it's smart enough to do lock discovery if a resource is locked, and DAV Explorer doesn't have the lock token. It then tries the lock token on the off chance the requesting principal actually owns the lock. >> Just a tangent... I'm sure Jim know this, but I'd just like to warn other client developers that servers are not obligated to expose the lock-token in the lock-discovery property. Servers might chose not to expose the tokens so as to avoid the situation described in section 7.6. Make sure your clients can handle a server not returning the lock token in the lock-discovery property. From w3c-dist-auth-request@w3.org Wed Jun 27 02:30: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 CAA23947 for ; Wed, 27 Jun 2001 02:30:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA08606; Wed, 27 Jun 2001 02:29:29 -0400 (EDT) Resent-Date: Wed, 27 Jun 2001 02:29:29 -0400 (EDT) Resent-Message-Id: <200106270629.CAA08606@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 CAA08544 for ; Wed, 27 Jun 2001 02:29:15 -0400 (EDT) Received: from smtp-relay-2.Adobe.COM (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA10071 for ; Wed, 27 Jun 2001 02:29:16 -0400 Received: from inner-relay-1.Adobe.COM (inner-relay-1.corp.adobe.com [153.32.1.51]) by smtp-relay-2.Adobe.COM (8.8.6) with ESMTP id XAA02273 for ; Tue, 26 Jun 2001 23:34:08 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com by inner-relay-1.Adobe.COM (8.8.5) with ESMTP id XAA21670; Tue, 26 Jun 2001 23:27:48 -0700 (PDT) Received: from [192.168.1.6] ([130.248.188.66]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id GFKSNV00.1A9; Tue, 26 Jun 2001 23:28:43 -0700 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: References: Date: Tue, 26 Jun 2001 23:09:37 -0700 To: "Tim Ellison" From: "Dan Brotsky" Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5085 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I'm definitely in the camp that thinks lock-null resources should go away in the next revise of 2518, and I very much like the way this discussion went, which I would summarize as: 0. we don't talk about "null resources" any more, just unmapped-URIs. 1. lock-null resources are just "regular resources" that are required to respond to certain methods in certain ways. 2. creating a lock-null resource should return 201 So far I would say a simple rephrasing might be: a. The result of a LOCK call on an unmapped-URI is that the URI gets mapped to a no-content resource that responds to certain (non-write) methods with 404 or 405. But the problem with this rephrasing is that: 3. GET on the resource returns 404 or 405 not 204 (as would be expected for a "regular" no-content resource). [Aside: 404 really makes no sense here, given that the resource is required to appear as a member of its parent collection - PROPFIND returns 207 but GET returns 404? But that's a different issue.] 4. OPTIONS and other non-write methods return 404 or 405 for no particular reason. 5. UNLOCK on the resource returns the URL to an unmapped state. Note that restrictions #3 and #4 are unmotivated, as far as I can tell; the only "special" aspect of this resource (aside from #5) is that the server really can't know whether it's a collection or not. [Aside: The DAV:resourcetype property really needs another value in these cases, such as "indeterminate". But that's another issue.] Which brings us to #5: UNLOCK (essentially) deletes the resource. I think I understand the motivation for this: a client that locks the URI but then decides not to write it doesn't want to have to do a delete in order not to leave an empty resource mapped to the URI. But my problem is that the spec *mandates* this behavior, rather than leaving up to the server (or allowing the client to request it specially as part of the UNLOCK). Essentially the spec is requiring that a LOCK/UNLOCK combination with no intervening write operations do *nothing* to a URI or the resource mapped to it. (This is a mandate that has been picked up in deltaV, as well.) But while I can understand that servers might want to work this way, and that clients might want to request this, I can see no reason to mandate this. In fact, my experience with building workflow and document-management servers leads me to entirely the other conclusion: servers need the discretion to interpret LOCK as a statement of intent in the workflow, one that an UNLOCK does not necessarily "undo." In particular, LOCK is the only way in WebDAV for a client to create a no-content resource (as opposed to one with content-length 0), and just because the client doesn't create the content before unlocking doesn't mean that the client wants the created resource (and live properties such as its creator) to be expunged from the server. As we revise 2518, I think we should give servers much more discretion about how they handle LOCK/UNLOCK pairs, and possibly we should give clients a way of indicating in the UNLOCK that "the lock was a mistake, undo it if you can" (much as deltaV allows undoing a checkout). If we do so, I think lock-null resources (and their concomitant problems) can be done away with completely, and LOCK can simply be seen as creating a no-content resource when applied to unmapped URIs. Servers who wish to preserve the lock-null kinds of behavior for those resources are welcome to, and they will still be in compliance with the spec. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Wed Jun 27 08:18:59 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 IAA14220 for ; Wed, 27 Jun 2001 08:18:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA19057; Wed, 27 Jun 2001 04:56:15 -0400 (EDT) Resent-Date: Wed, 27 Jun 2001 04:56:15 -0400 (EDT) Resent-Message-Id: <200106270856.EAA19057@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 EAA18810 for ; Wed, 27 Jun 2001 04:55:11 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA18849 for ; Wed, 27 Jun 2001 03:58:50 -0400 Received: from maggie [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Wed, 27 Jun 2001 09:57:52 +0200 From: "Stefan Eissing" To: "WebDAV WG" Date: Wed, 27 Jun 2001 09:57:51 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: AW: Are you using lock discovery? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5086 X-Loop: w3c-dist-auth@w3.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 > [mailto:w3c-dist-auth-request@w3.org]Im Auftrag von Jason Crawford > > << > As I recall, the DAV Explorer client > uses > lock discovery. I believe it's smart enough to do lock discovery if a > resource is locked, and DAV Explorer doesn't have the lock token. It then > tries the lock token on the off chance the requesting principal actually > owns the lock. > >> > Just a tangent... > > I'm sure Jim know this, but I'd just like to warn other client developers > that servers are not obligated to expose the lock-token in the > lock-discovery property. Servers might chose not to expose the tokens so > as to avoid the situation described in section 7.6. Make sure > your clients > can handle a server not returning the lock token in the lock-discovery > property. Well, thanks for the warning. Which server(s) would that be? And will they prevent a client application/operating system/network connection from crashing or will they have another method to discover locks and unlock resources? Stefan From w3c-dist-auth-request@w3.org Wed Jun 27 09:01: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 IAA14219 for ; Wed, 27 Jun 2001 08:18:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA28392; Wed, 27 Jun 2001 08:17:47 -0400 (EDT) Resent-Date: Wed, 27 Jun 2001 08:17:47 -0400 (EDT) Resent-Message-Id: <200106271217.IAA28392@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 IAA28337 for ; Wed, 27 Jun 2001 08:17:28 -0400 (EDT) Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA11297 for ; Wed, 27 Jun 2001 08:17:28 -0400 Received: from sadurgin (h00010322f091.ne.mediaone.net [24.128.51.20]) by chmls06.mediaone.net (8.11.1/8.11.1) with SMTP id f5RCHR817319 for ; Wed, 27 Jun 2001 08:17:27 -0400 (EDT) From: "Tom Bednarz" To: "WebDAV WG" Date: Wed, 27 Jun 2001 08:28:38 -0400 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: Are you using lock discovery? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5087 X-Loop: w3c-dist-auth@w3.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 > Do we have any clients out there that do lock discovery or are > dependent on > this property? Goliath will use this property and has the capability to let users 'reclaim' a lock as their own. --tom From w3c-dist-auth-request@w3.org Wed Jun 27 13:23: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 NAA26651 for ; Wed, 27 Jun 2001 13:23:50 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA23889; Wed, 27 Jun 2001 13:22:20 -0400 (EDT) Resent-Date: Wed, 27 Jun 2001 13:22:20 -0400 (EDT) Resent-Message-Id: <200106271722.NAA23889@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 NAA23845 for ; Wed, 27 Jun 2001 13:21:57 -0400 (EDT) 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 NAA21078 for ; Wed, 27 Jun 2001 13:21:57 -0400 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 KAA25763 for ; Wed, 27 Jun 2001 10:22:00 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 27 Jun 2001 10:19:36 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Subject: RE: Are you using lock discovery? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5088 X-Loop: w3c-dist-auth@w3.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 sure Jim know this, but I'd just like to warn other client developers > that servers are not obligated to expose the lock-token in the > lock-discovery property. Servers might chose not to expose the tokens so > as to avoid the situation described in section 7.6. Make sure > your clients can handle a server not returning the lock token in the lock-discovery > property. Well, actually, this did take me a bit by surprise. But, after re-reading Section 13.8, Jason is right, we do allow servers to hold back some elements of the lockdiscovery property. But, the stated rationale is access control, not keeping clients from grabbing lock tokens. It seems to me the root issue here is how much you trust users to remove their own locks. For DAV Explorer, we felt the people using the tool would likely either be doing server development, or setup of a WebDAV server. That it why we added the protocol logging feature to the tool. While DAV Explorer is useful enough to accomplish some day-to-day editing work, we didn't think that would be its main use (we were somewhat surprised to see DAV Explorer get bundled with the Merlin server: http://www.abriasoft.com/products/product16.php :-). Since we felt our user base would be fairly sophisticated, we were comfortable giving them the ability to grab locks that they took out using another program (and no, I don't think DAV Explorer prompts the user about this). This makes it a handy protocol exploration tool. If you want to know exactly how tool X performs when a lock is yanked out from under it, you can use DAV Explorer to unlock the resource. For more mainstream *authoring* tools, I agree completely that, if the user is granted the ability to grab a lock, they should be shown a dialog box about the event. As for tools like Goliath that give a filesystem-like view, I think a good case can be made either way (prompting or no prompting). Perhaps it should be configurable, or the dialog should have an option to not be displayed in the future. - Jim From w3c-dist-auth-request@w3.org Wed Jun 27 13:47:03 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 NAA11742 for ; Wed, 27 Jun 2001 13:47:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA26571; Wed, 27 Jun 2001 13:46:03 -0400 (EDT) Resent-Date: Wed, 27 Jun 2001 13:46:03 -0400 (EDT) Resent-Message-Id: <200106271746.NAA26571@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 NAA26407 for ; Wed, 27 Jun 2001 13:45:26 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA24232 for ; Wed, 27 Jun 2001 13:45:26 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 27 Jun 2001 13:51:39 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 13:51:39 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E24EC@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV WG Date: Wed, 27 Jun 2001 13:51:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Are you using lock discovery? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5089 X-Loop: w3c-dist-auth@w3.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 have to vigorously disagree with Jim's suggestion that it is ever reasonable behavior for a client to steal a lock without first having a dialog with the user. People work on multiple machines, and with multiple clients on the same machine that access the same resources (e.g. Word and the Windows Explorer). It is just too easy to forget or not notice that you already have a client open that is modifying a resource. And if the user does explicitly tell the client to go ahead and steal the lock, it should do so by unlocking the resource, and obtaining a new lock. This ensures that if the original locking client is still around, it will not overwrite the data you just uploaded. Cheers, Geoff -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] Sent: Wednesday, June 27, 2001 1:20 PM To: WebDAV WG Subject: RE: Are you using lock discovery? > I'm sure Jim know this, but I'd just like to warn other client developers > that servers are not obligated to expose the lock-token in the > lock-discovery property. Servers might chose not to expose the tokens so > as to avoid the situation described in section 7.6. Make sure > your clients can handle a server not returning the lock token in the lock-discovery > property. Well, actually, this did take me a bit by surprise. But, after re-reading Section 13.8, Jason is right, we do allow servers to hold back some elements of the lockdiscovery property. But, the stated rationale is access control, not keeping clients from grabbing lock tokens. It seems to me the root issue here is how much you trust users to remove their own locks. For DAV Explorer, we felt the people using the tool would likely either be doing server development, or setup of a WebDAV server. That it why we added the protocol logging feature to the tool. While DAV Explorer is useful enough to accomplish some day-to-day editing work, we didn't think that would be its main use (we were somewhat surprised to see DAV Explorer get bundled with the Merlin server: http://www.abriasoft.com/products/product16.php :-). Since we felt our user base would be fairly sophisticated, we were comfortable giving them the ability to grab locks that they took out using another program (and no, I don't think DAV Explorer prompts the user about this). This makes it a handy protocol exploration tool. If you want to know exactly how tool X performs when a lock is yanked out from under it, you can use DAV Explorer to unlock the resource. For more mainstream *authoring* tools, I agree completely that, if the user is granted the ability to grab a lock, they should be shown a dialog box about the event. As for tools like Goliath that give a filesystem-like view, I think a good case can be made either way (prompting or no prompting). Perhaps it should be configurable, or the dialog should have an option to not be displayed in the future. - Jim From w3c-dist-auth-request@w3.org Wed Jun 27 13:55: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 NAA17563 for ; Wed, 27 Jun 2001 13:55:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA27803; Wed, 27 Jun 2001 13:54:47 -0400 (EDT) Resent-Date: Wed, 27 Jun 2001 13:54:47 -0400 (EDT) Resent-Message-Id: <200106271754.NAA27803@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 NAA27449 for ; Wed, 27 Jun 2001 13:54:12 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA18476 for ; Wed, 27 Jun 2001 12:57:26 -0400 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 MAA237856; Wed, 27 Jun 2001 12:55:04 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5RGou8103450; Wed, 27 Jun 2001 12:50:56 -0400 Importance: Normal To: "Stefan Eissing" Cc: "WebDAV WG" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Wed, 27 Jun 2001 12:39:03 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 06/27/2001 12:56:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: token-less lock-discovery Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5090 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > Well, thanks for the warning. Which server(s) would that be? I don't know if there are any now. Perhaps someone will speak up. I doubt a server would be configured this way by default, but I wouldn't be surprised if some were to be configurable in this regard so as to leave it up the administrator to deal with situations local to his sites if the need develops. The spec left this option open intentionally for the reasons described in section 7.6. << And will they prevent a client application/operating system/network connection from crashing or will they have another method to discover locks and unlock resources? >> Of course not. The thinking was that problems of the ilk you described could be addressed in several ways: 1) the locks can time out 2) the server administrator can break a lock 3) a client can store it's lock tokens persistantly in what they deem to be an adequately secure fashion. The the most compeling case against it was the case of clients who store their tokens locally and whose users switch between machines (home vs work) often and know their applications won't interact in bad ways. ("Drat! I left my token on my office machine! I really want to put my updated file back on the server! Grumble.") There are of course ways around this, but it's doubtful that these approaches would be used. I believe that's pretty much the history and it answers your question. My thinking is that section 7.6 might be a red herring and this last case certainly can be common. But we did leave the final decision up to the server developer and administrator. I personally feel the behavior you expect should be the default. But I also believe that administrator should be able to configure this if they discover there is a need to hide the tokens. I also believe that clients should not be written to be dependent on the visibility of the token. So what are clients to do? In your case, you could probably use an IF header in a quick benign operation to determine if the lock is still there before you do the expensive operation. In JimW's case, he just needs to make sure his client doesn't do anything if the lock-discovery doesn't reveal the token. And generically client apps should request appropriate lock timeout periods and keep a persistant vault of their tokens if they feel they or their OS are prone to crashing. BTW... this topic is a tangent and not the reason I asked my original question. :-) J. From w3c-dist-auth-request@w3.org Wed Jun 27 15:33: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 PAA17285 for ; Wed, 27 Jun 2001 15:33:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA04790; Wed, 27 Jun 2001 15:31:38 -0400 (EDT) Resent-Date: Wed, 27 Jun 2001 15:31:38 -0400 (EDT) Resent-Message-Id: <200106271931.PAA04790@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 PAA04764 for ; Wed, 27 Jun 2001 15:31:21 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA03113 for ; Wed, 27 Jun 2001 15:31:20 -0400 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 PAA327718; Wed, 27 Jun 2001 15:28:54 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5RJOi8178340; Wed, 27 Jun 2001 15:24:44 -0400 Importance: Normal To: "Jim Whitehead" Cc: "WebDAV WG" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Wed, 27 Jun 2001 15:27:23 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 06/27/2001 03:30:41 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: lock-discovery property without a lock-token Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5091 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << It seems to me the root issue here is how much you trust users to remove their own locks. >> I agree it's trust... users and client tools... be it to remove or replace or reuse. << Since we felt our user base would be fairly sophisticated, we were comfortable giving them the ability to grab locks that they took out using another program (and no, I don't think DAV Explorer prompts the user about this). >> As an exploration tool I'd guess it probably should be able to do *anything*. :-) But of course I'd think it should ask the user before it takes discretionary action. Knowing something was locked with a lock that you didn't have seems like an important part of exploring. So does controling what's done... (Cancel) (Reuse lock) (Replace lock) << This makes it a handy protocol exploration tool. If you want to know exactly how tool X performs when a lock is yanked out from under it, you can use DAV Explorer to unlock the resource. >> Understood. << For more mainstream *authoring* tools, I agree completely that, if the user is granted the ability to grab a lock, they should be shown a dialog box about the event. As for tools like Goliath that give a filesystem-like view, I think a good case can be made either way (prompting or no prompting). Perhaps it should be configurable, or the dialog should have an option to not be displayed in the future. >> I guess configurable is okay... but it probably should not be made easy for an ordinary user to avoid being prompted. It doesn't sound like Merlin's customers would be using DAVExplorer in the exploratory way that DAVExplorer was intended to be used. It sounds like DAVExplorer could get them in trouble. J. From w3c-dist-auth-request@w3.org Wed Jun 27 15:45: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 PAA17875 for ; Wed, 27 Jun 2001 15:45:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA05526; Wed, 27 Jun 2001 15:40:48 -0400 (EDT) Resent-Date: Wed, 27 Jun 2001 15:40:48 -0400 (EDT) Resent-Message-Id: <200106271940.PAA05526@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 PAA05491 for ; Wed, 27 Jun 2001 15:40:22 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA03972 for ; Wed, 27 Jun 2001 15:40:22 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 27 Jun 2001 15:46:45 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 15:46:45 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E24EE@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Wed, 27 Jun 2001 15:46:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5092 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree with point 0, but believe there is a much simpler answer to points 1 and 2. In particular, we just define a LOCK on an unmapped URI as just being equivalent to an atomic PUT (with an empty body) followed by a LOCK. No other special behavior. I am very much against making any of this behavior server-defined. That would just make the already difficult job of writing an interoperable client that much harder. And if I really could roll back time, I'd say: "LOCK on an unmapped URL just fails" (i.e. you can only LOCK a URL if there is a resource mapped to that URL). If you want to LOCK a URL, you first have to create a resource at that URL to display the lock. If some other client gets their lock in before you, that's no different from somebody today getting their lock-null resource created before you. In either case, you have to either try your request again at some other URL, or wait until the other client releases the lock. Cheers, Geoff -----Original Message----- From: Dan Brotsky [mailto:dbrotsky@Adobe.COM] Sent: Wednesday, June 27, 2001 2:10 AM To: Tim Ellison Cc: w3c-dist-auth@w3.org Subject: RE: Status code for creating lock-null resource I'm definitely in the camp that thinks lock-null resources should go away in the next revise of 2518, and I very much like the way this discussion went, which I would summarize as: 0. we don't talk about "null resources" any more, just unmapped-URIs. 1. lock-null resources are just "regular resources" that are required to respond to certain methods in certain ways. 2. creating a lock-null resource should return 201 So far I would say a simple rephrasing might be: a. The result of a LOCK call on an unmapped-URI is that the URI gets mapped to a no-content resource that responds to certain (non-write) methods with 404 or 405. But the problem with this rephrasing is that: 3. GET on the resource returns 404 or 405 not 204 (as would be expected for a "regular" no-content resource). [Aside: 404 really makes no sense here, given that the resource is required to appear as a member of its parent collection - PROPFIND returns 207 but GET returns 404? But that's a different issue.] 4. OPTIONS and other non-write methods return 404 or 405 for no particular reason. 5. UNLOCK on the resource returns the URL to an unmapped state. Note that restrictions #3 and #4 are unmotivated, as far as I can tell; the only "special" aspect of this resource (aside from #5) is that the server really can't know whether it's a collection or not. [Aside: The DAV:resourcetype property really needs another value in these cases, such as "indeterminate". But that's another issue.] Which brings us to #5: UNLOCK (essentially) deletes the resource. I think I understand the motivation for this: a client that locks the URI but then decides not to write it doesn't want to have to do a delete in order not to leave an empty resource mapped to the URI. But my problem is that the spec *mandates* this behavior, rather than leaving up to the server (or allowing the client to request it specially as part of the UNLOCK). Essentially the spec is requiring that a LOCK/UNLOCK combination with no intervening write operations do *nothing* to a URI or the resource mapped to it. (This is a mandate that has been picked up in deltaV, as well.) But while I can understand that servers might want to work this way, and that clients might want to request this, I can see no reason to mandate this. In fact, my experience with building workflow and document-management servers leads me to entirely the other conclusion: servers need the discretion to interpret LOCK as a statement of intent in the workflow, one that an UNLOCK does not necessarily "undo." In particular, LOCK is the only way in WebDAV for a client to create a no-content resource (as opposed to one with content-length 0), and just because the client doesn't create the content before unlocking doesn't mean that the client wants the created resource (and live properties such as its creator) to be expunged from the server. As we revise 2518, I think we should give servers much more discretion about how they handle LOCK/UNLOCK pairs, and possibly we should give clients a way of indicating in the UNLOCK that "the lock was a mistake, undo it if you can" (much as deltaV allows undoing a checkout). If we do so, I think lock-null resources (and their concomitant problems) can be done away with completely, and LOCK can simply be seen as creating a no-content resource when applied to unmapped URIs. Servers who wish to preserve the lock-null kinds of behavior for those resources are welcome to, and they will still be in compliance with the spec. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Wed Jun 27 16:41:08 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 QAA15976 for ; Wed, 27 Jun 2001 16:41:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA11016; Wed, 27 Jun 2001 16:40:07 -0400 (EDT) Resent-Date: Wed, 27 Jun 2001 16:40:07 -0400 (EDT) Resent-Message-Id: <200106272040.QAA11016@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 QAA10987 for ; Wed, 27 Jun 2001 16:39:42 -0400 (EDT) Received: from smtp-relay-1.Adobe.COM (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA11277 for ; Wed, 27 Jun 2001 16:39:41 -0400 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 NAA26250 for ; Wed, 27 Jun 2001 13:42:30 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id NAA05118; Wed, 27 Jun 2001 13:38:52 -0700 (PDT) Received: from [192.168.1.6] ([130.248.184.82]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id GFLW1400.4KG; Wed, 27 Jun 2001 13:39:04 -0700 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1018E24EE@SUS-MA1IT01> References: <3906C56A7BD1F54593344C05BD1374B1018E24EE@SUS-MA1IT01> Date: Wed, 27 Jun 2001 13:28:26 -0700 To: "Clemm Geoff" From: "Dan Brotsky" Cc: w3c-dist-auth@w3.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5093 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: So it sounds like you and I are in violent agreement about this: we both believe LOCK should simply create a no-content resource that's mapped to the URI and locked. You seem to take the additional position that there shouldn't be any way for clients to request the "auto-delete on unlock" behavior. It also sounds like you're suggesting that servers shouldn't be allowed to implement the "lock-null special method handling" or "auto-delete on unlock" behavior as a matter of policy, but (while I might agree this is not a good thing for them to do) I don't think we should be trying to legislate server policy (and it would be a hugely backward-incompatible change). dan At 3:46 PM -0400 6/27/01, Clemm, Geoff wrote: >I agree with point 0, but believe there is a much simpler >answer to points 1 and 2. In particular, we just define a LOCK >on an unmapped URI as just being equivalent to an atomic >PUT (with an empty body) followed by a LOCK. No other special >behavior. > >I am very much against making any of this behavior server-defined. >That would just make the already difficult job of writing an >interoperable client that much harder. > >And if I really could roll back time, I'd say: "LOCK on an >unmapped URL just fails" (i.e. you can only LOCK a URL if >there is a resource mapped to that URL). If you want to LOCK >a URL, you first have to create a resource at that URL to >display the lock. If some other client gets their >lock in before you, that's no different from somebody today >getting their lock-null resource created before you. In either case, >you have to either try your request again at some other URL, >or wait until the other client releases the lock. > >Cheers, >Geoff > >-----Original Message----- >From: Dan Brotsky [mailto:dbrotsky@Adobe.COM] >Sent: Wednesday, June 27, 2001 2:10 AM >To: Tim Ellison >Cc: w3c-dist-auth@w3.org >Subject: RE: Status code for creating lock-null resource > > >I'm definitely in the camp that thinks lock-null resources should go >away in the next revise of 2518, and I very much like the way this >discussion went, which I would summarize as: > >0. we don't talk about "null resources" any more, just unmapped-URIs. > >1. lock-null resources are just "regular resources" that are required >to respond to certain methods in certain ways. > >2. creating a lock-null resource should return 201 > >So far I would say a simple rephrasing might be: > >a. The result of a LOCK call on an unmapped-URI is that the URI gets >mapped to a no-content resource that responds to certain (non-write) >methods with 404 or 405. > >But the problem with this rephrasing is that: > >3. GET on the resource returns 404 or 405 not 204 (as would be >expected for a "regular" no-content resource). [Aside: 404 really >makes no sense here, given that the resource is required to appear as >a member of its parent collection - PROPFIND returns 207 but GET >returns 404? But that's a different issue.] > >4. OPTIONS and other non-write methods return 404 or 405 for no >particular reason. > >5. UNLOCK on the resource returns the URL to an unmapped state. > >Note that restrictions #3 and #4 are unmotivated, as far as I can >tell; the only "special" aspect of this resource (aside from #5) is >that the server really can't know whether it's a collection or not. >[Aside: The DAV:resourcetype property really needs another value in >these cases, such as "indeterminate". But that's another issue.] > >Which brings us to #5: UNLOCK (essentially) deletes the resource. I >think I understand the motivation for this: a client that locks the >URI but then decides not to write it doesn't want to have to do a >delete in order not to leave an empty resource mapped to the URI. >But my problem is that the spec *mandates* this behavior, rather than >leaving up to the server (or allowing the client to request it >specially as part of the UNLOCK). > >Essentially the spec is requiring that a LOCK/UNLOCK combination with >no intervening write operations do *nothing* to a URI or the resource >mapped to it. (This is a mandate that has been picked up in deltaV, >as well.) But while I can understand that servers might want to work >this way, and that clients might want to request this, I can see no >reason to mandate this. > >In fact, my experience with building workflow and document-management >servers leads me to entirely the other conclusion: servers need the >discretion to interpret LOCK as a statement of intent in the >workflow, one that an UNLOCK does not necessarily "undo." In >particular, LOCK is the only way in WebDAV for a client to create a >no-content resource (as opposed to one with content-length 0), and >just because the client doesn't create the content before unlocking >doesn't mean that the client wants the created resource (and live >properties such as its creator) to be expunged from the server. > >As we revise 2518, I think we should give servers much more >discretion about how they handle LOCK/UNLOCK pairs, and possibly we >should give clients a way of indicating in the UNLOCK that "the lock >was a mistake, undo it if you can" (much as deltaV allows undoing a >checkout). If we do so, I think lock-null resources (and their >concomitant problems) can be done away with completely, and LOCK can >simply be seen as creating a no-content resource when applied to >unmapped URIs. Servers who wish to preserve the lock-null kinds of >behavior for those resources are welcome to, and they will still be >in compliance with the spec. > > dan >-- >Daniel Brotsky, Adobe Systems >tel 408-536-4150, pager 877-704-4062 >2-way pager email: -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Wed Jun 27 17:23: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 RAA14599 for ; Wed, 27 Jun 2001 17:23:14 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA13672; Wed, 27 Jun 2001 17:22:15 -0400 (EDT) Resent-Date: Wed, 27 Jun 2001 17:22:15 -0400 (EDT) Resent-Message-Id: <200106272122.RAA13672@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 RAA13599 for ; Wed, 27 Jun 2001 17:21:46 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA15851 for ; Wed, 27 Jun 2001 17:21:46 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 27 Jun 2001 17:28:08 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 17:28:08 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E24F1@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Wed, 27 Jun 2001 17:21:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5094 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Yes, I think violent agreement is accurate description of our attitude toward lock null resources. The reason I believe backward compatibility is not an issue here is that very few servers have implemented the specified lock-null behavior (e.g. auto-delete on unlock, or the ability to create an arbitrary type of resource at the locked URL (e.g. a collection by MKCOL). Since there is no common functionality for lock-null resources today, the only interoperable thing a client can do today is to create the resource first and then lock it. So I'm just suggesting that we capture that interoperable approach in the revised spec. So I think we should just say "A server SHOULD fail an attempt to lock an unmapped URL", and then remain silent on what a server might end up doing if it lets the lock of an unmapped URL succeed. In general, a MAY here is of little more use to the client than having the protocol remain discretely silent, and the benefit of using one of the several different flavors of lock-null behavior is unlikely to warrant writing special purpose code for each of those flavors. Cheers, Geoff -----Original Message----- From: Dan Brotsky [mailto:dbrotsky@Adobe.COM] Sent: Wednesday, June 27, 2001 4:28 PM To: Clemm Geoff Cc: w3c-dist-auth@w3.org Subject: RE: Status code for creating lock-null resource So it sounds like you and I are in violent agreement about this: we both believe LOCK should simply create a no-content resource that's mapped to the URI and locked. You seem to take the additional position that there shouldn't be any way for clients to request the "auto-delete on unlock" behavior. It also sounds like you're suggesting that servers shouldn't be allowed to implement the "lock-null special method handling" or "auto-delete on unlock" behavior as a matter of policy, but (while I might agree this is not a good thing for them to do) I don't think we should be trying to legislate server policy (and it would be a hugely backward-incompatible change). dan At 3:46 PM -0400 6/27/01, Clemm, Geoff wrote: >I agree with point 0, but believe there is a much simpler >answer to points 1 and 2. In particular, we just define a LOCK >on an unmapped URI as just being equivalent to an atomic >PUT (with an empty body) followed by a LOCK. No other special >behavior. > >I am very much against making any of this behavior server-defined. >That would just make the already difficult job of writing an >interoperable client that much harder. > >And if I really could roll back time, I'd say: "LOCK on an >unmapped URL just fails" (i.e. you can only LOCK a URL if >there is a resource mapped to that URL). If you want to LOCK >a URL, you first have to create a resource at that URL to >display the lock. If some other client gets their >lock in before you, that's no different from somebody today >getting their lock-null resource created before you. In either case, >you have to either try your request again at some other URL, >or wait until the other client releases the lock. > >Cheers, >Geoff > >-----Original Message----- >From: Dan Brotsky [mailto:dbrotsky@Adobe.COM] >Sent: Wednesday, June 27, 2001 2:10 AM >To: Tim Ellison >Cc: w3c-dist-auth@w3.org >Subject: RE: Status code for creating lock-null resource > > >I'm definitely in the camp that thinks lock-null resources should go >away in the next revise of 2518, and I very much like the way this >discussion went, which I would summarize as: > >0. we don't talk about "null resources" any more, just unmapped-URIs. > >1. lock-null resources are just "regular resources" that are required >to respond to certain methods in certain ways. > >2. creating a lock-null resource should return 201 > >So far I would say a simple rephrasing might be: > >a. The result of a LOCK call on an unmapped-URI is that the URI gets >mapped to a no-content resource that responds to certain (non-write) >methods with 404 or 405. > >But the problem with this rephrasing is that: > >3. GET on the resource returns 404 or 405 not 204 (as would be >expected for a "regular" no-content resource). [Aside: 404 really >makes no sense here, given that the resource is required to appear as >a member of its parent collection - PROPFIND returns 207 but GET >returns 404? But that's a different issue.] > >4. OPTIONS and other non-write methods return 404 or 405 for no >particular reason. > >5. UNLOCK on the resource returns the URL to an unmapped state. > >Note that restrictions #3 and #4 are unmotivated, as far as I can >tell; the only "special" aspect of this resource (aside from #5) is >that the server really can't know whether it's a collection or not. >[Aside: The DAV:resourcetype property really needs another value in >these cases, such as "indeterminate". But that's another issue.] > >Which brings us to #5: UNLOCK (essentially) deletes the resource. I >think I understand the motivation for this: a client that locks the >URI but then decides not to write it doesn't want to have to do a >delete in order not to leave an empty resource mapped to the URI. >But my problem is that the spec *mandates* this behavior, rather than >leaving up to the server (or allowing the client to request it >specially as part of the UNLOCK). > >Essentially the spec is requiring that a LOCK/UNLOCK combination with >no intervening write operations do *nothing* to a URI or the resource >mapped to it. (This is a mandate that has been picked up in deltaV, >as well.) But while I can understand that servers might want to work >this way, and that clients might want to request this, I can see no >reason to mandate this. > >In fact, my experience with building workflow and document-management >servers leads me to entirely the other conclusion: servers need the >discretion to interpret LOCK as a statement of intent in the >workflow, one that an UNLOCK does not necessarily "undo." In >particular, LOCK is the only way in WebDAV for a client to create a >no-content resource (as opposed to one with content-length 0), and >just because the client doesn't create the content before unlocking >doesn't mean that the client wants the created resource (and live >properties such as its creator) to be expunged from the server. > >As we revise 2518, I think we should give servers much more >discretion about how they handle LOCK/UNLOCK pairs, and possibly we >should give clients a way of indicating in the UNLOCK that "the lock >was a mistake, undo it if you can" (much as deltaV allows undoing a >checkout). If we do so, I think lock-null resources (and their >concomitant problems) can be done away with completely, and LOCK can >simply be seen as creating a no-content resource when applied to >unmapped URIs. Servers who wish to preserve the lock-null kinds of >behavior for those resources are welcome to, and they will still be >in compliance with the spec. > > dan >-- >Daniel Brotsky, Adobe Systems >tel 408-536-4150, pager 877-704-4062 >2-way pager email: -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Wed Jun 27 18:33:06 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02660 for ; Wed, 27 Jun 2001 18:33:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA20073; Wed, 27 Jun 2001 18:32:01 -0400 (EDT) Resent-Date: Wed, 27 Jun 2001 18:32:01 -0400 (EDT) Resent-Message-Id: <200106272232.SAA20073@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 SAA20051 for ; Wed, 27 Jun 2001 18:31:46 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA23548 for ; Wed, 27 Jun 2001 18:31:46 -0400 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 SAA189362; Wed, 27 Jun 2001 18:29:24 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5RMPF8188186; Wed, 27 Jun 2001 18:25:15 -0400 Importance: Normal To: "Dan Brotsky" Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Wed, 27 Jun 2001 18:13:12 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 06/27/2001 06:31:11 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5095 X-Loop: w3c-dist-auth@w3.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. lock-null resources are just "regular resources" that are required to respond to certain methods in certain ways. >> I'd like to suggest that LNR's are *not* regular resources. With one exception that I've noticed, they are just "null resources" that have a lock affecting them. Think about a resource /b/ that has a depth lock and /b/a that is a null resource. Think about how /b/a behaves. It's not a LNR resource, it's just a totally normal "null resource" (or unmapped URL), but it seems to have the same behavior as a LNR. The exact same behavior. Except for one thing... The exception is that we've defined PROPFIND to not give a response for /b/a but we have specified that PROPFIND give a response to a LNR. That's the only exception, right? (This is a genuine question.) This being the case, I'd like to get away from talking about a LNR as a normal resource or an particularly odd type of "null resource". Instead we can say that we are allowed to lock a null resource that has a parent and that PROPFIND has special behavior for a null resource that has a lock rooted on it. If we can talk about something being "odd", we can talk about PROPFIND being odd. << As we revise 2518, I think we should give servers much more discretion about how they handle LOCK/UNLOCK pairs, and possibly we ... >> Given what I've suggested above, I don't think we'd need special behavior controling the creation/destruction of LNR by LOCK/UNLOCK methods since there would be no creation/destruction to control. Anyway... is LNR simply an illusion created by PROPFIND? Do LNR have any other behavior that distinguishes them from locked null resource? J. From w3c-dist-auth-request@w3.org Wed Jun 27 20:03: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 UAA01749 for ; Wed, 27 Jun 2001 20:03:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA05189; Wed, 27 Jun 2001 19:56:09 -0400 (EDT) Resent-Date: Wed, 27 Jun 2001 19:56:09 -0400 (EDT) Resent-Message-Id: <200106272356.TAA05189@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 TAA05169 for ; Wed, 27 Jun 2001 19:55:55 -0400 (EDT) Received: from smtp-relay-1.Adobe.COM (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA31656 for ; Wed, 27 Jun 2001 19:55:55 -0400 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 QAA01999 for ; Wed, 27 Jun 2001 16:58:41 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id QAA06511; Wed, 27 Jun 2001 16:54:57 -0700 (PDT) Received: from [192.168.1.6] ([130.248.184.82]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id GFM53X00.TYV; Wed, 27 Jun 2001 16:55:09 -0700 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: References: Date: Wed, 27 Jun 2001 16:55:40 -0700 To: "Jason Crawford" From: "Dan Brotsky" Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5096 X-Loop: w3c-dist-auth@w3.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 6:13 PM -0400 6/27/01, Jason Crawford wrote: ><< >1. lock-null resources are just "regular resources" that are required >to respond to certain methods in certain ways. >>> >I'd like to suggest that LNR's are *not* regular resources. With one >exception that I've noticed, they are just "null resources" that have >a lock affecting them. Jason, I wasn't suggesting that LNRs, as *currently specified*, are regular resources. I was trying to summarize the back-and-forth between Tim and Jim as concluding that they *should* be regular resources, that is, that LOCK of an unmapped-URI should create a (mostly) standard, no-content resource mapped to that URI. Sorry if this wasn't clear from my message. The reason for the (mostly) qualifier above, by the way, is that the no-content resource created by a LOCK call in this proposal would not start off as a collection but could become a collection if a MKCOL was then done. (That's why I was also suggesting we needed a new value for the DAV:resourcetype property.) Geoff is suggesting something slightly different: that LOCK not even be allowed on unmapped-URIs. This also gets rid of LNRs and has the advantage that you always know whether something is a collection or not. However it doesn't allow users to simultaneously create and LOCK resources for further editing, which bothers me. >Think about a resource /b/ that has a depth lock and /b/a that is a >null resource. Think about how /b/a behaves. It's not a LNR resource, >it's just a totally normal "null resource" (or unmapped URL), but it >seems to have the same behavior as a LNR. The exact same behavior. > >Except for one thing... > >The exception is that we've defined PROPFIND to not give a response >for /b/a yes we have. It gives a 404 (Not Found). >but we have specified that PROPFIND give a response to a >LNR. well, a different response (207). > >That's the only exception, right? (This is a genuine question.) And the answer is no. If you do a PUT on /b/a (in the unmapped case) it will succeed, but if you do a PUT on /b/a (in the LNR case) it will fail with a 423 Locked [or 412 Lock Token not specified as Precondition]. It's important not to forget that the big difference between an LNR and an NR is the L! :^) >This being the case, I'd like to get away from talking about a LNR as a >normal resource or an particularly odd type of "null resource". Instead >we can say that we are allowed to lock a null resource that has a parent >and that PROPFIND has special behavior for a null resource that has a lock >rooted on it. If we can talk about something being "odd", we can talk >about PROPFIND being odd. I think the language about null resources makes these situations seem similar when they're not. That's one of the reasons I like Tim's "unmapped-URI" language much more. IMHO, there is no such thing as a "null resource;" there are only resources (some of which have content and some of which don't). If you want locks to be on resources, which the spec does, then you either have to have LOCK create a resource (my thinking) or you have to forbid LOCKs on URIs that aren't bound to a resource (Geoff's thinking). Of course the other thought in the air is to make locks be on URIs and not resources at all. But even in this case I think you want to disallow locks on unmapped-URIs, because such locks (given the semantics of PROPFIND, which is about resources not URIs) would not be discoverable nor would they be presentable as "resource state". These two outcomes would require a major revamp of the spec. My guess about where we're going to end up is that LOCKs are requested on and attach to the *binding* between a URI and a resource, and that they control that resource regardless of which URI it is accessed through. That would disallow LOCKs on unmapped-URIs, and it would also account for why LOCKs on a particular URI/resource binding are destroyed when that binding is destroyed (such as by a MOVE request). It would also make it easy to say how LOCK and BIND are related (in the deltaV spec). dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Wed Jun 27 23:01: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 XAA07604 for ; Wed, 27 Jun 2001 23:01:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA11035; Wed, 27 Jun 2001 22:54:15 -0400 (EDT) Resent-Date: Wed, 27 Jun 2001 22:54:15 -0400 (EDT) Resent-Message-Id: <200106280254.WAA11035@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 WAA11000 for ; Wed, 27 Jun 2001 22:53:59 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id WAA12107 for ; Wed, 27 Jun 2001 22:53:59 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 27 Jun 2001 23:00:21 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 23:00:21 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103770917@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Wed, 27 Jun 2001 23:00:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5097 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Dan has lots of good stuff in this message that I'll want to follow-up on, but I first wanted to focus on one particular comment: From: Dan Brotsky [mailto:dbrotsky@Adobe.COM] Geoff is suggesting something slightly different: that LOCK not even be allowed on unmapped-URIs. This also gets rid of LNRs and has the advantage that you always know whether something is a collection or not. However it doesn't allow users to simultaneously create and LOCK resources for further editing, which bothers me. Could you expand on why this bothers you? Since (I believe) this is the only thing that you gain with "unmapped URI locks" (UULs, previously known as LNRs :-), it is important to understand why (or whether) this matters enough to warrant the kind of confusion and complexity that UULs bring to the model. Suppose UULs are supported. If you issue a LOCK against an unmapped URI, this may fail because someone already has a lock on that URI. In this case, you either need to wait until that lock is removed (at which time, it is likely there is a resource mapped to that URI, but maybe not), or you need to try again on a different URI. Now suppose UULs are not supported. You can't issue a LOCK against an unmapped URI, so instead, you first create a resource *of the appropriate type* and then try to LOCK that. This LOCK request may fail because someone already has a lock on that URI. In this case, you either need to wait until that lock is removed (at which time, it is likely there is a resource mapped to that URI, but maybe not), or you need to try again on a different URI. Those two cases look very similar (in fact, I copied the text of the first case into the second case, so they should look *really* similar :-). So what do you really gain with UULs? Note: for compatibility with old 2518 servers, we shouldn't say that a LOCK MUST fail on an unmapped URI, but we certainly could amend the protocol to say that it SHOULD fail. Since UULs act so differently on current servers, this is probably the only thing we could say, if we wanted to tell client writers how to achieve interoperability with existing servers. Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Jun 28 02:10:59 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 CAA03783 for ; Thu, 28 Jun 2001 02:10:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA19998; Thu, 28 Jun 2001 01:57:20 -0400 (EDT) Resent-Date: Thu, 28 Jun 2001 01:57:20 -0400 (EDT) Resent-Message-Id: <200106280557.BAA19998@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 BAA19973 for ; Thu, 28 Jun 2001 01:56:50 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA26297 for ; Thu, 28 Jun 2001 01:56:49 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id EE58849B49; Thu, 28 Jun 2001 15:56:06 +1000 (EST) Date: Thu, 28 Jun 2001 15:56:06 +1000 From: Alan Kent To: w3c-dist-auth@w3.org Message-ID: <20010628155606.B16339@io.mds.rmit.edu.au> References: <3906C56A7BD1F54593344C05BD1374B103770917@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103770917@SUS-MA1IT01>; from Clemm, Geoff on Wed, Jun 27, 2001 at 11:00:27PM -0400 Subject: Re: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5098 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Wed, Jun 27, 2001 at 11:00:27PM -0400, Clemm, Geoff wrote: > Now suppose UULs are not supported. You can't issue a LOCK against an > unmapped URI, so instead, you first create a resource *of the > appropriate type* and then try to LOCK that. This LOCK request may > fail because someone already has a lock on that URI. In this case, > you either need to wait until that lock is removed (at which time, it > is likely there is a resource mapped to that URI, but maybe not), or > you need to try again on a different URI. I am having trouble associating what I was going to say exactly with the above, but its a bit of context... I do not have a personal need for the following, but what about the case where an application wants to create a temporary file with a new unique file name. It does a 'LOCK' on a name. If it fails, it tries another unique name. It keeps trying until it succeeds. Without the current LOCK semantics, you would have to do a PUT to create an empty file and then LOCK it. Does PUT have an OVERWRITE Y/N flag? (I dont have the spec handy). If it always overwrites, then there is the potential for a race condition. Personally I would say tough luck. The above seems important in /tmp or C:\temp etc, but not on a WebDAV file system. And there are lots of potentials for race conditions in other parts of WebDAV arn't there? (OK, so I don't actually know of any...) So why worry about one case when it makes things so much more confusing overall? WebDAV would be easier to implement if LOCK didn't have to create these temporary amorphous resources that change their resource type later (or even vanish complete). Alan ps: I like getting rid of the jargon "null resource", and like getting rid of "lock-null" resources too *if possible*. Simplicity is a good thing. If people are not implementing it correctly, there is probably a good reason. From w3c-dist-auth-request@w3.org Thu Jun 28 02:11: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 CAA03810 for ; Thu, 28 Jun 2001 02:11:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA20172; Thu, 28 Jun 2001 02:01:28 -0400 (EDT) Resent-Date: Thu, 28 Jun 2001 02:01:28 -0400 (EDT) Resent-Message-Id: <200106280601.CAA20172@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 CAA20142 for ; Thu, 28 Jun 2001 02:01:07 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA26620 for ; Thu, 28 Jun 2001 02:01:07 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id 0E34A49B49; Thu, 28 Jun 2001 16:00:35 +1000 (EST) Date: Thu, 28 Jun 2001 16:00:35 +1000 From: Alan Kent To: WebDAV Message-ID: <20010628160035.C16339@io.mds.rmit.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Subject: Why HTTP/1.1 in MKCOL requests? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5099 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: No deep questions - just an observation that came up. A presentation was given internally here about WebDAV to raise the awareness of the protocol. Someone asked a question which I did not have a good answer for. Since the extended WebDAV commands are not a part of HTTP 1.1, why do you say MKCOL /foo/bar HTTP/1.1 Why is it not MKCOL /foo/bar WebDAV/1.0 A few people were complaining that WebDAV seemed to be "messing up" the HTTP 1.1 protocol, pretending to be a part of HTTP 1.1, when the extensions are not a part of the HTTP protocol. My answer was "thats what the spec says to do". Alan From w3c-dist-auth-request@w3.org Thu Jun 28 02:27: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 CAA04948 for ; Thu, 28 Jun 2001 02:27:50 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA20983; Thu, 28 Jun 2001 02:26:53 -0400 (EDT) Resent-Date: Thu, 28 Jun 2001 02:26:53 -0400 (EDT) Resent-Message-Id: <200106280626.CAA20983@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 CAA20963 for ; Thu, 28 Jun 2001 02:26:38 -0400 (EDT) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA28429 for ; Thu, 28 Jun 2001 02:26:39 -0400 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f5S6Q3820330 for ; Wed, 27 Jun 2001 23:26:03 -0700 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 f5S6Q2L20247; Wed, 27 Jun 2001 23:26:02 -0700 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f5S6Nos01401; Wed, 27 Jun 2001 23:23:50 -0700 Date: Wed, 27 Jun 2001 23:23:50 -0700 From: "Roy T. Fielding" To: Alan Kent Cc: WebDAV Message-ID: <20010627232350.F1271@waka.ebuilt.net> References: <20010628160035.C16339@io.mds.rmit.edu.au> 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: <20010628160035.C16339@io.mds.rmit.edu.au>; from ajk@mds.rmit.edu.au on Thu, Jun 28, 2001 at 04:00:35PM +1000 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: Why HTTP/1.1 in MKCOL requests? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5100 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > A few people were complaining that WebDAV seemed to be "messing up" > the HTTP 1.1 protocol, pretending to be a part of HTTP 1.1, when the > extensions are not a part of the HTTP protocol. RFC 2518 uses the HTTP/1.1 standard as specified by RFC 2616, which specifically encourages the development of additional methods for this type of functionality. Adding new methods does not change HTTP, for the same reason that adding new executables doesn't change Linux. Cheers, Roy T. Fielding, Chief Scientist, eBuilt, Inc. 2652 McGaw Avenue Irvine, CA 92614-5840 fax:+1.949.609.0001 (fielding@ebuilt.com) Chairman, The Apache Software Foundation (fielding@apache.org) From w3c-dist-auth-request@w3.org Thu Jun 28 03:50:37 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09021 for ; Thu, 28 Jun 2001 03:50:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA23374; Thu, 28 Jun 2001 03:39:01 -0400 (EDT) Resent-Date: Thu, 28 Jun 2001 03:39:01 -0400 (EDT) Resent-Message-Id: <200106280739.DAA23374@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 DAA23335 for ; Thu, 28 Jun 2001 03:38:35 -0400 (EDT) Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA01350 for ; Thu, 28 Jun 2001 03:38:34 -0400 Received: from smtp-relay-1.Adobe.COM by sophia.inria.fr (8.11.1/8.10.0) with ESMTP id f5S7cWs06430 for ; Thu, 28 Jun 2001 09:38:33 +0200 (MET DST) 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 AAA22344 for ; Thu, 28 Jun 2001 00:34:24 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com by inner-relay-1.Adobe.COM (8.8.5) with ESMTP id AAA28107; Thu, 28 Jun 2001 00:30:06 -0700 (PDT) Received: from [192.168.1.6] ([130.248.188.64]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id GFMQ7O00.6NA for ; Thu, 28 Jun 2001 00:31:00 -0700 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103770917@SUS-MA1IT01> References: <3906C56A7BD1F54593344C05BD1374B103770917@SUS-MA1IT01> Date: Thu, 28 Jun 2001 00:30:04 -0700 To: w3c-dist-auth@w3.org From: "Dan Brotsky" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5101 X-Loop: w3c-dist-auth@w3.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 11:00 PM -0400 6/27/01, Clemm, Geoff wrote: >Dan has lots of good stuff in this message that I'll want to >follow-up on, but I first wanted to focus on one particular >comment: > > From: Dan Brotsky [mailto:dbrotsky@Adobe.COM] > > Geoff is suggesting something slightly different: that LOCK not > even be allowed on unmapped-URIs. This also gets rid of LNRs and > has the advantage that you always know whether something is a > collection or not. However it doesn't allow users to > simultaneously create and LOCK resources for further editing, which > bothers me. > >Could you expand on why this bothers you? There are actually three reasons: 1. Because it sets you up for ambiguity and race conditions by breaking a single user-conceptual operation (beginning to edit a new resource) into two protocol operations (PUT and LOCK). A client that wants to create and edit a new resource will go through a conventional sequence such as HEAD (to verify the URL as unmapped), PUT (to create the resource), and LOCK (to reserve the resource for editing). This conflicts not only with itself but with the conventional sequence for editing an existing resource is LOCK / GET (LOCK first to make sure the GET content is the latest content). This gives rise to two canonical problem cases: a. If I'm creating and editing a new resource, and you are editing a resource but specify my name by mistake, then my client has to deal with the unexpected (and meaningless at the user level) case where I successfully create the resource but then can't edit it, and your client has to deal with the unexpected (and meaningless at the user level) case where you open a resource to edit it only to find that it's empty or doesn't contain anything like what I was expecting. b. If we're both trying to create and edit the same (new) resource, and my PUT precedes yours but my LOCK follows yours, then once I've obtained the LOCK I find that the etag on the resource is different than the one I got back from my PUT. This is the canonical client-side warning sign that I'm in a race with someone else, and I have to stop and make sure that I pull down the current content. At that point, unless you and I were using the same "template" resource in our initial PUTs, I've got a real problem. I either have to blow away your edit (which I'm not entitled to do under normal circumstances) or I need to give up my lock. But by then your LOCK has failed, so you've figured out that someone else is creating the resource and you've given up. (I have observed both of these scenarios in existing graphic arts workflows, by the way. There are many workflow systems in use that have exactly this kind of problem.) 2. Because there's no well-defined way for PUT to reliably create a no-content resource, which is the kind I claim you want to be creating when you're creating a new one but don't have content for it yet. Most servers given a PUT of 0 length create a 0-length resource, which is quite a different thing than a no-content one. 3. Because doing a PUT and then a LOCK and then (eventually) another PUT forces you to make *two* updates to the resource rather than one, and the controlling server may not actually want to authorize that. (For example, workflow servers often want to send things off for approval, etc., each time they are updated.) > Since (I believe) this is >the only thing that you gain with "unmapped URI locks" (UULs, >previously known as LNRs :-), it is important to understand why (or >whether) this matters enough to warrant the kind of confusion and >complexity that UULs bring to the model. > >Suppose UULs are supported. If you issue a LOCK against an unmapped >URI, this may fail because someone already has a lock on that URI. In >this case, you either need to wait until that lock is removed (at >which time, it is likely there is a resource mapped to that URI, but >maybe not), or you need to try again on a different URI. Don't get me wrong: I am as opposed to UULs as I am to LNRs! >Now suppose UULs are not supported. You can't issue a LOCK against an >unmapped URI, My proposal is that you *can* do this, but the effect is that a no-content resource is created and bound to that URI. > so instead, you first create a resource *of the >appropriate type* and then try to LOCK that. The big differences between this proposal and yours seem to be: 1. The initial content of the resource (none) is fixed. 2. The resource can be made a collection via MKCOL. 3. There's no chance of race conditions. > This LOCK request may >fail because someone already has a lock on that URI. In this case, >you either need to wait until that lock is removed (at which time, it >is likely there is a resource mapped to that URI, but maybe not), or >you need to try again on a different URI. > >Those two cases look very similar (in fact, I copied the text >of the first case into the second case, so they should look >*really* similar :-). So what do you really gain with UULs? See above. I think we're very close. >Note: for compatibility with old 2518 servers, we shouldn't say that a >LOCK MUST fail on an unmapped URI, but we certainly could amend the >protocol to say that it SHOULD fail. Since UULs act so differently on >current servers, this is probably the only thing we could say, if we >wanted to tell client writers how to achieve interoperability with >existing servers. In my proposal, there is no incompatibility with existing servers, because the LNR they create is a no-content resource (or would be, if you were allowed to do a GET :^), and you can still issue a MKCOL. So let me ask you the converse question: You seem to be worried by the fact that we don't know what kind of resource (collection or not) the new resource is going to be. What's the problem with letting the new resource start out as a no-content non-collection and then be made into a collection? Note that in both of our proposals the same requests are made---either a PUT or a MKCOL and a LOCK. It's just that in my version the LOCK comes first (a la the LOCK / GET sequence that initiates an edit). And in my version the client doesn't have to figure out whether the resource exists before initiating the sequence: all edits (of both existing and new resources) start out with a LOCK / GET, and in the case of the create the LOCK comes back with a 201 which tells the client that the GET would return a 204 (and thus there's no reason to issue it). dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Thu Jun 28 08:55: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 IAA17664 for ; Thu, 28 Jun 2001 08:55:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA05568; Thu, 28 Jun 2001 08:50:56 -0400 (EDT) Resent-Date: Thu, 28 Jun 2001 08:50:56 -0400 (EDT) Resent-Message-Id: <200106281250.IAA05568@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 IAA05544 for ; Thu, 28 Jun 2001 08:50:41 -0400 (EDT) Received: from apollo.eurgw.xerox.com (firewall-user@apollo.ext.eurgw.xerox.com [212.120.143.4]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA28857 for ; Thu, 28 Jun 2001 08:50:21 -0400 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by apollo.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id NAA10937 for ; Thu, 28 Jun 2001 13:47:33 +0100 (BST) Received: from eur.xerox.com (eurdubmg02.eur.xerox.com [13.202.65.254]) by eurodns2.eur.xerox.com (8.9.3/8.9.3) with ESMTP id NAA14756 for ; Thu, 28 Jun 2001 13:50:17 +0100 (BST) Received: from eurgbrbh03.emeacinops.xerox.com (unverified) by eur.xerox.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 28 Jun 2001 13:49:17 +0100 Received: by eurgbrbh03.eur.xerox.com with Internet Mail Service (5.5.2651.58) id <2XAFWMDW>; Thu, 28 Jun 2001 13:49:49 +0100 Received: from [13.202.66.60] (eurdubmg03.eur.xerox.com [13.202.66.60]) by eurgbrbh03.emeacinops.xerox.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id 2XAFWMD3; Thu, 28 Jun 2001 13:49:40 +0100 Received: from gbrwgcbh01.wgc.gbr.xerox.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 28 Jun 2001 13:43:58 +0100 Received: by gbrwgcbh01.wgc.gbr.xerox.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Jun 2001 13:49:33 +0100 Message-ID: <59697CCC6CE3D411B4CD00805FBB77672875D2@gbrwgcms03.wgc.gbr.xerox.com> From: "Hall, Shaun" To: "'Alan Kent'" , w3c-dist-auth@w3.org Date: Thu, 28 Jun 2001 13:49:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5102 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Bits snipped. All IMHO... > -----Original Message----- > From: Alan Kent [mailto:ajk@mds.rmit.edu.au] > Sent: 28 June 2001 06:56 > To: w3c-dist-auth@w3.org > Subject: Re: Status code for creating lock-null resource > > Without the current LOCK semantics, you would have to do a PUT to > create an empty file and then LOCK it. Does PUT have an OVERWRITE Y/N > flag? (I dont have the spec handy). If it always overwrites, then > there is the potential for a race condition. There is no Overwrite with PUT. Unless you use one of the If-* headers, PUT will overwrite the existing resource (assuming permissions etc are okay). This is the kind of thing LOCK is suppose to deal with. > > Personally I would say tough luck. The above seems important in /tmp > or C:\temp etc, but not on a WebDAV file system. And there are lots of > potentials for race conditions in other parts of WebDAV arn't there? > (OK, so I don't actually know of any...). So why worry about one case > when it makes things so much more confusing overall? > > Alan There are lots of conditions and requests that conflict with each other, so it is important. In fact, some servers have "undefined" behaviour. Am I the only person who actually has no real big problem with lock-null resources (LNRs) ? Regards Shaun Hall Xerox Europe From w3c-dist-auth-request@w3.org Thu Jun 28 12:43: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 MAA17022 for ; Thu, 28 Jun 2001 12:43:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA26973; Thu, 28 Jun 2001 12:42:44 -0400 (EDT) Resent-Date: Thu, 28 Jun 2001 12:42:44 -0400 (EDT) Resent-Message-Id: <200106281642.MAA26973@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 MAA26948 for ; Thu, 28 Jun 2001 12:42:18 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA26511 for ; Thu, 28 Jun 2001 12:42:17 -0400 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 MAA455930; Thu, 28 Jun 2001 12:39:25 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5SGZFu170268; Thu, 28 Jun 2001 12:35:16 -0400 Importance: Normal To: "Hall, Shaun" , w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Thu, 28 Jun 2001 12:32:41 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 06/28/2001 12:41:12 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5105 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << Am I the only person who actually has no real big problem with lock-null resources (LNRs) ? >> I have no problem with them as long as we don't pretend they are anything other than a null resource (with a lock rooted on them). They really aren't that strange. It's mostly because we've felt compelled to say that they are a real resource or a quasi-resouce that we've had confusion and angst over the years. From w3c-dist-auth-request@w3.org Thu Jun 28 12:43: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 MAA17052 for ; Thu, 28 Jun 2001 12:43:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA26478; Thu, 28 Jun 2001 12:39:21 -0400 (EDT) Resent-Date: Thu, 28 Jun 2001 12:39:21 -0400 (EDT) Resent-Message-Id: <200106281639.MAA26478@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 MAA26440 for ; Thu, 28 Jun 2001 12:38:55 -0400 (EDT) Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA26087 for ; Thu, 28 Jun 2001 12:38:54 -0400 Received: from [216.36.75.57] (HELO beaver) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8) with SMTP id 1240553; Thu, 28 Jun 2001 09:36:07 -0700 From: "Lisa Dusseault" To: "Alan Kent" , Date: Thu, 28 Jun 2001 09:36:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010628155606.B16339@io.mds.rmit.edu.au> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5103 X-Loop: w3c-dist-auth@w3.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 Alan wrote: > What about the case > where an application wants to create a temporary file with a new unique > file name. It does a 'LOCK' on a name. If it fails, it trinother > unique name. It keeps trying until it succeeds. > > Without the current LOCK semantics, you would have to do a PUT to > create an empty file and then LOCK it. Does PUT have an OVERWRITE Y/N > flag? (I dont have the spec handy). If it always overwrites, then > there is the potential for a race condition. In a sense, PUT does have overwrite semantics. You can use the "If-None-Match: *" header to make sure that there are no entity tags at the URL destination. We might want to mention it so (a) servers know they must support it and (b) clients know they can use it, and what for. RFC2616 does state it quite clearly though (section 14.26): "It is also used to prevent a method (e.g. PUT) from inadvertently modifying an existing resource when the client believes that the resource does not exist." Let's assume the "If-None-Match: *" feature can reliably be used, though I'd want to check that before setting anything in stone. Can we just remove the lock-null feature? Some useful interactions would still be lost: - A client can be the creator of a file which they subsequently lose control of. This is because they would have to create the file with PUT then set permissions, leaving a window where the file is unlocked and some other user can set ACLs before the first user has a chance to prevent. - A client can PUT a file and then find themselves unable to LOCK it if somebody else has locked it. They can't create the body, change properties, or delete it. They may not be able to unlock it. What kind of problems might this present to a user interface client? - Similar scenarios with MKCOL. So let's imagine we could transform lock-null resources into locked empty resources -- the only requirement on the server would now be that the server would allow the creation of an empty resource through use of the LOCK request. With a locked empty resource, it's a regular resource, it appears in listings, and it doesn't magically go away if no PUT request is received before UNLOCK. Would this help us out? A locked empty resource as I described would solve the PUT-control problem, but not the MKCOL problem, unless the server were required to be able to support MKCOL on a locked empty resource. So if I have write and permissions access to a repository where other users have write and permissions access, I could create a directory called "lisa" - and there's a risk that somebody else can change permissions before I have a chance to. The malicious user could lock me out of my own directory. On the other hand, presumably the malicious user could create a directory called "lisa" in the first place and not have to worry about waiting for me to create it. Some servers will solve this problem by assigning special permissions to the creator of a resource, however I don't think we can rely on this being always the case. There are certainly use cases for other permissions models. We would want to think about whether it's valid for a server to grant permissions permission on newly created resources to principals that did not either create the new resource, or own the parent resource. lisa From w3c-dist-auth-request@w3.org Thu Jun 28 12:43: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 MAA17058 for ; Thu, 28 Jun 2001 12:43:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA26513; Thu, 28 Jun 2001 12:39:38 -0400 (EDT) Resent-Date: Thu, 28 Jun 2001 12:39:38 -0400 (EDT) Resent-Message-Id: <200106281639.MAA26513@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 MAA26443 for ; Thu, 28 Jun 2001 12:38:55 -0400 (EDT) Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA26089 for ; Thu, 28 Jun 2001 12:38:55 -0400 Received: from [216.36.75.57] (HELO beaver) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8) with SMTP id 1240559; Thu, 28 Jun 2001 09:36:09 -0700 From: "Lisa Dusseault" To: "Dan Brotsky" , Date: Thu, 28 Jun 2001 09:36:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5104 X-Loop: w3c-dist-auth@w3.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 > b. If we're both trying to create and edit the same (new) resource, > and my PUT precedes yours but my LOCK follows yours, then once I've > obtained the LOCK I find that the etag on the resource is different > than the one I got back from my PUT. This is the canonical I believe this can, and should, be solved with the consistent use of "If-None-Match: *" in the PUT request, whenever a client is trying to create a new resource. > 2. Because there's no well-defined way for PUT to reliably create a > no-content resource, which is the kind I claim you want to be > creating when you're creating a new one but don't have content for it > yet. Most servers given a PUT of 0 length create a 0-length > resource, which is quite a different thing than a no-content one. Can you elaborate on how this is a different thing? It might be just as hard for servers to handle no-content resources (if they currently only handle 0-length resources) as it is to support a lock-null resource. At any rate, I wouldn't support adding a completely new concept (no-content resources) even if we did remove the lock-null concept. lisa From w3c-dist-auth-request@w3.org Thu Jun 28 14:05: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 OAA14092 for ; Thu, 28 Jun 2001 14:05:33 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA02099; Thu, 28 Jun 2001 14:04:06 -0400 (EDT) Resent-Date: Thu, 28 Jun 2001 14:04:06 -0400 (EDT) Resent-Message-Id: <200106281804.OAA02099@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 OAA02043 for ; Thu, 28 Jun 2001 14:03:45 -0400 (EDT) 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 OAA03801 for ; Thu, 28 Jun 2001 14:03:41 -0400 Received: from gmgw01.us.oracle.com (gmgw01.us.oracle.com [130.35.249.115]) by inet-mail3.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5SHxR118178; Thu, 28 Jun 2001 10:59:27 -0700 (PDT) Received: from esedlarlaptop (dhcp-4op7-4op8-east-130-35-171-33.us.oracle.com [130.35.171.33]) by gmgw01.us.oracle.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f5SI39v12092; Thu, 28 Jun 2001 11:03:09 -0700 (PDT) From: "Eric Sedlar" To: "Lisa Dusseault" , "Alan Kent" , Date: Thu, 28 Jun 2001 11:07:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5106 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think the historical view that resulted in LNR's is as follows: * There are valid scenarios where clients want to create a resource and lock atomically, or create a collection and lock atomically * We can't handle this for regular resources since we can't change PUT, although we could solve this for MKCOL My suggestion is built on Lisa's suggestion: * Make LOCK create empty resources (with length 0) that are real resources if the URL is not mapped and a special header is specified (say Create: true, kind of like the O_CREAT flag on open() on Unix) * Make MKCOL take a header specifying that a lock should be granted as well, like Lock: true I've always had a viceral negative reaction to creating gratuitous empty files, but on retrospect I think this comes from working on versioning systems where this would create a useless version that the customer doesn't want. In this case, since a deltaV content creation client would probably do: * Open --> LOCK / Create: true * Save --> PUT followed by VERSION-CONTROL followed by UNLOCK so there is no problem of an extraneous version. --Eric From w3c-dist-auth-request@w3.org Thu Jun 28 14:50:11 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 OAA15478 for ; Thu, 28 Jun 2001 14:50:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA04909; Thu, 28 Jun 2001 14:49:17 -0400 (EDT) Resent-Date: Thu, 28 Jun 2001 14:49:17 -0400 (EDT) Resent-Message-Id: <200106281849.OAA04909@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 OAA04888 for ; Thu, 28 Jun 2001 14:48:56 -0400 (EDT) Received: from smtp-relay-2.Adobe.COM (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA08388 for ; Thu, 28 Jun 2001 14:48:55 -0400 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 LAA12662 for ; Thu, 28 Jun 2001 11:53:48 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id LAA02329; Thu, 28 Jun 2001 11:48:07 -0700 (PDT) Received: from [153.32.159.142] ([153.32.159.142]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id GFNLKK00.L8L; Thu, 28 Jun 2001 11:48:20 -0700 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: References: Date: Thu, 28 Jun 2001 11:36:07 -0700 To: "Lisa Dusseault" From: "Dan Brotsky" Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5107 X-Loop: w3c-dist-auth@w3.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:36 AM -0700 6/28/01, Lisa Dusseault wrote: > > b. If we're both trying to create and edit the same (new) resource, >> and my PUT precedes yours but my LOCK follows yours, then once I've >> obtained the LOCK I find that the etag on the resource is different >> than the one I got back from my PUT. This is the canonical > >I believe this can, and should, be solved with the consistent use of >"If-None-Match: *" in the PUT request, whenever a client is trying to create >a new resource. Good point. (And thanks, I had completely missed this "idiom." Like you, I wonder if servers are good about supporting it.) But in the workflows I described, the user concept is not "intent to create" per se, it's "intent to edit, creating if necessary". From a user point of view, I'm being asked to work on resource "foo," creating it if necessary. I don't want to have to tell my client to do something different in the two cases. I just want to tell it "I want to edit 'foo'; do the right thing." Which, if we allow LOCK to create foo if necessary (as it does currently), is always done by the sequence LOCK / GET (but only if the GET is allowed to succeed on the LOCKED created resource). I actually think (from your next message) that we agree about what should happen. And I actually believe that LNRs can be changed fairly easily to be "empty" rather than "null" resources; all we have to do is remove the method response restrictions AND take away the "auto-delete" on UNLOCK behavior. > > 2. Because there's no well-defined way for PUT to reliably create a >> no-content resource, which is the kind I claim you want to be >> creating when you're creating a new one but don't have content for it >> yet. Most servers given a PUT of 0 length create a 0-length >> resource, which is quite a different thing than a no-content one. > >Can you elaborate on how this is a different thing? A no-content resource is one which returns 204. (By the way, some servers do this for directory resources when "default docs" and "directory listings" are turned off.) The response means "there's a resource here but it has no body (and thus no mime type). A 0-length resource corresponds to a 0-length file in a file system; it has a MIME type but no octets. No-content resources and 0-length resources both show up in listings and both respond to GET. > It might be just as >hard for servers to handle no-content resources (if they currently only >handle 0-length resources) as it is to support a lock-null resource. That's a good point. But I'm not arguing against LNRs cause I think they're hard to implement :^). I don't like their conceptual model, and I think we don't need to introduce them at all. > At any >rate, I wouldn't support adding a completely new concept (no-content >resources) even if we did remove the lock-null concept. No-content resources are not new; they're in HTTP 1.0 and 1.1. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Thu Jun 28 16:03: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 QAA07308 for ; Thu, 28 Jun 2001 16:03:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA08386; Thu, 28 Jun 2001 15:59:16 -0400 (EDT) Resent-Date: Thu, 28 Jun 2001 15:59:16 -0400 (EDT) Resent-Message-Id: <200106281959.PAA08386@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 PAA08314 for ; Thu, 28 Jun 2001 15:58:45 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA15639 for ; Thu, 28 Jun 2001 15:58:45 -0400 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 PAA411024; Thu, 28 Jun 2001 15:56:23 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5SJqEu157872; Thu, 28 Jun 2001 15:52:14 -0400 Importance: Normal To: "Dan Brotsky" Cc: "Lisa Dusseault" , X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jason Crawford" Date: Thu, 28 Jun 2001 15:55:12 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.8 |June 18, 2001) at 06/28/2001 03:58:11 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5108 X-Loop: w3c-dist-auth@w3.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 any > >rate, I wouldn't support adding a completely new concept (no-content > >resources) even if we did remove the lock-null concept. > No-content resources are not new; they're in HTTP 1.0 and 1.1. I agree and to go further, the point isn't that there is no content. We might chose to enhance this later to allow it to have content or to create a type of resource that doesn't even have the concept of content. The point isn't content or no-content. The real point is that a resource is created. From w3c-dist-auth-request@w3.org Thu Jun 28 16:10: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 QAA12145 for ; Thu, 28 Jun 2001 16:10:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA09465; Thu, 28 Jun 2001 16:09:11 -0400 (EDT) Resent-Date: Thu, 28 Jun 2001 16:09:11 -0400 (EDT) Resent-Message-Id: <200106282009.QAA09465@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 QAA09435 for ; Thu, 28 Jun 2001 16:08:54 -0400 (EDT) Received: from smtp-relay-1.Adobe.COM (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA16633 for ; Thu, 28 Jun 2001 16:08:54 -0400 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 NAA00326 for ; Thu, 28 Jun 2001 13:11:42 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com by inner-relay-1.Adobe.COM (8.8.5) with ESMTP id NAA03366; Thu, 28 Jun 2001 13:07:22 -0700 (PDT) Received: from [153.32.159.142] ([153.32.159.142]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id GFNP9S00.5UG; Thu, 28 Jun 2001 13:08:16 -0700 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: References: Date: Thu, 28 Jun 2001 12:58:21 -0700 To: "Lisa Dusseault" From: "Dan Brotsky" Cc: "Alan Kent" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5109 X-Loop: w3c-dist-auth@w3.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:36 AM -0700 6/28/01, Lisa Dusseault wrote: > > >So let's imagine we could transform lock-null resources into locked empty >resources -- the only requirement on the server would now be that the server >would allow the creation of an empty resource through use of the LOCK >request. With a locked empty resource, it's a regular resource, it appears >in listings, and it doesn't magically go away if no PUT request is received >before UNLOCK. Would this help us out? I claim yes. That's exactly what I'm proposing, and where I think Tim and Jim got to in their discussion earlier on this thread. >A locked empty resource as I described would solve the PUT-control problem, >but not the MKCOL problem, unless the server were required to be able to >support MKCOL on a locked empty resource. Which I think is reasonable, but I'm likely to be in the minority about this. > So if I have write and >permissions access to a repository where other users have write and >permissions access, I could create a directory called "lisa" - and there's a >risk that somebody else can change permissions before I have a chance to. >The malicious user could lock me out of my own directory. On the other >hand, presumably the malicious user could create a directory called "lisa" >in the first place and not have to worry about waiting for me to create it. I really don't think malicious users are the problem. It's accidental collisions that are the problem: you want to make directory "lisa" because it's your name at the same time someone else wants to make file "lisa" because it's a picture of her niece Lisa. Accidental collisions are rare but a real pain if the underlying protocol allows races. >Some servers will solve this problem by assigning special permissions to the >creator of a resource, however I don't think we can rely on this being >always the case. There are certainly use cases for other permissions models. >We would want to think about whether it's valid for a server to grant >permissions permission on newly created resources to principals that did not >either create the new resource, or own the parent resource. It's valid for servers to do whatever is appropriate for the application. This gets back to the other example I raised in my message: workflow servers typically want to attribute workflow intent to file operations, so two PUTS are quite different than one, and LOCK / PUT means something quite different than PUT / LOCK. I think that, without requiring servers to support "placeholder" resources of some kind, it's going to be hard to avoid races around LOCKING and creation. I think that's why LNRs were introduced in the first place. I simply think that the notion of placeholder was too restrictive, and the notion of a "placeholder that vanishes" was just ill-conceived. Since HTTP already supports the notion of "placeholders" well with no-content resources, I think we can simply say that LOCKing an unmapped URI puts a locked no-content resource there, and it stays there until someone either says "here's content" with PUT or "actually it's a collection" with MKCOL. If they really made a mistake they can say DELETE. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Thu Jun 28 16:13: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 QAA14208 for ; Thu, 28 Jun 2001 16:13:25 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA09496; Thu, 28 Jun 2001 16:09:26 -0400 (EDT) Resent-Date: Thu, 28 Jun 2001 16:09:26 -0400 (EDT) Resent-Message-Id: <200106282009.QAA09496@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 QAA09434 for ; Thu, 28 Jun 2001 16:08:54 -0400 (EDT) Received: from smtp-relay-2.Adobe.COM (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA16632 for ; Thu, 28 Jun 2001 16:08:54 -0400 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 NAA23554 for ; Thu, 28 Jun 2001 13:13:47 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id NAA03510; Thu, 28 Jun 2001 13:08:06 -0700 (PDT) Received: from [153.32.159.142] ([153.32.159.142]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id GFNP9U00.JA2 for ; Thu, 28 Jun 2001 13:08:18 -0700 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj.corp.adobe.com Message-Id: In-Reply-To: References: Date: Thu, 28 Jun 2001 12:59:37 -0700 To: w3c-dist-auth@w3.org From: "Dan Brotsky" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5110 X-Loop: w3c-dist-auth@w3.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:32 PM -0400 6/28/01, Jason Crawford wrote: ><< >Am I the only person who actually has no real big problem with lock-null >resources (LNRs) ? >>> >I have no problem with them as long as we don't pretend they are anything >other than a null resource (with a lock rooted on them). If you change that to "an empty resource" rather than "a null resource" then I think we agree. It's the notion of "null resources" that 2518 introduced that I think is the most hinky of all. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Thu Jun 28 19:51: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 TAA01285 for ; Thu, 28 Jun 2001 19:51:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA18134; Thu, 28 Jun 2001 19:44:53 -0400 (EDT) Resent-Date: Thu, 28 Jun 2001 19:44:53 -0400 (EDT) Resent-Message-Id: <200106282344.TAA18134@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 TAA18093 for ; Thu, 28 Jun 2001 19:44:38 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA05351 for ; Thu, 28 Jun 2001 19:44:37 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id 1B42B49B49; Fri, 29 Jun 2001 09:44:06 +1000 (EST) Date: Fri, 29 Jun 2001 09:44:05 +1000 From: Alan Kent To: WebDAV Message-ID: <20010629094405.A18194@io.mds.rmit.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Subject: Recommendations for integrating WebDAV and other applications Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5111 X-Loop: w3c-dist-auth@w3.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 was after any recommendations or experience others have had of the best way to integrate WebDAV into an application. In particular, we want to ship a demo application with three distinct functionalities in the one web server: * WebDAV interface to a file system of documents that can be edited * Web based workflow interface for document management (users log on) * Public anonymous web interface to released documents I am thinking at present that the paths in the WebDAV folder are not going to be related to the paths in the public interface. The folder paths can be set up by users to whatever structure they want. The final public application paths are determined by the application logic. So URIs for WebDAV and for the public web interface are not going to be the same. One way to avoid collisions with URLs is to prefix the three different areas with a name http://localhost/webdav/... http://localhost/dms/... http://localhost/public/... The public access URL is not very nice though (people want to just go to http://localhost/), so the URI for / might relocate the user down into /public/... The real question for this list is, is there any reason against requiring client applications to use a base URI of http://localhost/webdav/ instead of http://localhost/ ? Are there any clients that assume WebDAV folders always start from /? Does it create any bad semantics starting from /webdav? The other logical alternative strategy I can see is to mount WebDAV from http://localhost/ and have hidden URIs of /public and /dms where a GET request on / relocates the user to /public/... DMS users can just be told to start at /dms in order to bring up the DMS interface. Is there any *best* thing to do? Or is intensionally left up to developers? Would any clients break if they had to be given http://localhost/webdav/ instead of http://localhost/? Thanks as always Alan From w3c-dist-auth-request@w3.org Thu Jun 28 23:33: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 XAA07341 for ; Thu, 28 Jun 2001 23:33:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA24767; Thu, 28 Jun 2001 23:33:05 -0400 (EDT) Resent-Date: Thu, 28 Jun 2001 23:33:05 -0400 (EDT) Resent-Message-Id: <200106290333.XAA24767@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 XAA24741 for ; Thu, 28 Jun 2001 23:32:54 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id XAA23834 for ; Thu, 28 Jun 2001 23:32:54 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 28 Jun 2001 23:39:11 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 23:39:11 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103770C2D@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Thu, 28 Jun 2001 23:39:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Recommendations for integrating WebDAV and other applications Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5112 X-Loop: w3c-dist-auth@w3.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 can see why you would want the authoring location to be different from the released location, but just for interests sake, can you explain why you would separate the webdav root from the dms root? In any case, I know of no client that requires WebDAV to be enabled at "/". Cheers, Geoff -----Original Message----- From: Alan Kent [mailto:ajk@mds.rmit.edu.au] Sent: Thursday, June 28, 2001 7:44 PM To: WebDAV Subject: Recommendations for integrating WebDAV and other applications I was after any recommendations or experience others have had of the best way to integrate WebDAV into an application. In particular, we want to ship a demo application with three distinct functionalities in the one web server: * WebDAV interface to a file system of documents that can be edited * Web based workflow interface for document management (users log on) * Public anonymous web interface to released documents I am thinking at present that the paths in the WebDAV folder are not going to be related to the paths in the public interface. The folder paths can be set up by users to whatever structure they want. The final public application paths are determined by the application logic. So URIs for WebDAV and for the public web interface are not going to be the same. One way to avoid collisions with URLs is to prefix the three different areas with a name http://localhost/webdav/... http://localhost/dms/... http://localhost/public/... The public access URL is not very nice though (people want to just go to http://localhost/), so the URI for / might relocate the user down into /public/... The real question for this list is, is there any reason against requiring client applications to use a base URI of http://localhost/webdav/ instead of http://localhost/ ? Are there any clients that assume WebDAV folders always start from /? Does it create any bad semantics starting from /webdav? The other logical alternative strategy I can see is to mount WebDAV from http://localhost/ and have hidden URIs of /public and /dms where a GET request on / relocates the user to /public/... DMS users can just be told to start at /dms in order to bring up the DMS interface. Is there any *best* thing to do? Or is intensionally left up to developers? Would any clients break if they had to be given http://localhost/webdav/ instead of http://localhost/? Thanks as always Alan From w3c-dist-auth-request@w3.org Fri Jun 29 02:36: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 CAA22537 for ; Fri, 29 Jun 2001 02:36:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA00754; Fri, 29 Jun 2001 02:35:41 -0400 (EDT) Resent-Date: Fri, 29 Jun 2001 02:35:41 -0400 (EDT) Resent-Message-Id: <200106290635.CAA00754@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 CAA00734 for ; Fri, 29 Jun 2001 02:35:28 -0400 (EDT) Received: from io.mds.rmit.edu.au (io.mds.rmit.edu.au [131.170.70.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA05181 for ; Fri, 29 Jun 2001 02:35:26 -0400 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id 5E7E049B65; Fri, 29 Jun 2001 16:34:54 +1000 (EST) Date: Fri, 29 Jun 2001 16:34:54 +1000 From: Alan Kent To: WebDAV Message-ID: <20010629163454.S18194@io.mds.rmit.edu.au> References: <3906C56A7BD1F54593344C05BD1374B103770C2D@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103770C2D@SUS-MA1IT01>; from Clemm, Geoff on Thu, Jun 28, 2001 at 11:39:21PM -0400 Subject: Re: Recommendations for integrating WebDAV and other applications Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5113 X-Loop: w3c-dist-auth@w3.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, Jun 28, 2001 at 11:39:21PM -0400, Clemm, Geoff wrote: > I can see why you would want the authoring location to be different > from the released location, but just for interests sake, can you > explain why you would separate the webdav root from the dms root? The DMS root I was referring to was the user interface to the DMS application. That is, it comes up with menu bars with commands like 'display worklist'. The URLs are not normal resources - its more like a CGI-bin application with lots of arguments encoded into the URL. So the DMS urls do not relate to resources made available from WebDAV in my particular application. So it seemed good to separate them. Alan From w3c-dist-auth-request@w3.org Fri Jun 29 04:49: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 EAA23384 for ; Fri, 29 Jun 2001 04:49:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA04237; Fri, 29 Jun 2001 04:47:42 -0400 (EDT) Resent-Date: Fri, 29 Jun 2001 04:47:42 -0400 (EDT) Resent-Message-Id: <200106290847.EAA04237@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 EAA04176 for ; Fri, 29 Jun 2001 04:47:16 -0400 (EDT) Received: from aslan.computas.com ([193.71.42.32]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA15766 for ; Fri, 29 Jun 2001 04:47:15 -0400 To: w3c-dist-auth@w3.org From: Steinar Bang Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Jun 2001 10:47:11 +0200 Subject: WebDAV and write access discovery Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5114 X-Loop: w3c-dist-auth@w3.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 have implemented HTTP read and write for a tool (the METIS modelling tool ). The main issue with doing write over HTTP, was determining if a file was read-only, or read/write when loaded. Basically the only way I found, was to set all files loaded over HTTP to be read-only initially, and to provide a toggle command that allows the user to make a file loaded over HTTP be read/write (with warnings that changes made may be lost), and then try to save. If the files being saved are of megabyte size, this is a slow and wasteful approach. So what I hoped to get from WebDAV, was a way to check if the user given by the authentication scheme has write access to a particular file. However, when I read the WebDAV documents I couldn't find anything in the XML format described, that held the information I needed. I figured that this might be because I was too stupid to understand the specification, and I didn't want to embarras myself by asking a question that was obvious to everybody on this mailing list. :-) So I kept quiet and walked away. Recently I've returned to the WebDAV docs, and I've discovered and concluded that the reason I didn't find it, was that it wasn't there to find when I looked...:-) But then my question is: people have been layering webdav over file systems since back in 1998 or thereabouts (mod_dav is a prime example), and people have been running explorer-like tools against WebDAV servers for as long. And the explorer like tools would have need to have knowledge about the stuff that WebDAV ACL provides. So what have they done when it was missing? Using custom properties would give uninteroperable solutions. From w3c-dist-auth-request@w3.org Fri Jun 29 09:31: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 JAA05374 for ; Fri, 29 Jun 2001 09:31:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA16278; Fri, 29 Jun 2001 09:30:35 -0400 (EDT) Resent-Date: Fri, 29 Jun 2001 09:30:35 -0400 (EDT) Resent-Message-Id: <200106291330.JAA16278@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 JAA16230 for ; Fri, 29 Jun 2001 09:30:19 -0400 (EDT) Received: from europa.cox-internet.com (europa-cox.cox-internet.com [208.180.118.40]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA08970 for ; Fri, 29 Jun 2001 09:30:19 -0400 Received: from felix ([207.50.87.45]) by europa.cox-internet.com (InterMail vK.4.02.00.10 201-232-116-110 license dd72657b95c070b1853187e4f5a0d6a7) with ESMTP id <20010629132744.ZTBC1750.europa@felix>; Fri, 29 Jun 2001 08:27:44 -0500 Reply-To: From: "Jason Coward" To: "WebDAV" Cc: "Alan Kent" Date: Fri, 29 Jun 2001 08:30:56 -0500 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal In-Reply-To: <20010629094405.A18194@io.mds.rmit.edu.au> Subject: RE: Recommendations for integrating WebDAV and other applications Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5115 X-Loop: w3c-dist-auth@w3.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 Alan: I have just finished integrating a (custom modified) open source DAV server for use with my company's collaborative portal offerings and would like to offer my experiences and thoughts, as well as pose some additional questions. | In particular, we want to ship a demo application with three distinct | functionalities in the one web server: | | * WebDAV interface to a file system of documents that can be edited | * Web based workflow interface for document management (users log on) | * Public anonymous web interface to released documents | | I am thinking at present that the paths in the WebDAV folder are not | going to be related to the paths in the public interface. The folder | paths can be set up by users to whatever structure they want. | The final public application paths are determined by the application | logic. So URIs for WebDAV and for the public web interface are not | going to be the same. | | One way to avoid collisions with URLs is to prefix the three different | areas with a name | | http://localhost/webdav/... | http://localhost/dms/... | http://localhost/public/... In our implementation, the DAV server is Java servlet-based and to access content via a web server, the URL would actually include two prefixes--one for delimiting the root of the portal web-app, and the other representing the servlet-mapping to the DAV servlet (e.g. http://localhost/portal/dav). IMO, this only increases the flexibility of the solution, allowing multiple portal web-apps per machine and/or multiple dav servlet mappings per web-app. In other words, I could have any number of portal sites available from a single host, each with any number of DAV repositories. BTW, what constitutes a "namespace" in DAV, I'm still not totally clear on this. Would the namespace be the URL prefix (before the DAV resource portion of the URI) without the host (i.e. /portal/dav) or would it be (/dav) or is it something totally different? | The public access URL is not very nice though (people want to just go | to http://localhost/), so the URI for / might relocate the user down | into /public/... We would handle this by having the root URL be an index page that redirects appropriately based on user context (including authentication/authorization credentials, device, language preferences, browser version, etc.). In particular, I might be inclined to forward/redirect the "public" request to "/" to a public collection inside the DAV namespace (proper usage?) that contained BINDings, which are essentially symbolic links to other DAV resources that can maintain properties such as access control permissions, separate from those defined on the target of the link. | The real question for this list is, is there any reason against requiring | client applications to use a base URI of http://localhost/webdav/ | instead of http://localhost/ ? Are there any clients that assume | WebDAV folders always start from /? Does it create any bad semantics | starting from /webdav? | | The other logical alternative strategy I can see is to mount WebDAV from | http://localhost/ and have hidden URIs of /public and /dms where a | GET request on / relocates the user to /public/... DMS users can just | be told to start at /dms in order to bring up the DMS interface. | | Is there any *best* thing to do? Or is intentionally left up to | developers? | Would any clients break if they had to be given http://localhost/webdav/ | instead of http://localhost/? Don't see a best scenario easily here, but I believe standard J2EE-container security mappings could easily manage this type of setup, while still maintaining the flexibility of allowing the situation I described above (multiple namespaces per web-app, per host) to function. I even have an HTTP-based DAV explorer-like interface component that might be mapped to /portal/davclient, which encapsulates all of the access to the DAV server and provides the most-appropriate or preferred access interface based on context. And I'm sure there are similar ways to accomplish the same thing using other paradigms besides J2EE... Thanks, Jason Coward Technical Relationship Manager/Developer Mongoose Technology, Incorporated jason.coward@mongoosetech.com http://www.mongoosetech.com From w3c-dist-auth-request@w3.org Fri Jun 29 09: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 JAA13798 for ; Fri, 29 Jun 2001 09:44:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA17157; Fri, 29 Jun 2001 09:43:55 -0400 (EDT) Resent-Date: Fri, 29 Jun 2001 09:43:55 -0400 (EDT) Resent-Message-Id: <200106291343.JAA17157@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 JAA17137 for ; Fri, 29 Jun 2001 09:43:40 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA10382 for ; Fri, 29 Jun 2001 09:43:40 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Fri, 29 Jun 2001 09:47:59 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 09:47:59 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103770CAC@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Fri, 29 Jun 2001 09:41:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: WebDAV and write access discovery Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5116 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Probably the most general way to handle this is with the Expect header ... that lets the server tell you that the request will fail before you've sent the request body (an ACL violation is only one of the reasons why the request might fail). The main problem with the Expect header is that it is an HTTP/1.1 construct that is not understood by old HTTP/1.0 servers and proxies. But I'd encourage client writers to use the Expect header to optimize this situation (with suitable timeout guards to handle 1.0 servers). This will help motivate everyone to replace their 1.0 servers with 1.1 servers (making things run faster is always a good motivator). Cheers, Geoff -----Original Message----- From: Steinar Bang [mailto:sb@metis.no] Sent: Friday, June 29, 2001 4:47 AM To: w3c-dist-auth@w3.org Subject: WebDAV and write access discovery I have implemented HTTP read and write for a tool (the METIS modelling tool ). The main issue with doing write over HTTP, was determining if a file was read-only, or read/write when loaded. Basically the only way I found, was to set all files loaded over HTTP to be read-only initially, and to provide a toggle command that allows the user to make a file loaded over HTTP be read/write (with warnings that changes made may be lost), and then try to save. If the files being saved are of megabyte size, this is a slow and wasteful approach. So what I hoped to get from WebDAV, was a way to check if the user given by the authentication scheme has write access to a particular file. However, when I read the WebDAV documents I couldn't find anything in the XML format described, that held the information I needed. I figured that this might be because I was too stupid to understand the specification, and I didn't want to embarras myself by asking a question that was obvious to everybody on this mailing list. :-) So I kept quiet and walked away. Recently I've returned to the WebDAV docs, and I've discovered and concluded that the reason I didn't find it, was that it wasn't there to find when I looked...:-) But then my question is: people have been layering webdav over file systems since back in 1998 or thereabouts (mod_dav is a prime example), and people have been running explorer-like tools against WebDAV servers for as long. And the explorer like tools would have need to have knowledge about the stuff that WebDAV ACL provides. So what have they done when it was missing? Using custom properties would give uninteroperable solutions. From w3c-dist-auth-request@w3.org Fri Jun 29 10:55: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 KAA29013 for ; Fri, 29 Jun 2001 10:55:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA25666; Fri, 29 Jun 2001 10:53:07 -0400 (EDT) Resent-Date: Fri, 29 Jun 2001 10:53:07 -0400 (EDT) Resent-Message-Id: <200106291453.KAA25666@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 KAA25633 for ; Fri, 29 Jun 2001 10:52:56 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA18815 for ; Fri, 29 Jun 2001 10:52:56 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Fri, 29 Jun 2001 10:59:11 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 10:59:10 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103770D0B@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Fri, 29 Jun 2001 10:59:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5117 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Dan Brotsky [mailto:dbrotsky@Adobe.COM] But in the workflows I described, the user concept is not "intent to create" per se, it's "intent to edit, creating if necessary". From a user point of view, I'm being asked to work on resource "foo," creating it if necessary. I don't want to have to tell my client to do something different in the two cases. I understand and agree with that, but in general, a user gesture will invoke several client requests (sometimes a very large number). Your client will be doing at least 2 requests for this gesture anyway (i.e. LOCK/GET), so having it do 3 requests (i.e. PUT/LOCK/GET) is not qualitatively different. In somewhat more detail: PUT(URL)/if-does-not-exist LOCK(URL) if (lock-failed) then report-error; break; GET(URL) PROPFIND(URL, appropriate-authoring-properties) Notice that the only difference in this sequence and the one you suggest is the initial "PUT(URL)/if-does-not-exist". That additional request seems to be a relatively minor imposition on the client, compared to the complexity of dealing with the variety of ways that servers end up handling LNRs. I just want to tell it "I want to edit 'foo'; do the right thing." Which, if we allow LOCK to create foo if necessary (as it does currently), is always done by the sequence LOCK / GET (but only if the GET is allowed to succeed on the LOCKED created resource). Yes, I agree that this is a good argument against the current LNR behavior of returning a 404 on a GET. In general, this is a very good argument for why a client can be written more simply if there is a "real" resource that holds the lock, instead of some "null" resource with special behavior. I actually think (from your next message) that we agree about what should happen. And I actually believe that LNRs can be changed fairly easily to be "empty" rather than "null" resources; all we have to do is remove the method response restrictions AND take away the "auto-delete" on UNLOCK behavior. Yes, but if we are going to implicitly create a real resource, I think it is a simpler and more consistent model to just have the client explicitly create the resource. In particular, the "auto PUT with an empty body" doesn't handle the case where you want to create a collection there. That's what motivated the "auto-morph" behavior of a LNR. If the client just creates the kind of resource it wants there (PUT, MKCOL, MKWORKSPACE, whatever), you can do what you need without having to have a special "LNR" that has the ability to morph into another kind of resource (thus requiring special code in MKCOL, MKWORKSPACE, etc.). A no-content resource is one which returns 204. (By the way, some servers do this for directory resources when "default docs" and "directory listings" are turned off.) The response means "there's a resource here but it has no body (and thus no mime type). A 0-length resource corresponds to a 0-length file in a file system; it has a MIME type but no octets. No-content resources and 0-length resources both show up in listings and both respond to GET. A problem with distinguishing no-content resources from 0-length resources is that most repositories have no such distinction, and it is a non-trivial amount of work to layer this distinction on existing repositories. Which means you want to require it only if it really gives you significant benefit. But either the no-content has the auto-morph capability (which means every "create" method has to have a special case for it), or it does not, in which case it does not handle any of the LNR use cases that are collections or other types of resources not created by PUT. > It might be just as >hard for servers to handle no-content resources (if they currently only >handle 0-length resources) as it is to support a lock-null resource. That's a good point. But I'm not arguing against LNRs cause I think they're hard to implement :^). I don't like their conceptual model, and I think we don't need to introduce them at all. I'm somewhat different ... I believe they are a pain to implement, I'm fairly neutral on their conceptual model, but then agree with you on the conclusion, i.e. that we don't need to introduce them at all. > At any >rate, I wouldn't support adding a completely new concept (no-content >resources) even if we did remove the lock-null concept. No-content resources are not new; they're in HTTP 1.0 and 1.1. Yes, but the distinction between a no-content and zero-length resource is made by many repositories, and is not a feature currently required by 2518 servers, so requiring it for locking behavior would be problematic. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Jun 29 10:58: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 KAA00560 for ; Fri, 29 Jun 2001 10:58:31 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA25718; Fri, 29 Jun 2001 10:53:23 -0400 (EDT) Resent-Date: Fri, 29 Jun 2001 10:53:23 -0400 (EDT) Resent-Message-Id: <200106291453.KAA25718@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 KAA25646 for ; Fri, 29 Jun 2001 10:52:58 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA18817 for ; Fri, 29 Jun 2001 10:52:58 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Fri, 29 Jun 2001 10:59:14 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 10:59:13 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B103770D0C@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Fri, 29 Jun 2001 10:59:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5118 X-Loop: w3c-dist-auth@w3.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 only thing that currently separates what Dan and I prefer is the "explicit initial resource creation". So at the risk of being repetitive, I'll try to give a detailed response to Dan's message on this issue. From: Dan Brotsky [mailto:dbrotsky@Adobe.COM] At 11:00 PM -0400 6/27/01, Clemm, Geoff wrote: > From: Dan Brotsky [mailto:dbrotsky@Adobe.COM] > ... it doesn't allow users to > simultaneously create and LOCK resources for further editing, which > bothers me. >Could you expand on why this bothers you? There are actually three reasons: 1. Because it sets you up for ambiguity and race conditions by breaking a single user-conceptual operation (beginning to edit a new resource) into two protocol operations (PUT and LOCK). The conceptual operation is probably "get me the locked content and properties of this resource so I can edit them". This will be at least 3 client requests (LOCK, GET, PROPFIND), so making it be 4 client requests (PUT, LOCK, GET, PROPFIND) is not qualitatively different. A client that wants to create and edit a new resource will go through a conventional sequence such as HEAD (to verify the URL as unmapped), PUT (to create the resource), and LOCK (to reserve the resource for editing). No need for the HEAD/PUT ... just the PUT/If-None-Match:* is sufficient. This conflicts not only with itself but with the conventional sequence for editing an existing resource is LOCK / GET (LOCK first to make sure the GET content is the latest content). I don't see that prefixing the LOCK/GET with a PUT/If-None-Match:* would conflict with anything. This gives rise to two canonical problem cases: a. If I'm creating and editing a new resource, and you are editing a resource but specify my name by mistake, then my client has to deal with the unexpected (and meaningless at the user level) case where I successfully create the resource but then can't edit it, and your client has to deal with the unexpected (and meaningless at the user level) case where you open a resource to edit it only to find that it's empty or doesn't contain anything like what I was expecting. The user does not see any of this. Your client just issues an initial PUT/If-None-Match:*, and then ignores the result (your client doesn't care if it ended up creating an empty resource with this request or not ... it just wants to make sure it can lock that URL). From the user's perspective, it either succeeds, and you have the lock, or it fails because somebody else has that URL locked (and it doesn't really matter to the client that the LOCK by that other client was done weeks ago, or was done a millesecond ago). b. If we're both trying to create and edit the same (new) resource, and my PUT precedes yours but my LOCK follows yours, then once I've obtained the LOCK I find that the etag on the resource is different than the one I got back from my PUT. You don't care at all what the response from the PUT/If-None-Match:* request was. You only care what the response is from the LOCK request. This is the canonical client-side warning sign that I'm in a race with someone else, and I have to stop and make sure that I pull down the current content. No race condition here because you don't pull down the current content until you have the lock. At that point, unless you and I were using the same "template" resource in our initial PUTs, I've got a real problem. I either have to blow away your edit (which I'm not entitled to do under normal circumstances) or I need to give up my lock. You have exactly the same failure case if your lock succeeds and there already was a resource there. It doesn't matter if the resource got there a millisecond ago or a few weeks ago. But by then your LOCK has failed, so you've figured out that someone else is creating the resource and you've given up. You don't care that someone else is creating the resource ... you only whether someone else has that resource locked. 2. Because there's no well-defined way for PUT to reliably create a no-content resource, which is the kind I claim you want to be creating when you're creating a new one but don't have content for it yet. Most servers given a PUT of 0 length create a 0-length resource, which is quite a different thing than a no-content one. If a no-content resource can morph into any kind of resource, then it is difficult to implement (most repositories have no such resource). If it cannot morph into any kind of resource, then I do not see an important reason to distinguish a new no-content resource from a new 0-length resource. 3. Because doing a PUT and then a LOCK and then (eventually) another PUT forces you to make *two* updates to the resource rather than one, and the controlling server may not actually want to authorize that. (For example, workflow servers often want to send things off for approval, etc., each time they are updated.) How can something be sent off for approval unless there is a way for me to store what I want on the server so that it can be approved? So let me ask you the converse question: You seem to be worried by the fact that we don't know what kind of resource (collection or not) the new resource is going to be. What's the problem with letting the new resource start out as a no-content non-collection and then be made into a collection? None of my repositories have a resource that has that behavior. This means that I have to figure out a way to simulate such a resource, and have to make sure that the locking semantics is satisfied by all the other protocols that I currently implement on my repository. It is very likely that we would make the same choice made by most servers today wrt LNR's, namely simply be non-compliant with the protocol unless a compelling use case motivated us making this fairly major effort. Note that in both of our proposals the same requests are made---either a PUT or a MKCOL and a LOCK. It's just that in my version the LOCK comes first (a la the LOCK / GET sequence that initiates an edit). And in my version the client doesn't have to figure out whether the resource exists before initiating the sequence: all edits (of both existing and new resources) start out with a LOCK / GET, and in the case of the create the LOCK comes back with a 201 which tells the client that the GET would return a 204 (and thus there's no reason to issue it). I agree that your proposal would allow the client to omit the initial PUT/If-None-Match:*, but adding that call in our clients is trivial compared to the cost of implementing resources that are locked but can morph to any resource type when first updated. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Jun 29 13:58: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 NAA20986 for ; Fri, 29 Jun 2001 13:58:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA12422; Fri, 29 Jun 2001 13:55:25 -0400 (EDT) Resent-Date: Fri, 29 Jun 2001 13:55:25 -0400 (EDT) Resent-Message-Id: <200106291755.NAA12422@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 NAA12398 for ; Fri, 29 Jun 2001 13:55:09 -0400 (EDT) Received: from sus-ma1it00.rational.com (ext-37015.rational.com [192.229.37.15]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA10535 for ; Fri, 29 Jun 2001 13:55:09 -0400 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Fri, 29 Jun 2001 14:01:22 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 14:01:22 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E24F8@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Fri, 29 Jun 2001 14:01:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Recommendations for integrating WebDAV and other applications Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5119 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Jason Coward [mailto:jason.coward@mongoosetech.com] BTW, what constitutes a "namespace" in DAV, I'm still not totally clear on this. Would the namespace be the URL prefix (before the DAV resource portion of the URI) without the host (i.e. /portal/dav) or would it be (/dav) or is it something totally different? A "namespace" in DAV is just an HTTP namespace, i.e. a hierarchical namespace where "/" delimits segments of the namespace (see Section 5.1 of RFC 2518). Perhaps you are thinking of what DAV calls a "consistent" namespace? A consistent namespace is one where every resource is a member of the collection that contains it, or as section 5.1 states: "for every URL in the HTTP hierarchy there exists a collection that contains that URL as an internal member". (Now we all know that the internal members of a collection are resources, and not URLs, but let's not go there right now :-). | The public access URL is not very nice though (people want to just go | to http://localhost/), so the URI for / might relocate the user down | into /public/... We would handle this by having the root URL be an index page that redirects appropriately based on user context (including authentication/authorization credentials, device, language preferences, browser version, etc.). Note though that this might make it challenging to support interoperable locking semantics, since locks are URL based. If the redirecting is always to the same place while the client holds the lock token (which is likely to be the case), it probably won't be bad in practice. In particular, I might be inclined to forward/redirect the "public" request to "/" to a public collection inside the DAV namespace (proper usage?) that contained BINDings, which are essentially symbolic links to other DAV resources that can maintain properties such as access control permissions, separate from those defined on the target of the link. I assume by BINDings, you are referring to what is described in the BIND protocol? If so, the result of a BIND call is like a Unix hard link, not like a symbolic link, because a BIND call does not create a new resource, and does not maintain properties, such as access control permissions, that are separate from those defined on the target of the binding. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Jun 29 14:51: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 OAA22817 for ; Fri, 29 Jun 2001 14:51:50 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA15901; Fri, 29 Jun 2001 14:51:08 -0400 (EDT) Resent-Date: Fri, 29 Jun 2001 14:51:08 -0400 (EDT) Resent-Message-Id: <200106291851.OAA15901@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 OAA15878 for ; Fri, 29 Jun 2001 14:50:44 -0400 (EDT) Received: from shell.rawbw.com (root@shell.rawbw.com [198.144.192.42]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA17310 for ; Fri, 29 Jun 2001 14:50:44 -0400 Received: from beaver ([198.144.203.248]) by shell.rawbw.com (8.11.1/8.11.1) with SMTP id f5TIoW879602; Fri, 29 Jun 2001 11:50:33 -0700 (PDT) From: "Lisa Dusseault" To: "Dan Brotsky" Cc: Date: Fri, 29 Jun 2001 11:48:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: RE: Status code for creating lock-null resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5120 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I think we can simply > say that LOCKing an unmapped URI puts a locked no-content resource > there, and it stays there until someone either says "here's content" > with PUT or "actually it's a collection" with MKCOL. If they really > made a mistake they can say DELETE. I'd point out that in many systems, DELETE privilege is separate from create(write) privilege. UserA, creating a resource in a folder "owned" by UserB, may well end up creating a resource that UserA cannot delete (perhaps UserB can). Thus they can't necessarily do cleanup. This is a problem with any write operation that doesn't turn out the way the user expects so I'd be happy if that problem was not solved at all, particularly through a special case "disappearing" resource. lisa From w3c-dist-auth-request@w3.org Sat Jun 30 17:03:41 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 RAA25588 for ; Sat, 30 Jun 2001 17:03:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA25536; Sat, 30 Jun 2001 14:55:46 -0400 (EDT) Resent-Date: Sat, 30 Jun 2001 14:55:46 -0400 (EDT) Resent-Message-Id: <200106301855.OAA25536@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 OAA25254 for ; Sat, 30 Jun 2001 14:55:04 -0400 (EDT) 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 OAA03201 for ; Sat, 30 Jun 2001 14:55:04 -0400 Received: (qmail 15816 invoked by uid 0); 30 Jun 2001 18:54:53 -0000 Received: from pd950c2e9.dip.t-dialin.net (HELO lisa) (217.80.194.233) by mail.gmx.net (mp002-rz3) with SMTP; 30 Jun 2001 18:54:53 -0000 From: "Julian Reschke" To: "Dan Brotsky" , "WebDAV Working Group" Date: Sat, 30 Jun 2001 20:54:51 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-reply-to: Importance: Normal Subject: RE: Proposal for marshalling property type information Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5121 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dan Brotsky > Sent: Monday, June 25, 2001 9:24 PM > To: WebDAV Working Group > Subject: RE: Proposal for marshalling property type information > > > I also like Julian's proposal and would be glad to see it > incorporated into 2518. But there are a few questions related to > live properties that I'm hoping Julian and others would comment on: > > 1. I work on a number of servers that have specialized live > ("computed" in the deltaV sense) properties for workflow tracking. > It seems that we could use the extended PROPFIND to indicate to > clients the datatype of those properties, but Julian only shows an Correct. > example where the client has indicated the datatype. Were live > properties expected to obey the same extension rule? If so we might > want to clarify this and add an example. Good idea. Which example should I take? Maybe som property from the deltaV spec? > 2. Some of my servers implement "type-restricted" live properties > which are essentially dead properties whose values are restricted to > a certain datatype. These servers will reject PROPPATCH requests > that use the wrong datatype whether or not the client has declared a > datatype in the PROPPATCH. Julian's proposal shows an example of a > 422 response when the PROPPATCH-declared datatype doesn't match the > datatype of the value; I would also like to use such a response when > the value's datatype doesn't match the PROPFIND-shown (and enforced) > datatype. How does this strike people? I think this would make sense. Do we need clients to be able to distinguish between both error conditions?