From w3c-dist-auth-request@w3.org Thu Nov 1 21:00:50 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 VAA06114 for ; Thu, 1 Nov 2001 21:00:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA02326; Thu, 1 Nov 2001 20:56:53 -0500 (EST) Resent-Date: Thu, 1 Nov 2001 20:56:53 -0500 (EST) Resent-Message-Id: <200111020156.UAA02326@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA02302 for ; Thu, 1 Nov 2001 20:56:39 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA04058 for ; Thu, 1 Nov 2001 20:56:38 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id RAA16171 for ; Thu, 1 Nov 2001 17:59:21 -0800 (PST) From: "Jim Whitehead" To: Date: Thu, 1 Nov 2001 17:52:37 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Subject: Resolving Digest authentication issue Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5523 X-Loop: w3c-dist-auth@w3.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 pointed out to me that we never resolved the Digest authentication issue, so let me take a stab at it. If you quibble with the wording below, don't just say you don't like it -- suggest some alternate wording. Dylan Barrel [1] and Alan Kent [2] describe the issues with supporting Digest authentication on the server, and their contention that support for Digest is unacceptable: [1] http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0062.html [2] http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0087.html I clarified the meaning of "supports Digest authentication" in [3]: [3] http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0073.html I think Matt Timmerman's post [4] has the start of a solution: [4] http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0080.html Thus, I propose the following authentication requirements: * Basic MUST NOT be used unless the connection is secure. Secure is defined to be TLS over the Internet, a physically secure network, or a network behind a well-administered firewall. Client requirements: MUST support Basic, SSL/TLS support is STRONGLY RECOMMENDED Server requirements: SHOULD support Basic, SSL/TLS support is STRONGLY RECOMMENDED * Digest SHOULD be used when the connection is insecure, such as a non-TLS connection over the Internet. Client requirements: MUST support Digest Server requirements: SHOULD support Digest, but it is acceptable for Digest authentication to be disabled by default. It SHOULD be possible for an administrator to configure a server to use Digest. * Additional authentication schemes beyond Basic and Digest MAY be supported, whether or not described in an IETF specification. Implementors should be aware that use of other authentication schemes guarantees some level of non-interoperation of that authentication scheme, since all WebDAV clients and servers cannot be expected to support that authentication scheme. So, for example, it's OK for people to support NTLM. * Finally, to guarantee some level of authentication will be possible: a server MUST at minimum support either Basic OR Digest. A server SHOULD support Basic AND Digest. Note that the terms MUST and SHOULD are being used as defined in RFC 2119: 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. For example, I would say that Dylan and Matt have carefully weighed the implications of Digest support, and so if they decided not to support Digest under the language above, this would meet the letter and the spirit of the proposed language. Comments? - Jim From w3c-dist-auth-request@w3.org Thu Nov 1 21:12: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 VAA06433 for ; Thu, 1 Nov 2001 21:12:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA02448; Thu, 1 Nov 2001 20:57:50 -0500 (EST) Resent-Date: Thu, 1 Nov 2001 20:57:50 -0500 (EST) Resent-Message-Id: <200111020157.UAA02448@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA02420 for ; Thu, 1 Nov 2001 20:57:36 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA04114 for ; Thu, 1 Nov 2001 20:57:36 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id SAA16359; Thu, 1 Nov 2001 18:00:18 -0800 (PST) From: "Jim Whitehead" To: "Dylan Barrell" , "WebDAV" Date: Thu, 1 Nov 2001 17:53:34 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 In-Reply-To: Importance: Normal Subject: RE: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5524 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > In order to frame this discussion of what we need to do we need > to agree on the requirements. Sure. > @Jim - how to we proceed on this type of activity? Someone should post a set of requirements to get discussion going. - Jim From w3c-dist-auth-request@w3.org Thu Nov 1 22:00: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 WAA08048 for ; Thu, 1 Nov 2001 22:00:14 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA04189; Thu, 1 Nov 2001 21:54:01 -0500 (EST) Resent-Date: Thu, 1 Nov 2001 21:54:01 -0500 (EST) Resent-Message-Id: <200111020254.VAA04189@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA04160 for ; Thu, 1 Nov 2001 21:53:46 -0500 (EST) 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 VAA08586 for ; Thu, 1 Nov 2001 21:53:34 -0500 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id ADD2949B67; Fri, 2 Nov 2001 13:52:54 +1100 (EST) Date: Fri, 2 Nov 2001 13:52:54 +1100 From: Alan Kent To: w3c-dist-auth@w3.org Message-ID: <20011102135254.G7312@io.mds.rmit.edu.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Jim Whitehead on Thu, Nov 01, 2001 at 05:52:37PM -0800 Subject: Re: Resolving Digest authentication issue Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5525 X-Loop: w3c-dist-auth@w3.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, Nov 01, 2001 at 05:52:37PM -0800, Jim Whitehead wrote: > * Basic MUST NOT be used unless the connection is secure. Secure is defined > to be TLS over the Internet, a physically secure network, or a network > behind a well-administered firewall. > > Client requirements: MUST support Basic, SSL/TLS support is STRONGLY > RECOMMENDED > Server requirements: SHOULD support Basic, SSL/TLS support is STRONGLY > RECOMMENDED > > * Digest SHOULD be used when the connection is insecure, such as a non-TLS > connection over the Internet. > > Client requirements: MUST support Digest > Server requirements: SHOULD support Digest, but it is acceptable for Digest > authentication to be disabled by default. It SHOULD be possible for an > administrator to configure a server to use Digest. > > * Additional authentication schemes beyond Basic and Digest MAY be > supported, whether or not described in an IETF specification. Implementors > should be aware that use of other authentication schemes guarantees some > level of non-interoperation of that authentication scheme, since all WebDAV > clients and servers cannot be expected to support that authentication > scheme. > > * Finally, to guarantee some level of authentication will be possible: a > server MUST at minimum support either Basic OR Digest. A server SHOULD > support Basic AND Digest. ... > Comments? > > - Jim Sounds good to me. Alan From w3c-dist-auth-request@w3.org Fri Nov 2 05:32: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 FAA28942 for ; Fri, 2 Nov 2001 05:32:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA13321; Fri, 2 Nov 2001 05:23:28 -0500 (EST) Resent-Date: Fri, 2 Nov 2001 05:23:28 -0500 (EST) Resent-Message-Id: <200111021023.FAA13321@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA13292 for ; Fri, 2 Nov 2001 05:23:14 -0500 (EST) 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 FAA05979 for ; Fri, 2 Nov 2001 05:23:14 -0500 Received: from apu [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Fri, 02 Nov 2001 11:23:30 +0100 From: "Stefan Eissing" To: "Jim Whitehead" , Date: Fri, 2 Nov 2001 11:24:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: RE: Resolving Digest authentication issue Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5526 X-Loop: w3c-dist-auth@w3.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 Fine with me. //Stefan > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Friday, November 02, 2001 2:53 AM > To: w3c-dist-auth@w3.org > Subject: Resolving Digest authentication issue > > > > Jason Crawford pointed out to me that we never resolved the Digest > authentication issue, so let me take a stab at it. If you quibble with the > wording below, don't just say you don't like it -- suggest some alternate > wording. > > Dylan Barrel [1] and Alan Kent [2] describe the issues with supporting > Digest authentication on the server, and their contention that support for > Digest is unacceptable: > > [1] http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0062.html > [2] http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0087.html > > I clarified the meaning of "supports Digest authentication" in [3]: > > [3] http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0073.html > > I think Matt Timmerman's post [4] has the start of a solution: > > [4] http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0080.html > > Thus, I propose the following authentication requirements: > > * Basic MUST NOT be used unless the connection is secure. Secure > is defined > to be TLS over the Internet, a physically secure network, or a network > behind a well-administered firewall. > > Client requirements: MUST support Basic, SSL/TLS support is STRONGLY > RECOMMENDED > Server requirements: SHOULD support Basic, SSL/TLS support is STRONGLY > RECOMMENDED > > * Digest SHOULD be used when the connection is insecure, such as a non-TLS > connection over the Internet. > > Client requirements: MUST support Digest > Server requirements: SHOULD support Digest, but it is acceptable > for Digest > authentication to be disabled by default. It SHOULD be possible for an > administrator to configure a server to use Digest. > > * Additional authentication schemes beyond Basic and Digest MAY be > supported, whether or not described in an IETF specification. Implementors > should be aware that use of other authentication schemes guarantees some > level of non-interoperation of that authentication scheme, since > all WebDAV > clients and servers cannot be expected to support that authentication > scheme. > > So, for example, it's OK for people to support NTLM. > > * Finally, to guarantee some level of authentication will be possible: a > server MUST at minimum support either Basic OR Digest. A server SHOULD > support Basic AND Digest. > > Note that the terms MUST and SHOULD are being used as defined in RFC 2119: > > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the > definition is an absolute requirement of the specification. > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > For example, I would say that Dylan and Matt have carefully weighed the > implications of Digest support, and so if they decided not to > support Digest > under the language above, this would meet the letter and the spirit of the > proposed language. > > Comments? > > - Jim > > > From w3c-dist-auth-request@w3.org Fri Nov 2 09:03: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 JAA04481 for ; Fri, 2 Nov 2001 09:03:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA20273; Fri, 2 Nov 2001 09:01:11 -0500 (EST) Resent-Date: Fri, 2 Nov 2001 09:01:11 -0500 (EST) Resent-Message-Id: <200111021401.JAA20273@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA20240 for ; Fri, 2 Nov 2001 09:01:01 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA23707 for ; Fri, 2 Nov 2001 09:01:01 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA420478; Fri, 2 Nov 2001 08:57:56 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id fA2E0Sn118264; Fri, 2 Nov 2001 09:00:28 -0500 To: "Jim Whitehead" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Fri, 2 Nov 2001 08:49:04 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V509_10042001 |October 4, 2001) at 11/02/2001 09:00:28 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Resolving Digest authentication issue Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5527 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Sounds good to me. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Nov 2 10:35:52 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 KAA08072 for ; Fri, 2 Nov 2001 10:35:52 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA26834; Fri, 2 Nov 2001 10:33:53 -0500 (EST) Resent-Date: Fri, 2 Nov 2001 10:33:53 -0500 (EST) Resent-Message-Id: <200111021533.KAA26834@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA26810 for ; Fri, 2 Nov 2001 10:33:47 -0500 (EST) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA01806 for ; Fri, 2 Nov 2001 10:33:47 -0500 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id KAA18562; Fri, 2 Nov 2001 10:33:10 -0500 Received: from 022.dhcp2.liv.opentext.com(172.17.2.22) by krusty.wl.opentext.com via smap (V2.1) id xmaa18540; Fri, 2 Nov 01 10:33:06 -0500 From: "Dylan Barrell" To: "Alan Kent" , Date: Fri, 2 Nov 2001 10:32:29 -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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20011102135254.G7312@io.mds.rmit.edu.au> Subject: RE: Resolving Digest authentication issue Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5528 X-Loop: w3c-dist-auth@w3.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 Sounds good to me too... --Dylan > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Alan Kent > Sent: Thursday, November 01, 2001 9:53 PM > To: w3c-dist-auth@w3.org > Subject: Re: Resolving Digest authentication issue > > > On Thu, Nov 01, 2001 at 05:52:37PM -0800, Jim Whitehead wrote: > > * Basic MUST NOT be used unless the connection is secure. > Secure is defined > > to be TLS over the Internet, a physically secure network, or a network > > behind a well-administered firewall. > > > > Client requirements: MUST support Basic, SSL/TLS support is STRONGLY > > RECOMMENDED > > Server requirements: SHOULD support Basic, SSL/TLS support is STRONGLY > > RECOMMENDED > > > > * Digest SHOULD be used when the connection is insecure, such > as a non-TLS > > connection over the Internet. > > > > Client requirements: MUST support Digest > > Server requirements: SHOULD support Digest, but it is > acceptable for Digest > > authentication to be disabled by default. It SHOULD be possible for an > > administrator to configure a server to use Digest. > > > > * Additional authentication schemes beyond Basic and Digest MAY be > > supported, whether or not described in an IETF specification. > Implementors > > should be aware that use of other authentication schemes guarantees some > > level of non-interoperation of that authentication scheme, > since all WebDAV > > clients and servers cannot be expected to support that authentication > > scheme. > > > > * Finally, to guarantee some level of authentication will be possible: a > > server MUST at minimum support either Basic OR Digest. A server SHOULD > > support Basic AND Digest. > ... > > Comments? > > > > - Jim > > Sounds good to me. > Alan From w3c-dist-auth-request@w3.org Fri Nov 2 11:41:17 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 LAA10849 for ; Fri, 2 Nov 2001 11:41:17 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA01196; Fri, 2 Nov 2001 11:39:20 -0500 (EST) Resent-Date: Fri, 2 Nov 2001 11:39:20 -0500 (EST) Resent-Message-Id: <200111021639.LAA01196@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA01172 for ; Fri, 2 Nov 2001 11:39:14 -0500 (EST) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA09246 for ; Fri, 2 Nov 2001 11:39:14 -0500 Received: from mt2k (212.dhcp.ott.opentext.com [192.168.130.212]) by opentext.com (8.9.3/8.9.3) with SMTP id LAA12267; Fri, 2 Nov 2001 11:38:11 -0500 Reply-To: From: "Matt Timmermans" To: "'Jim Whitehead'" , Date: Fri, 2 Nov 2001 11:38:08 -0500 Message-ID: <000b01c163bc$c1a6a550$d482a8c0@mt2k> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Subject: RE: Resolving Digest authentication issue Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5529 X-Loop: w3c-dist-auth@w3.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 Jim Whitehead > Sent: Thursday, November 01, 2001 8:53 PM > To: w3c-dist-auth@w3.org > Subject: Resolving Digest authentication issue > > > > Jason Crawford pointed out to me that we never resolved the Digest > authentication issue, so let me take a stab at it. If you > quibble with the > wording below, don't just say you don't like it -- suggest > some alternate > wording. > > Dylan Barrel [1] and Alan Kent [2] describe the issues with supporting > Digest authentication on the server, and their contention > that support for > Digest is unacceptable: > > [1] > http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0062.html > [2] > http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0087.html > > I clarified the meaning of "supports Digest authentication" in [3]: > > [3] > http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0073.html > > I think Matt Timmerman's post [4] has the start of a solution: > > [4] > http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0080.html > > Thus, I propose the following authentication requirements: > > * Basic MUST NOT be used unless the connection is secure. > Secure is defined > to be TLS over the Internet, a physically secure network, or a network > behind a well-administered firewall. > > Client requirements: MUST support Basic, SSL/TLS support is STRONGLY > RECOMMENDED > Server requirements: SHOULD support Basic, SSL/TLS support is STRONGLY > RECOMMENDED > > * Digest SHOULD be used when the connection is insecure, such > as a non-TLS > connection over the Internet. > > Client requirements: MUST support Digest > Server requirements: SHOULD support Digest, but it is > acceptable for Digest > authentication to be disabled by default. It SHOULD be possible for an > administrator to configure a server to use Digest. > > * Additional authentication schemes beyond Basic and Digest MAY be > supported, whether or not described in an IETF specification. > Implementors > should be aware that use of other authentication schemes > guarantees some > level of non-interoperation of that authentication scheme, > since all WebDAV > clients and servers cannot be expected to support that authentication > scheme. > > So, for example, it's OK for people to support NTLM. > > * Finally, to guarantee some level of authentication will be > possible: a > server MUST at minimum support either Basic OR Digest. A server SHOULD > support Basic AND Digest. > > Note that the terms MUST and SHOULD are being used as defined > in RFC 2119: > > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the > definition is an absolute requirement of the specification. > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > For example, I would say that Dylan and Matt have carefully > weighed the > implications of Digest support, and so if they decided not to > support Digest > under the language above, this would meet the letter and the > spirit of the > proposed language. > > Comments? > > - Jim From w3c-dist-auth-request@w3.org Fri Nov 2 11:47:01 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 LAA11152 for ; Fri, 2 Nov 2001 11:47:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA01814; Fri, 2 Nov 2001 11:45:11 -0500 (EST) Resent-Date: Fri, 2 Nov 2001 11:45:11 -0500 (EST) Resent-Message-Id: <200111021645.LAA01814@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA01794 for ; Fri, 2 Nov 2001 11:45:07 -0500 (EST) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA10082 for ; Fri, 2 Nov 2001 11:45:06 -0500 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id fA2Ghkr18308 for ; Fri, 2 Nov 2001 08:43:46 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id fA2GijS04142 for ; Fri, 2 Nov 2001 08:44:45 -0800 (PST) Received: from larrypad ([130.248.188.128]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with SMTP id GM6MI600.K5S; Fri, 2 Nov 2001 08:44:30 -0800 From: "Larry Masinter" To: "Jim Whitehead" Cc: Date: Fri, 2 Nov 2001 08:43:54 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Subject: RE: Resolving Digest authentication issue Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5530 X-Loop: w3c-dist-auth@w3.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 > Thus, I propose the following authentication requirements: > > * Basic MUST NOT be used unless the connection is secure. Secure is defined > to be TLS over the Internet, a physically secure network, or a network > behind a well-administered firewall. In most IETF circles, it is believed that "well-administered firewall" is a fleeting circumstance: you might have one today, but it's unlikely to remain that way for long. It is also believed that the only "physically secure network" is one that you make with wirecutters -- snipping all the cables, and that the specifications for things appropriate for those networks aren't the domain of the IETF. That's why, in general, no IETF standards-track document can assume such things. (If you want to deploy a system that makes those assumptions, that's fine, you just can't say that there's an IETF standard that it's compliant with). So I think the acceptable choices (as far as IETF goes) are: a) clients and servers MUST support Digest (what we have now) b) clients MUST support BOTH Digest and basic-with-SSL/TLS servers MUST support one or the other (or both) c) clients MUST support one or the other (or both) servers MUST support both Digest and basic-with-SSL/TLS (since it is the server implementors squawking about Digest, I don't think this will fly) d) There are two standards: WebDAV-with-digest WebDAV-with-SSL/TLS An implementation (client or server) supports either or both. The two protocols are not interoperable, of course, so you should be careful to say which you have. In all of these cases, you can support other authentication mechanisms too, but it doesn't guarantee interoperability. I don't have a preference for what the standard should say, except that I believe that it's important that users should be able to tell whether a client will interoperate with a server without having to do some kind of protocol analysis to see which options each supports. From w3c-dist-auth-request@w3.org Fri Nov 2 12:07: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 MAA11841 for ; Fri, 2 Nov 2001 12:07:23 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA03768; Fri, 2 Nov 2001 12:05:47 -0500 (EST) Resent-Date: Fri, 2 Nov 2001 12:05:47 -0500 (EST) Resent-Message-Id: <200111021705.MAA03768@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA03736 for ; Fri, 2 Nov 2001 12:05:40 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37184.rational.com [192.229.37.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA12698 for ; Fri, 2 Nov 2001 12:05:40 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Fri, 02 Nov 2001 12:05:08 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <4D31RAC9>; Fri, 2 Nov 2001 12:05:08 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AD47@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Fri, 2 Nov 2001 12:05:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Resolving Digest authentication issue Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5531 X-Loop: w3c-dist-auth@w3.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 Larry. The statement made in the protocol should just be a simple "A WebDAV server MUST support xxx". Since an argument has been made that "A WebDAV server MUST support digest" is not acceptable, the only choice I see is option (c), namely: "A WebDAV server MUST support either Digest or Basic-with-SSL/TLS". The fact that an interoperable client must support both Digest and Basic-with-SSL/TLS follows from this statement about the server, and therefore is redundant. All that additional language about when to use Digest vs Basic is standard security info just obscures the basic interoperability issue, and should occur in the authentication protocol definitions, not in the WebDAV spec. Cheers, Geoff -----Original Message----- From: Larry Masinter [mailto:LMM@acm.org] Sent: Friday, November 02, 2001 11:44 AM To: Jim Whitehead Cc: w3c-dist-auth@w3.org Subject: RE: Resolving Digest authentication issue > Thus, I propose the following authentication requirements: > > * Basic MUST NOT be used unless the connection is secure. Secure is defined > to be TLS over the Internet, a physically secure network, or a network > behind a well-administered firewall. In most IETF circles, it is believed that "well-administered firewall" is a fleeting circumstance: you might have one today, but it's unlikely to remain that way for long. It is also believed that the only "physically secure network" is one that you make with wirecutters -- snipping all the cables, and that the specifications for things appropriate for those networks aren't the domain of the IETF. That's why, in general, no IETF standards-track document can assume such things. (If you want to deploy a system that makes those assumptions, that's fine, you just can't say that there's an IETF standard that it's compliant with). So I think the acceptable choices (as far as IETF goes) are: a) clients and servers MUST support Digest (what we have now) b) clients MUST support BOTH Digest and basic-with-SSL/TLS servers MUST support one or the other (or both) c) clients MUST support one or the other (or both) servers MUST support both Digest and basic-with-SSL/TLS (since it is the server implementors squawking about Digest, I don't think this will fly) d) There are two standards: WebDAV-with-digest WebDAV-with-SSL/TLS An implementation (client or server) supports either or both. The two protocols are not interoperable, of course, so you should be careful to say which you have. In all of these cases, you can support other authentication mechanisms too, but it doesn't guarantee interoperability. I don't have a preference for what the standard should say, except that I believe that it's important that users should be able to tell whether a client will interoperate with a server without having to do some kind of protocol analysis to see which options each supports. From w3c-dist-auth-request@w3.org Fri Nov 2 12:13: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 MAA12004 for ; Fri, 2 Nov 2001 12:13:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA03847; Fri, 2 Nov 2001 12:06:36 -0500 (EST) Resent-Date: Fri, 2 Nov 2001 12:06:36 -0500 (EST) Resent-Message-Id: <200111021706.MAA03847@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA03822 for ; Fri, 2 Nov 2001 12:06:31 -0500 (EST) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA12828 for ; Fri, 2 Nov 2001 12:06:31 -0500 Received: (from root@localhost) by opentext.com (8.9.3/8.9.3) id MAA18196; Fri, 2 Nov 2001 12:06:00 -0500 Received: from 022.dhcp2.liv.opentext.com(172.17.2.22) by krusty.wl.opentext.com via smap (V2.1) id xma018185; Fri, 2 Nov 01 12:05:58 -0500 From: "Dylan Barrell" To: "Larry Masinter" , "Jim Whitehead" Cc: Date: Fri, 2 Nov 2001 12:05:20 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Subject: RE: Resolving Digest authentication issue Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5532 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit If we have to choose one, then I vote for Basic/SSL/TLS --Dylan > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Larry Masinter > Sent: Friday, November 02, 2001 11:44 AM > To: Jim Whitehead > Cc: w3c-dist-auth@w3.org > Subject: RE: Resolving Digest authentication issue > > > > Thus, I propose the following authentication requirements: > > > > * Basic MUST NOT be used unless the connection is secure. Secure is > defined > > to be TLS over the Internet, a physically secure network, or a network > > behind a well-administered firewall. > > In most IETF circles, it is believed that "well-administered firewall" > is a fleeting circumstance: you might have one today, but it's unlikely > to remain that way for long. It is also believed that the only > "physically secure network" is one that you make with wirecutters -- > snipping all the cables, and that the specifications for things > appropriate for those networks aren't the domain of the IETF. > > That's why, in general, no IETF standards-track document can assume > such things. (If you want to deploy a system that makes those assumptions, > that's fine, you just can't say that there's an IETF standard that it's > compliant with). > > So I think the acceptable choices (as far as IETF goes) are: > > a) clients and servers MUST support Digest (what we have now) > b) clients MUST support BOTH Digest and basic-with-SSL/TLS > servers MUST support one or the other (or both) > c) clients MUST support one or the other (or both) > servers MUST support both Digest and basic-with-SSL/TLS > (since it is the server implementors squawking about Digest, > I don't think this will fly) > d) There are two standards: > WebDAV-with-digest > WebDAV-with-SSL/TLS > An implementation (client or server) supports either or both. > The two protocols are not interoperable, of course, so you > should be careful to say which you have. > > In all of these cases, you can support other authentication mechanisms > too, but it doesn't guarantee interoperability. > > I don't have a preference for what the standard should say, > except that I believe that it's important that users should > be able to tell whether a client will interoperate with a > server without having to do some kind of protocol analysis > to see which options each supports. From w3c-dist-auth-request@w3.org Fri Nov 2 13:03:43 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 NAA13640 for ; Fri, 2 Nov 2001 13:03:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA07551; Fri, 2 Nov 2001 13:02:14 -0500 (EST) Resent-Date: Fri, 2 Nov 2001 13:02:14 -0500 (EST) Resent-Message-Id: <200111021802.NAA07551@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA07525 for ; Fri, 2 Nov 2001 13:02:01 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA19346 for ; Fri, 2 Nov 2001 13:02:01 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA02963 for ; Fri, 2 Nov 2001 10:04:52 -0800 (PST) From: "Jim Whitehead" To: Date: Fri, 2 Nov 2001 09:58:01 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: Resolving Digest authentication issue Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5533 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > In most IETF circles, it is believed that "well-administered firewall" > is a fleeting circumstance: you might have one today, but it's unlikely > to remain that way for long. It is also believed that the only > "physically secure network" is one that you make with wirecutters -- > snipping all the cables, and that the specifications for things > appropriate for those networks aren't the domain of the IETF. All true. My purpose was to characterize times when someone might reasonably deploy and use Basic authentication. It's naive to assume that Basic will not be used, and so having the protocol state "don't do this thing that everyone does" makes it seem out of touch. > b) clients MUST support BOTH Digest and basic-with-SSL/TLS > servers MUST support one or the other (or both) This is essentially what I was proposing. I think you are proposing we go further and add "clients MUST only use Basic when using SSL/TLS". After all, if a client supports basic with SSL/TLS, then it of course supports Basic when not using SSL/TLS. But, I think adding additional constraints goes too far -- what if a different transport security mechanism is introduced, perhaps as part of IPv6? It would be better to say, "clients MUST only use Basic over a secure connection", which then gets us back to the definition of a secure connection. > I don't have a preference for what the standard should say, > except that I believe that it's important that users should > be able to tell whether a client will interoperate with a > server without having to do some kind of protocol analysis > to see which options each supports. The solution is to place the responsibility of supporting as many authentication schemes as possible on the client. This frees the server to pick the one that best serves its needs. That's why I like your choice (b), since clients MUST support Basic and Digest, while servers only must support one of the two. This, then, meets the condition of interoperability without the user needing to do detailed protocol analysis. - Jim From w3c-dist-auth-request@w3.org Fri Nov 2 13:17: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 NAA14058 for ; Fri, 2 Nov 2001 13:17:58 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA07967; Fri, 2 Nov 2001 13:16:30 -0500 (EST) Resent-Date: Fri, 2 Nov 2001 13:16:30 -0500 (EST) Resent-Message-Id: <200111021816.NAA07967@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA07943 for ; Fri, 2 Nov 2001 13:16:24 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37184.rational.com [192.229.37.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA20570 for ; Fri, 2 Nov 2001 13:16:25 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Fri, 02 Nov 2001 13:15:54 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <4D31R15H>; Fri, 2 Nov 2001 13:15:54 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AD49@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Fri, 2 Nov 2001 13:15:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Resolving Digest authentication issue Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5534 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Oops. My preferred choice (server MUST support either Digest or Basic-with-SSL/TLS) was option (b), not option (c)). The problem with saying just "a secure transport mechanism" is that this doesn't help a client know what secure transport mechanisms it needs to support in order to interoperate. Cheers, Geoff -----Original Message----- From: Clemm, Geoff [mailto:gclemm@Rational.Com] Sent: Friday, November 02, 2001 12:05 PM To: w3c-dist-auth@w3.org Subject: RE: Resolving Digest authentication issue I agree with Larry. The statement made in the protocol should just be a simple "A WebDAV server MUST support xxx". Since an argument has been made that "A WebDAV server MUST support digest" is not acceptable, the only choice I see is option (c), namely: "A WebDAV server MUST support either Digest or Basic-with-SSL/TLS". The fact that an interoperable client must support both Digest and Basic-with-SSL/TLS follows from this statement about the server, and therefore is redundant. All that additional language about when to use Digest vs Basic is standard security info just obscures the basic interoperability issue, and should occur in the authentication protocol definitions, not in the WebDAV spec. Cheers, Geoff -----Original Message----- From: Larry Masinter [mailto:LMM@acm.org] Sent: Friday, November 02, 2001 11:44 AM To: Jim Whitehead Cc: w3c-dist-auth@w3.org Subject: RE: Resolving Digest authentication issue > Thus, I propose the following authentication requirements: > > * Basic MUST NOT be used unless the connection is secure. Secure is defined > to be TLS over the Internet, a physically secure network, or a network > behind a well-administered firewall. In most IETF circles, it is believed that "well-administered firewall" is a fleeting circumstance: you might have one today, but it's unlikely to remain that way for long. It is also believed that the only "physically secure network" is one that you make with wirecutters -- snipping all the cables, and that the specifications for things appropriate for those networks aren't the domain of the IETF. That's why, in general, no IETF standards-track document can assume such things. (If you want to deploy a system that makes those assumptions, that's fine, you just can't say that there's an IETF standard that it's compliant with). So I think the acceptable choices (as far as IETF goes) are: a) clients and servers MUST support Digest (what we have now) b) clients MUST support BOTH Digest and basic-with-SSL/TLS servers MUST support one or the other (or both) c) clients MUST support one or the other (or both) servers MUST support both Digest and basic-with-SSL/TLS (since it is the server implementors squawking about Digest, I don't think this will fly) d) There are two standards: WebDAV-with-digest WebDAV-with-SSL/TLS An implementation (client or server) supports either or both. The two protocols are not interoperable, of course, so you should be careful to say which you have. In all of these cases, you can support other authentication mechanisms too, but it doesn't guarantee interoperability. I don't have a preference for what the standard should say, except that I believe that it's important that users should be able to tell whether a client will interoperate with a server without having to do some kind of protocol analysis to see which options each supports. From w3c-dist-auth-request@w3.org Sun Nov 4 21:32:26 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 VAA19483 for ; Sun, 4 Nov 2001 21:32:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA17533; Sun, 4 Nov 2001 21:30:18 -0500 (EST) Resent-Date: Sun, 4 Nov 2001 21:30:18 -0500 (EST) Resent-Message-Id: <200111050230.VAA17533@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA17510 for ; Sun, 4 Nov 2001 21:30:02 -0500 (EST) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA17349 for ; Sun, 4 Nov 2001 21:30:01 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id SAA15130; Sun, 4 Nov 2001 18:36:25 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Sun, 4 Nov 2001 18:36:24 -0800 From: Greg Stein To: Matthieu Chevrier Cc: w3c-dist-auth@w3.org Message-ID: <20011104183624.Q13242@lyra.org> Mail-Followup-To: Matthieu Chevrier , w3c-dist-auth@w3.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mchevrier@4D.com on Sun, Nov 04, 2001 at 01:40:02PM -0800 X-URL: http://www.lyra.org/greg/ Subject: Re: [Interop] quick poll on the Translate field Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5535 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: [ moving this to the w3c-dist-auth list, where discussion belongs. a poll on the interop list is fine, but no more than that. ] Before continuing further on this discussion, you should read the thread that just occurred on the webdav working group list. See: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0094.html and the replies... On Sun, Nov 04, 2001 at 01:40:02PM -0800, Matthieu Chevrier wrote: > > > mod_dav does not implement it, and it never will. > > Frankly, I believe that this is a mistake. but I am a bit too young to the > DAV world to try to convince you. You're free to disagree with me :-) > I wish I could hear from some people on the Client side, especially the > GoLive/DreamWeaver teams, or simply some webmasters using WebDAV as > end-users. With some luck some of them could confirm that you just can't use > WebDAV to edit remotely your website if it contains non static pages. and > that means quite a few people will stick with FTP ;-( I realize that WebDAV > is not intended only for Webmasters, but they still represent a large amount > of users. I've used it myself, and the multiple resource model works quite fine. Through one namespace, I get the output. Through another, it is read/write and I can edit the source. So I maintain that today's WebDAV *can* edit non-static pages. Now, if the clients could simply read the DAV:source element, then it make things even easier. > Now concerning the alternative/cleaner solutions you refer to, I do not know > what they are. The DAV:source element referring to a separate namespace. Go read that thread that I referred to at the top of this email. > but I fear in advance that it's going to be much more > complex, that very few clients will actually implement it, and that in > practive it will do no more than what the Translate field did. If you "do not know what they are", then you cannot make that claim. So don't even try, please. > Also, I am > concerned about the security : the most straightforward solutions are often > the most secure (IIS4 being the exception to this rule ;-) Separate resources for the source and for the generated output means that you can apply *better* security. One resource is open to everybody, and the other resource is locked up tight. > So what will gain WebDAV from this choice, apart from proving that even > Microsoft can't always do whatever they want ? Microsoft has nothing to do with this. WebDAV has a design for this today, and it works. The Translate header has numerous problems. In particular, I like Roy Fielding's and Geoff Clemm's responses in the referenced thread; they make pretty strong/clear points about the issue. > Don't get me wrong, I am a big supporter of WebDAV, and I am just trying to > find a practical solution to an issue which I believe has been left apart by > the specs. And the solution brought silently by Microsoft, which may be not > the most elegant/perfect, does address the issue. But if other people tell > me that the other solutions are much better AND are implemented, then I will > be happy to modify our server WebSTAR in order to support it. Existing implementations of a poor solution does not make it a good solution. We're here to make good standards, not to simply follow what somebody has done to work around a problem. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sun Nov 4 22:50: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 WAA22005 for ; Sun, 4 Nov 2001 22:50:23 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA19441; Sun, 4 Nov 2001 22:45:33 -0500 (EST) Resent-Date: Sun, 4 Nov 2001 22:45:33 -0500 (EST) Resent-Message-Id: <200111050345.WAA19441@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA19421 for ; Sun, 4 Nov 2001 22:45:28 -0500 (EST) Received: from kurgan.lyra.org (kurgan.lyra.org [198.144.203.198]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA21797 for ; Sun, 4 Nov 2001 22:45:27 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id TAA15192 for w3c-dist-auth@w3.org; Sun, 4 Nov 2001 19:52:00 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Sun, 4 Nov 2001 19:52:00 -0800 From: Greg Stein To: w3c-dist-auth@w3.org Message-ID: <20011104195200.S13242@lyra.org> Mail-Followup-To: w3c-dist-auth@w3.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i X-URL: http://www.lyra.org/greg/ Subject: web folders incompatibility? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5536 X-Loop: w3c-dist-auth@w3.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 that I just ran into a problem with Web Folders and wondered if anybody else has seen this. Or if my assumptions are mistaken :-) I set a property on a file like so: x There is no default namespace defined. When I select "Properties" in a Web Folder, it pops up an error dialog saying "Unable to display properties." I've narrowed it down to exactly this property. Just setting this one single property on a file will do it. Has anybody else seen this? Or duplicate it? The User-Agent is "Microsoft Data Access Internet Publishing Provider DAV 1.1" Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Nov 5 03:40:51 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 DAA09177 for ; Mon, 5 Nov 2001 03:40:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA27094; Mon, 5 Nov 2001 03:35:49 -0500 (EST) Resent-Date: Mon, 5 Nov 2001 03:35:49 -0500 (EST) Resent-Message-Id: <200111050835.DAA27094@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA27018 for ; Mon, 5 Nov 2001 03:35:33 -0500 (EST) Received: from nike.mediafactory.de ([194.25.116.194]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA10652 for ; Mon, 5 Nov 2001 03:35:32 -0500 Message-Id: <200111050835.DAA10652@tux.w3.org> Received: FROM nike BY nike.mediafactory.de ; Mon Nov 05 09:35:25 2001 +0100 From: "Henrik Genssen" To: Date: Mon, 5 Nov 2001 09:35:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id DAA27018 Subject: Fw: web folders incompatibility? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5537 X-Loop: w3c-dist-auth@w3.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 never got them working as well... Nor visualisation of extending props, nor setting of standard props like attribs... The Webfolder does simply not show them. So if anyone has a working sample for a PROPFIND with depth 0 please send it in... But I even tried this with an IIS and the setting of props was not supported ether... Henrik ----- Original Message ----- From: "Greg Stein" To: Sent: Monday, November 05, 2001 4:52 AM Subject: web folders incompatibility? > It seems that I just ran into a problem with Web Folders and wondered if > anybody else has seen this. Or if my assumptions are mistaken :-) > > I set a property on a file like so: > > x > > There is no default namespace defined. When I select "Properties" in a Web > Folder, it pops up an error dialog saying "Unable to display properties." > > I've narrowed it down to exactly this property. Just setting this one single > property on a file will do it. > > Has anybody else seen this? Or duplicate it? > > The User-Agent is "Microsoft Data Access Internet Publishing Provider DAV 1.1" > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ > > > From w3c-dist-auth-request@w3.org Mon Nov 5 03:50: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 DAA09241 for ; Mon, 5 Nov 2001 03:50:18 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA27867; Mon, 5 Nov 2001 03:45:42 -0500 (EST) Resent-Date: Mon, 5 Nov 2001 03:45:42 -0500 (EST) Resent-Message-Id: <200111050845.DAA27867@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA27842 for ; Mon, 5 Nov 2001 03:45:22 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA12116 for ; Mon, 5 Nov 2001 03:45:20 -0500 Received: (qmail 24061 invoked by uid 0); 5 Nov 2001 08:45:15 -0000 Received: from pd9535125.dip.t-dialin.net (HELO lisa) (217.83.81.37) by mail.gmx.net (mp005-rz3) with SMTP; 5 Nov 2001 08:45:15 -0000 From: "Julian Reschke" To: "Greg Stein" , Date: Mon, 5 Nov 2001 09:45:51 +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 V6.00.2600.0000 Importance: Normal In-Reply-To: <20011104195200.S13242@lyra.org> Subject: RE: web folders incompatibility? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5538 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit If you are doing this with mod_dav, you might be hitting the bug (in mod_dav) I have reported recently: Do you have a trace to verify? > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > Sent: Monday, November 05, 2001 4:52 AM > To: w3c-dist-auth@w3.org > Subject: web folders incompatibility? > > > It seems that I just ran into a problem with Web Folders and wondered if > anybody else has seen this. Or if my assumptions are mistaken :-) > > I set a property on a file like so: > > x > > There is no default namespace defined. When I select "Properties" in a Web > Folder, it pops up an error dialog saying "Unable to display properties." > > I've narrowed it down to exactly this property. Just setting this > one single > property on a file will do it. > > Has anybody else seen this? Or duplicate it? > > The User-Agent is "Microsoft Data Access Internet Publishing > Provider DAV 1.1" > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ > From w3c-dist-auth-request@w3.org Mon Nov 5 05: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 ESMTP id FAA10763 for ; Mon, 5 Nov 2001 05:43:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA04357; Mon, 5 Nov 2001 05:41:18 -0500 (EST) Resent-Date: Mon, 5 Nov 2001 05:41:18 -0500 (EST) Resent-Message-Id: <200111051041.FAA04357@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA04335 for ; Mon, 5 Nov 2001 05:41:00 -0500 (EST) Received: from munich.ixos.de (HOST.31.95.ixos.de [149.235.31.95]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA25395 for ; Mon, 5 Nov 2001 05:40:59 -0500 Received: from muc-imc.ixos.de (localhost [127.0.0.1]) by munich.ixos.de (8.9.3/8.9.3) with ESMTP id KAA27197 for ; Mon, 5 Nov 2001 10:26:18 GMT Received: by muc-imc.ixos.de with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Nov 2001 11:41:10 +0100 Message-ID: From: Herbert Bock To: WebDAV Date: Mon, 5 Nov 2001 11:40:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5539 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Perhaps I'm a bit late with my comment but I just now read Jim's suggestions. Especially the MULTIPUT feature is one that I missed very very much when I recently read RFC2518 and tried to map the functionality of our systems to WebDAV. I think MULTIPUT is vital for many scenarios and it is quite easy to implement on the server side but extremely hard if not impossible on the client side. Please, please add this feature to WebDAV. I'm sure its desperately needed. And many thanks to Jim for triggering this. Regards, Herbert -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] Sent: Montag, 29. Oktober 2001 21:14 To: WebDAV Subject: Ideas: GETSRC & MULTIPUT I'm interested in the list's thoughts on two ideas for DAV improvements: The first is to introduce a GETSRC method to support access to the unprocessed source of a resource. This would decouple the dynamic response of a resource (GET) from its static source (GETSRC). The second is to introduce the MULTIPUT method to support "PUT with PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart MIME packages and atomically write them to the server. This would support the update of a resource and its metadata in one transaction. - Jim From w3c-dist-auth-request@w3.org Mon Nov 5 07:19:21 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 HAA12288 for ; Mon, 5 Nov 2001 07:19:20 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA10125; Mon, 5 Nov 2001 07:16:47 -0500 (EST) Resent-Date: Mon, 5 Nov 2001 07:16:47 -0500 (EST) Resent-Message-Id: <200111051216.HAA10125@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA10080 for ; Mon, 5 Nov 2001 07:16:30 -0500 (EST) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA04044 for ; Mon, 5 Nov 2001 07:16:24 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id EAA15654; Mon, 5 Nov 2001 04:22:44 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Mon, 5 Nov 2001 04:22:44 -0800 From: Greg Stein To: Julian Reschke Cc: w3c-dist-auth@w3.org Message-ID: <20011105042244.W13242@lyra.org> Mail-Followup-To: Julian Reschke , w3c-dist-auth@w3.org References: <20011104195200.S13242@lyra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from julian.reschke@gmx.de on Mon, Nov 05, 2001 at 09:45:51AM +0100 X-URL: http://www.lyra.org/greg/ Subject: Re: web folders incompatibility? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5540 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Totally unrelated to that. Sheesh. And I left out the most important part. The setting of xml:lang is what blows it up. Cheers, -g On Mon, Nov 05, 2001 at 09:45:51AM +0100, Julian Reschke wrote: > If you are doing this with mod_dav, you might be hitting the bug (in > mod_dav) I have reported recently: > > > > Do you have a trace to verify? > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > > Sent: Monday, November 05, 2001 4:52 AM > > To: w3c-dist-auth@w3.org > > Subject: web folders incompatibility? > > > > > > It seems that I just ran into a problem with Web Folders and wondered if > > anybody else has seen this. Or if my assumptions are mistaken :-) > > > > I set a property on a file like so: > > > > x > > > > There is no default namespace defined. When I select "Properties" in a Web > > Folder, it pops up an error dialog saying "Unable to display properties." > > > > I've narrowed it down to exactly this property. Just setting this > > one single > > property on a file will do it. > > > > Has anybody else seen this? Or duplicate it? > > > > The User-Agent is "Microsoft Data Access Internet Publishing > > Provider DAV 1.1" > > > > Cheers, > > -g > > > > -- > > Greg Stein, http://www.lyra.org/ > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Nov 5 08:46: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 IAA16848 for ; Mon, 5 Nov 2001 08:46:58 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA13268; Mon, 5 Nov 2001 08:44:52 -0500 (EST) Resent-Date: Mon, 5 Nov 2001 08:44:52 -0500 (EST) Resent-Message-Id: <200111051344.IAA13268@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA13223 for ; Mon, 5 Nov 2001 08:44:43 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA11812 for ; Mon, 5 Nov 2001 08:44:42 -0500 Received: (qmail 8813 invoked by uid 0); 5 Nov 2001 13:44:38 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp011-rz3) with SMTP; 5 Nov 2001 13:44:38 -0000 From: "Julian Reschke" To: "Greg Stein" , "Julian Reschke" Cc: Date: Mon, 5 Nov 2001 14:44:20 +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) In-reply-to: <20011105042244.W13242@lyra.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: web folders incompatibility? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5541 X-Loop: w3c-dist-auth@w3.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 Indeed. I can reproduce your problem with IE6 + Sharepoint Client. It seems that the webfolder client gets the namespace Uri and fails to foresee the case that it may be null. What's interesting is that the client is asking for all properties, although it will only display a hardwired set. Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > Sent: Monday, November 05, 2001 1:23 PM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: Re: web folders incompatibility? > > > Totally unrelated to that. > > Sheesh. And I left out the most important part. The setting of xml:lang is > what blows it up. > > Cheers, > -g > > On Mon, Nov 05, 2001 at 09:45:51AM +0100, Julian Reschke wrote: > > If you are doing this with mod_dav, you might be hitting the bug (in > > mod_dav) I have reported recently: > > > > > > > > Do you have a trace to verify? > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > > > Sent: Monday, November 05, 2001 4:52 AM > > > To: w3c-dist-auth@w3.org > > > Subject: web folders incompatibility? > > > > > > > > > It seems that I just ran into a problem with Web Folders and > wondered if > > > anybody else has seen this. Or if my assumptions are mistaken :-) > > > > > > I set a property on a file like so: > > > > > > x > > > > > > There is no default namespace defined. When I select > "Properties" in a Web > > > Folder, it pops up an error dialog saying "Unable to display > properties." > > > > > > I've narrowed it down to exactly this property. Just setting this > > > one single > > > property on a file will do it. > > > > > > Has anybody else seen this? Or duplicate it? > > > > > > The User-Agent is "Microsoft Data Access Internet Publishing > > > Provider DAV 1.1" > > > > > > Cheers, > > > -g > > > > > > -- > > > Greg Stein, http://www.lyra.org/ > > > > > -- > Greg Stein, http://www.lyra.org/ > From w3c-dist-auth-request@w3.org Mon Nov 5 10:06:26 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 KAA22072 for ; Mon, 5 Nov 2001 10:06:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA22266; Mon, 5 Nov 2001 10:04:01 -0500 (EST) Resent-Date: Mon, 5 Nov 2001 10:04:01 -0500 (EST) Resent-Message-Id: <200111051504.KAA22266@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA22236 for ; Mon, 5 Nov 2001 10:03:46 -0500 (EST) 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 KAA21903 for ; Mon, 5 Nov 2001 10:03:46 -0500 Received: from corp.enron.com (nahou-msmsw02p.corp.enron.com [192.168.110.109]) by postmaster.enron.com (8.10.1/8.10.1/external_corp-1.08) with ESMTP id fA5F30310281 for ; Mon, 5 Nov 2001 09:03:00 -0600 (CST) Received: from nahou-mscnx04p.corp.enron.com (unverified) by corp.enron.com (Content Technologies SMTPRS 4.2.1) with SMTP id ; Mon, 5 Nov 2001 09:02:55 -0600 Received: from NAHOU-MSDOG01V.corp.enron.com ([172.24.192.210]) by nahou-mscnx04p.corp.enron.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 5 Nov 2001 09:02:54 -0600 Date: Mon, 5 Nov 2001 09:02:57 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: Ideas: GETSRC & MULTIPUT Thread-Index: AcFl5qUvSwHRVwm1T+e8/GIgjTIExgAI944Q From: "Fuller, Dan (ENW)" To: "Herbert Bock" , "WebDAV" X-OriginalArrivalTime: 05 Nov 2001 15:02:54.0766 (UTC) FILETIME=[F28604E0:01C1660A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id KAA22236 Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5542 X-Loop: w3c-dist-auth@w3.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 Am I the only one who gets queazy about MULTIPUT? We have well implemented DIR and COPY commands in DOS that accept multiple parameters. Why not just extend PUT and GET to accept multiple parameters? -----Original Message----- From: Herbert Bock [mailto:herbert.bock@ixos.de] Sent: Mon, November 05, 2001 4:41 AM To: WebDAV Subject: RE: Ideas: GETSRC & MULTIPUT Perhaps I'm a bit late with my comment but I just now read Jim's suggestions. Especially the MULTIPUT feature is one that I missed very very much when I recently read RFC2518 and tried to map the functionality of our systems to WebDAV. I think MULTIPUT is vital for many scenarios and it is quite easy to implement on the server side but extremely hard if not impossible on the client side. Please, please add this feature to WebDAV. I'm sure its desperately needed. And many thanks to Jim for triggering this. Regards, Herbert -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] Sent: Montag, 29. Oktober 2001 21:14 To: WebDAV Subject: Ideas: GETSRC & MULTIPUT I'm interested in the list's thoughts on two ideas for DAV improvements: The first is to introduce a GETSRC method to support access to the unprocessed source of a resource. This would decouple the dynamic response of a resource (GET) from its static source (GETSRC). The second is to introduce the MULTIPUT method to support "PUT with PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart MIME packages and atomically write them to the server. This would support the update of a resource and its metadata in one transaction. - Jim ********************************************************************** This e-mail is the property of Enron Corp. and/or its relevant affiliate and may contain confidential and privileged material for the sole use of the intended recipient (s). Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender or reply to Enron Corp. at enron.messaging.administration@enron.com and delete all copies of the message. This e-mail (and any attachments hereto) are not intended to be an offer (or an acceptance) and do not create or evidence a binding and enforceable contract between Enron Corp. (or any of its affiliates) and the intended recipient or any other party, and may not be relied on by anyone as the basis of a contract by estoppel or otherwise. Thank you. ********************************************************************** From w3c-dist-auth-request@w3.org Mon Nov 5 14:34: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 OAA04112 for ; Mon, 5 Nov 2001 14:34:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA10742; Mon, 5 Nov 2001 14:28:11 -0500 (EST) Resent-Date: Mon, 5 Nov 2001 14:28:11 -0500 (EST) Resent-Message-Id: <200111051928.OAA10742@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA10722 for ; Mon, 5 Nov 2001 14:28:05 -0500 (EST) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA19500 for ; Mon, 5 Nov 2001 14:28:05 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id LAA16143; Mon, 5 Nov 2001 11:34:43 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Mon, 5 Nov 2001 11:34:43 -0800 From: Greg Stein To: interop@webdav.org Cc: w3c-dist-auth@w3.org, Mathias.Picker@virtual-earth.de Message-ID: <20011105113442.A16131@lyra.org> Mail-Followup-To: interop@webdav.org, w3c-dist-auth@w3.org, Mathias.Picker@virtual-earth.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i X-URL: http://www.lyra.org/greg/ Subject: [Mathias.Picker@virtual-earth.de: Re: [Interop] quick poll on the Translate field] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5543 X-Loop: w3c-dist-auth@w3.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 Mathias sent this directly to me. I believe it was intended to go back to the list. I've CC'd the main DAV list since this is turning from a quick poll about interop into a discussion of approaches. Cheers, -g ----- Forwarded message from Mathias.Picker@virtual-earth.de ----- From: Mathias.Picker@virtual-earth.de Subject: Re: [Interop] quick poll on the Translate field To: gstein@lyra.org Date: Mon, 5 Nov 2001 12:12:15 +0100 (CET) SimpleCMS does support it, as well as the source/link way of doing it. On 3 Nov, Greg Stein wrote: > On Fri, Nov 02, 2001 at 05:33:17PM -0800, Matthieu Chevrier wrote: >>... >> --> which WebDAV Servers and Clients support (or will very soon) the >> 'Translate' field ? (besides IE on PC) > > mod_dav does not implement it, and it never will. > > > IMO, it is the wrong approach to solving the problem. The source/link > stuff and multiple resources is the right way. You didn't ask for a No, it isn't. translate and source/link solve different problems. WebDAV emulates a file system layer. So my clients expect _one_ source file. Everthing else is nice-to-have, and may be very powerfull for some uses, but is obviously wrong for a simple: give me _this_ resource, untranslated. As for SimpleCMS, we could well use the both approaches for different reasons (we do not right now). Situation: every page is transformed on-the-fly, using a menu-module, and possible background, logo etc. resources. So, where should the source link(s) point to? The complete solution: - a raw version of the url in question and probably - a menu vonfig page, where the current menu style is choosen (or the menu program module??) - the background gif - the logo, if used - any sub-dir logos, if used - possible many more resources. - if it's a database generated pag: possible pointers to the raw table data, too. Very powerfull, potentially very usefull, but tell me: how should a network redirector like WebIFS show this mess to the user?? Instead, the translate header would just say: give me _this_ url, untranslated. No questions what this means. One resource. No choice (no power, too :). Easy to realize, consistent with the file system model, and easy to explain to the user. So: source link are nice and powerfull and may be used for advanced purposes, but are simply not the same as translate. Use both. Just my two cents Cheers, Mathias > "why?" (which is good: that belongs on w3c-dist-auth), but I figured > people would want to at least hear a bit more reason why mod_dav is > taking a stance against it. > > Cheers, > -g > -- virtual earth Mathias Picker Geschäftsführer Gesellschaft für Wissens re/prä sentation mbH Mathias.Picker@virtual-earth.de Fon +49 89 / 540 7425-1 Fax +49 89 / 540 7425-9 ----- End forwarded message ----- -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Nov 5 16:29:13 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 QAA08405 for ; Mon, 5 Nov 2001 16:29:12 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA16516; Mon, 5 Nov 2001 16:27:10 -0500 (EST) Resent-Date: Mon, 5 Nov 2001 16:27:10 -0500 (EST) Resent-Message-Id: <200111052127.QAA16516@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA16483 for ; Mon, 5 Nov 2001 16:26:54 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37184.rational.com [192.229.37.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA28114 for ; Mon, 5 Nov 2001 16:26:54 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Mon, 05 Nov 2001 16:25:50 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <4D31V38V>; Mon, 5 Nov 2001 16:25:50 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AD57@SUS-MA1IT01> From: "Clemm, Geoff" To: interop@webdav.org Cc: w3c-dist-auth@w3.org, Mathias.Picker@virtual-earth.de Date: Mon, 5 Nov 2001 16:25:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Mathias.Picker@virtual-earth.de: Re: [Interop] quick poll on the Translate field] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5544 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: My standard response to everyone who suggests that it is too complicated for a client to make sense of multiple source fields is: adopt the convention that the first link is the most important one, and just show that one. Some of the points made in the WebDAV thread against using headers to control what GET does: One very common mechanism for doing Web-based access control is to base the access control on the URL (i.e. what you can do to a resource depends on what the URL is). Using any header (such as the Translate header) breaks any scheme like this. When you do a COPY, should it go against the raw form or the processed form of the resource? Probably need the Translate header for that then too. Similarly for any other method that could reasonably be applied to both the raw and the processed form. So all that is needed is for the server to be able to dummy up some URL that means "the raw form of this resource" to avoid all these issues. That does not seem like an unreasonable burden on the server implementor. Similarly, I don't think it is an unreasonable burden on a client writer to do one extra roundtrip to retrieve a tree of source images (i.e. one Depth:infinity PROPFIND to retrieve all the links for a tree). Cheers, Geoff -----Original Message----- From: Greg Stein [mailto:gstein@lyra.org] Sent: Monday, November 05, 2001 2:35 PM To: interop@webdav.org Cc: w3c-dist-auth@w3.org; Mathias.Picker@virtual-earth.de Subject: [Mathias.Picker@virtual-earth.de: Re: [Interop] quick poll on the Translate field] Mathias sent this directly to me. I believe it was intended to go back to the list. I've CC'd the main DAV list since this is turning from a quick poll about interop into a discussion of approaches. Cheers, -g ----- Forwarded message from Mathias.Picker@virtual-earth.de ----- From: Mathias.Picker@virtual-earth.de Subject: Re: [Interop] quick poll on the Translate field To: gstein@lyra.org Date: Mon, 5 Nov 2001 12:12:15 +0100 (CET) SimpleCMS does support it, as well as the source/link way of doing it. On 3 Nov, Greg Stein wrote: > On Fri, Nov 02, 2001 at 05:33:17PM -0800, Matthieu Chevrier wrote: >>... >> --> which WebDAV Servers and Clients support (or will very soon) the >> 'Translate' field ? (besides IE on PC) > > mod_dav does not implement it, and it never will. > > > IMO, it is the wrong approach to solving the problem. The source/link > stuff and multiple resources is the right way. You didn't ask for a No, it isn't. translate and source/link solve different problems. WebDAV emulates a file system layer. So my clients expect _one_ source file. Everthing else is nice-to-have, and may be very powerfull for some uses, but is obviously wrong for a simple: give me _this_ resource, untranslated. As for SimpleCMS, we could well use the both approaches for different reasons (we do not right now). Situation: every page is transformed on-the-fly, using a menu-module, and possible background, logo etc. resources. So, where should the source link(s) point to? The complete solution: - a raw version of the url in question and probably - a menu vonfig page, where the current menu style is choosen (or the menu program module??) - the background gif - the logo, if used - any sub-dir logos, if used - possible many more resources. - if it's a database generated pag: possible pointers to the raw table data, too. Very powerfull, potentially very usefull, but tell me: how should a network redirector like WebIFS show this mess to the user?? Instead, the translate header would just say: give me _this_ url, untranslated. No questions what this means. One resource. No choice (no power, too :). Easy to realize, consistent with the file system model, and easy to explain to the user. So: source link are nice and powerfull and may be used for advanced purposes, but are simply not the same as translate. Use both. Just my two cents Cheers, Mathias > "why?" (which is good: that belongs on w3c-dist-auth), but I figured > people would want to at least hear a bit more reason why mod_dav is > taking a stance against it. > > Cheers, > -g > -- virtual earth Mathias Picker Geschäftsführer Gesellschaft für Wissens re/prä sentation mbH Mathias.Picker@virtual-earth.de Fon +49 89 / 540 7425-1 Fax +49 89 / 540 7425-9 ----- End forwarded message ----- -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Nov 5 16:46: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 QAA08819 for ; Mon, 5 Nov 2001 16:46:57 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA17426; Mon, 5 Nov 2001 16:45:21 -0500 (EST) Resent-Date: Mon, 5 Nov 2001 16:45:21 -0500 (EST) Resent-Message-Id: <200111052145.QAA17426@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA17402 for ; Mon, 5 Nov 2001 16:45:15 -0500 (EST) 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 QAA29525 for ; Mon, 5 Nov 2001 16:45:14 -0500 Received: from lisa [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Mon, 05 Nov 2001 22:44:20 +0100 From: "Julian Reschke" To: "Clemm, Geoff" , Cc: , Date: Mon, 5 Nov 2001 22:45:03 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <3906C56A7BD1F54593344C05BD1374B103F8AD57@SUS-MA1IT01> Importance: Normal X-MDRemoteIP: 192.168.1.2 X-Return-Path: julian.reschke@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: RE: [Mathias.Picker@virtual-earth.de: Re: [Interop] quick poll on the Translate field] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5545 X-Loop: w3c-dist-auth@w3.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 Our server currently supports the Translate header (because it's supported by Microsoft). However, experience shows that the way it's defined (or not defined, lacking any official documentation) I really problematic. For instance, PROPFIND currently will behave differently depending on the Translate header -- in the default case, the server will (try to) report the properties of the dynamic content (and in many case will fail to do so, for instance for the content length). This basically means that we're forcing clients to supply a proprietary and under-specified header to get at the 'real' (static) information. It seems that having different URLs for different things is the way to go, however, the DAV:source property should a) have better documentation, b) be easier to act upon by a user client (see proposal in [1]) Julian [1] > -----Original Message----- > From: interop-admin@webdav.org [mailto:interop-admin@webdav.org]On > Behalf Of Clemm, Geoff > Sent: Monday, November 05, 2001 10:26 PM > To: interop@webdav.org > Cc: w3c-dist-auth@w3.org; Mathias.Picker@virtual-earth.de > Subject: RE: [Mathias.Picker@virtual-earth.de: Re: [Interop] quick poll > on the Translate field] > > > My standard response to everyone who suggests that it is > too complicated for a client to make sense of multiple source > fields is: adopt the convention that the first link is the > most important one, and just show that one. > > Some of the points made in the WebDAV thread against using > headers to control what GET does: > > One very common mechanism for doing Web-based access control > is to base the access control on the URL (i.e. what you can do > to a resource depends on what the URL is). Using any header > (such as the Translate header) breaks any scheme like this. > > When you do a COPY, should it go against the raw form or > the processed form of the resource? Probably need the Translate > header for that then too. Similarly for any other method that > could reasonably be applied to both the raw and the processed form. > > So all that is needed is for the server to be able to dummy up > some URL that means "the raw form of this resource" to avoid all > these issues. That does not seem like an unreasonable burden on > the server implementor. Similarly, I don't think it is an unreasonable > burden on a client writer to do one extra roundtrip to retrieve a > tree of source images (i.e. one Depth:infinity PROPFIND to retrieve > all the links for a tree). > > Cheers, > Geoff > > > -----Original Message----- > From: Greg Stein [mailto:gstein@lyra.org] > Sent: Monday, November 05, 2001 2:35 PM > To: interop@webdav.org > Cc: w3c-dist-auth@w3.org; Mathias.Picker@virtual-earth.de > Subject: [Mathias.Picker@virtual-earth.de: Re: [Interop] quick poll on > the Translate field] > > > Mathias sent this directly to me. I believe it was intended to go back to > the list. I've CC'd the main DAV list since this is turning from a quick > poll about interop into a discussion of approaches. > > Cheers, > -g > > ----- Forwarded message from Mathias.Picker@virtual-earth.de ----- > > From: Mathias.Picker@virtual-earth.de > Subject: Re: [Interop] quick poll on the Translate field > To: gstein@lyra.org > Date: Mon, 5 Nov 2001 12:12:15 +0100 (CET) > > SimpleCMS does support it, as well as the source/link way of doing it. > > > On 3 Nov, Greg Stein wrote: > > On Fri, Nov 02, 2001 at 05:33:17PM -0800, Matthieu Chevrier wrote: > >>... > >> --> which WebDAV Servers and Clients support (or will very soon) the > >> 'Translate' field ? (besides IE on PC) > > > > mod_dav does not implement it, and it never will. > > > > > > IMO, it is the wrong approach to solving the problem. The source/link > > stuff and multiple resources is the right way. You didn't ask for a > > No, it isn't. translate and source/link solve different problems. WebDAV > emulates a file system layer. So my clients expect _one_ source file. > Everthing else is nice-to-have, and may be very powerfull for some uses, > but is obviously wrong for a simple: give me _this_ resource, > untranslated. > > As for SimpleCMS, we could well use the both approaches for different > reasons (we do not right now). > > Situation: every page is transformed on-the-fly, using a menu-module, > and possible background, logo etc. resources. > > So, where should the source link(s) point to? The complete solution: > - a raw version of the url in question > and probably > - a menu vonfig page, where the current menu style is choosen (or the > menu program module??) > - the background gif > - the logo, if used > - any sub-dir logos, if used > - possible many more resources. > - if it's a database generated pag: possible pointers to the raw table > data, too. > > Very powerfull, potentially very usefull, but tell me: how should a > network redirector like WebIFS show this mess to the user?? > > > Instead, the translate header would just say: give me _this_ url, > untranslated. No questions what this means. One resource. No choice (no > power, too :). Easy to realize, consistent with the file system model, > and easy to explain to the user. > > So: source link are nice and powerfull and may be used for advanced > purposes, but are simply not the same as translate. > > Use both. > > > Just my two cents > > Cheers, Mathias > > > "why?" (which is good: that belongs on w3c-dist-auth), but I figured > > people would want to at least hear a bit more reason why mod_dav is > > taking a stance against it. > > > > Cheers, > > -g > > > > -- > virtual earth > Mathias Picker > Geschäftsführer Gesellschaft für Wissens re/prä sentation mbH > > Mathias.Picker@virtual-earth.de > Fon +49 89 / 540 7425-1 > Fax +49 89 / 540 7425-9 > > ----- End forwarded message ----- > > -- > Greg Stein, http://www.lyra.org/ > _______________________________________________ > Interop mailing list > Interop@webdav.org > http://mailman.webdav.org/mailman/listinfo/interop > > From w3c-dist-auth-request@w3.org Mon Nov 5 17:45:02 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 RAA10033 for ; Mon, 5 Nov 2001 17:45:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA19308; Mon, 5 Nov 2001 17:43:04 -0500 (EST) Resent-Date: Mon, 5 Nov 2001 17:43:04 -0500 (EST) Resent-Message-Id: <200111052243.RAA19308@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA19286 for ; Mon, 5 Nov 2001 17:42:47 -0500 (EST) Received: from mail.4d.com ([216.33.0.197]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA01136 for ; Mon, 5 Nov 2001 17:42:46 -0500 Received: from 10.196.1.86 by mail.4d.com; Mon, 5 Nov 2001 14:44:42 -0800 User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 15 Nov 2001 14:42:58 -0800 From: Matthieu Chevrier To: Message-ID: In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AD57@SUS-MA1IT01> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Interop] quick poll on the Translate field] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5546 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > One very common mechanism for doing Web-based access control > is to base the access control on the URL (i.e. what you can do > to a resource depends on what the URL is). An access control based entirely on the URL ? hum. so it would give the same access for a GET and DELETE command ? Even these systems need to extract other info from the HTTP request, like the method name in the first place. So checking a new HTTP field should not be a big deal (it's not in our implementation). > When you do a COPY, should it go against the raw form or > the processed form of the resource? Probably need the Translate > header for that then too. Similarly for any other method that > could reasonably be applied to both the raw and the processed form. Do a COPY, MOVE, DELETE on the processed version makes no sense, isnt'it ? At least for all the existing Clients that I know of right now. For PROPFIND and PROPPATCH, it's not as obvious, though using the raw file is probably what we want in 99% of the cases. > So all that is needed is for the server to be able to dummy up > some URL that means "the raw form of this resource" to avoid all > these issues. I am not a big fan of having several URLs for the same resource in different status. Seems more like a workaround than anything else. To be honest I didn't really want to start discussing the specs when I asked to the interop list who was supporting the 'Translate' field. too late ;-) In my perspective if all clients were sending the 'Translate: f' with all their outgoing requests AND if the servers were always targetting the raw resource (considering the user has the right priviledges of course) then we would not have this discussion today. and my main concern is that, whatever solution is chosen, it is widely supported asap by most Clients and Servers (another point for the translate field). Unfortunately it does not seem to be the case, and it could be a hurdle for the big WebDAV breakthrough we all want to happen. Sincerely, Matthieu. From w3c-dist-auth-request@w3.org Mon Nov 5 17:52:14 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 RAA10127 for ; Mon, 5 Nov 2001 17:52:14 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA19586; Mon, 5 Nov 2001 17:50:16 -0500 (EST) Resent-Date: Mon, 5 Nov 2001 17:50:16 -0500 (EST) Resent-Message-Id: <200111052250.RAA19586@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA19565 for ; Mon, 5 Nov 2001 17:50:09 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA01734 for ; Mon, 5 Nov 2001 17:50:08 -0500 Received: (qmail 2074 invoked by uid 0); 5 Nov 2001 22:49:37 -0000 Received: from pd9535606.dip.t-dialin.net (HELO lisa) (217.83.86.6) by mail.gmx.net (mp005-rz3) with SMTP; 5 Nov 2001 22:49:37 -0000 From: "Julian Reschke" To: "Matthieu Chevrier" , Date: Mon, 5 Nov 2001 23:50:16 +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 V6.00.2600.0000 In-reply-to: Importance: Normal Subject: RE: [Interop] quick poll on the Translate field] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5547 X-Loop: w3c-dist-auth@w3.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 Matthieu Chevrier > Sent: Thursday, November 15, 2001 11:43 PM > To: w3c-dist-auth@w3.org > Subject: Re: [Interop] quick poll on the Translate field] > > > > > One very common mechanism for doing Web-based access control > > is to base the access control on the URL (i.e. what you can do > > to a resource depends on what the URL is). > > An access control based entirely on the URL ? hum. so it would > give the same > access for a GET and DELETE command ? > Even these systems need to extract other info from the HTTP request, like > the method name in the first place. So checking a new HTTP field > should not > be a big deal (it's not in our implementation). I think you missed the WebDAV ACL spec :-) > > When you do a COPY, should it go against the raw form or > > the processed form of the resource? Probably need the Translate > > header for that then too. Similarly for any other method that > > could reasonably be applied to both the raw and the processed form. > > Do a COPY, MOVE, DELETE on the processed version makes no sense, isnt'it ? > At least for all the existing Clients that I know of right now. > > For PROPFIND and PROPPATCH, it's not as obvious, though using the raw file > is probably what we want in 99% of the cases. Really. So PROPFIND/getcontentlength will say "application/ecma-script", but GET returns HTML content? > > So all that is needed is for the server to be able to dummy up > > some URL that means "the raw form of this resource" to avoid all > > these issues. > > I am not a big fan of having several URLs for the same resource > in different > status. Seems more like a workaround than anything else. > > To be honest I didn't really want to start discussing the specs > when I asked > to the interop list who was supporting the 'Translate' field. too late ;-) > > In my perspective if all clients were sending the 'Translate: f' with all > their outgoing requests AND if the servers were always targetting the raw > resource (considering the user has the right priviledges of > course) then we > would not have this discussion today. So what should IE do upon GET? From w3c-dist-auth-request@w3.org Mon Nov 5 19:36:07 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 TAA11483 for ; Mon, 5 Nov 2001 19:36:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA23943; Mon, 5 Nov 2001 19:34:10 -0500 (EST) Resent-Date: Mon, 5 Nov 2001 19:34:10 -0500 (EST) Resent-Message-Id: <200111060034.TAA23943@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA23911 for ; Mon, 5 Nov 2001 19:33:59 -0500 (EST) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA09596 for ; Mon, 5 Nov 2001 19:33:58 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id QAA16605; Mon, 5 Nov 2001 16:40:36 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Mon, 5 Nov 2001 16:40:35 -0800 From: Greg Stein To: dav-announce@lyra.org Cc: dav-dev@lyra.org, w3c-dist-auth@w3.org Message-ID: <20011105164035.A16585@lyra.org> Mail-Followup-To: dav-announce@lyra.org, dav-dev@lyra.org, w3c-dist-auth@w3.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i X-URL: http://www.lyra.org/greg/ Subject: mod_dav: 1.0.3 release, a birthday, and a retrospective Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5548 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Three years ago, today, I released mod_dav 0.9.0 onto an unsuspecting world. For many, it was "cool technology", but they had no idea what to do with it, where it was going, or if it would even catch on. This was made very explicit when peole would ask, "Neat. What can I use with it?" "Nothing," I replied to their amazement. At that point, mod_dav was the *only* publicly available WebDAV tool out there. There were early (non-public) betas of Internet Explorer v5 that spoke an early and incompatible version of WebDAV. Somebody had to be the first WebDAV tool, and that was mod_dav. It wasn't until three weeks later that Joe Orton released sitecopy 0.2.9, which supported uploading web sites via WebDAV. Three years have passed, and wow... what a different WebDAV world we live in today. There are literally *dozens* of clients and servers and associated tools. Numerous articles, presentations, and papers have been written about WebDAV. It has taken hold... even to the point of peole *asking* for WebDAV capabilities at their work, their school, or from their ISPs. And mod_dav? By the latest Apache module report from E-Soft[1], mod_dav is the 8th most popular Apache module in use today. Nearly 2% of the public sites surveyed have mod_dav installed and configured to advertise itself. I am also amazed at the fact that those are the *public* sites. Using DAV on internal sites or only available on the internal side of a public site would be much more prevalent. So what is the reach/penetration there? I can only assume it would be much higher. mod_dav has seen even larger success by the simple virtue of it being an Open Source project. IBM uses mod_dav in their IBM HTTP Server and WebSphere products. Oracle uses a customized mod_dav to support a WebDAV front end to a content management system. Rational uses a customized mod_dav to provide WebDAV capabilities for their ClearCase repository. Apple bundles mod_dav in MacOS X Server, to provide file services to other (Mac) clients (and they are leaning towards using WebDAV to *replace* Apple File Sharing). And those are just the ones that I know about (mod_dav's license doesn't require companies to notify or cooperate with me to put mod_dav into their products). Schools, government labs, small and large companies, and non-profits have all used mod_dav for web site publishing and simple document management. Technologically, mod_dav has been used in many cases as a "reference" platform for testing WebDAV clients, and by *other* server developers who want to "see how mod_dav handles that situation." Of course, this is also greatly due to its zero purchase cost, but also simply because it is a full function implementation of RFC 2518 built upon the best HTTP reference platform of all: the Apache HTTP Server. I never gave it much attention because I knew Open Source was an unbeatable strategy, but people are going to ask about it... Three years ago, in the "Halloween documents" [2], Microsoft talked about using the WebDAV protocol as a barrier to Open Source developers. Mere days after the Halloween Document came out, mod_dav 0.9.0 was released. Since then, I think we have laid to rest the community's concern about the comments in those documents -- it goes without saying that the Open Source community is rich with WebDAV features: mod_dav, sitecopy, Neon, cadaver, Zope, Goliath, Nautilus, and PerlDAV just to name a few. mod_dav has stood the test of time, and I would like to thank all of the contributors to its development. Keith Wannamaker, John Vasta, and Joe Orton all deserve particular credit for their direct involvement with mod_dav's success. So with that... I'd like to announce the birthday release of mod_dav: mod_dav-1.0.3-1.3.6 has been released. The distribution and related information is available at: http://www.webdav.org/mod_dav/ This is primarily a bug fix release and some minor changes to improve interoperability. mod_dav is very stable code (the last release was over a year ago). See the change log at the bottom of the mod_dav page for more details. As always, upgrading is recommended to improve interoperability. There are no security issues which would require an upgrade. Please report problems, ask questions, or send patches to the mod_dav users and developers mailing list at: dav-dev@lyra.org Best wishes to all in the WebDAV community, and let's see where the next three years takes us! Cheers, -g [1] http://www.securityspace.com/s_survey/data/man.200110/apachemods.html [2] http://www.opensource.org/halloween/ -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Nov 6 06:33:48 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06293 for ; Tue, 6 Nov 2001 06:33:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA22542; Tue, 6 Nov 2001 06:31:03 -0500 (EST) Resent-Date: Tue, 6 Nov 2001 06:31:03 -0500 (EST) Resent-Message-Id: <200111061131.GAA22542@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA22522 for ; Tue, 6 Nov 2001 06:30:50 -0500 (EST) Received: from munich.ixos.de (HOST.31.95.ixos.de [149.235.31.95]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA06330 for ; Tue, 6 Nov 2001 06:30:49 -0500 Received: from muc-imc.ixos.de (localhost [127.0.0.1]) by munich.ixos.de (8.9.3/8.9.3) with ESMTP id LAA16897; Tue, 6 Nov 2001 11:16:04 GMT Received: by muc-imc.ixos.de with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Nov 2001 12:30:55 +0100 Message-ID: From: Herbert Bock To: "'Fuller, Dan (ENW)'" , WebDAV Date: Tue, 6 Nov 2001 12:30:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5549 X-Loop: w3c-dist-auth@w3.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 Dan, could it be that you misunderstand the MULTIPUT as a PUT of more than one file? The MULTIPUT was meant as an atomic update of a resource and its related meta data. Regards, Herbert -----Original Message----- From: Fuller, Dan (ENW) [mailto:Dan.Fuller@enron.com] Sent: Montag, 5. November 2001 16:03 To: Herbert Bock; WebDAV Subject: RE: Ideas: GETSRC & MULTIPUT Am I the only one who gets queazy about MULTIPUT? We have well implemented DIR and COPY commands in DOS that accept multiple parameters. Why not just extend PUT and GET to accept multiple parameters? -----Original Message----- From: Herbert Bock [mailto:herbert.bock@ixos.de] Sent: Mon, November 05, 2001 4:41 AM To: WebDAV Subject: RE: Ideas: GETSRC & MULTIPUT Perhaps I'm a bit late with my comment but I just now read Jim's suggestions. Especially the MULTIPUT feature is one that I missed very very much when I recently read RFC2518 and tried to map the functionality of our systems to WebDAV. I think MULTIPUT is vital for many scenarios and it is quite easy to implement on the server side but extremely hard if not impossible on the client side. Please, please add this feature to WebDAV. I'm sure its desperately needed. And many thanks to Jim for triggering this. Regards, Herbert -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] Sent: Montag, 29. Oktober 2001 21:14 To: WebDAV Subject: Ideas: GETSRC & MULTIPUT I'm interested in the list's thoughts on two ideas for DAV improvements: The first is to introduce a GETSRC method to support access to the unprocessed source of a resource. This would decouple the dynamic response of a resource (GET) from its static source (GETSRC). The second is to introduce the MULTIPUT method to support "PUT with PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart MIME packages and atomically write them to the server. This would support the update of a resource and its metadata in one transaction. - Jim ********************************************************************** This e-mail is the property of Enron Corp. and/or its relevant affiliate and may contain confidential and privileged material for the sole use of the intended recipient (s). Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender or reply to Enron Corp. at enron.messaging.administration@enron.com and delete all copies of the message. This e-mail (and any attachments hereto) are not intended to be an offer (or an acceptance) and do not create or evidence a binding and enforceable contract between Enron Corp. (or any of its affiliates) and the intended recipient or any other party, and may not be relied on by anyone as the basis of a contract by estoppel or otherwise. Thank you. ********************************************************************** From w3c-dist-auth-request@w3.org Tue Nov 6 12:39:07 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 MAA22729 for ; Tue, 6 Nov 2001 12:39:07 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA18977; Tue, 6 Nov 2001 12:36:44 -0500 (EST) Resent-Date: Tue, 6 Nov 2001 12:36:44 -0500 (EST) Resent-Message-Id: <200111061736.MAA18977@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA18956 for ; Tue, 6 Nov 2001 12:36:37 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37184.rational.com [192.229.37.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA24466 for ; Tue, 6 Nov 2001 12:36:36 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Tue, 06 Nov 2001 12:34:59 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <4D31X350>; Tue, 6 Nov 2001 12:34:59 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AD5C@SUS-MA1IT01> From: "Clemm, Geoff" To: "'Mathias.Picker@virtual-earth.de'" Cc: interop@webdav.org, w3c-dist-auth@w3.org Date: Tue, 6 Nov 2001 12:34:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Mathias.Picker@virtual-earth.de: Re: [Interop] quick poll on the Translate field] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5550 X-Loop: w3c-dist-auth@w3.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: Mathias.Picker@virtual-earth.de I'm not against the source paradigm, but still see some problems there. The very first thing being the completely undefined semantics of it, if it has more than one link per resource. How is the semantics undefined? If you have multiple resources that are used to generate another resource, you need to give the user the option to modify any of them, since only the user knows which one needs to be modified. It's no harder for the user to decide which resource needs to be modified than it is to decide which line of a resource needs to be modified. On 5 Nov, Clemm, Geoff wrote: > My standard response to everyone who suggests that it is > too complicated for a client to make sense of multiple source > fields is: adopt the convention that the first link is the > most important one, and just show that one. I do not think that conventions will solve this problem. If you think its the solution, bring it into the standard. I'm not sure what "problem" you are trying to solve. The notion of "most important" is going to be a fuzzy concept at best, so you won't be able to formally define it in any case. Actually, I don't think it's a solution. When we put that information into the standard, we should a t least formally model this decision, by honoring the "preferred", "true", "i-really-mean-this" link with special markup. And here we have the semantic problem again: what do we _mean_ with multiple source links, and which one ist the "true" link to the source of this property? The whole point is that when there are multiple sources, there never is a well defined notion of "preferred", "true", or any such thing. Just as there is no well defined notion of "the preferred line of the file to change" or "the preferred paragraph to change". This is a bit like a file system, which does not show me mysource.c, but mysource.h, someheader.h, somesystemheader.h, evenmoreheaders.h, someconnectedsource.c,, mysource.c, somelibrary.a, somethingsentirelydiffent.dontknow. Do you find the source in that? Would you _want_ your file system to do that? And that's pretty much the example from the standard. If the thing I had to fix was defined in mysource.h, and not in mysource.c, a client that only showed me mysource.c is pretty useless. The difference between "test.c", "test.exe", and "the output of running test.exe" are all significant, and should each have their own URL. > One very common mechanism for doing Web-based access control > is to base the access control on the URL (i.e. what you can do > to a resource depends on what the URL is). Using any header > (such as the Translate header) breaks any scheme like this. Good point. But we do not control acces by URL, we control it by URL and method, and since some header obviously modify the semantic of methods (e.g. GET with if-modified-since is really a HEAD (=PROPGET?) if the resource has not been modified), so we allready control by URL and method and header implicitly, why shouldn't we officially control by URL and method and header? A header is an "argument" to a method. Normally, you do not base your access control for a method on the arguments to the method. Obviously you could in theory, but in practice the cost outweighs the benefit. > When you do a COPY, should it go against the raw form or > the processed form of the resource? Probably need the Translate > header for that then too. Similarly for any other method that > could reasonably be applied to both the raw and the processed form. Yes, and that's perfectly fine. Where's the problem there? The problem is that "Translate" is only one of many headers that one could think of that redirect to different content (e.g. a Version-Selector header for versioning, and a Variant-Selector header for variants. This means that every method would need to contain the logic for all of these headers, which requires massive reworking of the implementation whenever such a header is introduced. In addition, you now you have to define what happens when you combine these headers (is that the "Translate" of the "Version-Selector", or vica versa). Compare this to the source solution: Just look at the example in 13.10.1, where foo.bar/program has three source links. How do you copy this? Only the user knows the answer here, since it depends on what is being done. The copy operation needs to be well defined, and then the user can make sensible choices on composite copy requests. And, how do you manage the connection source to destination? I mean, if I copy the source or destination, should the corresponding destination or source be copied with it? If I copy the destination, will I create a sort of "binding", since in effect it's the same as the first destination, since it uses the same source link? or do I need to copy the source link, too? What happens if I move one or the other? It depends. There is no right answer here, so forcing one as the only answer is wrong. Nothing of this is defined (I just tried to find it in the standard or in the issues list, correct me if I'm wrong), making the current solution, well, hmmmm, what can I say ...: unusable? Nothing of this is defined because there is no "right" answer. Forcing a trivial wrong answer does not help things. > So all that is needed is for the server to be able to dummy up > some URL that means "the raw form of this resource" to avoid all > these issues. That does not seem like an unreasonable burden on > the server implementor. Similarly, I don't think it is an > unreasonable burden on a client writer to do one extra roundtrip to > retrieve a tree of source images (i.e. one Depth:infinity PROPFIND to > retrieve all the links for a tree). Well, unreasonable burden for the developer or not, I want the source and dest links to be the same, so users can use their favorite html/text-editor to edit the page and include links that actually work, whithout thinking about where the link should go, e.g. source or destination. Different source and destination hierarchy place an unreasonable burden on the _user_, not on the developer. Well, I want my users to be able to modify the right line of the source file without thinking about which line they need to modify. I won't get that either (:-). Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Nov 6 13:20:14 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25452 for ; Tue, 6 Nov 2001 13:20:14 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA23823; Tue, 6 Nov 2001 13:18:25 -0500 (EST) Resent-Date: Tue, 6 Nov 2001 13:18:25 -0500 (EST) Resent-Message-Id: <200111061818.NAA23823@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA23803 for ; Tue, 6 Nov 2001 13:18:17 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA29098 for ; Tue, 6 Nov 2001 13:18:17 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA146218 for ; Tue, 6 Nov 2001 13:15:11 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id fA6IHiX49388 for ; Tue, 6 Nov 2001 13:17:44 -0500 To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Tue, 6 Nov 2001 12:59:04 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V509_10042001 |October 4, 2001) at 11/06/2001 01:17:43 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Resolving Digest authentication issue Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5551 X-Loop: w3c-dist-auth@w3.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 we agree that Larry's option (b) is what we prefer to go with and that Jim Whitehead's proposal, which multiple people have supported, falls in category (b). The remaining question seems to be whether we will include any language about a secure network. The text was... Basic MUST NOT be used unless the connection is secure. Secure is defined to be TLS over the Internet, a physically secure network, or a network behind a well-administered firewall. Client requirements: MUST support Basic, SSL/TLS support is STRONGLY RECOMMENDED Server requirements: SHOULD support Basic, SSL/TLS support is STRONGLY RECOMMENDED Instead perhaps we can say something *like* the following... Basic MUST NOT be used unless the connection is secure. The recommended method for securing a connection is TLS. Client requirements: MUST support Basic, SSL/TLS support is STRONGLY RECOMMENDED Server requirements: SHOULD support Basic, SSL/TLS support is STRONGLY RECOMMENDED J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Tue Nov 6 15:06: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 PAA01225 for ; Tue, 6 Nov 2001 15:06:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA00333; Tue, 6 Nov 2001 15:04:29 -0500 (EST) Resent-Date: Tue, 6 Nov 2001 15:04:29 -0500 (EST) Resent-Message-Id: <200111062004.PAA00333@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA00308 for ; Tue, 6 Nov 2001 15:04:14 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA05415 for ; Tue, 6 Nov 2001 15:04:14 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA18664 for ; Tue, 6 Nov 2001 12:07:44 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 6 Nov 2001 12:00:11 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FW: 52nd IETF Agenda - As of Novermber 06. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5552 X-Loop: w3c-dist-auth@w3.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. -----Original Message----- From: dinaras@cnri.reston.va.us [mailto:dinaras@cnri.reston.va.us]On Behalf Of agenda@ietf.org Sent: Tuesday, November 06, 2001 11:21 AM To: iesg@ietf.org; wgchairs@ietf.org; bofchairs@ietf.org Cc: dinaras@ietf.org Subject: 52nd IETF Agenda - As of Novermber 06. Please review the below draft of the 52nd IETF Agenda. A lot of changes have been made in there since yestreday's version. And send us your comments. Thanks, Dinara Suleymanova Draft Agenda of the Fifty-second IETF December 9-14, 2001 SUNDAY, December 9, 2001 1200-1900 Registration 1530-1600 Newcomer's Orientation 1600-1630 IETF Standards Process Orientation 1700-1900 Welcome Reception MONDAY, December 10, 2001 0800-1930 IETF Registration - 0800-0900 Continental Breakfast 0900-1130 Morning Sessions APP apparea Applications Open Area Meeting & irnss & Internet Resource Name Search Service BOF INT dhc Dynamic Host Configuration WG IRTF gsec Group Security Research Group RTG forces Forwarding and Control Element Separation WG SEC kink Kerberized Internet Negotiation of Keys WG SUB ccamp Common Control and Measurement Plane WG TSV ips IP Storage WG TSV rmt Reliable Multicast Transport WG 1130-1300 Break 1300-1500 Afternoon Sessions I APP geopriv Geographic Location/Privacy WG INT idn Internationalized Domain Name WG INT l2tpext Layer Two Tunneling Protocol Extensions WG OPS adslmib ADSL MIB WG OPS mboned MBONE Deployment WG SEC inch Extended Incident Handling BOF SUB mpls Multiprotocol Label Switching WG USV uswg User Services WG 1500-1530 Break (Refreshments provided) 1530-1730 Afternoon Sessions II APP webdav WWW Distributed Authoring and Versioning WG APP intloc Internationalization and Localization of Internet Protocols BOF INT ipcdn IP over Cable Data Network WG OPS aaa Authentication, Authorization and Accounting WG OPS hubmib Ethernet Interfaces and Hub MIB WG SEC msec Multicast Security WG TSV diffserv Differentiated Services WG TSV mmusic Multiparty Multimedia Session Control WG 1730-1930 Break 1930-2200 Evening Sessions APP fax Internet Fax WG INT dnsext DNS Extensions WG INT ipoib IP over InfiniBand WG OPS rmonmib Remote Network Monitoring WG RTG manet Mobile Ad-hoc Networks WG SEC ipsp IP Security Policy WG TSV midcom Middlebox Communication WG TSV seamoby Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting WG TUESDAY, December 11, 2001 0800-1700 IETF Registration 0800-0900 Continental Breakfast 0900-1130 Morning Sessions APP trade Internet Open Trading Protocol WG INT ipngwg IPNG WG OPS bmwg Benchmarking Methodology WG RTG idr Inter-Domain Routing WG SEC pkix Public-Key Infrastructure (X.509) WG TSV ips IP Storage WG TSV rserpool Reliable Server Pooling WG 1130-1300 Break 1300-1400 Afternoon Sessions I OPS hubmib Ethernet Interfaces and Hub MIB WG & AToM MIB WG &INT & atommib RTG vrrp Virtual Router Redundancy Protocol WG SUB gsmp General Switch Management Protocol WG TSV pilc Performance Implications of Link Characteristics WG 1415-1515 Afternoon Sessions II APP provreg Provisioning Registry Protocol WG OPS rap Resource Allocation Protocol WG TSV iptel IP Telephony WG 1515-1545 Break (Refreshments provided) - 1545-1645 Afternoon Sessions III INT ipoib IP over InfiniBand WG INT atommib AToM MIB WG RTG udlr UniDirectional Link Routing WG TSV rmt Reliable Multicast Transport WG TSV sipping Session Initiation Proposal Investigation WG 1700-1800 Afternoon Sessions IV INT pppext Point-to-Point Protocol Extensions WG OPS rmonmib Remote Network Monitoring WG TSV spirits Service in the PSTN/IN Requesting InTernet Service WG TSV sipping Session Initiation Proposal Investigation WG WEDNESDAY, December 12, 2001 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions APP vpim Voice Profile for Internet Mail WG APP ldapbis LDAP (v3) Revision WG OPS dnsop Domain Name Server Operations WG OPS entmib Entity MIB WG INT mobileip IP Routing for Wireless/Mobile Hosts WG SEC sacred Securely Available Credentials WG SUB ppvpn Provider Provisioned Virtual Private Networks WG TSV avt Audio/Video Transport WG 1130-1300 Break 1300-1500 Afternoon Sessions I APP calsch Calendaring and Scheduling WG OPS bridge Bridge MIB WG OPS ngtrans Next Generation Transition WG RTG pim Protocol Independent Multicast WG SEC smime S/MIME Mail Security WG TSV megaco Media Gateway Control WG TSV seamoby Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting WG 1500-1530 Break (Refreshments provided) - 1530-1730 Afternoon Sessions II APP simple SIP for Instant Messaging and Presence Leveraging Extensions WG INT magma Multicast & Anycast Group Membership WG OPS ipfix IP Flow Information Export WG RTG idr Inter-Domain Routing WG SEC ipsec IP Security Protocol WG SUB ipo IP over Optical WG TSV nfsv4 Network File System Version 4 WG TSV sip Session Initiation Protocol WG 1730-1930 Break 1930-2200 Open Plenary - Welcome Speakers IESG Report IESG Open Mike 2230 Late Night Session PGP Key Signing THURSDAY, December 13, 2001 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions APP opes Open Pluggable Edge Services BOF INT ipngwg IPNG WG OPS aaa Authentication, Authorization and Accounting WG SEC ipsec IP Security Protocol WG SUB-IP tewg Internet Traffic Engineering WG TSV avt Audio/Video Transport WG TSV nsis Next Steps in Signaling WG 1130-1300 Break 1300-1500 Afternoon Sessions I APP ipp Internet Printing Protocol WG OPS ngtrans Next Generation Transition WG OPS policy Policy Framework WG SEC krb-wg Kerberos WG TSV sipping Session Initiation Proposal Investigation WG 1500-1530 Break (Refreshments provided) - 1530-1730 Afternoon Sessions II APP geopriv Geographic Location/Privacy WG APP ldup LDAP Duplication/Replication/Update Protocols WG IRTF aaaarch Authentication Authorisation Accounting ARCHitectureResearch Group SEC saag Open Security Area Directorate Meeting SUB mplsoam MPLS Maintenance Mechanisms BOF TSV pwe3 Pseudo Wire Emulation Edge to Edge WG TSV sip Session Initiation Protocol WG 1730-1930 Break 1930-2200 Open IAB Plenary - IAB Report including: RFC Editor Report IANA Report IRTF Report Question Open discussion on architectural principles FRIDAY, December 14, 2001 0800-1000 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions SEC idwg Intrusion Detection Exchange Format WG SUB-IP subarea Sub-IP Area Meeting From w3c-dist-auth-request@w3.org Tue Nov 6 20:30: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 UAA07713 for ; Tue, 6 Nov 2001 20:30:56 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA13203; Tue, 6 Nov 2001 20:29:14 -0500 (EST) Resent-Date: Tue, 6 Nov 2001 20:29:14 -0500 (EST) Resent-Message-Id: <200111070129.UAA13203@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA13168 for ; Tue, 6 Nov 2001 20:28:55 -0500 (EST) 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 UAA30452 for ; Tue, 6 Nov 2001 20:28:54 -0500 Received: by io.mds.rmit.edu.au (Postfix, from userid 301) id 10F8849B49; Wed, 7 Nov 2001 12:28:21 +1100 (EST) Date: Wed, 7 Nov 2001 12:28:21 +1100 From: Alan Kent To: interop@webdav.org, w3c-dist-auth@w3.org Message-ID: <20011107122821.C11145@io.mds.rmit.edu.au> References: <20011105113442.A16131@lyra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <20011105113442.A16131@lyra.org>; from Greg Stein on Mon, Nov 05, 2001 at 11:34:43AM -0800 Subject: Re: [Interop] quick poll on the Translate field] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5553 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I don't have a firm opinion on source vs translate (ie: we have not implemented it yet! :-), but I have been finding the 'source' arguments more convincing so I am leaning that way at present. Its also what is in the standard. ... > So, where should the source link(s) point to? The complete solution: > - a raw version of the url in question > and probably > - a menu vonfig page, where the current menu style is choosen (or the > menu program module??) > - the background gif > - the logo, if used > - any sub-dir logos, if used > - possible many more resources. > - if it's a database generated pag: possible pointers to the raw table > data, too. Well, I would say logos should not be included as they are not a part of the HTML resource (they would have separate URLs referenced via a I would assume). Since we are talking about Web resources identified by URLs, I think including other resources referenced by a resource ( or ) are out of scope. I am not sure what "possibly many more resources" would be, so I cannot comment on them. If its a database generated page (eg: content retrived from a database) then I would say that is out of scope. The database is not part of the script - it is referenced by the script. So from your above list, we are only left with - raw version of the URL in question (which I assume means raw version of the resource referenced by the URL in question) - a menu config page, where the current menu style is chosen > Instead, the translate header would just say: give me _this_ url, > untranslated. No questions what this means. One resource. No choice (no > power, too :). Easy to realize, consistent with the file system model, > and easy to explain to the user. So you are saying that it is not necessary to edit the 'menu config page'? If this is the case, then the source information would only be one URL. If you are saying its important to be able to edit all of the resources, then you are saying the translate header is not enough. As I think you are arguing against the source link, I think the point you are trying to make is that you would rather restrict the system to have exactly one 'source' resource behind a URL--that way you can use a 'translate' header with a single URL instead of allocating different URLs to all of the source resources behind a URL. This makes clients easier to write. But you also seem to be making a case that a single source resource behind a URL is actually insufficient, which is why there may be multiple source values. The problem with this is it makes tools harder to write as they have to deal with multiple sources. Proposal: How about introducing the concept of a single *primary* source. Simple tools can then access that one only, whereas more powerful tools can show the full list of sources. (Hopefully the URLs will make it clear enough what the sources are when there are multiple of them - eg by looking at file extensions on URLs.) To avoid changing the protocol, the first source returned could be said to be the primary source. If there is no such thing as a primary source, then the translate scheme wont work correctly anyway as it is based on the presumption that there is a single primary source for all web resources. Alan From w3c-dist-auth-request@w3.org Thu Nov 8 04:11: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 EAA21385 for ; Thu, 8 Nov 2001 04:11:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA11778; Thu, 8 Nov 2001 04:07:37 -0500 (EST) Resent-Date: Thu, 8 Nov 2001 04:07:37 -0500 (EST) Resent-Message-Id: <200111080907.EAA11778@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA11740 for ; Thu, 8 Nov 2001 04:07:26 -0500 (EST) Received: from munich.ixos.de (HOST.31.95.ixos.de [149.235.31.95]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA06224 for ; Thu, 8 Nov 2001 04:07:26 -0500 Received: from muc-imc.ixos.de (localhost [127.0.0.1]) by munich.ixos.de (8.9.3/8.9.3) with ESMTP id IAA18404; Thu, 8 Nov 2001 08:52:28 GMT Received: by muc-imc.ixos.de with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Nov 2001 10:07:30 +0100 Message-ID: From: Herbert Bock To: Herbert Bock , "'Fuller, Dan (ENW)'" , WebDAV Date: Thu, 8 Nov 2001 10:07: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: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5554 X-Loop: w3c-dist-auth@w3.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 clarified with Dan what he meant with additional parameters for PUT and GET. The point is: isn't it possible to extend the definition of PUT to also supply the MULTIPUT feature instead of defining a new method? I actually would also feel more comfortable with this solution but I'm not sure if this is possible? Is it? Regards, Herbert -----Original Message----- From: Herbert Bock [mailto:herbert.bock@ixos.de] Sent: Dienstag, 6. November 2001 12:31 To: 'Fuller, Dan (ENW)'; WebDAV Subject: RE: Ideas: GETSRC & MULTIPUT Hi Dan, could it be that you misunderstand the MULTIPUT as a PUT of more than one file? The MULTIPUT was meant as an atomic update of a resource and its related meta data. Regards, Herbert -----Original Message----- From: Fuller, Dan (ENW) [mailto:Dan.Fuller@enron.com] Sent: Montag, 5. November 2001 16:03 To: Herbert Bock; WebDAV Subject: RE: Ideas: GETSRC & MULTIPUT Am I the only one who gets queazy about MULTIPUT? We have well implemented DIR and COPY commands in DOS that accept multiple parameters. Why not just extend PUT and GET to accept multiple parameters? -----Original Message----- From: Herbert Bock [mailto:herbert.bock@ixos.de] Sent: Mon, November 05, 2001 4:41 AM To: WebDAV Subject: RE: Ideas: GETSRC & MULTIPUT Perhaps I'm a bit late with my comment but I just now read Jim's suggestions. Especially the MULTIPUT feature is one that I missed very very much when I recently read RFC2518 and tried to map the functionality of our systems to WebDAV. I think MULTIPUT is vital for many scenarios and it is quite easy to implement on the server side but extremely hard if not impossible on the client side. Please, please add this feature to WebDAV. I'm sure its desperately needed. And many thanks to Jim for triggering this. Regards, Herbert -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] Sent: Montag, 29. Oktober 2001 21:14 To: WebDAV Subject: Ideas: GETSRC & MULTIPUT I'm interested in the list's thoughts on two ideas for DAV improvements: The first is to introduce a GETSRC method to support access to the unprocessed source of a resource. This would decouple the dynamic response of a resource (GET) from its static source (GETSRC). The second is to introduce the MULTIPUT method to support "PUT with PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart MIME packages and atomically write them to the server. This would support the update of a resource and its metadata in one transaction. - Jim ********************************************************************** This e-mail is the property of Enron Corp. and/or its relevant affiliate and may contain confidential and privileged material for the sole use of the intended recipient (s). Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender or reply to Enron Corp. at enron.messaging.administration@enron.com and delete all copies of the message. This e-mail (and any attachments hereto) are not intended to be an offer (or an acceptance) and do not create or evidence a binding and enforceable contract between Enron Corp. (or any of its affiliates) and the intended recipient or any other party, and may not be relied on by anyone as the basis of a contract by estoppel or otherwise. Thank you. ********************************************************************** From w3c-dist-auth-request@w3.org Thu Nov 8 12:43:01 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 MAA02381 for ; Thu, 8 Nov 2001 12:43:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA14005; Thu, 8 Nov 2001 12:40:21 -0500 (EST) Resent-Date: Thu, 8 Nov 2001 12:40:21 -0500 (EST) Resent-Message-Id: <200111081740.MAA14005@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA13983 for ; Thu, 8 Nov 2001 12:40:02 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA15969 for ; Thu, 8 Nov 2001 12:40:01 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id JAA08709; Thu, 8 Nov 2001 09:43:48 -0800 (PST) From: "Jim Whitehead" To: "'Fuller, Dan \(ENW\)'" , "WebDAV" Date: Thu, 8 Nov 2001 09:35:55 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5555 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit My concern with re-using PUT is that existing servers typically take the request entity body and write it byte-for-byte into a file. They do *not* check to see if it is a multipart package, instead they happily write bytes, and return a 200 or 201 (the same codes a multipart-augmented PUT would return). So, I think overloading PUT would result in poor interoperability. - Jim PS - It's OK to define new methods. Sure, the method name space is flat. But, even if you limit method names to 10 characters, that's still 32^10 possible name combinations, of which we have used around 25. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Herbert Bock > Sent: Thursday, November 08, 2001 1:07 AM > To: Herbert Bock; 'Fuller, Dan (ENW)'; WebDAV > Subject: RE: Ideas: GETSRC & MULTIPUT > > > I clarified with Dan what he meant with additional > parameters for PUT and GET. The point is: isn't it > possible to extend the definition of PUT to also supply > the MULTIPUT feature instead of defining a new method? > I actually would also feel more comfortable with this > solution but I'm not sure if this is possible? Is it? > > Regards, > Herbert > > > -----Original Message----- > From: Herbert Bock [mailto:herbert.bock@ixos.de] > Sent: Dienstag, 6. November 2001 12:31 > To: 'Fuller, Dan (ENW)'; WebDAV > Subject: RE: Ideas: GETSRC & MULTIPUT > > > Hi Dan, > > could it be that you misunderstand the MULTIPUT as a > PUT of more than one file? The MULTIPUT was meant as > an atomic update of a resource and its related meta > data. > > Regards, > Herbert > > -----Original Message----- > From: Fuller, Dan (ENW) [mailto:Dan.Fuller@enron.com] > Sent: Montag, 5. November 2001 16:03 > To: Herbert Bock; WebDAV > Subject: RE: Ideas: GETSRC & MULTIPUT > > > Am I the only one who gets queazy about MULTIPUT? We have well > implemented DIR and COPY commands in DOS that accept multiple > parameters. Why not just extend PUT and GET to accept multiple > parameters? > > -----Original Message----- > From: Herbert Bock [mailto:herbert.bock@ixos.de] > Sent: Mon, November 05, 2001 4:41 AM > To: WebDAV > Subject: RE: Ideas: GETSRC & MULTIPUT > > > Perhaps I'm a bit late with my comment but I just now read > Jim's suggestions. Especially the MULTIPUT feature is > one that I missed very very much when I recently read RFC2518 > and tried to map the functionality of our systems to WebDAV. > I think MULTIPUT is vital for many scenarios and it is > quite easy to implement on the server side but extremely > hard if not impossible on the client side. > > Please, please add this feature to WebDAV. I'm sure its > desperately needed. And many thanks to Jim for triggering > this. > > Regards, > Herbert > > -----Original Message----- > From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] > Sent: Montag, 29. Oktober 2001 21:14 > To: WebDAV > Subject: Ideas: GETSRC & MULTIPUT > > > I'm interested in the list's thoughts on two ideas for DAV improvements: > > The first is to introduce a GETSRC method to support access to the > unprocessed source of a resource. This would decouple the dynamic > response > of a resource (GET) from its static source (GETSRC). > > The second is to introduce the MULTIPUT method to support "PUT with > PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart > MIME > packages and atomically write them to the server. This would support the > update of a resource and its metadata in one transaction. > > - Jim > > > > ********************************************************************** > This e-mail is the property of Enron Corp. and/or its relevant > affiliate and > may contain confidential and privileged material for the sole use of the > intended recipient (s). Any review, use, distribution or disclosure by > others is strictly prohibited. If you are not the intended recipient (or > authorized to receive for the recipient), please contact the > sender or reply > to Enron Corp. at enron.messaging.administration@enron.com and delete all > copies of the message. This e-mail (and any attachments hereto) are not > intended to be an offer (or an acceptance) and do not create or evidence a > binding and enforceable contract between Enron Corp. (or any of its > affiliates) and the intended recipient or any other party, and may not be > relied on by anyone as the basis of a contract by estoppel or otherwise. > Thank you. > ********************************************************************** > From w3c-dist-auth-request@w3.org Thu Nov 8 14:03:51 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04235 for ; Thu, 8 Nov 2001 14:03:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA26644; Thu, 8 Nov 2001 14:01:57 -0500 (EST) Resent-Date: Thu, 8 Nov 2001 14:01:57 -0500 (EST) Resent-Message-Id: <200111081901.OAA26644@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA26619 for ; Thu, 8 Nov 2001 14:01:49 -0500 (EST) 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 OAA25445 for ; Thu, 8 Nov 2001 14:01:49 -0500 Received: from corp.enron.com (nahou-msmsw03p.corp.enron.com [192.168.110.110]) by postmaster.enron.com (8.10.1/8.10.1/external_corp-1.08) with ESMTP id fA8J1Z307708 for ; Thu, 8 Nov 2001 13:01:35 -0600 (CST) Received: from nahou-mscnx04p.corp.enron.com (unverified) by corp.enron.com (Content Technologies SMTPRS 4.2.1) with SMTP id ; Thu, 8 Nov 2001 13:01:34 -0600 Received: from NAHOU-MSDOG01V.corp.enron.com ([172.24.192.211]) by nahou-mscnx04p.corp.enron.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 8 Nov 2001 13:01:33 -0600 x-mimeole: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 8 Nov 2001 13:01:33 -0600 Message-ID: Thread-Topic: Ideas: GETSRC & MULTIPUT Thread-Index: AcFofGTxsQxSbj4CQE2mhB8pNeHEvgACskJQ From: "Fuller, Dan (ENW)" To: "Jim Whitehead" , "WebDAV" X-OriginalArrivalTime: 08 Nov 2001 19:01:33.0867 (UTC) FILETIME=[C89CAFB0:01C16887] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id OAA26619 Subject: RE: Ideas: GETSRC & MULTIPUT Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5556 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit OK. Sounds like a plan. Thanks for clarifying that. If we have that many names to play with, we could have a separate method for package size. ;) Just kidding, thanks again. -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] Sent: Thu, November 08, 2001 11:36 AM To: Fuller, Dan (ENW); WebDAV Subject: RE: Ideas: GETSRC & MULTIPUT My concern with re-using PUT is that existing servers typically take the request entity body and write it byte-for-byte into a file. They do *not* check to see if it is a multipart package, instead they happily write bytes, and return a 200 or 201 (the same codes a multipart-augmented PUT would return). So, I think overloading PUT would result in poor interoperability. - Jim PS - It's OK to define new methods. Sure, the method name space is flat. But, even if you limit method names to 10 characters, that's still 32^10 possible name combinations, of which we have used around 25. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Herbert Bock > Sent: Thursday, November 08, 2001 1:07 AM > To: Herbert Bock; 'Fuller, Dan (ENW)'; WebDAV > Subject: RE: Ideas: GETSRC & MULTIPUT > > > I clarified with Dan what he meant with additional > parameters for PUT and GET. The point is: isn't it > possible to extend the definition of PUT to also supply > the MULTIPUT feature instead of defining a new method? > I actually would also feel more comfortable with this > solution but I'm not sure if this is possible? Is it? > > Regards, > Herbert > > > -----Original Message----- > From: Herbert Bock [mailto:herbert.bock@ixos.de] > Sent: Dienstag, 6. November 2001 12:31 > To: 'Fuller, Dan (ENW)'; WebDAV > Subject: RE: Ideas: GETSRC & MULTIPUT > > > Hi Dan, > > could it be that you misunderstand the MULTIPUT as a > PUT of more than one file? The MULTIPUT was meant as > an atomic update of a resource and its related meta > data. > > Regards, > Herbert > > -----Original Message----- > From: Fuller, Dan (ENW) [mailto:Dan.Fuller@enron.com] > Sent: Montag, 5. November 2001 16:03 > To: Herbert Bock; WebDAV > Subject: RE: Ideas: GETSRC & MULTIPUT > > > Am I the only one who gets queazy about MULTIPUT? We have well > implemented DIR and COPY commands in DOS that accept multiple > parameters. Why not just extend PUT and GET to accept multiple > parameters? > > -----Original Message----- > From: Herbert Bock [mailto:herbert.bock@ixos.de] > Sent: Mon, November 05, 2001 4:41 AM > To: WebDAV > Subject: RE: Ideas: GETSRC & MULTIPUT > > > Perhaps I'm a bit late with my comment but I just now read > Jim's suggestions. Especially the MULTIPUT feature is > one that I missed very very much when I recently read RFC2518 > and tried to map the functionality of our systems to WebDAV. > I think MULTIPUT is vital for many scenarios and it is > quite easy to implement on the server side but extremely > hard if not impossible on the client side. > > Please, please add this feature to WebDAV. I'm sure its > desperately needed. And many thanks to Jim for triggering > this. > > Regards, > Herbert > > -----Original Message----- > From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] > Sent: Montag, 29. Oktober 2001 21:14 > To: WebDAV > Subject: Ideas: GETSRC & MULTIPUT > > > I'm interested in the list's thoughts on two ideas for DAV improvements: > > The first is to introduce a GETSRC method to support access to the > unprocessed source of a resource. This would decouple the dynamic > response > of a resource (GET) from its static source (GETSRC). > > The second is to introduce the MULTIPUT method to support "PUT with > PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart > MIME > packages and atomically write them to the server. This would support the > update of a resource and its metadata in one transaction. > > - Jim > > > > ********************************************************************** > This e-mail is the property of Enron Corp. and/or its relevant > affiliate and > may contain confidential and privileged material for the sole use of the > intended recipient (s). Any review, use, distribution or disclosure by > others is strictly prohibited. If you are not the intended recipient (or > authorized to receive for the recipient), please contact the > sender or reply > to Enron Corp. at enron.messaging.administration@enron.com and delete all > copies of the message. This e-mail (and any attachments hereto) are not > intended to be an offer (or an acceptance) and do not create or evidence a > binding and enforceable contract between Enron Corp. (or any of its > affiliates) and the intended recipient or any other party, and may not be > relied on by anyone as the basis of a contract by estoppel or otherwise. > Thank you. > ********************************************************************** > From w3c-dist-auth-request@w3.org Fri Nov 9 20:02:28 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 UAA01624 for ; Fri, 9 Nov 2001 20:02:28 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA13498; Fri, 9 Nov 2001 19:57:23 -0500 (EST) Resent-Date: Fri, 9 Nov 2001 19:57:23 -0500 (EST) Resent-Message-Id: <200111100057.TAA13498@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA13478 for ; Fri, 9 Nov 2001 19:57:17 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA30730 for ; Fri, 9 Nov 2001 19:57:17 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id RAA18333; Fri, 9 Nov 2001 17:01:17 -0800 (PST) From: "Jim Whitehead" To: , "WebDAV" Date: Fri, 9 Nov 2001 16:57:04 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5557 X-Loop: w3c-dist-auth@w3.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 have submitted draft-ietf-webdav-acl-07, the WebDAV Access Control Protocol, to the IETF for inclusion in the Internet Drafts directory. It should appear there in a few days. Big thanks are due to Julian Reschke, Stefan Eissing, Keith Wannamaker, Dylan Barrell, Tim Ellison, Lisa Dusseault, Greg Stein, and Geoff Clemm for their review of the -06 specification, and/or comments and suggestions on working drafts between -06 and -07. This specification can be found at: http://www.webdav.org/acl/ Specifically: Text: http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.txt PDF: http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.pdf Word (change tracking active): http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07-tracked.doc HTML: http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.htm - Jim From w3c-dist-auth-request@w3.org Fri Nov 9 20:13:13 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 UAA01697 for ; Fri, 9 Nov 2001 20:13:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA13906; Fri, 9 Nov 2001 20:08:55 -0500 (EST) Resent-Date: Fri, 9 Nov 2001 20:08:55 -0500 (EST) Resent-Message-Id: <200111100108.UAA13906@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA13882 for ; Fri, 9 Nov 2001 20:08:43 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA31411 for ; Fri, 9 Nov 2001 20:08:42 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id RAA20261 for ; Fri, 9 Nov 2001 17:12:45 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 9 Nov 2001 17:08:32 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Last Call: Access Control Protocol Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5558 X-Loop: w3c-dist-auth@w3.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 *** From June 21 to August 3, 2001, the WebDAV Working Group held a last call for comments period on the -06 version of the WebDAV Access Control Protocol. During the last call period, several working group members performed detailed reviews of the document. Their feedback has now been incorporated into the -07 version of the Access Control Protocol. Additionally, since the submission of the -06 version of the protocol specification, some early implementation experience indicated the need for a simple query mechanism to locate principals, since the use of hierarchy to organize principals was insufficient for large numbers of principals. Hence, the -07 version contains additional functionality not found in the -06 version that went through last call. Due to this, an additional, shorter last call period is being held to solicit review of the -07 specification. From the abstract of the -07 specification: 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 read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such as HTTP method invocations) by a given principal. I fully expect this to be the absolutely final call for comments from the WebDAV working group on the WebDAV Access Control Protocol, draft-ietf-webdav-acl-07, prior to sending it along to the IESG for approval. This last call for comments period begins immediately, and ends December 3, 2001, at midnight, US Pacific time. This allows over three 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-07.txt HTML: http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.htm PDF: http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.pdf Word (with change tracking active): http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07-tracked.doc At the end of the last call review period, a new draft may be issued. Depending on the scope of changes introduced between the -07 and -08 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 From w3c-dist-auth-request@w3.org Fri Nov 9 21:53: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 VAA03695 for ; Fri, 9 Nov 2001 21:53:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA26616; Fri, 9 Nov 2001 21:49:17 -0500 (EST) Resent-Date: Fri, 9 Nov 2001 21:49:17 -0500 (EST) Resent-Message-Id: <200111100249.VAA26616@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA26590 for ; Fri, 9 Nov 2001 21:49:06 -0500 (EST) 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 VAA05189 for ; Fri, 9 Nov 2001 21:49:06 -0500 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id fAA2mRk15111 for ; Fri, 9 Nov 2001 18:48:27 -0800 Received: from waka.ebuilt.net (IDENT:root@i142.ir.ebuilt.net [10.1.2.142]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id fAA2mQO15030; Fri, 9 Nov 2001 18:48:26 -0800 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id fAA2jhG01002; Fri, 9 Nov 2001 18:45:43 -0800 Date: Fri, 9 Nov 2001 18:45:43 -0800 From: "Roy T. Fielding" To: Jim Whitehead Cc: WebDAV Message-ID: <20011109184543.B935@waka.ebuilt.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: Last Call: Access Control Protocol Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5559 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Some general comments: 1) Why does every example use xmlns:D="DAV:"? That seems to be a pointless exercise in indirection that will ultimately lead to clients that parse on D:whatever instead of the actual spec. Besides, DAV itself is an xmlns that needs to be defined somewhere. If the goal is to simply show that it is possible, then only one or two of the examples should use the shorter short name. 2) This protocol has departed from the Web interface of access control being set on a per-method basis. The effect of this change is that access control will now have to be governed by both the Web server and whatever handler within the Web server is interpreting WebDAV methods, resulting in a pointless duplication of code (and effort, if the resource requires both forms be active). Eventually, someone will have to define an HTTP access control protocol. 3) The protocol does not differentiate between writing to a resource (PUT) and appending to a resource (POST), and thus cannot be used to control shared access for things like guest-books, log files, or collection-like bulletin-board resources. The first is a matter of editorial choice. The second prevents this protocol from being generally useful outside webdav. The third leads from the second. I don't think any of them would necessarily prevent it from becoming a proposed standard for WebDAV, but I wouldn't call it access control for the Web. ....Roy From w3c-dist-auth-request@w3.org Fri Nov 9 22:27:10 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 WAA04366 for ; Fri, 9 Nov 2001 22:27:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA29222; Fri, 9 Nov 2001 22:21:50 -0500 (EST) Resent-Date: Fri, 9 Nov 2001 22:21:50 -0500 (EST) Resent-Message-Id: <200111100321.WAA29222@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA29202 for ; Fri, 9 Nov 2001 22:21:44 -0500 (EST) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA07468 for ; Fri, 9 Nov 2001 22:21:40 -0500 Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by inet-mail3.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fAA3FnR09783; Fri, 9 Nov 2001 19:15:49 -0800 (PST) Received: from esedcarlaptop (dhcp-4op7-4op8-east-130-35-171-71.us.oracle.com [130.35.171.71]) by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id fAA3Lch29503; Fri, 9 Nov 2001 20:21:38 -0700 (MST) From: "Eric Sedlar" To: "Roy T. Fielding" , "Jim Whitehead" Cc: "WebDAV" Date: Fri, 9 Nov 2001 19:21:11 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20011109184543.B935@waka.ebuilt.net> Subject: RE: Last Call: Access Control Protocol Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5560 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit 1) I agree that the xmlns:D="DAV:" is kind of off-putting. "DAV:" is a URL with the "DAV:" protocol identifier, which is never used anywhere else, not another namespace. This is the way RFC2518 is defined, and I guess the goal was to define the shortest possible namespace URL for the "D" namespace prefix. You get used to it. 2) Are you complaining about the lack of mapping between the ACL privileges and HTTP methods? Would you be happier if it were specified that the "GET" method for example must be restricted by "DAV:read" and the "PUT" method must be restricted by "DAV:write"? This issue has come up before, and while I remember that there was some reason not to do so (because I think some HTTP methods may be restricted by different privileges depending on other context, e.g. POST), I'm not sure that's not a good reason to specify things for the methods that we do map. 3) POST is not necessarily appending to a resource. I consider it more of an "execute" command than anything else. I think access control in the scenarios you describe may well be constrained by server-defined privileges, and the general intent of the protocol is that this is what would be done. I can define privileges like "Sign GuestBook" for a particular resource if I want to restrict that. --Eric > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding > Sent: Friday, November 09, 2001 6:46 PM > To: Jim Whitehead > Cc: WebDAV > Subject: Re: Last Call: Access Control Protocol > > > Some general comments: > > 1) Why does every example use xmlns:D="DAV:"? That seems to be > a pointless > exercise in indirection that will ultimately lead to clients that > parse on D:whatever instead of the actual spec. Besides, DAV itself > is an xmlns that needs to be defined somewhere. If the goal is to > simply show that it is possible, then only one or two of the examples > should use the shorter short name. > > 2) This protocol has departed from the Web interface of access > control being > set on a per-method basis. The effect of this change is that access > control will now have to be governed by both the Web server > and whatever > handler within the Web server is interpreting WebDAV methods, > resulting > in a pointless duplication of code (and effort, if the resource > requires both forms be active). Eventually, someone will have to > define an HTTP access control protocol. > > 3) The protocol does not differentiate between writing to a > resource (PUT) > and appending to a resource (POST), and thus cannot be used to control > shared access for things like guest-books, log files, or > collection-like > bulletin-board resources. > > The first is a matter of editorial choice. The second prevents > this protocol > from being generally useful outside webdav. The third leads from > the second. > I don't think any of them would necessarily prevent it from becoming a > proposed standard for WebDAV, but I wouldn't call it access control for > the Web. > > ....Roy > > From w3c-dist-auth-request@w3.org Sat Nov 10 05:05: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 FAA25663 for ; Sat, 10 Nov 2001 05:05:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA19975; Sat, 10 Nov 2001 05:02:28 -0500 (EST) Resent-Date: Sat, 10 Nov 2001 05:02:28 -0500 (EST) Resent-Message-Id: <200111101002.FAA19975@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA19953 for ; Sat, 10 Nov 2001 05:02:18 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA31314 for ; Sat, 10 Nov 2001 05:02:17 -0500 Received: (qmail 13457 invoked by uid 0); 10 Nov 2001 10:01:46 -0000 Received: from pd9e51b38.dip.t-dialin.net (HELO lisa) (217.229.27.56) by mail.gmx.net (mp002-rz3) with SMTP; 10 Nov 2001 10:01:46 -0000 From: "Julian Reschke" To: "Roy T. Fielding" , "Jim Whitehead" Cc: "WebDAV" Date: Sat, 10 Nov 2001 11:01:39 +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) In-reply-to: <20011109184543.B935@waka.ebuilt.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Last Call: Access Control Protocol Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5561 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding > Sent: Saturday, November 10, 2001 3:46 AM > To: Jim Whitehead > Cc: WebDAV > Subject: Re: Last Call: Access Control Protocol > > > Some general comments: > > 1) Why does every example use xmlns:D="DAV:"? That seems to be > a pointless > exercise in indirection that will ultimately lead to clients that > parse on D:whatever instead of the actual spec. Besides, DAV itself > is an xmlns that needs to be defined somewhere. If the goal is to > simply show that it is possible, then only one or two of the examples > should use the shorter short name. I agree with the criticism to invent a new URI scheme in the first place. But this happened three years ago (RFC2518), not for ACL. It's true that is just one of many representations, but the fact that RFC2518 (as well) always uses the same format doesn't seem to have produced non-interoperable clients. The requirement is to parse requests and responses using a namespace-aware XML processor. If you don't, you have a problem. If you do, you won't care at all about the XML serialisation format. Julian From w3c-dist-auth-request@w3.org Mon Nov 12 13:30: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 NAA14439 for ; Mon, 12 Nov 2001 13:30:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA16904; Mon, 12 Nov 2001 13:26:56 -0500 (EST) Resent-Date: Mon, 12 Nov 2001 13:26:56 -0500 (EST) Resent-Message-Id: <200111121826.NAA16904@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA16880 for ; Mon, 12 Nov 2001 13:26:45 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA11831 for ; Mon, 12 Nov 2001 13:26:46 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA26138 for ; Mon, 12 Nov 2001 10:31:14 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Mon, 12 Nov 2001 10:26:33 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20011109184543.B935@waka.ebuilt.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Last Call: Access Control Protocol Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5562 X-Loop: w3c-dist-auth@w3.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) This protocol has departed from the Web interface of access > control being set on a per-method basis. The effect of this > change is that access control will now have to be governed > by both the Web server and whatever handler within the Web > server is interpreting WebDAV methods, resulting in a > pointless duplication of code (and effort, if the resource > requires both forms be active). Eventually, someone will have to > define an HTTP access control protocol. In a file-based Apache installation, reading a particular resource requires that GET is enabled, and that read permissions are set on a specific file. So, in stock Apache, the read operation is governed by both the "Web server" and the code interpreting the GET method. The DAV ACL protocol is the same. Our goal was to create an access control protocol for remote collaborative authoring of Web resources, not a remote Web server configuration protocol. There was room for consensus on the former, not on the latter. > 3) The protocol does not differentiate between writing to a > resource (PUT) and appending to a resource (POST), and > thus cannot be used to control shared access for things > like guest-books, log files, or collection-like bulletin > board resources. If you can identify a single DAV client that uses POST to append to a resource, I might consider this a valid case that should be accommodated by the protocol. At present, POST is almost exclusively used for forms submission and HTTP-tunneled RPCs of various types. We felt that each individual use of POST (i.e., each RPC scheme) would require one or more privileges to be defined for them. We didn't want to guess, a priori, as to which privileges they might need. - Jim From w3c-dist-auth-request@w3.org Tue Nov 13 07:12:07 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 HAA20661 for ; Tue, 13 Nov 2001 07:12:07 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA20702; Tue, 13 Nov 2001 07:09:41 -0500 (EST) Resent-Date: Tue, 13 Nov 2001 07:09:41 -0500 (EST) Resent-Message-Id: <200111131209.HAA20702@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA20672 for ; Tue, 13 Nov 2001 07:09:30 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA08885 for ; Tue, 13 Nov 2001 07:09:28 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20425; Tue, 13 Nov 2001 07:09:26 -0500 (EST) Message-Id: <200111131209.HAA20425@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 13 Nov 2001 07:09:26 -0500 Subject: I-D ACTION:draft-ietf-webdav-acl-07.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5563 X-Loop: w3c-dist-auth@w3.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-07.txt Pages : 59 Date : 12-Nov-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 read and modify access control lists that instruct a server whether to allow 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-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-acl-07.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-07.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: <20011112111951.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-acl-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-acl-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011112111951.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Tue Nov 13 13:19:13 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 NAA10060 for ; Tue, 13 Nov 2001 13:19:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA28279; Tue, 13 Nov 2001 13:17:28 -0500 (EST) Resent-Date: Tue, 13 Nov 2001 13:17:28 -0500 (EST) Resent-Message-Id: <200111131817.NAA28279@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA28241 for ; Tue, 13 Nov 2001 13:17:06 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA01375 for ; Tue, 13 Nov 2001 13:17:06 -0500 Received: (qmail 24435 invoked by uid 0); 13 Nov 2001 18:16:58 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp020-rz3) with SMTP; 13 Nov 2001 18:16:58 -0000 From: "Julian Reschke" To: , "WebDAV" Date: Tue, 13 Nov 2001 19:16:46 +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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5564 X-Loop: w3c-dist-auth@w3.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'd suggest to extend section 10 to make a few statements about content type and encoding of request/responses. In particular, - MUST support text/xml, (because it's what all examples have been using since RFC2518) - SHOULD accept application/xml, (because it makes more sense than text/xml) - when text/xml is used and the encoding is not US-ASCII, the charset MUST be declared in the content type (as per XML media types RFC2376), - the bodies MUST be encoded in UTF-8 or UTF-16. (because XML processors are not required to support anything else). (of course this is not really an ACL issue, but ACL would be the first WebDAV spec to clarify this). Julian > -----Original Message----- > From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of Jim > Whitehead > Sent: Saturday, November 10, 2001 1:57 AM > To: acl@webdav.org; WebDAV > Subject: [ACL] Access Control Protocol -07 submitted > > > I have submitted draft-ietf-webdav-acl-07, the WebDAV Access Control > Protocol, to the IETF for inclusion in the Internet Drafts directory. It > should appear there in a few days. > > Big thanks are due to Julian Reschke, Stefan Eissing, Keith Wannamaker, > Dylan Barrell, Tim Ellison, Lisa Dusseault, Greg Stein, and Geoff > Clemm for > their review of the -06 specification, and/or comments and suggestions on > working drafts between -06 and -07. > > This specification can be found at: > > http://www.webdav.org/acl/ > > Specifically: > > Text: > http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.txt > PDF: > http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.pdf > Word (change tracking active): > http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07-tracked.doc > HTML: > http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.htm > > - Jim > > _______________________________________________ > acl mailing list > acl@webdav.org > http://mailman.webdav.org/mailman/listinfo/acl > From w3c-dist-auth-request@w3.org Tue Nov 13 13:50: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 NAA12078 for ; Tue, 13 Nov 2001 13:50:40 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA00034; Tue, 13 Nov 2001 13:44:01 -0500 (EST) Resent-Date: Tue, 13 Nov 2001 13:44:01 -0500 (EST) Resent-Message-Id: <200111131844.NAA00034@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA00014 for ; Tue, 13 Nov 2001 13:43:52 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA04408 for ; Tue, 13 Nov 2001 13:43:52 -0500 Received: (qmail 2611 invoked by uid 0); 13 Nov 2001 18:43:21 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp010-rz3) with SMTP; 13 Nov 2001 18:43:21 -0000 From: "Julian Reschke" To: "Julian Reschke" , , "WebDAV" Date: Tue, 13 Nov 2001 19:43:14 +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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5565 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit OK, here's my attempt to clarify it: 10 XML PROCESSING 10.1 Request / response marshalling The XML media type rules as defined in [RFC2376] apply: Servers and clients MUST support the content type "text/xml". When this content type is used, the character set MUST be specified in the "charset" parameter unless the character set is "US-ASCII". Servers and clients also SHOULD accept the content type "application/xml". For this content type, the "charset" parameter is not required, but it is STRONGLY RECOMMENDED to specify it anyway. Request and response bodies MUST be encoded in one of the standard XML encodings ("UTF-8" or "UTF-16") . 10.2 Request / response parsing Implementations of this specification MUST support the XML element ignore rule, as specified in Section 23.3.2 of [RFC2518], and the WebDAV XML Namespace interpretation convention, described in Section 23.4 of [RFC2518]recommendation [REC-XML-NAMES]. Note that use of the DAV namespace is reserved for XML elements and property names defined in a standards-track or Experimental IETF RFC. > -----Original Message----- > From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of > Julian Reschke > Sent: Tuesday, November 13, 2001 7:17 PM > To: acl@webdav.org; WebDAV > Subject: content type for WebDAV request/response bodies, was: [ACL] > Access Control Protocol -07 submitted > > > Hi, > > I'd suggest to extend section 10 to make a few statements about > content type > and encoding of request/responses. > > In particular, > > - MUST support text/xml, > > (because it's what all examples have been using since RFC2518) > > - SHOULD accept application/xml, > > (because it makes more sense than text/xml) > > - when text/xml is used and the encoding is not US-ASCII, the charset MUST > be declared in the content type > > (as per XML media types RFC2376), > > - the bodies MUST be encoded in UTF-8 or UTF-16. > > (because XML processors are not required to support anything else). > > > (of course this is not really an ACL issue, but ACL would be the first > WebDAV spec to clarify this). > > Julian > > > -----Original Message----- > > From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of Jim > > Whitehead > > Sent: Saturday, November 10, 2001 1:57 AM > > To: acl@webdav.org; WebDAV > > Subject: [ACL] Access Control Protocol -07 submitted > > > > > > I have submitted draft-ietf-webdav-acl-07, the WebDAV Access Control > > Protocol, to the IETF for inclusion in the Internet Drafts directory. It > > should appear there in a few days. > > > > Big thanks are due to Julian Reschke, Stefan Eissing, Keith Wannamaker, > > Dylan Barrell, Tim Ellison, Lisa Dusseault, Greg Stein, and Geoff > > Clemm for > > their review of the -06 specification, and/or comments and > suggestions on > > working drafts between -06 and -07. > > > > This specification can be found at: > > > > http://www.webdav.org/acl/ > > > > Specifically: > > > > Text: > > http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.txt > > PDF: > > http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.pdf > > Word (change tracking active): > > http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07-tracked.doc > > HTML: > > http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.htm > > > > - Jim > > > > _______________________________________________ > > acl mailing list > > acl@webdav.org > > http://mailman.webdav.org/mailman/listinfo/acl > > > > _______________________________________________ > acl mailing list > acl@webdav.org > http://mailman.webdav.org/mailman/listinfo/acl > From w3c-dist-auth-request@w3.org Tue Nov 13 19:01: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 TAA22001 for ; Tue, 13 Nov 2001 19:01:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA21577; Tue, 13 Nov 2001 18:58:04 -0500 (EST) Resent-Date: Tue, 13 Nov 2001 18:58:04 -0500 (EST) Resent-Message-Id: <200111132358.SAA21577@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA21555 for ; Tue, 13 Nov 2001 18:57:55 -0500 (EST) Received: from lsmail.office.lightsurf.com (lsmail.office.lightsurf.com [204.30.31.25]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA08189 for ; Tue, 13 Nov 2001 18:57:55 -0500 Received: from urchin (urchin.office.lightsurf.com [10.10.10.133]) by lsmail.office.lightsurf.com (Mirapoint) with SMTP id AAN29091; Tue, 13 Nov 2001 15:57:48 -0800 (PST) Reply-To: From: "Adam Freeman" To: Date: Tue, 13 Nov 2001 15:57:50 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20011105113442.A16131@lyra.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: question about links Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5566 X-Loop: w3c-dist-auth@w3.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 Hello, I have a question for the webdav community about the link, src and dest elements as specified in RFC 2518. If I have a webdav server running and I want to make a reference to a jpeg image on the server, is this how I would go about it? --> PROPPATCH /aJpegImage.jpg HTTP/1.1 Connection: Keep-Alive Host: server:80 Content-Type: text/xml Content-Length: *** http://server/aJegImage.jpg http://server/referenceToAJpegImage.jpg Then, would the url http://server/referenceToAJpegImage.jpg return the image data at http://server/aJpegImage.jpg server-side or is this up to the client application?? From w3c-dist-auth-request@w3.org Fri Nov 16 15:53:09 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 PAA25077 for ; Fri, 16 Nov 2001 15:53:08 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA08745; Fri, 16 Nov 2001 15:42:03 -0500 (EST) Resent-Date: Fri, 16 Nov 2001 15:42:03 -0500 (EST) Resent-Message-Id: <200111162042.PAA08745@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA08724 for ; Fri, 16 Nov 2001 15:41:57 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA28085 for ; Fri, 16 Nov 2001 15:41:56 -0500 Received: (qmail 21860 invoked by uid 0); 16 Nov 2001 20:41:46 -0000 Received: from pd9535903.dip.t-dialin.net (HELO lisa) (217.83.89.3) by mail.gmx.net (mp002-rz3) with SMTP; 16 Nov 2001 20:41:46 -0000 From: "Julian Reschke" To: , "WebDAV" Date: Fri, 16 Nov 2001 21:41:43 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5567 X-Loop: w3c-dist-auth@w3.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 Below is an attempt to clarify the role of the DTD fragments: 19 APPENDICIES 19.1 WebDAV XML Document Type Definition Addendum All XML elements defined in this Document Type Definition (DTD) belong to the XML namespace "DAV:"DAV namespace. This DTD should be viewed as an addendum to the DTD provided in [RFC2518], section 23.1. Note that WebDAV messages must not be validated using the DTD, as WebDAV is based on XML namespaces, and the special WebDAV "element ignore" rule ([RFC2518], section 23.3.2) applies. The following transformations need to be applied to a WebDAV message before it can be validated using the DTD: - removal of all elements and attributes not defined in RFC2518 or this specification, - transformation of all remaining elements into elements in no namespace. > -----Original Message----- > From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of > Julian Reschke > Sent: Tuesday, November 13, 2001 7:43 PM > To: Julian Reschke; acl@webdav.org; WebDAV > Subject: RE: content type for WebDAV request/response bodies, was: [ACL] > Access Control Protocol -07 submitted > > > OK, here's my attempt to clarify it: > > 10 XML PROCESSING > > 10.1 Request / response marshalling > > The XML media type rules as defined in [RFC2376] apply: > Servers and clients MUST support the content type "text/xml". When this > content type is used, the character set MUST be specified in the "charset" > parameter unless the character set is "US-ASCII". > Servers and clients also SHOULD accept the content type "application/xml". > For this content type, the "charset" parameter is not required, but it is > STRONGLY RECOMMENDED to specify it anyway. > Request and response bodies MUST be encoded in one of the standard XML > encodings ("UTF-8" or "UTF-16") . > > 10.2 Request / response parsing > Implementations of this specification MUST support the XML element ignore > rule, as specified in Section 23.3.2 of [RFC2518], and the WebDAV XML > Namespace interpretation convention, described in Section 23.4 of > [RFC2518]recommendation [REC-XML-NAMES]. > Note that use of the DAV namespace is reserved for XML elements > and property > names defined in a standards-track or Experimental IETF RFC. > > > -----Original Message----- > > From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of > > Julian Reschke > > Sent: Tuesday, November 13, 2001 7:17 PM > > To: acl@webdav.org; WebDAV > > Subject: content type for WebDAV request/response bodies, was: [ACL] > > Access Control Protocol -07 submitted > > > > > > Hi, > > > > I'd suggest to extend section 10 to make a few statements about > > content type > > and encoding of request/responses. > > > > In particular, > > > > - MUST support text/xml, > > > > (because it's what all examples have been using since RFC2518) > > > > - SHOULD accept application/xml, > > > > (because it makes more sense than text/xml) > > > > - when text/xml is used and the encoding is not US-ASCII, the > charset MUST > > be declared in the content type > > > > (as per XML media types RFC2376), > > > > - the bodies MUST be encoded in UTF-8 or UTF-16. > > > > (because XML processors are not required to support anything else). > > > > > > (of course this is not really an ACL issue, but ACL would be the first > > WebDAV spec to clarify this). > > > > Julian > > > > > -----Original Message----- > > > From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On > Behalf Of Jim > > > Whitehead > > > Sent: Saturday, November 10, 2001 1:57 AM > > > To: acl@webdav.org; WebDAV > > > Subject: [ACL] Access Control Protocol -07 submitted > > > > > > > > > I have submitted draft-ietf-webdav-acl-07, the WebDAV Access Control > > > Protocol, to the IETF for inclusion in the Internet Drafts > directory. It > > > should appear there in a few days. > > > > > > Big thanks are due to Julian Reschke, Stefan Eissing, Keith > Wannamaker, > > > Dylan Barrell, Tim Ellison, Lisa Dusseault, Greg Stein, and Geoff > > > Clemm for > > > their review of the -06 specification, and/or comments and > > suggestions on > > > working drafts between -06 and -07. > > > > > > This specification can be found at: > > > > > > http://www.webdav.org/acl/ > > > > > > Specifically: > > > > > > Text: > > > http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.txt > > > PDF: > > > http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.pdf > > > Word (change tracking active): > > > http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07-tracked.doc > > HTML: > > http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.htm > > > > - Jim > > > > _______________________________________________ > > acl mailing list > > acl@webdav.org > > http://mailman.webdav.org/mailman/listinfo/acl > > > > _______________________________________________ > acl mailing list > acl@webdav.org > http://mailman.webdav.org/mailman/listinfo/acl > _______________________________________________ acl mailing list acl@webdav.org http://mailman.webdav.org/mailman/listinfo/acl From w3c-dist-auth-request@w3.org Sun Nov 18 11:02: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 LAA25867 for ; Sun, 18 Nov 2001 11:02:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA27515; Sun, 18 Nov 2001 11:00:15 -0500 (EST) Resent-Date: Sun, 18 Nov 2001 11:00:15 -0500 (EST) Resent-Message-Id: <200111181600.LAA27515@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA27464 for ; Sun, 18 Nov 2001 10:59:53 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA12048 for ; Sun, 18 Nov 2001 10:59:52 -0500 Received: (qmail 16242 invoked by uid 0); 18 Nov 2001 15:59:20 -0000 Received: from pd9535fda.dip.t-dialin.net (HELO lisa) (217.83.95.218) by mail.gmx.net (mp009-rz3) with SMTP; 18 Nov 2001 15:59:20 -0000 From: "Julian Reschke" To: , "WebDAV" Date: Sun, 18 Nov 2001 16:59:15 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0017_01C17052.5ACE4020" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5568 X-Loop: w3c-dist-auth@w3.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_0017_01C17052.5ACE4020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit OK, to verify my wording, I've done the following: 1) write an XSLT that extracts all XML examples from rfc2518.xml (needs an XSLT engine with the XSLT 1.1 xsl:document function), 2) write an XSLT that implements the transformation in my proposal (XSLT 1.0). Results (attached): 1) The RFC2518 DTD has an error in the keepalive element (at least according to MSXML). 2) Example 8.1.1 in RFC2518 (response) isn't wellformed. 3) Several DTD validation errors were found: 3a) in ordering of lockdiscovery child elements, 3b) in the examples in appendix C (which were supposed to fail). Question: so *do* we assume that child element ordering is relevant? In which case, the examples in RFC2518 should be fixed. Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Friday, November 16, 2001 9:42 PM > To: acl@webdav.org; WebDAV > Subject: RE: content type for WebDAV request/response bodies, was: [ACL] > Access Control Protocol -07 submitted > > > Below is an attempt to clarify the role of the DTD fragments: > > 19 APPENDICIES > 19.1 WebDAV XML Document Type Definition Addendum > All XML elements defined in this Document Type Definition (DTD) belong to > the XML namespace "DAV:"DAV namespace. This DTD should be viewed as an > addendum to the DTD provided in [RFC2518], section 23.1. > Note that WebDAV messages must not be validated using the DTD, as > WebDAV is > based on XML namespaces, and the special WebDAV "element ignore" rule > ([RFC2518], section 23.3.2) applies. > The following transformations need to be applied to a WebDAV > message before > it can be validated using the DTD: > - removal of all elements and attributes not defined in > RFC2518 or this > specification, > - transformation of all remaining elements into elements in > no namespace. > > > -----Original Message----- > > From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of > > Julian Reschke > > Sent: Tuesday, November 13, 2001 7:43 PM > > To: Julian Reschke; acl@webdav.org; WebDAV > > Subject: RE: content type for WebDAV request/response bodies, was: [ACL] > > Access Control Protocol -07 submitted > > > > > > OK, here's my attempt to clarify it: > > > > 10 XML PROCESSING > > > > 10.1 Request / response marshalling > > > > The XML media type rules as defined in [RFC2376] apply: > > Servers and clients MUST support the content type "text/xml". When this > > content type is used, the character set MUST be specified in > the "charset" > > parameter unless the character set is "US-ASCII". > > Servers and clients also SHOULD accept the content type > "application/xml". > > For this content type, the "charset" parameter is not required, > but it is > > STRONGLY RECOMMENDED to specify it anyway. > > Request and response bodies MUST be encoded in one of the standard XML > > encodings ("UTF-8" or "UTF-16") . > > > > 10.2 Request / response parsing > > Implementations of this specification MUST support the XML > element ignore > > rule, as specified in Section 23.3.2 of [RFC2518], and the WebDAV XML > > Namespace interpretation convention, described in Section 23.4 of > > [RFC2518]recommendation [REC-XML-NAMES]. > > Note that use of the DAV namespace is reserved for XML elements > > and property > > names defined in a standards-track or Experimental IETF RFC. > > > > > -----Original Message----- > > > From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of > > > Julian Reschke > > > Sent: Tuesday, November 13, 2001 7:17 PM > > > To: acl@webdav.org; WebDAV > > > Subject: content type for WebDAV request/response bodies, was: [ACL] > > > Access Control Protocol -07 submitted > > > > > > > > > Hi, > > > > > > I'd suggest to extend section 10 to make a few statements about > > > content type > > > and encoding of request/responses. > > > > > > In particular, > > > > > > - MUST support text/xml, > > > > > > (because it's what all examples have been using since RFC2518) > > > > > > - SHOULD accept application/xml, > > > > > > (because it makes more sense than text/xml) > > > > > > - when text/xml is used and the encoding is not US-ASCII, the > > charset MUST > > > be declared in the content type > > > > > > (as per XML media types RFC2376), > > > > > > - the bodies MUST be encoded in UTF-8 or UTF-16. > > > > > > (because XML processors are not required to support anything else). > > > > > > > > > (of course this is not really an ACL issue, but ACL would be the first > > > WebDAV spec to clarify this). > > > > > > Julian > > > > > > > -----Original Message----- > > > > From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On > > Behalf Of Jim > > > > Whitehead > > > > Sent: Saturday, November 10, 2001 1:57 AM > > > > To: acl@webdav.org; WebDAV > > > > Subject: [ACL] Access Control Protocol -07 submitted > > > > > > > > > > > > I have submitted draft-ietf-webdav-acl-07, the WebDAV Access Control > > > > Protocol, to the IETF for inclusion in the Internet Drafts > > directory. It > > > > should appear there in a few days. > > > > > > > > Big thanks are due to Julian Reschke, Stefan Eissing, Keith > > Wannamaker, > > > > Dylan Barrell, Tim Ellison, Lisa Dusseault, Greg Stein, and Geoff > > > > Clemm for > > > > their review of the -06 specification, and/or comments and > > > suggestions on > > > > working drafts between -06 and -07. > > > > > > > > This specification can be found at: > > > > > > > > http://www.webdav.org/acl/ > > > > > > > > Specifically: > > > > > > > > Text: > > > > http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.txt > > > > PDF: > > > > http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.pdf > > > > Word (change tracking active): > > > > > http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07-tracked.doc > > > HTML: > > > http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.htm > > > > > > - Jim > > > > > > _______________________________________________ > > > acl mailing list > > > acl@webdav.org > > > http://mailman.webdav.org/mailman/listinfo/acl > > > > > > > _______________________________________________ > > acl mailing list > > acl@webdav.org > > http://mailman.webdav.org/mailman/listinfo/acl > > > > _______________________________________________ > acl mailing list > acl@webdav.org > http://mailman.webdav.org/mailman/listinfo/acl > ------=_NextPart_000_0017_01C17052.5ACE4020 Content-Type: application/x-gzip; name="rfc2518-dtd-validation.tar.gz" Content-Disposition: attachment; filename="rfc2518-dtd-validation.tar.gz" Content-Transfer-Encoding: base64 H4sIAFrZ9zsAA+1d63fbNpbv1+ac/A+opmdru6b40sPSykozjjPdTNzmJN6ZdvbsB4qELDYUqSEp 28pk9m9fPPgmSEm2BMoJfn1YxOMCIHEvLh73At7PF46k6m1VaavtKfrvfu58s1soqqL0Op1vFIR+ j/xFISp5xr/1Hvrd1/vdfrej43BV0zvdb4Cy43owsQxCwwfgmz98WJvur9B2edSHM0Yv0PcGt9AP bM89b6ltpQWga3qW7d6ct5bhVDprgRfjZwCA0avhwvcWAGVwg+Gr89arl38btqLH1+etWRguhrJ8 d3fXnnqe6fmLtunN5Xe+9wc0Q7lFiBAygbf0TRg9x4GO7X7MBtHw17jMP6a2A4PxB5JtJGfDShkQ dd8cR3VB9WhPDF9G6W98Yz6SaSwjkxWExUwopTw3bLdt4nw4QbbCcrnGGzXirT3xDX/FvxWOPdll O66MjxD/4tyQuNB1DSG0026GH3HnHT9rmuEODDCR/2pT8l/RlLL813tC/vPA9vJ/artWYQxIJTvh Mcz0y8XC80NoOZ75UR6n7JfhRUxI8GPDKPK/1oD+11U7Zf2vL/ifB7bj//nSCW30wsJlUCkCfBgs PDcoqnczH07HeRWRDOum54ZIPYG+jOUCSZXPiEUFLpKlJiQypYSiDGKnipPiFNAN/VVNsmzawPQW EMs5eG86y8C+hVTGpXGb0QlXlMydb4cZEiS4psLyZjV+TMOCmeFD68BaRZS62q+aG2gKVaP9dvzz 9fU7GQk7oCkK+PWvhCaNeVamk+l4OCjXt3FAhiGe5lCWyP+zval/D9H/NJRMyH8OeKT+9wMW/j+U 9T/MnJaNhAaivBL63+GiwP/7UP/W8b+m6HqJ//ua4H8eeLz+VxQBB6P/5WRQvZpkmCHS4dboiVm6 D1NxshR2oUJacBHOxgpZDSM/12fx7tCrHr8xXAg+zO1whvPSsPV5Q3sOvWU4/i8XiW7Ubpw3Dtvw tXlIvVuXNs5Q7AsE3sL45xImtIbTM9WCmmFJ/aluSYY60aTOVDclRTEUc6AaA6vf26g8RuerSrdJ S3C6db0qplXdSYU6K7Bf0PEfD/57U//X6v96X8mM/woZ/xWx/sMFe1j/jSLfF3cEyXA/8e4Dcwbn RrIfSLO+H07sGxQpF0KNZTjz/GLoK1S7l2/R/4oR7w3X8uZyRsaJaUct8vy/F/V/7fpvv9cr8b8m 9H8uaHz9N97OfYDm/xBBwxA5dVrc++GfvftrrNWjvwCr9+DlSE5DK/S6etKJWKsv+RdjDsdv2m/a 4I03cwPPxXRJYGWpFWT3qEbGZNbO0vJSOyOqt6lcR9HBa8+f2JYFXXYd46xxN7RgYPr2IkTdewyu ZxAsA+gDy4MBcL0QzIxbCAzThEEAQg/TCVGapKYA1wz64arNeqesMrbUumvr6kNUvwBMIHSB4cbV vLU9x8BpAPR9z2+XKRfrU6Pap/Jfa0z/U7taWf8T+/9csGP9z3AcnEYWGtcTQZ7/G9H/eoqulvhf VQX/80Dj+t+j13+/Bi3wZ8PybePhCiCNfzU0fUg0B8sI69aX1cGgL6mapKjXan/Y0YaaKilnQ0Wp XMZcTxgvV9vBwjFWbmULCC7vDSSSIDA9x4EmJlpZ6lqCtDuSY6Dxin1KlqqeuXhxlGQPDRNHSbab BWwtOKc++tmehXPnSYnQPz9ehD5Iop0NtX4jEu3n66u3IJY3jxJqNzDEnx/1bwe6N7Ubf52u1q0s azM6uQLXsF4I70MZd8UNyqwVuSgZDI2bmqI+fVp9uq8rpjo/pe8YQThHms7UhlZNOVe4E6xOAeo+ bwxXGpwBZTDUusNuD/zl6rquAusLKAxQcmUqMQKJEShbNbH7K7ALpPN/vbn1v44u9n8bwjbz//zq X2HijyOxzhIv/YmFvyeBPP83sv6HmF2s/zeFbfi/tPpXEAHMCewm636lKWv1hHWH09UqZZt56CQT n50ZVqXJTOKqkmyi9xfMKMsKIls9rFIOWaphSTEsLkw88KtmFyUO6/vu6PsV587r09V96Wi6WhOd nUw+6T41ksVE42CQjP8K/rcZ+/+OVtL/9Y4Y/7lgu/0/LDJsd+pVbv5ttmKy5cLTiGGiwFgYt82g vTTtNrSW8v/BP+7oYGQyV8bzZg9xobhpX5lAKvJ/E/b/ilLa/9c7iuB/Hmhm/x9OLOO2HUzahucQ J1E0RA4gUs7Cil2s7Q4DPnyPrapyD7VPW2MOW8hSaqXWAa8N24EWeAUX0EVtNVdinVdgN8jI/7Om 7P8Z+p/WF/7/uOCR+l/R+HdLtW5jdVHof3tCgf+bsP9XsbOnov6nCP8fXPBo/595ZmaaMtcb2D9g n/3BBxcSm/nIhH1VbTrPEjpl8VN9AmBTwVR5NoBJv9pcP2Of/wGiAiypp3TOFKXOSH+9Vf6mZviw r1qdqQGlrgVNSdOsnjSFRjc2w4e9Cexs31Jm5ZiW9WxTeuH1cy0y8n/QnPwv7f/hP0L+c4CQ/7uX /0L0C9H/VBDLf61B+89+zv9rZP+lC/nPA9vLf2wNvVzgzfPCSIDT0JB/5Hbu73Syiores2sZvhXI n/RBu6vkLgSALHvysmD4R3Q0o2zxHce/pAZQb+w5+PsMjSQzaFgjOQlfk+29twKvbejg1tfkwlGM ihSWdckibdIwsvg8RwKK1VBUgwtvsfLtm1ko/YqFfGmRmK7kJgTi2PRrPEzS5fm/Gf8fGmP9TxX6 Hxfsav9nS+Z/mL0opjQx/MeYOo0TZg947sNsU711kqC+msoAXHju1LHNcOvaMf1QJNUBpDrANFzi OWMCgQUdGKIX4vmYjuGE0IdWu94zhtiROijE8r+HZH9D/v9Z/t/0rtj/4YJt5L/FkP9WYRnAYstz awMz1vjwoj6SrbJotxgSWQdvsY2VhTMUNv+topCxhJBhIeb/s/1t/673/66Wz/9rQv/jgu34P55x TODMuLU9v1IIfIRwYTg2mqycYNZLH2NmLFISHNkM8vzfyPxP6SgM/4/i/C8X7Hj8f4AC4IUz6Kda wHtN3nT8VzXwzicL3jZxh0enZyVlQGgDNYj5f4BmAIc0/qvC/pcLdjT+58+BifH/ySDP/82M/3qv dP5L08X+Dxc8fvwvsv7jhv+LzYd/Mf3fASj/X0Srfw35/+h3S/c/aWL854J9+v9NsmT9ggiXwAeF lP+bO/+hdcr3P4r7H/hgJ/yfbv5eMn02pLu/ZOMxPflxOYT3C9uHlkQjhIzgjTz/N6P/axpj/Bf7 f1ywM/7PYntZIHi+IeT5X29m/q/2S/yvi/0/LjgQ/mdMFYh64EDjFkr4APvJxAuCk5GcDROS49GA 96FvmKEEqY/qoH0fOOGOy1h7/3PG/lPro9+q3tWF/ScXjND3HqIu4AZTz59HnIvCioc4Pf9GVgeD gfzbh7fydZy+lZUcamv8/NnzZ4Qi4s7FMgRzGM4867yFvYK3gEzjv5Mk4C9RXwOIBLAt6IZ2uAJJ JYhztgBIUkouhKhz4hPnKNKcnbdcz4JHx59/OmmBMUlgLBbOSoqTBSCA+JKHXEJ8jjJLq5q6jBvy LYkyvcVqkxJS8iQHIrxhWYYf3nn+x/+JVkCDo/bpD//hhP+JxfIPx/+La4JkHM55a/i2MXEgwCLy vBXQSyxogigJfs1jOqLH5aOATAJz5nkBjEKisLsZdAFqEWqL4Zror+cPhxPD/NiiDXeX8wk+9ukt 3TAtFjjwFqJeQlZVkeBoAfrpzlsvyV2SyT/pm8EF5Ysma793NqrRNiXF9NLcUQvlUhPTt4KUm8wr YRQ3tW+WPqSdNKYVv3ISlHyIOQwC4waO/+7bIb4iLvo6zhINStOkX3yf1D+ub5wP94WIlOWZyznq /wCvd5+3/hVn+jfWw3KftkQfdRjTCI/SznIaLCdB6KMaScY0hH6+Jx3nWxYXzO6pSWDMkuOmxZTA nuBirnXsT9CSqOBQdeILbJeLgWvtv0rz/05XFet/XFCv///39Wuk/yP1H43ar369uP793SW5ERPJ kQ+/f7i+vAKtyF2WFVpIkx+lty3Ts7zJERzHdrOmv6PAN+PdwHhmgPLe+MZ8JOO4TFIrCItJUQp5 jobLtjmScXRy0CdbzL7KdOwJ71I/QnpNLrtURCd62ZHz1i2+P5P/d3wZ/Pr1v6z9p0b4X/j/5oOH 8T+ebNfKADobx30za7jE8j0c+xvO3BjQ9Dv5mlDD/zvbDFhn/9nN+f8U/M8T2/N/5hxNpQjInbXB TF48FLT1tQAsl/E52cKSMGWDydo7mUbr7oYaZRyNsPLLtQRGa+6NGkWuTyops32hyNVtemxz43uz Dr6tSAOq+O4ld/YbOrIvOLHPurDP+69vmoEfCZb8P9vxWbDt9D8dy/+OLvZ/uYCv/lfwgyz0v8ZR zf+7OwuyTv/r6WX+74j9Hy740vS/Sid0NLrGDx3Yl9YC9q9ZUhd2ykhm+7LDSajruDeGC8GHuR3O RnKle7tR7DQu8pIHR3KVG7m4bTV+5KJvXYwrupGbnqkW1AxL6k91SzLUiSZ1proZu5EzBla/x6Zf KK1021QaU13TkVzVM2guVpf6IlTLkvw/a+949W+D8/+9rP+nDpb/wv8HJ3DR/2Sh3h0qKvl/h0eB 1/G/oigl/hf6Hx8wv/+OTUHWy/9e6fv3VPH9eWDv8j+1CBNDwAGikv/5yf9Ov5OV/13K/0L/44Iv bf6fvdy3Yj6KoQ4GfUnVJEW9VvvDjjbUVEk5GyoKM8tIriabvSq4psBLer4amJ7j0DN+FSVVkstd 7luewKaE5eIEtjqj2C7bZXPFdhlrTQM8jP2r7g/foyA4G2p9boLg5+urtyDmzK1lQfHy8ZoCO12t W0G/nkrh5vKaIvCZarnmRos6QvHN5zXkP31afbqvJl3OXbwuvYb2Ff6Uq1OAusAbw5UGZ0AZDLXu sNsDf7m6ri60mnzdJexC3u6yuULePn4Nman/67zn//2y/i/Wf7iAy/pvZNQpFgAOD5X8z2/+r3aV LP/3xPyfI77k+X9R+cqo08WojXU2eb+D9wPf1S4nS1u8teL8oTqe9V4j1Z0RnFWuD/VLfSGnQFny X8H/crT/6ehqUf53VSH/uWB7+R9flF4p/NOb1AFjppWdWhXmUuUZX3FGW5zWjXJnmEqCcs2N8Imk TM5CUfqk8k1/GE6o4X9e9j9KP+f/r0/4XxP+f7ngIPQ/mjeYtA3PIZe80RA5gEgxCQsqTfnGMx28 9vyJbVnQzQ3g2ylWVZXYwTnU7VSRipvm9qOZsPl/t3cBbTf+9+n5bzH+cwGX8X+7MX0bjUGM/49E Nf/zs//Quhn+VxXK/+L8Fxfszf8H89Q82/6iYjemvAnD3Hup2idi74axN4YiA4rI3mFVtqMYMYwl 2HYNKTYVRBWbjAXqZXuNxEzjA7kDSeopnTNFYdlqVJlobGaZAfuq1ZkaUOpa0JQ0zepJU2h0Y8sM 2JvAzqZtKFWkZHhRsrfY3qeJwOZgy/8BX/nf6ZTlv9j/4wIh/0nojuW/EP1C9D8NMOT/zq8CWev/ W8nc/6eq1P5P+P/mgofJf3xz33KBdwtrR4I0GeXvAKbu69JrgkZyHD7y4dy7hcw0cRSVCRnKTb/B p41K/udo/9fvlfm/J9b/ueAg1v+jMw140X1i+NucY8ipdrtYSH94YcoAXHju1LHNcIMy4hdiwcD0 7QU+fDFG+Rcr376ZheBXrPAB03CB64VgAoEFHRiihng+pmA4IfSh1U6X/bN0ttkQYPB/L7oMkNv+ n561/1ep/z9NzP+44JD4P3+mKT7oo6/b/8vcA1qx+feFnNXZBxj8f7bj7b/1/t+y/p8o/+t9sf7P BQ/X/+Obu9fOANIrvjFb5m4Gz9wLnur1Sfqm383XgEr+56j/6/3M+W+V+n9ThP7PBYc2/heuA3+v Fc/flIZ/VQPvfLIMamPtN9L4hS6wGRj8P0AzgAbHf12M/xwhxv+vG5X8z3P8z63/Rfwv5v9ccODj /8X68V9M/x+DEv9fRKt/PMd/JXP/lxr5f+sL/ucBjv7f4mV0YQ1+QGDyP2//j3qZ//vi/j8u2CP/ y4KvDx+V/M9R/8/zf1fo/xwh+P/rRiX/6w35f6L831HE+M8Fwv/T141bw2kHs/2Wgbm93+1Wr/9p if93rUfO/ylIARD8zwN/+k6e2K48MYLZ82fPn/lzIE3BCRkKTvAIgAMD495zgT81ta56hgMBvA99 wwzRkEGcmQbt+8AJcdKp5wMb2C6gFJ4/s7znz76lBL63ARUUEup0tkUcDpGMYAwyw9D3Ns7lwhy5 4jAV1Y1QR79sNwTZfE2/1acD9hfZbRlrxn9N6yf8rxNbMFXvdcT+PxeMECO7AeKzOUB85Abnrcyi /J3e9vwbWR0MBvJvH97K13HaFk08fPXyb+ct9L9hK69CjDETjrxluFiGJXUCWJ6JbbikYBWEcH6e VR8Qr1vQDc9bKxi0gEzpfCdJIAh9ewEMdwWW7kfXu0MSxoFzlDRAgRYwQhQ/WYYwAJKEco0Q4YVj hBDMjdCcnbdOPv90kiPoe14Y06jII+N24CXMxcJZSXFsQKiM5Pg5JZnUaOp7c/D+9QWWlxFtUn8p WBgmTNKhWuEqAUKgWDguGb/Z1EbqM3mky6mf4+jU7TuJzjpyS9IQYzYSnfHlRp+DMEmVmMslIRn3 boZ7szRuaKai17dCIP60cRD275Yll3XsloTj7Z3kIdkRTkKQcKdNzxmHJSHE3W7yhF03JA/Eyi+l E9ufJfGkpnF0ZosoCfPmdkhSE/u7JJh8gPhHdsc6F0jNU5IgrPYmD8kHiM+FJ7Spmctn+jP1dBcH kB2t3EPm4HdCJIC02tRBMv1JSNGfvkn/0saSn1nHeQmZyJoweSb2mPgh4ouYe3Brzlv/QnkNR8IP R8f/bpFQ0t/PWzQ9g5MCiDvveeunk8+uZ6F8lEXx9l1EnMFqciKyxDTi0Uhl7/7KWDP+671+cv5H 13Xs/0fVxfyfDzBXorHrPAPw29VbcJkbyz7QIQaoGjgvgQxwhMFH312+vby6/OUapKMWOEpE8SmI pe4pIGPSKSCC9cUpiETNi1NCJxHVL45BmXYi9ZmkSY5SejwuVNSEVqGqIJwGHBHJV6ZMgsHl1bvr 3yuyk9LAUTK2gs+ACuUysTRNQjAXT/NVlkZeKDj607uLVy+vX7KaQxoKXv7Cyh29/9r8yVcBR3jI /pGVBkfUE0GjOThCQ9CPqA8E4Y/l94BC8xTyb8E3a+lnhnFwFI+RqCzGcMn85nE62sZTcET+npwC SvP481E8ZP94fEx7ayXpfMWjOlW2LKYLSAlxgTU1Z9Y7k6r2PeEyKvpCUasBR1gPQj030c3KxZMU xa6JVOI0RZI5qRaiGPcjpPaTGSjqxaZj+ESFxYrzt4ViUiL1Vae6F+4AWJvCTAfD4x8ZL41EkxfO +GIwzEQxSsIqHTiKNHJUSKzZRT/LFOOkbAZPslexeKrrM151VoC/i15DlRTXi1KciPB8WZmJRE2n zUwoalKVJxKbJSbTi42SUjFdlxBPRepTZCcnNSlz0xD0+ZOR7viExZWJCh932XwfI9FoZEJikZE/ p5fT8YuMfDRp07qDgICAgICAgICAgICAgICAgICAgICAgMBh4v8BX8TNoQBAAQA= ------=_NextPart_000_0017_01C17052.5ACE4020-- From w3c-dist-auth-request@w3.org Sun Nov 18 13:56:48 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 NAA27904 for ; Sun, 18 Nov 2001 13:56:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA06230; Sun, 18 Nov 2001 13:45:38 -0500 (EST) Resent-Date: Sun, 18 Nov 2001 13:45:38 -0500 (EST) Resent-Message-Id: <200111181845.NAA06230@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA06209 for ; Sun, 18 Nov 2001 13:45:28 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37184.rational.com [192.229.37.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA23845 for ; Sun, 18 Nov 2001 13:45:28 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Sun, 18 Nov 2001 13:44:20 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sun, 18 Nov 2001 13:44:20 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B104EC8597@SUS-MA1IT01> From: "Clemm, Geoff" To: acl@webdav.org, WebDAV Date: Sun, 18 Nov 2001 13:44:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: content type for WebDAV request/response bodies, was: [ACL] A ccess Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5569 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: To allow for extensiblity, the DeltaV protocol leaves the ordering of the children of top-level protocol elements undefined. In particular, instead of specifying a DTD, a statement of the form "at most one of the following nodes can appear as a child" is used. This is motivated by the observation that under extension, the order of the children will always be at most partially constrained. In particular, suppose an element, A, was defined to have children B and C. Now suppose there are two independent extensions, extension-X and extension-Y, that add new children to A. In particular, extension-X adds children D and E, and extenstion-Y adds children F and G. Even if extension-X requires the ordering to be B,D,E,C and extension-Y requires the ordering to be B,F,G,C, a client that wants to handle both extensions cannot count on a fixed order for the children of A (e.g. B,D,E,F,G,C and B,D,F,E,G,C are two of the many possibilities). So I would propose that we explicitly state that the order of different types of child elements for top level WebDAV protocol elements is undefined. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Question: so *do* we assume that child element ordering is relevant? In which case, the examples in RFC2518 should be fixed. Julian From w3c-dist-auth-request@w3.org Sun Nov 18 14: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 ESMTP id OAA28035 for ; Sun, 18 Nov 2001 14:15:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA07491; Sun, 18 Nov 2001 14:01:58 -0500 (EST) Resent-Date: Sun, 18 Nov 2001 14:01:58 -0500 (EST) Resent-Message-Id: <200111181901.OAA07491@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA07470 for ; Sun, 18 Nov 2001 14:01:50 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA25963 for ; Sun, 18 Nov 2001 14:01:49 -0500 Received: (qmail 31939 invoked by uid 0); 18 Nov 2001 19:01:18 -0000 Received: from pd9e51e63.dip.t-dialin.net (HELO lisa) (217.229.30.99) by mail.gmx.net (mp006-rz3) with SMTP; 18 Nov 2001 19:01:18 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , , "WebDAV" Date: Sun, 18 Nov 2001 20:01:14 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B104EC8597@SUS-MA1IT01> Importance: Normal Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5570 X-Loop: w3c-dist-auth@w3.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 Correct. This basically means that independant extensions of RFC2518 (say deltaV and ACL) would have to define a common DTD to make things work. As long as this is the case, the proposed validation mechanism should continue to work. As long as ACL uses DTD fragments as "normative", I think we still need to *properly* define what this actually means. I've seen clients freak out on perfectly "valid" server responses, just because the authors decided that they can "validate" against the WebDAV DTD. So this really needs to be sorted out. Julian > -----Original Message----- > From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of > Clemm, Geoff > Sent: Sunday, November 18, 2001 7:44 PM > To: acl@webdav.org; WebDAV > Subject: RE: content type for WebDAV request/response bodies, was: [ACL] > Access Control Protocol -07 submitted > > > To allow for extensiblity, the DeltaV protocol leaves the ordering > of the children of top-level protocol elements undefined. > In particular, instead of specifying a DTD, a statement of the > form "at most one of the following nodes can appear as a child" > is used. > > This is motivated by the observation that under extension, the > order of the children will always be at most partially constrained. > In particular, suppose an element, A, was defined to have children > B and C. Now suppose there are two independent extensions, > extension-X and extension-Y, that add new children to A. > In particular, extension-X adds children D and E, and extenstion-Y > adds children F and G. Even if extension-X requires the ordering > to be B,D,E,C and extension-Y requires the ordering to be B,F,G,C, > a client that wants to handle both extensions cannot count on a fixed > order for the children of A (e.g. B,D,E,F,G,C and B,D,F,E,G,C are > two of the many possibilities). > > So I would propose that we explicitly state that the order of > different types of child elements for top level WebDAV protocol > elements is undefined. > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > Question: so *do* we assume that child element ordering is relevant? In > which case, the examples in RFC2518 should be fixed. > > Julian > > _______________________________________________ > acl mailing list > acl@webdav.org > http://mailman.webdav.org/mailman/listinfo/acl > From w3c-dist-auth-request@w3.org Mon Nov 19 15:10: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 PAA21908 for ; Mon, 19 Nov 2001 15:10:39 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA28343; Mon, 19 Nov 2001 15:07:22 -0500 (EST) Resent-Date: Mon, 19 Nov 2001 15:07:22 -0500 (EST) Resent-Message-Id: <200111192007.PAA28343@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA28317 for ; Mon, 19 Nov 2001 15:07:16 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA30954 for ; Mon, 19 Nov 2001 15:07:16 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA04616 for ; Mon, 19 Nov 2001 12:07:21 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Mon, 19 Nov 2001 15:07:00 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FW: [Moderator Action] The bindings specification... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5572 X-Loop: w3c-dist-auth@w3.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 Caught by the spam filter. I have added to the accept2 list, so future emails from this address will go straight through. - Jim -----Original Message----- From: Peter Raymond [mailto:Peter.Raymond@merant.com] Sent: Friday, November 16, 2001 11:08 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] The bindings specification... Hi, I see that the WebDAV bindings protocol specification completed a last call for comments. Does anyone know the timeframe/schedule for getting this draft approved as a "Proposed Standard"? I am currently reading through this draft with some other folks from MERANT, we will also look at the open issues list etc. So we will probably have some input/comments on this specification in the next couple of weeks. Regards, -- Peter Raymond - MERANT Principal Architect (PVCS) Tel: +44 (0)1727 813362 Fax: +44 (0)1727 869804 mailto:Peter.Raymond@merant.com WWW: http://www.merant.com From w3c-dist-auth-request@w3.org Mon Nov 19 15:11:01 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 PAA21980 for ; Mon, 19 Nov 2001 15:11:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA28309; Mon, 19 Nov 2001 15:07:12 -0500 (EST) Resent-Date: Mon, 19 Nov 2001 15:07:12 -0500 (EST) Resent-Message-Id: <200111192007.PAA28309@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA28289 for ; Mon, 19 Nov 2001 15:06:59 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA30876 for ; Mon, 19 Nov 2001 15:06:59 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id MAA04532 for ; Mon, 19 Nov 2001 12:06:57 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Mon, 19 Nov 2001 15:06:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0191_01C1710B.C88EB860" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FW: [Moderator Action] Webdav .ASP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5571 X-Loop: w3c-dist-auth@w3.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_0191_01C1710B.C88EB860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Webdav .ASPCaught by the spam filter. I have added Mark's email address to the accept2 list, so future emails will go straight through. - Jim -----Original Message----- From: Mark.Payne@barclayscapital.com [mailto:Mark.Payne@barclayscapital.com] Sent: Friday, November 16, 2001 7:00 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Webdav .ASP Im having a problem with a webclient for uploading (PUT) and downloading(GET) files and folders to an IIS server. The problem is, the application runs great until it has to upload an ASP file(.asp). The status returned is just forbidden I've been around the block on this about ten times and cant find a way around it. Code in vb but have tried javascript also with same problem. Also can write to file on server if file is specified as a .txt URI. Little prolems that causing big fuss. Dim WinHttpReq As New WinHttp.WinHttpRequest Dim data() As Byte, bSuccess As Boolean, lStatus As Long Upload = False If gbGUI Then formMain.Display ("Upload File: " & sFilePath & "..") data() = ReadBinFile(sFilePath, bSuccess) On Error GoTo Err_H If Not bSuccess Then GoTo Err_H WinHttpReq.Open "PUT", sURL, False WinHttpReq.Send data() Mark Payne Platform Engineering, Barclay's Capital ' Office: +44 (0) 20 777 33352 ' Mobile: +44 (0) 77 6494 2751 * mark.payne@barclayscapital.com ------------------------------------------------------------------------ For more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. ------------------------------------------------------------------------ ------=_NextPart_000_0191_01C1710B.C88EB860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Webdav .ASP
Caught=20 by the spam filter. I have added Mark's email address to the accept2 = list, so=20 future emails will go straight through.
 
-=20 Jim
-----Original Message-----
From: = Mark.Payne@barclayscapital.com=20 [mailto:Mark.Payne@barclayscapital.com]
Sent: Friday, November = 16,=20 2001 7:00 AM
To: w3c-dist-auth@w3.org
Subject: = [Moderator=20 Action] Webdav .ASP

Im having a problem with a webclient for = uploading=20 (PUT) and downloading(GET) files and folders to an IIS server.  The = problem=20 is, the application runs great until it has to upload an ASP = file(.asp). =20 The status returned is just forbidden I've been around the block on this = about=20 ten times and cant find a way around it.  Code in vb but have tried = javascript also with same problem.  Also can write to file on = server if=20 file is specified as a .txt URI.  Little prolems that causing big=20 fuss.


    Dim WinHttpReq As New=20 WinHttp.WinHttpRequest
    Dim=20 data() As Byte, bSuccess As Boolean, lStatus As Long

    Upload =3D = False
    If gbGUI Then formMain.Display = ("Upload=20 File: " & sFilePath & "..")
   
   =20 data() =3D ReadBinFile(sFilePath, bSuccess)
   
On = Error GoTo=20 Err_H

    If Not bSuccess Then = GoTo=20 Err_H
    =
    WinHttpReq.Open "PUT", sURL, = False=20
    WinHttpReq.Send = data()=20


Mark Payne
Platform Engineering, Barclay's = Capital=20
' = Office:   +44 = (0) 20 777=20 33352
'=20 Mobile:  +44 = (0) 77 6494=20 2751
*  = mark.payne@barclayscapital.com=20





--------------------------------------------------------= ----------------
For=20 more information about Barclays Capital, please
visit our web site at = http://www.barcap.com.


Internet communications are not secure = and=20 therefore the Barclays
Group does not accept legal responsibility = for the=20 contents of this
message. Although the Barclays Group operates = anti-virus=20 programmes,
it does not accept responsibility for any damage = whatsoever that=20 is
caused by viruses being passed. Any views or opinions presented = are=20
solely those of the author and do not necessarily represent those of = the=20
Barclays Group. Replies to this email may be monitored by the = Barclays=20
Group for operational or business=20 reasons.

---------------------------------------------------------= ---------------
 ------=_NextPart_000_0191_01C1710B.C88EB860-- From w3c-dist-auth-request@w3.org Mon Nov 19 17:44:54 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 RAA01387 for ; Mon, 19 Nov 2001 17:44:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA05534; Mon, 19 Nov 2001 16:39:53 -0500 (EST) Resent-Date: Mon, 19 Nov 2001 16:39:53 -0500 (EST) Resent-Message-Id: <200111192139.QAA05534@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA04964 for ; Mon, 19 Nov 2001 16:38:41 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA10087 for ; Mon, 19 Nov 2001 16:38:39 -0500 Received: (qmail 16775 invoked by uid 0); 19 Nov 2001 21:32:40 -0000 Received: from pd9e519c7.dip.t-dialin.net (HELO lisa) (217.229.25.199) by mail.gmx.net (mp011-rz3) with SMTP; 19 Nov 2001 21:32:40 -0000 From: "Julian Reschke" To: Date: Mon, 19 Nov 2001 22:32:39 +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: <200111131209.HAA20425@ietf.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5573 X-Loop: w3c-dist-auth@w3.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 (copy of post to ). Hi. (1) RFC2518 (WebDAV) is based on XML + namespaces and has chosen to use the namespace name "DAV:" to identify it's elements. Note that "DAV:" *is* a properly registered URI scheme (see [1]) (2) The XML namespaces recommendation says that an XML namespace is identified by a URI reference as defined in RFC2396. (3) RFC2396 gives the following grammar for absolute URIs: absoluteURI = scheme ":" ( hier_part | opaque_part ) opaque_part = uric_no_slash *uric "DAV:" doesn't seem to be a valid "opaque_part", because "opaque_part" MUST start with "uric_no_slash", thus it may not be empty. (4) I became aware of this mismatch when trying to develop a RELAG NG schema for WebDAV. James Clark's JING validator rejects the namespace name "DAV:" as invalid URI. So this has become a real-world problem (maybe it was "just" academic before). I think this means that either RFC2396 or RFC2518 need to be fixed. Feedback appreciated. Julian [1] From w3c-dist-auth-request@w3.org Mon Nov 19 20:58:34 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 UAA05408 for ; Mon, 19 Nov 2001 20:58:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA21233; Mon, 19 Nov 2001 20:54:33 -0500 (EST) Resent-Date: Mon, 19 Nov 2001 20:54:33 -0500 (EST) Resent-Message-Id: <200111200154.UAA21233@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA21177 for ; Mon, 19 Nov 2001 20:54:17 -0500 (EST) 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 UAA15049 for ; Mon, 19 Nov 2001 20:54:17 -0500 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id fAK1rhE31461 for ; Mon, 19 Nov 2001 17:53:43 -0800 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id fAK1rgO31380; Mon, 19 Nov 2001 17:53:42 -0800 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id fAK1pR609326; Mon, 19 Nov 2001 17:51:27 -0800 Date: Mon, 19 Nov 2001 17:51:27 -0800 From: "Roy T. Fielding" To: Matt Timmermans Cc: "'Julian Reschke'" , w3c-dist-auth@w3.org Message-ID: <20011119175127.M8807@waka.ebuilt.net> References: <000401c17158$c8908620$d482a8c0@mt2k> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000401c17158$c8908620$d482a8c0@mt2k> User-Agent: Mutt/1.3.20i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5578 X-Loop: w3c-dist-auth@w3.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, Nov 19, 2001 at 07:17:46PM -0500, Matt Timmermans wrote: > Wow, that's annoying! > > It seems to me that fixing RFC2396 to allow an empty opaque_part would be > best, unless someone can recall any rationale for disallowing it in the > first place. It looks quite arbitrary. More arbitrary than defining a new URI scheme *and* using xmlns just to replace DAV: with D:? Just choose one, please. Why on earth would we want to change the definition of URI in 2396 to allow scheme: to be a valid URI? It isn't a valid URI. As you said, RFC 2518 was based on an early draft of XML namespaces, and it will need to be updated for that in any case (or stop using xmlns). ....Roy From w3c-dist-auth-request@w3.org Mon Nov 19 21:01:37 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 VAA05957 for ; Mon, 19 Nov 2001 21:01:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA21461; Mon, 19 Nov 2001 20:57:19 -0500 (EST) Resent-Date: Mon, 19 Nov 2001 20:57:19 -0500 (EST) Resent-Message-Id: <200111200157.UAA21461@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA21441 for ; Mon, 19 Nov 2001 20:57:13 -0500 (EST) 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 UAA15270 for ; Mon, 19 Nov 2001 20:57:13 -0500 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id fAK1uhS32435 for ; Mon, 19 Nov 2001 17:56:43 -0800 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id fAK1ugO32354; Mon, 19 Nov 2001 17:56:42 -0800 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id fAK1sG709336; Mon, 19 Nov 2001 17:54:16 -0800 Date: Mon, 19 Nov 2001 17:54:16 -0800 From: "Roy T. Fielding" To: Jim Whitehead Cc: w3c-dist-auth@w3.org Message-ID: <20011119175416.N8807@waka.ebuilt.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5579 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Just stop using xmlns in the WebDAV examples. No other changes are necessary. ....Roy From w3c-dist-auth-request@w3.org Mon Nov 19 21:50:54 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 VAA10240 for ; Mon, 19 Nov 2001 21:50:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA18433; Mon, 19 Nov 2001 20:10:51 -0500 (EST) Resent-Date: Mon, 19 Nov 2001 20:10:51 -0500 (EST) Resent-Message-Id: <200111200110.UAA18433@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA18397 for ; Mon, 19 Nov 2001 20:10:45 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA10998 for ; Mon, 19 Nov 2001 20:10:45 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id RAA21408; Mon, 19 Nov 2001 17:10:51 -0800 (PST) From: "Jim Whitehead" To: , "WebDAV" Date: Mon, 19 Nov 2001 17:10:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5576 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > 1) The RFC2518 DTD has an error in the keepalive element (at > least according to MSXML). OK -- how *should* this element be represented in DTD language? > 2) Example 8.1.1 in RFC2518 (response) isn't wellformed. Which is the offending element. This looks OK to me. > 3) Several DTD validation errors were found: > > 3a) in ordering of lockdiscovery child elements, > 3b) in the examples in appendix C (which were supposed to fail). > > Question: so *do* we assume that child element ordering is relevant? In > which case, the examples in RFC2518 should be fixed. It was certainly my and Yaron's position that the ordering rules of XML didn't apply when sending XML across the wire. That is, the ordering rules make sense when you're doing markup of documents, but do not when you're sending a set of protocol elements where semantically the order of arrival is not meaningful. However, reading through RFC 2518, it appears we never explicitly stated this. It is certainly implied in the fact that we do not require validity, but only well formedness. Well-formed XML does not necessarily adhere to the ordering given in a specific DTD. - Jim From w3c-dist-auth-request@w3.org Mon Nov 19 21:50:54 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 VAA10245 for ; Mon, 19 Nov 2001 21:50:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA18459; Mon, 19 Nov 2001 20:10:59 -0500 (EST) Resent-Date: Mon, 19 Nov 2001 20:10:59 -0500 (EST) Resent-Message-Id: <200111200110.UAA18459@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA18395 for ; Mon, 19 Nov 2001 20:10:45 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA10991 for ; Mon, 19 Nov 2001 20:10:45 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id RAA21405; Mon, 19 Nov 2001 17:10:50 -0800 (PST) From: "Jim Whitehead" To: , "WebDAV" Date: Mon, 19 Nov 2001 17:10:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5577 X-Loop: w3c-dist-auth@w3.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 seems reasonable to me to add this text. I'd also go further, and explicitly note that validating requests and responses is generally a bad idea. IETF protocols should be strict in what they send, liberal in what they accept. Strict checking of a DAV message for validity is more stringent than is necessary to interpret the meaning of the message. It has been my experience that implementations that do require strict validity tend to be much less interoperable, since they tend to reject XML that most other implementations accept without any problem. This is why the DAV spec. has never required anything more than well formedness. - Jim > Below is an attempt to clarify the role of the DTD fragments: > > 19 APPENDICIES > > 19.1 WebDAV XML Document Type Definition Addendum > > All XML elements defined in this Document Type Definition (DTD) belong to > the XML namespace "DAV:"DAV namespace. This DTD should be viewed as an > addendum to the DTD provided in [RFC2518], section 23.1. > > Note that WebDAV messages must not be validated using the DTD, as > WebDAV is based on XML namespaces, and the special WebDAV "element > ignore" rule ([RFC2518], section 23.3.2) applies. > The following transformations need to be applied to a WebDAV > message before it can be validated using the DTD: > - removal of all elements and attributes not defined in > RFC2518 or this specification, > - transformation of all remaining elements into elements in > no namespace. > From w3c-dist-auth-request@w3.org Mon Nov 19 22:06: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 WAA10622 for ; Mon, 19 Nov 2001 22:06:57 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA16604; Mon, 19 Nov 2001 19:43:49 -0500 (EST) Resent-Date: Mon, 19 Nov 2001 19:43:49 -0500 (EST) Resent-Message-Id: <200111200043.TAA16604@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA16584 for ; Mon, 19 Nov 2001 19:43:42 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA07488 for ; Mon, 19 Nov 2001 19:43:42 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id QAA15998 for ; Mon, 19 Nov 2001 16:43:48 -0800 (PST) From: "Jim Whitehead" To: Date: Mon, 19 Nov 2001 16:43:25 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5575 X-Loop: w3c-dist-auth@w3.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 Julian Reschke writes: > I think this means that either RFC2396 or RFC2518 need to be fixed. As Julian pointed out in an off-list message, it is unlikely for all DAV applications to change just to add a (in this context) semantically meaningless "/" or "//" sequence of octets. So, changing RFC 2518 doesn't seem likely. On the other hand, Larry Masinter points out in another off-list message that the DAV URI scheme has rightly been criticized for being a flat namespace. So, attempts to chance RFC2396 to institutionalize what many perceive to be a poor design choice, is also likely to not be successful. Larry Masinter pointed out that adding some language to RFC 2396 pointing out that the DAV: URI scheme has some known quirks, and should not be considered as good example, might fly. Whether such text would then cause tools such as James Clark's JING validator to accept the DAV URI scheme is unclear. But, since WebDAV clients and servers are going to keep exchanging DAV: scheme URIs across the wire for the forseeable future, from my perspective the easiest change you can make to address your immediate problem, is to modify the JING validator tool. Frankly, compared to other items on the WebDAV plate, such as: * addressing all the items on the RFC 2518 issues list * finishing the bindings protocol * finishing DASL * finishing redirect references This issue comes in a *very* distant last. - Jim From w3c-dist-auth-request@w3.org Mon Nov 19 22:07: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 WAA10632 for ; Mon, 19 Nov 2001 22:06:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA15779; Mon, 19 Nov 2001 19:18:35 -0500 (EST) Resent-Date: Mon, 19 Nov 2001 19:18:35 -0500 (EST) Resent-Message-Id: <200111200018.TAA15779@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA15755 for ; Mon, 19 Nov 2001 19:18:26 -0500 (EST) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA05184 for ; Mon, 19 Nov 2001 19:18:26 -0500 Received: from mt2k (212.dhcp.ott.opentext.com [192.168.130.212]) by opentext.com (8.9.3/8.9.3) with SMTP id TAA08037; Mon, 19 Nov 2001 19:17:49 -0500 Reply-To: From: "Matt Timmermans" To: "'Julian Reschke'" , Date: Mon, 19 Nov 2001 19:17:46 -0500 Message-ID: <000401c17158$c8908620$d482a8c0@mt2k> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5574 X-Loop: w3c-dist-auth@w3.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 Wow, that's annoying! It seems to me that fixing RFC2396 to allow an empty opaque_part would be best, unless someone can recall any rationale for disallowing it in the first place. It looks quite arbitrary. Note that even if IETF changed the DAV namespace, you still couldn't write a meaningful schema for WebDAV, because schema languages don't recognize the odd naming convention that RFC2518 adopts in 23.4.2 (Meaning of Qualified Names). If anything is going to be done to change the basic XML structure of WebDAV, it would be a good time to fix 23.4.2 as well. What I really _don't_ want to see is everyone doing to get conformance to all 3 specs. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Monday, November 19, 2001 4:33 PM > To: w3c-dist-auth@w3.org > Subject: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > > (copy of post to ). > > Hi. > > (1) RFC2518 (WebDAV) is based on XML + namespaces and has > chosen to use the > namespace name "DAV:" to identify it's elements. Note that > "DAV:" *is* a > properly registered URI scheme (see [1]) > > (2) The XML namespaces recommendation says that an XML namespace is > identified by a URI reference as defined in RFC2396. > > (3) RFC2396 gives the following grammar for absolute URIs: > > absoluteURI = scheme ":" ( hier_part | opaque_part ) > opaque_part = uric_no_slash *uric > > "DAV:" doesn't seem to be a valid "opaque_part", because > "opaque_part" MUST > start with "uric_no_slash", thus it may not be empty. > > (4) I became aware of this mismatch when trying to develop a > RELAG NG schema > for WebDAV. James Clark's JING validator rejects the > namespace name "DAV:" > as invalid URI. So this has become a real-world problem > (maybe it was "just" > academic before). > > I think this means that either RFC2396 or RFC2518 need to be fixed. > > Feedback appreciated. > > Julian > > > [1] > From w3c-dist-auth-request@w3.org Tue Nov 20 03:15: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 DAA01858 for ; Tue, 20 Nov 2001 03:15:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA13057; Tue, 20 Nov 2001 03:11:49 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 03:11:49 -0500 (EST) Resent-Message-Id: <200111200811.DAA13057@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA13037 for ; Tue, 20 Nov 2001 03:11:32 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA17848 for ; Tue, 20 Nov 2001 03:11:31 -0500 Received: (qmail 1440 invoked by uid 0); 20 Nov 2001 08:11:00 -0000 Received: from pd9e519c7.dip.t-dialin.net (HELO lisa) (217.229.25.199) by mail.gmx.net (mp010-rz3) with SMTP; 20 Nov 2001 08:11:00 -0000 From: "Julian Reschke" To: "Jim Whitehead" , , "WebDAV" Date: Tue, 20 Nov 2001 09:11: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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5580 X-Loop: w3c-dist-auth@w3.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: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of Jim > Whitehead > Sent: Tuesday, November 20, 2001 2:10 AM > To: acl@webdav.org; WebDAV > Subject: RE: content type for WebDAV request/response bodies, was: [ACL] > Access Control Protocol -07 submitted > > > It seems reasonable to me to add this text. I'd also go further, and > explicitly note that validating requests and responses is generally a bad > idea. IETF protocols should be strict in what they send, liberal in what Well, it's not possible anyway, unless we have a proper definition of what this means for WebDAV. The DTD as it stands won't do it. > they accept. Strict checking of a DAV message for validity is > more stringent > than is necessary to interpret the meaning of the message. It has been my > experience that implementations that do require strict validity tend to be > much less interoperable, since they tend to reject XML that most other > implementations accept without any problem. This is why the DAV spec. has > never required anything more than well formedness. Well, XML does "draconian" error checking on accept, and this is one of the reasons *why* XML interoperability is quite good. The main point is to state the requirements clearly and early. From w3c-dist-auth-request@w3.org Tue Nov 20 03:21:18 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01964 for ; Tue, 20 Nov 2001 03:21:18 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA13340; Tue, 20 Nov 2001 03:18:51 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 03:18:51 -0500 (EST) Resent-Message-Id: <200111200818.DAA13340@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA13311 for ; Tue, 20 Nov 2001 03:18:36 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA18446 for ; Tue, 20 Nov 2001 03:18:36 -0500 Received: (qmail 5324 invoked by uid 0); 20 Nov 2001 08:18:05 -0000 Received: from pd9e519c7.dip.t-dialin.net (HELO lisa) (217.229.25.199) by mail.gmx.net (mp009-rz3) with SMTP; 20 Nov 2001 08:18:05 -0000 From: "Julian Reschke" To: "Jim Whitehead" , , "WebDAV" Date: Tue, 20 Nov 2001 09:18:07 +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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5581 X-Loop: w3c-dist-auth@w3.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: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of Jim > Whitehead > Sent: Tuesday, November 20, 2001 2:10 AM > To: acl@webdav.org; WebDAV > Subject: RE: content type for WebDAV request/response bodies, was: [ACL] > Access Control Protocol -07 submitted > > > > 1) The RFC2518 DTD has an error in the keepalive element (at > > least according to MSXML). > > OK -- how *should* this element be represented in DTD language? I'm not DTD expert, but in the worst case it would have to be "ANY". > > 2) Example 8.1.1 in RFC2518 (response) isn't wellformed. > > Which is the offending element. This looks OK to me. ~/dav-validation> saxon exmpl-8.1.1.f.2.xml ../identity.xslt Error on line 17 column 26 of file:/c:/reschke/dav-validation/exmpl-8.1.1.f.2.xml: Error reported by XML parser: undeclared name prefix in: R:DingALing Error on line 17 column 26 of file:/c:/reschke/dav-validation/exmpl-8.1.1.f.2.xml: Error reported by XML parser: undeclared name prefix in: R:DingALing Error on line 17 column 32 of file:/c:/reschke/dav-validation/exmpl-8.1.1.f.2.xml: Error reported by XML parser: undeclared name prefix in: R:Random Error on line 17 column 32 of file:/c:/reschke/dav-validation/exmpl-8.1.1.f.2.xml: Error reported by XML parser: undeclared name prefix in: R:Random Error XML Parsing failed Transformation failed: run-time errors were reported > > 3) Several DTD validation errors were found: > > > > 3a) in ordering of lockdiscovery child elements, > > 3b) in the examples in appendix C (which were supposed to fail). > > > > Question: so *do* we assume that child element ordering is relevant? In > > which case, the examples in RFC2518 should be fixed. > > It was certainly my and Yaron's position that the ordering rules of XML > didn't apply when sending XML across the wire. That is, the ordering rules > make sense when you're doing markup of documents, but do not when you're > sending a set of protocol elements where semantically the order of arrival > is not meaningful. However, reading through RFC 2518, it appears we never > explicitly stated this. It is certainly implied in the fact that we do not > require validity, but only well formedness. Well-formed XML does not > necessarily adhere to the ordering given in a specific DTD. You can't loosen the rules for XML validity (without stating them precisely and possibly giving them a different term). WebDAV messages can't be validated programatically, so well-formedness is all we have. We are having this discussion as I was trying to come up with a way how to turn the (by definition) non-normative DTD fragments into something that is actually usable (even if just for debugging). I agree that in WebDAV, element ordering *shouln't* matter. If this is the consensus, I'd try to rephrase my proposal so this is covered. In particular, the transformation algorithm would have to re-order elements (which requires some typing, but shouldn't be a problem). Yes, this is getting messy. Other approaches would be: - make sure that the specs work without the DTD fragments (I think deltav does), or - use a schema language that does what we need (I think XML Schema won't work either because of the ordering aspect, but RELAX NG might do it). Julian From w3c-dist-auth-request@w3.org Tue Nov 20 03:24:16 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 DAA02006 for ; Tue, 20 Nov 2001 03:24:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA13610; Tue, 20 Nov 2001 03:21:56 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 03:21:56 -0500 (EST) Resent-Message-Id: <200111200821.DAA13610@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA13510 for ; Tue, 20 Nov 2001 03:21:30 -0500 (EST) 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 DAA18853; Tue, 20 Nov 2001 03:21:30 -0500 Received: from lisa [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R); Tue, 20 Nov 2001 09:21:17 +0100 From: "Julian Reschke" To: , "'Julian Reschke'" , Cc: Date: Tue, 20 Nov 2001 09:21:17 +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: <000401c17158$c8908620$d482a8c0@mt2k> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MDRemoteIP: 192.168.1.2 X-Return-Path: julian.reschke@greenbytes.de Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5582 X-Loop: w3c-dist-auth@w3.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 Matt Timmermans > Sent: Tuesday, November 20, 2001 1:18 AM > To: 'Julian Reschke'; w3c-dist-auth@w3.org > Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > > Wow, that's annoying! > > It seems to me that fixing RFC2396 to allow an empty opaque_part would be > best, unless someone can recall any rationale for disallowing it in the > first place. It looks quite arbitrary. Yes, it does. > Note that even if IETF changed the DAV namespace, you still > couldn't write a > meaningful schema for WebDAV, because schema languages don't recognize the > odd naming convention that RFC2518 adopts in 23.4.2 (Meaning of Qualified > Names). That's on the list of known and resolved WebDAV issues. This section is going to be deleted. > If anything is going to be done to change the basic XML structure > of WebDAV, > it would be a good time to fix 23.4.2 as well. > > What I really _don't_ want to see is everyone doing xmlns:dp="DAV:p"> to get conformance to all 3 specs. That would be a mess. The only sane position is that the XML namespaces recommendation processing rules apply. From w3c-dist-auth-request@w3.org Tue Nov 20 03:38:18 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 DAA02122 for ; Tue, 20 Nov 2001 03:38:18 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA14014; Tue, 20 Nov 2001 03:36:01 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 03:36:01 -0500 (EST) Resent-Message-Id: <200111200836.DAA14014@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA13969 for ; Tue, 20 Nov 2001 03:35:37 -0500 (EST) 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 DAA20099; Tue, 20 Nov 2001 03:35:36 -0500 Received: from lisa [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R); Tue, 20 Nov 2001 09:35:13 +0100 From: "Julian Reschke" To: "Roy T. Fielding" , "Matt Timmermans" Cc: , Date: Tue, 20 Nov 2001 09:35:14 +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) In-Reply-To: <20011119175127.M8807@waka.ebuilt.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MDRemoteIP: 192.168.1.2 X-Return-Path: julian.reschke@greenbytes.de Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5583 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding > Sent: Tuesday, November 20, 2001 2:51 AM > To: Matt Timmermans > Cc: 'Julian Reschke'; w3c-dist-auth@w3.org > Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > > On Mon, Nov 19, 2001 at 07:17:46PM -0500, Matt Timmermans wrote: > > Wow, that's annoying! > > > > It seems to me that fixing RFC2396 to allow an empty > opaque_part would be > > best, unless someone can recall any rationale for disallowing it in the > > first place. It looks quite arbitrary. > > More arbitrary than defining a new URI scheme *and* using xmlns just to > replace DAV: with D:? Just choose one, please. Why on earth would we With all due respect, I think this shows a misunderstanding of the role of XML namespaces in WebDAV. There are a lot of reasons for WebDAV to use XML namespaces - it's not just a syntactic matter whether to write DAV:multistatus or D:multistatus. First of all, without namespace declaration, an element named DAV:multistatus wouldn't be NS-wellformed. In addition, - WebDAV messages can be extended with "arbitrary" new extension elements, preferrably from other namespaces (just like other XML applications do), - WebDAV has a resource property model where a property is identified by the pair (namespace, element name). So, having XML namespaces in WebDAV has really nothing to do with the syntax for the prefix. Of course I do agree that choosing "DAV:" as namespace name was a bad idea. > want to change the definition of URI in 2396 to allow > > scheme: > > to be a valid URI? It isn't a valid URI. (Side remark: good old Microsoft is even using namespace names like "xml:"). Not according to the current grammar, right. However, if you look at [1] you'll find that although TBL made his comments about the DAV: URI scheme himself, he didn't catch the greater problem if not being a URI at all. I think this says something about the *intent* of RFC2396 :-) > As you said, RFC 2518 was based on an early draft of XML namespaces, and > it will need to be updated for that in any case (or stop using xmlns). Again, this is on the list of known and resolved issues. [1] From w3c-dist-auth-request@w3.org Tue Nov 20 03:39: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 DAA02160 for ; Tue, 20 Nov 2001 03:39:14 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA14102; Tue, 20 Nov 2001 03:36:57 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 03:36:57 -0500 (EST) Resent-Message-Id: <200111200836.DAA14102@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA14068 for ; Tue, 20 Nov 2001 03:36:37 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA20192 for ; Tue, 20 Nov 2001 03:36:37 -0500 Received: (qmail 28050 invoked by uid 0); 20 Nov 2001 08:36:06 -0000 Received: from pd9e519c7.dip.t-dialin.net (HELO lisa) (217.229.25.199) by mail.gmx.net (mp001-rz3) with SMTP; 20 Nov 2001 08:36:06 -0000 From: "Julian Reschke" To: "Roy T. Fielding" , "Jim Whitehead" Cc: Date: Tue, 20 Nov 2001 09:36:07 +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) In-Reply-To: <20011119175416.N8807@waka.ebuilt.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5584 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding > Sent: Tuesday, November 20, 2001 2:54 AM > To: Jim Whitehead > Cc: w3c-dist-auth@w3.org > Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > > Just stop using xmlns in the WebDAV examples. No other changes are > necessary. Sorry, but *not* using XML namespaces would change the XML infoset of the messages, so we would have a 100% incompatible specification. From w3c-dist-auth-request@w3.org Tue Nov 20 06: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 ESMTP id GAA04124 for ; Tue, 20 Nov 2001 06:53:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA24112; Tue, 20 Nov 2001 06:45:06 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 06:45:06 -0500 (EST) Resent-Message-Id: <200111201145.GAA24112@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA24092 for ; Tue, 20 Nov 2001 06:45:00 -0500 (EST) 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 GAA06500 for ; Tue, 20 Nov 2001 06:45:00 -0500 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by www19.w3.org (8.9.0/8.9.0) with SMTP id GAA24086 for ; Tue, 20 Nov 2001 06:44:59 -0500 (EST) Received: (qmail 2679 invoked by uid 0); 20 Nov 2001 11:23:42 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp001-rz3) with SMTP; 20 Nov 2001 11:23:42 -0000 From: "Julian Reschke" To: "Jim Whitehead" , Date: Tue, 20 Nov 2001 12:23:42 +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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5585 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Tuesday, November 20, 2001 1:43 AM > To: w3c-dist-auth@w3.org > Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > ... > But, since WebDAV clients and servers are going to keep exchanging DAV: > scheme URIs across the wire for the forseeable future, from my perspective > the easiest change you can make to address your immediate problem, is to > modify the JING validator tool. I agree it's the easiest change. But this is just a workaround -- the problem stays. As long as the grammar for URIs says that "DAV:" isn't a URI, and the XML namespace REC says that a namespace name must be a syntactically correct URI reference, then we'll face the problem again -- for instance if developer's of XML processors decide to do proper namespace name checking. So this definitvely needs to be put onto the issues list. Julian From w3c-dist-auth-request@w3.org Tue Nov 20 11:22:09 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 LAA17730 for ; Tue, 20 Nov 2001 11:22:09 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA15227; Tue, 20 Nov 2001 11:16:27 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 11:16:27 -0500 (EST) Resent-Message-Id: <200111201616.LAA15227@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA15207 for ; Tue, 20 Nov 2001 11:16:21 -0500 (EST) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA22519 for ; Tue, 20 Nov 2001 11:16:22 -0500 Received: from mt2k (212.dhcp.ott.opentext.com [192.168.130.212]) by opentext.com (8.9.3/8.9.3) with SMTP id LAA12022 for ; Tue, 20 Nov 2001 11:15:51 -0500 Reply-To: From: "Matt Timmermans" To: "'WebDAV'" Date: Tue, 20 Nov 2001 11:15:48 -0500 Message-ID: <000201c171de$9e625f50$d482a8c0@mt2k> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5586 X-Loop: w3c-dist-auth@w3.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 > -----Original Message----- From: Jim Whitehead > From: Julian Reschke > > 1) The RFC2518 DTD has an error in the keepalive element (at > > least according to MSXML). > > OK -- how *should* this element be represented in DTD language? The closest you can get is (#PCDATA|href)* From w3c-dist-auth-request@w3.org Tue Nov 20 12:08:43 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 MAA20671 for ; Tue, 20 Nov 2001 12:08:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA21272; Tue, 20 Nov 2001 12:06:08 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 12:06:08 -0500 (EST) Resent-Message-Id: <200111201706.MAA21272@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA21251 for ; Tue, 20 Nov 2001 12:05:57 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA28450 for ; Tue, 20 Nov 2001 12:05:57 -0500 Received: (qmail 18035 invoked by uid 0); 20 Nov 2001 17:05:25 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp001-rz3) with SMTP; 20 Nov 2001 17:05:25 -0000 From: "Julian Reschke" To: "'WebDAV'" Date: Tue, 20 Nov 2001 18:05:25 +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: <000201c171de$9e625f50$d482a8c0@mt2k> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5587 X-Loop: w3c-dist-auth@w3.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 BTW: doesn't make sense here anyway, right? (property names aren't HREFs). > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Matt Timmermans > Sent: Tuesday, November 20, 2001 5:16 PM > To: 'WebDAV' > Subject: RE: content type for WebDAV request/response bodies, was: [ACL] > Access Control Protocol -07 submitted > > > > > -----Original Message----- > From: Jim Whitehead > > From: Julian Reschke > > > 1) The RFC2518 DTD has an error in the keepalive element (at > > > least according to MSXML). > > > > OK -- how *should* this element be represented in DTD language? > > The closest you can get is (#PCDATA|href)* > > From w3c-dist-auth-request@w3.org Tue Nov 20 12:39: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 MAA22642 for ; Tue, 20 Nov 2001 12:39:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA22851; Tue, 20 Nov 2001 12:33:55 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 12:33:55 -0500 (EST) Resent-Message-Id: <200111201733.MAA22851@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA22826 for ; Tue, 20 Nov 2001 12:33:49 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA02285 for ; Tue, 20 Nov 2001 12:33:48 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id JAA21118; Tue, 20 Nov 2001 09:33:50 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" , Date: Tue, 20 Nov 2001 09:33:30 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0099_01C171A6.6A348060" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FW: [Moderator Action] Webdav and php Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5588 X-Loop: w3c-dist-auth@w3.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_0099_01C171A6.6A348060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I'm also cc'ing the dav-dev mailing list. - Jim -----Original Message----- From: Michael Lam [mailto:mlam@tedis.com.au] Sent: Monday, November 19, 2001 8:22 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Webdav and php Hi, I am not sure if this is the right place for me to ask the following question, but I've decided to give it a try. Currently I am trying to use php for the webdav properties. I have set up apache in my local computer and php. The MKCOL and DELETE properties works fine. But I am having problem getting the PROPPATCH and PROFIND property to work in php. I have obtained a VB script and all the properties works fine with the VB script (thus, it create a new resource, set properties, remove properties, find the properties and delete resources). The following is the code I have written in php... ----------------------------------------- $socket = fsockopen ("127.0.0.1", 80); if ($socket < 0) { echo "socket() failed: reason: " . "\n"; } else { "socket() successful: " . "\n"; } /* PROPATCH - */ /* set or remove properties defined */ $r = htmlentities(""); $r .= htmlentities(""); $r .= htmlentities(""); $r .= htmlentities(""); $r .= htmlentities("ORDER"); $r .= htmlentities("OK"); $r .= htmlentities(""); $r .= htmlentities(""); $r .= htmlentities(""); $r .= htmlentities(""); $in = "PROPPATCH /webdisc/xyz.txt / HTTP/1.1\r\n"; $in .= "Host: localhost\r\n"; $in .= "Content-Type: text/plain\r\n"; $in .= "Content-Length: ". strlen($r) ."\r\n"; $in .= $r."\r\n"; /* PROPFIND */ /*$r = htmlentities(""); $r .= htmlentities(""); $r .= htmlentities(""); $r .= htmlentities(""); $in = "PROPFIND /webdisc/xyz.txt / HTTP/1.1\r\n"; $in .= "Host: localhost\r\n"; $in .= "Content-Type: text/plain\r\n"; $in .= "Content-Length: \r\n"; $in .= $r."\r\n";*/ $out = ''; fputs($socket, $in."\r\n"); while (!feof($socket)) { $out .= fread($socket, 4096); } fclose ($socket); ------------------------------------------ when I send the request with PROPPATCH property in php, it does not return me anything. When I use the VB script to set the property for a resource and then try to use php to send a PROPFIND, it return me the followings but without the xml containing the result I requested. TCP/IP Connection Attempting to connect to '127.0.0.1' on port 80... Request = PROPFIND /webdisc/xyz.txt / HTTP/1.1 Host: localhost Content-Type: text/plain Content-Length: Sending HTTP HEAD request... OK. Reading response: HTTP/1.1 207 Multi-Status Date: Tue, 20 Nov 2001 03:38:40 GMT Server: Apache/1.3.22 (Win32) DAV/1.0.3-dev Connection: close Content-Type: text/xml; charset="utf-8" /webdisc/xyz.txt Order 1234 New 2001-11-15T06:25:51Z 5599 Tue, 20 Nov 2001 02:58:02 GMT "0-15df-3bf9c6ba" text/plain HTTP/1.1 200 OK Closing socket...OK. thank you for your help. Michael ------=_NextPart_000_0099_01C171A6.6A348060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Accidentally caught by the spam filter. I'm = also cc'ing=20 the dav-dev mailing list.
 
-=20 Jim
-----Original Message-----
From: Michael Lam=20 [mailto:mlam@tedis.com.au]
Sent: Monday, November 19, 2001 = 8:22=20 PM
To: w3c-dist-auth@w3.org
Subject: [Moderator = Action]=20 Webdav and php

Hi,
 
I am not sure if this is the right = place for me to=20 ask the following question, but I've decided to give it a = try.
 
Currently I am trying to use php for = the webdav=20 properties. I have set up apache in my local computer and php. The MKCOL = and=20 DELETE properties works fine. But I am having problem getting the = PROPPATCH and=20 PROFIND property to work in php. I have obtained a VB = script and all=20 the properties works fine with the VB script (thus, it create a new = resource,=20 set properties, remove properties, find the properties and=20 delete resources). 
 
The following is the code I have = written in=20 php...
 
-----------------------------------------
 
$socket =3D fsockopen ("127.0.0.1", = 80);
 
if ($socket < 0) = {
    echo=20 "socket() failed: reason: " . "\n";
} else {
    = "socket()=20 successful: " . "\n";
}
 
   /* PROPATCH -=20 */
   /* set or remove properties defined = */
 $r =3D=20 htmlentities("<?xml version=3D1.0 encoding=3Dutf-8 = ?>");
 $r .=3D=20 htmlentities("<D:propertyupdate xmlns:D=3D'DAV:'=20 xmlns:Z=3D'http://www.tedis.com.au/'");
 $r .=3D=20 htmlentities("<D:set>");
 $r .=3D=20 htmlentities("<D:prop>");
 $r .=3D=20 htmlentities("<Z:Order>");
 $r .=3D=20 htmlentities("<Z:Type>ORDER</Z:Type>");
 $r .=3D=20 htmlentities("<Z:Status>OK</Z:Status>");
 $r .=3D=20 htmlentities("</Z:Order>");
 $r .=3D=20 htmlentities("</D:prop>");
 $r .=3D=20 htmlentities("</D:set>");
 $r .=3D=20 htmlentities("</D:propertyupdate>");
 $in =3D "PROPPATCH=20 /webdisc/xyz.txt / HTTP/1.1\r\n";
 $in .=3D "Host:=20 localhost\r\n";
 $in .=3D "Content-Type: = text/plain\r\n";
 $in .=3D=20 "Content-Length: ". strlen($r) ."\r\n";
 $in .=3D = $r."\r\n";
 
   /* PROPFIND=20 */
  /*$r =3D htmlentities("<?xml version=3D1.0 = encoding=3Dutf-8=20 ?>");
  $r .=3D htmlentities("<D:propfind=20 xmlns:D=3D'DAV:'>");
  $r .=3D=20 htmlentities("<D:allprop/>");
  $r .=3D=20 htmlentities("</D:propfind>");
  $in =3D "PROPFIND=20 /webdisc/xyz.txt / HTTP/1.1\r\n";
  $in .=3D "Host:=20 localhost\r\n";
  $in .=3D "Content-Type:=20 text/plain\r\n";
  $in .=3D "Content-Length:=20 \r\n";
  $in .=3D $r."\r\n";*/
 
$out =3D '';
 
fputs($socket, = $in."\r\n");
 
while (!feof($socket)) {
 $out = .=3D=20 fread($socket, 4096);
}
 
fclose ($socket);
------------------------------------------
 
when I send the request with PROPPATCH = property in=20 php, it does not return me anything.
 
When I use the VB script to set the = property for a=20 resource and then try to use php to send a PROPFIND, it return me the = followings=20 but without the xml containing the result I requested.
 

TCP/IP Connection

Attempting to connect to '127.0.0.1' on port=20 80...

Request =3D PROPFIND /webdisc/xyz.txt / HTTP/1.1 Host: = localhost=20 Content-Type: text/plain Content-Length: <?xml version=3D1.0 = encoding=3Dutf-8=20 ?><D:propfind=20 xmlns:D=3D'DAV:'><D:prop><T:Type/><T:Reference/><= T:Status/></D:prop></D:propfind>=20 Sending HTTP HEAD request...
OK.

Reading = response:
HTTP/1.1 207=20 Multi-Status Date: Tue, 20 Nov 2001 03:38:40 GMT Server: Apache/1.3.22 = (Win32)=20 DAV/1.0.3-dev Connection: close Content-Type: text/xml; = charset=3D"utf-8" /webdisc/xyz.txt=20 Order=20 1234 New = 2001-11-15T06:25:51Z=20 5599 Tue, 20 Nov = 2001=20 02:58:02 GMT = "0-15df-3bf9c6ba"=20 = text/plain=20 HTTP/1.1 200 OK=20 Closing socket...OK. =
 
thank you for your help.
 
Michael
------=_NextPart_000_0099_01C171A6.6A348060-- From w3c-dist-auth-request@w3.org Tue Nov 20 12:41: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 MAA22758 for ; Tue, 20 Nov 2001 12:41:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA23253; Tue, 20 Nov 2001 12:39:35 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 12:39:35 -0500 (EST) Resent-Message-Id: <200111201739.MAA23253@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA23233 for ; Tue, 20 Nov 2001 12:39:25 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA03017 for ; Tue, 20 Nov 2001 12:39:24 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id JAA22575 for ; Tue, 20 Nov 2001 09:39:27 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 20 Nov 2001 09:39:07 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Subject: XML in RFC 2518 section 8.1.1 example Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5589 X-Loop: w3c-dist-auth@w3.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 Wow, even knowing where to look, I still had to look twice. Yes, this is definitely an error -- we need to either move the xmlns declaration up into the response element, or add a second declaration of it. - Jim > > > 2) Example 8.1.1 in RFC2518 (response) isn't wellformed. > > > > Which is the offending element. This looks OK to me. > > ~/dav-validation> saxon exmpl-8.1.1.f.2.xml ../identity.xslt > Error on line 17 column 26 of > file:/c:/reschke/dav-validation/exmpl-8.1.1.f.2.xml: > Error reported by XML parser: undeclared name prefix in: R:DingALing > Error on line 17 column 26 of > file:/c:/reschke/dav-validation/exmpl-8.1.1.f.2.xml: > Error reported by XML parser: undeclared name prefix in: R:DingALing > Error on line 17 column 32 of > file:/c:/reschke/dav-validation/exmpl-8.1.1.f.2.xml: > Error reported by XML parser: undeclared name prefix in: R:Random > Error on line 17 column 32 of > file:/c:/reschke/dav-validation/exmpl-8.1.1.f.2.xml: > Error reported by XML parser: undeclared name prefix in: R:Random > Error > XML Parsing failed > Transformation failed: run-time errors were reported > From w3c-dist-auth-request@w3.org Tue Nov 20 13:45: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 NAA27829 for ; Tue, 20 Nov 2001 13:45:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA26514; Tue, 20 Nov 2001 13:42:18 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 13:42:18 -0500 (EST) Resent-Message-Id: <200111201842.NAA26514@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA26489 for ; Tue, 20 Nov 2001 13:42:08 -0500 (EST) 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 NAA12901 for ; Tue, 20 Nov 2001 13:42:08 -0500 Received: from [64.139.0.223] (HELO moose) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 12192601; Tue, 20 Nov 2001 10:39:29 -0800 From: "Lisa Dusseault" To: "Stefan Eissing" , "Jim Whitehead" , "Webdav WG" Date: Mon, 19 Nov 2001 22:39:33 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: RE: [ACL] Principal Identity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5590 X-Loop: w3c-dist-auth@w3.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 nice thing about allprop is that you get all the dead properties. > The bad thing about allprop is that you cannot see if a resource is > versioned/version or which methods it does support. How do you know you can get all the dead properties? 'allprop' as defined in RFC2518 seems to have to change, yet we've not clearly defined a new behaviour. In the meantime, I don't believe clients can rely on getting anything back in 'allprop' except the live properties defined in RFC2518. Lisa From w3c-dist-auth-request@w3.org Tue Nov 20 14:03: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 OAA29056 for ; Tue, 20 Nov 2001 14:03:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA28074; Tue, 20 Nov 2001 14:01:26 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 14:01:26 -0500 (EST) Resent-Message-Id: <200111201901.OAA28074@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA28024 for ; Tue, 20 Nov 2001 14:01:11 -0500 (EST) 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 OAA15547 for ; Tue, 20 Nov 2001 14:01:11 -0500 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id fAKJ0aE29665 for ; Tue, 20 Nov 2001 11:00:36 -0800 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id fAKJ0ZO29499; Tue, 20 Nov 2001 11:00:35 -0800 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id fAKIvsD01382; Tue, 20 Nov 2001 10:57:54 -0800 Date: Tue, 20 Nov 2001 10:57:54 -0800 From: "Roy T. Fielding" To: Julian Reschke Cc: Matt Timmermans , w3c-dist-auth@w3.org, uri@w3.org Message-ID: <20011120105754.B1306@waka.ebuilt.net> References: <20011119175127.M8807@waka.ebuilt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5591 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > > More arbitrary than defining a new URI scheme *and* using xmlns just to > > replace DAV: with D:? Just choose one, please. Why on earth would we > > With all due respect, I think this shows a misunderstanding of the role of > XML namespaces in WebDAV. There are a lot of reasons for WebDAV to use XML > namespaces - it's not just a syntactic matter whether to write > DAV:multistatus or D:multistatus. Well, that's the only example I've seen in use. > First of all, without namespace declaration, an element named > DAV:multistatus wouldn't be NS-wellformed. In addition, Should I take that to mean only namespaces can have ":" in the tag name? That would explain a lot. > - WebDAV messages can be extended with "arbitrary" new extension elements, > preferrably from other namespaces (just like other XML applications do), Yes, but those will presumably be in another (well-formed) namespace. > - WebDAV has a resource property model where a property is identified by the > pair (namespace, element name). Isn't it reasonable to have a default namespace in the property model? > So, having XML namespaces in WebDAV has really nothing to do with the syntax > for the prefix. I didn't say it did. I said that treating DAV: as both a namespace and a URI scheme is wrong (and confusing). The reasons for doing so at the time were because xmlns was being developed (slowly) at the same time as WebDAV. > Of course I do agree that choosing "DAV:" as namespace name was a bad idea. > > > want to change the definition of URI in 2396 to allow > > > > scheme: > > > > to be a valid URI? It isn't a valid URI. > > (Side remark: good old Microsoft is even using namespace names like "xml:"). > > Not according to the current grammar, right. Then it sounds to me like the xmlns attribute does not contain a URI. It contains a URI prefix. > However, if you look at [1] you'll find that although TBL made his comments > about the DAV: URI scheme himself, he didn't catch the greater problem if > not being a URI at all. I think this says something about the *intent* of > RFC2396 :-) Yeah, it says that we never considered that someone would try to use the grammar incorrectly within a specification. We naturally assume that people want the value to be a URI if they say it contans a URI. > > As you said, RFC 2518 was based on an early draft of XML namespaces, and > > it will need to be updated for that in any case (or stop using xmlns). > > Again, this is on the list of known and resolved issues. > > [1] I don't see that as being resolved, unless the WG is going to bite the bullet and follow Tim's recommendation. ....Roy From w3c-dist-auth-request@w3.org Tue Nov 20 14:46:31 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 OAA01624 for ; Tue, 20 Nov 2001 14:46:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA02026; Tue, 20 Nov 2001 14:44:19 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 14:44:19 -0500 (EST) Resent-Message-Id: <200111201944.OAA02026@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA01959 for ; Tue, 20 Nov 2001 14:44:04 -0500 (EST) 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 OAA26388; Tue, 20 Nov 2001 14:44:02 -0500 Received: from lisa [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R); Tue, 20 Nov 2001 20:43:09 +0100 From: "Julian Reschke" To: "Roy T. Fielding" Cc: "Matt Timmermans" , , Date: Tue, 20 Nov 2001 20:43:07 +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) In-Reply-To: <20011120105754.B1306@waka.ebuilt.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-MDRemoteIP: 192.168.1.2 X-Return-Path: julian.reschke@greenbytes.de Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5592 X-Loop: w3c-dist-auth@w3.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: Roy T. Fielding [mailto:fielding@ebuilt.com] > Sent: Tuesday, November 20, 2001 7:58 PM > To: Julian Reschke > Cc: Matt Timmermans; w3c-dist-auth@w3.org; uri@w3.org > Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > > .. > > > First of all, without namespace declaration, an element named > > DAV:multistatus wouldn't be NS-wellformed. In addition, > > Should I take that to mean only namespaces can have ":" in the tag name? > That would explain a lot. No. Colons in element names are allowed in XML 1.0 ([1]). Otherwise XML namespaces wouldn't have been possible (in the current syntactic form). However, if you use a namespace-aware XML processor, there are special rules once you put the a colon into an element name. These are expressed in the XML namespaces recommendation. Using "DAV:elementname" without declaring "DAV" as namespace prefix would have made WebDAV incompatible with XML + Namespaces. This would be a desaster, for instance we wouldn't have a defined XML Infoset for WebDAV messages ([2]). > > - WebDAV messages can be extended with "arbitrary" new > extension elements, > > preferrably from other namespaces (just like other XML applications do), > > Yes, but those will presumably be in another (well-formed) namespace. Yes. But to do so, the WebDAV message itself (unextended) needs to be NS-wellformed as well. > > - WebDAV has a resource property model where a property is > identified by the > > pair (namespace, element name). > > Isn't it reasonable to have a default namespace in the property model? Yes. That's why RFC2518-defined properties are in the DAV: namespace. > > So, having XML namespaces in WebDAV has really nothing to do > with the syntax > > for the prefix. > > I didn't say it did. I said that treating DAV: as both a namespace and a > URI scheme is wrong (and confusing). The reasons for doing so at the time > were because xmlns was being developed (slowly) at the same time > as WebDAV. May be. But then both the URI RFC and working drafts of XML namespaces had been around months earlier, and even the 1998 september version of XMLNS ([3]) speaks about the namespace being an URI. So this *could* have been noticed back then. The fact that it was only noticed a few days ago IMHO simply shows that what many people think is a valid URI just isn't true (according to the grammar). So maybe the grammar needs to be blamed (and updated). For instance, RFC2396++ could allow empty schema-specific parts, but the URI registration process could reject new URI schemes which allow empty scheme-specific parts. > > Of course I do agree that choosing "DAV:" as namespace name was > a bad idea. > > > > > want to change the definition of URI in 2396 to allow > > > > > > scheme: > > > > > > to be a valid URI? It isn't a valid URI. > > > > (Side remark: good old Microsoft is even using namespace names > like "xml:"). > > > > Not according to the current grammar, right. > > Then it sounds to me like the xmlns attribute does not contain a URI. > It contains a URI prefix. Well, the XML namespaces recommendation says it's a URI reference. RFC2518 uses "DAV:". RFC2396 says "DAV:" is not a valid URI reference. So the set of specs (RFC2396, RFC2518, XML/NS) is inconsistent right now. >... > > > As you said, RFC 2518 was based on an early draft of XML > namespaces, and > > > it will need to be updated for that in any case (or stop using xmlns). > > > > Again, this is on the list of known and resolved issues. > > > > [1] > > > I don't see that as being resolved, unless the WG is going to bite the > bullet and follow Tim's recommendation. Tim's recommendation was based on the fact that RFCs shouldn't *invent* URI schemes without compelling reason. At that point of time there already was a big number of RFC2518 based code, and "DAV:" already *was* a registered URI scheme. Back then I was saying to myself: "technically correct, but impractical to change". Now the situation is a bit different: using "DAV:" as namespace name is not only considered "bad practice", it's plain wrong. In a perfect world, the WebDAV WG could now just pick a better namespace name, everybody would be updating their servers and clients... But this isn't a perfect world, and I feel that we need a less intrusive solution. Regards, Julian [1] [2] [3] From w3c-dist-auth-request@w3.org Tue Nov 20 15:29:38 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03592 for ; Tue, 20 Nov 2001 15:29:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA01335; Tue, 20 Nov 2001 15:27:07 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 15:27:07 -0500 (EST) Resent-Message-Id: <200111202027.PAA01335@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA01306 for ; Tue, 20 Nov 2001 15:26:47 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA03410 for ; Tue, 20 Nov 2001 15:26:48 -0500 Received: (qmail 6187 invoked by uid 0); 20 Nov 2001 20:26:16 -0000 Received: from pd9535392.dip.t-dialin.net (HELO lisa) (217.83.83.146) by mail.gmx.net (mp020-rz3) with SMTP; 20 Nov 2001 20:26:16 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "Stefan Eissing" , "Jim Whitehead" , "Webdav WG" Date: Tue, 20 Nov 2001 21:26:13 +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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: [ACL] Principal Identity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5593 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lisa, I think that's a bit pessimistic. Neither deltaV nor ACL say anything about a behavorial change in PROPFIND for dead properties. I agree that better protocol over selection (exclude lists? by namespace?) might be nice. Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, November 20, 2001 7:40 AM > To: Stefan Eissing; Jim Whitehead; Webdav WG > Subject: RE: [ACL] Principal Identity > > > > > > The nice thing about allprop is that you get all the dead properties. > > The bad thing about allprop is that you cannot see if a resource is > > versioned/version or which methods it does support. > > How do you know you can get all the dead properties? 'allprop' as defined > in RFC2518 seems to have to change, yet we've not clearly defined a new > behaviour. In the meantime, I don't believe clients can rely on getting > anything back in 'allprop' except the live properties defined in RFC2518. > > Lisa > From w3c-dist-auth-request@w3.org Tue Nov 20 15:50: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 PAA04958 for ; Tue, 20 Nov 2001 15:50:39 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA02221; Tue, 20 Nov 2001 15:46:56 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 15:46:56 -0500 (EST) Resent-Message-Id: <200111202046.PAA02221@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA02197 for ; Tue, 20 Nov 2001 15:46:37 -0500 (EST) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA08028 for ; Tue, 20 Nov 2001 15:46:36 -0500 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id fAKKjB410417 for ; Tue, 20 Nov 2001 12:45:11 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id fAKKkHS00438 for ; Tue, 20 Nov 2001 12:46:17 -0800 (PST) Received: from [192.168.1.4] ([130.248.188.65]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GN49OO00.KQ4 for ; Tue, 20 Nov 2001 12:46:00 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj-v1.corp.adobe.com Message-Id: Date: Tue, 20 Nov 2001 12:33:58 -0800 To: w3c-dist-auth@w3.org From: Daniel Brotsky Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: another RFC issue: value of GETETAG property Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5594 X-Loop: w3c-dist-auth@w3.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 RFC says 13.6 getetag Property Name: getetag Namespace: DAV: Purpose: Contains the ETag header returned by a GET without accept headers. Description: The getetag property MUST be defined on any DAV compliant resource that returns the Etag header. Value: entity-tag ; defined in section 3.11 of [RFC2068] Unfortunately, the example in section 8.1.1 (page 27) says zzyzx which is not a valid etag. (Etags are quoted-strings, or quoted-strings preceded by the literal W/.) But fixing this example raises one of those classic "XML-ification" issues: should it be "zzyzx" or "zzyzx" and how about "zzyzx" Can we get this issue listed and can someone (I vote for Julian :^) resolve it and also explain to idiots like me where &-entities are required to be used, where they are allowed to be used, and what clients should do with them if their parser can't be told to do entity elimination??? Thanks! 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 Nov 20 16:08: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 QAA06082 for ; Tue, 20 Nov 2001 16:08:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA01253; Tue, 20 Nov 2001 16:07:17 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 16:07:17 -0500 (EST) Resent-Message-Id: <200111202107.QAA01253@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA01224 for ; Tue, 20 Nov 2001 16:07:07 -0500 (EST) 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 QAA10468 for ; Tue, 20 Nov 2001 16:07:07 -0500 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id fAKL6bd12253 for ; Tue, 20 Nov 2001 13:06:37 -0800 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id fAKL6aO12087; Tue, 20 Nov 2001 13:06:36 -0800 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id fAKL2pl01726; Tue, 20 Nov 2001 13:02:51 -0800 Date: Tue, 20 Nov 2001 13:02:51 -0800 From: "Roy T. Fielding" To: Julian Reschke Cc: Matt Timmermans , w3c-dist-auth@w3.org, uri@w3.org Message-ID: <20011120130251.F1306@waka.ebuilt.net> References: <20011120105754.B1306@waka.ebuilt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5595 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > Now the situation is a bit different: using "DAV:" as namespace name is not > only considered "bad practice", it's plain wrong. In a perfect world, the > WebDAV WG could now just pick a better namespace name, everybody would be > updating their servers and clients... But this isn't a perfect world, and I > feel that we need a less intrusive solution. How is making a normative change to an Internet Draft Standard a less intrusive change? I can rewrite all of the W3C's recommendations and pass them through that process faster than I can change 2396 and all of the implementations of URI references. In any case, I wouldn't change the definition of URI -- at most, the definition of URI-reference would change, and even then only if it were warranted by implementations that are believed to be correct. If the XML namespaces spec is broken, fix it. If it isn't broken, then fix WebDAV. Both of those communities are miniscule in comparison. What matters to URI is whether or not "DAV:" is believed to be a valid URI reference, and the fact is that it is not and therefore the standard for URI references should not be changed. XML namespaces needs to decide if the xmlns value is actually a URI-reference or something more like a URI prefix, and if the latter is true they should update that spec. Otherwise, WebDAV is broken and must be fixed on its own. That is the nature of one immature standard depending on other more mature standards for its specification. ....Roy From w3c-dist-auth-request@w3.org Tue Nov 20 16:19:43 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 QAA06443 for ; Tue, 20 Nov 2001 16:19:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA01674; Tue, 20 Nov 2001 16:17:46 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 16:17:46 -0500 (EST) Resent-Message-Id: <200111202117.QAA01674@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA01636 for ; Tue, 20 Nov 2001 16:17:24 -0500 (EST) 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 QAA11605; Tue, 20 Nov 2001 16:17:20 -0500 Received: from lisa [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R); Tue, 20 Nov 2001 22:16:20 +0100 From: "Julian Reschke" To: "Roy T. Fielding" Cc: "Matt Timmermans" , , Date: Tue, 20 Nov 2001 22:16:18 +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) In-Reply-To: <20011120130251.F1306@waka.ebuilt.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-MDRemoteIP: 192.168.1.2 X-Return-Path: julian.reschke@greenbytes.de Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5596 X-Loop: w3c-dist-auth@w3.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: Roy T. Fielding [mailto:fielding@ebuilt.com] > Sent: Tuesday, November 20, 2001 10:03 PM > To: Julian Reschke > Cc: Matt Timmermans; w3c-dist-auth@w3.org; uri@w3.org > Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > > .. > > How is making a normative change to an Internet Draft Standard a less > intrusive change? I can rewrite all of the W3C's recommendations and By relaxing the rules (why does the scheme-specific part have to be non-empty, besides common sense :-), (almost) nobody would be hurt. We can still discourage or even forbid *new* URI schemes with empty scheme-specific parts, but this wouldn't really affect anybody else. However, changing RFC2518 breaks *all* WebDAV clients and servers. Immediately. > pass them through that process faster than I can change 2396 and all > of the implementations of URI references. In any case, I wouldn't > change the definition of URI -- at most, the definition of URI-reference > would change, and even then only if it were warranted by implementations > that are believed to be correct. > > If the XML namespaces spec is broken, fix it. If it isn't broken, It isn't broken. > then fix WebDAV. Both of those communities are miniscule in comparison. > What matters to URI is whether or not "DAV:" is believed to be a valid URI > reference, and the fact is that it is not and therefore the standard > for URI references should not be changed. XML namespaces needs to decide > if the xmlns value is actually a URI-reference or something more like a > URI prefix, and if the latter is true they should update that spec. > Otherwise, WebDAV is broken and must be fixed on its own. That is the > nature of one immature standard depending on other more mature standards > for its specification. Technically correct. But extremely expensive and likely to be ignored by all major companies with existing code out there. So I don't think this is practical. If you insist that RFC2396 can't change and others insist that XNL namespaces can't change (I bet there'll be many!), then there are two possible outcomes: - The issue is ignored just like it was before. This is now a bit harder now that it's documented. - RFC2518++ is changed accordingly, and *all* software would need to be updated (basically throwing WebDAV back years). Whose choice is it, actually? Julian From w3c-dist-auth-request@w3.org Tue Nov 20 16: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 ESMTP id QAA07767 for ; Tue, 20 Nov 2001 16:52:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA02872; Tue, 20 Nov 2001 16:50:16 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 16:50:16 -0500 (EST) Resent-Message-Id: <200111202150.QAA02872@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA02844 for ; Tue, 20 Nov 2001 16:49:55 -0500 (EST) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA15639 for ; Tue, 20 Nov 2001 16:49:55 -0500 Received: from mt2k (212.dhcp.ott.opentext.com [192.168.130.212]) by opentext.com (8.9.3/8.9.3) with SMTP id QAA32070; Tue, 20 Nov 2001 16:49:21 -0500 Reply-To: From: "Matt Timmermans" To: "'Julian Reschke'" , "'WebDAV'" Date: Tue, 20 Nov 2001 16:49:16 -0500 Message-ID: <001901c1720d$344a4b30$d482a8c0@mt2k> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5597 X-Loop: w3c-dist-auth@w3.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 Appendix 23.4 provides an unambiguous interpretation of property names as HREFs. This will no longer apply when appendix 23.4 goes away. I've seen Microsoft use a convention for coding property names as HREFs that would work well for 2518: If the property's namespace ends in "/" or ":", then the property HREF is namespace+local_name, just like Today. Otherwise, the property HREF is namespace+"#"+local_name. WebDAV would have to codify this in the description of DAV:keepalive. This would at least be compatible with most current environments. Ideally, keepalive should be (allprop|prop), but that would break everybody. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Tuesday, November 20, 2001 12:05 PM > To: 'WebDAV' > Subject: RE: content type for WebDAV request/response bodies, > was: [ACL] > Access Control Protocol -07 submitted > > > BTW: > > doesn't make sense here anyway, right? (property names > aren't HREFs). > > > From w3c-dist-auth-request@w3.org Tue Nov 20 19:03:21 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 TAA11750 for ; Tue, 20 Nov 2001 19:03:20 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA10882; Tue, 20 Nov 2001 18:59:21 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 18:59:21 -0500 (EST) Resent-Message-Id: <200111202359.SAA10882@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA10854 for ; Tue, 20 Nov 2001 18:58:59 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA04117 for ; Tue, 20 Nov 2001 18:58:58 -0500 Received: (qmail 19782 invoked by uid 0); 20 Nov 2001 23:58:26 -0000 Received: from pd9535392.dip.t-dialin.net (HELO lisa) (217.83.83.146) by mail.gmx.net (mp006-rz3) with SMTP; 20 Nov 2001 23:58:26 -0000 From: "Julian Reschke" To: "Daniel Brotsky" , Date: Wed, 21 Nov 2001 00:58:26 +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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: another RFC issue: value of GETETAG property Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5598 X-Loop: w3c-dist-auth@w3.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 Daniel Brotsky > Sent: Tuesday, November 20, 2001 9:34 PM > To: w3c-dist-auth@w3.org > Subject: another RFC issue: value of GETETAG property > > > The RFC says > > 13.6 getetag Property > > Name: getetag > Namespace: DAV: > Purpose: Contains the ETag header returned by a GET without > accept headers. > Description: The getetag property MUST be defined on any DAV > compliant resource that returns the Etag header. > Value: entity-tag ; defined in section 3.11 of [RFC2068] > > > > Unfortunately, the example in section 8.1.1 (page 27) says > > > zzyzx > > > which is not a valid etag. (Etags are quoted-strings, or > quoted-strings preceded by the literal W/.) But fixing this example > raises one of those classic "XML-ification" issues: should it be > > "zzyzx" > > or > > "zzyzx" It doesn't matter. Same XML Infoset. > and how about > > "zzyzx" Same again. > Can we get this issue listed and can someone (I vote for Julian :^) > resolve it and also explain to idiots like me where &-entities are > required to be used, where they are allowed to be used, and what You don't need """, unless you are in the content of an attribute value which uses double quotes. > clients should do with them if their parser can't be told to do > entity elimination??? My XML parser resolves them for me (Xerces). Which parser do you use? Julian From w3c-dist-auth-request@w3.org Tue Nov 20 19: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 ESMTP id TAA12133 for ; Tue, 20 Nov 2001 19:14:12 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA11812; Tue, 20 Nov 2001 19:08:38 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 19:08:38 -0500 (EST) Resent-Message-Id: <200111210008.TAA11812@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA11788 for ; Tue, 20 Nov 2001 19:08:17 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA05099 for ; Tue, 20 Nov 2001 19:08:16 -0500 Received: (qmail 7534 invoked by uid 0); 21 Nov 2001 00:07:45 -0000 Received: from pd9535392.dip.t-dialin.net (HELO lisa) (217.83.83.146) by mail.gmx.net (mp005-rz3) with SMTP; 21 Nov 2001 00:07:45 -0000 From: "Julian Reschke" To: , "'WebDAV'" Date: Wed, 21 Nov 2001 01:07:45 +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: <001901c1720d$344a4b30$d482a8c0@mt2k> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5599 X-Loop: w3c-dist-auth@w3.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 Matt, > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Matt Timmermans > Sent: Tuesday, November 20, 2001 10:49 PM > To: 'Julian Reschke'; 'WebDAV' > Subject: RE: content type for WebDAV request/response bodies, was: [ACL] > Access Control Protocol -07 submitted > > > Appendix 23.4 provides an unambiguous interpretation of property names as > HREFs. This will no longer apply when appendix 23.4 goes away. The definition is broken. It doesn't work. See [1]. > I've seen Microsoft use a convention for coding property names as > HREFs that > would work well for 2518: No, it doesn't. > If the property's namespace ends in "/" or ":", then the property HREF is > namespace+local_name, just like Today. > > Otherwise, the property HREF is namespace+"#"+local_name. How do you encode the local name? Given an arbitrary URI, how do you select base URI and element name? ...and so on. It doesn't work. > WebDAV would have to codify this in the description of > DAV:keepalive. This > would at least be compatible with most current environments. I would care more if there is a single server implementation that actually implements keepalive. Is there? > Ideally, keepalive should be (allprop|prop), but that would break > everybody. Ideally, the whole behaviour of copying live/dead properties needs to be redefined, I think. Regards, Julian [1] From w3c-dist-auth-request@w3.org Tue Nov 20 19:56:37 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 TAA12973 for ; Tue, 20 Nov 2001 19:56:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA15283; Tue, 20 Nov 2001 19:54:05 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 19:54:05 -0500 (EST) Resent-Message-Id: <200111210054.TAA15283@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA15229 for ; Tue, 20 Nov 2001 19:53:39 -0500 (EST) Received: from toro.w3.mag.keio.ac.jp (postfix@toro.w3.mag.keio.ac.jp [133.27.228.201]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA09652; Tue, 20 Nov 2001 19:53:38 -0500 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 8EA2E7F434; Wed, 21 Nov 2001 09:53:09 +0900 (JST) Message-Id: <4.2.0.58.J.20011121093710.04c23720@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 21 Nov 2001 09:53:27 +0900 To: "Julian Reschke" , "Roy T. Fielding" From: Martin Duerst Cc: "Matt Timmermans" , , In-Reply-To: References: <20011120130251.F1306@waka.ebuilt.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5600 X-Loop: w3c-dist-auth@w3.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 22:16 01/11/20 +0100, Julian Reschke wrote: > > From: Roy T. Fielding [mailto:fielding@ebuilt.com] > > How is making a normative change to an Internet Draft Standard a less > > intrusive change? I can rewrite all of the W3C's recommendations and > >By relaxing the rules (why does the scheme-specific part have to be >non-empty, besides common sense :-), Very much for the reasons that Tim explained in his mails. An URI scheme is not something you define lightly, just for a single resource. Of course the restriction on 'at least one character' is technically very arbitrary, but I'm very sure that when the syntax was worked out, there was a clear feeling that having schemes without anything after them didn't make sense. The 'dav:' thingie is the only case we know so far, and we know it was a bad idea, so we know that the original rules were a good idea. In his mail, Tim didn't talk about the syntax because that's just a detail. If you don't get the principles right, you don't have to be surprised if you get the syntax wrong. >(almost) nobody would be hurt. We can >still discourage or even forbid *new* URI schemes with empty scheme-specific >parts, but this wouldn't really affect anybody else. > >However, changing RFC2518 breaks *all* WebDAV clients and servers. >Immediately. Well, I guess you should think about how to upgrade WebDAV to make this a workable update path. > > pass them through that process faster than I can change 2396 and all > > of the implementations of URI references. In any case, I wouldn't > > change the definition of URI -- at most, the definition of URI-reference > > would change, and even then only if it were warranted by implementations > > that are believed to be correct. > > > > If the XML namespaces spec is broken, fix it. If it isn't broken, > >It isn't broken. I agree. > > then fix WebDAV. Both of those communities are miniscule in comparison. > > What matters to URI is whether or not "DAV:" is believed to be a valid URI > > reference, and the fact is that it is not and therefore the standard > > for URI references should not be changed. XML namespaces needs to decide > > if the xmlns value is actually a URI-reference or something more like a > > URI prefix, and if the latter is true they should update that spec. > > Otherwise, WebDAV is broken and must be fixed on its own. That is the > > nature of one immature standard depending on other more mature standards > > for its specification. > >Technically correct. But extremely expensive and likely to be ignored by all >major companies with existing code out there. So I don't think this is >practical. What Roy is saying is that there are much more implementations out there that work with URIs than there are implementations that work with WebDAV. This is quite obvious. So he is saying that it's much easier to change WebDAV than URIs. There might be some slack here, in that most URI implementations do not actually check much of the URI syntax, because if they don't include scheme-specific knowledge (which a generic URI processor shouldn't), there is very few things that you can actually check. This may be supported by the fact that this is the first time this issue is comming up. >If you insist that RFC2396 can't change and others insist that XNL >namespaces can't change (I bet there'll be many!), then there are two >possible outcomes: > >- The issue is ignored just like it was before. This is now a bit harder now >that it's documented. >- RFC2518++ is changed accordingly, and *all* software would need to be >updated (basically throwing WebDAV back years). I suggest that for the short time, you ask James Clark to close an eye and tweak his implementation, and that for the longer term, you work on an upgrading strategy for WebDAV. Fixing WebDAV would now actually get rid of two problems, namely both the problem of unnecessary URI scheme registration and the problem of not conforming to URI syntax. So there is all the more motivation for doing it. It does not at all have to throw back WebDAV by years. Regards, Martin. From w3c-dist-auth-request@w3.org Tue Nov 20 20:10: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 UAA13360 for ; Tue, 20 Nov 2001 20:10:18 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA15944; Tue, 20 Nov 2001 20:07:07 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 20:07:07 -0500 (EST) Resent-Message-Id: <200111210107.UAA15944@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA15924 for ; Tue, 20 Nov 2001 20:06:48 -0500 (EST) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA10811 for ; Tue, 20 Nov 2001 20:06:43 -0500 Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id fAL17Ah25648 for ; Tue, 20 Nov 2001 17:07:10 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id fAL15F102179 for ; Tue, 20 Nov 2001 17:05:15 -0800 (PST) Received: from [192.168.1.4] ([130.248.188.65]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GN4LQ300.DGU; Tue, 20 Nov 2001 17:06:03 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj-v1.corp.adobe.com Message-Id: In-Reply-To: References: Date: Tue, 20 Nov 2001 17:04:38 -0800 To: "Julian Reschke" From: Daniel Brotsky Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: another RFC issue: value of GETETAG property Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5601 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Thanks, Julian!! (My parser does do entity-elimination by the way, but I just wanted to keep you talking long enough to clarify everything. :^) Lisa, Jim, can we add this issue as "resolved" and update the "current source" of the RFC to have the "zzyzx" form? dan At 12:58 AM +0100 11/21/01, Julian Reschke wrote: > > From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Daniel Brotsky >> Sent: Tuesday, November 20, 2001 9:34 PM >> To: w3c-dist-auth@w3.org >> Subject: another RFC issue: value of GETETAG property >> >> >> The RFC says >> >> 13.6 getetag Property >> >> Name: getetag >> Namespace: DAV: >> Purpose: Contains the ETag header returned by a GET without >> accept headers. >> Description: The getetag property MUST be defined on any DAV >> compliant resource that returns the Etag header. >> Value: entity-tag ; defined in section 3.11 of [RFC2068] >> >> >> >> Unfortunately, the example in section 8.1.1 (page 27) says >> >> >> zzyzx >> >> >> which is not a valid etag. (Etags are quoted-strings, or >> quoted-strings preceded by the literal W/.) But fixing this example >> raises one of those classic "XML-ification" issues: should it be >> >> "zzyzx" >> >> or >> >> "zzyzx" > >It doesn't matter. Same XML Infoset. > >> and how about >> >> "zzyzx" > >Same again. > >> Can we get this issue listed and can someone (I vote for Julian :^) >> resolve it and also explain to idiots like me where &-entities are >> required to be used, where they are allowed to be used, and what > >You don't need """, unless you are in the content of an attribute value >which uses double quotes. > >> clients should do with them if their parser can't be told to do >> entity elimination??? > >My XML parser resolves them for me (Xerces). Which parser do you use? > >Julian -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Tue Nov 20 21:35: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 VAA15741 for ; Tue, 20 Nov 2001 21:35:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA20381; Tue, 20 Nov 2001 21:29:35 -0500 (EST) Resent-Date: Tue, 20 Nov 2001 21:29:35 -0500 (EST) Resent-Message-Id: <200111210229.VAA20381@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA20343 for ; Tue, 20 Nov 2001 21:29:19 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA20114; Tue, 20 Nov 2001 21:29:19 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id SAA22236; Tue, 20 Nov 2001 18:29:25 -0800 (PST) From: "Jim Whitehead" To: , Date: Tue, 20 Nov 2001 18:29:01 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <4.2.0.58.J.20011121093710.04c23720@localhost> Importance: Normal Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5602 X-Loop: w3c-dist-auth@w3.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 Let me reconstruct how we got here. * WebDAV uses the "dav:" URI scheme for the name of XML elements used in protocol messages, and for the name of properties. * While the BNF for "dav:" URIs has never been explicitly defined (something we should do when we revise RFC 2518), if we had, its definition would be as follows: davuri = davscheme ":" davvalue davscheme = "dav" davvalue = opaque_part From RFC 2396 we know that the opaque_part is defined as: opaque_part = uric_no_slash *uric That is, the "dav:" URI scheme can be considered a member of the class of non-hierarchical URIs described on page 12 of RFC 2396. In particular, it was never the intent that just the string "dav:" would be considered a full URI. The string "dav:" is a URI scheme name, not a URI. The string "dav:" plus a string matching the production "opaque_part" is a URI. * WebDAV marshals "dav:" URIs that are the name of XML elements as a {namespace} + {opaque_part} pair. So, for example, "dav:creationdate" is . * The XML Namespace recommendation requires that the namespace identifier be a URI. * Since "dav:" scheme URIs are members of the class of non-hierarchical URIs, the only constant part is the URI scheme name itself, "dav:". From the definition of non-hierarchical URIs given in RFC 2396, ALL non-hierarchical URIs will share this quality. Since "dav:" is the only constant part, it is the only part of a "dav:" scheme URI suitable for use as the namespace identifier. To summarize: * The "dav:" URI scheme is perfectly legal according to RFC 2396. Therefore, no change is needed to RFC 2396. * It is only the use of the "dav:" URI scheme name as an namespace identifier that is violating any specification. Either RFC 2518 or the XML Namespaces specification could be changed to rectify this. In my opinion, it is natural to want to use the URI scheme name as the XML namespace identifier. That is: is more natural than: Not to mention that it uses fewer bytes on the wire (not a huge consideration these days, but those bytes add up over millions of daily users). As a result, I recommend that the XML namespace recommendation be modified to allow the use of just the URI scheme name as a namespace identifier, perhaps limited to just members of the set of non-hierarchical URIs. It seems clear to me that the XML namespace recommendation was written with only the class of hierarchical URIs in mind, and as a result it's not too surprising that a glitch arose in the first use with non-hierarchical URIs. Based on Julian's experience, and our experience with multiple WebDAV implementations, accepting a URI scheme name as a namespace identifier would codify existing, interoperable, practice. - Jim From w3c-dist-auth-request@w3.org Wed Nov 21 02:08:42 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 CAA05907 for ; Wed, 21 Nov 2001 02:08:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA06125; Wed, 21 Nov 2001 02:06:57 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 02:06:57 -0500 (EST) Resent-Message-Id: <200111210706.CAA06125@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA06089 for ; Wed, 21 Nov 2001 02:06:44 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA18226; Wed, 21 Nov 2001 02:06:44 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id CAA469382; Wed, 21 Nov 2001 02:03:32 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fAL76BK27496; Wed, 21 Nov 2001 02:06:11 -0500 To: Daniel Brotsky Cc: "Julian Reschke" , w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Wed, 21 Nov 2001 02:05:34 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V509_11062001 |November 6, 2001) at 11/21/2001 02:06:11 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: another RFC issue: value of GETETAG property Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5603 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << Lisa, Jim, can we add this issue as "resolved" and update the "current source" of the RFC to have the "zzyzx" form? >> Done. Labeled simply, ETAGS_ARE_QUOTED ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Nov 21 02:59:31 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 CAA06827 for ; Wed, 21 Nov 2001 02:59:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA09123; Wed, 21 Nov 2001 02:57:25 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 02:57:25 -0500 (EST) Resent-Message-Id: <200111210757.CAA09123@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA09084 for ; Wed, 21 Nov 2001 02:57:11 -0500 (EST) Received: from toro.w3.mag.keio.ac.jp (postfix@toro.w3.mag.keio.ac.jp [133.27.228.201]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA22338; Wed, 21 Nov 2001 02:56:51 -0500 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 7E69E7F434; Wed, 21 Nov 2001 16:55:47 +0900 (JST) Message-Id: <4.2.0.58.J.20011121154932.03cc1760@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 21 Nov 2001 15:52:01 +0900 To: Mark Baker , ejw@cse.ucsc.edu (Jim Whitehead) From: Martin Duerst Cc: w3c-dist-auth@w3.org, uri@w3.org In-Reply-To: <200111210357.WAA08445@markbaker.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5604 X-Loop: w3c-dist-auth@w3.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 22:57 01/11/20 -0500, Mark Baker wrote: >Perhaps a compromise here would be to treat "DAV:" as a relative URI >reference. A 2518 revision could include the use of XML Base, or its >own base-declaring mechanism, allowing future DAV specifications and >processors to use URIs to evolve, while existing processors could be >seen to be assuming a base URI. Thoughts? Well, it's not WebDAV's business to mess around with bases for namespaces. Namespaces don't currently use XML Base, and probably they won't in the future. There was an extensive discussion of whether namespace uris could be relative uris, and the conclusion as far as I remember was that it should be discouraged. Regards, Martin. From w3c-dist-auth-request@w3.org Wed Nov 21 04:47:10 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 EAA08100 for ; Wed, 21 Nov 2001 04:47:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA14989; Wed, 21 Nov 2001 04:45:04 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 04:45:04 -0500 (EST) Resent-Message-Id: <200111210945.EAA14989@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA14951 for ; Wed, 21 Nov 2001 04:44:51 -0500 (EST) 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 EAA00742 for ; Wed, 21 Nov 2001 04:44:50 -0500 Received: from apu [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Wed, 21 Nov 2001 10:44:37 +0100 From: "Stefan Eissing" To: "Jim Whitehead" , Date: Wed, 21 Nov 2001 10:46:25 +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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5605 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > > Let me reconstruct how we got here. > > * WebDAV uses the "dav:" URI scheme for the name of XML elements used in > protocol messages, and for the name of properties. I try to summarize my knowledge of XML element names, so either Julian can correct me, or everyone knows what we are talking about: Unfortunately, the name of XML elements in XML 1.0 ist just the name of the element as written in the document. So, the name of the elements in is "D:creationdate" and "x:creationdate". These two _names_ are not equivalent for XML parsers! In namespace-aware parsers, the name does not change. However such parsers subdivide a name in two parts: namespace-prefix + localname. This gives in our example: nsprefix localname D creationdate x creationdate NS-aware parsers require that each namespace-prefix be defined in a namespace declaration (as it is the case in the example). Note that the names of the elements are still unchanged and they are still not equivalent! Now, XML-NS does a trick and defines equivalence for a new thing called an expanded element type, consisting of localname and the belonging namespace-URI. This gives in our example: localname namespace-URI creationdate DAV: (which is no URI, unfortunately) creationdate DAV: which indeed are equivalent. Coming back to WebDAV: It is misleading to say that the name of the property creationdate in WebDAV is DAV:creationdate. Because when you serialize it to the name of the XML element is "D:creationdate". Another misleading thing is to assume that the localname of an XML element is appended to the namespace URI. As Julian pointed out, this is neither defined, nor always possible, since allowed character sets for XML element names and URIs differ. Example: would give DAV:prop-A which is not a valid URI either. And finally as for Jim's recommendation to XML-NS: requiring XML-NS to accept DAV: in namespace URIs, means to give up the notion that the namespace is an URI. Instead the namespace-thingie would be an unstructured sequence of characters. //Stefan > * While the BNF for "dav:" URIs has never been explicitly defined > (something > we should do when we revise RFC 2518), if we had, its definition > would be as > follows: > > davuri = davscheme ":" davvalue > davscheme = "dav" > davvalue = opaque_part > > From RFC 2396 we know that the opaque_part is defined as: > > opaque_part = uric_no_slash *uric > > That is, the "dav:" URI scheme can be considered a member of the class of > non-hierarchical URIs described on page 12 of RFC 2396. In particular, it > was never the intent that just the string "dav:" would be > considered a full > URI. The string "dav:" is a URI scheme name, not a URI. The string "dav:" > plus a string matching the production "opaque_part" is a URI. > > * WebDAV marshals "dav:" URIs that are the name of XML elements as a > {namespace} + {opaque_part} pair. So, for example, "dav:creationdate" is > . > > * The XML Namespace recommendation requires that the namespace > identifier be > a URI. > > * Since "dav:" scheme URIs are members of the class of non-hierarchical > URIs, the only constant part is the URI scheme name itself, > "dav:". From the > definition of non-hierarchical URIs given in RFC 2396, ALL > non-hierarchical > URIs will share this quality. Since "dav:" is the only constant > part, it is > the only part of a "dav:" scheme URI suitable for use as the namespace > identifier. > > > To summarize: > * The "dav:" URI scheme is perfectly legal according to RFC 2396. > Therefore, > no change is needed to RFC 2396. > * It is only the use of the "dav:" URI scheme name as an namespace > identifier that is violating any specification. Either RFC 2518 or the XML > Namespaces specification could be changed to rectify this. > > > In my opinion, it is natural to want to use the URI scheme name as the XML > namespace identifier. That is: > > > > is more natural than: > > > > Not to mention that it uses fewer bytes on the wire (not a huge > consideration these days, but those bytes add up over millions of daily > users). > > As a result, I recommend that the XML namespace recommendation be modified > to allow the use of just the URI scheme name as a namespace identifier, > perhaps limited to just members of the set of non-hierarchical URIs. It > seems clear to me that the XML namespace recommendation was written with > only the class of hierarchical URIs in mind, and as a result it's not too > surprising that a glitch arose in the first use with > non-hierarchical URIs. > Based on Julian's experience, and our experience with multiple WebDAV > implementations, accepting a URI scheme name as a namespace > identifier would > codify existing, interoperable, practice. > > - Jim > > > From w3c-dist-auth-request@w3.org Wed Nov 21 04:58:13 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 EAA08206 for ; Wed, 21 Nov 2001 04:58:12 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA15970; Wed, 21 Nov 2001 04:56:18 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 04:56:18 -0500 (EST) Resent-Message-Id: <200111210956.EAA15970@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA15835 for ; Wed, 21 Nov 2001 04:55:41 -0500 (EST) 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 EAA01863 for ; Wed, 21 Nov 2001 04:55:41 -0500 Received: from apu [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Wed, 21 Nov 2001 10:54:40 +0100 From: "Stefan Eissing" To: "Stefan Eissing" , "Jim Whitehead" , Date: Wed, 21 Nov 2001 10:56:28 +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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5606 X-Loop: w3c-dist-auth@w3.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 Correction: my mailer (or someone?) discarded my umlaut A. So the example below > would give DAV:prop-A which is not > a valid URI either. should be read with two dots above A... > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing > Sent: Wednesday, November 21, 2001 10:46 AM > To: Jim Whitehead; w3c-dist-auth@w3.org > Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > > > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > > > > Let me reconstruct how we got here. > > > > * WebDAV uses the "dav:" URI scheme for the name of XML elements used in > > protocol messages, and for the name of properties. > > I try to summarize my knowledge of XML element names, so either > Julian can correct me, or everyone knows what we are talking about: > > Unfortunately, the name of XML elements in XML 1.0 ist just the name > of the element as written in the document. So, the name of the elements > in > > > is "D:creationdate" and "x:creationdate". These two _names_ are not > equivalent for XML parsers! > > In namespace-aware parsers, the name does not change. However such > parsers subdivide a name in two parts: namespace-prefix + localname. > This gives in our example: > nsprefix localname > D creationdate > x creationdate > NS-aware parsers require that each namespace-prefix be defined in > a namespace declaration (as it is the case in the example). Note > that the names of the elements are still unchanged and they are still > not equivalent! > > Now, XML-NS does a trick and defines equivalence for a new thing > called an expanded element type, consisting of localname and the > belonging namespace-URI. This gives in our example: > localname namespace-URI > creationdate DAV: (which is no URI, unfortunately) > creationdate DAV: > which indeed are equivalent. > > Coming back to WebDAV: > > It is misleading to say that the name of the property > creationdate in WebDAV is DAV:creationdate. Because when you > serialize it to the name > of the XML element is "D:creationdate". > > Another misleading thing is to assume that the localname of > an XML element is appended to the namespace URI. As Julian pointed > out, this is neither defined, nor always possible, since allowed > character sets for XML element names and URIs differ. Example: > would give DAV:prop-A which is not > a valid URI either. > > And finally as for Jim's recommendation to XML-NS: requiring XML-NS > to accept DAV: in namespace URIs, means to give up the notion that > the namespace is an URI. Instead the namespace-thingie would be > an unstructured sequence of characters. > > //Stefan > > > * While the BNF for "dav:" URIs has never been explicitly defined > > (something > > we should do when we revise RFC 2518), if we had, its definition > > would be as > > follows: > > > > davuri = davscheme ":" davvalue > > davscheme = "dav" > > davvalue = opaque_part > > > > From RFC 2396 we know that the opaque_part is defined as: > > > > opaque_part = uric_no_slash *uric > > > > That is, the "dav:" URI scheme can be considered a member of > the class of > > non-hierarchical URIs described on page 12 of RFC 2396. In > particular, it > > was never the intent that just the string "dav:" would be > > considered a full > > URI. The string "dav:" is a URI scheme name, not a URI. The > string "dav:" > > plus a string matching the production "opaque_part" is a URI. > > > > * WebDAV marshals "dav:" URIs that are the name of XML elements as a > > {namespace} + {opaque_part} pair. So, for example, > "dav:creationdate" is > > . > > > > * The XML Namespace recommendation requires that the namespace > > identifier be > > a URI. > > > > * Since "dav:" scheme URIs are members of the class of non-hierarchical > > URIs, the only constant part is the URI scheme name itself, > > "dav:". From the > > definition of non-hierarchical URIs given in RFC 2396, ALL > > non-hierarchical > > URIs will share this quality. Since "dav:" is the only constant > > part, it is > > the only part of a "dav:" scheme URI suitable for use as the namespace > > identifier. > > > > > > To summarize: > > * The "dav:" URI scheme is perfectly legal according to RFC 2396. > > Therefore, > > no change is needed to RFC 2396. > > * It is only the use of the "dav:" URI scheme name as an namespace > > identifier that is violating any specification. Either RFC 2518 > or the XML > > Namespaces specification could be changed to rectify this. > > > > > > In my opinion, it is natural to want to use the URI scheme name > as the XML > > namespace identifier. That is: > > > > > > > > is more natural than: > > > > > > > > Not to mention that it uses fewer bytes on the wire (not a huge > > consideration these days, but those bytes add up over millions of daily > > users). > > > > As a result, I recommend that the XML namespace recommendation > be modified > > to allow the use of just the URI scheme name as a namespace identifier, > > perhaps limited to just members of the set of non-hierarchical URIs. It > > seems clear to me that the XML namespace recommendation was written with > > only the class of hierarchical URIs in mind, and as a result > it's not too > > surprising that a glitch arose in the first use with > > non-hierarchical URIs. > > Based on Julian's experience, and our experience with multiple WebDAV > > implementations, accepting a URI scheme name as a namespace > > identifier would > > codify existing, interoperable, practice. > > > > - Jim > > > > > > > > > > From w3c-dist-auth-request@w3.org Wed Nov 21 05:17: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 FAA08425 for ; Wed, 21 Nov 2001 05:17:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA17686; Wed, 21 Nov 2001 05:12:55 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 05:12:55 -0500 (EST) Resent-Message-Id: <200111211012.FAA17686@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA17653 for ; Wed, 21 Nov 2001 05:12:46 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA03850 for ; Wed, 21 Nov 2001 05:12:45 -0500 Received: (qmail 18375 invoked by uid 0); 21 Nov 2001 10:12:14 -0000 Received: from pd9535392.dip.t-dialin.net (HELO lisa) (217.83.83.146) by mail.gmx.net (mp009-rz3) with SMTP; 21 Nov 2001 10:12:14 -0000 From: "Julian Reschke" To: "Jim Whitehead" , , Date: Wed, 21 Nov 2001 11:12:15 +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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5607 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Wednesday, November 21, 2001 3:29 AM > To: w3c-dist-auth@w3.org; uri@w3.org > Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > ... > > That is, the "dav:" URI scheme can be considered a member of the class of > non-hierarchical URIs described on page 12 of RFC 2396. In particular, it > was never the intent that just the string "dav:" would be > considered a full > URI. The string "dav:" is a URI scheme name, not a URI. The string "dav:" > plus a string matching the production "opaque_part" is a URI. Correct so far. > * WebDAV marshals "dav:" URIs that are the name of XML elements as a > {namespace} + {opaque_part} pair. So, for example, "dav:creationdate" is > . RFC2518 says *nothing* about URIs in the DAV: URI scheme. RFC2518 itself never says that an element name or a property "has" a URI. must be read according to the specs that exist, and this means: an XML element with name "D:creationdate", local name "creationdate" and namespace name "dav:". BTW: this should have been "DAV:", right? If you claim that any element or property in WebDAV has a URI, you'd have to answer: - do WebDAV element names and properties share the same namespace? - what are the URIs (identifiers!!!) for: and ? > * The XML Namespace recommendation requires that the namespace > identifier be > a URI. Correct. > * Since "dav:" scheme URIs are members of the class of non-hierarchical > URIs, the only constant part is the URI scheme name itself, > "dav:". From the > definition of non-hierarchical URIs given in RFC 2396, ALL > non-hierarchical > URIs will share this quality. Since "dav:" is the only constant > part, it is > the only part of a "dav:" scheme URI suitable for use as the namespace > identifier. Why would that be? "DAV:deltaV" and "mailto:julian.reschke@gmx.de" are perfectly valid URIs and therefore useable as namespace names. > To summarize: > * The "dav:" URI scheme is perfectly legal according to RFC 2396. Yes. > Therefore, > no change is needed to RFC 2396. > * It is only the use of the "dav:" URI scheme name as an namespace > identifier that is violating any specification. Either RFC 2518 or the XML > Namespaces specification could be changed to rectify this. Guess what will be asked to be changed then :-) > In my opinion, it is natural to want to use the URI scheme name as the XML > namespace identifier. That is: > > > > is more natural than: > > It's shorter, but it's invalid (according to the XML NS rec), while the other one is perfectly valid. > Not to mention that it uses fewer bytes on the wire (not a huge > consideration these days, but those bytes add up over millions of daily > users). OK, let's tell the W3C to use "xhtml:" instead of "http://www.w3.org/1999/xhtml". > As a result, I recommend that the XML namespace recommendation be modified > to allow the use of just the URI scheme name as a namespace identifier, > perhaps limited to just members of the set of non-hierarchical URIs. It > seems clear to me that the XML namespace recommendation was written with > only the class of hierarchical URIs in mind, and as a result it's not too > surprising that a glitch arose in the first use with > non-hierarchical URIs. I doubt that anybody is going to touch XMLNS, but I'd still be interested how you come to this conclusion. The issue is not with non-hierarchical URIs, the issue is that RFC2518 is using "DAV:" as URI where it shouldn't. > Based on Julian's experience, and our experience with multiple WebDAV > implementations, accepting a URI scheme name as a namespace > identifier would > codify existing, interoperable, practice. *Lack* of interoperability with James Clark's code in JING exactly is the reason why we have this discussion. I think we should thank him for actually *using* the grammer in RFC2396 for validation, so this was finally uncovered. From w3c-dist-auth-request@w3.org Wed Nov 21 05:25:50 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 FAA08506 for ; Wed, 21 Nov 2001 05:25:50 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA18462; Wed, 21 Nov 2001 05:21:07 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 05:21:07 -0500 (EST) Resent-Message-Id: <200111211021.FAA18462@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA18418 for ; Wed, 21 Nov 2001 05:20:38 -0500 (EST) 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 FAA04916; Wed, 21 Nov 2001 05:20:38 -0500 Received: from lisa [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R); Wed, 21 Nov 2001 11:19:46 +0100 From: "Julian Reschke" To: "James Clark" , "Jim Whitehead" , , Date: Wed, 21 Nov 2001 11:19:46 +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) In-Reply-To: <420812957.1006340574@[192.168.0.197]> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-MDRemoteIP: 192.168.1.2 X-Return-Path: julian.reschke@greenbytes.de Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5608 X-Loop: w3c-dist-auth@w3.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: uri-request@w3.org [mailto:uri-request@w3.org]On Behalf Of James > Clark > Sent: Wednesday, November 21, 2001 5:03 AM > To: Jim Whitehead; w3c-dist-auth@w3.org; uri@w3.org > Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > ... > > I don't think the issue is anything to do with whether URIs are > hierarchical. From reading your message, the requirements appear to be as > follows: > > - DAV wants to identify elements by a URI not a URI/local name pair I think this should read: historically, in the development of WebDAV, there was a phase where the spec assumed the existence of a mapping like this. I don't think that RFC2518 as published does this. > - DAV wants the generated URI for an element to be > dav:creationdate > > - DAV to generate the URI that identifies an element from the namespace > identifier and local name > > You might think that these requirements imply that the namespace I don't think that these actually *are* requirements. At least not according to RFC2518. > identifier > for DAV must be "dav:", but in fact they don't, because there is no > requirement that the method that you use to generate the URI that > identifies an element is to concatenate the namespace identifier and the > local name or the element. You can solve the problem simply by choosing > some other method of generating the URI, which allows the namespace > identifier to be a legal URI, as required by the XML Namespaces Rec. Is there any (published one) that works well with arbitrary namespace names and element names? From w3c-dist-auth-request@w3.org Wed Nov 21 08:17:17 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 IAA12778 for ; Wed, 21 Nov 2001 08:17:17 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA01538; Wed, 21 Nov 2001 08:11:47 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 08:11:47 -0500 (EST) Resent-Message-Id: <200111211311.IAA01538@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA01516 for ; Wed, 21 Nov 2001 08:11:38 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37184.rational.com [192.229.37.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA24620 for ; Wed, 21 Nov 2001 08:11:38 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 21 Nov 2001 08:11:07 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Nov 2001 08:11:07 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B104EC8AF8@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Wed, 21 Nov 2001 08:11:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ACL] Principal Identity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5609 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I believe that when we revise 2518, that that the new DAV:allprop behavior should be defined to be "all live properties defined in RFC 2518 plus all dead properties". Since 2518 states that it is *all* properties (both live and dead), making this direction clear now will allow clients to rely on dead+2518 properties. Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Tuesday, November 20, 2001 1:40 AM To: Stefan Eissing; Jim Whitehead; Webdav WG Subject: RE: [ACL] Principal Identity > The nice thing about allprop is that you get all the dead properties. > The bad thing about allprop is that you cannot see if a resource is > versioned/version or which methods it does support. How do you know you can get all the dead properties? 'allprop' as defined in RFC2518 seems to have to change, yet we've not clearly defined a new behaviour. In the meantime, I don't believe clients can rely on getting anything back in 'allprop' except the live properties defined in RFC2518. Lisa From w3c-dist-auth-request@w3.org Wed Nov 21 08:18: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 IAA12881 for ; Wed, 21 Nov 2001 08:18:52 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA01664; Wed, 21 Nov 2001 08:14:46 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 08:14:46 -0500 (EST) Resent-Message-Id: <200111211314.IAA01664@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA01644 for ; Wed, 21 Nov 2001 08:14:33 -0500 (EST) 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 IAA24973 for ; Wed, 21 Nov 2001 08:14:31 -0500 Received: from apu [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Wed, 21 Nov 2001 14:13:35 +0100 From: "Stefan Eissing" To: "Webdav WG" Date: Wed, 21 Nov 2001 14:15:23 +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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: RE: [ACL] Principal Identity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5610 X-Loop: w3c-dist-auth@w3.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 > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Tuesday, November 20, 2001 7:40 AM > To: Stefan Eissing; Jim Whitehead; Webdav WG > Subject: RE: [ACL] Principal Identity > > > > > > The nice thing about allprop is that you get all the dead properties. > > The bad thing about allprop is that you cannot see if a resource is > > versioned/version or which methods it does support. > > How do you know you can get all the dead properties? 'allprop' as defined > in RFC2518 seems to have to change, yet we've not clearly defined a new > behaviour. In the meantime, I don't believe clients can rely on getting > anything back in 'allprop' except the live properties defined in RFC2518. Since no new behaviour is defined, I would expect servers to return all dead properties on , yes. I agree that the mechanism should be enhanced. Therefore our proposal, which does not claim to solve all issues. //Stefan From w3c-dist-auth-request@w3.org Wed Nov 21 12:36: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 MAA26643 for ; Wed, 21 Nov 2001 12:36:58 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA24673; Wed, 21 Nov 2001 12:34:43 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 12:34:43 -0500 (EST) Resent-Message-Id: <200111211734.MAA24673@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA24651 for ; Wed, 21 Nov 2001 12:34:33 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA14656 for ; Wed, 21 Nov 2001 12:34:33 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id JAA15826 for ; Wed, 21 Nov 2001 09:34:35 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 21 Nov 2001 09:34:15 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5611 X-Loop: w3c-dist-auth@w3.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 "jjc@jclark.com" to the accept2 list. - Jim -----Original Message----- From: James Clark [mailto:jjc@jclark.com] Sent: Tuesday, November 20, 2001 8:00 PM To: Jim Whitehead; w3c-dist-auth@w3.org; uri@w3.org Subject: [Moderator Action] RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > * WebDAV marshals "dav:" URIs that are the name of XML elements as a > {namespace} + {opaque_part} pair. So, for example, "dav:creationdate" is > . The XML Namespaces Recommendation provides a facility to name an element by a URI/local-name pair. It does not provide a facility to name an element by a URI. The element has a name that is a pair consisting of the (non-)URI "dav:" and the local name creationdate. Nowhere does the XML Namespaces Recommendation say that you will get anything interesting or useful by concatenating the URI and the local name. The fact that "dav:creationdate" is a fine URI is completely irrelevant from the perspective of the XML Namespaces Rec to the issue of whether "dav:" is a legal namespace identifier. > It > seems clear to me that the XML namespace recommendation was written with > only the class of hierarchical URIs in mind, and as a result it's not too > surprising that a glitch arose in the first use with non-hierarchical > URIs. I don't think the issue is anything to do with whether URIs are hierarchical. From reading your message, the requirements appear to be as follows: - DAV wants to identify elements by a URI not a URI/local name pair - DAV wants the generated URI for an element to be dav:creationdate - DAV to generate the URI that identifies an element from the namespace identifier and local name You might think that these requirements imply that the namespace identifier for DAV must be "dav:", but in fact they don't, because there is no requirement that the method that you use to generate the URI that identifies an element is to concatenate the namespace identifier and the local name or the element. You can solve the problem simply by choosing some other method of generating the URI, which allows the namespace identifier to be a legal URI, as required by the XML Namespaces Rec. James From w3c-dist-auth-request@w3.org Wed Nov 21 12:37:02 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 MAA26661 for ; Wed, 21 Nov 2001 12:37:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA24727; Wed, 21 Nov 2001 12:35:17 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 12:35:17 -0500 (EST) Resent-Message-Id: <200111211735.MAA24727@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA24701 for ; Wed, 21 Nov 2001 12:35:09 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA14910 for ; Wed, 21 Nov 2001 12:35:08 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id JAA15938 for ; Wed, 21 Nov 2001 09:35:10 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 21 Nov 2001 09:34:50 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5612 X-Loop: w3c-dist-auth@w3.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 filer. I've added "Patrick.Stickler@nokia.com" to the accept2 list. - Jim -----Original Message----- From: Patrick.Stickler@nokia.com [mailto:Patrick.Stickler@nokia.com] Sent: Wednesday, November 21, 2001 12:49 AM To: distobj@acm.org; ejw@cse.ucsc.edu Cc: w3c-dist-auth@w3.org; uri@w3.org Subject: [Moderator Action] RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > IMO, a URI scheme has identity, and so should be able to be identified > by a URI reference. Right. Insofar as RDF is concerned, which provides for a concatenative mapping from qname to URI, you could do the following: Where "dav:" is both a URI denoting the URI scheme, and an xmlns prefix. Which is which is 100% clear in the XML syntax. This gives the (RDF) URI "dav:creationdate" as desired and provides for consistency between URI and qname representation. Eh? Though this doesn't help much in a non-RDF context where a given qname is interpreted as just "{namespace}name" rather than the concatenation "namespacename". Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From w3c-dist-auth-request@w3.org Wed Nov 21 12:38: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 MAA26785 for ; Wed, 21 Nov 2001 12:38:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA24937; Wed, 21 Nov 2001 12:36:59 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 12:36:59 -0500 (EST) Resent-Message-Id: <200111211736.MAA24937@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA24832 for ; Wed, 21 Nov 2001 12:36:44 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA15206 for ; Wed, 21 Nov 2001 12:36:44 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id JAA16203 for ; Wed, 21 Nov 2001 09:36:46 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 21 Nov 2001 09:36:26 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5613 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Patrick.Stickler@nokia.com [mailto:Patrick.Stickler@nokia.com] Sent: Wednesday, November 21, 2001 4:31 AM To: julian.reschke@gmx.de; ejw@cse.ucsc.edu; w3c-dist-auth@w3.org; uri@w3.org Subject: [Moderator Action] RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > As a result, I recommend that the XML namespace > recommendation be modified > > to allow the use of just the URI scheme name as a namespace > identifier, The interpretation of a URI scheme prefix as a valid URI also makes sense from the viewpoint of RDF (at least to me ;-) in that otherwise, one has no way to make statements about the URI scheme itself. The same is true for a URN Namespace. Thus, "DAV:", "http:", "urn:", and "urn:issn:" should all be considered valid URIs. Not necessarily valid in terms of the individual schemes themselves, but in terms of the semantics assigned to those prefixes by RFC2396 and RFC2141. I.e. "http:" is not a valid HTTP URL but it is a valid URI denoting the HTTP URL scheme. > I doubt that anybody is going to touch XMLNS, No need to touch XMLNS. If the above are URIs, then you can use them as namespace URI refs. Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From w3c-dist-auth-request@w3.org Wed Nov 21 12:38:43 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 MAA26804 for ; Wed, 21 Nov 2001 12:38:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA24971; Wed, 21 Nov 2001 12:37:11 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 12:37:11 -0500 (EST) Resent-Message-Id: <200111211737.MAA24971@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA24834 for ; Wed, 21 Nov 2001 12:36:45 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA15207 for ; Wed, 21 Nov 2001 12:36:44 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id JAA16207 for ; Wed, 21 Nov 2001 09:36:46 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 21 Nov 2001 09:36:26 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5614 X-Loop: w3c-dist-auth@w3.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 "danbri@w3.org" to the accept2 list. - Jim -----Original Message----- From: Dan Brickley [mailto:danbri@w3.org] Sent: Wednesday, November 21, 2001 4:46 AM To: Patrick.Stickler@nokia.com Cc: julian.reschke@gmx.de; ejw@cse.ucsc.edu; w3c-dist-auth@w3.org; uri@w3.org Subject: [Moderator Action] RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency On Wed, 21 Nov 2001 Patrick.Stickler@nokia.com wrote: > > > As a result, I recommend that the XML namespace > > recommendation be modified > > > to allow the use of just the URI scheme name as a namespace > > identifier, > > The interpretation of a URI scheme prefix as a valid > URI also makes sense from the viewpoint of RDF (at least > to me ;-) in that otherwise, one has no way to make > statements about the URI scheme itself. Not so. It is possible to describe things without knowing their URI. We do it all the time. Here, you can describe the scheme indirectly, eg: dav The DAV URI scheme A URI schema for ... We can further tighten things by saying that the RDF property sketched here, 'prefix', is a UniqueProperty (using DAML+OIL or another Web ontology language). That tells us that an individual Scheme is picked out by each value of 'prefix'. BTW http://www.w3.org/Addressing/schemes.html is generated using a similar technique; details at http://www.w3.org/Addressing/schemes.html#ctech Dan (dropping out of this cross-posted thread and all its spinoffs...) -- mailto:danbri@w3.org http://www.w3.org/People/DanBri/ From w3c-dist-auth-request@w3.org Wed Nov 21 12:38: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 MAA26815 for ; Wed, 21 Nov 2001 12:38:44 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA25000; Wed, 21 Nov 2001 12:37:18 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 12:37:18 -0500 (EST) Resent-Message-Id: <200111211737.MAA25000@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA24838 for ; Wed, 21 Nov 2001 12:36:45 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA15210 for ; Wed, 21 Nov 2001 12:36:45 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id JAA16211 for ; Wed, 21 Nov 2001 09:36:47 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 21 Nov 2001 09:36:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5615 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Patrick.Stickler@nokia.com [mailto:Patrick.Stickler@nokia.com] Sent: Wednesday, November 21, 2001 4:57 AM To: danbri@w3.org Cc: julian.reschke@gmx.de; ejw@cse.ucsc.edu; w3c-dist-auth@w3.org; uri@w3.org Subject: [Moderator Action] RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > -----Original Message----- > From: ext Dan Brickley [mailto:danbri@w3.org] > Sent: 21 November, 2001 14:45 > To: Stickler Patrick (NRC/Tampere) > Cc: julian.reschke@gmx.de; ejw@cse.ucsc.edu; w3c-dist-auth@w3.org; > uri@w3.org > Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > > > > On Wed, 21 Nov 2001 Patrick.Stickler@nokia.com wrote: > > > > > As a result, I recommend that the XML namespace > > > recommendation be modified > > > > to allow the use of just the URI scheme name as a namespace > > > identifier, > > > > The interpretation of a URI scheme prefix as a valid > > URI also makes sense from the viewpoint of RDF (at least > > to me ;-) in that otherwise, one has no way to make > > statements about the URI scheme itself. > > Not so. I stand (somewhat) corrected. > It is possible to describe things without knowing > their URI. Just because something is possible, does not mean it is optimal. > We > do it all the time. Here, you can describe the scheme indirectly, eg: > > > > dav > The DAV URI scheme > > A URI schema for ... > > But this opens up the question of what the canonical identity of the URI scheme is and how equivalence operations (graph tidying, etc.) apply to such complex structures. A single URI provides a single, consistent point of reference, and one that is not bound to RDF, but is acceptable to any web application that is "URI aware". > We can further tighten things by saying that the RDF property sketched > here, 'prefix', is a UniqueProperty (using DAML+OIL or another Web > ontology language). That tells us that an individual Scheme > is picked out > by each value of 'prefix'. But that's the whole point of a URI, no? Why introduce yet another mechanism (and one that is less general) when a reliable and fully unambiguous interpretation can be ascribed to URI prefixes and URN Namespace prefixes? Surely the more general and economical solution would be better? And BTW, most RDF parsers are already quite happy interpreting "http:" and similar URI prefixes as a URI ;-) Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From w3c-dist-auth-request@w3.org Wed Nov 21 12:46:54 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 MAA27118 for ; Wed, 21 Nov 2001 12:46:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA25877; Wed, 21 Nov 2001 12:45:17 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 12:45:17 -0500 (EST) Resent-Message-Id: <200111211745.MAA25877@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA25857 for ; Wed, 21 Nov 2001 12:45:12 -0500 (EST) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA17268 for ; Wed, 21 Nov 2001 12:45:12 -0500 Received: from mt2k (212.dhcp.ott.opentext.com [192.168.130.212]) by opentext.com (8.9.3/8.9.3) with SMTP id MAA13450; Wed, 21 Nov 2001 12:44:37 -0500 Reply-To: From: "Matt Timmermans" To: "'Julian Reschke'" , "'WebDAV'" Date: Wed, 21 Nov 2001 12:44:35 -0500 Message-ID: <000d01c172b4$2f970270$d482a8c0@mt2k> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5616 X-Loop: w3c-dist-auth@w3.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: Julian Reschke > > From: Matt Timmermans > > If the property's namespace ends in "/" or ":", then the > property HREF is > > namespace+local_name, just like Today. > > > > Otherwise, the property HREF is namespace+"#"+local_name. > > How do you encode the local name? Given an arbitrary URI, how > do you select > base URI and element name? ...and so on. It doesn't work. To encode a general local name, you use UTF8 encoding and %xx escapes, as recommended in section B.2.1 of the HTML spec. http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.1 To get the namespace URI and local name from a property URI, just scan backwards for the last '#', '/', or ':', and split the URI. If the left part ends in #, then remove it. > > WebDAV would have to codify this in the description of > > DAV:keepalive. This > > would at least be compatible with most current environments. > > I would care more if there is a single server implementation > that actually > implements keepalive. Is there? Sort of. Depending on the context, our server can either satisfy any keepalive request, or it cant satisfy any keepalive request. In the latter situation, we fail the copy if keepalive is specified. But a server doesn't have to implement keepalive to be broken by changing the content model -- it only has to validate requests. From w3c-dist-auth-request@w3.org Wed Nov 21 12:53:21 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 MAA27412 for ; Wed, 21 Nov 2001 12:53:21 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA26344; Wed, 21 Nov 2001 12:51:50 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 12:51:50 -0500 (EST) Resent-Message-Id: <200111211751.MAA26344@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA26321 for ; Wed, 21 Nov 2001 12:51:38 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA18543 for ; Wed, 21 Nov 2001 12:51:37 -0500 Received: (qmail 26758 invoked by uid 0); 21 Nov 2001 17:51:27 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp003-rz3) with SMTP; 21 Nov 2001 17:51:27 -0000 From: "Julian Reschke" To: , "'Julian Reschke'" , "'WebDAV'" Date: Wed, 21 Nov 2001 18:51:24 +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 V6.00.2600.0000 In-Reply-To: <000d01c172b4$2f970270$d482a8c0@mt2k> Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5617 X-Loop: w3c-dist-auth@w3.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: Matt Timmermans [mailto:mtimmerm@opentext.com] > Sent: Wednesday, November 21, 2001 6:45 PM > To: 'Julian Reschke'; 'WebDAV' > Subject: RE: content type for WebDAV request/response bodies, was: [ACL] > Access Control Protocol -07 submitted > > > > From: Julian Reschke > > > > From: Matt Timmermans > > > If the property's namespace ends in "/" or ":", then the > > property HREF is > > > namespace+local_name, just like Today. > > > > > > Otherwise, the property HREF is namespace+"#"+local_name. > > > > How do you encode the local name? Given an arbitrary URI, how > > do you select > > base URI and element name? ...and so on. It doesn't work. > > To encode a general local name, you use UTF8 encoding and %xx escapes, as > recommended in section B.2.1 of the HTML spec. > > http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.1 > > To get the namespace URI and local name from a property URI, just scan > backwards for the last '#', '/', or ':', and split the URI. If the left > part ends in #, then remove it. That doesn't give you a one-to-one mapping. For instance: and would map to the same URI. How would you map ??? From w3c-dist-auth-request@w3.org Wed Nov 21 12:55:48 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 MAA27466 for ; Wed, 21 Nov 2001 12:55:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA26970; Wed, 21 Nov 2001 12:54:07 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 12:54:07 -0500 (EST) Resent-Message-Id: <200111211754.MAA26970@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA26915 for ; Wed, 21 Nov 2001 12:53:47 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA19027; Wed, 21 Nov 2001 12:53:47 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id JAA20747; Wed, 21 Nov 2001 09:53:49 -0800 (PST) From: "Jim Whitehead" To: , Date: Wed, 21 Nov 2001 09:53:29 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <2BF0AD29BC31FE46B78877321144043114C0C4@trebe003.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5618 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think it might help people to better understand the set of possible solutions to this issue if I point out that WebDAV implementations are NOT going to support any change that leads to a reduction in interoperability. So, for example, any suggestion that begins, "just change WebDAV's namespace identifier to ...." is not going to work. Complain to me all you wish about this -- you'll just be shooting the messenger. - Jim From w3c-dist-auth-request@w3.org Wed Nov 21 13: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 ESMTP id NAA27734 for ; Wed, 21 Nov 2001 13:01:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA27717; Wed, 21 Nov 2001 12:59:49 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 12:59:49 -0500 (EST) Resent-Message-Id: <200111211759.MAA27717@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA27688 for ; Wed, 21 Nov 2001 12:59:39 -0500 (EST) 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 MAA20615; Wed, 21 Nov 2001 12:59:38 -0500 Received: from lisa [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R); Wed, 21 Nov 2001 18:59:01 +0100 From: "Julian Reschke" To: "Jim Whitehead" , , Date: Wed, 21 Nov 2001 18:59:01 +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 V6.00.2600.0000 In-Reply-To: X-MDRemoteIP: 192.168.1.2 X-Return-Path: julian.reschke@greenbytes.de Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5619 X-Loop: w3c-dist-auth@w3.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: uri-request@w3.org [mailto:uri-request@w3.org]On Behalf Of Jim > Whitehead > Sent: Wednesday, November 21, 2001 6:53 PM > To: w3c-dist-auth@w3.org; uri@w3.org > Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > > > I think it might help people to better understand the set of possible > solutions to this issue if I point out that WebDAV implementations are NOT > going to support any change that leads to a reduction in interoperability. > > So, for example, any suggestion that begins, "just change > WebDAV's namespace > identifier to ...." is not going to work. Of course. So - a new namespace name would be needed - the old one would need to be deprecated - interoperability of all combinations of new/old servers needs to be investigated In theory the revision of RFC2518 could deprecate "DAV:" in favor of "somenewuri", right? > Complain to me all you wish about this -- you'll just be shooting the > messenger. Whose messenger? From w3c-dist-auth-request@w3.org Wed Nov 21 13:08: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 NAA27987 for ; Wed, 21 Nov 2001 13:08:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA28496; Wed, 21 Nov 2001 13:06:58 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 13:06:58 -0500 (EST) Resent-Message-Id: <200111211806.NAA28496@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA28468 for ; Wed, 21 Nov 2001 13:06:51 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA22616; Wed, 21 Nov 2001 13:06:50 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA24011; Wed, 21 Nov 2001 10:06:53 -0800 (PST) From: "Jim Whitehead" To: , Date: Wed, 21 Nov 2001 10:06:32 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5620 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > * WebDAV marshals "dav:" URIs that are the name of XML elements as a > > {namespace} + {opaque_part} pair. So, for example, > "dav:creationdate" is . > > RFC2518 says *nothing* about URIs in the DAV: URI scheme. RFC2518 itself > never says that an element name or a property "has" a URI. Section 18 clearly states that "The property names and XML elements in this specification are all derived from the base URI DAV: by adding a suffix to this URI, for example, DAV:creationdate for the 'creationdate' property." Now, we've had discussion on the WebDAV list to move away from this position, and more towards the {namespace identifier} + {name} position embedded within the XML namespace draft. This strikes me as a good thing. > must be read according to the specs that > exist, and this means: an XML element with name "D:creationdate", > local name "creationdate" and namespace name "dav:". BTW: this should have > been "DAV:", right? URI scheme names are case insensitive (see Section 3.1 of RFC 2396). So, "DAV:" and "dav:" are equivalent. > If you claim that any element or property in WebDAV has a URI, > you'd have to answer: > > - do WebDAV element names and properties share the same namespace? Yes. > - what are the URIs (identifiers!!!) for: /> and ? Following WebDAV concatenation rules: => http://a/b/cd => http://a/b/cd Again, let me stress that this is what RFC 2518 says, and we have discussed on the WebDAV list that this is probably not the best path to take going into the future. > It's shorter, but it's invalid (according to the XML NS rec), while the > other one is perfectly valid. OTOH, I haven't heard a compelling reason why the XML NS rec couldn't be changed. Certainly this change would have far fewer interoperability implications, especially since most namespace implementations already allow just a URI scheme. > OK, let's tell the W3C to use "xhtml:" instead of > "http://www.w3.org/1999/xhtml". I have no problem with this. > *Lack* of interoperability with James Clark's code in JING exactly is the > reason why we have this discussion. I think we should thank him > for actually *using* the grammer in RFC2396 for validation, so this > was finally uncovered. Frankly, I have found this discussion to be incredibly moot, and of little value. - Jim From w3c-dist-auth-request@w3.org Wed Nov 21 13:17: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 NAA28223 for ; Wed, 21 Nov 2001 13:17:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA29236; Wed, 21 Nov 2001 13:15:37 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 13:15:37 -0500 (EST) Resent-Message-Id: <200111211815.NAA29236@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA29215 for ; Wed, 21 Nov 2001 13:15:32 -0500 (EST) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA24430 for ; Wed, 21 Nov 2001 13:15:32 -0500 Received: from mt2k (212.dhcp.ott.opentext.com [192.168.130.212]) by opentext.com (8.9.3/8.9.3) with SMTP id NAA14991; Wed, 21 Nov 2001 13:14:44 -0500 Reply-To: From: "Matt Timmermans" To: "'Julian Reschke'" , "'WebDAV'" Date: Wed, 21 Nov 2001 13:14:41 -0500 Message-ID: <000f01c172b8$64b5f5c0$d482a8c0@mt2k> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5621 X-Loop: w3c-dist-auth@w3.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 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > That doesn't give you a one-to-one mapping. Sure it does. > For instance: > > and > > would map to the same URI. You get http://a.b.c/d#%23foo and http://a.b.c/d#foo > How would you map > > http://a.b.c/d#e%23foo From w3c-dist-auth-request@w3.org Wed Nov 21 13:21:18 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28395 for ; Wed, 21 Nov 2001 13:21:16 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA29814; Wed, 21 Nov 2001 13:19:29 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 13:19:29 -0500 (EST) Resent-Message-Id: <200111211819.NAA29814@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA29672 for ; Wed, 21 Nov 2001 13:19:02 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA25010 for ; Wed, 21 Nov 2001 13:19:02 -0500 Received: (qmail 6928 invoked by uid 0); 21 Nov 2001 18:18:31 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp003-rz3) with SMTP; 21 Nov 2001 18:18:31 -0000 From: "Julian Reschke" To: "Jim Whitehead" , , Date: Wed, 21 Nov 2001 19:18:30 +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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5622 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Wednesday, November 21, 2001 7:07 PM > To: w3c-dist-auth@w3.org; uri@w3.org > Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > > > > * WebDAV marshals "dav:" URIs that are the name of XML elements as a > > > {namespace} + {opaque_part} pair. So, for example, > > "dav:creationdate" is . > > > > RFC2518 says *nothing* about URIs in the DAV: URI scheme. RFC2518 itself > > never says that an element name or a property "has" a URI. > > Section 18 clearly states that "The property names and XML > elements in this > specification are all derived from the base URI DAV: by adding a suffix to > this URI, for example, DAV:creationdate for the 'creationdate' property." I admit I missed that because it's under "IANA" considerations :-) > Now, we've had discussion on the WebDAV list to move away from this > position, and more towards the {namespace identifier} + {name} position > embedded within the XML namespace draft. This strikes me as a good thing. The XML namespace recommendation doesn't specify a specific representation. > > must be read according to the specs that > > exist, and this means: an XML element with name "D:creationdate", > > local name "creationdate" and namespace name "dav:". BTW: this > should have > > been "DAV:", right? > > URI scheme names are case insensitive (see Section 3.1 of RFC 2396). So, > "DAV:" and "dav:" are equivalent. Yes, but XML namespace names are case-sensitive. So and are different things, and the latter isn't in the "DAV:" XML namespace (assuming for now that the notion of "DAV:" XML namespaces exists at all). > > If you claim that any element or property in WebDAV has a URI, > > you'd have to answer: > > > > - do WebDAV element names and properties share the same namespace? > > Yes. > > > - what are the URIs (identifiers!!!) for: > /> and ? > > Following WebDAV concatenation rules: > > => http://a/b/cd > > => http://a/b/cd > > Again, let me stress that this is what RFC 2518 says, and we have > discussed > on the WebDAV list that this is probably not the best path to take going > into the future. Ok. > > It's shorter, but it's invalid (according to the XML NS rec), while the > > other one is perfectly valid. > > OTOH, I haven't heard a compelling reason why the XML NS rec couldn't be > changed. Certainly this change would have far fewer interoperability > implications, especially since most namespace implementations > already allow > just a URI scheme. I understand why one would prefer to have a "small" change on somebody else's spec, but from the feedback I've seen so far I don't think it's going to happen. > ... > > > *Lack* of interoperability with James Clark's code in JING > exactly is the > > reason why we have this discussion. I think we should thank him > > for actually *using* the grammer in RFC2396 for validation, so this > > was finally uncovered. > > Frankly, I have found this discussion to be incredibly moot, and of little > value. I don't think it's moot. Whether you like it or not, RFC2518 as it's published is broken because it doesn't conform to what to other (earlier and more basic specifications) say. It's a pity that this wasn't discovered earlier, but ignoring the issue won't make it go away. From w3c-dist-auth-request@w3.org Wed Nov 21 13:27:37 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 NAA28537 for ; Wed, 21 Nov 2001 13:27:36 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA00582; Wed, 21 Nov 2001 13:22:19 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 13:22:19 -0500 (EST) Resent-Message-Id: <200111211822.NAA00582@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA00550 for ; Wed, 21 Nov 2001 13:21:58 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA25458 for ; Wed, 21 Nov 2001 13:21:58 -0500 Received: (qmail 1577 invoked by uid 0); 21 Nov 2001 18:21:54 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp005-rz3) with SMTP; 21 Nov 2001 18:21:54 -0000 From: "Julian Reschke" To: , "'Julian Reschke'" , "'WebDAV'" Date: Wed, 21 Nov 2001 19:21:54 +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 V6.00.2600.0000 In-Reply-To: <000f01c172b8$64b5f5c0$d482a8c0@mt2k> Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5623 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit OK, so how do you map ? > -----Original Message----- > From: Matt Timmermans [mailto:mtimmerm@opentext.com] > Sent: Wednesday, November 21, 2001 7:15 PM > To: 'Julian Reschke'; 'WebDAV' > Subject: RE: content type for WebDAV request/response bodies, was: [ACL] > Access Control Protocol -07 submitted > > > > > -----Original Message----- > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > That doesn't give you a one-to-one mapping. > > Sure it does. > > > For instance: > > > > and > > > > would map to the same URI. > > You get > > http://a.b.c/d#%23foo and http://a.b.c/d#foo > > > How would you map > > > > > > http://a.b.c/d#e%23foo > > From w3c-dist-auth-request@w3.org Wed Nov 21 13:32: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 NAA28764 for ; Wed, 21 Nov 2001 13:32:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA00970; Wed, 21 Nov 2001 13:27:24 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 13:27:24 -0500 (EST) Resent-Message-Id: <200111211827.NAA00970@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA00930 for ; Wed, 21 Nov 2001 13:27:08 -0500 (EST) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA26256 for ; Wed, 21 Nov 2001 13:27:08 -0500 Received: from mt2k (212.dhcp.ott.opentext.com [192.168.130.212]) by opentext.com (8.9.3/8.9.3) with SMTP id NAA15667; Wed, 21 Nov 2001 13:26:35 -0500 Reply-To: From: "Matt Timmermans" To: "'Julian Reschke'" , "'WebDAV'" Date: Wed, 21 Nov 2001 13:26:33 -0500 Message-ID: <001001c172ba$0cac8180$d482a8c0@mt2k> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5624 X-Loop: w3c-dist-auth@w3.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 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > so how do you map > > > http://a.b.c/d#f%23oo From w3c-dist-auth-request@w3.org Wed Nov 21 13:46: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 NAA29276 for ; Wed, 21 Nov 2001 13:46:25 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA01745; Wed, 21 Nov 2001 13:37:51 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 13:37:51 -0500 (EST) Resent-Message-Id: <200111211837.NAA01745@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA01695 for ; Wed, 21 Nov 2001 13:37:37 -0500 (EST) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA27858 for ; Wed, 21 Nov 2001 13:37:34 -0500 Received: from moose ([198.144.203.249]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id fALIbMQ81458; Wed, 21 Nov 2001 10:37:22 -0800 (PST) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: "Julian Reschke" , , "'WebDAV'" Date: Tue, 20 Nov 2001 22:35:18 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5627 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > To get the namespace URI and local name from a property URI, just scan > > backwards for the last '#', '/', or ':', and split the URI. If the left > > part ends in #, then remove it. > > That doesn't give you a one-to-one mapping. > > For instance: > > and > > would map to the same URI. > > How would you map > > I've seen this done before. MTimmerman's rules for undoing the concatenation were correct as I recall, but he didn't put the rules for concatenation in, which would have cleared things up. - If the namespace ends in '/' or ':', concatenate. - If the namespace ends in anything else, add a '#' and concatenate. Thus, you'd transform to "http://a.b.c/d##foo". Clearly different than "http://a.b.c/d#foo" since you only remove the last '#' when un-concatenating. You ask how to map : since it ends in 'e', add a '#', and it becomes "http://a.b.c/d#e#foo". When going back to real XML form, scan backward from the end for the last '#', remove it. Lisa From w3c-dist-auth-request@w3.org Wed Nov 21 13:46:26 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 NAA29293 for ; Wed, 21 Nov 2001 13:46:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA01715; Wed, 21 Nov 2001 13:37:40 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 13:37:40 -0500 (EST) Resent-Message-Id: <200111211837.NAA01715@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA01683 for ; Wed, 21 Nov 2001 13:37:35 -0500 (EST) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA27842 for ; Wed, 21 Nov 2001 13:37:32 -0500 Received: from moose ([198.144.203.249]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id fALIbKQ81450; Wed, 21 Nov 2001 10:37:20 -0800 (PST) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: "Clemm, Geoff" , "Webdav WG" Date: Tue, 20 Nov 2001 22:35:16 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B104EC8AF8@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: RE: [ACL] Principal Identity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5626 X-Loop: w3c-dist-auth@w3.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 definition of dead properties is not clear enough to make that proposal a basis for interoperability. Since I love examples, follow me through this one: - A WebDAV client software package defines a couple dead properties, "image-height" and "image-width" as integers. It sets these properties on all images it saves & uses them later. Obviously so far it's a dead property. - Other clients start to use these. Still dead, right? - Custom software is added onto another WebDAV server platform to set these properties auto-magically whenever an image is uploaded. The base server software is uninvolved in this process. - A full WebDAV server decides to make sure that whenever these properties are set, at least they're integers. Maybe it also checks they're not negative. Other servers, however, still ignore these properties. - Another DAV server decides that it can calculate this property on the fly and make sure it's always correct. However, the calculation is expensive (Note that this scenario starts to sound like justification for NOT including properties in allprop). When do these properties stop being dead and start being live? Can clients rely on these properties being listed in 'allprop' or not? On some servers but not on others? Ugh. That's why I think only a fixed list of properties can be relied upon to be in allprop. Let's rely on 'propname' to actually tell us the complete list of properties, whether they're alive, dead, or somewhere in between. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Wednesday, November 21, 2001 5:11 AM > To: Webdav WG > Subject: RE: [ACL] Principal Identity > > > I believe that when we revise 2518, that that the > new DAV:allprop behavior should be defined to be > "all live properties defined in RFC 2518 plus all > dead properties". Since 2518 states that it is *all* > properties (both live and dead), making this direction > clear now will allow clients to rely on dead+2518 > properties. > > Cheers, > Geoff > > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Tuesday, November 20, 2001 1:40 AM > To: Stefan Eissing; Jim Whitehead; Webdav WG > Subject: RE: [ACL] Principal Identity > > > > > > The nice thing about allprop is that you get all the dead properties. > > The bad thing about allprop is that you cannot see if a resource is > > versioned/version or which methods it does support. > > How do you know you can get all the dead properties? 'allprop' as defined > in RFC2518 seems to have to change, yet we've not clearly defined a new > behaviour. In the meantime, I don't believe clients can rely on getting > anything back in 'allprop' except the live properties defined in RFC2518. > > Lisa From w3c-dist-auth-request@w3.org Wed Nov 21 13:50: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 NAA29428 for ; Wed, 21 Nov 2001 13:50:58 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA02020; Wed, 21 Nov 2001 13:40:44 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 13:40:44 -0500 (EST) Resent-Message-Id: <200111211840.NAA02020@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA01980 for ; Wed, 21 Nov 2001 13:40:34 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA28355 for ; Wed, 21 Nov 2001 13:40:34 -0500 Received: (qmail 2365 invoked by uid 0); 21 Nov 2001 18:40:31 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp001-rz3) with SMTP; 21 Nov 2001 18:40:31 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "Julian Reschke" , , "'WebDAV'" Date: Wed, 21 Nov 2001 19:40:31 +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 V6.00.2600.0000 In-Reply-To: Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5628 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Wednesday, November 21, 2001 7:35 AM > To: Julian Reschke; mtimmerm@opentext.com; 'WebDAV' > Subject: RE: content type for WebDAV request/response bodies, was: [ACL] > Access Control Protocol -07 submitted > > .. > > You ask how to map : since it ends in 'e', > add a '#', and it becomes "http://a.b.c/d#e#foo". When going back to real > XML form, scan backward from the end for the last '#', remove it. But "http://a.b.c/d#e#foo" isn't a valid URI (reference), right? From w3c-dist-auth-request@w3.org Wed Nov 21 13:59: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 NAA29750 for ; Wed, 21 Nov 2001 13:59:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA03726; Wed, 21 Nov 2001 13:57:40 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 13:57:40 -0500 (EST) Resent-Message-Id: <200111211857.NAA03726@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA03640 for ; Wed, 21 Nov 2001 13:57:13 -0500 (EST) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA31625 for ; Wed, 21 Nov 2001 13:57:11 -0500 Received: from moose ([198.144.203.249]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id fALIuvQ84542; Wed, 21 Nov 2001 10:56:57 -0800 (PST) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: "Julian Reschke" , , "'WebDAV'" Date: Tue, 20 Nov 2001 22:54:53 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5629 X-Loop: w3c-dist-auth@w3.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 Where I saw this used, it wasn't supposed to be a valid URI. It was just supposed to be a way of representing DAV property names to systems that only supported name/value pairs, rather than namespace/name/value tuples. lisa > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Wednesday, November 21, 2001 10:41 AM > To: Lisa Dusseault; Julian Reschke; mtimmerm@opentext.com; 'WebDAV' > Subject: RE: content type for WebDAV request/response bodies, was: [ACL] > Access Control Protocol -07 submitted > > > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > Sent: Wednesday, November 21, 2001 7:35 AM > > To: Julian Reschke; mtimmerm@opentext.com; 'WebDAV' > > Subject: RE: content type for WebDAV request/response bodies, was: [ACL] > > Access Control Protocol -07 submitted > > > > .. > > > > You ask how to map : since it > ends in 'e', > > add a '#', and it becomes "http://a.b.c/d#e#foo". When going > back to real > > XML form, scan backward from the end for the last '#', remove it. > > But "http://a.b.c/d#e#foo" isn't a valid URI (reference), right? From w3c-dist-auth-request@w3.org Wed Nov 21 14:26: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 OAA01243 for ; Wed, 21 Nov 2001 14:26:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA08360; Wed, 21 Nov 2001 14:25:03 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 14:25:03 -0500 (EST) Resent-Message-Id: <200111211925.OAA08360@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA08089 for ; Wed, 21 Nov 2001 14:24:40 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA04634 for ; Wed, 21 Nov 2001 14:24:40 -0500 Received: (qmail 12955 invoked by uid 0); 21 Nov 2001 19:24:09 -0000 Received: from pd9e51f64.dip.t-dialin.net (HELO lisa) (217.229.31.100) by mail.gmx.net (mp006-rz3) with SMTP; 21 Nov 2001 19:24:09 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "Julian Reschke" , , "'WebDAV'" Date: Wed, 21 Nov 2001 20:24:06 +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 V6.00.2600.0000 In-Reply-To: Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5631 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit OK, then it's much easier to use Jim Clark's: {namespaceUri}name Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, November 21, 2001 7:55 AM > To: Julian Reschke; mtimmerm@opentext.com; 'WebDAV' > Subject: RE: content type for WebDAV request/response bodies, was: [ACL] > Access Control Protocol -07 submitted > > > Where I saw this used, it wasn't supposed to be a valid URI. It was just > supposed to be a way of representing DAV property names to > systems that only > supported name/value pairs, rather than namespace/name/value tuples. > > lisa > > > -----Original Message----- > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > Sent: Wednesday, November 21, 2001 10:41 AM > > To: Lisa Dusseault; Julian Reschke; mtimmerm@opentext.com; 'WebDAV' > > Subject: RE: content type for WebDAV request/response bodies, was: [ACL] > > Access Control Protocol -07 submitted > > > > > > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > > Sent: Wednesday, November 21, 2001 7:35 AM > > > To: Julian Reschke; mtimmerm@opentext.com; 'WebDAV' > > > Subject: RE: content type for WebDAV request/response bodies, > was: [ACL] > > > Access Control Protocol -07 submitted > > > > > > .. > > > > > > You ask how to map : since it > > ends in 'e', > > > add a '#', and it becomes "http://a.b.c/d#e#foo". When going > > back to real > > > XML form, scan backward from the end for the last '#', remove it. > > > > But "http://a.b.c/d#e#foo" isn't a valid URI (reference), right? > From w3c-dist-auth-request@w3.org Wed Nov 21 14:52: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 OAA02525 for ; Wed, 21 Nov 2001 14:52:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA15085; Wed, 21 Nov 2001 14:50:51 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 14:50:51 -0500 (EST) Resent-Message-Id: <200111211950.OAA15085@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA15026 for ; Wed, 21 Nov 2001 14:50:29 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA09841 for ; Wed, 21 Nov 2001 14:50:28 -0500 Received: (qmail 5761 invoked by uid 0); 21 Nov 2001 19:49:57 -0000 Received: from pd9e51f64.dip.t-dialin.net (HELO lisa) (217.229.31.100) by mail.gmx.net (mp009-rz3) with SMTP; 21 Nov 2001 19:49:57 -0000 From: "Julian Reschke" To: , "'Julian Reschke'" , "'Lisa Dusseault'" , "'WebDAV'" Date: Wed, 21 Nov 2001 20:49:54 +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 V6.00.2600.0000 In-Reply-To: <001201c172bf$e23070f0$d482a8c0@mt2k> Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5632 X-Loop: w3c-dist-auth@w3.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: Matt Timmermans [mailto:mtimmerm@opentext.com] > Sent: Wednesday, November 21, 2001 8:08 PM > To: 'Julian Reschke'; 'Lisa Dusseault'; 'WebDAV' > Subject: RE: content type for WebDAV request/response bodies, was: [ACL] > Access Control Protocol -07 submitted > > ... > > If we must have an encoding scheme for property URIs, and I think we must, > then it would help interoperability to conform to Microsoft's wherever > possible. Why do you think that we need an encoding scheme? And does the encoding scheme need to produce URIs, or will any Unicode string do? I think that identifying properties using the pair (namespace name, local name) is just fine, and how a server treats this internally shouldn't be of any concern to the spec. From w3c-dist-auth-request@w3.org Wed Nov 21 15:09: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 NAA29275 for ; Wed, 21 Nov 2001 13:46:25 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA01658; Wed, 21 Nov 2001 13:37:04 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 13:37:04 -0500 (EST) Resent-Message-Id: <200111211837.NAA01658@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA01631 for ; Wed, 21 Nov 2001 13:36:58 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA27753 for ; Wed, 21 Nov 2001 13:36:57 -0500 Received: (qmail 31657 invoked by uid 0); 21 Nov 2001 18:36:53 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp007-rz3) with SMTP; 21 Nov 2001 18:36:53 -0000 From: "Julian Reschke" To: , "'Julian Reschke'" , "'WebDAV'" Date: Wed, 21 Nov 2001 19:36:53 +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 V6.00.2600.0000 In-Reply-To: <001001c172ba$0cac8180$d482a8c0@mt2k> Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5625 X-Loop: w3c-dist-auth@w3.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 Well, that's not what your algorithm said, right? > -----Original Message----- > From: Matt Timmermans [mailto:mtimmerm@opentext.com] > Sent: Wednesday, November 21, 2001 7:27 PM > To: 'Julian Reschke'; 'WebDAV' > Subject: RE: content type for WebDAV request/response bodies, was: [ACL] > Access Control Protocol -07 submitted > > > > -----Original Message----- > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > > so how do you map > > > > > > > http://a.b.c/d#f%23oo > From w3c-dist-auth-request@w3.org Wed Nov 21 15:51:48 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 PAA05226 for ; Wed, 21 Nov 2001 15:51:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA20685; Wed, 21 Nov 2001 15:46:24 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 15:46:24 -0500 (EST) Resent-Message-Id: <200111212046.PAA20685@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA20639 for ; Wed, 21 Nov 2001 15:46:10 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA18235 for ; Wed, 21 Nov 2001 15:46:09 -0500 Received: (qmail 15367 invoked by uid 0); 21 Nov 2001 20:45:17 -0000 Received: from pd9e51f64.dip.t-dialin.net (HELO lisa) (217.229.31.100) by mail.gmx.net (mp005-rz3) with SMTP; 21 Nov 2001 20:45:17 -0000 From: "Julian Reschke" To: "Jim Whitehead" , , Date: Wed, 21 Nov 2001 21:45:15 +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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5633 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Wednesday, November 21, 2001 7:07 PM > To: w3c-dist-auth@w3.org; uri@w3.org > Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > > > > * WebDAV marshals "dav:" URIs that are the name of XML elements as a > > > {namespace} + {opaque_part} pair. So, for example, > > "dav:creationdate" is . > > > > RFC2518 says *nothing* about URIs in the DAV: URI scheme. RFC2518 itself > > never says that an element name or a property "has" a URI. > > Section 18 clearly states that "The property names and XML > elements in this > specification are all derived from the base URI DAV: by adding a suffix to > this URI, for example, DAV:creationdate for the 'creationdate' property." > > Now, we've had discussion on the WebDAV list to move away from this > position, and more towards the {namespace identifier} + {name} position > embedded within the XML namespace draft. This strikes me as a good thing. > > ... I just notice that the ACL spec says: 14 IANA CONSIDERATIONS This document uses the namespace defined by [RFC2518] for XML elements. All other IANA considerations mentioned in [RFC2518] also applicable to WebDAV ACL. So maybe this needs to be clarified. We don't want a new spec to normatively refer to a deprecated section of RFC2518, right? From w3c-dist-auth-request@w3.org Wed Nov 21 16:20: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 QAA06810 for ; Wed, 21 Nov 2001 16:20:11 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA05917; Wed, 21 Nov 2001 14:09:52 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 14:09:52 -0500 (EST) Resent-Message-Id: <200111211909.OAA05917@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA05591 for ; Wed, 21 Nov 2001 14:09:04 -0500 (EST) Received: from opentext.com (drawbridge.opentext.com [204.138.115.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA02236 for ; Wed, 21 Nov 2001 14:09:04 -0500 Received: from mt2k (212.dhcp.ott.opentext.com [192.168.130.212]) by opentext.com (8.9.3/8.9.3) with SMTP id OAA17830; Wed, 21 Nov 2001 14:08:21 -0500 Reply-To: From: "Matt Timmermans" To: "'Julian Reschke'" , "'Lisa Dusseault'" , "'WebDAV'" Date: Wed, 21 Nov 2001 14:08:18 -0500 Message-ID: <001201c172bf$e23070f0$d482a8c0@mt2k> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5630 X-Loop: w3c-dist-auth@w3.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 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > But "http://a.b.c/d#e#foo" isn't a valid URI (reference), right? It is if you uri-escape the added '#' to get http:/a.b.c/d#e%23foo I wasn't as detailed as I could have been about the algorithm, because these particular details aren't important. There are any number of injective encodings you might devise. The important part is the decision about whether to add '#' or to just concatenate. Most people have started making sure that their namespaces end in ':' or '/', depending on whether they use URNs or URLs. This is especially true for WebDAV developers who might think about a property's URI, and don't want the local name to merge with a final path segment. This URI encoding scheme preserves element identity in accordance with XMLNS, while maintaining backward compatability for these existing systems. Microsoft is the only implementor I know of that makes extensive use of property URIs (I think they use them a lot in their DASL implementation). It's just one implementor, but it's an important one, and they already have an encoding scheme for property URIs that makes some sense. If we must have an encoding scheme for property URIs, and I think we must, then it would help interoperability to conform to Microsoft's wherever possible. From w3c-dist-auth-request@w3.org Wed Nov 21 17:21:17 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 RAA11211 for ; Wed, 21 Nov 2001 17:21:17 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA28337; Wed, 21 Nov 2001 17:16:13 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 17:16:13 -0500 (EST) Resent-Message-Id: <200111212216.RAA28337@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA28310 for ; Wed, 21 Nov 2001 17:16:06 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA01738 for ; Wed, 21 Nov 2001 17:16:07 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id OAA24032 for ; Wed, 21 Nov 2001 14:16:10 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 21 Nov 2001 14:15:48 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FW: [Moderator Action] Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5634 X-Loop: w3c-dist-auth@w3.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 "distobj@acm.org" to the accept2 list. - Jim -----Original Message----- From: Mark Baker [mailto:distobj@acm.org] Sent: Wednesday, November 21, 2001 1:56 PM To: Martin Duerst Cc: Jim Whitehead; w3c-dist-auth@w3.org; uri@w3.org Subject: [Moderator Action] Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > Well, it's not WebDAV's business to mess around with bases for > namespaces. Namespaces don't currently use XML Base, and probably > they won't in the future. There was an extensive discussion of > whether namespace uris could be relative uris, and the conclusion > as far as I remember was that it should be discouraged. That decision[1] deprecated the use of relative URI for namespace names *for W3C work*. While certainly a cautionary note to others, I don't see how it can prevent work done outside the W3C from using them. [1] http://www.w3.org/2000/09/xppa MB -- Mark Baker, CSO, Planetfred. Ottawa, Ontario, CANADA. mbaker@planetfred.com From w3c-dist-auth-request@w3.org Wed Nov 21 17:23:42 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 RAA11344 for ; Wed, 21 Nov 2001 17:23:42 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA28962; Wed, 21 Nov 2001 17:18:58 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 17:18:58 -0500 (EST) Resent-Message-Id: <200111212218.RAA28962@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA28942 for ; Wed, 21 Nov 2001 17:18:48 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA02045 for ; Wed, 21 Nov 2001 17:18:48 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id OAA24704 for ; Wed, 21 Nov 2001 14:18:52 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 21 Nov 2001 14:18:30 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5635 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Mark Baker [mailto:distobj@acm.org] Sent: Tuesday, November 20, 2001 7:52 PM To: Jim Whitehead Cc: w3c-dist-auth@w3.org; uri@w3.org Subject: [Moderator Action] Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Hi Jim, > As a result, I recommend that the XML namespace recommendation be modified > to allow the use of just the URI scheme name as a namespace identifier, > perhaps limited to just members of the set of non-hierarchical URIs. It > seems clear to me that the XML namespace recommendation was written with > only the class of hierarchical URIs in mind, I can't see why you'd believe that. Namespaces are often URNs, for example. > and as a result it's not too > surprising that a glitch arose in the first use with non-hierarchical URIs. > Based on Julian's experience, and our experience with multiple WebDAV > implementations, accepting a URI scheme name as a namespace identifier would > codify existing, interoperable, practice. IMO, a URI scheme has identity, and so should be able to be identified by a URI reference. Perhaps a compromise here would be to treat "DAV:" as a relative URI reference. A 2518 revision could include the use of XML Base, or its own base-declaring mechanism, allowing future DAV specifications and processors to use URIs to evolve, while existing processors could be seen to be assuming a base URI. Thoughts? MB -- Mark Baker, CSO, Planetfred. Ottawa, Ontario, CANADA. mbaker@planetfred.com From w3c-dist-auth-request@w3.org Wed Nov 21 19:56:38 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 TAA15014 for ; Wed, 21 Nov 2001 19:56:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA09336; Wed, 21 Nov 2001 19:47:09 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 19:47:09 -0500 (EST) Resent-Message-Id: <200111220047.TAA09336@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA09313 for ; Wed, 21 Nov 2001 19:47:02 -0500 (EST) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA21936 for ; Wed, 21 Nov 2001 19:47:02 -0500 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id fAM0lWk17991 for ; Wed, 21 Nov 2001 16:47:32 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id fAM0kWS24617 for ; Wed, 21 Nov 2001 16:46:32 -0800 (PST) Received: from [192.168.1.4] ([130.248.188.65]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GN6FH300.E13; Wed, 21 Nov 2001 16:46:15 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj-v1.corp.adobe.com Message-Id: In-Reply-To: <3906C56A7BD1F54593344C05BD1374B104EC8AF8@SUS-MA1IT01> References: <3906C56A7BD1F54593344C05BD1374B104EC8AF8@SUS-MA1IT01> Date: Wed, 21 Nov 2001 16:29:15 -0800 To: "Clemm, Geoff" From: Daniel Brotsky Cc: Webdav WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: [ACL] Principal Identity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5636 X-Loop: w3c-dist-auth@w3.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 8:11 AM -0500 11/21/01, Clemm, Geoff wrote: >I believe that when we revise 2518, that that the >new DAV:allprop behavior should be defined to be >"all live properties defined in RFC 2518 plus all >dead properties". This works fine for me if we allow for server "discretion" by saying "at least all live properties defined in RFC 2518 plus all dead properties." Servers that *want* to show live properties should not be prohibited from doing so. My motivation for this (other than common sense :^) is that I believe many generic clients use ALLPROP as a way of saying "show me everything I'm likely to care about." Some servers will have a number of general-interest properties that are live and useful in such a list; for example, workflow servers often have live properties indicating status, assignee, and those kinds of things. It would be awkward if 2518++ prohibited them from showing these in response to an ALLPROP. dan > Since 2518 states that it is *all* >properties (both live and dead), making this direction >clear now will allow clients to rely on dead+2518 >properties. > >Cheers, >Geoff > >-----Original Message----- >From: Lisa Dusseault [mailto:lisa@xythos.com] >Sent: Tuesday, November 20, 2001 1:40 AM >To: Stefan Eissing; Jim Whitehead; Webdav WG >Subject: RE: [ACL] Principal Identity > > > > >> The nice thing about allprop is that you get all the dead properties. >> The bad thing about allprop is that you cannot see if a resource is >> versioned/version or which methods it does support. > >How do you know you can get all the dead properties? 'allprop' as defined >in RFC2518 seems to have to change, yet we've not clearly defined a new >behaviour. In the meantime, I don't believe clients can rely on getting >anything back in 'allprop' except the live properties defined in RFC2518. > >Lisa -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Wed Nov 21 20:55: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 UAA16049 for ; Wed, 21 Nov 2001 20:55:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA12719; Wed, 21 Nov 2001 20:47:48 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 20:47:48 -0500 (EST) Resent-Message-Id: <200111220147.UAA12719@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA12699 for ; Wed, 21 Nov 2001 20:47:37 -0500 (EST) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA26993 for ; Wed, 21 Nov 2001 20:47:36 -0500 Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id fAM1m8k27012 for ; Wed, 21 Nov 2001 17:48:08 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id fAM1kC100148 for ; Wed, 21 Nov 2001 17:46:12 -0800 (PST) Received: from [192.168.1.4] ([130.248.188.65]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GN6IAC00.QC6; Wed, 21 Nov 2001 17:47:00 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj-v1.corp.adobe.com Message-Id: In-Reply-To: References: Date: Wed, 21 Nov 2001 17:28:13 -0800 To: "Lisa Dusseault" From: Daniel Brotsky Cc: "Clemm, Geoff" , "Webdav WG" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: [ACL] Principal Identity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5637 X-Loop: w3c-dist-auth@w3.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 10:35 PM -0800 11/20/01, Lisa Dusseault wrote: >The definition of dead properties is not clear enough to make that proposal >a basis for interoperability. > >... Can clients >rely on these properties being listed in 'allprop' or not? On some servers >but not on others? Ugh. > >That's why I think only a fixed list of properties can be relied upon to be >in allprop. Let's rely on 'propname' to actually tell us the complete list >of properties, whether they're alive, dead, or somewhere in between. You and I seem to be going in exact opposite directions on this one, and I think it's because we have different ideas of what constitutes interoperability with respect to ALLPROP. You seem to feel that interoperability means that all servers return the same properties in response to an ALLPROP. And I would agree that this can only be satisfied by specifying ALLPROP as meaning a fixed set of properties, as you suggest. I feel that interoperability means that existing clients will continue to work "as well as possible" with the new definition of ALLPROP. Since ALLPROP originally meant "all properties," and the objection has been "that can be too expensive for servers," I think the compromise is to have ALLPROP mean "as many of the defined properties as the server feels it's reasonable to compute." I think Geoff's suggestion (DAV live props and all dead ones) is a good guideline for servers, both because these properties are presumably cheap and because an existing client who just set a dead property is likely to be very surprised when ALLPROP doesn't return it. I suggested adding "at least" because I think that gives servers the proper control over just how interoperable they want to be with old clients. Probably the place you and I really agree is that we'd both rather see ALLPROP go away entirely :^). But I think we also agree that such a move would be too backward-incompatible. dan > >Lisa > >> -----Original Message----- >> From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff >> Sent: Wednesday, November 21, 2001 5:11 AM >> To: Webdav WG >> Subject: RE: [ACL] Principal Identity >> >> >> I believe that when we revise 2518, that that the >> new DAV:allprop behavior should be defined to be >> "all live properties defined in RFC 2518 plus all >> dead properties". Since 2518 states that it is *all* >> properties (both live and dead), making this direction >> clear now will allow clients to rely on dead+2518 >> properties. >> >> Cheers, >> Geoff >> >> -----Original Message----- >> From: Lisa Dusseault [mailto:lisa@xythos.com] >> Sent: Tuesday, November 20, 2001 1:40 AM >> To: Stefan Eissing; Jim Whitehead; Webdav WG >> Subject: RE: [ACL] Principal Identity >> >> >> >> >> > The nice thing about allprop is that you get all the dead properties. >> > The bad thing about allprop is that you cannot see if a resource is >> > versioned/version or which methods it does support. >> >> How do you know you can get all the dead properties? 'allprop' as defined >> in RFC2518 seems to have to change, yet we've not clearly defined a new >> behaviour. In the meantime, I don't believe clients can rely on getting >> anything back in 'allprop' except the live properties defined in RFC2518. >> >> Lisa -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: From w3c-dist-auth-request@w3.org Wed Nov 21 22:03:14 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 WAA18979 for ; Wed, 21 Nov 2001 22:03:14 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA14176; Wed, 21 Nov 2001 21:54:18 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 21:54:18 -0500 (EST) Resent-Message-Id: <200111220254.VAA14176@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA14151 for ; Wed, 21 Nov 2001 21:53:55 -0500 (EST) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA31335 for ; Wed, 21 Nov 2001 21:53:55 -0500 Received: from moose ([198.144.203.249]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id fAM2riQ36143; Wed, 21 Nov 2001 18:53:45 -0800 (PST) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: "Daniel Brotsky" Cc: "Clemm, Geoff" , "Webdav WG" Date: Wed, 21 Nov 2001 06:51:37 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: RE: [ACL] Principal Identity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5638 X-Loop: w3c-dist-auth@w3.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 feel that interoperability means that existing clients will > continue to work "as well as possible" with the new definition of > ALLPROP. Since ALLPROP originally meant "all properties," and the > objection has been "that can be too expensive for servers," I think > the compromise is to have ALLPROP mean "as many of the defined > properties as the server feels it's reasonable to compute." You have a very good point - existing clients will expect to see dead properties. > I think Geoff's suggestion (DAV live props and all dead ones) is a > good guideline for servers, both because these properties are > presumably cheap and because an existing client who just set a dead > property is likely to be very surprised when ALLPROP doesn't return > it. I suggested adding "at least" because I think that gives servers > the proper control over just how interoperable they want to be with > old clients. However, although that proposal supports existing clients better, it isn't clearly defined, as I explained in a previous email today. > Probably the place you and I really agree is that we'd both rather > see ALLPROP go away entirely :^). But I think we also agree that > such a move would be too backward-incompatible. It's clear new clients must not expect allprop to mean all properties, but we also agree that old clients must be able to operate. However if we can't define a clear behaviour for allprop or some replacement, then perhaps we should simply discourage use of allprop in revised 2518. Lisa From w3c-dist-auth-request@w3.org Wed Nov 21 23:33: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 XAA21694 for ; Wed, 21 Nov 2001 23:33:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA17765; Wed, 21 Nov 2001 23:28:05 -0500 (EST) Resent-Date: Wed, 21 Nov 2001 23:28:05 -0500 (EST) Resent-Message-Id: <200111220428.XAA17765@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA17745 for ; Wed, 21 Nov 2001 23:27:54 -0500 (EST) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA06156 for ; Wed, 21 Nov 2001 23:27:54 -0500 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id fAM4SNk16581 for ; Wed, 21 Nov 2001 20:28:23 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id fAM4RXS29707 for ; Wed, 21 Nov 2001 20:27:33 -0800 (PST) Received: from [192.168.1.4] ([130.248.188.65]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GN6PPG00.2Q3; Wed, 21 Nov 2001 20:27:16 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj-v1.corp.adobe.com Message-Id: In-Reply-To: References: Date: Wed, 21 Nov 2001 20:27:11 -0800 To: "Lisa Dusseault" From: Daniel Brotsky Cc: "Clemm, Geoff" , "Webdav WG" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: [ACL] Principal Identity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5639 X-Loop: w3c-dist-auth@w3.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:51 AM -0800 11/21/01, Lisa Dusseault wrote: > > I feel that interoperability means that existing clients will >> continue to work "as well as possible" with the new definition of >> ALLPROP. Since ALLPROP originally meant "all properties," and the >> objection has been "that can be too expensive for servers," I think >> the compromise is to have ALLPROP mean "as many of the defined >> properties as the server feels it's reasonable to compute." >You have a very good point - existing clients will expect to see dead >properties. > >> I think Geoff's suggestion (DAV live props and all dead ones) is a >> good guideline for servers, both because these properties are >> presumably cheap and because an existing client who just set a dead >> property is likely to be very surprised when ALLPROP doesn't return >> it. I suggested adding "at least" because I think that gives servers >> the proper control over just how interoperable they want to be with >> old clients. >However, although that proposal supports existing clients better, it isn't >clearly defined, as I explained in a previous email today. I believe that your example shows well that it's completely up to each server which properties are live and which are dead, and that any given server implementation may allow for configuration that changes this. But that doesn't mean that the notion of a "dead property" is ill-defined for a given server and time of test. Nor does it mean that a requirement that servers return "at least all DAV live properties and all dead properties (i.e., all non-live properties that would give non-404 responses when queried for by name)" can't be tested on any given server at any given time. It simply means that it's at the server's discretion what properties are live, and that no test can be performed unless this is properly documented for the server being tested. > >> Probably the place you and I really agree is that we'd both rather >> see ALLPROP go away entirely :^). But I think we also agree that >> such a move would be too backward-incompatible. >It's clear new clients must not expect allprop to mean all properties, but >we also agree that old clients must be able to operate. However if we can't >define a clear behaviour for allprop or some replacement, then perhaps we >should simply discourage use of allprop in revised 2518. Actually I think we should do both :^). I think we should adopt Geoff's proposed semantics for ALLPROP (with my "at least" addition), and I think we should *also* deprecate the use of ALLPROP by generic clients. That way ALLPROP clearly becomes (i) a "quick and dirty" way of looking at an asset that's primarily used by older generic clients and is supported in that usage only for backwards compatibility; and (ii) a shortcut used by server-specific clients who know exactly which properties the server chooses to return on ALLPROP. 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 Nov 22 04:04:02 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 EAA10983 for ; Thu, 22 Nov 2001 04:04:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA27355; Thu, 22 Nov 2001 03:58:36 -0500 (EST) Resent-Date: Thu, 22 Nov 2001 03:58:36 -0500 (EST) Resent-Message-Id: <200111220858.DAA27355@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA27332 for ; Thu, 22 Nov 2001 03:58:13 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA29229 for ; Thu, 22 Nov 2001 03:58:12 -0500 Received: (qmail 3712 invoked by uid 0); 22 Nov 2001 08:57:41 -0000 Received: from pd9535b24.dip.t-dialin.net (HELO lisa) (217.83.91.36) by mail.gmx.net (mp007-rz3) with SMTP; 22 Nov 2001 08:57:41 -0000 From: "Julian Reschke" To: "'WebDAV'" Date: Thu, 22 Nov 2001 09:57:39 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5641 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Wednesday, November 21, 2001 8:50 PM > To: mtimmerm@opentext.com; 'Julian Reschke'; 'Lisa Dusseault'; 'WebDAV' > Subject: RE: content type for WebDAV request/response bodies, was: [ACL] > Access Control Protocol -07 submitted > > > > From: Matt Timmermans [mailto:mtimmerm@opentext.com] > > Sent: Wednesday, November 21, 2001 8:08 PM > > To: 'Julian Reschke'; 'Lisa Dusseault'; 'WebDAV' > > Subject: RE: content type for WebDAV request/response bodies, was: [ACL] > > Access Control Protocol -07 submitted > > > > ... > > > > If we must have an encoding scheme for property URIs, and I > think we must, > > then it would help interoperability to conform to Microsoft's wherever > > possible. > > Why do you think that we need an encoding scheme? > > And does the encoding scheme need to produce URIs, or will any Unicode > string do? > > I think that identifying properties using the pair (namespace name, local > name) is just fine, and how a server treats this internally > shouldn't be of > any concern to the spec. Another one: what's the point of having a URI for a WebDAV property? Is the underlying assumption that if the URIs of two properties are equivalent, the properties are identical? In which case: this won't work: the scheme name is case insensitive, the definition of equivalence for the scheme-specific-part is up to the URI scheme, so how could a program know them all? Consider: a) b) c) According to XML NS and RFC2518, all these properties are different (because namespace matching is done character by character). However, the namespace URIs in a) and b) are equivalent as per RFC2396, section 6. c's namespace name would be equivalent, depending on whether the program knows the equivalence rules for this particular URI scheme. From w3c-dist-auth-request@w3.org Thu Nov 22 04:04:54 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 EAA11001 for ; Thu, 22 Nov 2001 04:04:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA27245; Thu, 22 Nov 2001 03:56:12 -0500 (EST) Resent-Date: Thu, 22 Nov 2001 03:56:12 -0500 (EST) Resent-Message-Id: <200111220856.DAA27245@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA27218 for ; Thu, 22 Nov 2001 03:55:49 -0500 (EST) 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 DAA28408 for ; Thu, 22 Nov 2001 03:55:48 -0500 Received: from apu [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Thu, 22 Nov 2001 09:55:09 +0100 From: "Stefan Eissing" To: "'WebDAV'" Date: Thu, 22 Nov 2001 09:56:57 +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: <001201c172bf$e23070f0$d482a8c0@mt2k> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5640 X-Loop: w3c-dist-auth@w3.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 Matt Timmermans > Sent: Wednesday, November 21, 2001 8:08 PM > > [...] > > This URI encoding scheme preserves element identity in accordance with > XMLNS, while maintaining backward compatability for these > existing systems. > Microsoft is the only implementor I know of that makes extensive use of > property URIs (I think they use them a lot in their DASL implementation). > It's just one implementor, but it's an important one, and they > already have > an encoding scheme for property URIs that makes some sense. > > If we must have an encoding scheme for property URIs, and I think we must, > then it would help interoperability to conform to Microsoft's wherever > possible. Sorry, I must have missed that. Why do we need property URIs as compared to identifiers like {namespaceuri}localname? In which specification are they used? //Stefan From w3c-dist-auth-request@w3.org Thu Nov 22 04:12: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 EAA11070 for ; Thu, 22 Nov 2001 04:12:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA28160; Thu, 22 Nov 2001 04:10:26 -0500 (EST) Resent-Date: Thu, 22 Nov 2001 04:10:26 -0500 (EST) Resent-Message-Id: <200111220910.EAA28160@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA28134 for ; Thu, 22 Nov 2001 04:09:57 -0500 (EST) 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 EAA30224 for ; Thu, 22 Nov 2001 04:09:54 -0500 Received: from apu [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Thu, 22 Nov 2001 10:09:21 +0100 From: "Stefan Eissing" To: "WebDAV" , Date: Thu, 22 Nov 2001 10:11:09 +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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5642 X-Loop: w3c-dist-auth@w3.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 Unfortunately, "DAV:" is no legal URI reference either. RFC 2396 explicitly forbids ':' in relative path's first segment... //Stefan > From: Mark Baker [mailto:distobj@acm.org] > Sent: Tuesday, November 20, 2001 7:52 PM > > Hi Jim, > > > As a result, I recommend that the XML namespace recommendation > be modified > > to allow the use of just the URI scheme name as a namespace identifier, > > perhaps limited to just members of the set of non-hierarchical URIs. It > > seems clear to me that the XML namespace recommendation was written with > > only the class of hierarchical URIs in mind, > > I can't see why you'd believe that. Namespaces are often URNs, for > example. > > > and as a result it's not too > > surprising that a glitch arose in the first use with non-hierarchical > URIs. > > Based on Julian's experience, and our experience with multiple WebDAV > > implementations, accepting a URI scheme name as a namespace identifier > would > > codify existing, interoperable, practice. > > IMO, a URI scheme has identity, and so should be able to be identified > by a URI reference. > > Perhaps a compromise here would be to treat "DAV:" as a relative URI > reference. A 2518 revision could include the use of XML Base, or its > own base-declaring mechanism, allowing future DAV specifications and > processors to use URIs to evolve, while existing processors could be > seen to be assuming a base URI. Thoughts? > > MB > -- > Mark Baker, CSO, Planetfred. > Ottawa, Ontario, CANADA. > mbaker@planetfred.com > > From w3c-dist-auth-request@w3.org Thu Nov 22 04:25: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 EAA11256 for ; Thu, 22 Nov 2001 04:25:21 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA28910; Thu, 22 Nov 2001 04:23:27 -0500 (EST) Resent-Date: Thu, 22 Nov 2001 04:23:27 -0500 (EST) Resent-Message-Id: <200111220923.EAA28910@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA28885 for ; Thu, 22 Nov 2001 04:22:55 -0500 (EST) 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 EAA31347 for ; Thu, 22 Nov 2001 04:22:55 -0500 Received: from apu [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Thu, 22 Nov 2001 10:22:24 +0100 From: "Stefan Eissing" To: "Lisa Dusseault" , "Webdav WG" Date: Thu, 22 Nov 2001 10:24:12 +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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: RE: [ACL] Principal Identity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5643 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, November 21, 2001 7:35 AM > To: Clemm, Geoff; Webdav WG > Subject: RE: [ACL] Principal Identity > > > The definition of dead properties is not clear enough to make > that proposal > a basis for interoperability. > > Since I love examples, follow me through this one: > - A WebDAV client software package defines a couple dead properties, > "image-height" and "image-width" as integers. It sets these properties on > all images it saves & uses them later. Obviously so far it's a dead > property. > - Other clients start to use these. Still dead, right? > - Custom software is added onto another WebDAV server platform > to set these > properties auto-magically whenever an image is uploaded. The base server > software is uninvolved in this process. > - A full WebDAV server decides to make sure that whenever these > properties > are set, at least they're integers. Maybe it also checks they're not > negative. Other servers, however, still ignore these properties. > - Another DAV server decides that it can calculate this property > on the fly > and make sure it's always correct. However, the calculation is expensive > (Note that this scenario starts to sound like justification for NOT > including properties in allprop). > > When do these properties stop being dead and start being live? It depends if and where and how they are defined. Just having a property "image-height" accepted or returned by a server does not mean anything. If you define such a property, you should also define the expected behaviour, its liveliness and, etc. Some servers will then implement it, while for other servers these properties are really dead. So, the existence of such properties on a server will not tell a client anything about their semantics. You need to introduce some other way to announce this to a client. The defined way to do so, is to include these properties in the {DAV:}supported-live-property-set. Then the client knows that the server gives special meaning to these properties. Coming back to : a dead "image-height" property would be reported, while a live property would not be reported. A client interested in seeing "image-height" in either case, should attach a ... to allprop in our proposal. //Stefan From w3c-dist-auth-request@w3.org Thu Nov 22 04:39: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 EAA11401 for ; Thu, 22 Nov 2001 04:39:55 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA29526; Thu, 22 Nov 2001 04:37:34 -0500 (EST) Resent-Date: Thu, 22 Nov 2001 04:37:34 -0500 (EST) Resent-Message-Id: <200111220937.EAA29526@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA29486 for ; Thu, 22 Nov 2001 04:37:02 -0500 (EST) 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 EAA32338 for ; Thu, 22 Nov 2001 04:37:01 -0500 Received: from apu [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Thu, 22 Nov 2001 10:36:26 +0100 From: "Stefan Eissing" To: "Daniel Brotsky" Cc: "Webdav WG" Date: Thu, 22 Nov 2001 10:38:14 +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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: RE: [ACL] Principal Identity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5644 X-Loop: w3c-dist-auth@w3.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 Daniel Brotsky > Sent: Thursday, November 22, 2001 1:29 AM > > At 8:11 AM -0500 11/21/01, Clemm, Geoff wrote: > >I believe that when we revise 2518, that that the > >new DAV:allprop behavior should be defined to be > >"all live properties defined in RFC 2518 plus all > >dead properties". > > This works fine for me if we allow for server "discretion" by saying > "at least all live properties defined in RFC 2518 plus all dead > properties." Servers that *want* to show live properties should not > be prohibited from doing so. > > My motivation for this (other than common sense :^) is that I believe > many generic clients use ALLPROP as a way of saying "show me > everything I'm likely to care about." Some servers will have a > number of general-interest properties that are live and useful in > such a list; for example, workflow servers often have live properties > indicating status, assignee, and those kinds of things. It would be > awkward if 2518++ prohibited them from showing these in response to > an ALLPROP. I follow your motivation but not your conclusion. Let's stick to the workflow properties (workprops) example: A generic client will survive workprops returned from an allprop, sure. But will it be able to do anything with it? Most likely not. A workflow client will need the workprops returned from the server. Now there are four possible cases: 1) the client does not use but ...list... 2) the client uses and the server returns the workprops with allprop, even though they are live properties. 3) the client uses and the server does not return the workprops, because the server does not know these properties. 4) the client uses and the server does not return the workprops. The server implements the workprops, but it does not return those on allprop. 1) does not need your allprop "at least" extension, 2) works as you intended, 3) is working, although the client cannot distinguish it from 4), and 4) is not working. What would fix your situtation is implementing our proposal. The server would then know when to return the workprops, and a client knows that the server does not implement workprops if they are not returned. //Stefan From w3c-dist-auth-request@w3.org Thu Nov 22 08:08:16 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 IAA14193 for ; Thu, 22 Nov 2001 08:08:16 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA14559; Thu, 22 Nov 2001 08:06:22 -0500 (EST) Resent-Date: Thu, 22 Nov 2001 08:06:22 -0500 (EST) Resent-Message-Id: <200111221306.IAA14559@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA14530 for ; Thu, 22 Nov 2001 08:06:08 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37184.rational.com [192.229.37.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA20293 for ; Thu, 22 Nov 2001 08:06:08 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 22 Nov 2001 08:05:37 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Nov 2001 08:05:37 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B104EC8C63@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Thu, 22 Nov 2001 08:05:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: [ACL] Principal Identity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5645 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Allowing a server to return a server-defined set of live properties with an ALLPROP is fine with me. I also agree that this should be coupled with a deprecation of the use of ALLPROP by generic clients. This allows a server to chose how "interoperable" it wants to be with existing clients that use ALLPROP, without forcing it to do anything egregiously inefficient (the 2518 properties and dead properties are reasonable to require, because it is extremely unlikely that they will be very expensive to compute). Cheers, Geoff -----Original Message----- From: Daniel Brotsky [mailto:dbrotsky@adobe.com] Sent: Wednesday, November 21, 2001 11:27 PM To: Lisa Dusseault Cc: Clemm, Geoff; Webdav WG Subject: RE: [ACL] Principal Identity At 6:51 AM -0800 11/21/01, Lisa Dusseault wrote: > > I feel that interoperability means that existing clients will >> continue to work "as well as possible" with the new definition of >> ALLPROP. Since ALLPROP originally meant "all properties," and the >> objection has been "that can be too expensive for servers," I think >> the compromise is to have ALLPROP mean "as many of the defined >> properties as the server feels it's reasonable to compute." >You have a very good point - existing clients will expect to see dead >properties. > >> I think Geoff's suggestion (DAV live props and all dead ones) is a >> good guideline for servers, both because these properties are >> presumably cheap and because an existing client who just set a dead >> property is likely to be very surprised when ALLPROP doesn't return >> it. I suggested adding "at least" because I think that gives servers >> the proper control over just how interoperable they want to be with >> old clients. >However, although that proposal supports existing clients better, it isn't >clearly defined, as I explained in a previous email today. I believe that your example shows well that it's completely up to each server which properties are live and which are dead, and that any given server implementation may allow for configuration that changes this. But that doesn't mean that the notion of a "dead property" is ill-defined for a given server and time of test. Nor does it mean that a requirement that servers return "at least all DAV live properties and all dead properties (i.e., all non-live properties that would give non-404 responses when queried for by name)" can't be tested on any given server at any given time. It simply means that it's at the server's discretion what properties are live, and that no test can be performed unless this is properly documented for the server being tested. > >> Probably the place you and I really agree is that we'd both rather >> see ALLPROP go away entirely :^). But I think we also agree that >> such a move would be too backward-incompatible. >It's clear new clients must not expect allprop to mean all properties, but >we also agree that old clients must be able to operate. However if we can't >define a clear behaviour for allprop or some replacement, then perhaps we >should simply discourage use of allprop in revised 2518. Actually I think we should do both :^). I think we should adopt Geoff's proposed semantics for ALLPROP (with my "at least" addition), and I think we should *also* deprecate the use of ALLPROP by generic clients. That way ALLPROP clearly becomes (i) a "quick and dirty" way of looking at an asset that's primarily used by older generic clients and is supported in that usage only for backwards compatibility; and (ii) a shortcut used by server-specific clients who know exactly which properties the server chooses to return on ALLPROP. 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 Nov 22 09:49:16 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 JAA15489 for ; Thu, 22 Nov 2001 09:49:16 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA19501; Thu, 22 Nov 2001 09:46:46 -0500 (EST) Resent-Date: Thu, 22 Nov 2001 09:46:46 -0500 (EST) Resent-Message-Id: <200111221446.JAA19501@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA19473 for ; Thu, 22 Nov 2001 09:46:34 -0500 (EST) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA30857; Thu, 22 Nov 2001 09:46:34 -0500 Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id JAA16896; Thu, 22 Nov 2001 09:51:43 -0500 Message-Id: <200111221451.JAA16896@markbaker.ca> To: stefan.eissing@greenbytes.de (Stefan Eissing) Date: Thu, 22 Nov 2001 09:51:43 -0500 (EST) Cc: w3c-dist-auth@w3.org (WebDAV), uri@w3.org In-Reply-To: from "Stefan Eissing" at Nov 22, 2001 10:11:09 AM From: Mark Baker X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5646 X-Loop: w3c-dist-auth@w3.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 > Unfortunately, "DAV:" is no legal URI reference either. RFC 2396 > explicitly forbids ':' in relative path's first segment... Darn, I thought I checked this. I assume the reason for this is to allow disambiguation between absolute and relative URI references. But, "dav:" isn't a valid URI reference of any kind, so what if we updated 2396 to allow ":" as the last character of the relative path's first segment? Would that break anything? A change to 2396 is obviously a serious thing, but so is not breaking WebDAV, despite its quirkiness wrt namespaces. MB -- Mark Baker, CSO, Planetfred. Ottawa, Ontario, CANADA. mbaker@planetfred.com From w3c-dist-auth-request@w3.org Thu Nov 22 18:01:49 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 SAA22425 for ; Thu, 22 Nov 2001 18:01:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA10316; Thu, 22 Nov 2001 17:54:53 -0500 (EST) Resent-Date: Thu, 22 Nov 2001 17:54:53 -0500 (EST) Resent-Message-Id: <200111222254.RAA10316@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA10293 for ; Thu, 22 Nov 2001 17:54:46 -0500 (EST) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA17529 for ; Thu, 22 Nov 2001 17:54:46 -0500 Received: from moose ([198.144.203.249]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id fAMMsbQ96069; Thu, 22 Nov 2001 14:54:38 -0800 (PST) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: "Stefan Eissing" , "Webdav WG" Date: Thu, 22 Nov 2001 02:52:42 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: RE: [ACL] Principal Identity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5647 X-Loop: w3c-dist-auth@w3.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 defined way to do so, is to include these properties in the > {DAV:}supported-live-property-set. Then the client knows that the > server gives special meaning to these properties. However, supported-live-property-set is not part of RFC2518. Therefore, regular DAV clients cannot rely on knowing what properties are live and what properties are dead on any given server. Therefore, regular DAV clients cannot rely on knowing what properties they will get back on an 'allprop' request if 'allprop' is defined as returning 2518&dead properties. > Coming back to : a dead "image-height" property would > be reported, while a live property would not be reported. A client > interested in seeing "image-height" in either case, should attach > a ... to allprop in our proposal. I think it's simpler to not use allprop at all. Since so few properties may be returned by allprop, and all by propname, why not just use propname & then a specific query? I'd want to see a rather compelling reason before inventing new syntax when existing PROPFIND syntaxes, without allprop, suffice. lisa From w3c-dist-auth-request@w3.org Fri Nov 23 03:07:54 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 DAA15134 for ; Fri, 23 Nov 2001 03:07:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA24738; Fri, 23 Nov 2001 03:02:44 -0500 (EST) Resent-Date: Fri, 23 Nov 2001 03:02:44 -0500 (EST) Resent-Message-Id: <200111230802.DAA24738@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA24712 for ; Fri, 23 Nov 2001 03:02:21 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA30489 for ; Fri, 23 Nov 2001 03:02:20 -0500 Received: (qmail 17069 invoked by uid 0); 23 Nov 2001 08:01:49 -0000 Received: from pd953518b.dip.t-dialin.net (HELO lisa) (217.83.81.139) by mail.gmx.net (mp009-rz3) with SMTP; 23 Nov 2001 08:01:49 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "Stefan Eissing" , "Webdav WG" Date: Fri, 23 Nov 2001 09:01:48 +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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: [ACL] Principal Identity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5648 X-Loop: w3c-dist-auth@w3.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: Thursday, November 22, 2001 11:53 AM > To: Stefan Eissing; Webdav WG > Subject: RE: [ACL] Principal Identity > > > > The defined way to do so, is to include these properties in the > > {DAV:}supported-live-property-set. Then the client knows that the > > server gives special meaning to these properties. > > However, supported-live-property-set is not part of RFC2518. Therefore, > regular DAV clients cannot rely on knowing what properties are > live and what > properties are dead on any given server. Therefore, regular DAV clients > cannot rely on knowing what properties they will get back on an 'allprop' > request if 'allprop' is defined as returning 2518&dead properties. A "regular" client (knowing just RFC2518) will rely on allprop returning *all* properties. A "new" client (aware of deltaV) will know about {DAV:}supported-live-property-set. > > Coming back to : a dead "image-height" property would > > be reported, while a live property would not be reported. A client > > interested in seeing "image-height" in either case, should attach > > a ... to allprop in our proposal. > > I think it's simpler to not use allprop at all. Since so few > properties may > be returned by allprop, and all by propname, why not just use propname & > then a specific query? I'd want to see a rather compelling reason before > inventing new syntax when existing PROPFIND syntaxes, without allprop, > suffice. The existing RFC2518 syntax does suffice. However, that was modified in deltaV and ACL. We just think that the modification isn't complete without the inclusion facility. The compelling reason again is: performance (one requests rather than two). From w3c-dist-auth-request@w3.org Fri Nov 23 03:57:05 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 DAA15649 for ; Fri, 23 Nov 2001 03:57:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA26045; Fri, 23 Nov 2001 03:55:51 -0500 (EST) Resent-Date: Fri, 23 Nov 2001 03:55:51 -0500 (EST) Resent-Message-Id: <200111230855.DAA26045@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA26025 for ; Fri, 23 Nov 2001 03:55:30 -0500 (EST) 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 DAA02056 for ; Fri, 23 Nov 2001 03:55:29 -0500 Received: from apu [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Fri, 23 Nov 2001 09:54:27 +0100 From: "Stefan Eissing" To: "Lisa Dusseault" , "Webdav WG" Date: Fri, 23 Nov 2001 09:56:15 +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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MDRemoteIP: 192.168.1.2 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: RE: [ACL] Principal Identity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5649 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Thursday, November 22, 2001 11:53 AM > > > The defined way to do so, is to include these properties in the > > {DAV:}supported-live-property-set. Then the client knows that the > > server gives special meaning to these properties. > > However, supported-live-property-set is not part of RFC2518. Therefore, > regular DAV clients cannot rely on knowing what properties are > live and what > properties are dead on any given server. Therefore, regular DAV clients > cannot rely on knowing what properties they will get back on an 'allprop' > request if 'allprop' is defined as returning 2518&dead properties. > > > Coming back to : a dead "image-height" property would > > be reported, while a live property would not be reported. A client > > interested in seeing "image-height" in either case, should attach > > a ... to allprop in our proposal. > > I think it's simpler to not use allprop at all. Since so few > properties may > be returned by allprop, and all by propname, why not just use propname & > then a specific query? I'd want to see a rather compelling reason before > inventing new syntax when existing PROPFIND syntaxes, without allprop, > suffice. Well, I don't know if this is compelling for you, but reasons for allprop are: - it's a single request. Typical use case for me is PROPFIND/allprop on a collection with Depth=1. - To achieve the same with 2 propname/prop requests, I'd have to make a PROPFIND/propname Depth=1, calculate the closure of all propnames for all resources in that collection. Then perform a PROPFIND/prop with Depth=1 where includes the set of all property names of all resources. - PROPFIND/propname is not for free. To calculate the exact set of live properties of a resource is often more expensive than answering an allprop request. //Stefan From w3c-dist-auth-request@w3.org Fri Nov 23 11: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 ESMTP id LAA19033 for ; Fri, 23 Nov 2001 11:23:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA15833; Fri, 23 Nov 2001 11:21:56 -0500 (EST) Resent-Date: Fri, 23 Nov 2001 11:21:56 -0500 (EST) Resent-Message-Id: <200111231621.LAA15833@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA15812 for ; Fri, 23 Nov 2001 11:21:41 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA11069 for ; Fri, 23 Nov 2001 11:21:42 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA368250; Fri, 23 Nov 2001 11:18:28 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fANGL7p128878; Fri, 23 Nov 2001 11:21:07 -0500 To: "Julian Reschke" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Fri, 23 Nov 2001 11:06:25 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V509_11062001 |November 6, 2001) at 11/23/2001 11:21:07 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5650 X-Loop: w3c-dist-auth@w3.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 Julian is right. The specs conflict. It sounds like the other specs are not going to change. At least not 2396. It does sound like some of us feel that what 2518 specifies isn't really what should have been specified. I'll support the suggestion that 1) We pick a second URI for our namespace. I'll suggest http://webdav.org/base. 2) We update the spec to use this new URI in the examples. 3) We deprecate DAV: as the namespace URI in the spec. 4) ASAP implementors start accepting the new URI in addition to DAV: 5) Later implementors can start transmitting the new URI. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Nov 23 11:28: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 LAA19089 for ; Fri, 23 Nov 2001 11:28:57 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA16590; Fri, 23 Nov 2001 11:28:04 -0500 (EST) Resent-Date: Fri, 23 Nov 2001 11:28:04 -0500 (EST) Resent-Message-Id: <200111231628.LAA16590@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA16570 for ; Fri, 23 Nov 2001 11:27:57 -0500 (EST) 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 LAA11790 for ; Fri, 23 Nov 2001 11:27:57 -0500 Received: from lisa [192.168.1.2] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Fri, 23 Nov 2001 17:27:53 +0100 From: "Julian Reschke" To: "Jason Crawford" Cc: Date: Fri, 23 Nov 2001 17:27:51 +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 V6.00.2600.0000 In-Reply-To: Importance: Normal X-MDRemoteIP: 192.168.1.2 X-Return-Path: julian.reschke@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5651 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks, Jason. We'd probably need to cover some more issues: - how does a server decide which NS to use in a reply if the request didn't contain a body (PROPFIND for instance), - clarification, that and map to *identical* properties, - and probably some more details... Julian > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Friday, November 23, 2001 5:06 PM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > > > I think Julian is right. > > The specs conflict. > It sounds like the other specs are not going to change. At least not > 2396. > It does sound like some of us feel that what 2518 specifies isn't really > what should have been specified. > > I'll support the suggestion that > > 1) We pick a second URI for our namespace. I'll suggest > http://webdav.org/base. > 2) We update the spec to use this new URI in the examples. > 3) We deprecate DAV: as the namespace URI in the spec. > 4) ASAP implementors start accepting the new URI in addition to DAV: > 5) Later implementors can start transmitting the new URI. > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > > > From w3c-dist-auth-request@w3.org Fri Nov 23 12:43:54 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 MAA21223 for ; Fri, 23 Nov 2001 12:43:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA19665; Fri, 23 Nov 2001 12:43:03 -0500 (EST) Resent-Date: Fri, 23 Nov 2001 12:43:03 -0500 (EST) Resent-Message-Id: <200111231743.MAA19665@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA19641 for ; Fri, 23 Nov 2001 12:42:56 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA19233 for ; Fri, 23 Nov 2001 12:42:56 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA497654; Fri, 23 Nov 2001 12:39:44 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fANHgNp40774; Fri, 23 Nov 2001 12:42:23 -0500 To: "Julian Reschke" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Fri, 23 Nov 2001 12:29:15 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V509_11062001 |November 6, 2001) at 11/23/2001 12:42:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5652 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > We'd probably need to cover some more issues: > > - how does a server decide which NS to use in a reply if the request didn't > contain a body (PROPFIND for instance), I would suggest that this not go in the spec. It might not even be necessary for server to do this. Let's just get our code bases to accept both URI's. When we achieve this, and our updated code becomes prevalent in the field, this issue will be largely moot and implementations can begin to xmit the new URI. Perhaps if we find there are a lot of changes as we move to draft standard, we can suggest that the draft standard include a header to denote draft-standard support. But I don't think that's necessary for this issue, so let's not tie that in to this issue right now. > - clarification, that and map > to *identical* properties, Maybe. It seems obvious. If I alone were to make the choice, I'd tend to not even mention it. J. From w3c-dist-auth-request@w3.org Sat Nov 24 19:41:26 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 TAA26633 for ; Sat, 24 Nov 2001 19:41:25 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA12476; Sat, 24 Nov 2001 19:38:48 -0500 (EST) Resent-Date: Sat, 24 Nov 2001 19:38:48 -0500 (EST) Resent-Message-Id: <200111250038.TAA12476@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA12326 for ; Sat, 24 Nov 2001 19:38:29 -0500 (EST) Received: from toro.w3.mag.keio.ac.jp (postfix@toro.w3.mag.keio.ac.jp [133.27.228.201]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA04014; Sat, 24 Nov 2001 19:38:27 -0500 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 7F7E47F435; Sun, 25 Nov 2001 09:38:24 +0900 (JST) Message-Id: <4.2.0.58.J.20011124184719.040fd4a0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sat, 24 Nov 2001 18:49:32 +0900 To: Mark Baker , stefan.eissing@greenbytes.de (Stefan Eissing) From: Martin Duerst Cc: w3c-dist-auth@w3.org (WebDAV), uri@w3.org In-Reply-To: <200111221451.JAA16896@markbaker.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5653 X-Loop: w3c-dist-auth@w3.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 09:51 01/11/22 -0500, Mark Baker wrote: > > Unfortunately, "DAV:" is no legal URI reference either. RFC 2396 > > explicitly forbids ':' in relative path's first segment... > >Darn, I thought I checked this. I assume the reason for this is to >allow disambiguation between absolute and relative URI references. >But, "dav:" isn't a valid URI reference of any kind, so what if we > updated 2396 to allow ":" as the last character of >the relative path's first segment? Would that break anything? In terms of specs, probably not. In terms of implementations, we would have to test quite a few to be able to claim that all (or a sufficiently large subset of) current implementations already process foo: relative. Regards, Martin. From w3c-dist-auth-request@w3.org Sun Nov 25 02: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 ESMTP id CAA17622 for ; Sun, 25 Nov 2001 02:41:07 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA26473; Sun, 25 Nov 2001 02:39:45 -0500 (EST) Resent-Date: Sun, 25 Nov 2001 02:39:45 -0500 (EST) Resent-Message-Id: <200111250739.CAA26473@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA26440 for ; Sun, 25 Nov 2001 02:39:36 -0500 (EST) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA14885; Sun, 25 Nov 2001 02:39:34 -0500 Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id CAA26368; Sun, 25 Nov 2001 02:37:44 -0500 Message-Id: <200111250737.CAA26368@markbaker.ca> To: duerst@w3.org (Martin Duerst) Date: Sun, 25 Nov 2001 02:37:44 -0500 (EST) Cc: stefan.eissing@greenbytes.de (Stefan Eissing), w3c-dist-auth@w3.org (WebDAV), uri@w3.org In-Reply-To: <4.2.0.58.J.20011124184719.040fd4a0@localhost> from "Martin Duerst" at Nov 24, 2001 06:49:32 PM From: Mark Baker X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5654 X-Loop: w3c-dist-auth@w3.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 > At 09:51 01/11/22 -0500, Mark Baker wrote: > > > Unfortunately, "DAV:" is no legal URI reference either. RFC 2396 > > > explicitly forbids ':' in relative path's first segment... > > > >Darn, I thought I checked this. I assume the reason for this is to > >allow disambiguation between absolute and relative URI references. > >But, "dav:" isn't a valid URI reference of any kind, so what if we > > updated 2396 to allow ":" as the last character of > >the relative path's first segment? Would that break anything? > > In terms of specs, probably not. In terms of implementations, > we would have to test quite a few to be able to claim that > all (or a sufficiently large subset of) current implementations > already process foo: relative. Right. And BTW, my proposed correction above was incorrect. It should be that rel_path should be able to end with a ":", not rel_segment. Here's my "I'm not at all familiar with the intricacies of the BNF production rules, but here goes anyway" attempt at patching it up; rel_path = ( rel_segment [ abs_path ] | rel_segment ":" ) MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com From w3c-dist-auth-request@w3.org Sun Nov 25 03:20: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 DAA18254 for ; Sun, 25 Nov 2001 03:20:55 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA27126; Sun, 25 Nov 2001 03:19:46 -0500 (EST) Resent-Date: Sun, 25 Nov 2001 03:19:46 -0500 (EST) Resent-Message-Id: <200111250819.DAA27126@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA27072 for ; Sun, 25 Nov 2001 03:19:18 -0500 (EST) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA17342; Sun, 25 Nov 2001 03:18:12 -0500 Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id fAP8Gdb14608; Sun, 25 Nov 2001 00:16:39 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id fAP8Gf109573; Sun, 25 Nov 2001 00:16:41 -0800 (PST) Received: from larrypad ([130.248.184.150]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GNCKD400.KPE; Sun, 25 Nov 2001 00:17:28 -0800 Reply-To: From: "Larry Masinter" To: "'Mark Baker'" , "'Martin Duerst'" Cc: "'Stefan Eissing'" , "'WebDAV'" , Date: Sun, 25 Nov 2001 00:15:51 -0800 Message-ID: <000301c17589$67c61a50$0b78bfd1@larrypad> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <200111250737.CAA26368@markbaker.ca> Importance: Normal Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5655 X-Loop: w3c-dist-auth@w3.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 seems like people have noted the following possibilities: * Change the URI spec to allow "DAV:" as a URI * Change the WebDAV spec to use something other than "DAV:" as the namespace name but have left out the following possibilities: * Change the XML namespace spec to allow "scheme-name:" as a namespace name, even though it isn't a legal URI (This isn't such a big deal, since XML namespace names allow IRIs with non-ASCII characters anyway, not really URIs) * Declare that WebDAV bodies aren't really XML, because the WebDAV spec has this little problem with the "DAV:" namespace. The latter is the closest approximation to the 'truth', requires no incompatible changes to any specs or any other software, but means that (as happens to be true) anyone trying to apply generic XML software to WebDAV requests or responses has to be careful because of the use of the "DAV:" namespace. Larry -- http://larry.masinter.net From w3c-dist-auth-request@w3.org Sun Nov 25 04:48: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 EAA18729 for ; Sun, 25 Nov 2001 04:48:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA00752; Sun, 25 Nov 2001 04:47:29 -0500 (EST) Resent-Date: Sun, 25 Nov 2001 04:47:29 -0500 (EST) Resent-Message-Id: <200111250947.EAA00752@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA00721 for ; Sun, 25 Nov 2001 04:47:18 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA27244 for ; Sun, 25 Nov 2001 04:47:17 -0500 Received: (qmail 7868 invoked by uid 0); 25 Nov 2001 09:46:46 -0000 Received: from pd95358a3.dip.t-dialin.net (HELO lisa) (217.83.88.163) by mail.gmx.net (mp005-rz3) with SMTP; 25 Nov 2001 09:46:46 -0000 From: "Julian Reschke" To: , "'Mark Baker'" , "'Martin Duerst'" Cc: "'Stefan Eissing'" , "'WebDAV'" , Date: Sun, 25 Nov 2001 10:46:42 +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) In-Reply-To: <000301c17589$67c61a50$0b78bfd1@larrypad> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5656 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Larry Masinter > Sent: Sunday, November 25, 2001 9:16 AM > To: 'Mark Baker'; 'Martin Duerst' > Cc: 'Stefan Eissing'; 'WebDAV'; uri@w3.org > Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > > It seems like people have noted the following possibilities: > > * Change the URI spec to allow "DAV:" as a URI > * Change the WebDAV spec to use something other than "DAV:" as > the namespace name > > but have left out the following possibilities: > > * Change the XML namespace spec to allow "scheme-name:" as > a namespace name, even though it isn't a legal URI I mentioned this. > (This isn't such a big deal, since XML namespace names allow > IRIs with non-ASCII characters anyway, not really URIs) I don't think they do. "[Definition:] The attribute's value, a URI reference, is the namespace name identifying the namespace. ..." > * Declare that WebDAV bodies aren't really XML, because > the WebDAV spec has this little problem with the "DAV:" > namespace. WebDAV could also define that the message bodies do not use namespaces, and re-declare the namespace syntax so that "DAV:" is valid. However, I doubt that anybody would want *that*. It would basically mean that on the long run, an non-namespace aware XML processor is required, and that WebDAV servers/clients would need to do namespace checking and mapping on their own. > The latter is the closest approximation to the 'truth', requires > no incompatible changes to any specs or any other software, but > means that (as happens to be true) anyone trying to apply generic > XML software to WebDAV requests or responses has to be careful > because of the use of the "DAV:" namespace. I think you just argued for changing the WebDAV namespace (or to deprecate it and add an alternative one). From w3c-dist-auth-request@w3.org Sun Nov 25 12:15:09 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 MAA22666 for ; Sun, 25 Nov 2001 12:15:09 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA11889; Sun, 25 Nov 2001 12:13:32 -0500 (EST) Resent-Date: Sun, 25 Nov 2001 12:13:32 -0500 (EST) Resent-Message-Id: <200111251713.MAA11889@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA11869 for ; Sun, 25 Nov 2001 12:13:21 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37184.rational.com [192.229.37.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA31301 for ; Sun, 25 Nov 2001 12:13:21 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Sun, 25 Nov 2001 12:12:51 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sun, 25 Nov 2001 12:12:51 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B104EC8D27@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Sun, 25 Nov 2001 12:12:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5657 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Clearly a situation of trying to pick the least bad alternative ... I also agree that Julian's alternative appears to be the least bad. There is no "error" in any of the underlying specs (URI, XML namespace) that would support requesting a change. Declaring WebDAV processing to be incompatible with URI or XML namespaces would be worse. For Julian's issues, it would be up to the server to pick a NS if the client request does indicate that the client understands the new NS, but the conservative thing to do would be to use the DAV: namespace. The other issue is not really an issue, but rather a point that would need to be made in the revised spec. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@greenbytes.de] Sent: Friday, November 23, 2001 11:28 AM To: Jason Crawford Cc: w3c-dist-auth@w3.org Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Thanks, Jason. We'd probably need to cover some more issues: - how does a server decide which NS to use in a reply if the request didn't contain a body (PROPFIND for instance), - clarification, that and map to *identical* properties, - and probably some more details... Julian > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Friday, November 23, 2001 5:06 PM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > > > I think Julian is right. > > The specs conflict. > It sounds like the other specs are not going to change. At least not > 2396. > It does sound like some of us feel that what 2518 specifies isn't really > what should have been specified. > > I'll support the suggestion that > > 1) We pick a second URI for our namespace. I'll suggest > http://webdav.org/base. > 2) We update the spec to use this new URI in the examples. > 3) We deprecate DAV: as the namespace URI in the spec. > 4) ASAP implementors start accepting the new URI in addition to DAV: > 5) Later implementors can start transmitting the new URI. > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > > > From w3c-dist-auth-request@w3.org Sun Nov 25 13:58: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 NAA23748 for ; Sun, 25 Nov 2001 13:58:03 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA15740; Sun, 25 Nov 2001 13:56:52 -0500 (EST) Resent-Date: Sun, 25 Nov 2001 13:56:52 -0500 (EST) Resent-Message-Id: <200111251856.NAA15740@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA15684 for ; Sun, 25 Nov 2001 13:56:38 -0500 (EST) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA08392 for ; Sun, 25 Nov 2001 13:56:38 -0500 Received: from moose ([198.144.203.249]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id fAPIuaQ10959 for ; Sun, 25 Nov 2001 10:56:36 -0800 (PST) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: Date: Sat, 24 Nov 2001 22:54:42 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B104EC8D27@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5658 X-Loop: w3c-dist-auth@w3.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 pragmatic arguments: I don't think it's really feasible to change the bits on the wire now. Obviously, it hasn't been a problem in the past, and it hasn't harmed interoperability. I've never heard of XML parsers that object to that namespace, and I'm not clear why the single tool that does object to that namespace is required for DAV servers/clients. Changing the namespace DAV uses in all its bodies would be a tremendous change -- and I don't see what the need is for such a major change. Besides, even if we tried to "fix" RFC2518 on this issue, that's not the only place where it crops up. I know of other namespaces used in shipped software products where the namespaces look like a string of characters ending in ':'. Changing the "DAV:" prefix won't fix those, whereas a loosening of either the XML namespaces requirements or the URI requirements would. The theoretical argument I haven't heard yet: If the definition of this type of URI is ":", why can't the scheme-specific part string be the null string -- as long as that's legal for the declared scheme? lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Sunday, November 25, 2001 9:13 AM > To: w3c-dist-auth@w3.org > Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > > Clearly a situation of trying to pick the least bad alternative ... > > I also agree that Julian's alternative appears to be the least bad. > There is no "error" in any of the underlying specs (URI, XML > namespace) that would support requesting a change. > > Declaring WebDAV processing to be incompatible with URI or XML > namespaces would be worse. > > For Julian's issues, it would be up to the server to pick a NS if the > client request does indicate that the client understands the new NS, > but the conservative thing to do would be to use the DAV: namespace. > The other issue is not really an issue, but rather a point that would > need to be made in the revised spec. > > Cheers, > Geoff > > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@greenbytes.de] > Sent: Friday, November 23, 2001 11:28 AM > To: Jason Crawford > Cc: w3c-dist-auth@w3.org > Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > > Thanks, Jason. > > We'd probably need to cover some more issues: > > - how does a server decide which NS to use in a reply if the > request didn't > contain a body (PROPFIND for instance), > - clarification, that and xmlns="newuri..." /> map > to *identical* properties, > - and probably some more details... > > Julian > > > -----Original Message----- > > From: Jason Crawford [mailto:ccjason@us.ibm.com] > > Sent: Friday, November 23, 2001 5:06 PM > > To: Julian Reschke > > Cc: w3c-dist-auth@w3.org > > Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > > > > > > > I think Julian is right. > > > > The specs conflict. > > It sounds like the other specs are not going to change. At least not > > 2396. > > It does sound like some of us feel that what 2518 specifies isn't really > > what should have been specified. > > > > I'll support the suggestion that > > > > 1) We pick a second URI for our namespace. I'll suggest > > http://webdav.org/base. > > 2) We update the spec to use this new URI in the examples. > > 3) We deprecate DAV: as the namespace URI in the spec. > > 4) ASAP implementors start accepting the new URI in addition to DAV: > > 5) Later implementors can start transmitting the new URI. > > > > J. > > > > ------------------------------------------ > > Phone: 914-784-7569, ccjason@us.ibm.com > > > > > > > > From w3c-dist-auth-request@w3.org Sun Nov 25 15:20: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 PAA24589 for ; Sun, 25 Nov 2001 15:20:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA19081; Sun, 25 Nov 2001 15:18:58 -0500 (EST) Resent-Date: Sun, 25 Nov 2001 15:18:58 -0500 (EST) Resent-Message-Id: <200111252018.PAA19081@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA19057 for ; Sun, 25 Nov 2001 15:18:36 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA15269 for ; Sun, 25 Nov 2001 15:18:36 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA253912; Sun, 25 Nov 2001 15:15:23 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fAPKI3F87552; Sun, 25 Nov 2001 15:18:03 -0500 To: "Lisa Dusseault" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Sun, 25 Nov 2001 15:10:57 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V509_11062001 |November 6, 2001) at 11/25/2001 03:18:03 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5659 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << Besides, even if we tried to "fix" RFC2518 on this issue, that's not the only place where it crops up. I know of other namespaces used in shipped software products where the namespaces look like a string of characters ending in ':'. Changing the "DAV:" prefix won't fix those, whereas a loosening of either the XML namespaces requirements or the URI requirements would. >> The 2396 folks seem intransient on this issue. OTOH it doesn't sound like we've discussed this with the namespace folks. Perhaps you'd like to take those other examples you have and make a proposal to the namespace committee? We could defer this issue a few weeks until we have an idea if your proposal will be adopted. I can be responsible for making sure we bring up this topic again. So Lisa, are you game? From w3c-dist-auth-request@w3.org Sun Nov 25 17:02: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 RAA25251 for ; Sun, 25 Nov 2001 17:02:03 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA23039; Sun, 25 Nov 2001 17:00:41 -0500 (EST) Resent-Date: Sun, 25 Nov 2001 17:00:41 -0500 (EST) Resent-Message-Id: <200111252200.RAA23039@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA23001 for ; Sun, 25 Nov 2001 17:00:26 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA26260 for ; Sun, 25 Nov 2001 17:00:26 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA102188; Sun, 25 Nov 2001 16:57:12 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fAPLxnF125880; Sun, 25 Nov 2001 16:59:49 -0500 To: "Clemm, Geoff" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Sun, 25 Nov 2001 16:57:00 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V509_11062001 |November 6, 2001) at 11/25/2001 04:59:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5660 X-Loop: w3c-dist-auth@w3.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 other issue is not really an issue, but rather a point that would need to be made in the revised spec. >> Re: adding text to mention that the properties are the same regardless of the use of the new/old namespace URI.... That sounds fine to me. I won't protest adding that. :-) From w3c-dist-auth-request@w3.org Sun Nov 25 17:22:51 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 RAA25345 for ; Sun, 25 Nov 2001 17:22:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA24577; Sun, 25 Nov 2001 17:21:37 -0500 (EST) Resent-Date: Sun, 25 Nov 2001 17:21:37 -0500 (EST) Resent-Message-Id: <200111252221.RAA24577@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA24549 for ; Sun, 25 Nov 2001 17:21:24 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA29252 for ; Sun, 25 Nov 2001 17:21:25 -0500 Received: (qmail 3913 invoked by uid 0); 25 Nov 2001 22:20:52 -0000 Received: from pd9535432.dip.t-dialin.net (HELO lisa) (217.83.84.50) by mail.gmx.net (mp011-rz3) with SMTP; 25 Nov 2001 22:20:52 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , Date: Sun, 25 Nov 2001 23:20:48 +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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5661 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Sunday, November 25, 2001 7:55 AM > To: w3c-dist-auth@w3.org > Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > > The pragmatic arguments: I don't think it's really feasible to change the > bits on the wire now. Obviously, it hasn't been a problem in the We can't change them now, but we can define a migration path to a format that conforms to the underlying specs. > past, and > it hasn't harmed interoperability. I've never heard of XML parsers that > object to that namespace, and I'm not clear why the single tool that does > object to that namespace is required for DAV servers/clients. It isn't. But it *is* an example of a newly written piece of code that rejects the namespace name, and we have found out that it's correct in doing that. So we have to consider the fact that this may apply to newly written XML processors as well. > Changing the namespace DAV uses in all its bodies would be a tremendous > change -- and I don't see what the need is for such a major change. Because the standard as it's written today isn't well-defined? It says that you must use an XML-NS aware processor to parse the bodies, yet the bodies as defined by the spec do not conform to XML 1.0 (+ namespaces). > Besides, even if we tried to "fix" RFC2518 on this issue, that's not the > only place where it crops up. I know of other namespaces used in shipped > software products where the namespaces look like a string of characters > ending in ':'. Changing the "DAV:" prefix won't fix those, whereas a Well. Obviously these need to be fixed as well. > loosening of either the XML namespaces requirements or the URI > requirements > would. > > The theoretical argument I haven't heard yet: If the definition of this > type of URI is ":", why can't the > scheme-specific part string be the null string -- as long as that's legal > for the declared scheme? I was wondering about this as well. Fact is the grammar doesn't allow it, and it doesn't seem that anybody is going to touch RFC2396 "just" for WebDAV. Julian From w3c-dist-auth-request@w3.org Sun Nov 25 18:32: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 SAA25770 for ; Sun, 25 Nov 2001 18:32:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA26439; Sun, 25 Nov 2001 18:30:52 -0500 (EST) Resent-Date: Sun, 25 Nov 2001 18:30:52 -0500 (EST) Resent-Message-Id: <200111252330.SAA26439@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA26396 for ; Sun, 25 Nov 2001 18:30:31 -0500 (EST) 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 SAA02912 for ; Sun, 25 Nov 2001 18:30:30 -0500 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id fAPNU0r07138 for ; Sun, 25 Nov 2001 15:30:00 -0800 Received: from waka.ebuilt.net (IDENT:root@i142.ir.ebuilt.net [10.1.2.142]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id fAPNTxZ06972; Sun, 25 Nov 2001 15:29:59 -0800 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id fAPNQf301561; Sun, 25 Nov 2001 15:26:41 -0800 Date: Sun, 25 Nov 2001 15:26:40 -0800 From: "Roy T. Fielding" To: Larry Masinter Cc: "'Mark Baker'" , "'Martin Duerst'" , "'Stefan Eissing'" , "'WebDAV'" , uri@w3.org Message-ID: <20011125152640.B1399@waka.ebuilt.net> References: <200111250737.CAA26368@markbaker.ca> <000301c17589$67c61a50$0b78bfd1@larrypad> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000301c17589$67c61a50$0b78bfd1@larrypad> User-Agent: Mutt/1.3.20i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5662 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > but have left out the following possibilities: > > * Change the XML namespace spec to allow "scheme-name:" as > a namespace name, even though it isn't a legal URI > (This isn't such a big deal, since XML namespace names allow > IRIs with non-ASCII characters anyway, not really URIs) In case anyone is wondering, "scheme:" is not allowed in the URI syntax because Web browsers and client libraries do interpret it as a form of relative URI due to a loophole in CERN's original partial URI algorithm. People never used it, but the loophole makes it impossible for such an identifier to be interoperable. OTOH, I have found at least one other example -- the "about:" URL in Netscape Navigator -- so I guess this could be changed in a future revision of 2396. ....Roy From w3c-dist-auth-request@w3.org Sun Nov 25 18: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 ESMTP id SAA25894 for ; Sun, 25 Nov 2001 18:43:35 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA26892; Sun, 25 Nov 2001 18:42:35 -0500 (EST) Resent-Date: Sun, 25 Nov 2001 18:42:35 -0500 (EST) Resent-Message-Id: <200111252342.SAA26892@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA26872 for ; Sun, 25 Nov 2001 18:42:29 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA04131 for ; Sun, 25 Nov 2001 18:42:29 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA15840 for ; Sun, 25 Nov 2001 18:39:16 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fAPNfuF63146 for ; Sun, 25 Nov 2001 18:41:56 -0500 To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Sun, 25 Nov 2001 18:30:36 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V509_11062001 |November 6, 2001) at 11/25/2001 06:41:55 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5663 X-Loop: w3c-dist-auth@w3.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 2396 folks seem intransient on this issue. Whoops. I meant intransigent. :-) ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Sun Nov 25 20:32: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 UAA26654 for ; Sun, 25 Nov 2001 20:32:03 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA01235; Sun, 25 Nov 2001 20:30:56 -0500 (EST) Resent-Date: Sun, 25 Nov 2001 20:30:56 -0500 (EST) Resent-Message-Id: <200111260130.UAA01235@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA01200 for ; Sun, 25 Nov 2001 20:30:47 -0500 (EST) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA20678; Sun, 25 Nov 2001 20:30:44 -0500 Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id UAA30872; Sun, 25 Nov 2001 20:28:52 -0500 Message-Id: <200111260128.UAA30872@markbaker.ca> To: fielding@ebuilt.com (Roy T. Fielding) Date: Sun, 25 Nov 2001 20:28:52 -0500 (EST) Cc: LMM@acm.org (Larry Masinter), duerst@w3.org ('Martin Duerst'), stefan.eissing@greenbytes.de ('Stefan Eissing'), w3c-dist-auth@w3.org ('WebDAV'), uri@w3.org In-Reply-To: <20011125152640.B1399@waka.ebuilt.net> from "Roy T. Fielding" at Nov 25, 2001 03:26:40 PM From: Mark Baker X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5664 X-Loop: w3c-dist-auth@w3.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 Roy, > > but have left out the following possibilities: > > > > * Change the XML namespace spec to allow "scheme-name:" as > > a namespace name, even though it isn't a legal URI > > (This isn't such a big deal, since XML namespace names allow > > IRIs with non-ASCII characters anyway, not really URIs) > > In case anyone is wondering, "scheme:" is not allowed in the URI syntax > because Web browsers and client libraries do interpret it as a form of > relative URI due to a loophole in CERN's original partial URI algorithm. > People never used it, but the loophole makes it impossible for such an > identifier to be interoperable. > > OTOH, I have found at least one other example -- the "about:" URL in > Netscape Navigator -- so I guess this could be changed in a future revision > of 2396. Interesting. Just to clarify, what are you suggesting be changed? That "foo:" be a valid absolute URI reference, or a valid relative one? MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com From w3c-dist-auth-request@w3.org Mon Nov 26 03:28:24 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 DAA17613 for ; Mon, 26 Nov 2001 03:28:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA12880; Mon, 26 Nov 2001 03:20:29 -0500 (EST) Resent-Date: Mon, 26 Nov 2001 03:20:29 -0500 (EST) Resent-Message-Id: <200111260820.DAA12880@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA12556 for ; Mon, 26 Nov 2001 03:07:21 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA20470 for ; Mon, 26 Nov 2001 03:07:21 -0500 Received: (qmail 4615 invoked by uid 0); 26 Nov 2001 08:06:50 -0000 Received: from pd9e5172f.dip.t-dialin.net (HELO lisa) (217.229.23.47) by mail.gmx.net (mp009-rz3) with SMTP; 26 Nov 2001 08:06:50 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , Date: Mon, 26 Nov 2001 09:06:43 +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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5665 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Sunday, November 25, 2001 7:55 AM > To: w3c-dist-auth@w3.org > Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > > The pragmatic arguments: I don't think it's really feasible to change the > bits on the wire now. Obviously, it hasn't been a problem in the We can't change them now, but we can define a migration path to a format that conforms to the underlying specs. > past, and > it hasn't harmed interoperability. I've never heard of XML parsers that > object to that namespace, and I'm not clear why the single tool that does > object to that namespace is required for DAV servers/clients. It isn't. But it *is* an example of a newly written piece of code that rejects the namespace name, and we have found out that it's correct in doing that. So we have to consider the fact that this may apply to newly written XML processors as well. > Changing the namespace DAV uses in all its bodies would be a tremendous > change -- and I don't see what the need is for such a major change. Because the standard as it's written today isn't well-defined? It says that you must use an XML-NS aware processor to parse the bodies, yet the bodies as defined by the spec do not conform to XML 1.0 (+ namespaces). > Besides, even if we tried to "fix" RFC2518 on this issue, that's not the > only place where it crops up. I know of other namespaces used in shipped > software products where the namespaces look like a string of characters > ending in ':'. Changing the "DAV:" prefix won't fix those, whereas a Well. Obviously these need to be fixed as well. > loosening of either the XML namespaces requirements or the URI > requirements > would. > > The theoretical argument I haven't heard yet: If the definition of this > type of URI is ":", why can't the > scheme-specific part string be the null string -- as long as that's legal > for the declared scheme? I was wondering about this as well. Fact is the grammar doesn't allow it, and it doesn't seem that anybody is going to touch RFC2396 "just" for WebDAV. Julian From w3c-dist-auth-request@w3.org Mon Nov 26 13:31: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 NAA18964 for ; Mon, 26 Nov 2001 13:31:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA21214; Mon, 26 Nov 2001 13:26:27 -0500 (EST) Resent-Date: Mon, 26 Nov 2001 13:26:27 -0500 (EST) Resent-Message-Id: <200111261826.NAA21214@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA21179 for ; Mon, 26 Nov 2001 13:26:14 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA32016; Mon, 26 Nov 2001 13:26:14 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA07623; Mon, 26 Nov 2001 10:26:12 -0800 (PST) From: "Jim Whitehead" To: "Roy T. Fielding" Cc: "'WebDAV'" , Date: Mon, 26 Nov 2001 10:25:48 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20011125152640.B1399@waka.ebuilt.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5666 X-Loop: w3c-dist-auth@w3.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 Roy Fielding writes: > OTOH, I have found at least one other example -- the "about:" URL in > Netscape Navigator -- so I guess this could be changed in a > future revision of 2396. A very principled case can be made for viewing the scheme namespace as a set of URIs. This URI space identifies URI/URN/URL scheme names. A scheme identifies a resource, the abstract concept of the particular identifier of locator space. For "http" scheme URLs, the URI "http:" identifies the abstract notion of locators for Web resources accessed via the HTTP protocol. The "dav:" URI identifies the abstract concept of property and XML element names used in the WebDAV family of protocols. Put another way, there is a set of resources: {{The abstract notion of locators for Web resources accessed via the HTTP protocol}, {The abstract concept of property and XML element names used in the WebDAV family of protocols}, {The abstract concept of locators for directory resources accessed via the LDAP protocol}, {The abstract concept of identifiers for people's email inboxes}} These resources map to the following URIs: {"http:", "dav:", "ldap:", "mailto:"} Once you accept that these are all valid URIs, then RFC 2396 can be viewed as needing revision to remove the (artificial) constraints on URI syntax that prevent the use of scheme name URIs. - Jim PS - So, yes, I am reversing my earlier opinion that RFC 2396 does not need revision. From w3c-dist-auth-request@w3.org Mon Nov 26 13:56:07 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20909 for ; Mon, 26 Nov 2001 13:56:07 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA24371; Mon, 26 Nov 2001 13:54:55 -0500 (EST) Resent-Date: Mon, 26 Nov 2001 13:54:55 -0500 (EST) Resent-Message-Id: <200111261854.NAA24371@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA24317 for ; Mon, 26 Nov 2001 13:54:34 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37184.rational.com [192.229.37.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA03962; Mon, 26 Nov 2001 13:54:33 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Mon, 26 Nov 2001 13:53:59 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Nov 2001 13:53:59 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AD7F@SUS-MA1IT01> From: "Clemm, Geoff" To: "'WebDAV'" , uri@w3.org Date: Mon, 26 Nov 2001 13:53:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5667 X-Loop: w3c-dist-auth@w3.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 Jim makes a good case here. It is particularly convenient that "foo:" is not allowed as a relative URI, since otherwise the use of "foo:" as the URI for the schema would be ambiguous. And this would retroactively give us a much better answer for why "foo:" is not a legal relative URI Cheers, Geoff -----Original Message----- From: Jim Whitehead [mailto:ejw@cse.ucsc.edu] Sent: Monday, November 26, 2001 1:26 PM To: Roy T. Fielding Cc: 'WebDAV'; uri@w3.org Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Roy Fielding writes: > OTOH, I have found at least one other example -- the "about:" URL in > Netscape Navigator -- so I guess this could be changed in a > future revision of 2396. A very principled case can be made for viewing the scheme namespace as a set of URIs. This URI space identifies URI/URN/URL scheme names. A scheme identifies a resource, the abstract concept of the particular identifier of locator space. For "http" scheme URLs, the URI "http:" identifies the abstract notion of locators for Web resources accessed via the HTTP protocol. The "dav:" URI identifies the abstract concept of property and XML element names used in the WebDAV family of protocols. Put another way, there is a set of resources: {{The abstract notion of locators for Web resources accessed via the HTTP protocol}, {The abstract concept of property and XML element names used in the WebDAV family of protocols}, {The abstract concept of locators for directory resources accessed via the LDAP protocol}, {The abstract concept of identifiers for people's email inboxes}} These resources map to the following URIs: {"http:", "dav:", "ldap:", "mailto:"} Once you accept that these are all valid URIs, then RFC 2396 can be viewed as needing revision to remove the (artificial) constraints on URI syntax that prevent the use of scheme name URIs. - Jim PS - So, yes, I am reversing my earlier opinion that RFC 2396 does not need revision. From w3c-dist-auth-request@w3.org Mon Nov 26 14:24:47 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23215 for ; Mon, 26 Nov 2001 14:24:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA27363; Mon, 26 Nov 2001 14:22:35 -0500 (EST) Resent-Date: Mon, 26 Nov 2001 14:22:35 -0500 (EST) Resent-Message-Id: <200111261922.OAA27363@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA27303 for ; Mon, 26 Nov 2001 14:22:19 -0500 (EST) 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 OAA08615 for ; Mon, 26 Nov 2001 14:22:19 -0500 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id fAQJLjp01651 for ; Mon, 26 Nov 2001 11:21:45 -0800 Received: from waka.ebuilt.net (IDENT:root@i142.ir.ebuilt.net [10.1.2.142]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id fAQJLiZ01485; Mon, 26 Nov 2001 11:21:44 -0800 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id fAQJI0L07829; Mon, 26 Nov 2001 11:18:00 -0800 Date: Mon, 26 Nov 2001 11:18:00 -0800 From: "Roy T. Fielding" To: Jim Whitehead Cc: "'WebDAV'" , uri@w3.org Message-ID: <20011126111800.A7752@waka.ebuilt.net> References: <20011125152640.B1399@waka.ebuilt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5668 X-Loop: w3c-dist-auth@w3.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 very principled case can be made for viewing the scheme namespace as a set > of URIs. This URI space identifies URI/URN/URL scheme names. I understand that case, but don't think it is a good idea. URI namespaces are a form of protocol, and like all protocols they are occasionally subject to revision. I prefer to identify such protocols with a separate URI, not a construct of the syntax. But that is not just my preference -- it is also demonstrated by that silly "about:" URI in Netscape Navigator. That does identify a resource, not the naming scheme. The basic problem is that, given the ability to define their own namespace, most developers think it is "safer" to create their own world of names. And they may even be right. In other words, I think that "scheme:" is only a valid identifier for the namespace if the scheme defines it as such. ....Roy From w3c-dist-auth-request@w3.org Mon Nov 26 18:33: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 SAA12398 for ; Mon, 26 Nov 2001 18:33:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA18708; Mon, 26 Nov 2001 18:31:26 -0500 (EST) Resent-Date: Mon, 26 Nov 2001 18:31:26 -0500 (EST) Resent-Message-Id: <200111262331.SAA18708@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA18678 for ; Mon, 26 Nov 2001 18:31:16 -0500 (EST) 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 SAA21256 for ; Mon, 26 Nov 2001 18:31:16 -0500 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id fAQNUjd21252 for ; Mon, 26 Nov 2001 15:30:45 -0800 Received: from waka.ebuilt.net (IDENT:root@i142.ir.ebuilt.net [10.1.2.142]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id fAQNUiZ21086; Mon, 26 Nov 2001 15:30:44 -0800 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id fAQNRXW18655; Mon, 26 Nov 2001 15:27:33 -0800 Date: Mon, 26 Nov 2001 15:27:33 -0800 From: "Roy T. Fielding" To: Mark Baker Cc: Larry Masinter , "'Martin Duerst'" , "'Stefan Eissing'" , "'WebDAV'" , uri@w3.org Message-ID: <20011126152733.B8631@waka.ebuilt.net> References: <20011125152640.B1399@waka.ebuilt.net> <200111260128.UAA30872@markbaker.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200111260128.UAA30872@markbaker.ca> User-Agent: Mutt/1.3.20i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5669 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > Interesting. Just to clarify, what are you suggesting be changed? > That "foo:" be a valid absolute URI reference, or a valid relative > one? An absolute URI -- otherwise, the parsers would have to be changed. ....Roy From w3c-dist-auth-request@w3.org Mon Nov 26 18: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 ESMTP id SAA12886 for ; Mon, 26 Nov 2001 18:42:21 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA19306; Mon, 26 Nov 2001 18:41:37 -0500 (EST) Resent-Date: Mon, 26 Nov 2001 18:41:37 -0500 (EST) Resent-Message-Id: <200111262341.SAA19306@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA19261 for ; Mon, 26 Nov 2001 18:41:17 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA22402; Mon, 26 Nov 2001 18:41:16 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id PAA13171; Mon, 26 Nov 2001 15:41:20 -0800 (PST) From: "Jim Whitehead" To: "Roy T. Fielding" Cc: "'WebDAV'" , Date: Mon, 26 Nov 2001 15:40:54 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20011126111800.A7752@waka.ebuilt.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5670 X-Loop: w3c-dist-auth@w3.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 Roy Fielding writes: > I understand that case, but don't think it is a good idea. > URI namespaces are a form of protocol, and like all protocols > they are occasionally subject to revision. I prefer to identify > such protocols with a separate URI, not a construct of the syntax. I agree that it makes sense to have a different identifier for each revision of a URI scheme. BUT, these identifiers do not identify the same resource as the scheme URI. For example, "http:" identifies The abstract notion of locators for Web resources accessed via the HTTP protocol which is a different resource than The set of locators for Web resources accessed via the HTTP protocol and defined specifically by RFC 2616. and different still from The set of locators for Web resources accessed via the HTTP protocol and defined specifically by RFC 2068. even though the actual URL space in question could be the same (that is, the abstractions are different, even if, by chance, all these abstractions refer to the same set of URLs). So, you could still have "http:" and two additional URI/URL/URNs for the version-specific definitions of the http URL space. > But that is not just my preference -- it is also > demonstrated by that silly "about:" URI in Netscape Navigator. That does > identify a resource, not the naming scheme. Actually, since it does consistently return a resource, doesn't that make it a URL? > In other words, I think that "scheme:" is only a valid identifier for the > namespace if the scheme defines it as such. This would only be for pragmatic reasons, not for philosophic ones. - Jim From w3c-dist-auth-request@w3.org Mon Nov 26 19:05: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 TAA14435 for ; Mon, 26 Nov 2001 19:05:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA21392; Mon, 26 Nov 2001 19:04:26 -0500 (EST) Resent-Date: Mon, 26 Nov 2001 19:04:26 -0500 (EST) Resent-Message-Id: <200111270004.TAA21392@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA21364 for ; Mon, 26 Nov 2001 19:04:17 -0500 (EST) 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 TAA27359 for ; Mon, 26 Nov 2001 19:04:17 -0500 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id fAR03kF12376 for ; Mon, 26 Nov 2001 16:03:46 -0800 Received: from waka.ebuilt.net (IDENT:root@i142.ir.ebuilt.net [10.1.2.142]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id fAR03jZ12210; Mon, 26 Nov 2001 16:03:45 -0800 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id fAQNxNQ11494; Mon, 26 Nov 2001 15:59:23 -0800 Date: Mon, 26 Nov 2001 15:59:23 -0800 From: "Roy T. Fielding" To: Jim Whitehead Cc: "'WebDAV'" , uri@w3.org Message-ID: <20011126155923.A11448@waka.ebuilt.net> References: <20011126111800.A7752@waka.ebuilt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5671 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > I agree that it makes sense to have a different identifier for each revision > of a URI scheme. BUT, these identifiers do not identify the same resource as > the scheme URI. > > For example, "http:" identifies > > The abstract notion of locators for Web > resources accessed via the HTTP protocol No, it does not! The http scheme defines a namespace with a hierarchical syntax for which the naming authorities are defined by DNS/IP address and TCP port. The protocol used to access those names will change over time, just as it has already done so twice. Whether or not all such protocols are called HTTP depends on the IETF, which doesn't move anywhere near as fast as we develop new protocols that use the http namespace. > which is a different resource than > > The set of locators for Web resources > accessed via the HTTP protocol and defined > specifically by RFC 2616. > > and different still from > > The set of locators for Web resources > accessed via the HTTP protocol and defined > specifically by RFC 2068. > > even though the actual URL space in question could be the same (that is, the > abstractions are different, even if, by chance, all these abstractions refer > to the same set of URLs). > > So, you could still have "http:" and two additional URI/URL/URNs for the > version-specific definitions of the http URL space. Yes, but only if we defined it to be such a thing, which we won't do because Web browsers still discard the scheme name if it is the same as the scheme of the referring document. > > But that is not just my preference -- it is also > > demonstrated by that silly "about:" URI in Netscape Navigator. That does > > identify a resource, not the naming scheme. > > Actually, since it does consistently return a resource, doesn't that make it > a URL? *shrug* It isn't a relevant distinction. > > In other words, I think that "scheme:" is only a valid identifier for the > > namespace if the scheme defines it as such. > > This would only be for pragmatic reasons, not for philosophic ones. Hey, I'm a very pragmatic philosopher. I don't care for philosophies that don't work in practice. ....Roy From w3c-dist-auth-request@w3.org Tue Nov 27 01:59: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 BAA05294 for ; Tue, 27 Nov 2001 01:59:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA22401; Tue, 27 Nov 2001 01:56:53 -0500 (EST) Resent-Date: Tue, 27 Nov 2001 01:56:53 -0500 (EST) Resent-Message-Id: <200111270656.BAA22401@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA22352 for ; Tue, 27 Nov 2001 01:56:37 -0500 (EST) Received: from toro.w3.mag.keio.ac.jp (postfix@toro.w3.mag.keio.ac.jp [133.27.228.201]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA07316; Tue, 27 Nov 2001 01:56:36 -0500 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 1AFE17F49B; Tue, 27 Nov 2001 15:56:13 +0900 (JST) Message-Id: <4.2.0.58.J.20011127153447.03ffb380@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Tue, 27 Nov 2001 15:38:40 +0900 To: "Julian Reschke" , , "'Mark Baker'" From: Martin Duerst Cc: "'Stefan Eissing'" , "'WebDAV'" , In-Reply-To: References: <000301c17589$67c61a50$0b78bfd1@larrypad> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5672 X-Loop: w3c-dist-auth@w3.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 10:46 01/11/25 +0100, Julian Reschke wrote: > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Larry Masinter > > * Change the XML namespace spec to allow "scheme-name:" as > > a namespace name, even though it isn't a legal URI > > (This isn't such a big deal, since XML namespace names allow > > IRIs with non-ASCII characters anyway, not really URIs) Just a moment: IRIs are carefully defined so that they can be mapped to URIs. Therefore, 'scheme-name:' isn't an IRI. >I don't think they do. > >"[Definition:] The attribute's value, a URI reference, is the namespace name >identifying the namespace. ..." Julian is correct, currently the namespace Rec doesn't mention anything IRI-like, as opposed to XML, XML Schema, XLink, and many others. Regards, Martin. From w3c-dist-auth-request@w3.org Tue Nov 27 10:42: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 KAA04337 for ; Tue, 27 Nov 2001 10:42:03 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA22704; Tue, 27 Nov 2001 10:33:26 -0500 (EST) Resent-Date: Tue, 27 Nov 2001 10:33:26 -0500 (EST) Resent-Message-Id: <200111271533.KAA22704@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA22681 for ; Tue, 27 Nov 2001 10:33:19 -0500 (EST) Received: from sleepingbeauty.luciddream.com (luciddream.com [209.240.4.40]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA14025 for ; Tue, 27 Nov 2001 10:33:18 -0500 Received: from cb354016b (cb354016-b.rmdws1.il.home.com [24.182.42.44]) by sleepingbeauty.luciddream.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id com for ; Tue, 27 Nov 2001 10:26:58 -0500 From: "David Lewis" To: "'WebDAV'" Date: Tue, 27 Nov 2001 09:32:42 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AD7F@SUS-MA1IT01> Importance: Normal Subject: Remote Proofing question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5673 X-Loop: w3c-dist-auth@w3.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 Hello, I am a lurker on this list and I find it very interesting. We are developing a solution for remote proofing for printers and publishers and I feel this work has some potential in that market. My first question is how do you think WebDav and remote proofing come together? Also due to my limited participation in this list I wondered how I might switch to the digest version? Thanks David Lewis President Lucid Dream Software, Inc. _________________________________________________ TIFF/ITflow for producing TIFF/IT and Scitex Brisque formats DCSflow for producing DCS 2 files PRINTflow to convert Delta job to PostScript stream for other devices Thermal Compositor to convert color Delta job into a single separation Grayscale Delta job for Dylux OnTimeProof completely automated remote proofing solution for Delta Harlequin-Delta Out an Output plugin for the Harlequin Rip to create Delta jobs. This plugin can also be configured with Harlequin TrapMaster, their brand new raster trapping software. This allows you to configure a Harlequin station as an Offline Delta station. www.luciddream.com david@luciddream.com 847-202-8424 From w3c-dist-auth-request@w3.org Tue Nov 27 12:33: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 MAA12113 for ; Tue, 27 Nov 2001 12:33:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA29356; Tue, 27 Nov 2001 12:32:48 -0500 (EST) Resent-Date: Tue, 27 Nov 2001 12:32:48 -0500 (EST) Resent-Message-Id: <200111271732.MAA29356@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA29332 for ; Tue, 27 Nov 2001 12:32:32 -0500 (EST) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA12841 for ; Tue, 27 Nov 2001 12:32:32 -0500 Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id fARHV4e08045 for ; Tue, 27 Nov 2001 09:31:04 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id fARHV5112685 for ; Tue, 27 Nov 2001 09:31:05 -0800 (PST) Received: from [192.168.1.4] ([153.32.159.243]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GNGZD700.U19; Tue, 27 Nov 2001 09:31:55 -0800 Mime-Version: 1.0 X-Sender: dbrotsky@mailsj-v1.corp.adobe.com Message-Id: In-Reply-To: References: Date: Tue, 27 Nov 2001 08:30:37 -0800 To: "Jason Crawford" From: Daniel Brotsky Cc: w3c-dist-auth@w3.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5674 X-Loop: w3c-dist-auth@w3.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. I agree with Julian that we should make the 2518 revise be namespace-compliant. 2. I agree with Julian's suggestion that we table this for a few weeks while Lisa and others try again to get the "DAV:" string made an acceptable namespace. 3. If we can't get "DAV:" accepted, I agree with using Jason's suggestion: At 11:06 AM -0500 11/23/01, Jason Crawford wrote: >1) We pick a second URI for our namespace. I'll suggest >http://webdav.org/base. >2) We update the spec to use this new URI in the examples. >3) We deprecate DAV: as the namespace URI in the spec. >4) ASAP implementors start accepting the new URI in addition to DAV: >5) Later implementors can start transmitting the new URI. FWIW, I believe that making this change *will* eventually cause older DAV clients and servers to stop working, which I think was something Lisa raised in a different way. I believe this because I think eventually the cost-savings of using common namespace-processing technology will cause the hand-written backwards-compatibly-accept-DAV: patches to become too expensive, at which point they will go away. So 4. I agree that we will need an indicator (in OPTIONS) of spec-revision, and I believe that servers which *don't* accept "DAV:" should indicate that they are not "DAV servers" using the indicators that older clients look for. 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 Nov 28 16:30: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 QAA14165 for ; Wed, 28 Nov 2001 16:30:25 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA28458; Wed, 28 Nov 2001 16:23:51 -0500 (EST) Resent-Date: Wed, 28 Nov 2001 16:23:51 -0500 (EST) Resent-Message-Id: <200111282123.QAA28458@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA28419 for ; Wed, 28 Nov 2001 16:23:37 -0500 (EST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA32419; Wed, 28 Nov 2001 16:23:37 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA71518; Wed, 28 Nov 2001 16:20:23 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fASLN4T130786; Wed, 28 Nov 2001 16:23:04 -0500 To: "Roy T. Fielding" Cc: uri@w3.org, "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Wed, 28 Nov 2001 16:15:23 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V509_11062001 |November 6, 2001) at 11/28/2001 04:23:03 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5675 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Roy, > In other words, I think that "scheme:" is only a valid identifier for the > namespace if the scheme defines it as such. What are you suggesting here? Where would a scheme define it as such? Would this require a change to 2396 that you'd support? Or some place else? J. From w3c-dist-auth-request@w3.org Wed Nov 28 17:00: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 RAA16830 for ; Wed, 28 Nov 2001 17:00:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA00947; Wed, 28 Nov 2001 16:54:35 -0500 (EST) Resent-Date: Wed, 28 Nov 2001 16:54:35 -0500 (EST) Resent-Message-Id: <200111282154.QAA00947@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA00920 for ; Wed, 28 Nov 2001 16:54:21 -0500 (EST) 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 QAA08708 for ; Wed, 28 Nov 2001 16:54:21 -0500 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id fASLrjN21748 for ; Wed, 28 Nov 2001 13:53:45 -0800 Received: from waka.ebuilt.net (IDENT:root@i142.ir.ebuilt.net [10.1.2.142]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id fASLrjZ21667; Wed, 28 Nov 2001 13:53:45 -0800 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id fASLn6x02002; Wed, 28 Nov 2001 13:49:06 -0800 Date: Wed, 28 Nov 2001 13:49:06 -0800 From: "Roy T. Fielding" To: Jason Crawford Cc: uri@w3.org, "'WebDAV'" Message-ID: <20011128134906.A1986@waka.ebuilt.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5676 X-Loop: w3c-dist-auth@w3.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, Nov 28, 2001 at 04:15:23PM -0500, Jason Crawford wrote: > > Roy, > > > In other words, I think that "scheme:" is only a valid identifier for the > > namespace if the scheme defines it as such. > > What are you suggesting here? Where would a scheme define it as such? > Would this require a change to 2396 that you'd support? Or some place > else? If two or more independent implementations are doing something with the protocol that is not allowed by the RFC, and rough consensus within the working group is that those implementations are doing no harm, then the protocol specification should change to accommodate them. Whatever change is made to 2396 will have to also take into account the history of existing implementations. That doesn't mean it will change any time soon, but we can add it to the list of errata, which I need to compile anyway. I still think it is incredibly stupid for the webdav examples to be using "D:" as an xmlns, since the only thing that accomplishes is an unnecessary dependency on XML namespaces. ....Roy From w3c-dist-auth-request@w3.org Wed Nov 28 17:31: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 RAA19696 for ; Wed, 28 Nov 2001 17:31:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA03693; Wed, 28 Nov 2001 17:30:42 -0500 (EST) Resent-Date: Wed, 28 Nov 2001 17:30:42 -0500 (EST) Resent-Message-Id: <200111282230.RAA03693@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id RAA03651 for ; Wed, 28 Nov 2001 17:30:22 -0500 (EST) 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 RAA16275; Wed, 28 Nov 2001 17:30:16 -0500 Received: from lisa [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R); Wed, 28 Nov 2001 23:29:11 +0100 From: "Julian Reschke" To: "Roy T. Fielding" , "Jason Crawford" Cc: , "'WebDAV'" Date: Wed, 28 Nov 2001 23:29:09 +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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20011128134906.A1986@waka.ebuilt.net> X-MDRemoteIP: 192.168.1.23 X-Return-Path: julian.reschke@greenbytes.de Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5677 X-Loop: w3c-dist-auth@w3.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: uri-request@w3.org [mailto:uri-request@w3.org]On Behalf Of Roy T. > Fielding > Sent: Wednesday, November 28, 2001 10:49 PM > To: Jason Crawford > Cc: uri@w3.org; 'WebDAV' > Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency > > > On Wed, Nov 28, 2001 at 04:15:23PM -0500, Jason Crawford wrote: > > > > Roy, > > > > > In other words, I think that "scheme:" is only a valid > identifier for the > > > namespace if the scheme defines it as such. > > > > What are you suggesting here? Where would a scheme define it as such? > > Would this require a change to 2396 that you'd support? Or some place > > else? > > If two or more independent implementations are doing something with the > protocol that is not allowed by the RFC, and rough consensus within the > working group is that those implementations are doing no harm, then the > protocol specification should change to accommodate them. Whatever change > is made to 2396 will have to also take into account the history of > existing implementations. > > That doesn't mean it will change any time soon, but we can add it to the > list of errata, which I need to compile anyway. > > I still think it is incredibly stupid for the webdav examples to be using > "D:" as an xmlns, since the only thing that accomplishes is an unnecessary > dependency on XML namespaces. The WebDAV spec is using "D" as namespace *prefix*, with the prefix being mapped to the namespace name "DAV:". And yes, I'm with you that this wasn't a good idea. From w3c-dist-auth-request@w3.org Wed Nov 28 18:17:42 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 SAA23572 for ; Wed, 28 Nov 2001 18:17:42 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA07062; Wed, 28 Nov 2001 18:14:49 -0500 (EST) Resent-Date: Wed, 28 Nov 2001 18:14:49 -0500 (EST) Resent-Message-Id: <200111282314.SAA07062@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA07035 for ; Wed, 28 Nov 2001 18:14:21 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37184.rational.com [192.229.37.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA27617 for ; Wed, 28 Nov 2001 18:14:20 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Wed, 28 Nov 2001 18:13:48 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Nov 2001 18:13:48 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AD97@SUS-MA1IT01> From: "Clemm, Geoff" To: "'WebDAV'" Date: Wed, 28 Nov 2001 18:13:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5678 X-Loop: w3c-dist-auth@w3.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 do not understand your point here. WebDAV uses XML namespaces to provide extensibility for property names, not because it lets the examples be shorter. If you are going to use namespaces, you have to have an xmlns declaration, and "D:" is as good a choice for a namespace identifier as any other. Cheers, Geoff -----Original Message----- From: Roy T. Fielding [mailto:fielding@ebuilt.com] I still think it is incredibly stupid for the webdav examples to be using "D:" as an xmlns, since the only thing that accomplishes is an unnecessary dependency on XML namespaces. From w3c-dist-auth-request@w3.org Wed Nov 28 19:02:32 2001 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26970 for ; Wed, 28 Nov 2001 19:02:32 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA08462; Wed, 28 Nov 2001 19:00:28 -0500 (EST) Resent-Date: Wed, 28 Nov 2001 19:00:28 -0500 (EST) Resent-Message-Id: <200111290000.TAA08462@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA08436 for ; Wed, 28 Nov 2001 19:00:17 -0500 (EST) 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 TAA03467 for ; Wed, 28 Nov 2001 19:00:16 -0500 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id fASNxkM00996 for ; Wed, 28 Nov 2001 15:59:46 -0800 Received: from waka.ebuilt.net (IDENT:root@i142.ir.ebuilt.net [10.1.2.142]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id fASNxjZ00915; Wed, 28 Nov 2001 15:59:45 -0800 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id fASNtrL02283; Wed, 28 Nov 2001 15:55:54 -0800 Date: Wed, 28 Nov 2001 15:55:53 -0800 From: "Roy T. Fielding" To: "Clemm, Geoff" Cc: "'WebDAV'" Message-ID: <20011128155553.D1986@waka.ebuilt.net> References: <3906C56A7BD1F54593344C05BD1374B103F8AD97@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AD97@SUS-MA1IT01> User-Agent: Mutt/1.3.20i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5679 X-Loop: w3c-dist-auth@w3.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, Nov 28, 2001 at 06:13:42PM -0500, Clemm, Geoff wrote: > I do not understand your point here. > > WebDAV uses XML namespaces to provide extensibility for > property names, not because it lets the examples > be shorter. Maybe that should be said in the spec. > If you are going to use namespaces, > you have to have an xmlns declaration, and "D:" is as good > a choice for a namespace identifier as any other. Ah, finally an explanation that makes some sense! I should have known it was something as simple as XML being, well, XML-ish. ....Roy From w3c-dist-auth-request@w3.org Thu Nov 29 01:20: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 BAA00803 for ; Thu, 29 Nov 2001 01:20:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA21452; Thu, 29 Nov 2001 01:15:48 -0500 (EST) Resent-Date: Thu, 29 Nov 2001 01:15:48 -0500 (EST) Resent-Message-Id: <200111290615.BAA21452@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA21380 for ; Thu, 29 Nov 2001 01:15:23 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA00436 for ; Thu, 29 Nov 2001 01:15:23 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id BAA159508; Thu, 29 Nov 2001 01:12:08 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fAT6EoT152422; Thu, 29 Nov 2001 01:14:50 -0500 To: "Roy T. Fielding" Cc: "Clemm, Geoff" , "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Thu, 29 Nov 2001 01:01:03 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9 |November 16, 2001) at 11/29/2001 01:14:50 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Purpose of Namespace Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5680 X-Loop: w3c-dist-auth@w3.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, Nov 28, 2001 at 06:13:42PM -0500, Clemm, Geoff wrote: > > I do not understand your point here. > > > > WebDAV uses XML namespaces to provide extensibility for > > property names, not because it lets the examples > > be shorter. > Maybe that should be said in the spec. I can add that to the issues/todo list, but I think I've heard Jim and a few other people mention something about the prefered style of prose in the spec, so I thought I'd check first... Is this something we want to put in the spec... or would we put that in a meta document?... like an annotated spec? If latter, I'm sure I can denote that in the issues list. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Nov 29 01:20: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 BAA00814 for ; Thu, 29 Nov 2001 01:20:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA21475; Thu, 29 Nov 2001 01:16:01 -0500 (EST) Resent-Date: Thu, 29 Nov 2001 01:16:01 -0500 (EST) Resent-Message-Id: <200111290616.BAA21475@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA21391 for ; Thu, 29 Nov 2001 01:15:24 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA00438; Thu, 29 Nov 2001 01:15:24 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id BAA159510; Thu, 29 Nov 2001 01:12:09 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fAT6EqT134846; Thu, 29 Nov 2001 01:14:52 -0500 To: "Roy T. Fielding" Cc: uri@w3.org, "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Thu, 29 Nov 2001 01:08:19 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9 |November 16, 2001) at 11/29/2001 01:14:52 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5681 X-Loop: w3c-dist-auth@w3.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, Nov 28, 2001 at 04:15:23PM -0500, Jason Crawford wrote: > > Roy, > > > In other words, I think that "scheme:" is only a valid identifier for the > > namespace if the scheme defines it as such. > > What are you suggesting here? Where would a scheme define it as such? > > Would this require a change to 2396 that you'd support? Or some place > > else? > If two or more independent implementations are doing something with the > protocol that is not allowed by the RFC, and rough consensus within the > working group is that those implementations are doing no harm, then the > protocol specification should change to accommodate them. Whatever change > is made to 2396 will have to also take into account the history of > existing implementations. > > That doesn't mean it will change any time soon, but we can add it to the > list of errata, which I need to compile anyway. Then it sounds to me like we have enough resolution of this for me to log it on the webdav issues list as temporarily resolved, and to note that it should be revisited again in a year to insure that the change in 2396 actually can be counted on. Any problems with this? J. From w3c-dist-auth-request@w3.org Thu Nov 29 10:23: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 KAA11769 for ; Thu, 29 Nov 2001 10:23:56 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA05578; Thu, 29 Nov 2001 07:25:51 -0500 (EST) Resent-Date: Thu, 29 Nov 2001 07:25:51 -0500 (EST) Resent-Message-Id: <200111291225.HAA05578@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA05508 for ; Thu, 29 Nov 2001 07:25:25 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA17530; Thu, 29 Nov 2001 07:25:24 -0500 From: Patrick.Stickler@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fATCQ6A10085; Thu, 29 Nov 2001 14:26:06 +0200 (EET) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 29 Nov 2001 14:25:22 +0200 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 29 Nov 2001 14:25:20 +0200 Message-ID: To: fielding@ebuilt.com, ejw@cse.ucsc.edu Cc: w3c-dist-auth@w3.org, uri@w3.org Date: Thu, 29 Nov 2001 14:25:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5684 X-Loop: w3c-dist-auth@w3.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, you could still have "http:" and two additional > URI/URL/URNs for the > > version-specific definitions of the http URL space. > > Yes, but only if we defined it to be such a thing, which we > won't do because > Web browsers still discard the scheme name if it is the same > as the scheme > of the referring document. What makes you think that web browsers are the only (or even primary) agents utilizing a "scheme:" URI approach? And what's to say that web browsers should be discarding the scheme? Patrick From w3c-dist-auth-request@w3.org Thu Nov 29 10:23: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 KAA11791 for ; Thu, 29 Nov 2001 10:23:57 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA05405; Thu, 29 Nov 2001 07:22:22 -0500 (EST) Resent-Date: Thu, 29 Nov 2001 07:22:22 -0500 (EST) Resent-Message-Id: <200111291222.HAA05405@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA05351 for ; Thu, 29 Nov 2001 07:21:46 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA17127; Thu, 29 Nov 2001 07:21:41 -0500 From: Patrick.Stickler@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fATCMNA06905; Thu, 29 Nov 2001 14:22:23 +0200 (EET) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 29 Nov 2001 14:21:39 +0200 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 29 Nov 2001 14:21:39 +0200 Message-ID: To: fielding@ebuilt.com, ejw@cse.ucsc.edu Cc: w3c-dist-auth@w3.org, uri@w3.org Date: Thu, 29 Nov 2001 14:21:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5683 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > In other words, I think that "scheme:" is only a valid > identifier for the > namespace if the scheme defines it as such. Fair enough. Though it seems that an RFC revision would still be in order to permit schemes to define "scheme:" as a valid absolute URI -- and also once some schemes adopt such a practice, it will be pretty darn hard to keep folks from presuming that "foo:" is the canonical, official URI denoting the scheme. It may be more practical to just state it once and for all in a revision of the RFC. Otherwise, all existing schemes that would like to use "scheme:" would themselves have to be revised. Clearly, though, namespace and other sub-scheme identifiers (e.g. "urn:issn:" etc.) are the domain of each particular scheme as to whether they are meaninful or allowed. Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com From w3c-dist-auth-request@w3.org Thu Nov 29 10:24: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 KAA11807 for ; Thu, 29 Nov 2001 10:23:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA07318; Thu, 29 Nov 2001 08:04:04 -0500 (EST) Resent-Date: Thu, 29 Nov 2001 08:04:04 -0500 (EST) Resent-Message-Id: <200111291304.IAA07318@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA07294 for ; Thu, 29 Nov 2001 08:03:43 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37184.rational.com [192.229.37.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA22002 for ; Thu, 29 Nov 2001 08:03:43 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 29 Nov 2001 08:03:12 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Nov 2001 08:03:12 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B105028BD8@SUS-MA1IT01> From: "Clemm, Geoff" To: "'WebDAV'" Date: Thu, 29 Nov 2001 08:03:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Purpose of Namespace Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5685 X-Loop: w3c-dist-auth@w3.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 only namespace identified I would suggest *not* using in the examples is "DAV:". This in the past has misled folks into believing that if they use DAV:xxx, they can leave out the xmlns: declaration, which they can't. I'd vote to leave the examples as they are. If we use more than one namespace identifier, I guarantee we will get a continuing stream of "why do you have to use DAV: namespace identifier for PROPFIND and use D: namespace identifier for PROPPATCH?" questions. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Thursday, November 29, 2001 3:51 AM To: Jason Crawford; Roy T. Fielding Cc: Clemm, Geoff; 'WebDAV' Subject: RE: Purpose of Namespace I don't think that the spec should make any attempt to explain how XML works. What *could* be done is to vary the XML style in the examples. For instance, is even shorter, and as readable (at least in those examples where no mixing with other namespaces is needed). > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Thursday, November 29, 2001 7:01 AM > To: Roy T. Fielding > Cc: Clemm, Geoff; 'WebDAV' > Subject: Re: Purpose of Namespace > > > > > On Wed, Nov 28, 2001 at 06:13:42PM -0500, Clemm, Geoff wrote: > > > I do not understand your point here. > > > > > > WebDAV uses XML namespaces to provide extensibility for > > > property names, not because it lets the examples > > > be shorter. > > Maybe that should be said in the spec. > > I can add that to the issues/todo list, but I think I've heard Jim and a > few other people mention something about the prefered style of > prose in the > spec, so I thought I'd check first... > > Is this something we want to put in the spec... or would we put that in a > meta document?... like an annotated spec? > > If latter, I'm sure I can denote that in the issues list. > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > From w3c-dist-auth-request@w3.org Thu Nov 29 10:29:34 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 KAA12683 for ; Thu, 29 Nov 2001 10:29:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA26257; Thu, 29 Nov 2001 03:52:03 -0500 (EST) Resent-Date: Thu, 29 Nov 2001 03:52:03 -0500 (EST) Resent-Message-Id: <200111290852.DAA26257@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA26232 for ; Thu, 29 Nov 2001 03:51:40 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA24617 for ; Thu, 29 Nov 2001 03:51:39 -0500 Received: (qmail 26267 invoked by uid 0); 29 Nov 2001 08:51:08 -0000 Received: from pd9535fde.dip.t-dialin.net (HELO lisa) (217.83.95.222) by mail.gmx.net (mp001-rz3) with SMTP; 29 Nov 2001 08:51:08 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Roy T. Fielding" Cc: "Clemm, Geoff" , "'WebDAV'" Date: Thu, 29 Nov 2001 09:51:16 +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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Purpose of Namespace Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5682 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I don't think that the spec should make any attempt to explain how XML works. What *could* be done is to vary the XML style in the examples. For instance, is even shorter, and as readable (at least in those examples where no mixing with other namespaces is needed). > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Thursday, November 29, 2001 7:01 AM > To: Roy T. Fielding > Cc: Clemm, Geoff; 'WebDAV' > Subject: Re: Purpose of Namespace > > > > > On Wed, Nov 28, 2001 at 06:13:42PM -0500, Clemm, Geoff wrote: > > > I do not understand your point here. > > > > > > WebDAV uses XML namespaces to provide extensibility for > > > property names, not because it lets the examples > > > be shorter. > > Maybe that should be said in the spec. > > I can add that to the issues/todo list, but I think I've heard Jim and a > few other people mention something about the prefered style of > prose in the > spec, so I thought I'd check first... > > Is this something we want to put in the spec... or would we put that in a > meta document?... like an annotated spec? > > If latter, I'm sure I can denote that in the issues list. > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > From w3c-dist-auth-request@w3.org Thu Nov 29 12:25: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 MAA23855 for ; Thu, 29 Nov 2001 12:25:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA29708; Thu, 29 Nov 2001 12:24:30 -0500 (EST) Resent-Date: Thu, 29 Nov 2001 12:24:30 -0500 (EST) Resent-Message-Id: <200111291724.MAA29708@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA29679 for ; Thu, 29 Nov 2001 12:24:20 -0500 (EST) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA13636; Thu, 29 Nov 2001 12:24:20 -0500 Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id fATHOqm08607; Thu, 29 Nov 2001 09:24:52 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id fATHMr108490; Thu, 29 Nov 2001 09:22:53 -0800 (PST) Received: from larrypad ([130.248.184.182]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GNKOBJ00.U4S; Thu, 29 Nov 2001 09:23:43 -0800 Reply-To: From: "Larry Masinter" To: , , Cc: , Date: Thu, 29 Nov 2001 09:21:03 -0800 Message-ID: <00ec01c178fa$39294e50$0b78bfd1@larrypad> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5686 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > In other words, I think that "scheme:" is only a valid > > identifier for the > > namespace if the scheme defines it as such. > > Fair enough. Though it seems that an RFC revision would > still be in order to permit schemes to define "scheme:" > as a valid absolute URI -- and also once some schemes > adopt such a practice, it will be pretty darn hard to > keep folks from presuming that "foo:" is the canonical, > official URI denoting the scheme. It's pretty darn hard to keep folks from presuming that the moon is made from cheese, too, despite the fact that it wasn't when we got there. So if the official RFC says that an undecorated "scheme:" is only valid if the scheme definition says it is, and it only means what the scheme definition says it means, well, we'll just have to put up with those cheesy jokers who decide it means something else. > It may be more practical to just state it once and > for all in a revision of the RFC. Otherwise, all > existing schemes that would like to use "scheme:" would > themselves have to be revised. How does a URI scheme 'want' to do something? If YOU want to identify the URI scheme itself, you need something else. I would suggest using the process in http://www.ietf.org/draft/draft-mealling-iana-urn-02.txt making a "uri-scheme" space, and then using, say, urn:ietf:uri-scheme:http if you want to talk about the "http" URI scheme. I think it must be the case that "http:" remains illegal as a URI even though "DAV:" would be allowed. From w3c-dist-auth-request@w3.org Thu Nov 29 12:45:24 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 MAA25370 for ; Thu, 29 Nov 2001 12:45:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA00750; Thu, 29 Nov 2001 12:42:38 -0500 (EST) Resent-Date: Thu, 29 Nov 2001 12:42:38 -0500 (EST) Resent-Message-Id: <200111291742.MAA00750@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA00600 for ; Thu, 29 Nov 2001 12:42:10 -0500 (EST) 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 MAA17014 for ; Thu, 29 Nov 2001 12:42:09 -0500 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id fATHfZw28796 for ; Thu, 29 Nov 2001 09:41:35 -0800 Received: from waka.ebuilt.net (IDENT:root@i142.ir.ebuilt.net [10.1.2.142]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id fATHfYZ28630; Thu, 29 Nov 2001 09:41:34 -0800 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id fATHcqq01503; Thu, 29 Nov 2001 09:38:52 -0800 Date: Thu, 29 Nov 2001 09:38:52 -0800 From: "Roy T. Fielding" To: Patrick.Stickler@nokia.com Cc: ejw@cse.ucsc.edu, w3c-dist-auth@w3.org, uri@w3.org Message-ID: <20011129093852.A1481@waka.ebuilt.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5687 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > What makes you think that web browsers are the only (or > even primary) agents utilizing a "scheme:" URI approach? I don't know of any others. If I did, I would have had a test case for that in RFC 2396. > And what's to say that web browsers should be discarding > the scheme? RFC 1630 and all versions of CERN/W3C libwww. ....Roy From w3c-dist-auth-request@w3.org Thu Nov 29 18:12: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 SAA20418 for ; Thu, 29 Nov 2001 18:12:30 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAB19419; Thu, 29 Nov 2001 18:10:47 -0500 (EST) Resent-Date: Thu, 29 Nov 2001 18:10:47 -0500 (EST) Resent-Message-Id: <200111292310.SAB19419@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA19395 for ; Thu, 29 Nov 2001 18:10:20 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA13272 for ; Thu, 29 Nov 2001 18:10:21 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA451048 for ; Thu, 29 Nov 2001 18:07:06 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fATN9lp190570 for ; Thu, 29 Nov 2001 18:09:47 -0500 To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Thu, 29 Nov 2001 18:08:42 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9 |November 16, 2001) at 11/29/2001 06:09:47 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: issue: XML Namespace Concatenation Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5688 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: In a recent discussion, several people expressed dissatisfaction with rfc2518 section 23.4 which says that the Namespace URI and the local part are concatenated to determine the qualified tag name. I think someone even suggested that it was on the issues list and was going to be changed. As I look at the issues list, there is an item for it, but it doesn't look like it was resolved to take any action. What's the verdict on this issue? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Nov 29 18:32: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 SAA21614 for ; Thu, 29 Nov 2001 18:32:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA20708; Thu, 29 Nov 2001 18:31:50 -0500 (EST) Resent-Date: Thu, 29 Nov 2001 18:31:50 -0500 (EST) Resent-Message-Id: <200111292331.SAA20708@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA20688 for ; Thu, 29 Nov 2001 18:31:32 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37184.rational.com [192.229.37.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA16070 for ; Thu, 29 Nov 2001 18:31:32 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Thu, 29 Nov 2001 18:31:00 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Nov 2001 18:31:00 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AD9E@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Thu, 29 Nov 2001 18:30:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: issue: XML Namespace Concatenation Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5689 X-Loop: w3c-dist-auth@w3.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 would want us to remove any reference to concatentation, and to just say that a tag name is identified by the pair: Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Thursday, November 29, 2001 6:09 PM To: w3c-dist-auth@w3.org Subject: issue: XML Namespace Concatenation In a recent discussion, several people expressed dissatisfaction with rfc2518 section 23.4 which says that the Namespace URI and the local part are concatenated to determine the qualified tag name. I think someone even suggested that it was on the issues list and was going to be changed. As I look at the issues list, there is an item for it, but it doesn't look like it was resolved to take any action. What's the verdict on this issue? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Nov 29 23:20:43 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 XAA07265 for ; Thu, 29 Nov 2001 23:20:42 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA01558; Thu, 29 Nov 2001 23:19:42 -0500 (EST) Resent-Date: Thu, 29 Nov 2001 23:19:42 -0500 (EST) Resent-Message-Id: <200111300419.XAA01558@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA01434 for ; Thu, 29 Nov 2001 23:19:19 -0500 (EST) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA21580; Thu, 29 Nov 2001 23:19:16 -0500 Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id XAA03496; Thu, 29 Nov 2001 23:17:41 -0500 Message-Id: <200111300417.XAA03496@markbaker.ca> To: fielding@ebuilt.com (Roy T. Fielding) Date: Thu, 29 Nov 2001 23:17:41 -0500 (EST) Cc: LMM@acm.org (Larry Masinter), duerst@w3.org ('Martin Duerst'), stefan.eissing@greenbytes.de ('Stefan Eissing'), w3c-dist-auth@w3.org ('WebDAV'), uri@w3.org In-Reply-To: <20011126152733.B8631@waka.ebuilt.net> from "Roy T. Fielding" at Nov 26, 2001 03:27:33 PM From: Mark Baker X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5690 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit (sorry for the delay, I've been out of email range) > > Interesting. Just to clarify, what are you suggesting be changed? > > That "foo:" be a valid absolute URI reference, or a valid relative > > one? > > An absolute URI -- otherwise, the parsers would have to be changed. Ok, thanks. But I'd point out that "about:" appears to me to be designed to be a relative URI; if IE supported "about:", it wouldn't pop up Communicator's info screen, it would pop up one about IE. That's not the case for "dav:", though. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com From w3c-dist-auth-request@w3.org Fri Nov 30 03:45:02 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 DAA29549 for ; Fri, 30 Nov 2001 03:45:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA09560; Fri, 30 Nov 2001 03:43:33 -0500 (EST) Resent-Date: Fri, 30 Nov 2001 03:43:33 -0500 (EST) Resent-Message-Id: <200111300843.DAA09560@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA09537 for ; Fri, 30 Nov 2001 03:43:03 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA13848 for ; Fri, 30 Nov 2001 03:43:02 -0500 Received: (qmail 16151 invoked by uid 0); 30 Nov 2001 08:42:29 -0000 Received: from pd9535d81.dip.t-dialin.net (HELO lisa) (217.83.93.129) by mail.gmx.net (mp013-rz3) with SMTP; 30 Nov 2001 08:42:29 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Fri, 30 Nov 2001 09:42:39 +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 V6.00.2600.0000 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AD9E@SUS-MA1IT01> Subject: RE: issue: XML Namespace Concatenation Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5691 X-Loop: w3c-dist-auth@w3.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 Correction: This is basically what the XML namespace rec says. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, November 30, 2001 12:31 AM > To: w3c-dist-auth@w3.org > Subject: RE: issue: XML Namespace Concatenation > > > I would want us to remove any reference to concatentation, > and to just say that a tag name is identified by the pair: > > > Cheers, > Geoff > > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Thursday, November 29, 2001 6:09 PM > To: w3c-dist-auth@w3.org > Subject: issue: XML Namespace Concatenation > > > > In a recent discussion, several people expressed dissatisfaction with > rfc2518 section 23.4 which says that the Namespace URI and the local part > are concatenated to determine the qualified tag name. I think > someone even > suggested that it was on the issues list and was going to be > changed. As I > look at the issues list, there is an item for it, but it doesn't look like > it was resolved to take any action. > > What's the verdict on this issue? > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > From w3c-dist-auth-request@w3.org Fri Nov 30 04:56: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 EAA00907 for ; Fri, 30 Nov 2001 04:56:40 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA12644; Fri, 30 Nov 2001 04:55:41 -0500 (EST) Resent-Date: Fri, 30 Nov 2001 04:55:41 -0500 (EST) Resent-Message-Id: <200111300955.EAA12644@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA12616 for ; Fri, 30 Nov 2001 04:55:33 -0500 (EST) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA21343 for ; Fri, 30 Nov 2001 04:55:33 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id BAA23187 for w3c-dist-auth@w3.org; Fri, 30 Nov 2001 01:56:05 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Fri, 30 Nov 2001 01:56:04 -0800 From: Greg Stein To: w3c-dist-auth@w3.org Message-ID: <20011130015604.L22950@lyra.org> Mail-Followup-To: w3c-dist-auth@w3.org References: <3906C56A7BD1F54593344C05BD1374B103F8AD9E@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AD9E@SUS-MA1IT01>; from gclemm@rational.com on Thu, Nov 29, 2001 at 06:30:59PM -0500 X-URL: http://www.lyra.org/greg/ Subject: Re: issue: XML Namespace Concatenation Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5692 X-Loop: w3c-dist-auth@w3.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 Geoff. mod_dav certainly treats the namespace/name thing as a tuple, rather than a concatenation. In other words, ns="DAV:" name="foo" is different from ns="DAV:f" name="oo". It seems that I recall one conversation that said that most clients and servers treated it that way. Cheers, -g On Thu, Nov 29, 2001 at 06:30:59PM -0500, Clemm, Geoff wrote: > I would want us to remove any reference to concatentation, > and to just say that a tag name is identified by the pair: > > > Cheers, > Geoff > > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Thursday, November 29, 2001 6:09 PM > To: w3c-dist-auth@w3.org > Subject: issue: XML Namespace Concatenation > > > > In a recent discussion, several people expressed dissatisfaction with > rfc2518 section 23.4 which says that the Namespace URI and the local part > are concatenated to determine the qualified tag name. I think someone even > suggested that it was on the issues list and was going to be changed. As I > look at the issues list, there is an item for it, but it doesn't look like > it was resolved to take any action. > > What's the verdict on this issue? > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Nov 30 05:00: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 FAA00957 for ; Fri, 30 Nov 2001 05:00:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA12968; Fri, 30 Nov 2001 04:59:58 -0500 (EST) Resent-Date: Fri, 30 Nov 2001 04:59:58 -0500 (EST) Resent-Message-Id: <200111300959.EAA12968@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA12939 for ; Fri, 30 Nov 2001 04:59:48 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA21779 for ; Fri, 30 Nov 2001 04:59:48 -0500 Received: (qmail 2841 invoked by uid 0); 30 Nov 2001 09:59:17 -0000 Received: from pd9535d81.dip.t-dialin.net (HELO lisa) (217.83.93.129) by mail.gmx.net (mp011-rz3) with SMTP; 30 Nov 2001 09:59:17 -0000 From: "Julian Reschke" To: "Greg Stein" , Date: Fri, 30 Nov 2001 10:59:27 +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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20011130015604.L22950@lyra.org> Subject: RE: issue: XML Namespace Concatenation Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5693 X-Loop: w3c-dist-auth@w3.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 summary in: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0343.html > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > Sent: Friday, November 30, 2001 10:56 AM > To: w3c-dist-auth@w3.org > Subject: Re: issue: XML Namespace Concatenation > > > I agree with Geoff. > > mod_dav certainly treats the namespace/name thing as a tuple, > rather than a > concatenation. In other words, ns="DAV:" name="foo" is different from > ns="DAV:f" name="oo". > > It seems that I recall one conversation that said that most clients and > servers treated it that way. > > Cheers, > -g > > On Thu, Nov 29, 2001 at 06:30:59PM -0500, Clemm, Geoff wrote: > > I would want us to remove any reference to concatentation, > > and to just say that a tag name is identified by the pair: > > > > > > Cheers, > > Geoff > > > > -----Original Message----- > > From: Jason Crawford [mailto:ccjason@us.ibm.com] > > Sent: Thursday, November 29, 2001 6:09 PM > > To: w3c-dist-auth@w3.org > > Subject: issue: XML Namespace Concatenation > > > > > > > > In a recent discussion, several people expressed dissatisfaction with > > rfc2518 section 23.4 which says that the Namespace URI and the > local part > > are concatenated to determine the qualified tag name. I think > someone even > > suggested that it was on the issues list and was going to be > changed. As I > > look at the issues list, there is an item for it, but it > doesn't look like > > it was resolved to take any action. > > > > What's the verdict on this issue? > > > > ------------------------------------------ > > Phone: 914-784-7569, ccjason@us.ibm.com > > -- > Greg Stein, http://www.lyra.org/ > From w3c-dist-auth-request@w3.org Fri Nov 30 06:48:05 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 GAA04930 for ; Fri, 30 Nov 2001 06:48:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA15915; Fri, 30 Nov 2001 06:43:26 -0500 (EST) Resent-Date: Fri, 30 Nov 2001 06:43:26 -0500 (EST) Resent-Message-Id: <200111301143.GAA15915@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA15889 for ; Fri, 30 Nov 2001 06:43:14 -0500 (EST) Received: from egateout.merant.com (rock-gate.merant.com [63.79.165.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA31766 for ; Fri, 30 Nov 2001 06:43:13 -0500 Received: from stalmail.eu.merant.com (stalmail.eu.merant.com [10.130.13.220]) by egateout.merant.com (Build 98 8.9.3/NT-8.9.3) with SMTP id GAA17136 for ; Fri, 30 Nov 2001 06:40:42 -0500 Received: by stalmail.eu.merant.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Nov 2001 11:40:34 -0000 Message-ID: <20CF1CE11441D411919C0008C7C5A13B034B838B@stalmail.eu.merant.com> From: Peter Raymond To: w3c-dist-auth@w3.org Date: Fri, 30 Nov 2001 11:40:32 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17993.D1A528E0" Subject: Issues/questions about the bindings protocol specification... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5694 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C17993.D1A528E0 Content-Type: text/plain; charset="iso-8859-1" Hi, A group of people here at MERANT have recently completed reading/reviewing the bindings protocol document. We recorded some issues/questions about the specification. I understand that this document has completed a final call period, but does anyone know the status of the document, there are open issues etc, is there a timeframe for it becoming a "proposed standard"? Is anyone actively editing or revising the document? Here are the questions/issues we had with the specification: 1) Section 9 says that methods MUST produce the same results when submitted on different bindings to the same resource. I disagree, if you issue a PROPFIND request on /coll1/bar the href returned would be /coll1/bar, if you issue the same PROPFIND request on /coll2/bar (which is bound to the same resource) the href returned would be /coll2/bar. The responses would not be the same. I am sure there could be other examples of this. 2) We found the definition of the DAV:bindings property in section 13.1 very confusing. It would be good to show an example of this property, an interesting example would be the DAV:bindings on resource R2 from Figure 1. I will send a separate e-mail on this issue. 3) Section 15 describes capability discovery and shows the use of a header called Public. I cannot find a definition of this header in RFC2518 or RFC2616 (there is a Cache-Control public directive but no Public header). In what specification is this header defined? Maybe I just missed it. 4) Also on the subject of section 15, it seems we have many ways of finding out what capabilities a server or a resource has...Allow header, Public header, DAV header, DAV:supported-method-set property (in DeltaV). I find this confusing, and I know in the various WebDAV groups there has been some discussion of these and the differences between them, I think they should be defined clearly and consistently in all the WebDAV related specifications. 5) Section 18 there is a missing space in the last sentence (after the 507 code). 6) Is there anyone looking at how bindings affect the other protocols, for example have we looked at how DeltaV features (like Baseline etc) are affected by bindings? BTW...are there any server vendors out there that implement or are thinking of implementing the BIND method? Similarly are any clients using it? Regards, -- Peter Raymond - MERANT Principal Architect (PVCS) Tel: +44 (0)1727 813362 Fax: +44 (0)1727 869804 mailto:Peter.Raymond@merant.com WWW: http://www.merant.com ------_=_NextPart_001_01C17993.D1A528E0 Content-Type: text/html; charset="iso-8859-1" Issues/questions about the bindings protocol specification...

Hi,

A group of people here at MERANT have recently completed reading/reviewing
the bindings protocol document.  We recorded some issues/questions about the
specification.

I understand that this document has completed a final call period, but does
anyone know the status of the document, there are open issues etc, is there
a timeframe for it becoming a "proposed standard"?  Is anyone actively
editing or revising the document?

Here are the questions/issues we had with the specification:

1) Section 9 says that methods MUST produce the same results when submitted
   on different bindings to the same resource.  I disagree, if you issue a
   PROPFIND request on /coll1/bar the href returned would be /coll1/bar,
   if you issue the same PROPFIND request on /coll2/bar (which is bound to
   the same resource) the href returned would be /coll2/bar.  The responses
   would not be the same.  I am sure there could be other examples of this.

2) We found the definition of the DAV:bindings property in section 13.1
   very confusing.  It would be good to show an example of this property,
   an interesting example would be the DAV:bindings on resource R2 from
   Figure 1.  I will send a separate e-mail on this issue.

3) Section 15 describes capability discovery and shows the use of a header
   called Public.  I cannot find a definition of this header in RFC2518 or
   RFC2616 (there is a Cache-Control public directive but no Public header).
   In what specification is this header defined?  Maybe I just missed it.

4) Also on the subject of section 15, it seems we have many ways of finding
   out what capabilities a server or a resource has...Allow header, Public
   header, DAV header, DAV:supported-method-set property (in DeltaV).
   I find this confusing, and I know in the various WebDAV groups there has
   been some discussion of these and the differences between them, I think
   they should be defined clearly and consistently in all the WebDAV related
   specifications.
  
5) Section 18 there is a missing space in the last sentence (after the 507
   code).

6) Is there anyone looking at how bindings affect the other protocols,
   for example have we looked at how DeltaV features (like Baseline
   etc) are affected by bindings?

BTW...are there any server vendors out there that implement or are thinking
of implementing the BIND method?  Similarly are any clients using it?

Regards,
--
Peter Raymond - MERANT
Principal Architect (PVCS)
Tel: +44 (0)1727 813362
Fax: +44 (0)1727 869804
mailto:Peter.Raymond@merant.com
WWW: http://www.merant.com


------_=_NextPart_001_01C17993.D1A528E0-- From w3c-dist-auth-request@w3.org Fri Nov 30 07:17:16 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 HAA06033 for ; Fri, 30 Nov 2001 07:17:14 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA16511; Fri, 30 Nov 2001 07:10:12 -0500 (EST) Resent-Date: Fri, 30 Nov 2001 07:10:12 -0500 (EST) Resent-Message-Id: <200111301210.HAA16511@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA16475 for ; Fri, 30 Nov 2001 07:09:47 -0500 (EST) Received: from egateout.merant.com (rock-gate.merant.com [63.79.165.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA01416 for ; Fri, 30 Nov 2001 07:09:47 -0500 Received: from stalmail.eu.merant.com (stalmail.eu.merant.com [10.130.13.220]) by egateout.merant.com (Build 98 8.9.3/NT-8.9.3) with SMTP id HAA17550 for ; Fri, 30 Nov 2001 07:07:09 -0500 Received: by stalmail.eu.merant.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Nov 2001 12:07:01 -0000 Message-ID: <20CF1CE11441D411919C0008C7C5A13B034B83A6@stalmail.eu.merant.com> From: Peter Raymond To: w3c-dist-auth@w3.org Date: Fri, 30 Nov 2001 12:06:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C17997.81BEC3F0" Subject: More detail on the DAV:bindings property... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5695 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C17997.81BEC3F0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17997.81BEC3F0" ------_=_NextPart_001_01C17997.81BEC3F0 Content-Type: text/plain; charset="iso-8859-1" Hi, In my earlier e-mail I mentioned that I was unsure about the contents of the DAV:bindings property. Here is some more detail about why I think it is unclear, also find attached some PowerPoint slides which I used to try to understand the bindings property. I guess there are two things in the text that mislead me: 1) Section 13.1 says that the property "contains a complete list of all bindings to that resource", but also says it is necessary to select one URI mapping for a collection. It seems to contradict itself, it is not complete because it only contains one URI mapping for a collection. 2) It also says you should preferably use the mapping in the request-URI of the BIND request. But I am unclear as to which BIND request. It is a PROPFIND request which was issued to find the DAV:bindings property, not a BIND request. Perhaps it means the last BIND request for that collection or perhaps it means the first bind request for the resource in the collection? So using the example in Figure 1 of the bindings document you have the URI paths: /coll1/bar /coll2/bar /coll3/foo /coll1/ and /coll2/ are the same collection resource but all these URIs point to the same resource (R2). Imagine you make a PROPFIND request on /coll2/bar, asking for the DAV:bindings property...should you get: /coll1/ bar /coll2/ bar /coll3/ foo That is a "complete" list of all bindings for resource R2...BUT section 13.1 says you should pick only one URI for a given collection, so perhaps it should return: /coll2/ bar /coll3/ foo Because /coll1/ and /coll2/ are the same collection I have picked just one URI mapping for that collection...in this case I used the URI mapping from the PROPFIND request. Is my understanding of this correct? <> Regards, -- Peter Raymond - MERANT Principal Architect (PVCS) Tel: +44 (0)1727 813362 Fax: +44 (0)1727 869804 mailto:Peter.Raymond@merant.com WWW: http://www.merant.com ------_=_NextPart_001_01C17997.81BEC3F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable More detail on the DAV:bindings property...

Hi,

In my earlier e-mail I mentioned = that I was unsure about the contents of
the DAV:bindings = property.  Here is some more detail about why I think it
is unclear, also find attached = some PowerPoint slides which I used to try
to understand the bindings = property.

I guess there are two things in = the text that mislead me:

1) Section 13.1 says that the = property "contains a complete list of all bindings
   to that = resource", but also says it is necessary to select one URI = mapping
   for a = collection.  It seems to contradict itself, it is not complete = because
   it only contains = one URI mapping for a collection.

2) It also says you should = preferably use the mapping in the request-URI of the
   BIND = request.  But I am unclear as to which BIND request.  It is a = PROPFIND
   request which was = issued to find the DAV:bindings property, not a BIND request.
   Perhaps it means = the last BIND request for that collection or perhaps it means
   the first bind = request for the resource in the collection?

So using the example in Figure 1 = of the bindings document you have the URI
paths:

/coll1/bar
/coll2/bar
/coll3/foo

/coll1/ and /coll2/ are the same = collection resource but all these URIs point to
the same resource (R2).

Imagine you make a PROPFIND = request on /coll2/bar, asking for the DAV:bindings
property...should you = get:

<bindings>
<href>/coll1/</href>
<segment>bar</segment>
<href>/coll2/</href>
<segment>bar</segment>
<href>/coll3/</href>
<segment>foo</segment>
</bindings>

That is a "complete" = list of all bindings for resource R2...BUT section 13.1 says you
should pick only one URI for a = given collection, so perhaps it should return:

<bindings>
<href>/coll2/</href>
<segment>bar</segment>
<href>/coll3/</href>
<segment>foo</segment>
</bindings>

Because /coll1/ and /coll2/ are = the same collection I have picked just one URI
mapping for that = collection...in this case I used the URI mapping from the
PROPFIND request.

Is my understanding of this = correct?

= <<BindingsProperty.ppt>>

Regards,
--
Peter Raymond - MERANT
Principal Architect (PVCS)
Tel: +44 (0)1727 813362
Fax: +44 (0)1727 869804
mailto:Peter.Raymond@merant.com=
WWW: http://www.merant.com


------_=_NextPart_001_01C17997.81BEC3F0-- ------_=_NextPart_000_01C17997.81BEC3F0 Content-Type: application/vnd.ms-powerpoint; name="BindingsProperty.ppt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="BindingsProperty.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAA+gAAAAAAAAAA EAAAAQEAAAEAAAD+////AAAAAPgAAAD5AAAAAAEAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8A bh7wfn4AAIJrU8vNk7HY3rFk8b+vwAf/iVBORw0KGgoAAAANSUhEUgAAAnMAAAHgCAIAAABByHwp AAAKN2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHicnJZ3VFPZFofPvTe9UJIQipTQa2hSAkgN vUiRLioxCRBKwJAAIjZEVHBEUZGmCDIo4ICjQ5GxIoqFAVGx6wQZRNRxcBQblklkrRnfvHnvzZvf H/d+a5+9z91n733WugCQ/IMFwkxYCYAMoVgU4efFiI2LZ2AHAQzwAANsAOBws7NCFvhGApkCfNiM bJkT+Be9ug4g+fsq0z+MwQD/n5S5WSIxAFCYjOfy+NlcGRfJOD1XnCW3T8mYtjRNzjBKziJZgjJW k3PyLFt89pllDznzMoQ8GctzzuJl8OTcJ+ONORK+jJFgGRfnCPi5Mr4mY4N0SYZAxm/ksRl8TjYA KJLcLuZzU2RsLWOSKDKCLeN5AOBIyV/w0i9YzM8Tyw/FzsxaLhIkp4gZJlxTho2TE4vhz89N54vF zDAON40j4jHYmRlZHOFyAGbP/FkUeW0ZsiI72Dg5ODBtLW2+KNR/Xfybkvd2ll6Ef+4ZRB/4w/ZX fpkNALCmZbXZ+odtaRUAXesBULv9h81gLwCKsr51Dn1xHrp8XlLE4ixnK6vc3FxLAZ9rKS/o7/qf Dn9DX3zPUr7d7+VhePOTOJJ0MUNeN25meqZExMjO4nD5DOafh/gfB/51HhYR/CS+iC+URUTLpkwg TJa1W8gTiAWZQoZA+J+a+A/D/qTZuZaJ2vgR0JZYAqUhGkB+HgAoKhEgCXtkK9DvfQvGRwP5zYvR mZid+8+C/n1XuEz+yBYkf45jR0QyuBJRzuya/FoCNCAARUAD6kAb6AMTwAS2wBG4AA/gAwJBKIgE cWAx4IIUkAFEIBcUgLWgGJSCrWAnqAZ1oBE0gzZwGHSBY+A0OAcugctgBNwBUjAOnoAp8ArMQBCE hcgQFVKHdCBDyByyhViQG+QDBUMRUByUCCVDQkgCFUDroFKoHKqG6qFm6FvoKHQaugANQ7egUWgS +hV6ByMwCabBWrARbAWzYE84CI6EF8HJ8DI4Hy6Ct8CVcAN8EO6ET8OX4BFYCj+BpxGAEBE6oosw ERbCRkKReCQJESGrkBKkAmlA2pAepB+5ikiRp8hbFAZFRTFQTJQLyh8VheKilqFWoTajqlEHUJ2o PtRV1ChqCvURTUZros3RzugAdCw6GZ2LLkZXoJvQHeiz6BH0OPoVBoOhY4wxjhh/TBwmFbMCsxmz G9OOOYUZxoxhprFYrDrWHOuKDcVysGJsMbYKexB7EnsFO459gyPidHC2OF9cPE6IK8RV4FpwJ3BX cBO4GbwS3hDvjA/F8/DL8WX4RnwPfgg/jp8hKBOMCa6ESEIqYS2hktBGOEu4S3hBJBL1iE7EcKKA uIZYSTxEPE8cJb4lUUhmJDYpgSQhbSHtJ50i3SK9IJPJRmQPcjxZTN5CbiafId8nv1GgKlgqBCjw FFYr1Ch0KlxReKaIVzRU9FRcrJivWKF4RHFI8akSXslIia3EUVqlVKN0VOmG0rQyVdlGOVQ5Q3mz covyBeVHFCzFiOJD4VGKKPsoZyhjVISqT2VTudR11EbqWeo4DUMzpgXQUmmltG9og7QpFYqKnUq0 Sp5KjcpxFSkdoRvRA+jp9DL6Yfp1+jtVLVVPVb7qJtU21Suqr9XmqHmo8dVK1NrVRtTeqTPUfdTT 1Lepd6nf00BpmGmEa+Rq7NE4q/F0Dm2OyxzunJI5h+fc1oQ1zTQjNFdo7tMc0JzW0tby08rSqtI6 o/VUm67toZ2qvUP7hPakDlXHTUegs0PnpM5jhgrDk5HOqGT0MaZ0NXX9dSW69bqDujN6xnpReoV6 7Xr39An6LP0k/R36vfpTBjoGIQYFBq0Gtw3xhizDFMNdhv2Gr42MjWKMNhh1GT0yVjMOMM43bjW+ a0I2cTdZZtJgcs0UY8oyTTPdbXrZDDazN0sxqzEbMofNHcwF5rvNhy3QFk4WQosGixtMEtOTmcNs ZY5a0i2DLQstuyyfWRlYxVtts+q3+mhtb51u3Wh9x4ZiE2hTaNNj86utmS3Xtsb22lzyXN+5q+d2 z31uZ27Ht9tjd9Oeah9iv8G+1/6Dg6ODyKHNYdLRwDHRsdbxBovGCmNtZp13Qjt5Oa12Oub01tnB Wex82PkXF6ZLmkuLy6N5xvP48xrnjbnquXJc612lbgy3RLe9blJ3XXeOe4P7Aw99D55Hk8eEp6ln qudBz2de1l4irw6v12xn9kr2KW/E28+7xHvQh+IT5VPtc99XzzfZt9V3ys/eb4XfKX+0f5D/Nv8b AVoB3IDmgKlAx8CVgX1BpKAFQdVBD4LNgkXBPSFwSGDI9pC78w3nC+d3hYLQgNDtoffCjMOWhX0f jgkPC68JfxhhE1EQ0b+AumDJgpYFryK9Issi70SZREmieqMVoxOim6Nfx3jHlMdIY61iV8ZeitOI E8R1x2Pjo+Ob4qcX+izcuXA8wT6hOOH6IuNFeYsuLNZYnL74+BLFJZwlRxLRiTGJLYnvOaGcBs70 0oCltUunuGzuLu4TngdvB2+S78ov508kuSaVJz1Kdk3enjyZ4p5SkfJUwBZUC56n+qfWpb5OC03b n/YpPSa9PQOXkZhxVEgRpgn7MrUz8zKHs8yzirOky5yX7Vw2JQoSNWVD2Yuyu8U02c/UgMREsl4y muOWU5PzJjc690iecp4wb2C52fJNyyfyffO/XoFawV3RW6BbsLZgdKXnyvpV0Kqlq3pX668uWj2+ xm/NgbWEtWlrfyi0LiwvfLkuZl1PkVbRmqKx9X7rW4sVikXFNza4bKjbiNoo2Di4ae6mqk0fS3gl F0utSytK32/mbr74lc1XlV992pK0ZbDMoWzPVsxW4dbr29y3HShXLs8vH9sesr1zB2NHyY6XO5fs vFBhV1G3i7BLsktaGVzZXWVQtbXqfXVK9UiNV017rWbtptrXu3m7r+zx2NNWp1VXWvdur2DvzXq/ +s4Go4aKfZh9OfseNkY39n/N+rq5SaOptOnDfuF+6YGIA33Njs3NLZotZa1wq6R18mDCwcvfeH/T 3cZsq2+nt5ceAockhx5/m/jt9cNBh3uPsI60fWf4XW0HtaOkE+pc3jnVldIl7Y7rHj4aeLS3x6Wn 43vL7/cf0z1Wc1zleNkJwomiE59O5p+cPpV16unp5NNjvUt675yJPXOtL7xv8GzQ2fPnfM+d6ffs P3ne9fyxC84Xjl5kXey65HCpc8B+oOMH+x86Bh0GO4cch7ovO13uGZ43fOKK+5XTV72vnrsWcO3S yPyR4etR12/eSLghvcm7+ehW+q3nt3Nuz9xZcxd9t+Se0r2K+5r3G340/bFd6iA9Puo9OvBgwYM7 Y9yxJz9l//R+vOgh+WHFhM5E8yPbR8cmfScvP174ePxJ1pOZp8U/K/9c+8zk2Xe/ePwyMBU7Nf5c 9PzTr5tfqL/Y/9LuZe902PT9VxmvZl6XvFF/c+At623/u5h3EzO577HvKz+Yfuj5GPTx7qeMT59+ E4/BuggAAAAEZ0FNQQAAsY58+1GTAAAAIGNIUk0AAHolAACAgwAA+f8AAIDmAAB1LgAA6l8AADqX AAAXb2nkxCsAAHO1SURBVHicYvg/CkYC+PcPSv4DgT+jYBQMa/APnOD/4QADnBlHwQgAAAHEMNAO GAW0B//+/f379x+YHOgSbxSMgoEHwIzwH1bvDnTmHAXDEwAE0GjNOpzBaG06CkYBfjDalx0FtAAA ATRasw5PMFqnjoJRQCr4ixsMdIYeBUMMAATQaM063MBonToKRgHVwWgVOwpIAgABNFqzDhMwui5p FIyCAQGj1e0owAQAATRasw5lAF7r+x9Wp/4eBaNgFAwEQK5oR+drRwEQAATQaM06NAF4yHegy5NR MApGAU6AvAJ5dOfPSAMAATRasw4x8G+0Th0Fo2DoA8hGuIEuTkYBrQBAAI3WrEMGjNapo2AUDDMA Xxg1WssOMwAQQKM16xAA8OW+A10OjIJRMApoAv5g2/MzWt0OXQAQQKM16+AG4NVJA53rR8EoGAUD AyCroga6GBoFJAOAABqtWQcfgK74/Q+pU3+NglEwCkY2gFSxv2GrokbB4AcAATRasw4uAMw5kIw0 WqeOglEwCtAAWo8WKDLaox2cACCARmvWQQPAk6kDnXNHwSgYBUMSjHZnBxUACKDRmnXgwT/waoWB zpijYBSMgiEP4Ldaja5+GlgAEECjNetAgn+wFb8DnR9HwSgYBcMKYC42HujSbmQBgAAarVkHAvyD 7qQZ6Nw3CkbBKBgpAPkIxoEuAYc/AAig0ZqVvgBap/6D9FN/joJRMApGAd0BZLHxQJeGwxkABNBo zUov8A9arY7WqaNgFIyCwQCQe7Sj87LUBQABNFqz0h78g25R/fP790BnpVEwCkbBKMACIPXrT3B3 dqBLzOEAAAJotGalDYDd7wbaS/Pnz0DnmlEwCsgEv5AYWEdafuFA+GV/4TZwFAwqMNqXJQ8ABNBo zUptAKtQ4Yf9DnTWGAWjAAX8+gEhf8ARGheOvt1/8u3Oox+v3/38+BnIAKJfX78hKfgJlIKIY6Jf 377/+v4dlyxC2ZdvWK1GR99/DHCojWAwusCYDAAQQKM1K/UAUp0Kqlb//B3oHDEKRgEMfPn66ysY ffn67dEzYE359fZDOAJVnA+eIosMQgR0JKhe//oVCX3DQCAPDnRYD2fwG+ma99GKFg8ACKDRmpUy ABkqQapTwcO/oLvegKnwxygYBbQHP799//n+488Pn7Cjj59/vHkHqpxuAdEDdDSAlSWmY26BHYld igT08+0HoK8RIQAMnB+gzPjz8xcQCQ6xgY60QQpIqmUhO3kg5yyODhqjAYAAGq1ZKQBIk6nQOhW8 RXW0Th0FtAagNPby7Y9Xb4G1Jqi7efM+GD0Yweg+HvT92asfr99+BY9sf3/y4tvDpz/evAcG4GhW JR4QrGVHK1dkABBAozUrWQCpToXWrH9B9epoRh0F1AXfX7759vDZ90fPEejxCyD69ujZlxv3CaCb hBSQgiisucm0F1wvUuz4e7gQMBiBFS0kSOEIJPjyzUDH/BAAmJUrpF8xulMWCAACaLRmJR2M1qmj gJbg59dvwEL/691HX+89BteOOCsGGEKq/zBrRBwIVlkSj6jfp8TjPEyPYPqLyOoTO7qOGwFlgc67 9/jrXRi682g0e+MBePqyI7YjCxBAozUrKQB1+BdYp4JOvv7799dotToKSAQ/wQgE3n/8cu0usDb9 9ug5vuL++r2vSCSG1H0wuvcVwkauokiqLEmd1CR1MpX4IVxcNe71+6ieBfkXM5TIRNfuYkGoakCD 8LDo+4kcj6MAbxUL6ciOnIoWIIBGa1ZSAGpX9fev3wOdkkfBUALA6vPnNyD6DuyPfrl6B3s5jg/d QyAsPS1svdWb0AFVECJQTT4kiL7hq0QfwRCa4EPY4ik4wusMbJ1awuO9KLXjPdSwIjWQUREwmtAQ NmXfn7/6+f07OHK/DXQqGxQATxU7Qu7hAQig0ZqVOIBap0Kup/k+CkYBEeDn5y8/P3/98ebd56t3 8KMvUPIuhAQj1KIca4cVPLwJJHF2RnH2MmHV4R2S0ONvMPa3u4/xo6/gTavoJmCpg1E7uMgux+jm ItoKcI/jGd1FrSM/g0MVKZAJxAgKunL78xUICUd3MNDtHx8/gxYhf/r8c6ATHnmADvXrL/BtdxAw XCdlAQJotGbFCzCGf8Fd1dE6dRRgBz+A6O17NPT52l14WfwFtSCGcEGF/hU8fSNQ9QAd+bwBR2hD vmj1KGT7CqLWRBzOgKj2wOx7j6EkAfQEge4/xYuewEgklVC9MNPQ3ABBaHXwbSSEtcsL9++NB+BA eAALDVhFewM6XAzpvH69hl7LwhE0Iq4iYgS5psSJLt/6fPk2ErqFhEAiQI//eP8RmgzevAfWuAOd PCkFtOjC/kTaIzvQxT01AUAAds5gBUAQBsPv/3qdO1iWSafosIQKSrTa3IQOXQJ/vlNQSYJfrlEx ayZi9++2F62WiHHTDHqAztIVNll8T7N6uaaIlUbcUIPalNhOlNRpgUuUSPFC9YFFGU/zgpa2KOdx rU0PhtPDdVQEjQH5GI+WShdqzX/hRKvNj3Hl5qbc99T7+bOpSaaPGTRDJXDeCMwY6azzr2F/zedy DRvZFeXvFeNDAPbOYAVAEAbD7/94dYsOdbDIzpVCHXLTlVOLDkEFjZ8oKCGMfey34U/WVPAuVcvU ZXarqk9/1X+8KPQ0DSab1wIK07xA8ZQap+atHiIHGJN7wuwN61ELDwMSbq56EHUcVZVAXAG0GDiB c23QwAMSm6Qv7V82UqPwpAe1FwR34oNunI51ucRgZvRt6Ojoq1AJ+oZus+ct76Ut/XJ86hiT8UuK py+mJqC0OFSW1lDWo3nf78eNfA02lP303gCrAOyaTQuDMAyG//+/282hsMtg3eh21h0mM99Jq+wk TjC8Fw8tFEue5k0OslZR2b/jB7C69QU+4r9iyuCchSFRtkGacH3NqsZvqFB5HEnMXodSbotKZ5SK NiFoL8ZsT/hUiAJHiZoIToYZQ3GooPhOGfUMui/oUXy+fotW6ULcf0gZdMuOvoHBRnRmcGJ5ABt9 8fgk8pyt2L0aaLu5KWUErY0Tq2PsjOKKr7EqLX79AkdZp3MpaPeKpsdZc9nvy30NuO6Xr18B2DmX FQZhIIr+/9910ZKULkJBSjFVQSw+kFLnTmIytkVaKNk4XFyIr5DB4x2HbGSN4q1VHcfUGbtFyuhY zb3eaanpRXmsIQFUz9QmlH9PEVBBU8X21JDceghRd+7MUaC0BUdh12TxVvrOLrt2tAU7L7YnboGa gYWSeTlkS69qsFUPDZHcnptX8ZP4XHc13C4v3QPkMYYLQW5Qn8fSOwzbQOKMGUyjDvb3jA+LmbuE W9hc44k7t18tmpa5N0obNykKczTN1EH+lN2/FIQDYikNap8SXvqD1JrosLasUqf/1/EPuPIyio8o UqNiPZ4CsHMGLQjDMBT+/7/Ok4jiYYqKDpmt01r0YpI27XPWHQRFcOVRehhbt4V9e0m3gazauj9/ iBlgihU3tP9rF8c09Wd3mi/wmdjmgViQZEcemDoDmmqmNyR7pWIK38BwiVTLostYFsXlP1WGqKd+ tY1ECfYu+8597HdgJWtmWIYic9GILOlGal7ocCzIkFoVjkW2JNwg7EQPcQ29zkQnZnC2wOCmZIiz CeZzp+uwqZPlDdDt5JldtYbVVZhPlusfl0rl739ijTali8cqLsHKC5Pc6ye+TkNs9JIVNJr0y9uW 4pCjUUSR+amY/yJf34ArFmJ/H7F3Adg7exaEYSAM//8/p+DQguIgpSgO1pgYwTp4X0kuIXSRYoce LyVTy6VpHu5NQ1ayUtRWVflnpZkG8RqLDWTq3frzFec1mfuCtI9XAjW4hWkLDdP06HKPF1F6yKxd hii6mgxRtD2pAJUaVMpQdFAvIFV9Us33BnxyiUnsHFEBnALFGgIfDmXg+oz6WNRIim3V8D+IbiIP cklVDBck5nRiXgWGMfdbqn2p8BXDmT3naDVDZ3ahY7voKveBuL22kek1nTLfWIOWNu3Iiqw2inf7 bG01935hCNntJFM3DaklNTW1HhIx9jUYuM7+LfyPr9Nk5eDzdpZ55M5XAPbOrgVBGArD///HRQgF iRdBgmGCSeQcskXb2c6HaXmVCDXei12IbjD3+J6duZ8n6wtT7cPiMTXfHrX/srbiZit1rlRR4tQG 2g7I6pWknKxEi6nRpBJNcdE0pO/GtKOc83WPmFsEKUUMUYp5UiA32NBL3XNUtukDZsYW07lJoqYj peCluauotjOtAnUW5CtKG6XtZ3Uj6TnRlXgTeDopNoPbRiBnBr+BcQOdpY7XEb0D41td0e/G5V73 XUKhck0eNwfingRrw04hsSuXDwviZKgQMcZtxyFQvMuEhU1viR8tAqVCcoxNcnSz58qkkoP/rXRR OiO70AuyIFxnbassK+TrUwD2zq0FQSCIwv//v9WDQhE9BGliECErq+ZiEXPZ2VGLgkKEWg6+CN5Y +DyzZ/SHydr/nSpZ1RsGgKeZpv8xh9HUtd0dqiSv0mMZb81yTUKmkpRhjTY+/au6aCSOxB8u8Ium VOblvhcfMqJ4UUKJXELpCSEqHD07gChK6rdYPgUVhtkJIsdpO1IPn4yua+01hGIbdHFvqX0lN5Le qw+lzw4aARuvuaOtJrFVDBYM4+2z/zZWoOuKMjw3KTgDbvHZEnHDsi4aXLS2nF6m3iEEbQOgzbgl l+rGaGctt/eojLFejo05SAyvYhFMnj5ceXYZxKpMPNTqqRYPBCGsNK/22ZQ1tm/x9ZOa8MC/0phJ ifguAHtns4IwDATh938/KwpWvYgXQWkUxaTBZvYniSnRUxU0zKGX9lDafMzubPurZC0GVb1zN0zU TPZo/tdn13mzM4u1aVranuAD5kFkFGTjSwq/4lN1YEbnZDiCtJWmKZJHmjmiQZfElXJPVOK1wtFT 5OgxgIHbmVQp7YzgE8VVoKV/yc4nKJbwC7LvyFvXW+chPcjkCqWnjFyzCuMaiRXGV8VwkHrfWHwG dAfcym28E3EJusxaEkrKmmfeHyS3jKBympBCMIodLVJml1g01k8ttiYd4IkjOlolXmZ8jT6VNUrQ XLNSIV3crAYXO+V7ND1c62T9kr+yPwRg51xWEIaBKPr/3ybF7oI7u5BuRLCtU1AipvPK0yKCcaFh Fl21mzand+7c/B5ZS+c/3HEAuObr+F9fW8eT24OGdqebFO5lZmjE39qasTU0qcSJGoqlUmxGaMra FN24pTROuj8ATahiTtSjFLXRVSWpNHWJo+yGnpmgtwSiFxB+aGM2U5wpPj0R1+Dny9Yoa7OHPoVx icclDCcAjjrYRFwIiAtEXNG48uMS4pY7ybGu7UO/FhVt10MnHq1OQmmUViI9S2G7mE900kRsZMSq z4rVKGJfAOomK/ePiDd01/M4VfikPgfX92RryFda9YXsQwD2zpgHQRiIwv//rxk3jIOLm4uLNCbV hFbpu+v1rkJjTIRByVtYCGkKX97dPfhdsqICnJ72ALe6wP77H+sevnf6BeS20rIqTC2JGppO6viT hNc9M5Vap9qb0hwv5z2QIlXG9GxndKW0q1DajyhNDVGCaJiD6A2qC7A1PoOQiUAVCGYKbPN6fK4o iko4ra/cvgfL4BfuDkOc8s0FvWZ98qKJzW0Ql3vSuZicKCugvdxlUDk7WsSBEmg5bkuzx8eTjfdk yspvA+ApdUbWoVZcjwobvmKLjnt1EqKiTdeQ2x08Gh/+mw3ZJeH6JllX5OtTAPbO7wVBGIjj//+f llFQhD0V9NiPh0xnaCre7W63eSUliCA0Dh98UXDzs+/dd5sm67zWDA1rIlXrRsZtXX4vrJp/m2d7 GpMb+JsYZOoqTqIdxtLO/blwFSeU+HXWpMfG+ZLsfuuoNvYHu9m9W2+KpVPa50hoymneQrQpuXav hNKgPnpPK+BoklXkKsoMilGyEf0GUUbmq+7K0BBFISk12Bq+MvYCHOLN9x09Rw/13C6J9as2jtm9 DA5hrKS5zDM0cQsbZUBcJ3PZz5Xjd0ntXAe+FGWSMYfs67UM2oukjq0lKswbA2VPXst6AxQdnIdn 4R3lxAVverLdjxfCguKEWHcrryRboQNTT456sLrYfo4IIz/fQMiqkTIlX4fCdUSyElynQVsrADvn 04MgDEPx7//R8IhHEhPksJgILDiEaEC3tX1u4p+DogddGkJCwoWsP95e258hKzN1GCOsHqZY/QoD /uuNy23vbd3V2mS5WSsrFzTSEOUm8VOBVVGo1Icqc/CtzuBBSL6sd1Wwb5qrvlDUNOmGGJBjSlMX ULgrKD1qKS8yLTujxFG4ob3k+liGDtCd4Ogd3Qn8BEwShs0Py9PTRPHiy68ZHClsuZnQNzyCjokL 3I4+AmcXAleKme2Xsp/MgLUArWdtBZs2AK0S0HKHj3L/Xs6a5WkVrfNluXHWYDYFlz5lJiwt9mfF FyOWCuvIgmWguqtOLEqXejGJJLWPfKRhEGX3m7Irq67ZPdhEn4frTLJ1uLXmZtxZAPbOpwVhGIbi 3/+b6UVwehBBEBE3ZCAILaLin/SlSWynsENVxNDDdttgy4+X5jWvyPoLcMUrKFb1Tzsaa8078/4/ isadqW5Vc7qhjGMqZij/MlBn3J0kQJ1Kf2+0yuD0BuOQOXClF9bSloUpzDAQpjs07gpNE0kKp4qR pMjvtn57Oqcbk10CTgh67UXQL4/kUXuq4Zy4l07JmxBX9ncTdcugfbAMmSYpF3ujAmtZ0YKyEbTB 4cOG2gBaHJ6l838WcagA9Rgv1SyLeQATOomCvk8xwo5Ixer+q5aCaUWOZjQdjGnJhdwOq30193Xr N1u3brx7mgZL8PWDsjXnawnY3QRg74xWEASCKPr/fyb0lCDoiwlFgYoVRgUh1M7cmZ1VDF8Ukpb9 g9U9O3fv3F01Wf2xt/MK8AsK8JLb/X8sMB7Nuc12101yiT6ncpLFsPUkylQxKKXwJfHLbpzci1wk ukDVNEGmKWf6HEsovWzlpRtTzWHQvpcOll3LUeMwsqJuD6UDiNpKdA3gnGNMqnqHBe4IbsN1CViL dQxZy6CV5h/vh2oEtJUPkHqeTAftgdpn4TRGFJTUsvJED2UruntZzaBw6YmpeondV83isNGEcaaM YpnbidMV0Pn+lhX3sv7yl/0oXMfIOh9f3wKwcy4rCMNAFP3/L1Pwga+KLtxJKW5KIjhWBM3kziQp VOOiC5WGWXVb2sPkPjJk/W24JrdJ4oZwX0tzG7D6Z4fsmbWo6daM+bcCrFr2KG3Uo6SdD8udXe0l ilpoQRJbfFEueNQipEp6BCVsqlVHKDnyeRhWTK0qpkhbXuhObsIdr26lsNu89uI+ovD5GUeHkz35 HTeu/kF7bjuZu81TLdZS4143T8jdyjoL0EqXRRKlrXFpfEVLVHkixGeRnUWe56C7LHRZ5GXR+iSm Jy/HomsCnvZZ4m8SqdWP8tV0Una0iJM8N5O1mRdUmzdfXC9w/U6y9kW9pwDsnU0LgkAURf//L+sD WhjYyp2bqBYqqGFlzZ33NeIIQSQUDrNw52o4vue5bwZkHb/gh/kqWDXJcMHqfy2c27r23+xpuSZH gyQO+aW6S01QShSo6PpaZgYVas46EqVOaaI9NXtP7PRixA9GNFTiHzWM0kZR2oU0jaH0Lhy1Rm6/ cHTO9UZ12wdF7fMxDdpbrKhl0LYGWjGhUMsiWyUa1KXoqGnspx9fEZ89g7L5cZCadZTNfJLHUZau wDsE0hNfAIAq1rtOqjhRf1hsJpDVcRS7XPED7zFidW/3xSbR0M7UAZwNrt9rCEfJ+jn4XgKwdwYr CAMxEP3/b/PYk3j1VEREmgUPC81kkm7AKkVa9dDQT+ju29lMZheRtf5iHujzSt6H7AGuD3RWv7z7 77V6FV3RuuBF7t3JdodwauD6t7MhP5p+KVKPHkDobVSm4TtQ+QY4pib4RAyGZC6RI6g0bUYkAJUJ R1IMqCmKIYTp08zoJElbz49qaefoH9Xb3m1sI8kgNgfaOhmjMmUtMNKPX1KanA2/Mf6uK3Ke8b/1 lLMxOHvu/RUjT1uM+Cd7KkDC9BQXxRgSo4p1L7FNvt4OtDLZx6OnLpZG1ozSF3w1Oasgh8F+GGYR uwVcF8rWtci6BVxHAdg7gxUGgRiI/v+Pee5RKBQKHjxVtKwKVXCTSTS77kFUaCku/oHoMzOTcStZ x29XWmw9KvVExurnwupfnLZ+U0Bp+eJmsQuWKmofxEzNEbCU9kHZQ32SlcV1g5hQezQ58KqMf7XR Cw6x3qoZFpo66bZ1DFTjmIaxo1DjtQmjJD4vlP7mSd6jYK6FdK/TbQTaOYEcjrODBS0Kk81ujxQg v1Q0xu99uKGCrFlZ5ikl/QRH9g6t+OEIsdxXjCbFW66ItSPsnBZWTdg/Pplea6xmacq6ovRTbFc3 Uaj4CFxPF4RPJ+s+vk4CsHc2LQjDMBj2//+wDnTCHJ5k4EUEJ65+sMHc7FzTdE3K9KJMB8u9p9I+ TfLm7awhS95gdRxpK1cJosK+vLe78isSTPGtKLJzvj9Ypsb4Bp/HOk9dwCj9Uit+rQ3hBrS+zilJ j81sd+A1yIBapihHMvVeLPZ6NCW5KRkq9Wq8qiEdu5fJ6P8foiloKHY/9lJW+ZR9+O8tClo721O7 /wk4ZeWtyq5V5wZlKQu2xiAwho4sqIthUhb9nuD/dm1ZnHQGT8Z04uKExChxYuKmYCWDSIoIT5Yg cBV9iDW92HBdHE+UrwOkrQO3Wj9E7FMA9s5lhUEghqL9/w9z0Y3WTdGFCMV2JYKmPmiFziSZjOOj i1KGUgzzCcHDzU2uB2md94L11+G67HVjrA7997EKe3mstqwgL/S3gMZWYqnyIY0WqU14xrj8FCSA UDGVgJphFL4A9UoKtXQNVHg0gEBlmj7nNJU33ebltaPNAe9e/1pb0+PRGf67B7W2iyZylnMZWc7i SY9qRQ5fNL/xQV+W0hYx0xjPeEzwEy096fhivd8rf5MlFXtKbK6TvYVF3+RIEpbmw3GlEBtE8uZM DVb4WsfJ/XLrwOZO+JetHqzWz/j6EoC9s0cBEIah8P0v1hM41cVBQXCSquBSNE9TI61F8W/QnKCD 5TPJe68gq42Jl/wTPPDdHi4rHOXXLVbfZsrXq6uNSVKyw6uFqeR2h0YJTSqASn3q5J/BJhVTX+QO Fu6BNgQNAqiVBKoBUOWwV2p6YzQNK4/++mrZDQWy+NcPU3YFWs6EmofGRNl15iKWsv2E2BJm2dw1 suSRbdm9gwwKNu2Mt8PlTvAWVgiJeUo8t60eYlWUr4ludObssLfC9cxA+KqedSdZBwHYO5sVgIAo jHr/B2MlSWGpbMjGaJqkFPdnfjJENixmnoHOfHe+zo3sR/CMrL+Dq3Nh9PpKL9Pq10AJRyopofGY lmOc7f+zSHJd/UXfLzt+K2r86pCK22bQ7UD72uYWjYPdsPRw3wegOhtMuZGkHKAiTVePpkaNG7Jp OPfnErFWj+X5oS7irEPZE8TuQZZ3Bgz0HEsyCtWwhkI7KEzdyay040HxZHVOBeVXQVNigChMhg1c T1Lsga95jXwFwH4eW/+QWTcBxABfYUF8zTqIKlecy4B/kdFbHejaZBSAAKjZ++XLe8iUD3KdCt1I AzuPELZ/5sv1+5ADCMEXt0EqVNCoL/jG07eQChV6nwyoQoUc2Psdsb4XfDnMP3gP9Q9mhTraPR0F 5ALsa6BQl4ujnVMBSYeQkxd/IQ6p+AO/NB7YkYVVsdDTjJGq2J/w6diHzyG33UFPLb4JPkYRfFU7 ZLkT9KBsjCr240nYLCxk8gW5ij2KYzkx7FwnUFf47FWgId/efQBVmN+wXCBGfOVK9QFhKnZbCcY8 QAD2zp6FQSAGw/3/v6xDpwOX0q3gbDHniUNpkvcSQ3ERhBa8DE4ODsk95uu9i/+G7yLrX/DVPzvI FoovzvuKwL9GSbNqmfI0jq90rwUojP5ynAOrzFSspSZjqnZSp8ezSCe1h5YvhHwlSRWgDiqFr5eE r3oOnqEqU3GKGVDDkdfS02ZH2nvTndYGbZBfjZRdvihrTVmyWrHu8ChiB6zJsvPLaF7vE0+yHWsy T3b3DgSeHLFQJ+YQu3W2C5s2Zon96dy9hr1YwLVK/yNmu0JUKM8nIyu/8BGAvfNpQRAIovj3/2AF USB0C1w6LJ5XU1PCIHZm3u6oKCSBQg6exdvPN3/eA1mnXzvzKd2KAe66iR32lQSr3zWB1wbKv5cX qS5/Fo/KWHdI3BF/wczUC9weyDRfTmhudxKpyoAw8zkzHqj+csbBwpeAymNUNUONCjW0fONa73vI 0Z2me/26pigL/xAYsuqO8Uu0bBSyjFgYP0nAu6TM0gkZR/FIDo9CbGrrlCIBpFFsODW2t+sEx/8i nutcoVMVX8fPSXm2nCVEtja2LatmFq6LR63bJOtHAPbOZgVAEAjCvf9zdYwuPUJEdOiHKKpToTur q0XUJQmcowfx9rHqzCQcrna97/1R6KwB4Oo+YFisLi+m1dBAiYLmqunTnJjag6kF6t7wR0mlPeiG VNXmhtQkGFIb7kBtN4rF7/SQOk72DXVBmYwDVGE83c8+maio73Xl6vGNsxKxphRv3fy7YoFY0cND GRSILNbRE4xY9aOYWmO5L9YU7EjEsoPcmWKxaIP+B0rtNpNrhjKMuaxXfUv8HK7/JeshgBgQ1yOT VbNCnEufhAd3NaJaRTq2cLRaHVrg25t3X+4++nLv8fsj598fBc/igLPoR3A/9dM5eJ0KOeD3Hmh1 0p1H38GHPPx4BD6D8AX4yCTw8Q4oFSp0EyriVhn0ChV+dt1ohToKBiv4h30/D5Yq9h/STtk/SB3Z 359AHdlf0CoWfK0schX7GLWKvf3oK3TTDnhT7OXbn5B37EAnYq/CBoovIx1EfAm+xRxeuSL6rKdh letZ6K0Y34Bd51dvaT0gPOA1K0AA9s5dByAYCqD+/7ckRpEYJGJgsQg1CQPR+6Klk4hH0vsLHU7v ua8AXog82FWyPuqExQBzM7D0K3ms/iuGTqkwplS1j9AAm0yNN6YWMAKfl3x/hsRvjUylC24ttSYd rC+LX0lSN+W7OHyvZ6qPj4crl11m17CstYxiPLtiKMdqxDb7JsUJEYuiGFZPQC02rxixVIjViNV8 TbJ9YkcmYs2br9hXnFqrRmnbqAhh494UfJqdcL1RCL9O1lUA9s4eBUAYhsL3v5yC6CC4CQ4ODi2U 4g9o0qQJcXMQlIbe4WuSl/eYrPvznvU9uMpiVR+trkeIBatfqeB8+tgmpuJKNU2NwPPB15jv1mqm jrJMnWby9cXBr21SLVA3FiUp39dC01LfrZvGmB00lfeTPt0BxEaNWFE8LRaxcLRDBoqgdQpooEiL WJQTuxzGXtmjWOJojtnBsFjJxsjxGNy2AqSbHnwtrtcNkYfDfyLrKYAYEM15EmtWTHfTtnLFGASG 9VZ//AJfYD5asw5+AKxWQf1UIILUqcfBF6mehp2jdPHmF/BpD1/BG2mgdeqj56AL3Z6/At80/g40 mQq5EhVWp/5FvrXtF2znDOo+1NEe6igYPgD7Nh6MDTwYA8XoVewnjCoWstwJVsVCLtuBHKAIOdoJ du7ELYyjE2G1LHzrDvQYCsQFySg1K+wGKvC5aeCVidfv/vz+/Sf1plqx1qz4K1eSalb8lR1QFiAA e2ewgyAQA1H+/9eExEQJF8NNTnoR2OphE3c63QjIEQgh239oXqfdncn0y8EyZCVcV+Hr8CVwHM2I Vd+7t0jC6s7LwVDpBZ0KqQqmQqqeruy00GBqnR+YWjsE0dA+qQFTYfWgaW5P/UJDl3wNnPFuXqRG K9cpU9ed/FKl2r7mF8V+vCv+XxR//ETF8hb7+AXbAbF2iL0LnxPTd6KqW0jYW2cSlhk7GrBTlBYW W5QxIUO90vIBWYlVI2vVnqPR98U2VRL6XY5A1q8AonLNCvEVlYswbNXqP0hv9fsPYDQQ2WEd6Mpl 5IJvn78AMxWwqwrfqAqeUr0CqlMv3PwCPuwX3E99CBqGevAUtMbhMaxOBU+mQrbQYK9Tf/1GPtvh H+a6pNEKdRQMewDfIYa66An7qYrwWvY70jGK4JOKQcud3n78Ca1iEcuJoV3Ye0+Qjk4EH1AMuQAA dLTTDcRyJ3DdCb3P7iz4tgxo5XoNKgu5MhmM0GpW8La6uz+AtpOyiIkqy4OpW7MCBGDv7FIYhIEg fP/DiYja2gSxT1YsPjQgKiI0+5MEUSlIKIVmjiDIF3ZnZwxZD3SOrFqLL8OwZeoGq9Po7o8DVn9T 8N3rVqWCQgqBqTD+zXilSgH6+hcV9549SliVSoc0T1ymaqYqzMrn2S88ujfWpD2gBgX9rT76iud1 9w73ARhHMR3tWMQ2HS1isQPgMVQudALSWgpEbC6xLPbmHMXx9YWV7EzT6MINjxxNimRNzEAYSpQl wxWC1cqx7abv2oP9kvUtAHtnswIgCATh939CIzA6dAmKIMvEU+6O2w/kJbpIDp47ePmY1p1hsqY/ +pqs3zjXhwWbPLBqfi+6hbablabfvxSKdmcqVlSVXmrOfEBhqjD18kDJSN/4Frdo/AWo0t12Y2pR URGUnsg+I3Zz4mLtsRcbnxMHxHLuBAcUc3TikeuEJruAWLjYcxYrTTvwpoh5olPFE8lKc1Z4VgPP ymRdqsb1oxumgFi/2uzIugvA3tmkAAgCUfj+t4sWgSWRtallUUq1iXmjUdkiiKjAwRsIfs7few+S 9S5fz7E6090PhteN3yXr2/D6cMiyjYUt/zqmWtkH/p8mEtqExFStXO13zVMhms9M9Zqpez/UkKSG CHEljnzdDBXP3kSxGfmZpbNtxLK0Uw0PAJJObEzFHjvY2JGlTm0vtk9yYDKz6k6wAYAtlQMt6sBd JAjAqCcfycpSa6KAKriatPkXWRcBxAA9NJX0kyKIrFmBfiancsVbrf4YuA7rQFdZQwHcfvgBWKce Of/h2MWP4GVKoMULoOMJb3y+AqxToRe9gQ7Qh9epL95A51OJrVNHB35HwSggHeDYt4NnuRPSuRPI BxSDj06EbNeBTMQ+ev4NsmMH2FYGDRRDrtmB9WKvQMaKIZXoTch6YBj7FmQoGHSh7BV4zXoPVLMC C4qbkPs2HgJNBo1FP3r+C1itDoWaFSCAgDXrL/CWVuyaqVKzkly5Is+tgo+DALkQVK0CoxmlWqVz zTrQVdZgB18ev3h/+Bx49S/42DPwMiXQRAuwTgVmnquwy1PBy5S+P0Jao/Tuw2/Qut/PkDVKkDr1 H2qdinw3yGidOgpGAUUAvX79h31fLPKm2K+wy+w+fvkFuWYHfFks7D52UC/2O/Sm2GfQQydAl7GD 52JBNSWoioWc7gRFV27D2V8gNSuoz3oXdikkpM8Kq1nvgG9cBlbb95/8eP568NesAAHEACq/aDka DPc2sZUr8kpg5GoVNM3+/RdqtUqwZh2tU+kGvoCO/z377sg50Nm/sMP0wcO/tz6DlynBl/6Czvt9 Ctmf+vbX2/fgS8hR6tS/WOvU0eW+o2AUUBX8w7FpB2kiFuP0ROQuLOSyWMg1dm/AVSxkIvbpK9Ao 8UPouU6Qa+y+Qe7YAXdGoVtjIWO/yAh8KgXoeHBEzQqqVmE1K+jAcFDnFXT78rOfwHLj50/kKmZQ 1awAAUSnmpXYnivW3uovaG/195dvP+hYs34GL8MZ6AprCICv7z58efbq/VHQ+Q/vT4C7qqfBl5Nf vAmrUx+A6tT74H7qU8j+VNQ6FTL2+/0H2kYa2PFJo9tSR8EooBVAZCjMfbGoo8TQOwBQr9mBVrHv P/9+B+nFgi4A+PH8zXdg6/npyx+QLizo0AnwRCxouRNooBh6gCJk0RN0YvUujH0PtAfvBmKSFanP iqhZQfvdHz//BbSaSjUrqZUr/iAFCCC61qwEKlfM3ioQgS+Gw1Wt0q5mHejaasiAr6/egE4APgo/ +xd6kSps+PfBV+ixD8/BdSrovF9g8xa5ToXupUHvp6Iu+h0Fo2AU0A2g79hB3H2CdM0O7LJYyCjx l6/wO3Z+gydiIaf/g9cSQ25ifwYarwJPxH6Frih++PUWeLwXsnUHNLEKQuCdPCDxL6AKGFyzgqtk RM16H1GzAk3+9enzIKxZAQKIAXwTyB+61aw4K1fUDViwavU3MPLA1Sr69CodOqyjgCD4+uI1+FR9 8AJg0PDvtY+gQwrBw7+QZUrQ7TQvkLbTfECvU9H20ozWqaNgFAwGgGutE8o1O9DLYv98g23XAWZt 0NHEn36jn5v4CrwjFjIRCzp0AjwXC+vF3gJ3TyFVKZx9C7wSCtRnfQQ6lw2tz/oQWrMCjQXN+wJt /PZj8NSsAAEEq1mxGYrfEWTXrNjrV+RqFXLlKrhaBc2cf/kGbBBhVqujHdaBBaBqFdJVPXn5w2l4 VxV88C/k5Adg0xKY9MFLf3+9fod8hv5fzDMf4Je7jU6mjoJRMHgAoe2wSGudfkHvsPsGvmAHOkoM OTfxA+wCO8hELLwX+wzci30MGSuGzMhCqlLQCDC8twrpsEJXMD2FjQaDlgpDalaQgZBte2/e//n5 azDUrAABNAA1K3xDEsJxmNXqb6Rq9fNX5N2rtK5ZB7rCGgLg6/sPoFvKwVdHwVYq3UB0VYFZAnwz OfhacsjVNB9gRykhznzANvY7uuh3FIyCQQmwnzgBq18hJTZ8Ryxy/Qrtwn7+BVvoBO7Cvv0B3a4D Xk78ENyLhezYgdSy4OFiMANep4KrVXDN+g1esz5GrVmfvwbv33sHbMf/GeiaFSAAe2evAiAMA+H3 fy9fwkU66NBJpRUVQWwukQZ08WfokNAHcJGPa3p3IOuH2vPXZOWRT8xkxZ0DW1eXlTfkXDBkZC1h YoiE1UqkKupU8VKJpGoz1Y7+BEfOM5GqvFKVyF/J+91VI42u6TCm2tgUPTd2WN7FqtSBLXdmozEl nTNuYgzIJR7YrqNCnfwMR6zc8RJlO+GoPqxWndKsiazthaweDySJrz0tnp7A9UeyHgJogGtWaOcV 4gBotYrYugqMj58/ftCzZh3ommtQg68fP4G6qkcvoHRVL90CrZ6HdFXvP8HVVUVsp0E67xdarY4O /46CUTC0AMZenf9o22HBy52gq5wg5ybC72CHjxK/hS90Am+HBY8SQ3fEQmrZB1AErlOfwarVZ/Ch 4O+QDiuoZn3149lrzJoV1LIHtul/D0DNChCAvTNJARCGoej9z+YVBKEi3QmCEyLUDE2TbkUUIaHb rkp5/Aw/35OV4XrKY1B5lZIJ83pQP/A9srpgfTYAqyBSs1RtaBsUeipRVRWkahu2bpDl5NL9i84P deuvjtPUTE3Jserh8b8on9f0Eitcma/Wl5hndZCvi63C8qwOclEQy4nivY8CWlG0IeopZIUrVrOi T2omK/J7nFCnvUvWSwANfM0Kv4cPKPUXPBP+Bzy9+usrolqlT8060JXXIAXAOvXLk+cfz1+HdlXP gs9/uHwTfN8T+OxfSFf16UvoSqW3H9BOfsCYUh3tpI6CUTC8AOqkHspCJ2BlhqhffyEOJQatofkC 3quDdKIToooF3xEL2RT75AVoxRMUgStUMBupwwrus754A++zotWsv99/BDXxwdUWfWpWgAAaRDUr 5MIgoDRodxT4FEP81Sp1a9aBrr8GKfj6+TOwNgXdWA49ARi8APjSLWhX9e7j7w+egduMryGXk6Ou VEIa/sVc+jsKRsEoGH4AcyExUi8WVL9CNupAZmG/QetX8EJi+Ln/sBOdXsKXE7/+CT7aCVTLgruz 0LnVp/BqFdxhfY5as75BqVmBhoOqc2DXmS41K0AADa6aFVq/gu6IQ1Sr9JlkHegqbDCCr5+/AKtV 6L2qp698Au1Vvfn5yu2vN2BdVdD5D/CuKvTwh79oK5UQpymNVqujYBSMDIC2KBW1fgUPEf+Cnln7 HXRsLaQLC61fP3z6DenCQhY6vYL1Yl+8Bm2Lf/YaUpWCalNEnQqbZH0BroyBWrDVrKBdfx/Byz6A tTuNa1aAACKzZsVarRJTs2JOsmLWrN8xAK1r1oGuwgYjAPVWT1wCVasnQb1VyAVwXyCLle48gnZV nyO6qn/gXdUfaF3Vv6Nn6I+CUTDiAOoqp39//yHq179/4atqgPXrP+R76yAbdSDHOX2Ad2EhE7GQ Xuwb6FgxhHwOGwSGz7C+evsLXrNCqud34GoVWrN+hm5VAPYBfqOPDFOxZgUIIHDN+me0Zh0FKABa rULvq7kKPQICcqo+ZK8qpKuKWKn09Q/G4Q+ju1RHwSgYBVh2wSJ6sX8Qh/7DVhH/+fb975dvsL2w nyEnJiJGieG9WMjRE8gIIvjqHXxhMKhKRu+zgmvWT9DKFWgLcj1HxZoVIIDwnW44WrOOTACqVs9e gxwCDB8BRuyrgexVffkWeVYVfVMNtKs6ulJpFIyCUQAG6Lt0/iJ6sb/hG0PAS5wgh/5/Q2zUQTnO CamKha14egclQV3V9+jV6tuPiD7rRyw1K3if/fd/1K5ZAQKI3vOsozXrIAdfP33+eOEG0gjwrS9X 7yAvVvr5HG0BMOp5+tDLyWFd1f+j22lGwSgYBWCAukUH9aB4xBQsZIgY1oX9Ca1fQbOw4OMmIIf+ w3uxkLFiyJQqAn2ASkE6rJCa9QOsz/oJrWaFLreEDlNTqWYFCCAy+6yDvGYdrVbJA+Bq9ebHU5c/ wQ8BRowAP0eMAKN2VVHP/h0d/h0Fo2AUEAIE69ffSPfCfocc94/ahQVPxIKv1vkI68vC6loIAyaO mGQFr2D6Da9WP39D1KzfvkNvsfyD834aIqtVsOf+AQQQvc8NHq1ZByf4AoR3Hn66ehe8BvjaZ+jV qtA1wKAjICCLlcDHKsG6qqCE+Bdy/gPsLtXROnUUjIJRQCxArlmhtc4/2BInyL3rf6A31sGOI4Zs 1EFUsfAL2CG17HvwumJohYpcrSImWX8jd1jBo8GImhV+pDnFNStAAI3WrKM1K+iC90+QEeAzsBFg 1O2qP5+/hl9Wg1ytIu9VHT34dxSMglFAMkDrucLr17/w+hXtICfYRtiv4EvrYCcm/vkI78jCKtoP SHUqtFrFmGTFVrMSU7kS8tM/gAAarVlHes0KDIGPF258xLMGGHJaIWQE+DNssRLq7W+j1eooGAWj gCKApXLFUr+CZ2GhVSzsUljYKDGoF/sVuikWUo8iKlRobxV9khVHzQpeSIXv5nJCXvkHEECjNeuI rllBvdWLNz+eRJ1Yvf0IdGP54xc/kU5Wgh4BgdhX82d0BHgUjIJRQGWAVL8ibYRF2gILWeIEr1+R jyP+ijxQ/BVSicJrUygDOsMKq1Yxa9bviJoVujATW+VIyBP/AAJotGYduZXrl89fYBOr16ETqzfv f4OdAgHahQ1ZA/wR9wjw6DU1o2AUjALqAqyLm6C7YGEHOcHqV6TrdMAbdb4h1a/wjiwmQlSrsOVL 337grFmxVa6EfPAPIIAY8KyGGq1ZhzH4CqxWryGqVcTWGuRTIGAnK6Heqwq7lHH0mppRMApGAe0A tvoVfNwEUv0KuR7tF2yVE6wLi17FYkVfkTqsaDXrT9Sa9TcY/SWhZgUIoOG5n3W0ZsUPUHqrkPVK oIlV9FMgoPfVQLqqv5AvqxmdVR0Fo2AU0AWgDg7DD5pArV9/I4aIURY6wdc6IaNvKNxvyDXrT3w1 K6QiJ65mBQgg+GjwaM06UgDQv5+u3EIcBAFdrwSpVsETq+8+4FoDjHKw/igYBaNgFNAHoPRf/6PU r8hTsJAuLLx+RaliwbUssBIFd1L/fEOqU9GqVfw1658/iGNwcDr2H0AAUXOeFbNaHRI160DXdHQF oGr1MqxaBa9X+gY5s/DxC8jhSuBzgL/8+fIVMQI8ul11FIyCUTDgALnk+fcfW/2KMgWLvYqFoG8/ ENXtd6RxYNRJVpw16x9wNwN3MQisPQECaLRmHUE1K9CzHy/ehO+u+Xr9PrBa/f7gKaRa/QnesQqa WP2KZWJ19L6aUTAKRsHgAv9QjvtH26KDOOv/5y+MKha5ov2J0ltF7rCi1Kx/0GpWcOWKw13//gEE EG1r1l8YYLRmHUhw494n+KbVG5BlwE+hB0G8eQ86CAJSraLeWD7aWx0Fo2AUDF4AHx9GvhEW7SBi rFUsdvSL+JoVPCyM1UX/AAIIVrNiWx48WrMOJ/D18+dPV25/Au+u+QrfXYO5DBh1vdLoIcCjYBSM gsEO/qFOxP7FVr9CRnTRqlhoRfsLuUKFjQP/glfJeGpW6EnpaM759w8ggGA1K7YtO6M167ABXz99 /nz1LqRahfZW4btr3qIfBYx8u+potToKRsEoGBoAy0ZYeP2KvsoJZS0xBsKoVgnVrH//IXdegTYD BNBozTr8a1Zgb/Xz1TufL6FuWoXvroEvA0a+YHV0a80oGAWjYMgB6Mjwf7T69T/2KvY3ovrEg5Cr VZw1K9J11OCaFSCARmvWYV6zfv385fPlW58vwg7Zh9wHB6xWX71Dq1aR1iv9He2tjoJRMAqGKkCd eUXeBYu9C4unikWrVompWcG1OUAAjdasw7lmBVWrl26BjliCV6uP4NUqZHcN+jLg/2jnK42CUTAK RsFQBDjqV/QhYsRE7B+kgV+MQWDMahVnzfoPqAYggEZr1mFbs4LOL7xwEzQIDK1WQWdB/HwOOwvi 42d4tfoX5Xyl0Wp1FIyCUTBcwL//mOPD/9EPIv6LWr/iQH+Irll//wEIIKSa9c9ozTp8AGhuFdhb Ra1WIbeXg8+CQFSryLtrRkeAR8EoGAXDFqDPv+KuYvEhWJ2Kt2YFCCCkmhXIGK1Zhwv4cucRZm8V dsQSqFr98w22DPjPH1gSGa1WR8EoGAXDGmCff8WsX5Fr2b94equItcGoNStAACHVrBi3vI7WrEMU fP346cvVO9CVwJC5VUS1+gVxyD64WoVN7I/WqaNgFIyCkQGwz78iHeSEpZZFRYRqVoAAGp1nHW41 K7Ba/Xzl9periCVL8N4q9OTC7yi91dFlwKNgFIyCEQf+4VnihFHF/sVZp+KqWQECaLRmHVY16zdg tXr5FviUJfS5VZRq9RfGptXRanUUjIJRMAIBZuWKGCJG2quDF6EsUgHXrAABNFqzDq+a9d0HYIcV dHgh7DiIX5CVwGi91d+jvdVRMApGwShAApj1K9aJWCiCX8P+D63DCqlZAQJodAXT8KlZv334CLrB Bn54IWLf6mfManV0vdIoGAWjYBQgwD8Yibt+haG/qFwsNStAAI3WrMOkZgVVq5BrzOFH7cMPL4Rs sEFZCTxarY6CUTAKRgEOgKt+/YdUjyIz/qHXrAABNFqzDoea9dt7WLUKum8VW7UK2bc6Wq2OglEw CkYBkQBX5UoIAatUgABCrVlRN96M1qxDBXy5cR+0dRV8jTnovlXIDTYY1SrK9TWjYBSMglEwCggC PP1X3DUrQACh1Kx/UbutozXrkADf3rwDVau3Hn679wR8jTnqxXAohxeOLlkaBaNgFIwC0gFJNeuf PwABhFSzgu+DHa1Zhxb49uY97ESIJ98fvwBVq5BrzDGq1dE7zEfBKBgFo4B8gHn+MHb0H1izAgTQ aM06xGvWZ6++3kLauvr6HUa1+htlbnW0Wh0Fo2AUjAKyAdYj/tFr1r8AAYRRs/4drVmHDAB2WJG3 rkJP2wdtXf3+9/sP5IvhRm+wGQWjYBSMAmoCXFXsf1DNChBA6DUrcrd1tGYdzADo8m/PX32D7LGB bF19h7p19ResWh3trY6CUTAKRgGNwD/UWhZI/P0LEECjNeuQrFnB1epr0GLg+08Re2wgd8N9/wk/ v3C0Wh0Fo2AUjAL6AXBBC6w7AQKI4d+v0Zp16IGvn78gFgPD99h8RjoRAnws8OgNNqNgFIyCUUBn AKw7AQJotGYdejUrqMP65AWuxcBYjgUeBaNgFIyCUUA38PcfQACN1qxDrGYFOvfbw6fQVUvg6+F+ vfuIb+vqKBgFo2AUjAJ6gn//AAKIAbzOZbRmHTIA6GDEEYaQe2zgq5bAkTi6x2YUjIJRMAoGEvz7 BxBAWGpWeOU6WrMONgB07bf7T4AIMb0KWrX09e/3n/+gB+6PLgYeBaNgFIyCAQX//gEE0GjNOpRq 1m9PX2JMr6LcY/MfvmpptFodBaNgFIyCAQH//gEEEKxm/T1asw528PXzl+8PnwHRz+evf4EPhUCs WkKbXh0Fo2AUjIJRMHAAIICw1azAkvrP39GadVABYLX67cET0FU28N2roLOWvqFWq6O91VEwCkbB KBh4ABBA2GvWv79+jdasgwp8f//h273HPx6/QNm9ijS9OjoIPApGwSgYBYMEAAQQ1pr112jNOqjA N2CH9c4j0DjwM/Qz99FPBh4Fo2AUjIJRMNAAIIDgNStkEROsz/pztGYdRODbh0/fEOPAsDP3YePA o/eZj4JRMApGwaACAAGEtWaFDAj/Hq1ZBwMAeubbvcffMcaB/2JusxkFo2AUjIJRMAgAQAAxQHZr jNasgxZ8//ARckncL8xxYPDhwKO7V0fBKBgFo2BQAYAAYoCuf0E+4HC0Zh00AOgTpPXAH/98+vJ3 dJvNKBgFo2AUDG4AEEAMkAJ6tGYdnOD7m/ffHz0HbWB98x40DvwFZRz43+j06igYBaNgFAw+ABBA 2GrWn6M166AAQLd9fwS+1Rx27D7ouCXEOPBotToKRsEoGAWDEQAEEO6a9fvPf3/+jNasAwi+v3zz 48kLlFvNIbfZ/EE6F2IUjIJRMApGwSADAAGEVLP+xqhZf4/WrAMGgA4D9VYh5wNDxoER5wOPrgce BaNgFIyCwQsAAmi0Zh2MNSvQVd+fvwbVrGjnA8PGgf+NdlhHwSgYBaNgsAKAAMJXs+I/L2K0ZqUd +P72A2IDK+z6Vfh64NGDDEfBKBgFo2AwA4AAYgBN2v3FUbMCS3PcU62jNSuNAGinzfNXP54jDjJE HQceXbg0CkbBKBgFgxoABBCsZoUdFjFasw44+P7hE2QD6+93iIMM//6CngsxuiR4FIyCUTAKBjkA CCD0mvUfas0KqlxHa1Y6gm/ADuuTF6gbWH9Alm2PdlhHwSgYBaNgSACAAGKAHDiA5VB+SM36bbRm pSv4/vkzqMP6CrqBFf1Cm9FqdRSMglEwCgY9AAgg3DXrD2jN+ufb99GalT4ANMOKb+HSaId1FIyC UTAKhgAACCDUmvU36gGHozUrfQGowwrZaYOxcGm0Wh0Fo2AUjIKhAgACCF6z/h2tWQcWAB39A63D Clu49B+0cGm0Wh0Fo2AUjIKhAQACCEfN+hO1Zv31a7RmpTX4Cj506Rf2nTajM6yjYBSMglEwZABA ADGAD/QB16xYNt7AatbfWE7nH61ZqQt+vPsA6rC++wjusCJOXBqtVkfBKBgFo2BoAYAAAtWsoMFG /DXr6GgwjQHQGT+A1Sqkwwo+IvgfsMM6evL+KBgFo2AUDEEAEEBYalbYVCt44w2kZv32Y7RmpSn4 8eY96E4b8NEQf1E6rKMLl0bBKBgFo2CIAYAAgtWsf/HVrKDBydGalWYA1GF9+Q7r3eajHdZRMApG wSgYcgAggBgg2zmwLQ9GHBYBrFkxx4RHa1aqVauv34IvYUWcZYiYYR3ts46CUTAKRsFQAwABxADp FSEtYsKsWUF9VlCJ/2e0ZqU+AC1cQr6EFeloiNG1S6NgFIyCUTAUAUAAYdasf7BsaQXWrF++/fn+ Y7RmpS4A7bR5+RZyliFKh3X0iOBRMApGwSgYsgAggBigxTf+jTejNSttwPdPn3F1WKGHLo2CUTAK RsEoGGoAIIDgNSvSVCvKufxINSuw6P/1e7RmpRb4Bj4aAsfh+6Md1lEwCkbBKBiqACCAsNWsKFOt qDUrUGS0ZqVWzfr5C6LDinT4/uhZhqNgFIyCUTCkAUAAwWpWlOXBf3DWrEgDwqM1K4Xg++fP8A4r 6lmGox3WUTAKRsEoGMIAIIAwatY/aDXrT2jN+hVUs4LqANgZwqM1KyUAfEowxvXmox3WUTAKRsEo GPoAIICQa1aU8yKQN96M1qxUBz8+fobsYf2DuiR49La4UTAKRsEoGOoAIIDw16y/oDXrN0TNCupg /fkzWrNSAr7g7LD+He2wjoJRMApGwVAHAAGEqFkxlgcjT7Ui1aywqdbRmpWSmhXLoUujO21GwSgY BaNgWACAAILUrP8xplpRalbI0cGwPuvX0T4r5TUrjkOXRmvWUTAKRsEoGPIAIIAYwNUqZs36B6PP CqtZQVOtv0drVkqq1Z9v3mPOsI6eZTgKRsEoGAXDAwAEEAOUxjYgjL48+At0QBh00xlmvTpasxIH fr56j95h/QUZCh6tWUfBKBgFo2A4AIAAwl2z/kZaxDRas1IJfP3y9eebd9g7rKNDwaNgFIyCUTAs AEAAodasuKZaUbe0gmrWnz8xK9fRmpUg+PHu4+i1NqNgFIyCUTC8AUAAwWtWtG4r+lQr8sYbYM36 +yOWbutozUq4Zn3/EXTo0ugM6ygYBaNgFAxfABBADAgmvqlWlOXBkJoVJDJas5ICvn/5iuPQpdHT IUbBKBgFo2D4AIAAIrZm/YtRs4JqiNGalRTw49PnX+8+YOxhHe2wjoJRMApGwbACAAGEUbP+Q7v0 BnydHPK5/J+//oHVrH9Ha1ZSwE9guL3/BOqwws7f/z96OsQoGAWjYBQMOwAQQFhrVoypVuTlwUg1 K2hMeLRmJQ58//zl19sPvz+CL4wDdlhBO21Gz98fBaNgFIyCYQgAAogBhYdnERP2mhWl2zpas+Kr Wb98xXlh3CgYBaNgFIyCYQQAAghPzYptERNazfrhE4g7WrMSAX58+QpduwTpsILXLo3OsI6CUTAK RsHwAwABhK1m/Yd6ND/mIqZPX0drVpLAV2CH9eNn6NolWId1dBx4FIyCUTAKhiUACCC0mhVzQBh8 XsQP9KlWeM0KWpLz89dozYoffP/6Fbp2CRiM4BlW0MKl0Zp1FIyCUTAKhiMACCAGdAHiplpBG29A NetnUIXx9ftozUqoZv0GXruEfDrE6B7WUTAKRsEoGJ4AIIBw1KygyhXbVCu2mvU3UGS0ZsUNgA79 DV679Adl7dJotToKRsEoGAXDEwAEEGbN+h+lZv0DP5ofNtWKOCwCWrOClrz++Dlas2IFX5CvYoWt XUKcDjFauY6CUTAKRsGwAwABhFGz/idiqhW6PBhRs0K6raM1K/aaFde5S6NgFIyCUTAKhiMACCCC NetfLFOt4PvPkWvWX28//Pn1a7RmxVqzgtcufQX1+KGbbf6OdlhHwSgYBaNgGAOAAMJas/7H3HuD ZaoVsjwYVrOCVuiM1qwY4OfnLxhrl0ar1VEwCkbBKBjOACCAsNWs/1FrVsiAMOZUK2rN+uvN+9Ga FROAOqzo5y6N1qyjYBSMglEwnAFAAOGrWbHsvQFNtaIuYkKqWUFjwqM1KxIAGg46Whn5kvPRanUU jIJRMAqGOwAIIFw1K+4BYdBUK+gKdHjN+vsd6DZvUM36Gr3bOsJrVsS5S4i1S6PbWEfBKBgFo2CY A4AAwlGz/ofXrP9wTbXCNt58+v0e2GcF16xv3qOtYxrpNeuHz4ih4F+jR/CPglEwCkbBiAAAAYSn Zv2PtvfmL3TvDWyqFX56MKRmBQ8I/3z9DrlyHck1K9B9v6BDwYhtrKP7bUbBKBgFo2DYA4AAwl2z /scxIIw21Yq6iAlYs4LWCY/WrJB7zlGHgkdPNBwFo2AUjIKRAAACiHDN+h8+IPwbY1crcs36ZrRm Ra1ZP3/Bvip4FIyCUTAKRsGwBgABRFzNirxCGD7VCqpZv6ItDx6tWeHg15evf77ChoIhl9uMdlhH wSgYBaNgBACAACKiZsU/IAyaakWpWX++egcaJR6tWb9+gw4Fj65dGgWjYBSMgpEEAAIIf82K+3T+ bz+Qz4tAq1lBJwmP+Jr1N7DDChsKBo0Djw4Fj4JRMApGwcgAAAFEZM2KGBD++wtp783nb5BFTL/e f0KuWX++fAvpto7YmvUnqMMKutwG/azgUTAKRsEoGAXDHQAEEN6a9T+O61rB995ADxCGT7WCt7TC a1ZIt3Vk1qxAM39//Tp6VvAoGAWjYBSMTAAQQARrVtQVwn+QD2P6DjqMCXmq9c2HX6/f/QLXrD9f vAFVriOyZv0BPqMKsXZp9Nq4UTAKRsEoGEkAIIAI1az/cVwqh7RCGDwgDFvE9Po9vGb9+fz17x8/ Rm7NCrvnfHTt0igYBaNgFIwoABBAxNSsOI+M+PMNdswh0iKm0Zr1x7dvWIaCR8EoGAWjYBSMDAAQ QETUrP+RzhD+i3Kp3B/ECmHIVCu4Zn2NqFl/PHv1e4TVrEBnIQ6IAA8Fj06yjoJRMApGwYgCAAFE Qs2KY0AYNtUKPYkJXLMCu63wmvXHzxFVs34HBQjytXGjQ8GjYBSMglEwsgBAABFZsxIYEP6DMtWK UrP+ePry96/fI6tmRbk2brTDOgpGwSgYBSMLAAQQcTXrf8yNrahHRnz6Crv0BrSICbzx5g2wcoXW rN++j6CaFTLJCjsrePRQw1EwCkbBKBhpACCAiK9ZsXVbkU7nR55qhWxp/fkc3G19CqpcR1TNCr82 bvSAiFEwCkbBKBiBACCAiK5Z/yPVrH+RB4RhF6EjdrWCz4uA1KzPwDXrk5e/Pn0eQTUrZCgYVLOO DgWPglEwCkbBiAMAAURyzYq0jgm6Qhg2IIy09+b1e+jyYFjN+uP56xFXs44OBY+CUTAKRsGIBAAB RFLNinpAP+KkQ6wDwoiNN6Ca9fGLn8BKd7jXrECrofttRu+3GQWjYBSMgpEKAAKIvJr1H+qA8E9Y zYrYe4OoWSF91icvfr58M+xrVlCH9dsP2CTr6FDwKBgFo2AUjEQAEECk1Kz/0W5sBd+FjjQgDDmM 6Tf4AGHYVCuiZv3+6PmvD5+Gcc0KNAp8XPCPv79GT+EfBaNgFIyCkQsAAojUmhX1gH60dUxIA8KI mvUZrGZ9/PwHsNs6vGtWlJ2so5Oso2AUjIJRMBIBQACRWLP+x+y2Qje2Is4QhgwIv4YOCP949hpe s35/+OzX5y/DuGZFmWQdrVZHwSgYBaNgRAKAACKjZsW6jgnjyAjIrlZgzQobEIbUrN+fvPw1TGvW X9++ww81HB0KHgWjYBSMghELAAKI9Jr1P6xyRTuPCW0d09sPGDXrC1DNCuy2fvs+LGtW8BkRPyAd 1tGh4FEwCkbBKBixACCAKKhZkbqtf3+hbWz9hNjVCptqhdasD55+u//k148fw69m/Q2ZZB3dbzMK RsEoGAUjGwAEEFk1639c22/gV99AVgjDp1pR+qzf7j/9du/JMKxZkSZZR6+4GQWjYBSMghELAAKI 7JoVuduKvP0GdYUw5NIb8Ln8P0A163NwzfoEWLPCx4SHTc365/sP+EH8o7edj4JRMApGwYgFAAFE bs36H9v2G+gB/bCTDt9+/IW8q/XxS2jNCh4Q/nb38a+v34ZVzfoDMsn6B9yV//dvtGYdBaNgFIyC EQkAAoiSmvU/yvYbzI2t72ArhOFTrY9QalYgdzjWrKOTrKNgFIyCUTCiAUAAUVCz/sd+r9wf+Dom yBnCkBXC4F2tKDXrvcff7jz6+fHzMKpZf45Oso6CUTAKRsEoAAggCmvW/+CaFUe3FXL1DXhAGFSz PoUsYnr+HalmBfVlh1PNCj19aXSSdRSMglEwCkYuAAggymrW//+xnsf0F3Ie08fP0NP5YXtvQDXr o+fgPutTUM169xFo/nXY1Kw/f4ECYXT50igYBaNgFIxsABBAlNessG4r2r1ySBtbQWcIQ1YIQwaE kWrWr7cf/njzfhjUrEBLwQfx/xk9I2IUjIJRMApGOAAIIIpr1v/os60o5zF9QO22PoWdcQje0gqq We88+v7sFdo6pqFYs0InWUHnGo7WrKNgFIyCUTCiAUAAUbFmRd1+A+m2Qk46fAM76fDpK8RJTLCa 9eutB9+fv0auXIdqzTo6yToKRsEoGAWj4P9/gACiSs2K1m39jaXbClrH9Aax9+bBM3DN+hhUs95+ CKxcf375OrRr1tEzIkbBKBgFo2AUgAFAAFGtz4q+SBh+jDC824o6IAzZ0voNUrPevA/k/hzqNeuf 0aHgUTAKRsEoGAX/AQKIGjXrf4xTI5C7raB75T79egddxwRdIQw5PRipz/r1xv2f378P0Zr1F+Ly uNGadRSMglEwCkY6AAggatWs/7CeGgHqtoLvlfsF6rbC1jGBBoQhU63INeu9Lzfv/xyaNevv76PL l0bBKBgFo2AUQAFAAFG5z4rUbQWf0Q/qtn77DT1GGHYe01PYYUz3nny98xhas968/+X6PSA5JGtW yPIl+IXno2AUjIJRMApGMAAIICrVrP8hlSvsRvQ/6LOtoOvQQeuY3oPPY4IPCIMXMYFq1oeQmhWI fn77NlRr1tGFwaNgFIyCUTAK/v8HCCDq1az/cS0S/gGdbYXcK/fy3Q/QgPAL6JERdx9/u/0IWrPe uPfl2l0g+fPr1yFas472WUfBKBgFo2AUAAQQTWpW+I3of3+hXtr67iPKOibIrlbo8uAHoJoV2G29 eufb4+dDq2b9CjqA6ReiZh2tXEfBKBgFo2AEA4AAomrN+h9zkTDkSKYff0HdVsj2G9iA8JMXkKlW 9Jr12t3PV27/+PR5CNWsP77/gI0Gj95yMwpGwSgYBSMdAAQQrWpWUOUKOewQMtsKOjUCekY/9MZW 8Dqmb5AVwrcfAWvWrzfuw2vWz5dRKtdBXrP+/vkTtGJrtGYdBaNgFIyCUfD/P0AAUbtm/Y+0jgm1 2wpax/QJvv0GOiAMrlmfgGrWW8A+K6xmvXoHVLO+eTe0atb/f0dXMI2CUTAKRsEo+A8QQLSoWf8h xoRRbkSHHXb49sPPV29/QDe2Pv92/+nXu48Qy4NhNevny7d+vP8wRGrWXyBvjm5mHQWjYBSMglHw /z9AANGgZv2PubcVtkj4y3fQqRGQ7TfgA/p/QNYxQfbe3Hzw9fr9L9fugWpW0IDwrc+Xbv74+m3o 1Kyjy5dGwSgYBaNgFPwHCCDa1Kz/4YuE0Y5kQum2/nwG7rY+fPYdso7pFlrNehtYs35/8WYI1Kyj C4NHwSgYBaNgFMAAQADRumaFVK7I3VbwqRHvwZe2Qu6Ve/T8+33IxlbogDByzfr54o2hUrOO9llH wSgYBaNgFAABQADRrGb9j9Rt/Yur2wpeJAzffgPZewPa0nr38xXwVOulW8Ca9StQdmjUrKPzrKNg FIyCUTAK/gMEEE1rVjD6ixgThl6A8+Xbn0+w2daX0G4r9Oqb2w9BK4RBG2/ufLkCrVk/Xbj+9cHT QV2z/oSMBo9uuRkFo2AUjIJR8B8ggGhZs/7H0239BjujH7xIGHKMMHQdE9KAMKhmvQmsWT+dv/7t EXrPdRDVrL9+QRoQozXrKBgFo2AUjAKAAKJLzfoPMdv6D3aS8G/4kUyQww5B3VboOibIGYdfQAPC kJr1BrBm/XL7AdqE66CqWSG3vo/WrKNgFIyCUTAKAAKIxjXrf8TBEf//Yru39e3HX69AZ/SDDjt8 AL5X7vbDLzdBA8Kg2dZLiJr107lrX+88/P7t+2CtWUePiRgFo2AUjIJRAAIAAUT7mvU/vHKF7cCB 3tsK7LZ+/f0B2G39AF8kDJptvQM+6RCyjgm8iAlUswLRueufzl79/u7DYK1ZRxcGj4JRMApGwSgA AYAAolvN+h9x3uEv0A6cP9B7Wz+D722FLhKGHiN868HXG7ADhC/e+nwB1m09e/Xz9bvfR2vWUTAK RsEoGAWDGAAEEF1q1v+IpUzIY8Kge1s/w7qtkAtwwLOtX8Hd1i/XwXtvQH3Wm58uQgeEPwK7rZ++ jNaso2AUjIJRMAoGLQAIIHrVrP/Rx4ThB0fAduC8+/HiDeRIJuhs64370BXCF2/Bp1o/ngWh719H a9ZRMApGwSgYBYMUAAQQPWvWf0jbW6G3y4HGhGE7cCDd1h+QI5nuPIKsY4LsvQHWrJ/P34D0WT+e ufLx9JXRmnUUjIJRMApGweAEAAFEx5r1P/phwn9hS5n+fATfLgc5OALYbYWd0Q/ZfgPdewOtWa9B atbvnz6P1qyjYBSMglEwCgYhAAgg+tas/5HHhKFLmUA7cL58BV2KDjk44tlr8EnC4L2tkPOYIMcc gpcHg0eDrwJrVmD9iqdyHa1ZR8EoGAWjYBQMFAAIIPrXrNCT+qHdVvSlTJDzDl+C9rbefQw/NQJU uSK6reCa9dRl0Gqmj59Ga9ZRMApGwSgYBYMKAAQQ3WvW/7BL0dGWMn39Brm69Sd4B873x+AdOKBF wve/XL37BVazQlYwQQaEP5669AVY+47WrKNgFIyCUTAKBhMACKCBqFn//wfXrP+w3YED2YEDPjgC skj4FmK2FbarFVGzfjh56fu796M16ygYBaNgFIyCwQMAAmiga1aUpUzfwIcJg7qtPyC3yz14+hW+ SPjy7U+gbivSVOupy8Ca9cOJi9/eoleudK5Zv375+vfP6BVyo2AUjIJRMApAACCABqhm/Y9cuSIv ZYLtwHn1FtxtfQ4+kunhlxv3wNtvwIcxgfqssJoViE5cBKLvbz8MYM368+fP0T7rKBgFo2AUjAII AAiggaxZobOtf2Hd1h8//379/vvzF9CY8GvwHTiQHTh3Hn+98QDabYUPCKPWrB+OX/j+ZcBqViD4 8+fPaM06CkbBKBgFowAIAAJoQPusaEuZfsC6rR8/g5YyvXoH2YHz7d6Tb6Ajme59gXRb4TXr6Ssf YAPCwJr124s3ozXrKBgFo2AUjIIBBwABNMB9VvQxYUjl+vnr7/efoUuZnkB24IBPEobsbYXde/Px FErN+uHYhW/PX43WrKNgFIyCUTAKBhYABNDA1az/kStXyJjwb8iYMGh7K+gw4U+/4Dtw7j/9dvsR 6AIc8Bn9ny9AVghfBdesl+E164dj5yGVK/1r1u/fvo/WrKNgFIyCUTAKgAAggAa+Zv2Hsk749z/I 9lbkw4QhV7dCljJdu/vlMtJ5TMBu60nYVCu4Zv105daA1KxAAPTCaM06CkbBKBgFowAggAa0Zv2P MSaMdsHc+08/37z/+eI1ZEwYugPn6l3IGf0fz0HWMV1BGhA+//7o+S/3Ho/WrKNgFIyCUTAKBgoA BNBA16z/UZcy/YV0W39DL5gD34v+89Xbn6CrW1+AD44AnXf4+cpt0KWt58Dbb4A16wlYzXr8ArBm fX/03NenL0dr1lEwCkbBKBgFAwIAAmhQ1KyYY8KwpUzgdcJv34PHhMFXt8KXMoG7rZ+g3dbLH2GV K6Rm/XzrPvFjwtSqWf9CFjGNglEwCkbBKBjZACCABkHNCgHwMeE/kDFh8FKmb9Ax4V9v3oNPZXr5 /T74VCbQwRF3oEcygbqtlz+evPzhOLhmPQauXI+c+3z7IZGVK7Vq1n+jNesoGAWjYBSMgv//AQJo kNWs0Mr1D6hyhSxl+gI+8hCyvfU5+IK5e49B21tBO3Bgs62QyhXUZ70IqllBs63n3h8+S2TlSuWa dbRyHQWjYBSMgpENAAJo0NSs/5FWM/2Bbm/99wOyThh8Uv87+En9z0EXzMEPEz4PPu/w1JWPJy+B uq2QmvUIqGYFok837n39QqBypVbN+ne0Zh0Fo2AUjIJR8P8/QAANypr1L6JyBZ3U/+37b1Dl+hl0 e+uLN9+fvIReMHfjPugOnIs3gTXrpzPgww6PX0Lus4LRmU/X7tCrzzp6KP8oGAWjYBSMgv8AATQo a1b0MeGf4CMPQWPCv0DX4IDXCd+HXjD3GbK99SxskTBkQBhYs0K7rWfeHzrz6eptOtSsX79+Ha1Z R8EoGAWjYBQABNBgqln/IypXxJgwpHJFrBOGXIPz8vvD51/vPgZtb70C7raClzJBDuiHL2ICV66g mhWIPt9+SOuaFWjUaM06CkbBKBgFowAggAZZzfofW+UKvRodNuEKrFyh1+A8+3obsk4YtL0VdCTT afAxwsBu69HzH47CZlvBNevHSzdwTbiO1qyjYBSMglEwCqgIAAJo8NWs/9EmXP8gH8z0++OXX++h 5wn/eAwbE752D7pOGLxIGDQmDOy2HgGdxwSdbT105t2hM5+u3MZatVKzZv07WrOOglEwCkbBSAcA ATQoa9b/mJtwwOcJ/4DcMfcFPCb8DnQwE2Sd8K0HoCMPL94EHSYMqVxB3VZw5Qpdx3QWWLO+O3j6 08WbmJUrtWrWz+Ar0Ee7raNgFIyCUTDCAUAADdaa9T/GJpzfsE04X0CH9YPOE4YczPTg2Tf4mPBF 2JgwuNsKGhA+fA5Ws54F1qzvDpz+eOE62rAwFWvWb9++jdaso2AUjIJRMMIBQAAN4pr1/3+kbivs sP7vP/+CD2b6BT2s/w1oTPjBU/g6YdCY8Fn4mPDFD6Cp1nPQmhXYbT0ArlzPXUc+QYL6NesoGAWj YBSMghEMAAJosNesaKce/gUfzPT3K3id8LuPP1+/+/Hs9Q/IHXPw84TP3/h4Gli5gg+OOHr+A2hM +BysZoVUrqc+nL4Cr1ypWLMCzQSdyz8KRsEoGAWjYAQDgAAaAjXrP6QJ17+/wLejf4OOCSNvwgGd HXETfHbEJfA1OKeufIRc2goZE4bUrAehNSuocj17BTIsTMWa9TNkqnUUjIJRMApGwQgGAAE0uGvW /1iOjwBVrtCbcGAHM718+/3xC9CEK+hgpnugHa7nb3yCHyYM2d4KGRM+eAY82wqqWd/tP/X51oPR 0eBRMApGwSgYBdQFAAE06GvW/4ieK3w1099foIOZ/n79/ufTF9BNOK/f/wCdegjahAM6rP/6vS+g 84Svf4JuwrkIqVnBA8LgdUyQynX/qQ+nL3/9TM2aFVhP//n9e7RyHQWjYBSMgpEMAAJoKNSs/5E3 4fxFmnCFVa6QUw+fvQb2XMG3oz+ETbiCD2Y6een9cWi39d1BWM0KRPvBleupS18/UbFu/fz9+/fR mnUUjIJRMApGMgAIoCFSs/6HDQsDa9a/0FMPIROuf798+wM69RC8munpq++PQDtcv9x88Pkq6ALX j+eugY48PHkJeuThoXPQAWHwDhxw5Xryw4lLX0dr1lEwCkbBKBgFVAIAATR0atb/4E04kJoVtXIF HSn8AVy5wlczASvXG/fhpx7CzhMGn3cIWccEqVlBlevJd/tOvj96jlqV62jNOgpGwSgYBSMcAATQ kKpZ//+HdFv/Q8aEoauZYEcKA3uub8B3uIKOFH767Q6kcr0D3uEKrlyPX4Sed3joLGyRMHjCdR+4 cj10hiqV6+giplEwCkbBKBjhACCAhmDNCqpcYROusMr1z7fvfz6Bz+uHHx9x/8nX2+AjhS+BVjOB KtcTwMr1AuTqVtBSJtje1nf7oJXru6Pnv376/IXiNU3QMw5HwSgYBaNgFIxIABBAQ61m/f8fcXYE 6mqmP1/BlSv0vH5Y5XrrwZdrd2DHR1wB34RzAXoHzsGz70GVK2gdE6RmfQtGH85fp7ByHa1ZR8Eo GAWjYCQDgAAagjXrf0TP9T9S5frn+48/X7/9gVyQ/gp0GQ5oNdO9J9Dz+oGV67lroMoVMuEKPjvi /cEz76HrmEA917fQyvXExws3KNmN8/Xr179//gx0GI2CUTAKRsEoGBgAEEBDs2b9j7ZUGFa5fkOp XH88Ay8VvvMY2nO9ePPTWXDlCp1wBa1meg+ZcAVXrm/3QyrXE0BEYc/1169fAx1Ao2AUjIJRMAoG BgAE0BCvWeGrhf/8+QuvXL98hd00B1kq/AxUuYJXM32+AK5cT16GHCkMvbp1/2kwAtesoMoVVLO+ 3Xvyw9lrZFeuozXrKBgFo2AUjFgAEEBDtmb9jzzhCjubCVi5/gBVrr+/QA8+/PXy7Y8nLyCV65fr 979cuQOacD1zFVy5XvhwFDLheub9gTPv95+G1qz7T0JqVmD/9f3py2Qff/hndEB4FIyCUTAKRiQA CKChXLP+R55w/YeyVPjrd/Cpwp9A+3BevAFVrqB9OA+/XL8LumkOdDbTlY+Q1UxHoROuSN3Wk+DK FYren7pCXuUKOuZwFIyCUTAKRsHIAwABNMRr1v9olesfaOUKWir87fenL7/ApwpD9uFAK9drGJXr EVjleuA0Zs36bt+pD2evkjEsPFqzjoJRMApGwcgEAAE09GvW/xiV62945fodXLl+BFWuz1//ePTi O/xUYXjlCrog/cIHcOX67uDpt/DKFalmBXZnP14geUHTaM06CkbBKBgFIxMABNCwqFn/o825AivX 34jK9SOocv0J2uQKqlyhR/ZD9+Fc/3gaUrleBFau4AtcQQczvT0AXyd8EjREDKxcD5z+eOUWSZXr aM06CkbBKBgFIxMABNBwqVn/I/bhgHquv8GVK+QEiS/fQJXrO/CR/c9ffX+EuA8HdNkcqHIFL2g6 BjueCXzHHKg2Be1whSLQzpxDZz5dvk38Ptdv3779AzpmFIyCUTAKRsEIAwABNIxq1v9Im1zBO1wh lSt4Hw6scn0FqVxBJ0iAbnIFDQvf/gi/bA5cuULvcN1/+i1azXrwDLDeBfVc7z0mck3T6HkRo2AU jIJRMAIBQAANx5oV6RrXf78wKteXb6GVK/Rg4bufoDe5XoFWrkcglSt0n+tb8DwrvGZ9f/Q8sIP7 5e4jYqrW0Zp1FIyCUTAKRiAACKDhVbP+x9jk+vs3lsoVcjzTY0TlClrQdAG0z/XDKWjlCrkP5y30 EAlYzXro7Psj5z+cuAhU+fnizW/PX+GvWYFd23+jBwiPglEwCkbBCAMAATTsatb/yD1X5Mr1J8aw MPhg4ftPkVYL34APC7+D91wPwG5yBdWsZ4CV7ofjFz+evvL5wo0vV+98e/UOf+d1dKp1FIyCUTAK RhoACKDhWLP+xzhBAjosjFy5fvr5+j2scgUvaLp+D3olDmhY+DLKsDCkfgWSkJr12IWPpy9/Onf9 85U7X28++P7uw7cvX3HNvP4ePeZwFIyCUTAKRhgACKBhWrNCAGbl+uPnX9CVON9/f/oKrVxfvPn+ +MW3B0+/3n4Eqlwv3wbfN3cVWrmCzxZG1K+HQFOtoJr15KWPZ68Ba+KvN+9/u/f4x5OXPz5hr1m/ fv060KEwCkbBKBgFo4CuACCAhnvNijIsDD37EFy5Qk9oglauT16iVK6QOVdE5QrqvIKGgg9BFzHB p1qB6r/eeQTs+P588ebnpy8/vn3DUrOOTrWOglEwCkbBSAIAATSsa9b/WCpX6D7Xbz/+fPsGOlsY WLm+ef/zxVtE5XrjPrhyvQle0HQZfOUceE0T5L50IAmqWS+BplqBNeu1u19vP/z+8PnPZ69/vXn/ +8PnH9++o1WuP378GOhQGAWjYBSMglFAPwAQQMO9Zv2PsRXnD/wQCfBlrp+//H7/8ReocoX1XO+A K9crd0A917PXPp66AqxHwZ1XWP0Kq1mBCkBTrbcefn/w9MezVz9fvQPW078watZv374NdBCMglEw CkbBKKAfAAigEVCz/kdUrv8xK9cvoGFhYOUK7rm++fH01beHz+CVK+iy9HPXoSPDkPvSgejYBWjN ev46sHf79eaDb/ef/Hjy8ufLt7/efQT2g4Ed4h/ff8DXNI3WrKNgFIyCUTCiAEAAjYya9T/qsDDK 8YegyvUP+OD+n2/e/XzxFli5fodUrjcffIYcLww5pOnUZWCFCroy/cTFDycRNeuX6/e/3Xvy/fEL YMX86+0HoFF/vn4Hmgw0/8f371+/fgWNBo9OtY6CUTAKRsGIAQABNGJq1v+Yw8J/MXqun369ff/z 5Zvv4J7rt7uPvt56AN7qevPThesfz179CKxcT13+CEFnrsJq1nvf7j4GLWJ6/ubXmw+/P3wGmvb3 x0/QPto/oEOMofaOglEwCkbBKBgZACCARljNCmeg91xhl6WDKtcPP1+9/fHsJbDnCt7qCq5cr9yG jAx/OnsNdD3OmaugXTcXbkBqVtDy4IfPQIuYXoOmWkE16/ef/379BpoPuiHg32jlOgpGwSgYBSMI AATQSKpZ4QA+5wo7pAlUuf6AVa4fPoMrV/AJiI+ef3sAPrv/xv0vV++ARoYv3AB2VT+duwbqsF68 CapZb9z7BqxZHzwDqv/16h18qhU8IPwH3G39O1qzjoJRMApGwcgBAAE0ImvW/6hXzsFPQIRUrl++ wSvXn8/f/HjyElhrfrv7+OtNWOf10q3PF2+BqlUg4wqwZr0PrVmfvvwJqlk//IZMtaINCI+CUTAK RsEoGBkAIIBGas36H/MExN/QcySgJyB+BvY+f71+B14wDB4Zvvf46+2HX2/eB13sCuy/XrkDJEH7 WW89+AqvWcHLg0dr1lEwCkbBKBjJACCARnDN+h/b8cLwcyQQa5o+gC+ee/3j8YvvD56COq+3QIPD X2/cB5E37wO5oBVMD2E169uPf5BrVuSp1lEwCkbBKBgFIwAABNDIrln//0esFka9Lx2xpgl5ZPgp dFkTqH4F9l9B6BGQDRT5/ug56LAISJ/14xfo8uBfozXrKBgFo2AUjDgAEEAjvmb9j6hc/6NVrvBp 14+fQZ3XN++BFedPSOf14bPv95+Cqth7T4AdWVCH9clLYL8WdAzTO6Q+62jNOgpGwSgYBSMPAATQ aM0KA4j6FWVNE2RkGNp5fQfuvL54A+yeglY2PXoO6qo+fgGqVoEd1hdvQEcHv/8EVDxas46CUTAK RsGIBQABNFqzIgH8I8OQzuu7j7/ewOvX1z+B6DkYAavV1+9+vQWfFAGvWUfnWUfBKBgFo2DkAYAA Gq1ZUQHihGHwsiZw5Yqt8wqqX0Erh19BEbC3CqpW338CLQwGnxQBOeBw9BimUTAKRsEoGGkAIIBG a1ZsAGNDDqhyRe68fvoCrF9B/VcgevvhF5gBEgFXq5AO699fv0FH//8BnUcxWq2OglEwCkbByAEA ATRas+IAuDbkQDqvX79BzvEHVbEfPwMRaNXS56/QahXeYf09WrOOglEwCkbBiAMAATRas+IA8GFh 1FvToZ1XcP36F9x/RSBgnQoU/AGuVmEdVkjdPDoaPApGwSgYBSMHAATQaM1KCGDrvCLqV2D39PsP BPkD3lv9De2tjlaro2AUjIJRMMIAQACN1qxEAKRDhtHqVwgC1bKQfuovSJ0KGQQePYt/FIyCUTAK RiIACKDRmpVogHZDDrR+/QPtoUIqVIgI2iDwaM06CkbBKBgFIwkABNBozUoKQOzJgdWd8EvU4egv dEfsaLU6CkbBKBgFIxMABNBozUoiQFrZ9P8vbMgXcjIilPsPRc0oGAWjYBSMghEGAAJotGYlC/z7 RxiNglEwCkbBKBiRACCARmtWCsBotToKRsEoGAWjAAMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpG wSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNg FFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQ aM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbB KBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AU UBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBo zToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEo GAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQ EwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjN OgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgY BaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFAT AATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06 CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgF o2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMA BNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToK RsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWj YBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE 0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpG wSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNg FFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQ aM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbB KBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AU UBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBo zToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEo GAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQ EwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjN OgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgY BaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFAT AATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06 CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgF o2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMA BNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToK RsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWj YBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE 0GjNOgpGwSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpG wSgYBaNgFFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNg FFATAATQaM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQ aM06CkbBKBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAE0GjNOgpGwSgYBaNgFFATAATQaM06CkbB KBgFo2AUUBMABNBozToKRsEoGAWjYBRQEwAEEMO/f/8G2g2jYBSMglEwCkbB8AEAATRas46CUTAK RsEoGAXUBAABNFqzjoJRMApGwSgYBdQEAAE0WrOOglEwCkbBKBgF1AQAATRas46CUTAKRsEoGAXU BAABNFqzjoJRMApGwSgYBdQEAAFEQs36DwPQ1GWjYBQMFPj79+9AO2EUjIJRMIQBQACR1mfFrFxH a9lRMGwAsEL9AwMD7ZZRMApGwRAGAAFE8mgwnsp1tIodBUMMgJMrMNH+wQAD7bJRMApGwRAGAAFE zjwrwcp1tKIdBYMWICfOv7jBQDtzFIyCUTCEAUAA0bxmRatiR+vaUTAggGBVOlqzjoJRMAqoBQAC iPy1weTVr7hq3FEwCmgBILUpSXXqaM06CkbBKKAQAAQQRbtuqFW5jlaxo4CKAF6PklGhjtaso2AU jALKAUAAUbqflbqV62gtOwrIBpTUo6M16ygYBaOAigAggKhzUgSN6tfRWnYU4AFUrEdHa9ZRMApG ARUBQABR7QwmmlauoxXtKICDf1Ttm47WrKNgFIwCqgOAABp6NetoLTtCADyK6VOVjtaso2AUjAJq AYAA7Jy7CgAgCAD//4srX2RFNrVJUXjc6iAqOun8N/jKft3hmFdwDCvf+W0avIg2iiBxytPC2QQu ICpgE1USGvZAPaFY2sOQ5e0BCL6gCiCanMg/cJUpPkB1b44CCgHWaBrognoUDBkArVOBNej3n6gV 6k9ghQpBKHXqb/x16mi1OgqoBgACiIZ33dC33iQT0MjvowATDHRUj4JhBID16q/foLoTW22KqFCx 1an/R/upo4D2ACCAaHuL3EDnPzIB7QJkhICBjsBRMJwBtPrEqE3BFSqOTuro2O8ooC8ACCB63M86 0DmR+oDWITZUwEDHwygYWQDaT8VAiB4qCXXqaLU6CmgIAAKITjefD3SWpAegQzAOCBjocB0FowAM MKpVRA8VuULFWqeOdlVHAX0BQADRqWaFgIHOmoMC4AoWusXCaFyMgqEE/vyF1qPIq3xxVqijdeoo GBQAIIDoWrMig4HOr6NgFIyCQQz+gpYpYalKERUqvjr1H5ax39FKdRTQDwAE0IDVrHAw0Dl4FIyC UTDIALCCJFibYu+kYp1PHa1TRwG9AUAADXzNih8MdBYfBaNgFNAR/PmLUneiV6JIVSmie4prgdLo 2O8oGDAAEEAMA52TRsEoGAWj4N/fX5C9NFiW/v79hWf17x/kKhZL/ToKRsFAAIAAAwBrB62HCPcV DQAAAABJRU5ErkJgggBuHvCwHgAAF2oLTMxkrnz7uzZnMSsB7P+JUE5HDQoaCgAAAA1JSERSAAAB LAAAACYIAgAAAPHzMfAAAAAEZ0FNQQAAsYiVmPSmAAAACXBIWXMAABcSAAAXEgFnn9JSAAAeQUlE QVR4nOxbeXwVRbb+qrpv3z1kISErWdh3MggBYQQUUFxA4Y36FAdnZEB9igvOeygOm6AgyuKgiMqA qCgq8hAdVBBCZBEJkTUsIQsJWcnCJXfv7qr5IzfJTXKT3JuE8f1+j+93/7ndVV+fqq5z6pxTpwnn HDdwAzfw24H+1gLcwA38f8cNJbyBG/iNIV4nXtXuZA4XszlUh5NzzmSFcw5wKmoIAZU0gskgGPTU oCWC0AIP55w5XdzhVh1O5nAxtwxKAA4GqtVQnZbqJKrXUb2WEHKdxtIUFqvzQMalu27p1U4eq10+ dOLy+OGJ/0bZb+D/HDpGCRWL1XEu15Vz2ZmZK5dVunOKnBcLWFkVc7o5kzlUDpUDgGexUYiEamjn YG23GCkhWooJ1yZE63ol6HonEEnjOJPjPJ/nzr7sLi535xQ684pYSSXjMiAQQkAIZwxQAUYhQtQI kaHa+GgpPlKKCZcSonQ9E7Q94qTocKrRdMjomkKgdO7aY1TQTxzZtdEtd/lVR14hkRo8miuKqU+S oNc1avzyu0fLK20TRiT6/+jMnMq8omuC0IoLwzkkDf3976I1rbX00OZW5RVcI2LTxlwSaVwXY9dI s07bYSb7dHbFsZMl0AhcZTGR5vEpcW2myi+2XKmyU0ooJQO6R1Dauj1TGT94vMhmVwlFTUpkSJ/w iFB9C9LmF1VT/2YSAOd8YI+wmAgTY/zIqQK7Uw4J0nGOvt0izlws7Z0YYTJI3u3bPq2qzW5Nz7Qe PG5N+9V5OlsprWCKi8HGoQBERDA1mfXJPcXYCLFzsBQWTE16CAJkRbU5lGqbWmGx/fSr7fAvtsOc QwVECoMQZASl6tVKGVUEooggKbGrcUB3cWKENi5SCA8RTHoiCMzlVm0OJb/UVVSmXC5znMq2Hjyq HLwKMAqjABM1GbQ94wzJvU23JJtuHqxLiiG0Ix1vUaTVdnXW4v1HP53aJdTgfYvbHHn3z3UXFFKq 9UyUYjNNuKXXtjcakfxwpGDN+mOPTRsQ0KPXbj21btNJmKRW2qksqJMud+dDoUFaf2jXbDn53uZm aAnRSzQx0jQuJebRyb2Te4cHJLBPPPvGoR9350IvQmGdIo1ZXz0QHmJovZsvLN/06/ufnIFJIm51 7qwhi2YNbbWL3Sk/8OKekhI7RArGwfn21XfcO6ZZU7jyo+MbPzsLo382nQNueeOrtz46qS+AkivV 2/acnnZ38rINqS/9ZezCd/a8t3BK/+5dvHsErITM6bqWml61fV/17p/decWM2wkogcChcEBjjjak 9Ot0+wjjiIH6XglicBARfXibyjVr0SvvV+91Uehq41LOocjXigFRl5AUcc/DxlGDjcP6S1Gdqbal Bcc5Vy1WR1a+9dDx6r1HrfvSlepybnXYM67aMjLKN3whGIJ0Q3oF3zkq+N4xht5JgY63ORh0wtnM 8llL07a/cbu3J6yNj+q65oWLk2dzxU4gMLjEkPDElXMEQ4NtsOiK7S+L9sPNNGKgnigHB1pNaTME lPbmvHlazh0ONfNiVWZm+QdfnXt++sDFTwxrj/N/JrsiLaMEZgmUQoKl1L49NXfmff3axiarXHYx SAwqlq47NrhX2H1jWn/LnMEzXg7wVufKvzmvbVtHSCkZN6L7+byy4YO6xnTptDP1bESoUVVZox4B KKHrcmn55m+qPvvOeSqLwUmhJRAEGBhcHNyYMiT0oTuDJ92iTYhp4f0wh6tkzZby97505eZQ6Os0 kMFBJVPo5AkhfxgfPHGkYGpoFzlc5ZXa8NCmhIQQMdhsHtrPPLRf1DMPO3MvV/1vauVH39p+PUmg oZCY3W776RfrT4dLFr1nHHtT+MwpIXeP9mkaAoZRs2NX9opBx//7j8nel0PuGR017/GiJW8J0ANC /PqX9X0aWFlVZY+/mpafa4E2YDEIIaAErTpdlPjjmDVLy+FZR4Sg5pogQBLsLnXJW79Yncqq50cG KnkdvvwxR7a46nddgi9257RZCSkhEDzCq2515qK0XvHBfRN9LJUGvajXeDlaNin+znkNOEDrbZRb VjjgcMlxkZ0Kii1JsaGMNdZmv5TQXVpRtvbzio3bXYUFBCKFJMAEgENhcJuG39Tl2YdD7r2ValvZ r20Z5/KfW16d9jOFhsJYK7ObA8FTJkb+dbp5+MDm+lbu3F+962Dcoqf0fRNaeIQuMTbquWkRs/6j cuv3JSs3O06fodBT6FCzh+/ae21XmmlkcsTsh8Pun+DP2FsCASRx/tqjw/pFjBkS430n+uXHrIdP Xv3x26hnZof9YVyjfss3H9/5XQ4MGtjc7RXApcKpoOnykJlFIG0/AyYAIeAcLgUKg05ETbgoUhik 1ZtOjk+JvXNkfBuIZYVt25cHjZf10YoHjpdeuFTVMz6kreLWQhLKS23T5+/b/fZdwUGNI/A2w+aQ YXHCewczaiBSz95IAIcCt+q5xQG37JI9f4PN+hlThoUE6Z99ZCQ4ANLJ3DhAaF0Jyzd/U7RonTMn m0Ir1GoOAA4nDQqOnjcj8pmHWvYYa1C5be+lWQvliiveJAx2qWtczPLnOj94R0udCSKmjCt5Yc3Z 1GldV77Y+ZG7Wn6WYNCF/2lyyJTbipa8X7b6Y664CSQCgcAAcOvBdOvBjIoPR8csedqY3L4Mp0hc dmXmK2lpH0yK7Fw/LqqV4t+ZS/9mjl38RKMee9MLF6w9Cp3oQ3MChUsdNSz69uGxahPjyhk36EWD rk0xv0O5Z0Li7Af7qwyFZdYzOVUffZt1pdTu2bcpgcJWfXJq4s1d2+CUnsmpzMy+Co1XiE6Js8q1 PTXvf6a3WwkBGDTpvxTPfuPQ5sW3dgAbAOA/J/bsGRtCJQEAARjHpp0X8i9f8xgmmd01LiGlXxe1 xuZxMJWl9I+s6SsINDzUCCAyzNwcf0svSS6/mv/M65VbdhDQmq2vDgw2fZ8+8RsXmVP8yitc+cfX l2YthKJ4a6AKm2lkStKHS3TdYltlEILNYX+eXPzm33P/ONeZczlm3oxWXUqxk6nriudMo5LzZyyU yysoaiwQodAD3PLPH60HjnV5dnrMosf9GUKz0IlZFyofeGnPzpUTg7wSG/qe8T23vt6orcOlzF1z RHGq0HdEptGp3DY05uUZQzqAyhsKS4oNGueVsXxscu+pc344l10FSQAAnbg/oyQzt6pfUiteX1Ok ZRSpVjcMDZ0mkW79IWfOw4NEH+nZwGGSPtp2dmCP0BceGdwBbMDk0UmTRzeIM9MyivNzr3o2Q1l9 cELitDv7tJm/2TE7LxZk3fFkxZZtFDqCBhsog904JLnHrrf91MCqr9MuzVoIRSWoX6MqbEHjx/TY +ZY/GliDoNuGCQgmEIoWrsp5dIGfvUInj+n29VuaLuEc3r4foTCya47CxW/lPfkaZ41j5cBg0KSl 5q/85ETLrRjj0xfsPXqsuGM0EACBs84L6kAQyEqDCembFLp09jCQ+kBRtsvHz5cHSmypdr39+Rk0 1TSJnrxQcTSzrO0ye4MAkvjSqp83fn22YwgbgjGuqKzekSGwO5X2EPpWQldBycXJz9qOZQgwo6Hb xOHWxid0+/INbXyUbxEV1XWlqu6vM/vypVmLocgE9caPwWlMTu726WuakCD/ZdX1TRIMRoAKMFR+ 8lXhkg/87GgeMTDxk2VEq+WQva8TiAJ0Zes+zJu51H8xfMMorfjH8bSMohaaLN/86xc7sqC/XqeX 1xUTUuJiYky1x72AS8ktqg6UZOdPly6cq/RspwDqvGhC1Gr39n25HSUtBCLLfM6bP1/Iv9phnNcN PpSQueW86QvtmWdoQxcUAMAhCF3XzdMmRDfHSAjy/2tZ4dL3mcsNoHDe2+6SAu+9lEOlBnPChgWa sOCAZJUiQ4XoMEAFKIW2aP7ais++97Nvp9uGxa6eC5E2yTRTAcYrG7YULdsUkDCNIRC7TZ6xOLWs 0u7z/v5jhYveToe2I0LB3wIGvRARovMoIQCONngP3x++XDf9BNB4R4aSsG1vrs0h++wYABj3PEIr VFU4pr7wfWGZtb2c1xk+lLBs3ZeWfamCDw0EgyP43vHBE1tKTxNBgNNd8PKS82NnFS/bZNmx3zsO 9JBMGtuWjAil1Gyo1SKBcDX/qWWOrHw/e3d5fKp51DAGV1ORKbTFi9bZT2UFLJI3dGLW+cqnXz/Q 9MOUkgr7nxemupwKAj4VbAX031XwVmlxXSqxQ/Dk9CEJMeGBHa+7ZOXwqVLPNsi5TifMe2yQXit4 3qdGyMm17Dt6uV1ScphMmvpTP514+njZgvXp7eK8/mishIrFWrZqC4XPbCcnVBf+1P2tkhqG9KHQ WQ+nX35xBXe6vJ/CoWo6R0UvblMuhHHurFchAq1cUVIwe4X/EZ15fAqHD/edQFSdltLVn7ZFKm8Y NJ/vyFq95aT3Nc7508sP5GRVoePKvuogK6rLrTib/lyyrHRkuLj1h+zKMhtqSrc4Jzqxf7fAkpmb d57PuVhVl1HsHhM0Z9rgnl2DUJPNJ4Cbbdub1y4p7fKsKX0mjoqDrXZHNUsbPs9c/1Vmu2ivMxov C+vhk+5LBd7xWx04FCkhwZTSv1VS06hBFAbi0b0GpprBGTZprL5H45JLf6BesynFFUB9UlSAwfLd 3sov9oQ94Nehn3nCcGFhJ8hyU+tDobN8naZYrGInHy5A6+AchIAQaMWXVh+5qW/475M9HvubH5/4 8pssGGvtGkeHeaRGadPOc7sO5jY5oQBzyFMndl/6VJuO1DkkTYPM88603AXvpEOgHsnd6oAB4YN7 BVC/Jivs759nctSOXWaTRsebDNKE4bEnMmq3R52w61DBlauO8OBmyzhbgcrCQ/TvzRswNPNKSZkd kgBCINA5rx/slxQyarDvLMZvjsZr0XH8PIPD5zLhULSJ0U2rkJvCPCpZ37cHh7sJD6fQBN0+om2y Oi4WsGo7acBJAFLy6kbmaOpk+oAuIVrQ67mvAiQCqlZaHGey2yAYISCUeA5zReJ0KDNfSSutsANI yyiav/YoJMEjNeMdGRNSUl7pPnPecvbCtUa/8+cs+aW2NtJKwokL5R//89yHO88uXH/0zqe/nfz8 7ooqZ31WU2FP3d9PKwVQ7nP4ZPHp8xUeX4BxwaS5d0wCgIkj42AUPQ6kSEsLq3e0Lz1jcyixXUzr /3YLpcQTwYrUZpUfnb+vqLytE3Kd0VgJudUBNOvdET8O5QFQrRTy0O3Mh+PHhOBQ083NlsW0DNfJ LKbaGik2hdZ+8lTVjlR/GIgoeL6E8gXOVLUy4IwfOBcomT9jcGJsEGoy+zrxXGb586sOlVbYnnjt gMMm1/pgalKc+b6x8XB1nKMoEEgCJNrkJ2jafOamFfYdKXpk7t5HX9q3aNWRXXsvccbrj9et7rsn dpt+T2Ah/dbdOdyh1G2Dg3qGDu7VGcCIAVF9u4VCrl1yAl3x0YnqdhYSAZNGJ85/8ibUpXl0YnZW 1WOLUt3ydTjRaTcavyfSyezt7zWGy9/kVcgDE0RtCEeDMXOoUmK0FNXGMnzb8Qs1n2g0vEw4FMuu g/4wMLfMVdacO0ioIIQ2W9bQLDgUtzp2aOysqX1gr50fo2bLdzlT/vp9Zu7VOvMPlb/74qhRg6Ph atexUsOn134o1uTXtEYxAAgUGhGSCJMEvQhKwAGZ4ZqrV9+wd1/6vRRI8a1LVvemF9WfTLiVsUNj RIEC0GmFUYO71Nd8ifRCfnVmblUzTAHgxT8lj78tHo7aqTZovtuTu2HHdTk5bCcaK6Hhd71qCkqa NiUQXZeKmdMvK6XvHhc6/S4Gh/dFDlWKCid+f5flDeZyV+9Lp2j6YQ6n0FbvS1etDh/dGsJ1sYA5 HMS3s82EkCB93wA+7fOG1S4//WD/m1KiPXpICDgOpZcCtSpvl5/8V3vXHhZVtcXX3uc17wHkKZBg YGW+MkQrTCWptNKsa9fSXlqWZqn3Vt6bZlpmafnd3mVlZl1vflH2kdrDVBSETHxnxkMBlYe8YWaY OXMee98/ZoARxmEGwfyD33f+YPjm7LPg7L3PWr/1W+s8ODht1BWWi97mPcEyWNB4OXgN5i9GfaIQ 8MxHUxA4HB2hW/jE8MyPJ0WHBRY27zlYUXCqwa0XpYD0/J2j20iBtJExwLdwpAiBQz74Z8AygI7g OWbtC2NMIYLb70AAAvvvt/cfKagx6vxy6C4Z2hMzhlGDhcR4sajQJXr2BALWWXzGduCEKcUvNVDf l2Y3bcmSKytbhTIUVDY2vGuGNm7bKxYUnk/bIgoKBQkBVsqqbHl/mMcl+R7E8lOuqlgukH0RTXem sEEBiAc8IStEp+E2LB83Ztb3tXUOdxDYuvc3yyk3xby54AZwFQ11F5rlh+4fuPD+a0mHTZOotE9Q Fyv0QKX9YkzNolxb63A70pKaNDRs29sTO4qP/cHXv5yiDhX07qGGDztP73732PiYGGNZuQ04DAiA oh9zz8yd2sWiCk/ER5u+fDV1xqKdVocKLAIWN9WLDy/d/f1btwUU0PY02m+WjF4bueghCqq3hyEi xFG79ls/h+b7hkW/uYAC9QgyqT+8TkdQRa1esxHgPE+SglMzMCF65bN8fD+JVtsPdu5pWLb/hrzJ ZSkojGCKWDi9C7Z5YmD/kPcXp6BWSsAFpxoVa1i/bJy221MUhESFGgYlhg9JjGh3DLs6MjayixsK iMrfb41/f9FNoLZwWDzOO1L9Q66/KVlPNFjEbTlnwWPSm/Xcxh8LNmzN37A1/4ut+Zu2F4UHC23T TWAy8ypKKixdNP58TLo5fv5DQ0BsCRO07LHjNbNX7JEV1d/SpJ6Hl2kR+sikxoyshi3bGGgfIGHQ NGz6wTLrbtNYv0TDoQ9MaP71eNV76xjQAyAArDQGznwA1HzynTV3HwZP5poSUCP+9UjYg3eEPjrp zKI1qr0Td7R8xTrb/sNeHVoCzujF8/RDB3TBtna4b3zC4cfqXn8/D3Q8IACVMixau2RMQqz54gfv CKVDhWg3gFJRIvelJXxxS9G2n4tBzwFCkqzOX5WTdE1Y4hWB6Zwy9pSeO2tpE+sJzK68yl25LdIZ 10LgWOBbngcMaq4Xv99dOv+BLhJ47bB41vBfj1Xt3H3anSXSstv3loGborss4CVsQAyO+2ypYUSy Cu0XDAJMFal09itSRY2fF4h9Y37w5Ikq2AAAASOdOReoifbjJytXfoLOp4sI2IMmpoU+MAEA+Mg+ CRtWRjw9zccgdd/sqHjxHUxxx6yJCrbQB6f2XTwzUMMuhFfmjLh9fLy7VlCUlz6VdNfNcd01+KWB a22vnj/S2Efjpnx5pqayee7rezuWTfnGVz+fau9UIeRmfXgWOBa4DlI+jL/afvKiiCUPaHj206Vj YuPMbaQ0x3Rnouii4T1250KDEjL+Y0odo4K1XcYCgeAsKjg19XnpXJ1fF9Dw8euXm9NSVbAiYJx/ lgb0MLTuO15425NyWYVnBQaBZi4qNm7tvz05Hh9a8Iat2adnLkUA7YhfCooK9rBZ0+PWLe3GJjQs gz95cUzCgBCodUy5I+GFR4d318iXGAPjQ5bMHg6i4l5Fem7H7tOrvzji/wiFpxuzDlVCa1kjBTd5 S84/XL9sXXQ8Pnii9lC+vxt9p4iLMn22bCzHY1Aux1bXF5x5fFRo4vdvRzwzi4BKQDz/HL0td1/R HU81H/VLbMkGG69MfyP43kkERKnyrGVXnp/G1WfsPjX5abninKf+W4Vm/sr4uC9X8DERPs5tRdVH 6cXTniNW2/kyIErAjvRC1OJ58Z8uxVw3R2sx4YaPltx8/cjId58fzXaJDfYTPS0dnT9t8JS7EqG1 VIdnX/4gb9/v/roz6TtPiY1OD8ePChpG0Ho5eA3TRkNgpFikjD3dV1QBMH5k7Kp/jAJZCaz3ziWB r8nH6LX93n7elJpcsfzDlpYtnMudw6C3HzpWdOsTUS/PDX/snk6zDqzZcOVXr5Uv61f5+vu1H28O uaeTqmfFYqt8bX3Vms9Blj14WqJCs2FkcvyGFdqrOu+tIBaXly/7sP7LDASMx4OUujTcxvEp0Sue 9rMksgu4JTkmc/2UnmbDe9qrEnj2tXkjf8g+43SqwGBgkdisPPlqdtank02ddXyTZHXT9mJonRsO 5bZx/d5ckNxx40AAikrnrsrN+a3C/djkmfQdJS/MvL4b2ayF04ceyK/5X3p+573qLi06/wuDJ481 pY2qXvtN7UffiIVFAIBBAMAYdEp13ZknX2pM/yXiuYfNt97oe1fGHBv76jzTLckVK9bV/pQTert3 WSNR1Pqvt59b9Zn92O8YtC2LhxJwIsSGz34oZtUC1qz3em4rnBU1dV9srX5ro1RVzoDONVcpEApO AKxLGhKxYHqf+yeiHg7NezwfpeXSdxafKK4nHXZ3SqjJwK9dMtZw0eWLV/ULmnPftW99fMg9d7Xs 0SNViz/c/+5zKb5PzD167o/Cek9edGpa/0EJF5RqTJ+QmPNrufsDxxScbMg+XHHrqK7IjC+EDxeN /vNU4+EjVe1L+/9S+LXNMDpN1MIZYTPvrk//pW5Dhn3fH6pixcABcBgYy8691p37DeNGhD462Xz7 jVyYL3G9OTXZOOZ6ucaLJMJZXtWYkVW/6Udb9gEA0prNo6BQUHTDB/ddPif4zpt9DE4k2X6koD59 e8NXPzvLz2DgGdBRoBScFFSGNxpGjwh78m/Bd47BmstrL+wiOHyypOlkQb0Xr1RR2SDtO88TQ1e1 0J546fHrt2WfLjrZ6G4zo+Pe++/vqUl9p4zz1VwwfUcxtcvupUsoY+BuGOwrgpiSGr/kg7z6Bicw yNXD6ttdJd27CE0G4fPlY1Mf31JXL8JlkyoM4FnPmg3hj00JmznZduBE45Y9TVuynfklqtMGQABk S2a2NTOHC4/Spww1pd1gSBmmiY9m9F6mAGYYITLU9bNqbRaLy21ZhyyZ+227DshNVa4eMB7eI+Hi oyOeezh8zlTszfkiDqdUVWs/mG/be9i6+6B4/KSqWBFwGFgCEoDCCEbdkIFBU8aZJqQYhl1s4/rL CxSAxV66RQCAgvVatrsixiCjsHr+qCnzf3IXi2AEMjyzOmfEteEx4d7VM/VN4ubMkjZKRlTuvS3x 6jhfG3RkiG7CjTEbvy1wt9kV2G3ZZxssYnD39U0DgCGJoR8sHj3t2V8ooZdJliJghxthbEweZEwe FP3ibEdBiS33qC3nmONYkVRwmoiis/q0Y3N+3ebNLASxEWHaa/szkX2EvmFMeDDTx4wQpoSodY1q TZOzrEopr3H8Xqg01ipgwSAwYObDYqkoqVabCs0ABAEDgDEnNGcdOX24kDMbkVYAhEBVVatdqm1Q axudRWfks1WqYiVgQ8AA8AwYsEbgr47TDU003DTUcOMw7VVx3dNo1AOKSkAhgJGrhbP/OhhCKCjE zfsrJFDGX/U83Zd9RO70Oxca1ptVd4+Nnz55wMZNJ9yOHIvKTjY8sTIrY83tXpmnjD0l50otrh7b QAAE5p8zhnbaCvXe1P4bvytwm4GgvKQxY0/pI3dd7b/l/iQ27ktLODK77rV380DDBnr7XFDUlotS fy/qA12PejHP6QcP0A8eEPHEVCLJYkmZdKpcLCiVK2udZ6vl0nJndUPz/j+o3UmJTAEhzABCCCOq EACKQ0xseLB+5GDuiki+b5jmmji+f4z2qji1weI4Uew4USyVnZPP1khnK6WKuqbvMqlTIiDTlnwJ AoSAQZhHWh5HhmoiEoUr+nKxYXxMhGZgf+HKGE3/GMz3lN+PAEJMGnOwhHgMhFJKBc7fRa7TsOYQ DTIKAEA5bAowbjTqOHMfDaPv5CyqkKAgjf8bvUnPm4M1yMC3WOXlX7dybnLeseqqOof7lRVmIeu3 8k0/F86Y2H6RUAq78irMQQLScQBAnWrS0PCkazpXLI4fFXPddZHFpU2IwwBA7XLO0Qrfi9Co49os Z5HOvyZay2Yn/VnckPlrGeIYCOT2AQBCEGzkzSEaLLBAgUiMtmutJVsH7KGXhFJCiCSDrFCVUFkh DpGqhAIwgoA1HMIYeBZxXKe5AaooRFJAVogkK002IkmAEQACQjDPsyY95nngGcRzmO2pN0x5haVZ UlTqmuQUwKjj/CwdEp2KXVRdjiKloBGYgLqD2kVFlNTO/UwKGIHJIPjpkdpFRXS2WaUVvE8sz68B ACEUMyjYm6C0weqkLbWTlFK9lvNTrulwKg5RcXU0dbnbJoMvwWo7y3Uaxs8X1xBCG61O14UMft8+ F6x2SVba7r5ew16MGLWnFmEvetELP9H7ktBe9OIvRu8i7EUv/mL0LsJe9OIvxv8Bmb/ImYm4WqUA AAAASUVORK5CYIIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8A6AOaBwAAAQDpAygAAACAFgAA4BAA AOAQAACAFgAABQAAAAoAAAAFAAAAAAAAAAEAAAAAAAABDwDyA64BAAAvAMgPDAAAADAA0g8EAAAA AQAAAA8A1QfkAAAAAAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAFgxvAB8 2hIAZNoSAHbHCzAIAAAAAAAAAHzaEgAo3Q0wAAAEABAAtw9EAAAAQQByAGkAYQBsAAAATgBlAHcA IABSAG8AbQBhAG4AAABYMbwAfNoSAGTaEgB2xwswCAAAAAAAAAB82hIAKN0NMABYBiIgALcPRAAA AEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAAG0AYQBuAAAAWDG8AHzaEgBk2hIAdscLMAgAAAAAAAAA fNoSACjdDTAAWAYxAACkDwoAAACAAGAAAAD/////AAClDwwAAAAAAAAILgAAAAcAAAAAAKkPCgAA AAcAAAACAAkIAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAcA AAD//+8AAAAAAP///////xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMA AAAAAAUAAIAEgAQAAAAADwALBIACAAAPAADweAIAAAAABvC4AQAAAtwAADYAAADzAAAACgAAAAEA AAAOAAAACgAAAE4AAAAAAAAAOAAAAAAAAAC3AAAAAwAAABAAAAAKAAAACAAAAAMAAAAEAAAAAAAA ACQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAA8AAAAAAAAABAAAAAAAAAApAAAAAAAAAAQAAAAAAAAA BAAAAAAAAABNAAAAAAAAAAQAAAAAAAAADwAAAAAAAAAEAAAAAAAAABMAAAAAAAAABAAAAAAAAAAm AAAAAAAAAAQAAAAAAAAAMQAAAAAAAAAEAAAAAAAAADIAAAAAAAAABAAAAAAAAABBAAAAAAAAAA8A AAAAAAAABAAAAAAAAAAiAAAAAAAAABsAAAAAAAAAGwAAAAAAAAAbAAAAAAAAABcAAAAAAAAAFwAA AAAAAAATAAAAAAAAAA8AAAAAAAAABAAAAAAAAAAhAAAABAAAAHYAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAANwAAAAUAAAAqAAAABwAAAC0AAAAI AAAAdwAAAAYAAAAsAAAAAgAAAHcAAAAvAAHwWAAAAGIAB/AkAAAABgaCa1PLzZOx2N6xZPG/r8AH /wCGfgAAAQAAAAAAAAAAAMsAYgAH8CQAAAAGBhdqC0zMZK58+7s2ZzErAez/ALgeAAABAAAAhn4A AAAAywBjAAvwJAAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACDAAGvEMAAAA mf+ZAAD/AAAAzGYAQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAIAAAAE AAAAAAAAAAAAAIAAAAAADwDQB3sBAAAfABQEHAAAAAAAFQQUAAAAuh117ADKmjsyTs3JAMqaOwEB AAEPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABDAAAAZAAAAEMAAABkAAAAdscLMAgAAAAAAAAA cNoSAAAAAAAAAAAArP///wr///8BAAAAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAf AAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAAGDzDTAs3hIAAAAAAEQyvAAAAAAAAAAAAAAA AAAAAAAAAAESAB8AEwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAAYPMNMCzeEgAAAAAARDK8 AAAAAAAAAAAAAAAAAAAAAAAAARIAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAB8ACAQ8AAAA AAD9AzQAAABCAAAAZAAAAEIAAABkAAAAnNoSANn0DTAs3hIAAQAAAAAAAAAAAAAAAAAAAAAAAAAA ABIADwDwD1EBAAAAAPMDFAAAAAYAAAAEAAAAAgAAAAMBAAAAAAAAAACfDwQAAAAGAAAAAACoDxkA AABXZWJEQVYgQmluZGluZ3MgUHJvcGVydHkgAAChDxwAAAAaAAAAAAAAAAAAGQAAAAAAAAABAAAA AAACABQAAACqDxYAAAAZAAAAAAAAAAEAAAAHAAAAAAAJBAAAEACfDwQAAAAFAAAAAACqDwoAAAAB AAAAAQAAAAAAAADzAxQAAAApAAAABAAAAAAAAAAeAQAAAAAAAAAA8wMUAAAAMgAAAAQAAAAAAAAA HwEAAAAAAAAAAPMDFAAAADQAAAAEAAAAAAAAACIBAAAAAAAAAADzAxQAAAAzAAAABAAAAAAAAAAg AQAAAAAAAAAA8wMUAAAANQAAAAQAAAAAAAAAIQEAAAAAAAAAAPMDFAAAADYAAAAEAAAAAAAAACMB AAAAAAAALwDwDxwAAAAAAPMDFAAAAAgAAAAAAAAAAAAAAAABAAAAAAAAAADqAwAAAAAPAPgD5goA AAIA7wMYAAAAAQAAAAECBwkIAAAAAAAAAAAAAAAAAAAAYADwByAAAAAAAP8A////AAAAAAD//wAA /5kAAAD//wD/AAAAlpaWAGAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgBg APAHIAAAAP///wAAAAAAMzMzAAAAAADd3d0AgICAAE1NTQDq6uoAYADwByAAAAD//8wAAAAAAGZm MwCAgAAAM5kzAIAAAAAAM8wA/8xmAGAA8AcgAAAA////AAAAAACAgIAAAAAAAP/MZgAAAP8AzADM AMDAwABgAPAHIAAAAP///wAAAAAAgICAAAAAAADAwMAAAGb/AP8AAAAAmQAAYADwByAAAAD///8A AAAAAICAgAAAAAAAM5n/AJn/zADMAMwAsrKyAAAAow8+AAAAAQD//T8AAAAiIAAAZAAAAAAAAQBk AAAAAAAAAAAAQAIAAAAABwAAAP//7wAAAAAA////////LAAAAAADAAAQAKMPfAAAAAUA//0/AAEA IiAAAGQAAAAAAAAAZAAUAAAA2AAAAEACAAAAAAcAAAD//+8AAAAAAP///////yAAAAAAAQAAgAUA ABMg1AEgAQAAAgAcAIAFAAAiINACQAIAAAIAGACABQAAEyDwA2ADAAACABQAgAUAALsAEAWABAAA AAAgAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAeAAAAAAAAAEACAAAAAAcAAAD//+8AAAAA AP///////wwAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAE gAQAAAAAUACjD1IAAAAFAAAAAQkAAAAAAQAAAAAAAAABAAEJAAAAAAEAIAEAAAAAAgABCQAAAAAB AEACAAAAAAMAAQkAAAAAAQBgAwAAAAAEAAEJAAAAAAEAgAQAAAAAYACjDwwAAAABAAAAAAAAAAAA AABwAKMPPgAAAAUAAAAAAAAAAAACABwAAQAAAAAAAAACABgAAgAAAAAAAAACABQAAwAAAAAAAAAC ABIABAAAAAAAAAACABIAgACjDz4AAAAFAAAAAAAAAAAAAgAYAAEAAAAAAAAAAgAUAAIAAAAAAAAA AgASAAMAAAAAAAAAAgAQAAQAAAAAAAAAAgAQAA8ADAQgBwAADwAC8BgHAAAQAAjwCAAAAAgAAAAN BAAADwAD8LAGAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUA AAAPAATwwAAAALIECvAIAAAABwQAAAAKAABzAAvwigAAAH8AgACAAARBAQAAAAXBYAAAAAYBAQAA AMABAAAACMsBakoAAP8BCAAIAEQAOgBcAE0ARQBSAEEATgBUAFwASgBPAEIAUwBcAEMAbwByAHAA XABFAGcAaQBsAGkAdAB5AF8AVAByAGQAcwBoAHcAXABiAGsAZwAxAGEAcgByAHcALgBwAG4AZwAA ABMAIvEGAAAAvwMABAAEAAAQ8AgAAAAAAAAAgBbgEA8ABPCuAAAAAgAK8AgAAAAIBAAAAAoAAMMA C/B4AAAAQgEEAAAAQwEBAAAARAEEAAAARcEQAAAARsEaAAAAfwEBAAEAgAEAAAAAgQEAAAAAgwH/ //8AvwEQABAA/wEQABgAiAMAAAAABAAEAPD/BAABAAAAAAAAAAEABAABAAoADAACAABAAKwBAACs AQAArAEAAKwBYACAEwAi8QYAAAC/AwAEAAQAABDwCAAAANoPPgdCB9sPDwAE8K4AAAACAArwCAAA AAkEAAAACgAAwwAL8HgAAABCAQEAAABDAQQAAABEAQQAAABFwRAAAABGwRoAAAB/AQEAAQCAAQAA AACBAQAAAACDAf///wC/ARAAEAD/ARAAGACIAwAAAAAEAAQA8P8BAAAAAAAEAAEABAABAAAACgAM AAIAAEAArAEAAKwBAACsAQAArAFgAIATACLxBgAAAL8DAAQABAAAEPAIAAAAYA8yBzMHZA8PAATw +gAAABIACvAIAAAACgQAAAAKAADzAAvwWgAAAH8AAQABAIAAtGe8AIEAq2cBAIIA1rMAAIMAq2cB AIQA1rMAAIcAAQAAAL8AEAAfAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACD8C AAACAAAAEPAIAAAAkACQACAWkAMPABHwEAAAAAAAwwsIAAAAAAAAAAEAvAAPAA3wWAAAAAAAnw8E AAAAAAAAAAAAqA8gAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGl0bGUgc3R5bGUAAKIPBgAAACEA AAAAAAAAqg8OAAAAIQAAAAcAAAAAAAkEAAAPAATwPgEAABIACvAIAAAACwQAAAAKAADjAAvwVAAA AH8AAQABAIAAZGq8AIEAq2cBAIIA1rMAAIMAq2cBAIQA1rMAAL8AEAAfAIEBBAAACIMBAAAACL8B AQARAMABAQAACP8BAQAJAAECAgAACD8CAAACAAAAEPAIAAAAKQSEAX4V0Q0PABHwEAAAAAAAwwsI AAAAAQAAAAIAvAAPAA3wogAAAAAAnw8EAAAAAQAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0 ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIExldmVsDVRoaXJkIExldmVsDUZvdXJ0aCBMZXZlbA1GaWZ0 aCBMZXZlbAAAog8eAAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDw4AAABTAAAA BwAAAAAACQQAAA8ABPC4AAAAsgQK8AgAAAAMBAAAAAoAAEMAC/CCAAAAfwCAAIAABEECAAAABcFq AAAABgEBAAAAQwA6AFwAXwBKAG8AYgBzACAAaQBuACAAUAByAG8AZwByAGUAcwBzAFwAQwBvAHIA cABvAHIAYQB0AGUAIABQAG8AdwBlAHIAUABvAGkAbgB0AFwATQBFAFIAQQBOAFQALgB0AGkAZgAA ABMAIvEGAAAAvwMABAAEAAAQ8AgAAAAYEEkRQBa4EA8ABPA8AQAAogwK8AgAAAANBAAAAAoAAOMA C/BUAAAAgACAb7wAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAIywGcMQAA0gEAAAAA0wEA AAAA1AEAAAAA1QEAAAAA/wEAAAgAAQICAAAIPwIAAAIAEwAi8QYAAAC/AwAEAAQAABDwCAAAACEQ AABzBrsQDwAN8KoAAAAAAJ8PBAAAAAQAAAAAAKAPRAAAAFYAZQByACAAMQAgAE4AbwB2ADIAOQAs ACAAMgAwADAAMQAgACAAIAAgACAAIAAgACAAIABTAGwAaQBkAGUAIAAjACoAAAChDxwAAAAjAAAA AAAAIAoAMgACACMAAAABAAMAAQABAAoAAADYDwQAAAAhAAAAAACqDxoAAAADAAAABwAAAAMACQQA ACAAAAAGAAAACQQAAA8ABPBIAAAAEgAK8AgAAAABBAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAI kwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAA AAAAAMyZADMzzADMzP8AsrKyACAAug8cAAAARABlAGYAYQB1AGwAdAAgAEQAZQBzAGkAZwBuAA8A 8APaBQAAAQDxAwgAAAAAAACAAAAOMA8ADASaBQAADwAC8JIFAACgAAjwCAAAAAcAAAAHGAAADwAD 8CoFAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAABgAAAUAAAAPAATw 0AAAABIACvAIAAAAAhgAAAAKAACDAAvwMAAAAH8AAQAFAIAAIGKLAYEBBAAACIMBAAAACL8BAQAR AMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAAAAAAFAHIAEPABHwEAAAAAAAwwsIAAAAAAAAAAoC iwEPAA3wWAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFAAAAAIAAAAAAAAAAAACAAAAAAAC AAwAAAD5DwQAAAAAAAAAAACqDxIAAAABAAAAAQAAAAAAAQAAAAAAAAAPAATw0gAAABIACvAIAAAA AxgAAAAKAACDAAvwMAAAAH8AAQAFAIAAeGaLAYEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJ AAECAgAACAAAEPAIAAAAAACQCeAQIAEPABHwEAAAAAAAwwsIAAAAAQAAAAcAiwEPAA3wWgAAAAAA nw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFgAAAAIAAAAAAAAIAAACAAIAAAAAAAIADAAAAPgPBAAA AAAAAAAAAKoPEgAAAAEAAAABAAAAAAABAAAAAAAAAA8ABPBkAAAAEgAK8AgAAAAEGAAAAAoAAGMA C/AkAAAAfwAEAAQAhwABAAAAfwEAAAEAvwERABEA/wEIAAkAPwIBAAEAAAAQ8AgAAACwAdACEA4g Cg8AEfAQAAAAAADDCwgAAAACAAAABQCLAQ8ABPAWAQAAEgAK8AgAAAAFGAAAAAoAAIMAC/AwAAAA fwABAAUAgABIaosBgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAACw CkACoA7QFA8AEfAQAAAAAADDCwgAAAADAAAABgKLAQ8ADfCeAAAAAACfDwQAAAACAAAAAACoD1IA AABDbGljayB0byBlZGl0IE1hc3RlciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2ZWwNVGhpcmQgbGV2 ZWwNRm91cnRoIGxldmVsDUZpZnRoIGxldmVsAACiDx4AAAAhAAAAAAANAAAAAQAMAAAAAgANAAAA AwAMAAAABAAAAKoPCgAAAFMAAAABAAAAAAAPAATw1gAAABIACvAIAAAABhgAAAAKAACTAAvwNgAA AH8AAQAFAIAA1G2LAYcAAgAAAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAA EPAIAAAAYBUAAFAHgBYPABHwEAAAAAAAwwsIAAAABAAAAAkCiwEPAA3wWAAAAAAAnw8EAAAABAAA AAAAoA8CAAAAKgAAAKEPFAAAAAIAAAAAAAAAAAACAAAAAAACAAwAAAD6DwQAAAAAAAAAAACqDxIA AAABAAAAAQAAAAAAAQAAAAAAAAAPAATw2AAAABIACvAIAAAABxgAAAAKAACTAAvwNgAAAH8AAQAF AIAANHOLAYcAAgAAAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAA YBWQCeAQgBYPABHwEAAAAAAAwwsIAAAABQAAAAgCiwEPAA3wWgAAAAAAnw8EAAAABAAAAAAAoA8C AAAAKgAAAKEPFgAAAAIAAAAAAAAIAAACAAIAAAAAAAIADAAAANgPBAAAAAAAAAAAAKoPEgAAAAEA AAABAAAAAAABAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAABGAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEF AAAIkwHevWgAlAGOn4sAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICA gAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gOzSAAAAgDvAxgAAAAAAAAADxAAAAAAAAAAAACAAAEA AAcAAAAAAPkDEAAAAAAAAAAAAAAAAgABAAI0FAAPAAwES0gAAA8AAvBDSAAAMAAI8AgAAAAPAAAA DxQAAA8AA/DbRwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAUAAAF AAAADwAD8GhFAAAPAATwTAAAAAEACfAQAAAA3AUAAMQIAACwEwAADQ4AAAIACvAIAAAAAhQAAAEC AAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAEPAIAAAA/AG0BIgSRQcPAATwphsAAAIACvAIAAAAAxQA AAIKAADjCAvwdhsAAH8ACAAIAIEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAAAAAIgA AAAAAIkAAAAAAL8AAAAPAAgBAAABAAkBAAAAAAwB9AAAEA0BAAAAIA4BAAAAID8BAAAGAEIBKQYA AEMBHQIAAEQBBAAAAEXBCAwAAEbBFAwAAH8BAQABAIABAAAAAIEBwgAKAIIBAAABAIMB////AIQB AAABAIUBAAAAIIbBAAAAAIfBAAAAAIgBAAAAAIkBAAAAAIoBAAAAAIsBAAAAAIwBAAAAAI0BAAAA AI4BAAAAAI8BAAAAAJABAAAAAJEBAAAAAJIBAAAAAJMBAAAAAJQBAAAAAJUBAAAAAJYBAAAAAJfB AAAAAJgBAAAAAJkBAAAAAJoBAAAAAJsBAAAAAJwBAwAAQL8BHAAeAMABAAAAAMEBAAABAMMBAAAA IMQBAAAAAMXBAAAAAMbBAAAAAMcBAAAAAMgBAAAAAMkBAAAAAMoBAAAAAMsBNSUAAMwBAAAIAM0B AAAAAM4BAAAAAM/BAAAAANIBAQAAANMBAQAAANQBAQAAANUBAQAAANcBAgAAAP8BFgAeAAACAAAA AAECgICAAAICy8vLAAMCAAAAIAQCAAABAAUCOGMAAAYCOGMAAAcCAAAAAAgCAAAAAAkCAAABAAoC AAAAAAsCAAAAAAwCAAABAA0CAAAAAA4CAAAAAA8CAAEAABACAAAAABECAAAAAD8CAAADAIACAAAA AIECAAABAIICBQAAAIMCnDEAAIQCAAAAAIUC8PkGAIYCAAAAAIcC9wAAEIgCAAAAIL8CAQAPAMAC AAAAAMECAAAAAMICZAAAAMMCAAAAAMQCAAAAAMUCAAAAAMYCAAAAAMcCAAAAAMgCAAAAAMkCAAAA AMoCMHUAAMsC0BITAMwCMO3s/80CQFSJAM4CAIAAAM8CAID//9ACAAB5/9ECMgAAANICIE4AANMC UMMAANQCAAAAANUCECcAANYCcJQAANcCsDz//9gCAAAAANkCECcAANoCcJQAAP8CFgAfAAQDAQAA AEEDqCkBAEIDAAAAAEMDAwAAAEQDfL4BAEUDAAAAAH8DAAAPAIQDfL4BAIUDAAAAAIYDfL4BAIcD AAAAAIgDAAAAAAIDAgPw/xIDBgIYAwcCHwMIAiUDCgItAwsCNAMMAjsDDQJBAw8CSAMQAlADEQJX AxICXgMTAmUDFQJsAxUCcgMWAnoDFwKBAxcCiAMYAo8DGQKXAxkCngMbAqUDGwKsAxsCswMcArwD HALDAxwCygMdAtIDHQLZAx0C4AMdAucDHQLvAx0C9wMdAhQEHQIwBBwCTAQbAmgEGAKDBBUCnQQR ArgEDQLRBAgC6gQCAgIF/AEaBfYBMQXvAUcF6AFdBeABcQXXAYQFzwGWBcUBqQW7AbkFsQHJBaYB 2AWbAeUFkAHyBYQB/QV4AQcGbAEQBmABFwZTAR0GRQEiBjgBJgYrASgGHgEpBg8BKAYCASYG8wAi BuYAHQbZABcGzAAQBr4ABwayAP0FpgDyBZoA5QWOANgFgwDJBXgAuQVuAKkFZACWBVkAhAVRAHEF RwBdBT8ARwU2ADEFLwAaBSgAAgUiAOoEHADRBBcAuAQRAJ0EDQCDBAoAaAQGAEwEBAAwBAIAFAQB APcDAQDwAwEA6AMBAOEDAQDaAwEA0wMBAMwDAgDEAwIAvQMCALYDAgCvAwQApwMEAKADBQCZAwUA kgMGAIwDBgCFAwcAfQMHAHYDCABvAwoAaQMKAGIDCwBaAwwAUwMNAE0DDgBGAw4APwMQADkDEQAx AxIAKwMTACQDFAAdAxcAFwMYABADFwAKAxQAAgMTAPsCEgD0AhEA7gIQAOcCDgDfAg0A2AIMANEC CwDLAgsAxAIKAL0CCAC1AgcArgIHAKcCBgCgAgUAmAIFAJECBACKAgQAgwICAHwCAgB0AgIAbQIB AGYCAQBfAgEAVgIAAE8CAABIAgAAQQIAADkCAAAyAgAAFQIAAPgBAQDdAQQAwQEGAKUBCACLAQwA cAERAFcBFgA/ARsAJQEhAA8BKAD4AC4A4gA2AMwAPQC4AEYApQBQAJEAWQCAAGMAcABsAGAAdwBR AIIAQwCNADcAmQAsAKUAIQCxABkAvgASAMoADADYAAYA5QACAPIAAQABAQAADgEBABwBAgAqAQYA NwEMAEQBEgBRARkAXwEhAGsBLAB3ATcAgwFDAI8BUQCaAWAApgFwAK8BgAC6AZEAxAGlAM0BuADW AcwA3gHiAOcB+ADuAQ8B9QElAfsBPwEBAlcBBwJwAQwCiwEQAqUBEwLBARcC3QEZAvgBGwIVAhwC MgIdAjkCHAJBAhwCSAIcAk8CHAJWAhwCXQIcAmUCHAJsAhsCcwIbAnkCGwKAAhkCiAIZAo8CGAKW AhgCnQIXAqQCFwKsAhYCsgIVArkCFQLAAhMCxwISAs0CEgLVAhEC3AIQAuICDwLpAg0C8AIMAvYC CwL+AgoCBAMIAgsDBwISAwYCvQAQAb0AAwG+APcAwADrAMQA3wDJANMAzgDIANQAvQDbALEA4wCn AOwAnQD0AJIA/wCIAAoBfwAVAXYAIQFuAC4BZQA7AV0ASgFWAFgBTgBoAUcAdwFBAIcBOwCYATYA qQExALsBLQDNASkA3wElAPIBIwAFAiEAGQIfACwCHgBBAh4AQwIeAEcCHgBKAh4ATQIeAFACHgBT Ah4AVgIeAFoCHgBcAh4AYAIeAGICHwBmAh8AaQIfAGwCHwBvAh8AcgIfAHUCIQB5AiEAfAIhAH8C IQCCAiIAhQIiAIgCIgCLAiMAjwIjAJECIwCVAiQAlwIkAJsCJACdAiUAoQIlAKMCJwCbAioAkgIu AIoCMwCCAjYAeQI7AHECQABpAkMAYgJIAFsCTQBUAlIATQJXAEUCXAA/AmAAOAJlADICawAsAnAA JgJ1ACECewAbAoAAFgKGABICjAANApEACAKXAAMCnQD/AaMA+wGpAPcBrwDzAbUA8QG7AO0BwQDr AccA6QHNAOYBzADlAcwA4wHKAOEByQDfAcgA3gHIANsBxwDaAcYA2AHEANUBxADUAcMA0gHCANAB wQDOAcAAzAG+AMkBvQDIAbwAxgG7AMMBugDBAbgAvgG3AL0BtgC7AbQAuAGyALYBsQC0AbAAsQGt AK8BrACsAaoAqwGpAKkBpgCmAaUApgGxAKgBvQCpAckAqwHWAK8B4wCyAe8AtgH7ALsBBwHAARMB xgEfAcwBKgHSATYB2QFAAeABSwHnAVYB7wFhAfcBbAH/AXUBCAJ/ARACiAEZApEBIQKaASoCoQEz AqkBPAKxAUQCtwFOAr0BVgLDAV8CxwFnAswBbwLQAXgC0gF1As8BdALLAXICxgFvAsMBbQK+AWsC uQFoArQBZwKvAWUCqQFiAqQBYAKeAV8CmAFcApIBWwKLAVoChQFZAn4BVwJ3AVYCbwFVAmgBVQJg AVUCWQFVAlABVQJHAVYCPgFWAjQBWQIrAVoCIQFcAhgBXwINAWECAgFlAvcAaALrAGwC4ABxAtQA dwLJAH0CvgCEArUAiwKqAJICoACbApcApAKNAK0ChQC4AnwAwwJ0AM0CawDYAmQA5AJdAPACVgD+ Ak4ACwNIABgDQgAnAz0ANQM5AEMDNABTAy8AYgMrAHIDKACCAyUAkwMiAKMDIQC1Ax4AxgMdANYD HQDoAx0A/QMdABAEHgAkBB8ANwQiAEkEJABcBCgAbQQrAH8ELwCQBDQAoQQ6ALIEQADBBEYA0ARM AN4EUwDtBFwA+gRjAAcFawATBXUAHwV9ACoFhwA0BZEAPQWbAEYFpQBNBbAAVAW7AFoFxwBfBdIA ZAXeAGgF6gBqBfYAawUCAWwFDgFrBRsBagUnAWgFMwFkBT8BXwVKAVoFVgFUBWEBTQVsAUYFdwE9 BYIBNAWLASoFlQEfBZ4BEwWoAQcFsQH6BLkB7QTAAd4EyQHQBNABwQTWAbAE3QGhBOIBkAToAX8E 7QFtBPABWwT1AUkE+AE2BPoBJAT8ARAE/wH8A/8B6AMAAuUDAALhAwAC3wP/AdsD/wHZA/8B1QP/ AdID/wHPA/8BzAP/AckD/wHGA/8BwgP/AcAD/gG8A/4BugP+AbYD/gGyA/4BsAP8AawD/AGqA/wB pgP8AaQD+wGgA/sBngP7AZoD+gGXA/oBlAP6AZED+QGOA/kBiwP5AYgD+AGFA/gBjgPzAZcD7wGf A+wBpwPnAbAD4gG3A94BwAPZAccD1QHOA9AB1QPLAdwDxgHiA8EB6gO9AfADuAH2A7MB/AOtAQIE qAEIBKIBDQSdARMElwEXBJIBHASMASEEhgElBIIBKgR8AS0EdQExBG8BNARpATgEYwE6BF0BPgRX AUAEUQFCBFMBRARTAUUEVAFIBFQBSQRVAUsEVgFMBFcBTwRXAVAEWQFSBFoBVARbAVYEXAFZBF0B WwRfAVwEXwFfBGABYQRhAWMEYwFlBGUBZwRmAWkEZwFsBGgBbgRpAW8EawFyBG0BdARuAXcEbwF5 BHIBewRzAX4EdAGABHcBgwR4AYEEbAGBBGABfwRUAX0ESAF6BDwBdwQuAXIEIgFuBBYBaAQKAWME /wBdBPMAVgTnAFAE3ABJBNIAQgTHADkEvAAyBLIAKgSpACEEnwAZBJUAEASNAAgEhQD+A3wA9gN1 AOwDbgDkA2YA2wNgANMDXADJA1cAwQNSALoDTgCxA0sAsgNOALUDUwC3A1cAugNcALwDXwC9A2QA wANpAMIDbwDEA3QAxgN6AMgDfwDKA4UAzAOMAM0DkgDPA5gA0AOfANIDpgDTA60A0wO2ANQDvQDU A8YA1APOANMD1gDTA+AA0gPpANAD8gDPA/wAzQMHAcoDEQHHAxsBxAMnAcEDMgG8Az4BtwNJAbED VAGrA18BpQNpAZ4DcwGVA30BjQOGAYUDkAF7A5oBcQOiAWYDqwFcA7IBUAO6AUMDwQE3A8kBKgPP AR0D1QEQA9sBAQPhAfQC5gHkAuoB1gLvAcYC8wG3AvYBpgL5AZYC+wGFAv4BdAL/AWMCAAJRAgEC PwIBAiwCAQIYAgACBAL/AfIB/AHfAfoBzQH2AbsB8wGpAe4BmAHpAYcB5AF3Ad4BaAHYAVgB0QFK AcoBOwHDAS4BugEhAbIBFQGpAQoBoAH/AJcB9ACMAewAgwHjAHgB2wBtAdQAYgHOAFcByQBNAcQA QAHAADQBvgAoAb0AHAG9ABABBwYIBgIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAF8JAADECAAAiA8AAOEKAAAP AATwrgMAAAIACvAIAAAABBQAAAIKAADTCAvwfgMAAIEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUA AAAAAIcAAAAAAIgAAAAAAIkAAAAAAL8AAAAPAAgBAAABAAkBAAAAAAwB9AAAEA0BAAAAIA4BAAAA ID8BAAAGAEIBjgAAAEMBYAAAAEQBBAAAAEXBEAAAAEbBGgAAAH8BAQABAIABAAAAAIEBwgAKAIIB AAABAIMB////AIQBAAABAIUBAAAAIIbBAAAAAIfBAAAAAIgBAAAAAIkBAAAAAIoBAAAAAIsBAAAA AIwBAAAAAI0BAAAAAI4BAAAAAI8BAAAAAJABAAAAAJEBAAAAAJIBAAAAAJMBAAAAAJQBAAAAAJUB AAAAAJYBAAAAAJfBAAAAAJgBAAAAAJkBAAAAAJoBAAAAAJsBAAAAAJwBAwAAQL8BHAAeAMABAAAA AMEBAAABAMMBAAAAIMQBAAAAAMXBAAAAAMbBAAAAAMcBAAAAAMgBAAAAAMkBAAAAAMoBAAAAAMsB NSUAAMwBAAAIAM0BAAAAAM4BAAAAAM/BAAAAANIBAQAAANMBAQAAANQBAQAAANUBAQAAANcBAgAA AP8BFgAeAAACAAAAAAECgICAAAICy8vLAAMCAAAAIAQCAAABAAUCOGMAAAYCOGMAAAcCAAAAAAgC AAAAAAkCAAABAAoCAAAAAAsCAAAAAAwCAAABAA0CAAAAAA4CAAAAAA8CAAEAABACAAAAABECAAAA AD8CAAADAIACAAAAAIECAAABAIICBQAAAIMCnDEAAIQCAAAAAIUC8PkGAIYCAAAAAIcC9wAAEIgC AAAAIL8CAQAPAMACAAAAAMECAAAAAMICZAAAAMMCAAAAAMQCAAAAAMUCAAAAAMYCAAAAAMcCAAAA AMgCAAAAAMkCAAAAAMoCMHUAAMsC0BITAMwCMO3s/80CQFSJAM4CAIAAAM8CAID//9ACAAB5/9EC MgAAANICIE4AANMCUMMAANQCAAAAANUCECcAANYCcJQAANcCsDz//9gCAAAAANkCECcAANoCcJQA AP8CFgAfAAQDAQAAAEEDqCkBAEIDAAAAAEMDAwAAAEQDfL4BAEUDAAAAAH8DAAAPAIQDfL4BAIUD AAAAAIYDfL4BAIcDAAAAAIgDAAAAAAQABADw/0cAYAAAAAAAjgAAAEcAYAAKAAwAAgAAQACsAQAA rAEAAKwBAACsAWAAgAAAD/AQAAAAegYAAAYMAAAIBwAAZgwAAA8ABPD2AwAAAgAK8AgAAAAFFAAA AgoAANMIC/DGAwAAgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwAAAAAAiAAAAAAAiQAA AAAAvwAAAA8ACAEAAAEACQEAAAAADAH0AAAQDQEAAAAgDgEAAAAgPwEAAAYAQgERAQAAQwEKAgAA RAEEAAAARcE0AAAARsE+AAAAfwEBAAEAgAEAAAAAgQEACrAAggEAAAEAgwH///8AhAEAAAEAhQEA AAAghsEAAAAAh8EAAAAAiAEAAAAAiQEAAAAAigEAAAAAiwEAAAAAjAEAAAAAjQEAAAAAjgEAAAAA jwEAAAAAkAEAAAAAkQEAAAAAkgEAAAAAkwEAAAAAlAEAAAAAlQEAAAAAlgEAAAAAl8EAAAAAmAEA AAAAmQEAAAAAmgEAAAAAmwEAAAAAnAEDAABAvwEcAB4AwAEAAAAAwQEAAAEAwwEAAAAgxAEAAAAA xcEAAAAAxsEAAAAAxwEAAAAAyAEAAAAAyQEAAAAAygEAAAAAywE1JQAAzAEAAAgAzQEAAAAAzgEA AAAAz8EAAAAA0gEBAAAA0wEBAAAA1AEBAAAA1QEBAAAA1wECAAAA/wEWAB4AAAIAAAAAAQKAgIAA AgLLy8sAAwIAAAAgBAIAAAEABQI4YwAABgI4YwAABwIAAAAACAIAAAAACQIAAAEACgIAAAAACwIA AAAADAIAAAEADQIAAAAADgIAAAAADwIAAQAAEAIAAAAAEQIAAAAAPwIAAAMAgAIAAAAAgQIAAAEA ggIFAAAAgwKcMQAAhAIAAAAAhQLw+QYAhgIAAAAAhwL3AAAQiAIAAAAgvwIBAA8AwAIAAAAAwQIA AAAAwgJkAAAAwwIAAAAAxAIAAAAAxQIAAAAAxgIAAAAAxwIAAAAAyAIAAAAAyQIAAAAAygIwdQAA ywLQEhMAzAIw7ez/zQJAVIkAzgIAgAAAzwIAgP//0AIAAHn/0QIyAAAA0gIgTgAA0wJQwwAA1AIA AAAA1QIQJwAA1gJwlAAA1wKwPP//2AIAAAAA2QIQJwAA2gJwlAAA/wIWAB8ABAMBAAAAQQOoKQEA QgMAAAAAQwMDAAAARAN8vgEARQMAAAAAfwMAAA8AhAN8vgEAhQMAAAAAhgN8vgEAhwMAAAAAiAMA AAAADQANAPD/EQFZAGEAWQBhANQACwHUAAsBLAFhACwBYQCyAREBsgERAQoCAAAKAgAAAAARAQAA EQFZABwAIAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBYACAAAAP8BAAAADKCAAAAwwAANsJAAANDgAADwAE8P4JAAACAArwCAAAAAYUAAACCgAA 4wgL8M4JAAB/AAgACACBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACHAAAAAACIAAAAAACJ AAAAAAC/AAAADwAIAQAAAQAJAQAAAAAMAfQAABANAQAAACAOAQAAACA/AQAABgBCAWgBAABDAQoC AABEAQQAAABFwTQDAABGwUADAAB/AQEAAQCAAQAAAACBAQAKsACCAQAAAQCDAf///wCEAQAAAQCF AQAAACCGwQAAAACHwQAAAACIAQAAAACJAQAAAACKAQAAAACLAQAAAACMAQAAAACNAQAAAACOAQAA AACPAQAAAACQAQAAAACRAQAAAACSAQAAAACTAQAAAACUAQAAAACVAQAAAACWAQAAAACXwQAAAACY AQAAAACZAQAAAACaAQAAAACbAQAAAACcAQMAAEC/ARwAHgDAAQAAAADBAQAAAQDDAQAAACDEAQAA AADFwQAAAADGwQAAAADHAQAAAADIAQAAAADJAQAAAADKAQAAAADLATUlAADMAQAACADNAQAAAADO AQAAAADPwQAAAADSAQEAAADTAQEAAADUAQEAAADVAQEAAADXAQIAAAD/ARYAHgAAAgAAAAABAoCA gAACAsvLywADAgAAACAEAgAAAQAFAjhjAAAGAjhjAAAHAgAAAAAIAgAAAAAJAgAAAQAKAgAAAAAL AgAAAAAMAgAAAQANAgAAAAAOAgAAAAAPAgABAAAQAgAAAAARAgAAAAA/AgAAAwCAAgAAAACBAgAA AQCCAgUAAACDApwxAACEAgAAAACFAvD5BgCGAgAAAACHAvcAABCIAgAAACC/AgEADwDAAgAAAADB AgAAAADCAmQAAADDAgAAAADEAgAAAADFAgAAAADGAgAAAADHAgAAAADIAgAAAADJAgAAAADKAjB1 AADLAtASEwDMAjDt7P/NAkBUiQDOAgCAAADPAgCA///QAgAAef/RAjIAAADSAiBOAADTAlDDAADU AgAAAADVAhAnAADWAnCUAADXArA8///YAgAAAADZAhAnAADaAnCUAAD/AhYAHwAEAwEAAABBA6gp AQBCAwAAAABDAwMAAABEA3y+AQBFAwAAAAB/AwAADwCEA3y+AQCFAwAAAACGA3y+AQCHAwAAAACI AwAAAADNAM0A8P9hAFMAfQBTAIQAUwCIAFMAjgBTAJMAVQCYAFUAnQBWAKIAVwCmAFgAqgBZAK8A WwCyAF0AtgBeALoAYQC9AGIAwABkAMMAZwDGAGkAyABtAMwAbwDNAHIAzwB1ANIAeQDTAHwA1QCA ANcAhADYAIcA2QCLANkAkADaAJMA2gCYANoAnQDbAKIA2gCnANoAqwDaAK8A2QC0ANgAtwDYALwA 1wDAANQAwwDTAMcA0gDLAM8AzgDNANEAywDUAMgA1wDGANoAwgDdAMAA3wC8AOIAuQDjALUA5QCx AOYArgDpAKkA6gClAOsAoADsAJwA7gCXAO8AkgDvAIwA8ACHAPAAgQDwAHwA8ABhAPAAYQBTAAQB GAEIARUBCgETAQ4BEQEQAQ4BFAELARYBCAEaAQUBHAECAR8B/wAhAfsAJAH3ACYB9AApAfAAKwHs ACwB6QAvAeQAMAHgADIB3QAzAdgANQHUADcB0AA4AcsAOQHHADkBwgA7Ab0APAG5ADwBtAA9Aa8A PQGqAD4BpQA+AaEAPgGcAD4BlwA+AZIAPQGOAD0BigA9AYYAPAGBADwBfgA7AXkAOQF1ADgBcAA3 AW0ANwFoADUBZAAzAWEAMgFdADEBWAAwAVUALQFRACwBTQAqAUoAJwFGACYBQwAkAUAAIQE9AB8B OQAcATcAGgEzABgBMQAVAS4AEwEqAA8BKAANASYACgEjAAgBIQAEASAAAgEdAP4AGwD8ABoA+AAX APUAFgDxABQA7wASAOsAEQDnAA8A5AAOAN8ADADbAAsA2AAKANQACQDPAAgAzAAGAMcABQDDAAUA vwAEALoAAwC2AAMAsQACAKwAAgCoAAIAowAAAJ4AAACZAAAAlAAAAJAAAAAAAAAAAAAKAmEACgJh ADgBbQA4AfEACgJoAQoCzQAvAc8ALgHSAC4B1AAsAdcALAHZACwB2gArAd0AKwHfACoB4AAqAeMA KQHkACkB5QAnAecAJwHpACYB6gAmAewAJQHtACUB7wAkAfAAJAHyACMB9AAjAfUAIQH2ACAB9wAg AfoAHwH7AB4B/AAdAf0AHQEAARsBAQEaAQIBGQEEARgBnQGgAQIAAEAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAWAAgAAAD/AQAAAA5woAAAMMAABPDAAADQ4AAA8ABPD+AwAAAgAK8AgAAAAHFAAAAgoA AOMIC/DOAwAAfwAIAAgAgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwAAAAAAiAAAAAAA iQAAAAAAvwAAAA8ACAEAAAEACQEAAAAADAH0AAAQDQEAAAAgDgEAAAAgPwEAAAYAQgHNAQAAQwEM AgAARAEEAAAARcE0AAAARsFAAAAAfwEBAAEAgAEAAAAAgQEACrAAggEAAAEAgwH///8AhAEAAAEA hQEAAAAghsEAAAAAh8EAAAAAiAEAAAAAiQEAAAAAigEAAAAAiwEAAAAAjAEAAAAAjQEAAAAAjgEA AAAAjwEAAAAAkAEAAAAAkQEAAAAAkgEAAAAAkwEAAAAAlAEAAAAAlQEAAAAAlgEAAAAAl8EAAAAA mAEAAAAAmQEAAAAAmgEAAAAAmwEAAAAAnAEDAABAvwEcAB4AwAEAAAAAwQEAAAEAwwEAAAAgxAEA AAAAxcEAAAAAxsEAAAAAxwEAAAAAyAEAAAAAyQEAAAAAygEAAAAAywE1JQAAzAEAAAgAzQEAAAAA zgEAAAAAz8EAAAAA0gEBAAAA0wEBAAAA1AEBAAAA1QEBAAAA1wECAAAA/wEWAB4AAAIAAAAAAQKA gIAAAgLLy8sAAwIAAAAgBAIAAAEABQI4YwAABgI4YwAABwIAAAAACAIAAAAACQIAAAEACgIAAAAA CwIAAAAADAIAAAEADQIAAAAADgIAAAAADwIAAQAAEAIAAAAAEQIAAAAAPwIAAAMAgAIAAAAAgQIA AAEAggIFAAAAgwKcMQAAhAIAAAAAhQLw+QYAhgIAAAAAhwL3AAAQiAIAAAAgvwIBAA8AwAIAAAAA wQIAAAAAwgJkAAAAwwIAAAAAxAIAAAAAxQIAAAAAxgIAAAAAxwIAAAAAyAIAAAAAyQIAAAAAygIw dQAAywLQEhMAzAIw7ez/zQJAVIkAzgIAgAAAzwIAgP//0AIAAHn/0QIyAAAA0gIgTgAA0wJQwwAA 1AIAAAAA1QIQJwAA1gJwlAAA1wKwPP//2AIAAAAA2QIQJwAA2gJwlAAA/wIWAB8ABAMBAAAAQQOo KQEAQgMAAAAAQwMDAAAARAN8vgEARQMAAAAAfwMAAA8AhAN8vgEAhQMAAAAAhgN8vgEAhwMAAAAA iAMAAAAADQANAPD/rQBLAecApgAdAUsBrQBLAWUBDALNAQwCDwEAAMMAAAAAAAwCZgAMAo8AnQE8 AZ0BZQEMAh0AIAACAABAAKwBAACsAQAArAEAAKwBYABAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAFgAIAAAA/wEAAAANkMAAABDAAApg4AAA0OAAAPAATw5gMAAAIACvAIAAAACBQA AAIKAADTCAvwtgMAAIEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAAAAAIgAAAAAAIkA AAAAAL8AAAAPAAgBAAABAAkBAAAAAAwB9AAAEA0BAAAAIA4BAAAAID8BAAAGAEIBqwEAAEMBCgIA AEQBBAAAAEXBLAAAAEbBNgAAAH8BAQABAIABAAAAAIEBAAqwAIIBAAABAIMB////AIQBAAABAIUB AAAAIIbBAAAAAIfBAAAAAIgBAAAAAIkBAAAAAIoBAAAAAIsBAAAAAIwBAAAAAI0BAAAAAI4BAAAA AI8BAAAAAJABAAAAAJEBAAAAAJIBAAAAAJMBAAAAAJQBAAAAAJUBAAAAAJYBAAAAAJfBAAAAAJgB AAAAAJkBAAAAAJoBAAAAAJsBAAAAAJwBAwAAQL8BHAAeAMABAAAAAMEBAAABAMMBAAAAIMQBAAAA AMXBAAAAAMbBAAAAAMcBAAAAAMgBAAAAAMkBAAAAAMoBAAAAAMsBNSUAAMwBAAAIAM0BAAAAAM4B AAAAAM/BAAAAANIBAQAAANMBAQAAANQBAQAAANUBAQAAANcBAgAAAP8BFgAeAAACAAAAAAECgICA AAICy8vLAAMCAAAAIAQCAAABAAUCOGMAAAYCOGMAAAcCAAAAAAgCAAAAAAkCAAABAAoCAAAAAAsC AAAAAAwCAAABAA0CAAAAAA4CAAAAAA8CAAEAABACAAAAABECAAAAAD8CAAADAIACAAAAAIECAAAB AIICBQAAAIMCnDEAAIQCAAAAAIUC8PkGAIYCAAAAAIcC9wAAEIgCAAAAIL8CAQAPAMACAAAAAMEC AAAAAMICZAAAAMMCAAAAAMQCAAAAAMUCAAAAAMYCAAAAAMcCAAAAAMgCAAAAAMkCAAAAAMoCMHUA AMsC0BITAMwCMO3s/80CQFSJAM4CAIAAAM8CAID//9ACAAB5/9ECMgAAANICIE4AANMCUMMAANQC AAAAANUCECcAANYCcJQAANcCsDz//9gCAAAAANkCECcAANoCcJQAAP8CFgAfAAQDAQAAAEEDqCkB AEIDAAAAAEMDAwAAAEQDfL4BAEUDAAAAAH8DAAAPAIQDfL4BAIUDAAAAAIYDfL4BAIcDAAAAAIgD AAAAAAsACwDw/wAACgIAAAMAQwADAEoBUAFKAQAAqwEAAKsBCgJnAQoCYQC5AGEACgIAAAoCGAAc AAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAA AABqDwAAAwwAABURAAANDgAADwAE8NYDAAACAArwCAAAAAkUAAACCgAA0wgL8KYDAACBADBlAQCC AJiyAACDADBlAQCEAJiyAACFAAAAAACHAAAAAACIAAAAAACJAAAAAAC/AAAADwAIAQAAAQAJAQAA AAAMAfQAABANAQAAACAOAQAAACA/AQAABgBCAT4BAABDAQoCAABEAQQAAABFwSQAAABGwS4AAAB/ AQEAAQCAAQAAAACBAQAKsACCAQAAAQCDAf///wCEAQAAAQCFAQAAACCGwQAAAACHwQAAAACIAQAA AACJAQAAAACKAQAAAACLAQAAAACMAQAAAACNAQAAAACOAQAAAACPAQAAAACQAQAAAACRAQAAAACS AQAAAACTAQAAAACUAQAAAACVAQAAAACWAQAAAACXwQAAAACYAQAAAACZAQAAAACaAQAAAACbAQAA AACcAQMAAEC/ARwAHgDAAQAAAADBAQAAAQDDAQAAACDEAQAAAADFwQAAAADGwQAAAADHAQAAAADI AQAAAADJAQAAAADKAQAAAADLATUlAADMAQAACADNAQAAAADOAQAAAADPwQAAAADSAQEAAADTAQEA AADUAQEAAADVAQEAAADXAQIAAAD/ARYAHgAAAgAAAAABAoCAgAACAsvLywADAgAAACAEAgAAAQAF AjhjAAAGAjhjAAAHAgAAAAAIAgAAAAAJAgAAAQAKAgAAAAALAgAAAAAMAgAAAQANAgAAAAAOAgAA AAAPAgABAAAQAgAAAAARAgAAAAA/AgAAAwCAAgAAAACBAgAAAQCCAgUAAACDApwxAACEAgAAAACF AvD5BgCGAgAAAACHAvcAABCIAgAAACC/AgEADwDAAgAAAADBAgAAAADCAmQAAADDAgAAAADEAgAA AADFAgAAAADGAgAAAADHAgAAAADIAgAAAADJAgAAAADKAjB1AADLAtASEwDMAjDt7P/NAkBUiQDO AgCAAADPAgCA///QAgAAef/RAjIAAADSAiBOAADTAlDDAADUAgAAAADVAhAnAADWAnCUAADXArA8 ///YAgAAAADZAhAnAADaAnCUAAD/AhYAHwAEAwEAAABBA6gpAQBCAwAAAABDAwMAAABEA3y+AQBF AwAAAAB/AwAADwCEA3y+AQCFAwAAAACGA3y+AQCHAwAAAACIAwAAAAAJAAkA8P/OAAoCbwAKAm8A WQAAAFkAAAAAAD4BAAA+AVkAzgBZAM4ACgIUABgAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBYACAAAAP8BAAAADPEQAAAwwAAA0TAAANDgAADwAE8OYDAAACAArwCAAAAAoU AAACCgAA0wgL8LYDAACBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACHAAAAAACIAAAAAACJ AAAAAAC/AAAADwAIAQAAAQAJAQAAAAAMAfQAABANAQAAACAOAQAAACA/AQAABgBCAckBAABDASkC AABEAQQAAABFwSwAAABGwTYAAAB/AQEAAQCAAQAAAACBAQAKsACCAQAAAQCDAf///wCEAQAAAQCF AQAAACCGwQAAAACHwQAAAACIAQAAAACJAQAAAACKAQAAAACLAQAAAACMAQAAAACNAQAAAACOAQAA AACPAQAAAACQAQAAAACRAQAAAACSAQAAAACTAQAAAACUAQAAAACVAQAAAACWAQAAAACXwQAAAACY AQAAAACZAQAAAACaAQAAAACbAQAAAACcAQMAAEC/ARwAHgDAAQAAAADBAQAAAQDDAQAAACDEAQAA AADFwQAAAADGwQAAAADHAQAAAADIAQAAAADJAQAAAADKAQAAAADLATUlAADMAQAACADNAQAAAADO AQAAAADPwQAAAADSAQEAAADTAQEAAADUAQEAAADVAQEAAADXAQIAAAD/ARYAHgAAAgAAAAABAoCA gAACAsvLywADAgAAACAEAgAAAQAFAjhjAAAGAjhjAAAHAgAAAAAIAgAAAAAJAgAAAQAKAgAAAAAL AgAAAAAMAgAAAQANAgAAAAAOAgAAAAAPAgABAAAQAgAAAAARAgAAAAA/AgAAAwCAAgAAAACBAgAA AQCCAgUAAACDApwxAACEAgAAAACFAvD5BgCGAgAAAACHAvcAABCIAgAAACC/AgEADwDAAgAAAADB AgAAAADCAmQAAADDAgAAAADEAgAAAADFAgAAAADGAgAAAADHAgAAAADIAgAAAADJAgAAAADKAjB1 AADLAtASEwDMAjDt7P/NAkBUiQDOAgCAAADPAgCA///QAgAAef/RAjIAAADSAiBOAADTAlDDAADU AgAAAADVAhAnAADWAnCUAADXArA8///YAgAAAADZAhAnAADaAnCUAAD/AhYAHwAEAwEAAABBA6gp AQBCAwAAAABDAwMAAABEA3y+AQBFAwAAAAB/AwAADwCEA3y+AQCFAwAAAACGA3y+AQCHAwAAAACI AwAAAAALAAsA8P/lAL0BaQERAWkBKQLJASkCyQEAAOUAMgEAAAAAAAApAmAAKQJgABEB5QC9ARgA HAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQ AAAA3AUAAOQLAAClBwAADQ4AAA8ABPDWAwAAAgAK8AgAAAALFAAAAgoAANMIC/CmAwAAgQAwZQEA ggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwAAAAAAiAAAAAAAiQAAAAAAvwAAAA8ACAEAAAEACQEA AAAADAH0AAAQDQEAAAAgDgEAAAAgPwEAAAYAQgEvAAAAQwE+AAAARAEEAAAARcEkAAAARsEuAAAA fwEBAAEAgAEAAAAAgQEACrAAggEAAAEAgwH///8AhAEAAAEAhQEAAAAghsEAAAAAh8EAAAAAiAEA AAAAiQEAAAAAigEAAAAAiwEAAAAAjAEAAAAAjQEAAAAAjgEAAAAAjwEAAAAAkAEAAAAAkQEAAAAA kgEAAAAAkwEAAAAAlAEAAAAAlQEAAAAAlgEAAAAAl8EAAAAAmAEAAAAAmQEAAAAAmgEAAAAAmwEA AAAAnAEDAABAvwEcAB4AwAEAAAAAwQEAAAEAwwEAAAAgxAEAAAAAxcEAAAAAxsEAAAAAxwEAAAAA yAEAAAAAyQEAAAAAygEAAAAAywE1JQAAzAEAAAgAzQEAAAAAzgEAAAAAz8EAAAAA0gEBAAAA0wEB AAAA1AEBAAAA1QEBAAAA1wECAAAA/wEWAB4AAAIAAAAAAQKAgIAAAgLLy8sAAwIAAAAgBAIAAAEA BQI4YwAABgI4YwAABwIAAAAACAIAAAAACQIAAAEACgIAAAAACwIAAAAADAIAAAEADQIAAAAADgIA AAAADwIAAQAAEAIAAAAAEQIAAAAAPwIAAAMAgAIAAAAAgQIAAAEAggIFAAAAgwKcMQAAhAIAAAAA hQLw+QYAhgIAAAAAhwL3AAAQiAIAAAAgvwIBAA8AwAIAAAAAwQIAAAAAwgJkAAAAwwIAAAAAxAIA AAAAxQIAAAAAxgIAAAAAxwIAAAAAyAIAAAAAyQIAAAAAygIwdQAAywLQEhMAzAIw7ez/zQJAVIkA zgIAgAAAzwIAgP//0AIAAHn/0QIyAAAA0gIgTgAA0wJQwwAA1AIAAAAA1QIQJwAA1gJwlAAA1wKw PP//2AIAAAAA2QIQJwAA2gJwlAAA/wIWAB8ABAMBAAAAQQOoKQEAQgMAAAAAQwMDAAAARAN8vgEA RQMAAAAAfwMAAA8AhAN8vgEAhQMAAAAAhgN8vgEAhwMAAAAAiAMAAAAACQAJAPD/HQA+ABIAPgAS AAsAAAALAAAAAAAvAAAALwALAB0ACwAdAD4AFAAYAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAWAAgAAAD/AQAAAAQRMAAAMMAABwEwAAQQwAAA8ABPAGBAAAAgAK8AgAAAAM FAAAAgoAANMIC/DWAwAAgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwAAAAAAiAAAAAAA iQAAAAAAvwAAAA8ACAEAAAEACQEAAAAADAH0AAAQDQEAAAAgDgEAAAAgPwEAAAYAQgE5AAAAQwE+ AAAARAEEAAAARcE8AAAARsFGAAAAfwEBAAEAgAEAAAAAgQEACrAAggEAAAEAgwH///8AhAEAAAEA hQEAAAAghsEAAAAAh8EAAAAAiAEAAAAAiQEAAAAAigEAAAAAiwEAAAAAjAEAAAAAjQEAAAAAjgEA AAAAjwEAAAAAkAEAAAAAkQEAAAAAkgEAAAAAkwEAAAAAlAEAAAAAlQEAAAAAlgEAAAAAl8EAAAAA mAEAAAAAmQEAAAAAmgEAAAAAmwEAAAAAnAEDAABAvwEcAB4AwAEAAAAAwQEAAAEAwwEAAAAgxAEA AAAAxcEAAAAAxsEAAAAAxwEAAAAAyAEAAAAAyQEAAAAAygEAAAAAywE1JQAAzAEAAAgAzQEAAAAA zgEAAAAAz8EAAAAA0gEBAAAA0wEBAAAA1AEBAAAA1QEBAAAA1wECAAAA/wEWAB4AAAIAAAAAAQKA gIAAAgLLy8sAAwIAAAAgBAIAAAEABQI4YwAABgI4YwAABwIAAAAACAIAAAAACQIAAAEACgIAAAAA CwIAAAAADAIAAAEADQIAAAAADgIAAAAADwIAAQAAEAIAAAAAEQIAAAAAPwIAAAMAgAIAAAAAgQIA AAEAggIFAAAAgwKcMQAAhAIAAAAAhQLw+QYAhgIAAAAAhwL3AAAQiAIAAAAgvwIBAA8AwAIAAAAA wQIAAAAAwgJkAAAAwwIAAAAAxAIAAAAAxQIAAAAAxgIAAAAAxwIAAAAAyAIAAAAAyQIAAAAAygIw dQAAywLQEhMAzAIw7ez/zQJAVIkAzgIAgAAAzwIAgP//0AIAAHn/0QIyAAAA0gIgTgAA0wJQwwAA 1AIAAAAA1QIQJwAA1gJwlAAA1wKwPP//2AIAAAAA2QIQJwAA2gJwlAAA/wIWAB8ABAMBAAAAQQOo KQEAQgMAAAAAQwMDAAAARAN8vgEARQMAAAAAfwMAAA8AhAN8vgEAhQMAAAAAhgN8vgEAhwMAAAAA iAMAAAAADwAPAPD/OQA+AC4APgAuAAoALQAKACIAPgAWAD4ACwAKAAsAPgAAAD4AAAAAABEAAAAc ADEAJwAAADkAAAA5AD4AIAAkAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAdxMAAAMMAACwEwAAQQwAAA8ABPDQ AAAAEgAK8AgAAAANFAAAAAoAANMAC/BOAAAAgAD4/bwAgQCrZwEAggDWswAAgwCrZwEAhADWswAA vwAQAB8AgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAQ8AgAAADu ChkBKRXuDQ8ADfBSAAAAAACfDwQAAAAEAAAAAAChDxgAAAABAAAAAAAAKAoAAQAUAAIAAQAAAAAA AAAAAKoPCgAAAAEAAAABAAAAAAAAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPCqAAAAEgAK8AgAAAAO FAAAIAIAAHMAC/AqAAAABAAAAAAAfwAAAAQAgACk9rwAvwEAAAEA/wEAAAEAAQMKBAAAiAMAAAAA AAAQ8AgAAABQB1ABcBQgCg8AEfA8AAAADwAUECQAAAABAPEPHAAAAAAAAAcABAAAAAAAAAAAAAAA AAEAAAAAAAAADjAAAMMLCAAAAAAAAAAPALwADwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwqQAAAKIM CvAIAAAADxQAAAAKAACDAAvwMAAAAIAAEACJAb8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAA CP8BAAAIAAECAgAACAAAEPAIAAAA9g4AACAH8A8PAA3wSQAAAAAAnw8EAAAABAAAAAAAqA8VAAAA QXV0aG9yOiBQZXRlciBSYXltb25kAAChDxgAAAAWAAAAAAAAIAAAMgAWAAAAAAADAAEAFAAPAATw SAAAABIACvAIAAAAARQAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BHgAf AP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAAAAAAAP///wAAAAAA//8AAADM/wAAzAAA/2YzAJkA zAAPAO4DSRQAAAIA7wMYAAAAEAAAAAAAAAAAAAAAAAAAgAAAAAAHAAAADwAMBPkTAAAPAALw8RMA AEAACPAIAAAAKAAAAHWkAAAwABjxDAAAAAEAAAACAAAAAwAAAA8AA/BtEwAADwAE8CgAAAABAAnw EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAACkAAAFAAAADwAE8KcAAAASAArwCAAAADCkAAAg AgAAYwAL8CQAAAB/AAAABACAAFQmiQG/AQAAAQD/AQAAAQABAwoEAACIAwAAAAAAABDwCAAAADAA kAAgFhACDwAR8BAAAAAAAMMLCAAAAP////8NAIkBDwAN8DsAAAAAAJ8PBAAAAAAAAAAAAKgPCQAA AEhpZXJhcmNoeQAAoQ8WAAAACgAAAAAAAAAAAAoAAAAAAAMAAQAgAA8AA/CGEgAADwAE8DgAAAAB AAnwEAAAAJADAADQAgAAMBIAAOANAAACAArwCAAAAHSkAAABAgAAAAAQ8AgAAADQAvAAkA/gDQ8A A/B1AQAADwAE8FQAAAABAAnwEAAAAEARAABAAgAAkBUAAMAJAAACAArwCAAAAEekAAADAgAAIwAL 8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAAJADAACQDAAAYAkAAOANAAAPAATwYAAAABIACvAIAAAA SKQAAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAI AAECAgAACAAAD/AQAAAAQBEAAEACAACQFQAAwAkAAA8ABPCpAAAAogwK8AgAAABJpAAAAgoAAIMA C/AwAAAAgAA0KokBvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAP 8BAAAABAEQAAbgIAAGAVAAC3BgAADwAN8EEAAAAAAJ8PBAAAAAQAAAAAAKgPCwAAAFJlc291cmNl IFIxAAChDxoAAAAMAAAAAAAAKAAAAQAyAAwAAAAAAAMAAQAOAA8AA/B1AQAADwAE8FQAAAABAAnw EAAAAEARAABAAgAAkBUAAMAJAAACAArwCAAAAEqkAAADAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAA AA/wEAAAAGAMAACQDAAAMBIAAOANAAAPAATwYAAAABIACvAIAAAAS6QAAAIKAACDAAvwMAAAAIUA AgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAD/AQAAAAQBEA AEACAACQFQAAwAkAAA8ABPCpAAAAogwK8AgAAABMpAAAAgoAAIMAC/AwAAAAgACILokBvwACAAIA gQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAP8BAAAABAEQAAbgIAAGAVAAC3 BgAADwAN8EEAAAAAAJ8PBAAAAAQAAAAAAKgPCwAAAFJlc291cmNlIFIyAAChDxoAAAAMAAAAAAAA KAAAAQAyAAwAAAAAAAMAAQAOAA8AA/AdBQAADwAE8EAAAAABAAnwEAAAAEAIAABAAgAA0A4AAKAF AAACAArwCAAAAGukAAADAgAAAAAP8BAAAACwBwAA0AIAAEAOAAAwBgAADwAD8HkBAAAPAATwVAAA AAEACfAQAAAAQBEAAEACAACQFQAAwAkAAAIACvAIAAAAOKQAAAMCAAAjAAvwDAAAAAQAAAAAAIgD AQAAAAAAD/AQAAAAQAgAAEACAADQDgAAoAUAAA8ABPBgAAAAEgAK8AgAAAA5pAAAAgoAAIMAC/Aw AAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAP8BAA AABAEQAAQAIAAJAVAADACQAADwAE8K0AAACiDArwCAAAADqkAAACCgAAgwAL8DAAAACAAPQyiQG/ AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAAA/wEAAAAEARAABsAgAA YBUAABcEAAAPAA3wRQAAAAAAnw8EAAAABAAAAAAAqA8PAAAAUm9vdCBDb2xsZWN0aW9uAAChDxoA AAAQAAAAAAAAKAAAAQAyABAAAAAAAAMAAQAOAA8AA/BMAwAADwAE8EAAAAABAAnwEAAAAHAIAAAw AwAAoA4AAHAFAAACAArwCAAAAFKkAAADAgAAAAAP8BAAAABwCAAAMAMAAKAOAABwBQAADwAE8GAA AAASAArwCAAAAE2kAAACCgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/ARAAEADA AQEAAAj/AQgACAABAgIAAAgAAA/wEAAAAHAIAAAwAwAAoA4AAHAFAAAPAATwpQAAAKIMCvAIAAAA TqQAAAIKAACDAAvwMAAAAIAAIDeJAb8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAI AAECAgAACAAAD/AQAAAAcAgAADADAABwCwAA8AMAAA8ADfA9AAAAAACfDwQAAAAEAAAAAACoDwkA AABCaW5kaW5nczoAAKEPGAAAAAoAAAAAAAAgAAAyAAoAAAAAAAMAAQAOAA8ABPCdAAAAogwK8AgA AABPpAAAAgoAAHMAC/AqAAAAgABMO4kBvwACAAIAgQH//5kAvwEQABAAwAEBAAAI/wEIAAgAAQIC AAAIAAAP8BAAAACgCAAAIAQAAFAKAADmBAAADwAN8DsAAAAAAJ8PBAAAAAQAAAAAAKgPBQAAAENv bGwxAAChDxoAAAAGAAAAAAAAKAAAAQAyAAYAAAAAAAMAAQAOAA8ABPCdAAAAogwK8AgAAABQpAAA AgoAAHMAC/AqAAAAgABAPokBvwACAAIAgQH//5kAvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAP 8BAAAACwCgAAIAQAAGAMAADmBAAADwAN8DsAAAAAAJ8PBAAAAAQAAAAAAKgPBQAAAENvbGwyAACh DxoAAAAGAAAAAAAAKAAAAQAyAAYAAAAAAAMAAQAOAA8ABPCdAAAAogwK8AgAAABRpAAAAgoAAHMA C/AqAAAAgAAMQYkBvwACAAIAgQH//5kAvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAP8BAAAADA DAAAIAQAAHAOAADmBAAADwAN8DsAAAAAAJ8PBAAAAAQAAAAAAKgPBQAAAENvbGwzAAChDxoAAAAG AAAAAAAAKAAAAQAyAAYAAAAAAAMAAQAOAA8AA/A6BAAADwAE8EAAAAABAAnwEAAAANACAADwBgAA oAgAAFAKAAACAArwCAAAAGykAAADAgAAAAAP8BAAAACQAwAAsAcAAGAJAAAQCwAADwAD8HcBAAAP AATwVAAAAAEACfAQAAAAQBEAAEACAACQFQAAwAkAAAIACvAIAAAAQaQAAAMCAAAjAAvwDAAAAAQA AAAAAIgDAAAAAAAAD/AQAAAA0AIAAPAGAACgCAAAUAoAAA8ABPBgAAAAEgAK8AgAAABCpAAAAgoA AIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAI AAAP8BAAAABAEQAAQAIAAJAVAADACQAADwAE8KsAAACiDArwCAAAAEOkAAACCgAAgwAL8DAAAACA ANREiQG/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAAA/wEAAAAEAR AABsAgAAYBUAABcEAAAPAA3wQwAAAAAAnw8EAAAABAAAAAAAqA8NAAAAQ29sbGVjdGlvbiBDMQAA oQ8aAAAADgAAAAAAACgAAAEAMgAOAAAAAAADAAEADgAPAATwZgAAABIACvAIAAAAVKQAAAIKAACT AAvwNgAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACIgD AwAAAAAAD/AQAAAAAAMAAOAHAABwCAAAIAoAAA8ABPCrAAAAogwK8AgAAABVpAAAAgoAAJMAC/A2 AAAAgABwSIkBvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIiAMDAAAA AAAP8BAAAAAAAwAA4AcAAAAGAACgCAAADwAN8D0AAAAAAJ8PBAAAAAQAAAAAAKgPCQAAAEJpbmRp bmdzOgAAoQ8YAAAACgAAAAAAACAAADIACgAAAAAAAwABAA4ADwAE8KEAAACiDArwCAAAAFakAAAC CgAAgwAL8DAAAACAAFxMiQG/AAIAAgCBAf//mQC/ARAAEADAAQEAAAj/AQgACAABAgIAAAiIAwMA AAAAAA/wEAAAADADAADQCAAA4AQAAJYJAAAPAA3wOQAAAAAAnw8EAAAABAAAAAAAqA8DAAAARm9v AAChDxoAAAAEAAAAAAAAKAAAAQAyAAQAAAAAAAMAAQAOAA8ABPChAAAAogwK8AgAAABXpAAAAgoA AIMAC/AwAAAAgACkT4kBvwACAAIAgQH//5kAvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIiAMDAAAA AAAP8BAAAABABQAA0AgAAPAGAACWCQAADwAN8DkAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAEJhcgAA oQ8aAAAABAAAAAAAACgAAAEAMgAEAAAAAAADAAEADgAPAAPwkQMAAA8ABPBAAAAAAQAJ8BAAAACg CwAA8AYAAHARAABQCgAAAgAK8AgAAABtpAAAAwIAAAAAD/AQAAAAYAwAALAHAAAwEgAAEAsAAA8A A/B3AQAADwAE8FQAAAABAAnwEAAAAEARAABAAgAAkBUAAMAJAAACAArwCAAAAESkAAADAgAAIwAL 8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAAKALAADwBgAAcBEAAFAKAAAPAATwYAAAABIACvAIAAAA RaQAAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAI AAECAgAACAAAD/AQAAAAQBEAAEACAACQFQAAwAkAAA8ABPCrAAAAogwK8AgAAABGpAAAAgoAAIMA C/AwAAAAgACIU4kBvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAP 8BAAAABAEQAAbAIAAGAVAAAXBAAADwAN8EMAAAAAAJ8PBAAAAAQAAAAAAKgPDQAAAENvbGxlY3Rp b24gQzIAAKEPGgAAAA4AAAAAAAAoAAABADIADgAAAAAAAwABAA4ADwAE8GYAAAASAArwCAAAAFqk AAACCgAAkwAL8DYAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAAB AgIAAAiIAwIAAAAAAA/wEAAAANALAADgBwAAQBEAACAKAAAPAATwqwAAAKIMCvAIAAAAW6QAAAIK AACTAAvwNgAAAIAAdFeJAb8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAA CIgDAgAAAAAAD/AQAAAA0AsAAOAHAADQDgAAoAgAAA8ADfA9AAAAAACfDwQAAAAEAAAAAACoDwkA AABCaW5kaW5nczoAAKEPGAAAAAoAAAAAAAAgAAAyAAoAAAAAAAMAAQAOAA8ABPChAAAAogwK8AgA AABcpAAAAgoAAIMAC/AwAAAAgACAW4kBvwACAAIAgQH//5kAvwEQABAAwAEBAAAI/wEIAAgAAQIC AAAIiAMCAAAAAAAP8BAAAAAADAAA0AgAALANAACWCQAADwAN8DkAAAAAAJ8PBAAAAAQAAAAAAKgP AwAAAEZvbwAAoQ8aAAAABAAAAAAAACgAAAEAMgAEAAAAAAADAAEADgAPAATwWgAAAEIBCvAIAAAA bqQAAAIKAABzAAvwKgAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACNEBAQAAAP8BGAAYAAECAgAA CAAAD/AQAAAAgA0AAFAKAACADQAAkAwAAA8ABPBaAAAAQgEK8AgAAABvpAAAAgoAAHMAC/AqAAAA RAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0QEBAAAA/wEYABgAAQICAAAIAAAP8BAAAAAgDQAAcAUA ACANAACwBwAADwAE8FoAAABCAQrwCAAAAHCkAAACCgAAcwAL8CoAAABEAQQAAAB/AQAAAQC/AQAA EADAAQEAAAjRAQEAAAD/ARgAGAABAgIAAAgAAA/wEAAAAPAGAABQCgAAYAwAAJAMAAAPAATwWgAA AEIBCvAIAAAAcaQAAAIKAABzAAvwKgAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACNEBAQAAAP8B GAAYAAECAgAACAAAD/AQAAAA4AQAAFAKAADgBAAAkAwAAA8ABPBaAAAAQgEK8AgAAABypAAAAgoA AHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0QEBAAAA/wEYABgAAQICAAAIAAAP8BAA AADQCAAAcAUAANAIAACwBwAADwAE8FoAAABCAQrwCAAAAHOkAABCCgAAcwAL8CoAAABEAQQAAAB/ AQAAAQC/AQAAEADAAQEAAAjRAQEAAAD/ARgAGAABAgIAAAgAAA/wEAAAAGAJAABwBQAA4AoAALAH AAAPAATwSAAAABIACvAIAAAAAaQAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1o AL8BEgASAP8BAAAIAAQDCQAAAD8DAQABAA8ABfAAAAAAEADwByAAAAD///8AAAAAAICAgAAAAAAA AMyZADMzzADMzP8AsrKyAA8A7gMfFQAAAgDvAxgAAAAQAAAAAAAAAAAAAAAAAACAAAAAAAcAAAAP AAwEzxQAAA8AAvDHFAAAUAAI8AgAAAApAAAAKcQAAA8AA/BfFAAADwAE8CgAAAABAAnwEAAAAAAA AAAAAAAAAAAAAAAAAAACAArwCAAAAADEAAAFAAAADwAE8KcAAAASAArwCAAAAALEAAAgAgAAYwAL 8CQAAAB/AAAABACAAPRjiQG/AQAAAQD/AQAAAQABAwoEAACIAwAAAAAAABDwCAAAADAAkAAgFhAC DwAR8BAAAAAAAMMLCAAAAP////8NAIkBDwAN8DsAAAAAAJ8PBAAAAAAAAAAAAKgPCQAAAEhpZXJh cmNoeQAAoQ8WAAAACgAAAAAAAAAAAAoAAAAAAAMAAQAgAA8AA/CiEgAADwAE8EYAAAABAAnwEAAA AJADAADQAgAAMBIAAOANAAACAArwCAAAAAPEAAABAgAAEwAL8AYAAACIAwAAAAAAABDwCAAAANAC 8ACQD+ANDwAD8HUBAAAPAATwVAAAAAEACfAQAAAAQBEAAEACAACQFQAAwAkAAAIACvAIAAAABMQA AAMCAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAD/AQAAAAkAMAAJAMAABgCQAA4A0AAA8ABPBgAAAA EgAK8AgAAAAFxAAAAgoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEB AAAI/wEIAAgAAQICAAAIAAAP8BAAAABAEQAAQAIAAJAVAADACQAADwAE8KkAAACiDArwCAAAAAbE AAACCgAAgwAL8DAAAACAANRniQG/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAAB AgIAAAgAAA/wEAAAAEARAABuAgAAYBUAALcGAAAPAA3wQQAAAAAAnw8EAAAABAAAAAAAqA8LAAAA UmVzb3VyY2UgUjEAAKEPGgAAAAwAAAAAAAAoAAABADIADAAAAAAAAwABAA4ADwAD8HUBAAAPAATw VAAAAAEACfAQAAAAQBEAAEACAACQFQAAwAkAAAIACvAIAAAAB8QAAAMCAAAjAAvwDAAAAAQAAAAA AIgDAAAAAAAAD/AQAAAAYAwAAJAMAAAwEgAA4A0AAA8ABPBgAAAAEgAK8AgAAAAIxAAAAgoAAIMA C/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAP 8BAAAABAEQAAQAIAAJAVAADACQAADwAE8KkAAACiDArwCAAAAAnEAAACCgAAgwAL8DAAAACAAChs iQG/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAAA/wEAAAAEARAABu AgAAYBUAALcGAAAPAA3wQQAAAAAAnw8EAAAABAAAAAAAqA8LAAAAUmVzb3VyY2UgUjIAAKEPGgAA AAwAAAAAAAAoAAABADIADAAAAAAAAwABAA4ADwAD8DkFAAAPAATwTgAAAAEACfAQAAAAQAgAAEAC AADQDgAAoAUAAAIACvAIAAAACsQAAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAAsAcAANACAABA DgAAMAYAAA8AA/B5AQAADwAE8FQAAAABAAnwEAAAAEARAABAAgAAkBUAAMAJAAACAArwCAAAAAvE AAADAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAAEAIAABAAgAA0A4AAKAFAAAPAATwYAAA ABIACvAIAAAADMQAAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMAB AQAACP8BCAAIAAECAgAACAAAD/AQAAAAQBEAAEACAACQFQAAwAkAAA8ABPCtAAAAogwK8AgAAAAN xAAAAgoAAIMAC/AwAAAAgACUcIkBvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgA AQICAAAIAAAP8BAAAABAEQAAbAIAAGAVAAAXBAAADwAN8EUAAAAAAJ8PBAAAAAQAAAAAAKgPDwAA AFJvb3QgQ29sbGVjdGlvbgAAoQ8aAAAAEAAAAAAAACgAAAEAMgAQAAAAAAADAAEADgAPAAPwWgMA AA8ABPBOAAAAAQAJ8BAAAABwCAAAMAMAAKAOAABwBQAAAgAK8AgAAAAOxAAAAwIAABMAC/AGAAAA iAMAAAAAAAAP8BAAAABwCAAAMAMAAKAOAABwBQAADwAE8GAAAAASAArwCAAAAA/EAAACCgAAgwAL 8DAAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAAA/w EAAAAHAIAAAwAwAAoA4AAHAFAAAPAATwpQAAAKIMCvAIAAAAEMQAAAIKAACDAAvwMAAAAIAA9HSJ Ab8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAD/AQAAAAcAgAADAD AABwCwAA8AMAAA8ADfA9AAAAAACfDwQAAAAEAAAAAACoDwkAAABCaW5kaW5nczoAAKEPGAAAAAoA AAAAAAAgAAAyAAoAAAAAAAMAAQAOAA8ABPCdAAAAogwK8AgAAAARxAAAAgoAAHMAC/AqAAAAgAAg eYkBvwACAAIAgQH//5kAvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAP8BAAAACgCAAAIAQAAFAK AADmBAAADwAN8DsAAAAAAJ8PBAAAAAQAAAAAAKgPBQAAAENvbGwxAAChDxoAAAAGAAAAAAAAKAAA AQAyAAYAAAAAAAMAAQAOAA8ABPCdAAAAogwK8AgAAAASxAAAAgoAAHMAC/AqAAAAgABMfIkBvwAC AAIAgQH//5kAvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAP8BAAAACwCgAAIAQAAGAMAADmBAAA DwAN8DsAAAAAAJ8PBAAAAAQAAAAAAKgPBQAAAENvbGwyAAChDxoAAAAGAAAAAAAAKAAAAQAyAAYA AAAAAAMAAQAOAA8ABPCdAAAAogwK8AgAAAATxAAAAgoAAHMAC/AqAAAAgACIf4kBvwACAAIAgQH/ /5kAvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAP8BAAAADADAAAIAQAAHAOAADmBAAADwAN8DsA AAAAAJ8PBAAAAAQAAAAAAKgPBQAAAENvbGwzAAChDxoAAAAGAAAAAAAAKAAAAQAyAAYAAAAAAAMA AQAOAA8AA/AwBAAADwAE8E4AAAABAAnwEAAAANACAADwBgAAoAgAAFAKAAACAArwCAAAABTEAAAD AgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAAJADAACwBwAAYAkAABALAAAPAAPwdwEAAA8ABPBUAAAA AQAJ8BAAAABAEQAAQAIAAJAVAADACQAAAgAK8AgAAAAVxAAAAwIAACMAC/AMAAAABAAAAAAAiAMA AAAAAAAP8BAAAADQAgAA8AYAAKAIAABQCgAADwAE8GAAAAASAArwCAAAABbEAAACCgAAgwAL8DAA AACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAAA/wEAAA AEARAABAAgAAkBUAAMAJAAAPAATwqwAAAKIMCvAIAAAAF8QAAAIKAACDAAvwMAAAAIAAJIOJAb8A AgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAD/AQAAAAQBEAAGwCAABg FQAAFwQAAA8ADfBDAAAAAACfDwQAAAAEAAAAAACoDw0AAABDb2xsZWN0aW9uIEMxAAChDxoAAAAO AAAAAAAAKAAAAQAyAA4AAAAAAAMAAQAOAA8ABPBgAAAAEgAK8AgAAAAYxAAAAgoAAIMAC/AwAAAA hQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAP8BAAAAAA AwAA4AcAAHAIAAAgCgAADwAE8KUAAACiDArwCAAAABnEAAACCgAAgwAL8DAAAACAABiHiQG/AAIA AgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAAA/wEAAAAAADAADgBwAAAAYA AKAIAAAPAA3wPQAAAAAAnw8EAAAABAAAAAAAqA8JAAAAQmluZGluZ3M6AAChDxgAAAAKAAAAAAAA IAAAMgAKAAAAAAADAAEADgAPAATwmwAAAKIMCvAIAAAAGsQAAAIKAABzAAvwKgAAAIAADIuJAb8A AgACAIEB//+ZAL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAD/AQAAAAMAMAANAIAADgBAAAlgkA AA8ADfA5AAAAAACfDwQAAAAEAAAAAACoDwMAAABGb28AAKEPGgAAAAQAAAAAAAAoAAABADIABAAA AAAAAwABAA4ADwAE8JsAAACiDArwCAAAABvEAAACCgAAcwAL8CoAAACAAMiNiQG/AAIAAgCBAf// mQC/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAAA/wEAAAAEAFAADQCAAA8AYAAJYJAAAPAA3wOQAA AAAAnw8EAAAABAAAAAAAqA8DAAAAQmFyAAChDxoAAAAEAAAAAAAAKAAAAQAyAAQAAAAAAAMAAQAO AA8AA/CNAwAADwAE8E4AAAABAAnwEAAAAKALAADwBgAAcBEAAFAKAAACAArwCAAAABzEAAADAgAA EwAL8AYAAACIAwAAAAAAAA/wEAAAAGAMAACwBwAAMBIAABALAAAPAAPwdwEAAA8ABPBUAAAAAQAJ 8BAAAABAEQAAQAIAAJAVAADACQAAAgAK8AgAAAAdxAAAAwIAACMAC/AMAAAABAAAAAAAiAMAAAAA AAAP8BAAAACgCwAA8AYAAHARAABQCgAADwAE8GAAAAASAArwCAAAAB7EAAACCgAAgwAL8DAAAACF AAIAAACHAAEAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAAA/wEAAAAEAR AABAAgAAkBUAAMAJAAAPAATwqwAAAKIMCvAIAAAAH8QAAAIKAACDAAvwMAAAAIAAZJGJAb8AAgAC AIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAD/AQAAAAQBEAAGwCAABgFQAA FwQAAA8ADfBDAAAAAACfDwQAAAAEAAAAAACoDw0AAABDb2xsZWN0aW9uIEMyAAChDxoAAAAOAAAA AAAAKAAAAQAyAA4AAAAAAAMAAQAOAA8ABPBgAAAAEgAK8AgAAAAgxAAAAgoAAIMAC/AwAAAAhQAC AAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAP8BAAAADQCwAA 4AcAAEARAAAgCgAADwAE8KUAAACiDArwCAAAACHEAAACCgAAgwAL8DAAAACAAJCViQG/AAIAAgCB AQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAAA/wEAAAANALAADgBwAA0A4AAKAI AAAPAA3wPQAAAAAAnw8EAAAABAAAAAAAqA8JAAAAQmluZGluZ3M6AAChDxgAAAAKAAAAAAAAIAAA MgAKAAAAAAADAAEADgAPAATwmwAAAKIMCvAIAAAAIsQAAAIKAABzAAvwKgAAAIAA2JiJAb8AAgAC AIEB//+ZAL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAD/AQAAAAAAwAANAIAACwDQAAlgkAAA8A DfA5AAAAAACfDwQAAAAEAAAAAACoDwMAAABGb28AAKEPGgAAAAQAAAAAAAAoAAABADIABAAAAAAA AwABAA4ADwAE8FoAAABCAQrwCAAAACPEAAACCgAAcwAL8CoAAABEAQQAAAB/AQAAAQC/AQAAEADA AQEAAAjRAQEAAAD/ARgAGAABAgIAAAgAAA/wEAAAAIANAABQCgAAgA0AAJAMAAAPAATwWgAAAEIB CvAIAAAAJMQAAAIKAABzAAvwKgAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACNEBAQAAAP8BGAAY AAECAgAACAAAD/AQAAAAIA0AAHAFAAAgDQAAsAcAAA8ABPBaAAAAQgEK8AgAAAAlxAAAAgoAAHMA C/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0QEBAAAA/wEYABgAAQICAAAIAAAP8BAAAADw BgAAUAoAAGAMAACQDAAADwAE8FoAAABCAQrwCAAAACbEAAACCgAAcwAL8CoAAABEAQQAAAB/AQAA AQC/AQAAEADAAQEAAAjRAQEAAAD/ARgAGAABAgIAAAgAAA/wEAAAAOAEAABQCgAA4AQAAJAMAAAP AATwWgAAAEIBCvAIAAAAJ8QAAAIKAABzAAvwKgAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACNEB AQAAAP8BGAAYAAECAgAACAAAD/AQAAAA0AgAAHAFAADQCAAAsAcAAA8ABPBaAAAAQgEK8AgAAAAo xAAAQgoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0QEBAAAA/wEYABgAAQICAAAI AAAP8BAAAABgCQAAcAUAAOAKAACwBwAADwAE8M4AAACiDArwCAAAACnEAAAACgAAgwAL8DAAAACA ADCdiQG/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAANAC AA8AFfEFDwAN8G4AAAAAAJ8PBAAAAAQAAAAAAKgPOgAAAFNvIFIyIGNhbiBiZSBhY2Nlc3NlZCBh czoNL0NvbGwxL0Jhcg0vQ29sbDIvQmFyDS9Db2xsMy9Gb28AAKEPGAAAADsAAAAAAAAgAAAyADsA AAAAAAMAAQAOAA8ABPBIAAAAEgAK8AgAAAABxAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGO n4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAA AMyZADMzzADMzP8AsrKyAA8A7gOyBAAAAgDvAxgAAAAQAAAAAAAAAAAAAAAAAACAAAAAAAcAAAAP AAwEYgQAAA8AAvBaBAAAYAAI8AgAAAADAAAAK9AAAA8AA/DyAwAADwAE8CgAAAABAAnwEAAAAAAA AAAAAAAAAAAAAAAAAAACAArwCAAAAADQAAAFAAAADwAE8LYAAAASAArwCAAAAALQAAAgAgAAYwAL 8CQAAAB/AAAABACAAISmiQG/AQAAAQD/AQAAAQABAwoEAACIAwAAAAAAABDwCAAAADAAkAAgFhAC DwAR8BAAAAAAAMMLCAAAAP////8NAIkBDwAN8EoAAAAAAJ8PBAAAAAAAAAAAAKgPGAAAAFBvc3Np YmxlIEludGVycHJldGF0aW9ucwAAoQ8WAAAAGQAAAAAAAAAAABkAAAAAAAMAAQAgAA8ABPD8AgAA ogwK8AgAAAAr0AAAAAoAAIMAC/AwAAAAgACkqYkBvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEB AAAI/wEAAAgAAQICAAAIAAAQ8AgAAABwAuABQBQgDg8ADfCcAgAAAACfDwQAAAAEAAAAAACoD+4B AABUaGUgZGVmaW5pdGlvbiBvZiB0aGUgYmluZGluZ3MgcHJvcGVydHkgaXMgcmVhbGx5IG1pc2xl YWRpbmcsIEkgY2FuIHRoaW5rIG9mIHRocmVlIHBvc3NpYmxlIGltcGxlbWVudGF0aW9ucyBvZiB0 aGF0IHByb3BlcnR5Og1UaGUgYmluZGluZ3MgcHJvcGVydHkgY29udGFpbnMgYWxsIHBvc3NpYmxl IGhyZWZzIGFuZCBzZWdtZW50IG5hbWVzIGZvciB0aGUgcmVzb3VyY2UuDVRoZSBiaW5kaW5ncyBw cm9wZXJ0eSBjb250YWlucyBhbGwgcG9zc2libGUgc2VnbWVudCBuYW1lcyBidXQgb25seSBvbmUg aHJlZiBwZXIgY29sbGVjdGlvbi4NVGhlIGJpbmRpbmdzIHByb3BlcnR5IG9ubHkgY29udGFpbnMg dGhlIGJpbmRpbmdzIGdpdmVuIHRoZSBwYXJlbnQgY29sbGVjdGlvbiBvZiB0aGUgUFJPUEZJTkQg cmVxdWVzdC4NDUkgbm93IHRoaW5rIHRoYXQgb3B0aW9uIDIgKG9ubHkgb25lIGhyZWYgZm9yIHRo ZSBjb2xsZWN0aW9uKSBpcyB0aGUgY29ycmVjdCBkZWZpbml0aW9uIQAAoQ9MAAAAfgAAAAAAACAA ADIAGQEAAAAAASAAAAEAMgBYAAAAAAAAIAAAMgB+AAAAAAADAAEAFAAZAQAAAAABAAEAWAAAAAAA BwABABQAAAAABQAAqg8+AAAAqgAAAAAAAAAFAAAAAQAAAAMAbAAAAAAAAAAFAAAAAQAAAAMAmwAA AAAAAAAFAAAAAQAAAAMALwAAAAAAAAAPAATwSAAAABIACvAIAAAAAdAAAAAMAACDAAvwMAAAAIEB AAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA//// AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAO4D1BgAAAIA7wMYAAAAEAAAAAAAAAAAAAAA AAAAgAAAAAAHAAAADwAMBIQYAAAPAALwfBgAAHAACPAIAAAAKgAAACzIAAAgABjxCAAAAAEAAAAC AAAADwAD8AQYAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAMgAAAUA AAAPAATw0QAAABIACvAIAAAAAsgAACACAABjAAvwJAAAAH8AAAAEAIAACLmJAb8BAAABAP8BAAAB AAEDCgQAAIgDAAAAAAAAEPAIAAAAMACQACAWEAIPABHwEAAAAAAAwwsIAAAA/////w0AiQEPAA3w ZQAAAAAAnw8EAAAAAAAAAAAAqA8RAAAAQWxsIHBvc3NpYmxlIFVSSXMAAKEPFgAAABIAAAAAAAAA AAASAAAAAAADAAEAIAAAAKoPGgAAAA0AAAAAAAAABAAAAAEAAAADAAEAAAAAAAAADwAE8DYCAACi DArwCAAAACvIAAAACgAAgwAL8DAAAACAACT5iQG/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEA AAj/AQgACAABAgIAAAgAABDwCAAAAOkMMADwFTAPDwAN8NYBAAAAAJ8PBAAAAAQAAAAAAKAPogEA AFQAaABlACAAZABlAGYAaQBuAGkAdABpAG8AbgAgAG8AZgAgAHQAaABlACAAYgBpAG4AZABpAG4A ZwBzACAAcAByAG8AcABlAHIAdAB5ACAAcwB0AGEAdABlAHMAIAB0AGgAYQB0ACAAaQB0ACAAYwBv AG4AdABhAGkAbgBzACAAHCBhACAAYwBvAG0AcABsAGUAdABlACAAbABpAHMAdAAgAG8AZgAgAGEA bABsACAAYgBpAG4AZABpAG4AZwBzACAAdABvACAAdABoAGEAdAAgAHIAZQBzAG8AdQByAGMAZQAd IC4AIAAgAFMAbwAgABwgYwBvAG0AcABsAGUAdABlAB0gIAB3AG8AdQBsAGQAIABpAG0AcABsAHkA IABhAGwAbAAgAHAAbwBzAHMAaQBiAGwAZQAgAFUAUgBJACAAcABhAHQAaABzACAAdABoAGEAdAAg AGMAbwB1AGwAZAAgAGIAZQAgAHUAcwBlAGQAIAB0AG8AIABhAGMAYwBlAHMAcwAgAHQAaABhAHQA IAByAGUAcwBvAHUAcgBjAGUALgAAAKEPGAAAANIAAAAAAAAgAAAyANIAAAAAAAMAAQASAA8AA/DK EgAADwAE8DgAAAABAAnwEAAAAPAAAADQAgAAkA8AAGAMAAACAArwCAAAACzIAAABAgAAAAAQ8AgA AADQAvAAkA9gDA8AA/B1AQAADwAE8FQAAAABAAnwEAAAAEARAABAAgAAkBUAAMAJAAACAArwCAAA AATIAAADAgAAIwAL8AwAAAAEAAAAAACIAwIAAAAAAA/wEAAAAPAAAAAQCwAAwAYAAGAMAAAPAATw YAAAABIACvAIAAAABcgAAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQ AMABAQAACP8BCAAIAAECAgAACAAAD/AQAAAAQBEAAEACAACQFQAAwAkAAA8ABPCpAAAAogwK8AgA AAAGyAAAAgoAAIMAC/AwAAAAgABYvYkBvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEA AAgAAQICAAAIAAAP8BAAAABAEQAAbgIAAGAVAAC3BgAADwAN8EEAAAAAAJ8PBAAAAAQAAAAAAKgP CwAAAFJlc291cmNlIFIxAAChDxoAAAAMAAAAAAAAKAAAAQAyAAwAAAAAAAMAAQAOAA8AA/B1AQAA DwAE8FQAAAABAAnwEAAAAEARAABAAgAAkBUAAMAJAAACAArwCAAAAAfIAAADAgAAIwAL8AwAAAAE AAAAAACIAwIAAAAAAA/wEAAAAMAJAAAQCwAAkA8AAGAMAAAPAATwYAAAABIACvAIAAAACMgAAAIK AACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAA CAAAD/AQAAAAQBEAAEACAACQFQAAwAkAAA8ABPCpAAAAogwK8AgAAAAJyAAAAgoAAIMAC/AwAAAA gAAIwYkBvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAP8BAAAABA EQAAbgIAAGAVAAC3BgAADwAN8EEAAAAAAJ8PBAAAAAQAAAAAAKgPCwAAAFJlc291cmNlIFIyAACh DxoAAAAMAAAAAAAAKAAAAQAyAAwAAAAAAAMAAQAOAA8AA/A/BQAADwAE8FQAAAABAAnwEAAAAEAI AABAAgAA0A4AAKAFAAACAArwCAAAAArIAAADAgAAIwAL8AwAAAAEAAAAAACIAwIAAAAAAA/wEAAA ABAFAADQAgAAoAsAADAGAAAPAAPweQEAAA8ABPBUAAAAAQAJ8BAAAABAEQAAQAIAAJAVAADACQAA AgAK8AgAAAALyAAAAwIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAABACAAAQAIAANAOAACg BQAADwAE8GAAAAASAArwCAAAAAzIAAACCgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiDAQAA AAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAAA/wEAAAAEARAABAAgAAkBUAAMAJAAAPAATwrQAA AKIMCvAIAAAADcgAAAIKAACDAAvwMAAAAIAA4MSJAb8AAgACAIEBBAAACIMBAAAACL8BAAAQAMAB AQAACP8BAAAIAAECAgAACAAAD/AQAAAAQBEAAGwCAABgFQAAFwQAAA8ADfBFAAAAAACfDwQAAAAE AAAAAACoDw8AAABSb290IENvbGxlY3Rpb24AAKEPGgAAABAAAAAAAAAoAAABADIAEAAAAAAAAwAB AA4ADwAD8FoDAAAPAATwTgAAAAEACfAQAAAAcAgAADADAACgDgAAcAUAAAIACvAIAAAADsgAAAMC AAATAAvwBgAAAIgDAAAAAAAAD/AQAAAAcAgAADADAACgDgAAcAUAAA8ABPBgAAAAEgAK8AgAAAAP yAAAAgoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgA AQICAAAIAAAP8BAAAABwCAAAMAMAAKAOAABwBQAADwAE8KUAAACiDArwCAAAABDIAAACCgAAgwAL 8DAAAACAAETJiQG/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAAA/w EAAAAHAIAAAwAwAAcAsAAPADAAAPAA3wPQAAAAAAnw8EAAAABAAAAAAAqA8JAAAAQmluZGluZ3M6 AAChDxgAAAAKAAAAAAAAIAAAMgAKAAAAAAADAAEADgAPAATwnQAAAKIMCvAIAAAAEcgAAAIKAABz AAvwKgAAAIAAcM2JAb8AAgACAIEB//+ZAL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAD/AQAAAA oAgAACAEAABQCgAA5gQAAA8ADfA7AAAAAACfDwQAAAAEAAAAAACoDwUAAABDb2xsMQAAoQ8aAAAA BgAAAAAAACgAAAEAMgAGAAAAAAADAAEADgAPAATwnQAAAKIMCvAIAAAAEsgAAAIKAABzAAvwKgAA AIAAnNCJAb8AAgACAIEB//+ZAL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAD/AQAAAAsAoAACAE AABgDAAA5gQAAA8ADfA7AAAAAACfDwQAAAAEAAAAAACoDwUAAABDb2xsMgAAoQ8aAAAABgAAAAAA ACgAAAEAMgAGAAAAAAADAAEADgAPAATwnQAAAKIMCvAIAAAAE8gAAAIKAABzAAvwKgAAAIAA2NOJ Ab8AAgACAIEB//+ZAL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAD/AQAAAAwAwAACAEAABwDgAA 5gQAAA8ADfA7AAAAAACfDwQAAAAEAAAAAACoDwUAAABDb2xsMwAAoQ8aAAAABgAAAAAAACgAAAEA MgAGAAAAAAADAAEADgAPAAPwNgQAAA8ABPBUAAAAAQAJ8BAAAADQAgAA8AYAAKAIAABQCgAAAgAK 8AgAAAAUyAAAAwIAACMAC/AMAAAABAAAAAAAiAMCAAAAAAAP8BAAAADwAAAAwAYAAMAGAAAgCgAA DwAD8HcBAAAPAATwVAAAAAEACfAQAAAAQBEAAEACAACQFQAAwAkAAAIACvAIAAAAFcgAAAMCAAAj AAvwDAAAAAQAAAAAAIgDAAAAAAAAD/AQAAAA0AIAAPAGAACgCAAAUAoAAA8ABPBgAAAAEgAK8AgA AAAWyAAAAgoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEI AAgAAQICAAAIAAAP8BAAAABAEQAAQAIAAJAVAADACQAADwAE8KsAAACiDArwCAAAABfIAAACCgAA gwAL8DAAAACAAHTXiQG/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgA AA/wEAAAAEARAABsAgAAYBUAABcEAAAPAA3wQwAAAAAAnw8EAAAABAAAAAAAqA8NAAAAQ29sbGVj dGlvbiBDMQAAoQ8aAAAADgAAAAAAACgAAAEAMgAOAAAAAAADAAEADgAPAATwYAAAABIACvAIAAAA GMgAAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAI AAECAgAACAAAD/AQAAAAAAMAAOAHAABwCAAAIAoAAA8ABPClAAAAogwK8AgAAAAZyAAAAgoAAIMA C/AwAAAAgABo24kBvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAP 8BAAAAAAAwAA4AcAAAAGAACgCAAADwAN8D0AAAAAAJ8PBAAAAAQAAAAAAKgPCQAAAEJpbmRpbmdz OgAAoQ8YAAAACgAAAAAAACAAADIACgAAAAAAAwABAA4ADwAE8JsAAACiDArwCAAAABrIAAACCgAA cwAL8CoAAACAANyeiQG/AAIAAgCBAf//mQC/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAAA/wEAAA ADADAADQCAAA4AQAAJYJAAAPAA3wOQAAAAAAnw8EAAAABAAAAAAAqA8DAAAARm9vAAChDxoAAAAE AAAAAAAAKAAAAQAyAAQAAAAAAAMAAQAOAA8ABPCbAAAAogwK8AgAAAAbyAAAAgoAAHMAC/AqAAAA gAAk4okBvwACAAIAgQH//5kAvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAP8BAAAABABQAA0AgA APAGAACWCQAADwAN8DkAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAEJhcgAAoQ8aAAAABAAAAAAAACgA AAEAMgAEAAAAAAADAAEADgAPAAPwkwMAAA8ABPBUAAAAAQAJ8BAAAACgCwAA8AYAAHARAABQCgAA AgAK8AgAAAAcyAAAAwIAACMAC/AMAAAABAAAAAAAiAMCAAAAAAAP8BAAAADACQAAwAYAAJAPAAAg CgAADwAD8HcBAAAPAATwVAAAAAEACfAQAAAAQBEAAEACAACQFQAAwAkAAAIACvAIAAAAHcgAAAMC AAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAD/AQAAAAoAsAAPAGAABwEQAAUAoAAA8ABPBgAAAAEgAK 8AgAAAAeyAAAAgoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI /wEIAAgAAQICAAAIAAAP8BAAAABAEQAAQAIAAJAVAADACQAADwAE8KsAAACiDArwCAAAAB/IAAAC CgAAgwAL8DAAAACAADzliQG/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIA AAgAAA/wEAAAAEARAABsAgAAYBUAABcEAAAPAA3wQwAAAAAAnw8EAAAABAAAAAAAqA8NAAAAQ29s bGVjdGlvbiBDMgAAoQ8aAAAADgAAAAAAACgAAAEAMgAOAAAAAAADAAEADgAPAATwYAAAABIACvAI AAAAIMgAAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8B CAAIAAECAgAACAAAD/AQAAAA0AsAAOAHAABAEQAAIAoAAA8ABPClAAAAogwK8AgAAAAhyAAAAgoA AIMAC/AwAAAAgABYz4kBvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAI AAAP8BAAAADQCwAA4AcAANAOAACgCAAADwAN8D0AAAAAAJ8PBAAAAAQAAAAAAKgPCQAAAEJpbmRp bmdzOgAAoQ8YAAAACgAAAAAAACAAADIACgAAAAAAAwABAA4ADwAE8JsAAACiDArwCAAAACLIAAAC CgAAcwAL8CoAAACAAPDsiQG/AAIAAgCBAf//mQC/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAAA/w EAAAAAAMAADQCAAAsA0AAJYJAAAPAA3wOQAAAAAAnw8EAAAABAAAAAAAqA8DAAAARm9vAAChDxoA AAAEAAAAAAAAKAAAAQAyAAQAAAAAAAMAAQAOAA8ABPBgAAAAQgEK8AgAAAAkyAAAAgoAAIMAC/Aw AAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0QEBAAAA/wEYABgAAQICAAAIiAMCAAAAAAAP8BAA AACACgAAcAUAAIAKAADABgAADwAE8GAAAABCAQrwCAAAACfIAAACCgAAgwAL8DAAAABEAQQAAAB/ AQAAAQC/AQAAEADAAQEAAAjRAQEAAAD/ARgAGAABAgIAAAiIAwIAAAAAAA/wEAAAADAGAABwBQAA MAYAAMAGAAAPAATwYAAAAEIBCvAIAAAAKMgAAEIKAACDAAvwMAAAAEQBBAAAAH8BAAABAL8BAAAQ AMABAQAACNEBAQAAAP8BGAAYAAECAgAACIgDAgAAAAAAD/AQAAAAwAYAAHAFAABACAAAwAYAAA8A BPBgAAAAQgEK8AgAAAAlyAAAAgoAAIMAC/AwAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0QEB AAAA/wEYABgAAQICAAAIiAMCAAAAAAAP8BAAAAAgBAAAYAkAAMAJAAAQCwAADwAE8GAAAABCAQrw CAAAACbIAAACCgAAgwAL8DAAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjRAQEAAAD/ARgAGAAB AgIAAAiIAwIAAAAAAA/wEAAAAEACAABgCQAAQAIAABALAAAPAATwYAAAAEIBCvAIAAAAI8gAAAIK AACDAAvwMAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACNEBAQAAAP8BGAAYAAECAgAACIgDAgAA AAAAD/AQAAAA4AoAAGAJAADgCgAAEAsAAA8ABPDjAQAAogwK8AgAAAApyAAAAAoAAHMAC/AqAAAA gABI8IkBvwACAAIAgQEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAADQAnAOABVk Cg8ADfCJAQAAAACfDwQAAAAEAAAAAACoD7sAAABQUk9QRklORCAvQ29sbDIvQmFyIHdpbGwgcmV0 dXJuOg08YmluZGluZ3M+DTxocmVmPi9Db2xsMi88L2hyZWY+DTxzZWdtZW50PkJhcjwvc2VnbWVu dD4NPGhyZWY+L0NvbGwxLzwvaHJlZj4NPHNlZ21lbnQ+QmFyPC9zZWdtZW50Pg08aHJlZj4vQ29s bDMvPC9ocmVmPg08c2VnbWVudD5Gb288L3NlZ21lbnQ+DTwvYmluZGluZ3M+AAChDyQAAAC8AAAA AAAAIAAAMgAhAAAAAAADAAEADgCbAAAAAAADAAIADgAAAKoPhgAAAC0AAAAAAAAABAAAAAEAAAAD AAoAAAAAAAAABAAAAAEAAAADABoAAAAAAAAABAAAAAEAAAADAAoAAAAAAAAABAAAAAEAAAADABoA AAAAAAAABAAAAAEAAAADAAoAAAAAAAAABAAAAAEAAAADAAsAAAAAAAAAAwAAAAEAAAADABcAAAAA AAAADwAE8EgAAAASAArwCAAAAAHIAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69 aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPM AMzM/wCysrIADwDuA4gZAAACAO8DGAAAABAAAAAAAAAAAAAAAAAAAIAAAAAABwAAAA8ADAQ4GQAA DwAC8DAZAACAAAjwCAAAACoAAAB2zAAADwAD8MgYAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAA AAAAAAAAAAIACvAIAAAAAMwAAAUAAAAPAATwvQAAABIACvAIAAAAAswAACACAABjAAvwJAAAAH8A AAAEAIAAYAKLAb8BAAABAP8BAAABAAEDCgQAAIgDAAAAAAAAEPAIAAAAMACQACAWEAIPABHwEAAA AAAAwwsIAAAA/////w0AiwEPAA3wUQAAAAAAnw8EAAAAAAAAAAAAqA8fAAAAT25seSBvbmUgVVJJ IGZvciB0aGUgY29sbGVjdGlvbgAAoQ8WAAAAIAAAAAAAAAAAACAAAAAAAAMAAQAgAA8ABPB0AwAA ogwK8AgAAABQzAAAAAoAAIMAC/AwAAAAgADgQosBvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEB AAAI/wEIAAgAAQICAAAIAAAQ8AgAAAAwDDAA8BXRDw8ADfAUAwAAAACfDwQAAAAEAAAAAACgD+AC AABUAGgAZQAgAGQAZQBmAGkAbgBpAHQAaQBvAG4AIABvAGYAIAB0AGgAZQAgAGIAaQBuAGQAaQBu AGcAcwAgAHAAcgBvAHAAZQByAHQAeQAgAHMAdABhAHQAZQBzACAAdABoAGEAdAAgABwgaQB0ACAA aQBzACAAbgBlAGMAZQBzAHMAYQByAHkAIAB0AG8AIABzAGUAbABlAGMAdAAgAG8AbgBlACAAVQBS AEkAIABtAGEAcABwAGkAbgBnACAAZgBvAHIAIAB0AGgAZQAgAGMAbwBsAGwAZQBjAHQAaQBvAG4A HSAuACAAIABTAG8AIAB0AGgAaQBzACAAcwBlAGUAbQBzACAAdABvACAAaQBtAHAAbAB5ACAAdABo AGEAdAAgAGkAZgAgAGEAIABjAG8AbABsAGUAYwB0AGkAbwBuACAAaABhAHMAIABhACAAYgBpAG4A ZABpAG4AZwAgAHQAbwAgAHQAaABpAHMAIAByAGUAcwBvAHUAcgBjAGUAIABiAHUAdAAgAHQAaABh AHQAIABjAG8AbABsAGUAYwB0AGkAbwBuACAAaQB0AHMAZQBsAGYAIABoAGEAcwAgAG0AdQBsAHQA aQBwAGwAZQAgAGIAaQBuAGQAaQBuAGcAcwAgAHQAbwAgAGkAdAAgAHQAaABlAG4AIAB5AG8AdQAg AG0AdQBzAHQAIABwAGkAYwBrACAAbwBuAGUAIABVAFIASQAgAGYAbwByACAAdABoAGEAdAAgAGMA bwBsAGwAZQBjAHQAaQBvAG4AIAAoAHAAcgBlAGYAZQByAGEAYgBsAHkAIAB0AGgAZQAgAG8AbgBl ACAAdQBzAGUAZAAgAHcAaABlAG4AIAB0AGgAZQAgAHIAZQBzAG8AdQByAGMAZQAgAHcAYQBzACAA YgBvAHUAbgBkACAAaQBuAHQAbwAgAHQAaABlACAAYwBvAGwAbABlAGMAdABpAG8AbgApAC4AAACh DxgAAABxAQAAAAAAIAAAMgBxAQAAAAADAAEAEgAPAAPwtBIAAA8ABPBGAAAAAQAJ8BAAAADwAAAA 0AIAAJAPAABgDAAAAgAK8AgAAABRzAAAAQIAABMAC/AGAAAAiAMAAAAAAAAQ8AgAAABAAvAAkA/Q Cw8AA/B1AQAADwAE8FQAAAABAAnwEAAAAEARAABAAgAAkBUAAMAJAAACAArwCAAAAFLMAAADAgAA IwAL8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAAPAAAAAQCwAAwAYAAGAMAAAPAATwYAAAABIACvAI AAAAU8wAAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8B CAAIAAECAgAACAAAD/AQAAAAQBEAAEACAACQFQAAwAkAAA8ABPCpAAAAogwK8AgAAABUzAAAAgoA AIMAC/AwAAAAgADMzIsBvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAI AAAP8BAAAABAEQAAbgIAAGAVAAC3BgAADwAN8EEAAAAAAJ8PBAAAAAQAAAAAAKgPCwAAAFJlc291 cmNlIFIxAAChDxoAAAAMAAAAAAAAKAAAAQAyAAwAAAAAAAMAAQAOAA8AA/B1AQAADwAE8FQAAAAB AAnwEAAAAEARAABAAgAAkBUAAMAJAAACAArwCAAAAFXMAAADAgAAIwAL8AwAAAAEAAAAAACIAwAA AAAAAA/wEAAAAMAJAAAQCwAAkA8AAGAMAAAPAATwYAAAABIACvAIAAAAVswAAAIKAACDAAvwMAAA AIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAD/AQAAAA QBEAAEACAACQFQAAwAkAAA8ABPCpAAAAogwK8AgAAABXzAAAAgoAAIMAC/AwAAAAgADkwYsBvwAC AAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAP8BAAAABAEQAAbgIAAGAV AAC3BgAADwAN8EEAAAAAAJ8PBAAAAAQAAAAAAKgPCwAAAFJlc291cmNlIFIyAAChDxoAAAAMAAAA AAAAKAAAAQAyAAwAAAAAAAMAAQAOAA8AA/A/BQAADwAE8FQAAAABAAnwEAAAAEAIAABAAgAA0A4A AKAFAAACAArwCAAAAFjMAAADAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAABAFAADQAgAA oAsAADAGAAAPAAPweQEAAA8ABPBUAAAAAQAJ8BAAAABAEQAAQAIAAJAVAADACQAAAgAK8AgAAABZ zAAAAwIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAABACAAAQAIAANAOAACgBQAADwAE8GAA AAASAArwCAAAAFrMAAACCgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/ARAAEADA AQEAAAj/AQgACAABAgIAAAgAAA/wEAAAAEARAABAAgAAkBUAAMAJAAAPAATwrQAAAKIMCvAIAAAA W8wAAAIKAACDAAvwMAAAAIAA8FD1Ar8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAI AAECAgAACAAAD/AQAAAAQBEAAGwCAABgFQAAFwQAAA8ADfBFAAAAAACfDwQAAAAEAAAAAACoDw8A AABSb290IENvbGxlY3Rpb24AAKEPGgAAABAAAAAAAAAoAAABADIAEAAAAAAAAwABAA4ADwAD8FoD AAAPAATwTgAAAAEACfAQAAAAcAgAADADAACgDgAAcAUAAAIACvAIAAAAXMwAAAMCAAATAAvwBgAA AIgDAAAAAAAAD/AQAAAAcAgAADADAACgDgAAcAUAAA8ABPBgAAAAEgAK8AgAAABdzAAAAgoAAIMA C/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAP 8BAAAABwCAAAMAMAAKAOAABwBQAADwAE8KUAAACiDArwCAAAAF7MAAACCgAAgwAL8DAAAACAAJBS 9QK/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAAA/wEAAAAHAIAAAw AwAAcAsAAPADAAAPAA3wPQAAAAAAnw8EAAAABAAAAAAAqA8JAAAAQmluZGluZ3M6AAChDxgAAAAK AAAAAAAAIAAAMgAKAAAAAAADAAEADgAPAATwnQAAAKIMCvAIAAAAX8wAAAIKAABzAAvwKgAAAIAA /FP1Ar8AAgACAIEB//+ZAL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAD/AQAAAAoAgAACAEAABQ CgAA5gQAAA8ADfA7AAAAAACfDwQAAAAEAAAAAACoDwUAAABDb2xsMQAAoQ8aAAAABgAAAAAAACgA AAEAMgAGAAAAAAADAAEADgAPAATwnQAAAKIMCvAIAAAAYMwAAAIKAABzAAvwKgAAAIAAYFn1Ar8A AgACAIEB//+ZAL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAD/AQAAAAsAoAACAEAABgDAAA5gQA AA8ADfA7AAAAAACfDwQAAAAEAAAAAACoDwUAAABDb2xsMgAAoQ8aAAAABgAAAAAAACgAAAEAMgAG AAAAAAADAAEADgAPAATwnQAAAKIMCvAIAAAAYcwAAAIKAABzAAvwKgAAAIAAEF/1Ar8AAgACAIEB //+ZAL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAD/AQAAAAwAwAACAEAABwDgAA5gQAAA8ADfA7 AAAAAACfDwQAAAAEAAAAAACoDwUAAABDb2xsMwAAoQ8aAAAABgAAAAAAACgAAAEAMgAGAAAAAAAD AAEADgAPAAPwNgQAAA8ABPBUAAAAAQAJ8BAAAADQAgAA8AYAAKAIAABQCgAAAgAK8AgAAABizAAA AwIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAADwAAAAwAYAAMAGAAAgCgAADwAD8HcBAAAP AATwVAAAAAEACfAQAAAAQBEAAEACAACQFQAAwAkAAAIACvAIAAAAY8wAAAMCAAAjAAvwDAAAAAQA AAAAAIgDAAAAAAAAD/AQAAAA0AIAAPAGAACgCAAAUAoAAA8ABPBgAAAAEgAK8AgAAABkzAAAAgoA AIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAI AAAP8BAAAABAEQAAQAIAAJAVAADACQAADwAE8KsAAACiDArwCAAAAGXMAAACCgAAgwAL8DAAAACA AOBf9QK/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAAA/wEAAAAEAR AABsAgAAYBUAABcEAAAPAA3wQwAAAAAAnw8EAAAABAAAAAAAqA8NAAAAQ29sbGVjdGlvbiBDMQAA oQ8aAAAADgAAAAAAACgAAAEAMgAOAAAAAAADAAEADgAPAATwYAAAABIACvAIAAAAZswAAAIKAACD AAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAA D/AQAAAAAAMAAOAHAABwCAAAIAoAAA8ABPClAAAAogwK8AgAAABnzAAAAgoAAIMAC/AwAAAAgACQ Y/UCvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAP8BAAAAAAAwAA 4AcAAAAGAACgCAAADwAN8D0AAAAAAJ8PBAAAAAQAAAAAAKgPCQAAAEJpbmRpbmdzOgAAoQ8YAAAA CgAAAAAAACAAADIACgAAAAAAAwABAA4ADwAE8JsAAACiDArwCAAAAGjMAAACCgAAcwAL8CoAAACA ANxm9QK/AAIAAgCBAf//mQC/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAAA/wEAAAADADAADQCAAA 4AQAAJYJAAAPAA3wOQAAAAAAnw8EAAAABAAAAAAAqA8DAAAARm9vAAChDxoAAAAEAAAAAAAAKAAA AQAyAAQAAAAAAAMAAQAOAA8ABPCbAAAAogwK8AgAAABpzAAAAgoAAHMAC/AqAAAAgACQavUCvwAC AAIAgQH//5kAvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAP8BAAAABABQAA0AgAAPAGAACWCQAA DwAN8DkAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAEJhcgAAoQ8aAAAABAAAAAAAACgAAAEAMgAEAAAA AAADAAEADgAPAAPwkwMAAA8ABPBUAAAAAQAJ8BAAAACgCwAA8AYAAHARAABQCgAAAgAK8AgAAABq zAAAAwIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAADACQAAwAYAAJAPAAAgCgAADwAD8HcB AAAPAATwVAAAAAEACfAQAAAAQBEAAEACAACQFQAAwAkAAAIACvAIAAAAa8wAAAMCAAAjAAvwDAAA AAQAAAAAAIgDAAAAAAAAD/AQAAAAoAsAAPAGAABwEQAAUAoAAA8ABPBgAAAAEgAK8AgAAABszAAA AgoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQIC AAAIAAAP8BAAAABAEQAAQAIAAJAVAADACQAADwAE8KsAAACiDArwCAAAAG3MAAACCgAAgwAL8DAA AACAAPBo9QK/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAAA/wEAAA AEARAABsAgAAYBUAABcEAAAPAA3wQwAAAAAAnw8EAAAABAAAAAAAqA8NAAAAQ29sbGVjdGlvbiBD MgAAoQ8aAAAADgAAAAAAACgAAAEAMgAOAAAAAAADAAEADgAPAATwYAAAABIACvAIAAAAbswAAAIK AACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAA CAAAD/AQAAAA0AsAAOAHAABAEQAAIAoAAA8ABPClAAAAogwK8AgAAABvzAAAAgoAAIMAC/AwAAAA gACocPUCvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAP8BAAAADQ CwAA4AcAANAOAACgCAAADwAN8D0AAAAAAJ8PBAAAAAQAAAAAAKgPCQAAAEJpbmRpbmdzOgAAoQ8Y AAAACgAAAAAAACAAADIACgAAAAAAAwABAA4ADwAE8JsAAACiDArwCAAAAHDMAAACCgAAcwAL8CoA AACAAAh09QK/AAIAAgCBAf//mQC/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAAA/wEAAAAAAMAADQ CAAAsA0AAJYJAAAPAA3wOQAAAAAAnw8EAAAABAAAAAAAqA8DAAAARm9vAAChDxoAAAAEAAAAAAAA KAAAAQAyAAQAAAAAAAMAAQAOAA8ABPBaAAAAQgEK8AgAAABxzAAAAgoAAHMAC/AqAAAARAEEAAAA fwEAAAEAvwEAABAAwAEBAAAI0QEBAAAA/wEYABgAAQICAAAIAAAP8BAAAACACgAAcAUAAIAKAADA BgAADwAE8FoAAABCAQrwCAAAAHLMAAACCgAAcwAL8CoAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEA AAjRAQEAAAD/ARgAGAABAgIAAAgAAA/wEAAAADAGAABwBQAAMAYAAMAGAAAPAATwWgAAAEIBCvAI AAAAc8wAAEIKAABzAAvwKgAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACNEBAQAAAP8BGAAYAAEC AgAACAAAD/AQAAAAwAYAAHAFAABACAAAwAYAAA8ABPBaAAAAQgEK8AgAAAB0zAAAAgoAAHMAC/Aq AAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0QEBAAAA/wEYABgAAQICAAAIAAAP8BAAAAAgBAAA YAkAAMAJAAAQCwAADwAE8FoAAABCAQrwCAAAAHXMAAACCgAAcwAL8CoAAABEAQQAAAB/AQAAAQC/ AQAAEADAAQEAAAjRAQEAAAD/ARgAGAABAgIAAAgAAA/wEAAAAEACAABgCQAAQAIAABALAAAPAATw WgAAAEIBCvAIAAAAdswAAAIKAABzAAvwKgAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACNEBAQAA AP8BGAAYAAECAgAACAAAD/AQAAAA4AoAAGAJAADgCgAAEAsAAA8ABPCTAQAAogwK8AgAAAApzAAA AAoAAHMAC/AqAAAAgADUO4sBvwACAAIAgQEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ 8AgAAADQAnAOABXSCA8ADfA5AQAAAACfDwQAAAAEAAAAAACoD48AAABQUk9QRklORCAvQ29sbDIv QmFyIHdpbGwgcmV0dXJuOg08YmluZGluZ3M+DTxocmVmPi9Db2xsMi88L2hyZWY+DTxzZWdtZW50 PkJhcjwvc2VnbWVudD4NPGhyZWY+L0NvbGwzLzwvaHJlZj4NPHNlZ21lbnQ+Rm9vPC9zZWdtZW50 Pg08L2JpbmRpbmdzPgAAoQ8kAAAAkAAAAAAAACAAADIAIQAAAAAAAwABAA4AbwAAAAAAAwACAA4A AACqD2IAAAAtAAAAAAAAAAQAAAABAAAAAwAKAAAAAAAAAAQAAAABAAAAAwAaAAAAAAAAAAQAAAAB AAAAAwAKAAAAAAAAAAQAAAABAAAAAwALAAAAAAAAAAMAAAABAAAAAwAXAAAAAAAAAA8ABPBIAAAA EgAK8AgAAAABzAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEA AAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A 7gNyGAAAAgDvAxgAAAAQAAAAAAAAAAAAAAAAAACAAAAAAAcAAAAPAAwEIhgAAA8AAvAaGAAAIAAI 8AgAAAAqAAAAdtQAAA8AA/CyFwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArw CAAAAADUAAAFAAAADwAE8LEAAAASAArwCAAAAALUAAAgAgAAYwAL8CQAAAB/AAAABACAALCivAC/ AQAAAQD/AQAAAQABAwoEAACIAwAAAAAAABDwCAAAADAAkAAgFhACDwAR8BAAAAAAAMMLCAAAAP// //8NALwADwAN8EUAAAAAAJ8PBAAAAAAAAAAAAKgPEwAAAE9ubHkgb25lIGNvbGxlY3Rpb24AAKEP FgAAABQAAAAAAAAAAAAUAAAAAAADAAEAIAAPAATwzAIAAKIMCvAIAAAAUNQAAAAKAACDAAvwMAAA AIAAeOG8AL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAA kAwwAPAVhA8PAA3wbAIAAAAAnw8EAAAABAAAAAAAoA8WAgAAVABoAGUAIABkAGUAZgBpAG4AaQB0 AGkAbwBuACAAbwBmACAAdABoAGUAIABiAGkAbgBkAGkAbgBnAHMAIABwAHIAbwBwAGUAcgB0AHkA IABzAHQAYQB0AGUAcwAgAHQAaABhAHQAIAAcIGkAdAAgAGkAcwAgAG4AZQBjAGUAcwBzAGEAcgB5 ACAAdABvACAAcwBlAGwAZQBjAHQAIABvAG4AZQAgAFUAUgBJACAAbQBhAHAAcABpAG4AZwAgAGYA bwByACAAdABoAGUAIABjAG8AbABsAGUAYwB0AGkAbwBuAB0gLgAgACAAUwBvACAAdABoAGkAcwAg AG0AaQBnAGgAdAAgAGkAbQBwAGwAeQAgAHQAaABhAHQAIAB0AGgAZQAgAHAAcgBvAHAAZQByAHQA eQAgAG8AbgBsAHkAIABjAG8AbgB0AGEAaQBuAHMAIABvAG4AZQAgAGgAcgBlAGYAIAAoAGYAbwBy ACAAdABoAGUAIABjAG8AbABsAGUAYwB0AGkAbwBuACAAYwBvAG4AdABhAGkAbgBpAG4AZwAgAHQA aABlACAAcgBlAHMAbwB1AHIAYwBlACkALAAgAHAAZQByAGgAYQBwAHMAIABmAHIAbwBtACAAdABo AGUAIABCAEkATgBEACAAbwByACAAUABSAE8AUABGAEkATgBEACAAcgBlAHEAdQBlAHMAdAA/AC4A AAChDxgAAAAMAQAAAAAAIAAAMgAMAQAAAAADAAEAEgAAAKoPGgAAAK0AAAAAAAAABQAAAAEAAAAD AFoAAAAAAAAADwAD8LQSAAAPAATwRgAAAAEACfAQAAAA8AAAANACAACQDwAAYAwAAAIACvAIAAAA UdQAAAECAAATAAvwBgAAAIgDAAAAAAAAEPAIAAAAcALwAJAPAAwPAAPwdQEAAA8ABPBUAAAAAQAJ 8BAAAABAEQAAQAIAAJAVAADACQAAAgAK8AgAAABS1AAAAwIAACMAC/AMAAAABAAAAAAAiAMAAAAA AAAP8BAAAADwAAAAEAsAAMAGAABgDAAADwAE8GAAAAASAArwCAAAAFPUAAACCgAAgwAL8DAAAACF AAIAAACHAAEAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAAA/wEAAAAEAR AABAAgAAkBUAAMAJAAAPAATwqQAAAKIMCvAIAAAAVNQAAAIKAACDAAvwMAAAAIAA1D/1Ar8AAgAC AIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAD/AQAAAAQBEAAG4CAABgFQAA twYAAA8ADfBBAAAAAACfDwQAAAAEAAAAAACoDwsAAABSZXNvdXJjZSBSMQAAoQ8aAAAADAAAAAAA ACgAAAEAMgAMAAAAAAADAAEADgAPAAPwdQEAAA8ABPBUAAAAAQAJ8BAAAABAEQAAQAIAAJAVAADA CQAAAgAK8AgAAABV1AAAAwIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAADACQAAEAsAAJAP AABgDAAADwAE8GAAAAASAArwCAAAAFbUAAACCgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiD AQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAAA/wEAAAAEARAABAAgAAkBUAAMAJAAAPAATw qQAAAKIMCvAIAAAAV9QAAAIKAACDAAvwMAAAAIAAlEL1Ar8AAgACAIEBBAAACIMBAAAACL8BAAAQ AMABAQAACP8BAAAIAAECAgAACAAAD/AQAAAAQBEAAG4CAABgFQAAtwYAAA8ADfBBAAAAAACfDwQA AAAEAAAAAACoDwsAAABSZXNvdXJjZSBSMgAAoQ8aAAAADAAAAAAAACgAAAEAMgAMAAAAAAADAAEA DgAPAAPwPwUAAA8ABPBUAAAAAQAJ8BAAAABACAAAQAIAANAOAACgBQAAAgAK8AgAAABY1AAAAwIA ACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAAAQBQAA0AIAAKALAAAwBgAADwAD8HkBAAAPAATw VAAAAAEACfAQAAAAQBEAAEACAACQFQAAwAkAAAIACvAIAAAAWdQAAAMCAAAjAAvwDAAAAAQAAAAA AIgDAAAAAAAAD/AQAAAAQAgAAEACAADQDgAAoAUAAA8ABPBgAAAAEgAK8AgAAABa1AAAAgoAAIMA C/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAP 8BAAAABAEQAAQAIAAJAVAADACQAADwAE8K0AAACiDArwCAAAAFvUAAACCgAAgwAL8DAAAACAAFzE iwG/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAAA/wEAAAAEARAABs AgAAYBUAABcEAAAPAA3wRQAAAAAAnw8EAAAABAAAAAAAqA8PAAAAUm9vdCBDb2xsZWN0aW9uAACh DxoAAAAQAAAAAAAAKAAAAQAyABAAAAAAAAMAAQAOAA8AA/BaAwAADwAE8E4AAAABAAnwEAAAAHAI AAAwAwAAoA4AAHAFAAACAArwCAAAAFzUAAADAgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAAHAIAAAw AwAAoA4AAHAFAAAPAATwYAAAABIACvAIAAAAXdQAAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEB BAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAD/AQAAAAcAgAADADAACgDgAAcAUA AA8ABPClAAAAogwK8AgAAABe1AAAAgoAAIMAC/AwAAAAgACwZfUCvwACAAIAgQEEAAAIgwEAAAAI vwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAP8BAAAABwCAAAMAMAAHALAADwAwAADwAN8D0AAAAA AJ8PBAAAAAQAAAAAAKgPCQAAAEJpbmRpbmdzOgAAoQ8YAAAACgAAAAAAACAAADIACgAAAAAAAwAB AA4ADwAE8J0AAACiDArwCAAAAF/UAAACCgAAcwAL8CoAAACAABgRiQG/AAIAAgCBAf//mQC/ARAA EADAAQEAAAj/AQgACAABAgIAAAgAAA/wEAAAAKAIAAAgBAAAUAoAAOYEAAAPAA3wOwAAAAAAnw8E AAAABAAAAAAAqA8FAAAAQ29sbDEAAKEPGgAAAAYAAAAAAAAoAAABADIABgAAAAAAAwABAA4ADwAE 8J0AAACiDArwCAAAAGDUAAACCgAAcwAL8CoAAACAAPCP9QK/AAIAAgCBAf//mQC/ARAAEADAAQEA AAj/AQgACAABAgIAAAgAAA/wEAAAALAKAAAgBAAAYAwAAOYEAAAPAA3wOwAAAAAAnw8EAAAABAAA AAAAqA8FAAAAQ29sbDIAAKEPGgAAAAYAAAAAAAAoAAABADIABgAAAAAAAwABAA4ADwAE8J0AAACi DArwCAAAAGHUAAACCgAAcwAL8CoAAACAAAyT9QK/AAIAAgCBAf//mQC/ARAAEADAAQEAAAj/AQgA CAABAgIAAAgAAA/wEAAAAMAMAAAgBAAAcA4AAOYEAAAPAA3wOwAAAAAAnw8EAAAABAAAAAAAqA8F AAAAQ29sbDMAAKEPGgAAAAYAAAAAAAAoAAABADIABgAAAAAAAwABAA4ADwAD8DYEAAAPAATwVAAA AAEACfAQAAAA0AIAAPAGAACgCAAAUAoAAAIACvAIAAAAYtQAAAMCAAAjAAvwDAAAAAQAAAAAAIgD AAAAAAAAD/AQAAAA8AAAAMAGAADABgAAIAoAAA8AA/B3AQAADwAE8FQAAAABAAnwEAAAAEARAABA AgAAkBUAAMAJAAACAArwCAAAAGPUAAADAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAANAC AADwBgAAoAgAAFAKAAAPAATwYAAAABIACvAIAAAAZNQAAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAA AIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAD/AQAAAAQBEAAEACAACQFQAA wAkAAA8ABPCrAAAAogwK8AgAAABl1AAAAgoAAIMAC/AwAAAAgACQl/UCvwACAAIAgQEEAAAIgwEA AAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAP8BAAAABAEQAAbAIAAGAVAAAXBAAADwAN8EMA AAAAAJ8PBAAAAAQAAAAAAKgPDQAAAENvbGxlY3Rpb24gQzEAAKEPGgAAAA4AAAAAAAAoAAABADIA DgAAAAAAAwABAA4ADwAE8GAAAAASAArwCAAAAGbUAAACCgAAgwAL8DAAAACFAAIAAACHAAEAAACB AQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAAA/wEAAAAAADAADgBwAAcAgAACAK AAAPAATwpQAAAKIMCvAIAAAAZ9QAAAIKAACDAAvwMAAAAIAAdJb1Ar8AAgACAIEBBAAACIMBAAAA CL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAD/AQAAAAAAMAAOAHAAAABgAAoAgAAA8ADfA9AAAA AACfDwQAAAAEAAAAAACoDwkAAABCaW5kaW5nczoAAKEPGAAAAAoAAAAAAAAgAAAyAAoAAAAAAAMA AQAOAA8ABPCbAAAAogwK8AgAAABo1AAAAgoAAHMAC/AqAAAAgACQnvUCvwACAAIAgQH//5kAvwEQ ABAAwAEBAAAI/wEIAAgAAQICAAAIAAAP8BAAAAAwAwAA0AgAAOAEAACWCQAADwAN8DkAAAAAAJ8P BAAAAAQAAAAAAKgPAwAAAEZvbwAAoQ8aAAAABAAAAAAAACgAAAEAMgAEAAAAAAADAAEADgAPAATw mwAAAKIMCvAIAAAAadQAAAIKAABzAAvwKgAAAIAAhJ/1Ar8AAgACAIEB//+ZAL8BEAAQAMABAQAA CP8BCAAIAAECAgAACAAAD/AQAAAAQAUAANAIAADwBgAAlgkAAA8ADfA5AAAAAACfDwQAAAAEAAAA AACoDwMAAABCYXIAAKEPGgAAAAQAAAAAAAAoAAABADIABAAAAAAAAwABAA4ADwAD8JMDAAAPAATw VAAAAAEACfAQAAAAoAsAAPAGAABwEQAAUAoAAAIACvAIAAAAatQAAAMCAAAjAAvwDAAAAAQAAAAA AIgDAAAAAAAAD/AQAAAAwAkAAMAGAACQDwAAIAoAAA8AA/B3AQAADwAE8FQAAAABAAnwEAAAAEAR AABAAgAAkBUAAMAJAAACAArwCAAAAGvUAAADAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAA AKALAADwBgAAcBEAAFAKAAAPAATwYAAAABIACvAIAAAAbNQAAAIKAACDAAvwMAAAAIUAAgAAAIcA AQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAD/AQAAAAQBEAAEACAACQ FQAAwAkAAA8ABPCrAAAAogwK8AgAAABt1AAAAgoAAIMAC/AwAAAAgADsovUCvwACAAIAgQEEAAAI gwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAP8BAAAABAEQAAbAIAAGAVAAAXBAAADwAN 8EMAAAAAAJ8PBAAAAAQAAAAAAKgPDQAAAENvbGxlY3Rpb24gQzIAAKEPGgAAAA4AAAAAAAAoAAAB ADIADgAAAAAAAwABAA4ADwAE8GAAAAASAArwCAAAAG7UAAACCgAAgwAL8DAAAACFAAIAAACHAAEA AACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAAA/wEAAAANALAADgBwAAQBEA ACAKAAAPAATwpQAAAKIMCvAIAAAAb9QAAAIKAACDAAvwMAAAAIAAIKf1Ar8AAgACAIEBBAAACIMB AAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAD/AQAAAA0AsAAOAHAADQDgAAoAgAAA8ADfA9 AAAAAACfDwQAAAAEAAAAAACoDwkAAABCaW5kaW5nczoAAKEPGAAAAAoAAAAAAAAgAAAyAAoAAAAA AAMAAQAOAA8ABPCbAAAAogwK8AgAAABw1AAAAgoAAHMAC/AqAAAAgAA8q/UCvwACAAIAgQH//5kA vwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAP8BAAAAAADAAA0AgAALANAACWCQAADwAN8DkAAAAA AJ8PBAAAAAQAAAAAAKgPAwAAAEZvbwAAoQ8aAAAABAAAAAAAACgAAAEAMgAEAAAAAAADAAEADgAP AATwWgAAAEIBCvAIAAAAcdQAAAIKAABzAAvwKgAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACNEB AQAAAP8BGAAYAAECAgAACAAAD/AQAAAAgAoAAHAFAACACgAAwAYAAA8ABPBaAAAAQgEK8AgAAABy 1AAAAgoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0QEBAAAA/wEYABgAAQICAAAI AAAP8BAAAAAwBgAAcAUAADAGAADABgAADwAE8FoAAABCAQrwCAAAAHPUAABCCgAAcwAL8CoAAABE AQQAAAB/AQAAAQC/AQAAEADAAQEAAAjRAQEAAAD/ARgAGAABAgIAAAgAAA/wEAAAAMAGAABwBQAA QAgAAMAGAAAPAATwWgAAAEIBCvAIAAAAdNQAAAIKAABzAAvwKgAAAEQBBAAAAH8BAAABAL8BAAAQ AMABAQAACNEBAQAAAP8BGAAYAAECAgAACAAAD/AQAAAAIAQAAGAJAADACQAAEAsAAA8ABPBaAAAA QgEK8AgAAAB11AAAAgoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0QEBAAAA/wEY ABgAAQICAAAIAAAP8BAAAABAAgAAYAkAAEACAAAQCwAADwAE8FoAAABCAQrwCAAAAHbUAAACCgAA cwAL8CoAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjRAQEAAAD/ARgAGAABAgIAAAgAAA/wEAAA AOAKAABgCQAA4AoAABALAAAPAATwMQEAAKIMCvAIAAAAKdQAAAAKAABzAAvwKgAAAIAANNy8AL8A AgACAIEBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAA0AJwDgAVQAcPAA3w1wAA AAAAnw8EAAAABAAAAAAAqA9jAAAAUFJPUEZJTkQgL0NvbGwyL0JhciB3aWxsIHJldHVybjoNPGJp bmRpbmdzPg08aHJlZj4vQ29sbDIvPC9ocmVmPg08c2VnbWVudD5CYXI8L3NlZ21lbnQ+DTwvYmlu ZGluZ3M+AAChDyQAAABkAAAAAAAAIAAAMgAhAAAAAAADAAEADgBDAAAAAAADAAIADgAAAKoPLAAA AC0AAAAAAAAABAAAAAEAAAADAAoAAAAAAAAABAAAAAEAAAADACUAAAAAAAAADwAE8EgAAAASAArw CAAAAAHUAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAE AwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIADwDwAxQC AAABAPEDCAAAAAMBAAAHAA4wDwAMBNQBAAAPAALwzAEAAJAACPAIAAAAAwAAAAMcAAAPAAPwZAEA AA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAHAAABQAAAA8ABPCaAAAA EgAK8AgAAAACHAAAAAIAAPMAC/BaAAAABAAAAAAAgAEAAAAAgQH///8AvwERABEAwAEAAAAAwQEA AAEAxAEAAAAAywGcMQAAzQEAAAAAzgEAAAAA1wECAAAA/wEJAAkAPwIAAAIAAQMAAAAAiAMAAAAA AAAQ8AgAAADCAc4CIA4/Cg8AEfAQAAAAAADDCwgAAAAAAAAACwCLAQ8ABPCKAAAAEgAK8AgAAAAD HAAAAAIAAGMAC/AkAAAABAAAAAAAgACAfosBvwEBAAEA/wEBAAEAAQMAAAAAiAMAAAAAAAAQ8AgA AADVCuABVw7lFA8AEfAQAAAAAADDCwgAAAABAAAADACLAQ8ADfAeAAAAAACfDwQAAAACAAAAAACq DwoAAAABAAAAAQAAAAAADwAE8EgAAAASAArwCAAAAAEcAAAADAAAgwAL8DAAAACBAQAAAAiDAQUA AAiTAd69aACUAY6fiwC/AR4AHwD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICA AAAAAAAAzJkAMzPMAMzM/wCysrIAAAByF0AAAAABACAAAAAAAKIHAAAFACAAkBIAAHIYAAAIABAA RdoAACkAEAAtYQAAMgBQAH51AABfjwAApYoAADuoAADLwQAAAAD1DxwAAAAhAQAAnAoAAwAAAABh 3AAAAQAAADYAAAABAHQADwDoA5oHAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAUA AAAAAAAAAQAAAAAAAAEPAPIDrgEAAC8AyA8MAAAAMADSDwQAAAABAAAADwDVB+QAAAAAALcPRAAA AFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAWDG8AHzaEgBk2hIAdscLMAgAAAAAAAAA fNoSACjdDTAAAAQAEAC3D0QAAABBAHIAaQBhAGwAAABOAGUAdwAgAFIAbwBtAGEAbgAAAFgxvAB8 2hIAZNoSAHbHCzAIAAAAAAAAAHzaEgAo3Q0wAFgGIiAAtw9EAAAAQwBvAHUAcgBpAGUAcgAgAE4A ZQB3AAAAbQBhAG4AAABYMbwAfNoSAGTaEgB2xwswCAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAAAAAA AAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAANBRAAALAAAAAQAAAGAAAAACAAAArFEAAAQAAABo AAAACAAAAIAAAAAJAAAAmAAAABIAAACkAAAACgAAAMQAAAAMAAAA0AAAAA0AAADcAAAADwAAAOgA AAARAAAA8AAAAAIAAADkBAAAHgAAAA4AAABQZXRlciBSYXltb25kAGxsHgAAAA4AAABQZXRlciBS YXltb25kAGxsHgAAAAMAAAA1MgBlHgAAABUAAABNaWNyb3NvZnQgUG93ZXJQb2ludABsbGVAAAAA gKMlqCwAAABAAAAAsEU9zTYGwQFAAAAA4M2OWft4wQEDAAAAlQEAAEcAAAC0UAAA/////wMAAAAI AIkQZwwAAAEACQAAA1IoAAACAKEnAAAAABEAAAAmBg8AGAD/////AAAQAAAAAAAAAAAAwAMAANAC AAAJAAAAJgYPAAgA/////wIAAAAXAAAAJgYPACMA/////wQAGwBUTlBQFAD8ALwAMgAAAP//TwAU AAAATQBpAOcACgAAACYGDwAKAFROUFAAAAIA9AMJAAAAJgYPAAgA/////wMAAAAPAAAAJgYPABQA VE5QUAQADAABAAAAAQAAAAAAAAAFAAAACwIAAAAABQAAAAwC0ALAAwUAAAAJAgAAAAIFAAAAAQL/ //8CBQAAAAQBDQAAAAUAAAAHAQMAAAChJwAAQQsgAMwAeACgAAAAAADQAsADAAAAACgAAACgAAAA eAAAAAEACAAAAAAAAEsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACA gAAAwMDAAMDcwADwyqYABAQEAAgICAAMDAwAERERABYWFgAcHBwAIiIiACkpKQBVVVUATU1NAEJC QgA5OTkAgHz/AFBQ/wCTANYA/+zMAMbW7wDW5+cAkKmtAAAAMwAAAGYAAACZAAAAzAAAMwAAADMz AAAzZgAAM5kAADPMAAAz/wAAZgAAAGYzAABmZgAAZpkAAGbMAABm/wAAmQAAAJkzAACZZgAAmZkA AJnMAACZ/wAAzAAAAMwzAADMZgAAzJkAAMzMAADM/wAA/2YAAP+ZAAD/zAAzAAAAMwAzADMAZgAz AJkAMwDMADMA/wAzMwAAMzMzADMzZgAzM5kAMzPMADMz/wAzZgAAM2YzADNmZgAzZpkAM2bMADNm /wAzmQAAM5kzADOZZgAzmZkAM5nMADOZ/wAzzAAAM8wzADPMZgAzzJkAM8zMADPM/wAz/zMAM/9m ADP/mQAz/8wAM///AGYAAABmADMAZgBmAGYAmQBmAMwAZgD/AGYzAABmMzMAZjNmAGYzmQBmM8wA ZjP/AGZmAABmZjMAZmZmAGZmmQBmZswAZpkAAGaZMwBmmWYAZpmZAGaZzABmmf8AZswAAGbMMwBm zJkAZszMAGbM/wBm/wAAZv8zAGb/mQBm/8wAzAD/AP8AzACZmQAAmTOZAJkAmQCZAMwAmQAAAJkz MwCZAGYAmTPMAJkA/wCZZgAAmWYzAJkzZgCZZpkAmWbMAJkz/wCZmTMAmZlmAJmZmQCZmcwAmZn/ AJnMAACZzDMAZsxmAJnMmQCZzMwAmcz/AJn/AACZ/zMAmcxmAJn/mQCZ/8wAmf//AMwAAACZADMA zABmAMwAmQDMAMwAmTMAAMwzMwDMM2YAzDOZAMwzzADMM/8AzGYAAMxmMwCZZmYAzGaZAMxmzACZ Zv8AzJkAAMyZMwDMmWYAzJmZAMyZzADMmf8AzMwAAMzMMwDMzGYAzMyZAMzMzADMzP8AzP8AAMz/ MwCZ/2YAzP+ZAMz/zADM//8AzAAzAP8AZgD/AJkAzDMAAP8zMwD/M2YA/zOZAP8zzAD/M/8A/2YA AP9mMwDMZmYA/2aZAP9mzADMZv8A/5kAAP+ZMwD/mWYA/5mZAP+ZzAD/mf8A/8wAAP/MMwD/zGYA /8yZAP/MzAD/zP8A//8zAMz/ZgD//5kA///MAGZm/wBm/2YAZv//AP9mZgD/Zv8A//9mACEApQBf X18Ad3d3AIaGhgCWlpYAy8vLALKysgDX19cA3d3dAOPj4wDq6uoA8fHxAPj4+ADw+/8ApKCgAICA gAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8A//////////////////T////0////9P////// ////////////////////////////////////9P////T/////////////9P//9P//9P//9P////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////T/////9P/////0//// 9P////T///T/////////////////////////////3r28vb22vf///93/3f/itd72vOLe3f/d9Lz/ 4v//vP////////////////////////////////////////////////////////////////////// ////////////////9P/////0//////////////////////////////////////////////////// ////////////////////////b5T/vd5vvb1p9P/PvLT/3rTd/7TP4rvPi/+13ore/7T///////8A AP///////wAA/wD//wD//////////////////wD/AP////////////////////////////////// //////T///////////////////////////////////////////////////////////////////// ////////t0b/jpT/t2n/aZT/rYun9sKGu/+trv//rrT/tLSu4va0//////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////Zptr1G /7y9vWm9/670i//dtOL/z5Hd9q279rS0td0Zi97///////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////729t7cavb3////ivd7/ /7Xd/7zc///d///d/93/vNbC//////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////8A//////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /wAA/wAAAAD//wAAAP///wD//wAAAP8AAAD//wD/AAAAAP//AAD/AAD/AP8AAP////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////8AAP8A/wAAAP8A AAD///8AAP8AAAD/AAAA//8AAP8AAAAA/wAAAAAA/wAAAAD///////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////wD///8AAP//////////AAD///8A ////////AAD///////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////b29v////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////xve//T///////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////2/xvew97///// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////0G97xvd3D//////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////969vb299PT///////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////+99r3xvby93v/0//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /929t7y9G/T09P////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////0/729vby93v/09P// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////9t68vba99PT09PT///////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////09L28vb299PT/9PT0//////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////2/97evb289PT09PT0//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////9Bu9 vby93v/09PT09PT///////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////29vTevby99PT/9PT09PT/ //////////////////////////////////////////////////////////////////////////// //////8AAAD/////////////////////////AAAA////////////////AAD///////////////// /////////////////////////////////////////94bvb299PT09PT09P/0//////////////// //////////////////////////////////////////////////////////////////8A////AP// //////////////////////8A////////////////////AP////////////////////////////// //////////////////////////8b3r28G/T0//QA//QA9P///wAA//8AAP//AAAAAP///wAAAP// AAD///8A////////AAAAAAD/AAAAAAD/AAD/AAAAAAAAAAAA/wAAAAAAAAAA/////wAAAP//AAAA //8AAP//AAAA////AAAAAAD/AAAA/wD///////////////////////////////////////////// //////////+99Ly93v/09PQAAPT0AAD//wD///8A//8A//8A//8A////AP///wD///8A/wD///// //8A////AP8A/wD//wD/AP//AP//AP8A//8A/wD//////wD/////AP////8A//8A//8A/wD//wD/ AP///wD//wD///8AAP/////////////////////////////////////////////////////09L29 vfT/9PT0APQAAPQA//8AAAD/AP//AP//AP///wD//wAAAAAA////AP8A////////AP///wD/AP8A //8A/wD//wD//wD/AP//AP//AAD/AAD//////wAAAP//AP//AP//AP8A//8A/wAAAP8A//8A//// AAD/////////////////////////////////////////////////////3r3dvf/09PT/9AD0AAD0 AP//AP8A/wD//wD//wD///8A////AP8A/////wD/AP///////wAAAAD//wD/AAD/AP8A//8A//8A /wAA/wD/AP//AAD///////8A//8A/wD//wD//wD/AP//AP8A/wD/AP//AP//AP//AP////////// ////////////////////////////////////////9PS9Ghv09P/09AD09AD09PQA//8A//8AAAD/ //8A////AP///wD/AP///wD///8A//////8A////AAAAAAD/AP///wAAAP8AAAAA/wD///8AAAAA AAD/////AP//AAAAAAD/AAD/AAAAAP///wD/AAAAAAAAAAD//wAA//////////////////////// ///////////////////////29PS98d7/9P/09P8A9P8A9PT/AP//////AP//////AP//AP////8A /wD///8A////AP//////AP///wD//////////////wD//////////////////////////wD//wD/ //////////////////////////8A//////////////////////////////////////////////// ////////9P+93r30//T09PQAAPQAAAD0AAAA////AAD/////AAAAAP///////wD///8AAAD//wAA ////AAAAAAD//wD//////////wAA//8A/////////////////////wAAAAD///////////////// //////////////////////////////////////////////////////////////////////+94r3/ 9PT/9P/0//T09PT09P////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////2//be9L29//T/9PT09PT0//T0 9PT0//////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////94b/730//T09P/0//T09PT0//T0//////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////S99PT/9P/09PT0//T09PT09PT///////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////7303v/09P/09P/09PT0//T09PT0//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////xv/vfT/ 9P/09P/09PT/9PT0//T09P////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////e9PT/9P/0//T0//T09PT0 9PT09PT2//////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////9vb/9L3/9P/0//T/9PT09P/0//T0//T09Pb///+F oYX/////////haGF//////////+hhaGFoYWhhf////////+FoYX/////oYWh//////+hhaH///// //+FoYX//////4Whhf////////+Fof//////////haGF//////////////////////////////// ///////////////////////eG///9P/0//T09P/0//T09PT09PT09P//9P//oYWF/////////4WF of//////////haGFoYWFhaH/////////oYWh////hYWh////////haGF////////oYWh//////+h haH///////+FoYX//////////6GFhf////////////////////////////////////////////// //////////+99P/0//T/9P/09PT09P/09PT09P/e/////4Whhf////////+FoYX//////////6GF oYWhhaGF/////////4Whhf//oYWh//////////+Fof//////oYWh////////haGF//////+FoYWh //////////+FoYX///////////////////////////////////////////////////b///8b///0 //T/9PT/9P/09PT09P/09PT/9P////+FhaH/////pv//oYWF//////////+Foab///////////// //+FhaH//4Whhf//////////hYWhpoWFoYWFhf///////4WFof//////hYWhpv//////////hYWh ///////////////////////////////////////////////////////23v/0///0//T/9PT09P/0 9PT09PT09PT0////haGF////haGF/4Whhf//////////oYWh////////////////haGF/4Whhf// /////////4WhhaGFoYWhhaH///////+FoYX/////oYWhhaH//////////4Whhf////////////// //////////////////////////////////////8b//T///T/9P/09P/09P/09P/09PT0//T09P// /6GFof//haGFof+hhaH//////////4Whhf///////////////6GFoYWhhf//////////////haGF oYWhhaH/////////oYWh////oYWhhaGF//////////+hhaH///////////////////////////// /////////////////////////73///T/9P/0//T0//T09PT09P/09PT09PT0//aFoYX/haGFoYWh haGF//////////+hhaGFoYWhhf////////+FoYWhhaH//////////////6GFof//haGF//////// /4Whhf///4Whhf+Fof//////////haGF//////////////////////////////////////////// /////////97///T///T/9P/0//T0//T/9PT09PT0//T0////hYWhpoWFof+FhaGmhf////////// haGFhYWhpoX/////////hYWhhYWFoab/////////////oYX//6Gmhf////////+FhaH//4Whpv// oYX//////////4WFof//////////////////////////////////////////////////////9P// 9P/0//T/9PT/9PT09PT/9PT/9PT0/8Pe/4WhhaGFof///6GFoYX//////////6GFoYWhhaGF//// /////4Whhf//oYWhhf///////////4Whhf+Fof//////////haGF/4Whhf///4Wh//////////+F oYX///////////////////////////////////////////////////8b////9P//9P/09P/09P/0 9PT09PT09PT09PT0//+hhYWFof////+FhYWh//////////+FoYX///////////////+hhaH///+F haH///////////+hhaGFhYX//////////6GFoYWhhf////+hhf//////////oYWF//////////// //////////////////////////////////////////b/9P//9P/0///0//T09P/0//T09PT09P/0 9P//haGFof///////4Whhf//////////oYWh////////////////haGF////haGF//////////// /6GFoYWh//////////+FoYWhhaH/////haH//////////4Whhf////////////////////////// /////////////////////////97/9P//9P/0//T09PT/9PT09PT09P/09PT09PT0/4WFoYX///// ////hYX//////////4Whpv///////////////4WFof///6GFhf////////////+mhYWh//////// ////hYWhpoX//////6Gm//////////+FhaH///////////////////////////////////////// ////////////////9P//9P/0//T/9PT/9PT0//T09P/09PT0/xuFoYX/////IP///6GF//////// //+hhaGFoYWhhf////////+FoYX/haGFoYX//////////////4Whhf///////////4WhhaH///// //+Fof//////oYWhhaGFoYWh//////////////////////////////////////////////b29Pb/ ///0///0//T/9PT/9PT/9PT09PT09PT/9PT0oYX/////ICAg////of//////////haGFoYWhhaH/ ////////oYWhhaGFoYX///////////////+hhaH///////////+hhaH/////////oYX//////4Wh haGFoYWhhf////+h///////////////////////////////////////23v////T///T/9P/09PT/ 9PT09PT0//T09P/09PT0/4X/////ICAgIP///////////////6GFoYWhhaGF/////////4WhhaGF of//////////////////haH/////////////haH//////////4Wh//////+hhaGFoYWhhaH///+h hf////////////////////////////////////////////T///T/9P/0//T/9PT/9P/09PT09PT0 9PT09PQb9vb///////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////0//////T///T/9P/09P/09PT09PT09P/09P/09PT0/970//// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////0////9P//9P/0//T0//T09P/09PT09PT09P/09P/0//////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///0///0//T/9PT/9PT0//T0//T09P/09PT09PT09PS9//////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////9P////T///T/9P/0 9P/09PT09PT09PT09PT/9PT09PT0///2//////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////T/9P/0//T/9P/09P/0//T0//T0 9P/09PT09P/0/xve//////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////0//T/9PT/9PT09PT09PT09PT09PT0//T09PT0 9PT2//////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////9P//9P/0///0//T/9vT/9PT0//T0//T09PT/9PT09PT09P+9//////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////9P/0//T0//T09P/0//T09PT0//T09PT09PT0//T03hv///////////////////////// //////////8gPyAfIB8gHyA/IB8gHyAfID8gHyAfIB8gP/////////////////////////////// ///////////////////////////////////////////////////////////////////0///0//b0 //T0//T09PT09PT09PT09PT/9PT/9PT09P8b3vT/////////////////////////////ICAgICD/ /////////////yAgICAg////////ICAgICAg//////////////////////////////////////// //////////////////////////////b////////////////////0///0///0//T/9PT/9PT0//T0 //T0//T09PT09PT09PT09L309P////////////////////////8fIB8gH///////////IP////// /x8gICD//////////x8gHyAf//////////////////////////////////////////////////// //////////////////////////////////T///T///T/9P/09P/09PT/9PT09PT09PT09PT0//T0 //T0//T/vfT/9P////////////////////8gICAg////////////IP//////////ICAgIP////// ////ICAgICD///////////////////////////////////////////////////////////////// //b29v////////////////////T/9P/0//T0//T09PT/9PT0//T09P/09PT09PT09PT09PS93v// /////////////////yAfIB8g////////////IB////////////8fIB8g//////////8/IB8gH/// ////////////////////////////////////////////////////////////////3v/0//////// ///////0//T///T/9PT/9PT09P/09PT09PT09PT09PT0//T09PT09PT09L3DG/////////////// //8gICAgIP//////////ICAg/////////////yAgICAg/////////yAgICAg//////////////// //////////////////////////////////////////////////////T/////////////////9P// 9P//9P/09P/09P/09P/09P/09PT09PT0//T0//T0//TevN70//////////////8fIB8gHyD///// ////ICAgH/////////////8gHyAgIP////////8gHyAfIP////////////////////////////// ////////////////////////////////9N7/w97/9v/////////0////9P//9P/0G//0//T09PT0 9PT09PT09P/09PT09PT09PT09PT09P+9vf//////////////ICAgICAg/////////yAgICD///// ////////ICAgICD/////////ICAgICD///////////////////////////////////////////// ////9v////b/9v8b3sP///T////////////////0////9P/0///e/xv/9PT/9P/09PT09PT09P/0 9P/09PT0//T09P/09Ly93fb/9Pb///////8gPyAfIP///////x8gHyAfIP////////////8fIB// /////////yAfID8g///////////////////////////////////////////////////////e9hve 9P/eG//////////////////////0//T////0//T/9P/09PT09P/09P/09PT09PT09P/09PT09PT0 9PT/vb3ew97/////////ICAgICD///////8g/yAgICD/////////////ICD//////////yAgICAg IP//////////////////////////////////////////////////9r3/9Bvew/S9//T///////// ////////9P/0///////////09PT09P/09PT09PT09P/09P/09PT09P/09P/09P/09PT0vbz/9P// //////8gIB8gH///////////IB8gIP//////////IB8g//////////8fIB8gIP////////////// ///////////////////////////////////0/97ivfS99N4b//////T///////////////////// ////////9P/0//T09P/09PT09PT09PT09PT09PT09PT09PT09PT09PS9Gr3ew////////yAgICAg //////////8gICAg/////////yAg/////////yAgICAgIP////////////////////////////// ////////////9v////T2vfS9vb3x3r30//T////////////////////////////////////09PT/ 9PT09P/0//T/9PT09P/09P/09PT09PT09PT/9PT/9N68vd0b//T//////yA/IB8g/////////yAf IB///////////////////yAfID8g/////////////////////////////////////////////97/ wt693b3dvd4avf//9P////T////////////////////////////////////09PT0//T09PT09PT0 //T09PT09P/0//T/9P/09PT09PT0/729vd69/////////yAgICAg/////////yAgICAg//////// //8gICAgIP////////////////////////////////b///////////b29P8bvd69vb29vby99P/0 9P//9P//9P////////////////////////////////////T/9PT0//T/9PT/9PT0//T0//T09PT0 9PT09P/0//T/9PT09L28vd29///0////////IB8gICAfIB8gH////x8gHyAfICAgH/////////// //////////////////////////b/////9P///xv03vG93b29vL28vb3/9P/0////9P////////// ///////////////////////////////09PT/9PT09PT09PT/9PT09PT09PT/9PT0//T09PT09PT0 9PT/9L29Gt29/73/9P////////////////////////////////////////////////////////// ///////////////////0/xvevb3evb29vL0a3vT/9P/0//T/9P//9P////////////////////// ///////////////////09PT/9PT/9P/09PT/9P/09P/09PT/9PT0//T0//T0//T/9PT0/7298b3d w97/G//////////////////////////////////////////////////////////2//T/////3v/0 9PS9vd293b29vL28vd7/9P/09P/0//T/9P/0//////////////////////////////////////// //////T/9PT/9PT09PT/9PT0//T0//T/9PT/9PT/9PT0//T09PT/9PT/G969vbzevf+9/xv/9P/2 9v////////////////////////////////b////////////2///////0//TD3r298d69vb28vb29 //T0//T0//T0//T/9P//////////////////////////////////////////////////9PT/9PT/ 9P/09P/09P/0//T09PT/9PT/9PT/9PT/9P/09P/09P/09P+9vby93RveG/+9/94b//////////// ////////////////////9Pb2////9PT/3vT/vd69G7293RrevL29vL299PT0//T0//T0//T/9P/0 ///0////////////////////////////////////////////////////9PT/9PT0//T0//T09PT0 //T/9PT/9PT/9PT/9PT0//T09P/09P/09P8b3r29vfG93sLe/7309P/09PT/9v/29P/0///29P/0 ///0///23vT0w97/vf8b3sK94r3dvfG9vb29G97/9PT/9PT0//T0//T/9P/0//T///////////// ////////////////////////////////////////////9P/0//T0//T/9P/0//T0//T/9P/09P/0 9P/0//T/9P/09P/09P/0//T/9L3eGhq9vcLevfS99N7D3hveG/+9/xv/3sP09N4b/73eG/+93hve wt69G73evb29vb3eG/T/9PT/9PT/9P/0//T/9P/0//T///////////////////////////////// ///////////////////////////////0//T/9P/0//T/9P/0//T/9P/0//T/9P/0//T/9P/0//T/ 9P/0//T/9P/0//T/3hvevb283r0b3sLewt703r3eGxve9L294r3ewt694r0bvb29vd29vRve9P/0 //T/9P/0//T/9P/0//T/9PT/9P////////////////////////////////////////////////// ///////////////////0//T/9P/0//T/9P/0//T0//T/9P//9P/0//T0//T/9P//9P/0//T0//T/ 9P//9P/0/730vd69vb29vcK9vd69G73ew729vd4avb3eG94b/73/9P/09P/0//T/9P/0//T/9P/0 9P/0//////////////////////////////////////////////////////////////////////// ////////9P/0//T/9P/0//T///T///T/9P/0//T///T///T/9P/0//T///T///T/9P/0//T///T/ //T/9P/e//T/G97/G970//T/9P//9P/0///0///0///0//T/9P/0//T/9P/0//////////////// ////////////////////////////////////////////////////////////////////////9P/0 //T///T/9P/0//T/9P/0//T/9P/0//T/9P/0//T/9P/0//T/9P/0//T/9P/0//T/9P/0//T/9P/0 //T/9P/0//T/9P/0//T///T/9P/0///0//T/9P////////////////////////////////////// ///////////////////////////////////////////////////////////////0//T///T///T/ //T///T///T///T///T///T///T///T///T///T///T///T///T///T///T///T///T///T///T/ //T/9PT/9P/0///0//////////////////////////////////////////////////////////// ////////////////////////////////////////////////////9P//9P//9P//9P//9P//9P// 9P//9P//9P//9P//9P//9P//9P//9P//9P//9P//9P//9P//9P//9P//9P//9P////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////BQAAAAcBAQAAAAgAAAD6AgUAAQAAAAAAAAAEAAAALQEAAAcA AAD8AgEAAAAAAAAABAAAAC0BAQAPAAAAJgYPABQAVE5QUAQADAAAAAAAAAAAAAAAAAAJAAAAJgYP AAgA/////wEAAAADAAAAAAAeAAAAGQAAAFdlYkRBViBCaW5kaW5ncyBQcm9wZXJ0eQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAguAAAA BwAAAAAAqQ8KAAAABwAAAAIACQgAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAA AAAAQAIAAAAABwAAAP//7wAAAAAA////////GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAA AAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEgAIAAA8AAPB4AgAAAAAG8LgBAAAC3AAANgAA APMAAAAKAAAAAQAAAA4AAAAKAAAATgAAAAAAAAA4AAAAAAAAALcAAAADAAAAEAAAAAoAAAAIAAAA AwAAAAQAAAAAAAAAJAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAADwAAAAAAAAAEAAAAAAAAACkAAAAA AAAABAAAAAAAAAAEAAAAAAAAAE0AAAAAAAAABAAAAAAAAAAPAAAAAAAAAAQAAAAAAAAAEwAAAAAA AAAEAAAAAAAAACYAAAAAAAAABAAAAAAAAAAxAAAAAAAAAAQAAAAAAAAAMgAAAAAAAAAEAAAAAAAA AEEAAAAAAAAADwAAAAAAAAAEAAAAAAAAACIAAAAAAAAAGwAAAAAAAAAbAAAAAAAAABsAAAAAAAAA FwAAAAAAAAAXAAAAAAAAABMAAAAAAAAADwAAAAAAAAAEAAAAAAAAACEAAAAEAAAAdgAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAA3AAAABQAAACoA AAAHAAAALQAAAAgAAAB3AAAABgAAACwAAAACAAAAdwAAAC8AAfBYAAAAYgAH8CQAAAAGBoJrU8vN k7HY3rFk8b+vwAf/AIZ+AAABAAAAAAAAAAAAywBiAAfwJAAAAAYGF2oLTMxkrnz7uzZnMSsB7P8A uB4AAAEAAACGfgAAAADLAGMAC/AkAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQIC AAAIMAAa8QwAAACZ/5kAAP8AAADMZgBAAB7xEAAAAAQAAAgBAAAIAgAACPcAABAfAPAPHAAAAAAA 8wMUAAAAAgAAAAQAAAAAAAAAAAAAgAAAAAAPANAHewEAAB8AFAQcAAAAAAAVBBQAAAC6HXXsAMqa OzJOzckAypo7AQEAAQ8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAAEMAAABkAAAAQwAAAGQAAAB2 xwswCAAAAAAAAABw2hIAAAAAAAAAAACs////Cv///wEAAABwAPsDCAAAAAAAAABwCAAAcAD7AwgA AAABAAAAQAsAAB8ABwQ8AAAAAAD9AzQAAAAhAAAAZAAAACEAAABkAAAAYPMNMCzeEgAAAAAARDK8 AAAAAAAAAAAAAAAAAAAAAAAAARIAHwATBDwAAAAAAP0DNAAAAGQAAABkAAAAZAAAAGQAAABg8w0w LN4SAAAAAABEMrwAAAAAAAAAAAAAAAAAAAAAAAABEgAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAAC AAAAHwAIBDwAAAAAAP0DNAAAAEIAAABkAAAAQgAAAGQAAACc2hIA2fQNMCzeEgABAAAAAAAAAAAA AAAAAAAAAAAAAAAAEgAPAPAPUQEAAAAA8wMUAAAABgAAAAQAAAACAAAAAwEAAAAAAAAAAJ8PBAAA AAYAAAAAAKgPGQAAAFdlYkRBViBCaW5kaW5ncyBQcm9wZXJ0eSAAAKEPHAAAABoAAAAAAAAAAAAZ AAAAAAAAAAEAAAAAAAIAFAAAAKoPFgAAABkAAAAAAAAAAQAAAAcAAAAAAAkEAAAQAJ8PBAAAAAUA AAAAAKoPCgAAAAEAAAABAAAAAAAAAPMDFAAAACkAAAAEAAAAAAAAAB4BAAAAAAAAAADzAxQAAAAy AAAABAAAAAAAAAAfAQAAAAAAAAAA8wMUAAAANAAAAAQAAAAAAAAAIgEAAAAAAAAAAPMDFAAAADMA AAAEAAAAAAAAACABAAAAAAAAAADzAxQAAAA1AAAABAAAAAAAAAAhAQAAAAAAAAAA8wMUAAAANgAA AAQAAAAAAAAAIwEAAAAAAAAvAPAPHAAAAAAA8wMUAAAACAAAAAAAAAAAAAAAAAEAAAAAAAAAAOoD AAAAAAAAchcIAAAAAQAQAKPkAAAAAPUPHAAAACMBAACcCgADf+QAAEXsAAABAAAANgAAAAEAdAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPYPJQAAABQAAABf wJHjqdwAAA0A9AMDALwAUGV0ZXIgUmF5bW9uZAgAAABQAGUAdABlAHIAIABSAGEAeQBtAG8AbgBk AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAG AAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQA AAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAA ACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAA MQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/ AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAAAEoAAABLAAAATAAAAE0A AABOAAAA/v///1AAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABXAAAAWAAAAFkAAABaAAAAWwAA AFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAAZAAAAGUAAABmAAAAZwAAAGgAAABpAAAA agAAAGsAAABsAAAAbQAAAG4AAABvAAAAcAAAAHEAAAByAAAAcwAAAHQAAAB1AAAAdgAAAHcAAAB4 AAAAeQAAAHoAAAB7AAAAfAAAAH0AAAB+AAAAfwAAAIAAAACBAAAAggAAAIMAAACEAAAAhQAAAIYA AACHAAAAiAAAAIkAAACKAAAAiwAAAIwAAACNAAAAjgAAAI8AAACQAAAAkQAAAJIAAACTAAAAlAAA AJUAAACWAAAAlwAAAJgAAACZAAAAmgAAAJsAAACcAAAAnQAAAJ4AAACfAAAAoAAAAKEAAACiAAAA owAAAKQAAAClAAAApgAAAKcAAACoAAAAqQAAAKoAAACrAAAArAAAAK0AAACuAAAArwAAALAAAACx AAAAsgAAALMAAAC0AAAAtQAAALYAAAC3AAAAuAAAALkAAAC6AAAAuwAAALwAAAC9AAAA/AAAAL8A AADAAAAAwQAAAMIAAADDAAAAxAAAAMUAAADGAAAAxwAAAMgAAADJAAAAygAAAMsAAADMAAAAzQAA AM4AAADPAAAA0AAAANEAAADSAAAA0wAAANQAAADVAAAA1gAAANcAAADYAAAA2QAAANoAAADbAAAA 3AAAAN0AAADeAAAA3wAAAOAAAADhAAAA4gAAAOMAAADkAAAA5QAAAOYAAAD+/////////+kAAADq AAAA6wAAAP7///////////////////////////////////////////////////////////////// ///9/////f////sAAAD+/////QAAAP4AAAD/AAAA6AAAAFIAbwBvAHQAIABFAG4AdAByAHkAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAA EI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAIDn2NWTecEBAgEAAEADAAAAAAAAUABpAGMAdAB1 AHIAZQBzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIA AgH/////AgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPp0A AAAAAABDAHUAcgByAGUAbgB0ACAAVQBzAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAGgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAsAAABHAAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAQAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAvgAAAABSAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQA bwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgH///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABPAAAAeewAAAAAAAAFAEQAbwBjAHUA bQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAAC AQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACUAgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfNoSACjdDTAAWAYxAACkDwoAAACAAGAA AAD/////AAClDwwAAAAAAAAILgAAAAcAAAAAAKkPCgAAAAcAAAACAAkIAABAAKMPbgAAAAUA//0/ AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAP///////xgAAAAAAQAA AAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwALBIACAAAP AADweAIAAAAABvC4AQAAAtwAADYAAADzAAAACgAAAAEAAAAOAAAACgAAAE4AAAAAAAAAOAAAAAAA AAC3AAAAAwAAABAAAAAKAAAACAAAAAMAAAAEAAAAAAAAACQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AA8AAAAAAAAABAAAAAAAAAApAAAAAAAAAAQAAAAAAAAABAAAAAAAAABNAAAAAAAAAAQAAAAAAAAA DwAAAAAAAAAEAAAAAAAAABMAAAAAAAAABAAAAAAAAAAmAAAAAAAAAAQAAAAAAAAAMQAAAAAAAAAE AAAAAAAAADIAAAAAAAAABAAAAAAAAABBAAAAAAAAAA8AAAAAAAAABAAAAAAAAAAiAAAAAAAAABsA AAAAAAAAGwAAAAAAAAAbAAAAAAAAABcAAAAAAAAAFwAAAAAAAAATAAAAAAAAAA8AAAAAAAAABAAA AAAAAAAhAAAABAAAAHYAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAANwAAAAUAAAAqAAAABwAAAC0AAAAIAAAAdwAAAAYAAAAsAAAAAgAAAHcAAAAv AAHwWAAAAGIAB/AkAAAABgaCa1PLzZOx2N6xZPG/r8AH/wCGfgAAAQAAAAAAAAAAAMsAYgAH8CQA AAAGBhdqC0zMZK58+7s2ZzErAez/ALgeAAABAAAAhn4AAAAAywBjAAvwJAAAAIEBBAAACIMBAAAA CL8BEAAQAMABAQAACP8BCAAIAAECAgAACDAAGvEMAAAAmf+ZAAD/AAAAzGYAQAAe8RAAAAAEAAAI AQAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAIAAAAEAAAAAAAAAAAAAIAAAAAADwDQB3sBAAAf ABQEHAAAAAAAFQQUAAAAuh117ADKmjsyTs3JAMqaOwEBAAEPAPoDZwAAAAAA/gMDAAAAAAEAAAD9 AzQAAABDAAAAZAAAAEMAAABkAAAAdscLMAgAAAAAAAAAcNoSAAAAAAAAAAAArP///wr///8BAAAA cAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfAAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAh AAAAZAAAAGDzDTAs3hIAAAAAAEQyvAAAAAAAAAAAAAAAAAAAAAAAAAESAB8AEwQ8AAAAAAD9AzQA AABkAAAAZAAAAGQAAABkAAAAYPMNMCzeEgAAAAAARDK8AAAAAAAAAAAAAAAAAAAAAAAAARIAHwD/ AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAB8ACAQ8AAAAAAD9AzQAAABCAAAAZAAAAEIAAABkAAAA nNoSANn0DTAs3hIAAQAAAAAAAAAAAAAAAAAAAAAAAAAAABIADwDwD1EBAAAAAPMDFAAAAAYAAAAE AAAAAgAAAAMBAAAAAAAAAACfDwQAAAAGAAAAAACoDxkAAABXZWJEQVYgQmluZGluZ3MgUHJvcGVy dHkgAAChDxwAAAAaAAAAAAAAAAAAGQAAAAAAAAABAAAAAAACABQAAACqDxYAAAAZAAAAAAAAAAEA AAAHAAAAAAAJBAAAEACfDwQAAAAFAAAAAACqDwoAAAABAAAAAQAAAAAAAADzAxQAAAApAAAABAAA AAAAAAAeAQAAAAAAAAAA8wMUAAAAMgAAAAQAAAAAAAAAHwEAAAAAAAAAAPMDFAAAADQAAAAEAAAA AAAAACIBAAAAAAAAAADzAxQAAAAzAAAABAAAAAAAAAAgAQAAAAAAAAAA8wMUAAAANQAAAAQAAAAA AAAAIQEAAAAAAAAAAPMDFAAAADYAAAAEAAAAAAAAACMBAAAAAAAALwDwDxwAAAAAAPMDFAAAAAgA AAAAAAAAAAAAAAABAAAAAAAAAADqAwAAAAAAAHIXCAAAAAEAEADN3AAAAAD1DxwAAAAjAQAAnAoA A6ncAABv5AAAAQAAADYAAAABAHQADwDoA5oHAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAA CgAAAAUAAAAAAAAAAQAAAAAAAAEPAPIDrgEAAC8AyA8MAAAAMADSDwQAAAABAAAADwDVB+QAAAAA ALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAWDG8AHzaEgBk2hIAdscLMAgA AAAAAAAAfNoSACjdDTAAAAQAEAC3D0QAAABBAHIAaQBhAGwAAABOAGUAdwAgAFIAbwBtAGEAbgAA AFgxvAB82hIAZNoSAHbHCzAIAAAAAAAAAHzaEgAo3Q0wAFgGIiAAtw9EAAAAQwBvAHUAcgBpAGUA cgAgAE4AZQB3AAAAbQBhAG4AAABYMbwAfNoSAGTaEgB2xwswCAAAAAAAAAB82hIAKN0NMABYBjEA AKQPCgAAAIAAYAAAAP////8AAKUPDAAAAAAAAP3////+////AwEAAP7///////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////AQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgA AAAJAAAACgAAAP7///8MAAAA/v////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////+/wAABQACAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN 1ZwuGxCTlwgAKyz5rjAAAABkAgAAEAAAAAEAAACIAAAAAwAAAJAAAAAPAAAAqAAAAAQAAAC4AAAA BgAAAMAAAAAHAAAAyAAAAAgAAADQAAAACQAAANgAAAAKAAAA4AAAABcAAADoAAAACwAAAPAAAAAQ AAAA+AAAABMAAAAAAQAAFgAAAAgBAAANAAAAEAEAAAwAAAACAgAAAgAAAOQEAAAeAAAADwAAAE9u LXNjcmVlbiBTaG93AAAeAAAABwAAAE1FUkFOVABlAwAAAHnsAAADAAAAcAAAAAMAAAAHAAAAAwAA AAEAAAADAAAAAAAAAAMAAAAAAAAAAwAAAKAKCQALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAA AAAAAB4QAAALAAAAEAAAAFRpbWVzIE5ldyBSb21hbgAGAAAAQXJpYWwADAAAAENvdXJpZXIgTmV3 AA8AAABEZWZhdWx0IERlc2lnbgAaAAAAV2ViREFWIEJpbmRpbmdzIFByb3BlcnR5IAAKAAAASGll cmFyY2h5AAoAAABIaWVyYXJjaHkAGQAAAFBvc3NpYmxlIEludGVycHJldGF0aW9ucwASAAAAQWxs IHBvc3NpYmxlIFVSSXMAIAAAAE9ubHkgb25lIFVSSSBmb3IgdGhlIGNvbGxlY3Rpb24AFAAAAE9u bHkgb25lIGNvbGxlY3Rpb24ADBAAAAYAAAAeAAAACwAAAEZvbnRzIFVzZWQAAwAAAAMAAAAeAAAA EAAAAERlc2lnbiBUZW1wbGF0ZQADAAAAAQAAAB4AAAANAAAAU2xpZGUgVGl0bGVzAAMAAAAHAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9g8lAAAAFAAA AF/AkeNV7AAADQD0AwMAvABQZXRlciBSYXltb25kCAAAAFAAZQB0AGUAcgAgAFIAYQB5AG0AbwBu AGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------_=_NextPart_000_01C17997.81BEC3F0-- From w3c-dist-auth-request@w3.org Fri Nov 30 07:48:13 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 HAA07508 for ; Fri, 30 Nov 2001 07:48:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA17780; Fri, 30 Nov 2001 07:46:38 -0500 (EST) Resent-Date: Fri, 30 Nov 2001 07:46:38 -0500 (EST) Resent-Message-Id: <200111301246.HAA17780@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA17751 for ; Fri, 30 Nov 2001 07:46:28 -0500 (EST) Received: from toro.w3.mag.keio.ac.jp (postfix@toro.w3.mag.keio.ac.jp [133.27.228.201]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA05015; Fri, 30 Nov 2001 07:46:27 -0500 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id D28D97F4E3; Fri, 30 Nov 2001 21:45:37 +0900 (JST) Message-Id: <4.2.0.58.J.20011130205636.03244430@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Fri, 30 Nov 2001 20:59:00 +0900 To: Mark Baker , fielding@ebuilt.com (Roy T. Fielding) From: Martin Duerst Cc: LMM@acm.org (Larry Masinter), stefan.eissing@greenbytes.de ('Stefan Eissing'), w3c-dist-auth@w3.org ('WebDAV'), uri@w3.org In-Reply-To: <200111300417.XAA03496@markbaker.ca> References: <20011126152733.B8631@waka.ebuilt.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5696 X-Loop: w3c-dist-auth@w3.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 23:17 01/11/29 -0500, Mark Baker wrote: >But I'd point out that "about:" appears to me to be designed to be >a relative URI; if IE supported "about:", it wouldn't pop up >Communicator's info screen, it would pop up one about IE. And if you use about: on a Japanese version of Netscape, it will turn up in Japanese. Content negotiation. There is nothing saying that an URI with absolute URI syntax but resolve to exactly the same bytes every time. 'about:' would just be defined as 'information about the tool I'm just using'. Regards, Martin. From w3c-dist-auth-request@w3.org Fri Nov 30 13:12: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 NAA25585 for ; Fri, 30 Nov 2001 13:12:44 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA04976; Fri, 30 Nov 2001 13:11:03 -0500 (EST) Resent-Date: Fri, 30 Nov 2001 13:11:03 -0500 (EST) Resent-Message-Id: <200111301811.NAA04976@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA04952 for ; Fri, 30 Nov 2001 13:10:40 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.ucsc.edu [128.114.129.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA28774 for ; Fri, 30 Nov 2001 13:10:40 -0500 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.9.3/8.8.4.cats-athena) with SMTP id KAA20361 for ; Fri, 30 Nov 2001 10:10:43 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 30 Nov 2001 10:10:15 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01C17987.34D9CF40" 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: [Fresher to webdav] How to implement WebDav http extension methods in Java Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5697 X-Loop: w3c-dist-auth@w3.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_003D_01C17987.34D9CF40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Rohit.Marwaha [mailto:rohit.marwaha@oracle.com] Sent: Friday, November 30, 2001 1:18 AM To: w3c-dist-auth@w3.org Cc: Rohit.Marwaha Subject: [Moderator Action] [Fresher to webdav] How to implement WebDav http extension methods in Java Hi All, I am a new comer to this subject. I am looking to implement a client in Java which can communicate with WebDav enable server. However it looks like Java's networking classes like URL, URLConnection and HttpURLConnection only support standard HTTP methods. Do I need to look at sockets to implement a client or is there a better way available? Thanks in advance. - Rohit ------=_NextPart_000_003D_01C17987.34D9CF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Accidentally caught by the spam=20 filter.
 
-=20 Jim
-----Original Message-----
From: Rohit.Marwaha=20 [mailto:rohit.marwaha@oracle.com]
Sent: Friday, November 30, = 2001 1:18=20 AM
To: w3c-dist-auth@w3.org
Cc:=20 Rohit.Marwaha
Subject: [Moderator Action] [Fresher to webdav] = How to=20 implement WebDav http extension methods in Java

Hi All,
 
 I am a new comer to this subject. = I am=20 looking to implement a client in Java
 which can communicate with WebDav = enable=20 server. However it looks like Java's
 networking classes like URL, = URLConnection and HttpURLConnection only
 support standard HTTP methods. Do = I need to=20 look at sockets to implement a client
 or is there a better way=20 available?
 
Thanks in advance.
 
-=20 Rohit
------=_NextPart_000_003D_01C17987.34D9CF40-- From w3c-dist-auth-request@w3.org Fri Nov 30 14:38:16 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 OAA01199 for ; Fri, 30 Nov 2001 14:38:16 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA08855; Fri, 30 Nov 2001 14:34:26 -0500 (EST) Resent-Date: Fri, 30 Nov 2001 14:34:26 -0500 (EST) Resent-Message-Id: <200111301934.OAA08855@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA08829 for ; Fri, 30 Nov 2001 14:34:19 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA11435 for ; Fri, 30 Nov 2001 14:34:19 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA67564 for ; Fri, 30 Nov 2001 14:31:02 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fAUJXhY47582 for ; Fri, 30 Nov 2001 14:33:44 -0500 To: "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Fri, 30 Nov 2001 14:31:32 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9 |November 16, 2001) at 11/30/2001 02:33:43 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Purpose of Namespace Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5698 X-Loop: w3c-dist-auth@w3.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 couple of people have come forward to say we probably should not add an explanation of why we use XML namespaces in WebDAV. I have no problem with that, but I just want to point out the following that I just found in RFC2518, Section 1. The XML namespace extension (Appendix 4) is also used in this specification in order to allow for new XML elements to be added without fear of colliding with other element names. Because of this, I'd like to propose than we just go ahead and modify this to mention the properties issue. Okay? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Nov 30 14:48:38 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 OAA02010 for ; Fri, 30 Nov 2001 14:48:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA09149; Fri, 30 Nov 2001 14:41:36 -0500 (EST) Resent-Date: Fri, 30 Nov 2001 14:41:36 -0500 (EST) Resent-Message-Id: <200111301941.OAA09149@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA09127 for ; Fri, 30 Nov 2001 14:41:25 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37184.rational.com [192.229.37.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA13336 for ; Fri, 30 Nov 2001 14:41:24 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Fri, 30 Nov 2001 14:40:48 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Nov 2001 14:40:48 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8ADA1@SUS-MA1IT01> From: "Clemm, Geoff" To: "'WebDAV'" Date: Fri, 30 Nov 2001 14:40:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Purpose of Namespace Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5699 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Fine by me. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Friday, November 30, 2001 2:32 PM To: 'WebDAV' Subject: RE: Purpose of Namespace A couple of people have come forward to say we probably should not add an explanation of why we use XML namespaces in WebDAV. I have no problem with that, but I just want to point out the following that I just found in RFC2518, Section 1. The XML namespace extension (Appendix 4) is also used in this specification in order to allow for new XML elements to be added without fear of colliding with other element names. Because of this, I'd like to propose than we just go ahead and modify this to mention the properties issue. Okay? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Nov 30 15:18: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 PAA03850 for ; Fri, 30 Nov 2001 15:18:39 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA10777; Fri, 30 Nov 2001 15:14:55 -0500 (EST) Resent-Date: Fri, 30 Nov 2001 15:14:55 -0500 (EST) Resent-Message-Id: <200111302014.PAA10777@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA10755 for ; Fri, 30 Nov 2001 15:14:43 -0500 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA19680 for ; Fri, 30 Nov 2001 15:14:40 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA488834 for ; Fri, 30 Nov 2001 15:11:24 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fAUKE5Y114938 for ; Fri, 30 Nov 2001 15:14:05 -0500 To: "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Fri, 30 Nov 2001 14:54:06 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9 |November 16, 2001) at 11/30/2001 03:14:05 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Purpose of Namespace Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5700 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Just to clarify my note a bit... By "properties issue" what I meant is that XML namespaces are needed largely for the sake of properties. As per http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0299.html I'd like to provide a bit more info. (Sorry for being so fractured in the presentation.) I just want to point out in section 4.5 we already have... The XML namespace mechanism, which is based on URIs [RFC2396], is used to name properties because it prevents namespace collisions and provides for varying degrees of administrative control. Should we leave that XML namespace comment in section 1, modify it, or remove it. (You can find the text of it below.) J. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Friday, November 30, 2001 8:32 PM > To: 'WebDAV' > Subject: RE: Purpose of Namespace > > > > > A couple of people have come forward to say we probably should not add an > explanation of why we use XML namespaces in WebDAV. I have no > problem with > that, but I just want to point out the following that I just found in > RFC2518, Section 1. > > The XML namespace extension (Appendix 4) is also used in this > specification in order to allow for new XML elements to be added > without fear of colliding with other element names. > > Because of this, I'd like to propose than we just go ahead and modify this > to mention the properties issue. > > Okay? > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Nov 30 15:59: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 PAA06287 for ; Fri, 30 Nov 2001 15:59:40 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA13864; Fri, 30 Nov 2001 15:57:29 -0500 (EST) Resent-Date: Fri, 30 Nov 2001 15:57:29 -0500 (EST) Resent-Message-Id: <200111302057.PAA13864@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA13844 for ; Fri, 30 Nov 2001 15:57:06 -0500 (EST) Received: from sus-ma1it00.rational.com (ext-37184.rational.com [192.229.37.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA25477 for ; Fri, 30 Nov 2001 15:57:06 -0500 Received: from 192.168.215.70 by sus-ma1it00.rational.com (InterScan E-Mail VirusWall NT); Fri, 30 Nov 2001 15:56:34 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Nov 2001 15:56:34 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8ADA3@SUS-MA1IT01> From: "Clemm, Geoff" To: "'WebDAV'" Date: Fri, 30 Nov 2001 15:56:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Purpose of Namespace Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5701 X-Loop: w3c-dist-auth@w3.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 is probably still worth making the general comment about namespaces in section 1, because it is also useful for proprietary extensions to the method request and response bodies. It further looks like section 4.5 says all that needs to be said about namespaces and property names. So I'd say all that needs to be done is to get rid of the sentence that refers to concatenating the namespace URL with the local node name, and we are done with this issue. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Friday, November 30, 2001 2:54 PM To: 'WebDAV' Subject: RE: Purpose of Namespace Just to clarify my note a bit... By "properties issue" what I meant is that XML namespaces are needed largely for the sake of properties. As per http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0299.html I'd like to provide a bit more info. (Sorry for being so fractured in the presentation.) I just want to point out in section 4.5 we already have... The XML namespace mechanism, which is based on URIs [RFC2396], is used to name properties because it prevents namespace collisions and provides for varying degrees of administrative control. Should we leave that XML namespace comment in section 1, modify it, or remove it. (You can find the text of it below.) J. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Friday, November 30, 2001 8:32 PM > To: 'WebDAV' > Subject: RE: Purpose of Namespace > > > > > A couple of people have come forward to say we probably should not add an > explanation of why we use XML namespaces in WebDAV. I have no > problem with > that, but I just want to point out the following that I just found in > RFC2518, Section 1. > > The XML namespace extension (Appendix 4) is also used in this > specification in order to allow for new XML elements to be added > without fear of colliding with other element names. > > Because of this, I'd like to propose than we just go ahead and modify this > to mention the properties issue. > > Okay? > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Nov 30 16:03:20 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 QAA06598 for ; Fri, 30 Nov 2001 16:03:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA14305; Fri, 30 Nov 2001 16:00:59 -0500 (EST) Resent-Date: Fri, 30 Nov 2001 16:00:59 -0500 (EST) Resent-Message-Id: <200111302100.QAA14305@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA14255 for ; Fri, 30 Nov 2001 16:00:36 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA26044 for ; Fri, 30 Nov 2001 16:00:35 -0500 Received: (qmail 2687 invoked by uid 0); 30 Nov 2001 21:00:34 -0000 Received: from pd9e51719.dip.t-dialin.net (HELO lisa) (217.229.23.25) by mail.gmx.net (mp010-rz3) with SMTP; 30 Nov 2001 21:00:34 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'WebDAV'" Date: Fri, 30 Nov 2001 22:00:42 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8ADA3@SUS-MA1IT01> Subject: RE: Purpose of Namespace Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5702 X-Loop: w3c-dist-auth@w3.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. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, November 30, 2001 9:57 PM > To: 'WebDAV' > Subject: RE: Purpose of Namespace > > > It is probably still worth making the general comment about namespaces > in section 1, because it is also useful for proprietary extensions to > the method request and response bodies. It further looks like section 4.5 > says all that needs to be said about namespaces and property names. > > So I'd say all that needs to be done is to get rid of the sentence that > refers to concatenating the namespace URL with the local node name, > and we are done with this issue. > > Cheers, > Geoff > > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Friday, November 30, 2001 2:54 PM > To: 'WebDAV' > Subject: RE: Purpose of Namespace > > > > Just to clarify my note a bit... > > By "properties issue" what I meant is that XML namespaces are needed > largely for the sake of properties. As per > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0299.html > > I'd like to provide a bit more info. (Sorry for being so fractured in the > presentation.) I just want to point out in section 4.5 we already have... > > The XML namespace mechanism, which is based on URIs [RFC2396], is > used to name properties because it prevents namespace collisions and > provides for varying degrees of administrative control. > > Should we leave that XML namespace comment in section 1, modify it, or > remove it. (You can find the text of it below.) > > J. > > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > > Sent: Friday, November 30, 2001 8:32 PM > > To: 'WebDAV' > > Subject: RE: Purpose of Namespace > > > > > > > > > > A couple of people have come forward to say we probably should > not add an > > explanation of why we use XML namespaces in WebDAV. I have no > > problem with > > that, but I just want to point out the following that I just found in > > RFC2518, Section 1. > > > > The XML namespace extension (Appendix 4) is also used in this > > specification in order to allow for new XML elements to be added > > without fear of colliding with other element names. > > > > Because of this, I'd like to propose than we just go ahead and modify > this > > to mention the properties issue. > > > > Okay? > > > > J. > > > > ------------------------------------------ > > Phone: 914-784-7569, ccjason@us.ibm.com > > > > > > > > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > From w3c-dist-auth-request@w3.org Fri Nov 30 16:19:02 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 QAA07634 for ; Fri, 30 Nov 2001 16:19:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA15546; Fri, 30 Nov 2001 16:14:50 -0500 (EST) Resent-Date: Fri, 30 Nov 2001 16:14:50 -0500 (EST) Resent-Message-Id: <200111302114.QAA15546@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA15492 for ; Fri, 30 Nov 2001 16:14:37 -0500 (EST) 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 QAA27596 for ; Fri, 30 Nov 2001 16:14:37 -0500 Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id fAULE6C10662 for ; Fri, 30 Nov 2001 13:14:06 -0800 Received: from waka.ebuilt.net (IDENT:root@i142.ir.ebuilt.net [10.1.2.142]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id fAULE5Z10496; Fri, 30 Nov 2001 13:14:05 -0800 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id fAUL9co01764; Fri, 30 Nov 2001 13:09:38 -0800 Date: Fri, 30 Nov 2001 13:09:38 -0800 From: "Roy T. Fielding" To: Mark Baker Cc: Larry Masinter , "'Martin Duerst'" , "'Stefan Eissing'" , "'WebDAV'" , uri@w3.org Message-ID: <20011130130938.A1552@waka.ebuilt.net> References: <20011126152733.B8631@waka.ebuilt.net> <200111300417.XAA03496@markbaker.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200111300417.XAA03496@markbaker.ca> User-Agent: Mutt/1.3.20i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5703 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > But I'd point out that "about:" appears to me to be designed to be > a relative URI; if IE supported "about:", it wouldn't pop up > Communicator's info screen, it would pop up one about IE. Ditto what Martin said -- that is confusing the terminology. A relative URI is a syntax construct (one name relative to another name), not a mapping construct (one location relative to another location). A URI like news:comp.infosystems.www identifies the newsgroup even though the representation retrieved by accessing that newsgroup will depend on context (configuration of NNTP host and the amount of that news feed that has propagated to that host). ....Roy